Utilizing Cross-Web-Property Headers and Footers
Whether you're redesigning an entire website, modifying footer text, or changing the name of a menu item, running "duplicated code" for any given element across multiple web properties can be a serious pain point. It's not only incredibly inefficient but also leaves gaping holes for human error. You simply shouldn't be - and certainly don't want to be - maintaining multiple instances of code across a variety of web properties. Centralizing that code into a single instance allows for efficient code management while ensuring that all the web properties are 100% consistent at all times.
One of the ways we've circumvented this issue is the utilization of custom theme APIs. The goal is to maintain one set of code which automatically updates across multiple domains or websites. In this way we can make one update to an element, push it live, and instantly have all the other web properties using the new updated code. There are a hundred different ways to accomplish this, but for the purposes of this article I'm going to take a ten thousand foot view of one example use case within Drupal 7.
The first step is to create the custom API endpoint. A good method for this in Drupal 7 is usinghook_menu() to create a custom path within the system. Using the "page callback" to call a custom function, that custom function then calls another unique function, depending on the url argument. There is one for each theme piece that needs to be opened up to the API. In this case, one for the script and style-sheets, one for the page header, and one for the page footer.
The next step is to write individual functions for each theme piece. These functions are not only called from the API endpoint created earlier, but also in the theme files themselves. The functions become a placeholder for any instance where the particular theme piece needs to be output. The head piece is more straight forward - some calls to drupal_get_html_head(),drupal_get_css(), and drupal_get_js() and we are pretty much done. With the header and footer functions we pull in a *.inc file for each as they both need to contain some HTML markup. In both cases it is all markup, with the exception of the menus which were obtained via menu_tree_all_data() and menu_tree_output().
Once those are in place, the API functions and theme files make calls to those functions. This pulls in all the needed markup in each case, with the new custom API spitting out markup for each theme piece. We can make simple GET requests from other existing web properties to each API endpoint and pull in that markup on the fly, throughout the life of the site. An update can be made to the functions/inc files (in a version controlled system like Git). When those changes are pushed to the production site, all web properties utilizing the API instantly receive the updates as well.
There are some considerations to take with this approach, however. One is the fact that it calls functions to pull in data on pages where that data was already available. For example, the calls to get_html/get_css/get_js are redundant in the theme layer since the data is already in the template variables. Another is an increase in requests created from other sites using the new theme API (more load on the server). Some clever workarounds can be created by utilizing some of the available variables, or through caching output (which are both topics for another article!).
