Introduction
Recently, I released a framework that I call a Web Theming Infrastructure, and I think it's worth dissecting and exploring here given the potential that I see in it. But first, I have to explain how I got to this point.
For more than a decade, web theming at Georgia Tech has been the domain of Institute Communications, and they have handled both specifications and implementation. Unfortunately, they've never been funded to act as a true central web development unit, so they have struggled to manage the implementation side of the equation. I would imagine that Georgia Tech is not alone in facing this kind of problem, but like most universities, we have been applying early 2000's techniques to a rather complex problem that needs a more sophisticated approach.
The tradition has been for Communications to build one, possibly two implementations of the campus theme: one in the content system du jour (Drupal 6, Drupal7) and sometimes one as just static HTML. After content systems came into play, it was common for the static HTML implementation to stay woefully out of date, as it was always a completely separate instance from the Drupal implementation, and thus had to be manually updated any time changes were made to the Drupal version.
It didn't help that work on the initial Drupal 7 version was fielded out to a design company that didn't seem to know how to actually build a proper theme for Drupal, and thus lumped many pieces and parts into the Drupal page template and lumped all of the CSS into one gigantic file. The critical problem here is that there was no separation of the core of the web theme from the pieces needed to adapt the core specifically to Drupal 7, so trying to extract just the core to create other implementations was exceedingly difficult. Extracting from the static HTML implementation was a little more straightforward, but even then one was ultimately creating their own completely separate implementation and having to manually apply any future core design updates.
In addition to the deep mixing of core and Drupal specific code, there was also no clean separation of code for individual components, making customization and improvements rather difficult, even on the most basic level. Because Drupal's native block system wasn't utilized at all, there was no way for units to pull out individual pieces that they might not want or need to use and replace them with other components. Any changes of that nature had to be done by forking (duplicating) and modifying the page template, which meant that the unit effectively created their own separate implementation (and again had to manually maintain it from then on). A lot of units stayed away from the new theme as long as possible, while others ended up paying outside developers to make their own custom versions, which usually didn't line up at all with the official version, even in the areas that were meant to be in alignment.
The Premise
What is needed for campus website theming is a truly modular, platform agnostic web theming system that:
- Gives units the much needed flexibility to:
- Pick and choose which components they want (or need) to use, especially for special use cases
- Easily replace optional components with other suitable third-party or custom built components
- Avoid the costly hiring of an outside developer just because they have a bona fide special need for a slight change to the theming design (e.g. a joint partnership with another university)
- Allows unit developers on campus to contribute to implementation development for specific applications without having to fully reinvent the wheel
- Automates the flow of centrally approved updates into the various implementations, eliminating the impractical manual application of updates to every implementation
Since I was not aware of any such system already existing, I began developing one in the fall of 2016 using a new "version 3" Georgia Tech web theme design that had been developed to a beta test state over the summer of 2016 by a web theming committee. My goal was not to change the designs themselves, since it is rightfully up to Institute Communications to finalize the designs, but to build an infrastructure for implementing those designs in multiple web applications where updates to the core designs can be pushed into all implementations without any manual labor whatsoever.
Structure of the System
When you start to analyze a web theme, you can break the core down into four basic parts:
- HTML Code - provides the structure of the overall page and theme components
- CSS Rules - styles the page and components (colors, spacings, sizings, borders, etc.)
- JavaScript Code - automates any interactive features of the theme components
- Image Files - logos, icons, and other imagery
Ideally, the same core files and code should be directly insertable into skeletal package stubs for many different applications, with the package stub containing code wrappers and any extra CSS needed to adapt to the quirks of the application itself. But first, you have to boil down a theme design to just these four basic parts.
While my initial implementation goal was Drupal 8, I quickly realized the value in first focusing on a simple PHP library for stand-alone PHP applications. This helped me create my core implementation and ensure that it only contained the minimum necessary code for implementing the overall page structure and each key component that the theme system needed to provide:
- Georgia Tech Branding Header
- Site Identity Box
- Social Media Bar
- Accessible Hover Drop-Down Menu Bar
- Georgia Tech Branding Footer
I call these the "BIN" components: Branding, Identity, and Navigation. They are the most important parts of making a website look uniformly "themed" within an organization. The other two parts of theming, "Page Layout" and "Content Styling", I separated out for ease of maintenance, since they can completely stand on their own. At this time, I've only implemented Page Layout and Content Styling for Drupal 8 and Drupal 7, but I have partially ported the Content Styling CSS rules to the stand-alone PHP Library implementation.
The Build System
The next step in building a theming infrastructure was working out a way to merge the core with the skeletal stub of an application. For that, I developed a robust PHP script that functions a lot like the UNIX/Linux "make" command for building a software package. My build system uses my own version of a "makefile" for indicating which core files need to be copied in whole to specific parts of the implementation directory tree, and supports tokens to allow HTML code and other values (e.g. a version number) to be inserted into stub PHP and configuration files. The "makefile" processor is even capable of aggregating multiple CSS files (or JavaScript files) into a single file, making the final implementation a bit tighter when the application in question doesn't do its own CSS and JavaScript aggregation.
From there, I began expanding the functionality, thinking about what would really save time for someone maintaining this system in the long run. Sometimes, it's the little stuff that really makes life easier, such as automating the deployment of newly built implementations to test websites hosted on the same server as the build workspace. Thus, every time I run build, I can immediately bring up any of the test websites to see how the new build looks without having to do any manual copying or unpacking of archive files on the backend. Similarly, I added automatic copying of the compiled versions up to an NFS share so that they would be available to any of my other web servers that mount that same share. It would be easy enough to extend that feature to push the files into a repository that others on campus could access.
Current Supported Implementations
While this kind of system will always be a work in progress, as of the time of writing (late November 2017), I have built implementation support for the following applications:
- Drupal 8: BIN Components, Page Layouts, Content Styling
- Drupal 7: BIN Components, Page Layouts, Content Styling
- WordPress: BIN Components (GT Header/Footer only)
- Omeka: BIN Components (GT Header/Footer, Site Identity, and styling of the Omeka Menu Bar)
- PHP Library: BIN Components, Content Styling (partial)
- Static HTML: BIN Components (GT Header/Footer and Site Identity only)
On the drawing board are plans to hopefully port the rest of the BIN components over to WordPress to create a full WordPress theme package.
Possible Future of the System
Here's where it really gets interesting. Lets say that a developer on campus has an application that they'd like to adapt to the campus theme using the Web Theming Infrastructure (WTI). Such a developer could request a copy of the WTI build workspace, which is easily archived and shared, and then use their copy of the workspace to locally develop the skeletal stub for their implementation. Once they have it working, they could submit the stub to whomever centrally manages the WTI for inclusion in the central system. There would be a low barrier of entry for this, since adding stubs won't affect the core or any other stubs, and the central manager wouldn't have to offer any support for "third-party" stubs. They would just get rebuilt whenever core changes and the resulting implementations made available through a repository for download without any offer of support or guarantee of usability.
Alternatively, if the build workspace and the up-to-date core files are made available to all of campus in a repository, the developer could just download the most recent set of core files periodically and do his/her own rebuild as desired. Even if the up-to-date build workspace were not always available, the core files can always be extracted easily from the stand-alone PHP library, providing another avenue for future sustainability.
In the far future, I would love to see big application teams like Drupal, WordPress, Joomla, ZenPhoto, Omeka, etc., collaborate on a common theming infrastructure based on the ideas I'm developing here. It would be a huge win for the web community if an organization like Georgia Tech could just develop their organization-wide theme in one standard format and drop it into most of the popular web applications out there. Until then, I think a system like my Web Theming Infrastructure is the best way to provide support for theming multiple web applications with minimal overhead and maximum ability to expand to more applications over time.