Theme deployment and maintenance was drastically improved when I moved theme settings to an indepedent repository rather then editing manually. Further process automations provided reduced bug and feature request times.

When I started at Learning Pool, there were roughly 150 Moodle instances, one for each of our customers. Each instance was a separate code structure and each were manually maintained, core codebase, custom features and themes alike. I lead the initiative to automate the maintenance and deployment of themes across all instances. This opportunity was made possible during an effort by the developer to dramatically reduce the number of instances that were being supported by serving multiple sites off of the same codebase.

Within a Moodle instance the theme settings were stored in a separate database table. So, instead of editing individual theme settings through the web interface, I wrote some scripts with SQL queries to extract individual theme information and store in a dedicated database that stored the theme settings, precursor to design tokens, for all our brands as well as custom scripts that was able to spin up a local instance of the latest Moodle code with our customizations, the preivous day's data backup as well as the theme data from the theme database. This was necessary to both create and deploy new themes as well as address any theme related bugs quickly and confidently.

Advanced themes were also supported by injecting custom CSS and images into the same Moodle theme layer. Those customizations were also keep in the centralize theme database which expanded to include more theme information than only the values to be injected into the Moodle theme table.

When I finished up at Learning Pool in 2013, the number of supported instances had grown to over 300 all easily managed by a few keystrokes.