The WGBH.org Development Blog

One great thing about Drupal is being able to easily put your site into site maintenance mode. For example, if you need to perform some site maintenance work (like installing core or contributed module code updates) you can easily put the site into this mode by clicking a button on the following form:

What this will do is then direct all anonymous and non-admin users to a page using your chosen theme with a message that you write, which you plug into the message box. For WGBH.org, the page looks like this:

So - easy!

However, this page can’t be used for some types of site maintenance, like, for example, maintenance work that takes the database offline. No database, no Drupal-generated site maintenance page. Bummer.

We recently faced this problem when our fine friends in the WGBH IT department needed to do some MySQL maintenance work (they wanted to do a little cleanup and reorganization of the database files on the production server). Since this type of work comes up now and again, I wanted to devise an easy way to post the same site down page that all requests for the site would get directed to, with the minimal amount of work, so IT could incorporate it into their process for future maintenance work. I wanted a simple process to make everybody’s life as easy as possible.

My first thought was to have an alternate Apache config file for the site, which would point to a different document root that stored the site down code and graphics. This would work well enough, but would require stopping Apache and then restarting it using the new configuration file. Not too complicated, but still more steps then I wanted.

After some coffee and deep thinking the solution popped right out me: symbolic links!

The document root for the site is actually a symbolic link to the real directory of Drupal code. So, I figured, if we just change that link to point to a new document root, containing the site down code, then - bingo - we’d be done! That’s even easier than using an alternative Apache conf file.

So, this is what we did. There was just one other fine point here: where to put the site down directory?

Initially, I figured on a directory completely separate from the Drupal tree. However, that would then mean we’d need to copy all the required images and style sheets from the Drupal tree to the site down tree, making future maintenance a bit more work (we do tweak the site down page according to what’s going on at the time). Kind of a pain.

What we did instead was put the site down directory within the Drupal directory tree. That way the page code could reference the appropriate images and style sheets. Plus, that code then gets managed via SVN as part of our Drupal code base. The final approach, then, involved the following:

* Create a site_down directory under the top-level Drupal directory.
* Create an index.html file in that directory that contains the source code from the Drupal-generated site maintenance page.
* Tweak the source code to use absolute, rather than relative, links to images and CSS files.
* Create an .htaccess file to make sure all page requests get redirected to the index.html page.

Voila! Using this method, all IT had to do before performing their database maintenance was change the docroot’s symbolic link to point to the site down directory. Then, when the work was done, change the link back. No need to even stop/restart Apache.

So - once again - easy!

If only fixing the economy were so simple…

Do you have a different method for handling this sort of thing (or for fixing the economy)? Talk amongst yourselves then please share!

Drupalcon Day 2 started off better than Day 1. Why? Because I decided to skip the hell out of the free coffee and just buy my own at Dunkin’ Donuts. Sometimes free just ain’t worth the cost.

The morning started well when I ran into Robert Douglass, formerly of Lullabot, now of Acquia. Late last year Robert worked with us when we hired Lullabot for some consulting on our rebuild. We had only worked with Robert over the phone and via email, so it was nice to meet him in person. In addition to being a Drupal genius, he’s also a very nice guy. More on Robert in the coming days…

Today Pete and I were joined by another WGBH developer and our buddy, Josh Boughey. Josh works in the membership department and will be working with us to rebuild WGBH.org. Hopefully we’ll get Josh to blog here about his involvement at some point.

Other than that, it was more of the same. Lots of people with facial hair, lots of laptops, lots of Drupal talk, of varying degrees of usefulness. Here’s a recap:

The first session I hit was Best practices in development environments, staging, build management,
and production environments. This was pretty good, though mostly high level. There were some interesting things to note.

One of the panelists was Narayan Newton, the DBA for OSU Open Source Lab; they’re the ones who host Drupal.org. He gave us a rundown of their setup: four load balanced web servers, two database servers (one active, one passive, using replication).

Narayan told us about how they’ve made use of this database replication patch, which allows them to redirect all read queries to the passive database, thereby improving performance. He says that the new database layer for Drupal will support this functionality by default.

One person in the audience got up and spoke about SQL Relay and MySQL Proxy, both of which offer the ability to load balance requests to your MySQL database servers. This is all worth checking out.

The panelists then talked about leveraging source control. One panelist said he didn’t see the need for branching if you’re just developing for yourself (which is my opinion, also). A common code control approach is to use CVS to manage the core and contributed Drupal code, and import that all (including the CVS subdirectories) into SVN. This is the approach we plan to use for WGBH.org. The panelists differed over whether to deploy from staging to live using SVN or rsync.

They then talked about automated deployments. The Open Source Lab folks use something called Cfengine to manage the system configurations of all of their servers with a small staff.

The discussion then veered into the topic of code vs. content migration. The upshot here was that nobody seems to have a good solution to the problem of migrating database changes from staging to live environments (particularly, settings and content in the db that needs to be migrated). Again, though, the audience stepped up and somebody recommended the Publish and Subscribe modules to push from staging to live. Somebody else suggested Drupal Migraine (yes, like the headache), which is a Python-based (the scripting language, not the snake) tool for doing this sort of thing. We’ll have to check these all out.

Things wrapped up with a discussion of QA best practices. One of the attendees got up and mentioned a tool called Watir, a Ruby-based (the language, not the precious gem) tool which allows for automated cross-browser testing. It works on Windows IE, but there are also Firefox and Safari versions. The crowd was duly impressed.

The big session of the morning was by Chris DiBona of Google, who gave an entertaining and interesting speech about open source and why Google supports it. I believe that Chris will be doing two shows nightly throughout the week. Try the fish!

Following a lunch of a burrito con carnitas, I attended one of the birds of a feather sessions, about the problems with upgrading staging environments to production systems. People kicked around potential solutions for pushing configuration and content changes that are stored in the database from the staging to the live database.

The most common solution involved writing any number of scripts to dump DML and content from the staging database and import them into the live database. This approach makes some people uncomfortable as it sidesteps the usual Drupal APIs (either using the GUI or programming it on the back end).

Another solution is to enable binary logging for MySQL. Binary logging causes all SQL statements that updated (or could have updated) data (e.g. no select or show statements) as executable commands. You can then extract those commands (filtering in/out the ones you want/don’t want) using MySQL tools and writing the commands out to a text file of SQL commands that can then be executed against the live database.

The main problem with both of these approaches is the potential for overlapping ID numbers. Some people get around this by allocating the first X number of auto increment IDs (like the first 1,000 or 10,000) for use on the development server only. That sounds clunky to me and I’d rather not do that.

After a break for coffee and a large chocolate chip cookie, all of us GBHers headed into the Theming with the Theme Developer module session, led by Moshe Weitzman, who wrote the new (as of Drupal 6) theme developer module.

This module looks mighty slick.

It’s part of the Devel module distribution. The big thing here is that there is now support for sub-themes, meaning that you can base a theme on an existing theme and simply override the parts of the parent theme that you want to change without having to replicate all of the theme code. Wow-wee! Themes now have .info files, in which you can define a base or parent theme.

Another great thing about this module is that is makes use of Krumo (which you need to first download into the Devel directory). Krumo allows nice functionality like being able to highlight and click on page elements and see what file or function is controlling its style! It tells you how you can override the base theme’s styling. It will also show you all variable and parameters passed into the appropriate theming function and let’s you browse all of the data available to that theming function. It looks as sweet as that big-ass cookie I ate just before the session.

Bottom line is this new module looks like it’ll make theming much, much, much easier.

After that, I called it day and headed home to help put the kids to bed.