How to include across many differing platforms?

November 19, 2008 5:36 PM

30-45 separate vendor servers with lots of platforms. One template design that must be on all of them, and all must look alike and undergo some minor changes every week. How on earth do I keep them synchronized? As always...

I work for a newspaper. We use vendors for nearly everything we do. No two venders could possibly have the same requirements for their templates, so as a result we have literally dozens and dozens of flat HTML pages scattered about that must be updated by hand every time someone decides to change a link in some part of the nav or a logo in the footer.

I've been pushing hard for some sort of standardized system for doing this for months. There's no way to serve the entire flat page from one place on our webservers. There's no platform commonality that would allow me to just use a php include everywhere. I've nearly coded a set of functions that does the task really elegantly in javascript, but the cross site limitations of that language have me wanting to give up.

Any ideas out there? I've been given the latitude to do nearly anything I need to to make this work. I'm not looking for a complete system, just a nudge in the right direction. For the record, the includes are built and they are simply fragments of semantically valid XHTML. One tired template maintainer thanks you :)

posted by littlerobothead to computers & internet (6 comments total)

You could reverse-proxy through Apache and resolve some SSIs which would just look like comments on each platform. That's effectively approaching it from the other side... treating these 45 vendors like 3rd party websites that you scrape in and redesign with your template.
posted by holloway at 5:52 PM on November 19, 2008

Some sort of reverse proxying could work, whether SSIs as holloway suggested or another dynamic templating system in a programming language.

The disadvantage I see to proxying is that the per-request performance might decrease due to the extra overhead. It seems like this is taking a problem you have occasionally and solving it on every page request. But it could work.

Another possibility would be to address the problem of having to manually update multiple templates by making some sort of ur-template from which the 30-45 other templates can be generated. You could store all the pieces of the ur-template in a database, or files, or string constants for that matter. Then for each vendor system there would be a template-generating template. A shell/Python/PHP/whatever script would re-generate the vendor-system templates after the underlying information is updated. This system allows for both items that are standard across all templates (logo, main navigation) and items that are specific to particular vendor templates (after all, a specific section of the site might have some specific items in the template).

Also, make sure that as much as possible is being done in CSS, formatting-wise, though that doesn't help with adding navigation.
posted by pengale at 6:10 PM on November 19, 2008

The disadvantage I see to proxying is that the per-request performance might decrease due to the extra overhead

Yeah but you'd cache the result and that could¹ even speed up the system.

¹ if the site doesn't change much
posted by holloway at 6:32 PM on November 19, 2008

I worked for a newspaper as a programmer that dealt with a lot of vendors and a lot of vendor templates. We solved this problem by having our content management system output a blank page in the basic site template. Then, for each vendor, we write a script that parses the blank page into templates for that vendor. In some cases, the vendors had FTP sites where we could upload our templates and that step could be automated. We run these scripts via cron every hour or so.
posted by bryanzera at 8:22 PM on November 19, 2008

pengale's approach sounds like the first thing I'd try if this were my problem, except that as a first cut I'd just implement the template-generating-templates as individual scripts in their own right rather than bothering to try to design my own template-generating-template description format.

Only if I found that most of the scripts were nearly identical, and that the scripts themselves had started to require frequent updating, would I start thinking about a template-generating-template-based central script.
posted by flabdablet at 12:13 AM on November 20, 2008

To clarify my answer, I would recommend using an existing third-party templating library (such as Mako for Python or Smarty for PHP) for the template-generating-templates, rather than rolling your own format. Using these libraries, the templates are sort of like individual scripts as recommended by flabdablet, except that a single executable script can call them all and save the results to files. I see the benefits of not abstracting any more than necessary up front but do not see the benefits of separating this into different executable files per se.

The database, files, or string constants I referred to would be for common "pieces"; for example, the common navigation bar HTML might go in a keyed database row, a file, or constant, depending on your architectural preference. The script would load these values into an associative array (or whatever data structure of choice your templating system uses) and provide them to all of the templates. The templates could be coded to take these common values and insert them where needed, intermixed with vendor-specific HTML.

Sorry if my first answer wasn't clear; I was up late.
posted by pengale at 10:32 AM on November 20, 2008