I’ve been pretty busy lately with several projects, most of which are developed on Drupal. One, in particular, has been really exciting to work on. The great thing about working in the web industry is that your clients are often varied and interesting people, and this is a good example.
The most recent major project was for a new public policy think tank called ResPublica. I won’t pass judgement on their politics, except to say that the people involved are all committed, intelligent and genuinely hoping to make a positive difference to the world. I’ve already blogged about the purpose of the site and written a case study on Drupal.org, but I’d like to go into a bit more detail about the process of building and deploying sites like this. <!–break–>
Drupal’s new essential modules
There has always been a class of Drupal modules that were ‘essential’ for most sites despite not being part of Drupal core. In Drupal 5, the essential modules included Views, CCK and often an image-handling module like ImageCache. Google Analytics, XML Sitemap and others were useful, but for me Views + CCK were the two modules that I would always use on every project. Drupal 6 suffered greatly from the fact that these modules were not 100% ready with upgrades when Drupal 6 launched - a problem that has been largely solved for the upcoming Drupal 7.
Since Drupal 6 was released, a few new modules have made it on to the 'essential’ list. The first is 'Features’, which integrates with CCK, Views, Context and other modules to make it easy to package your settings into code in a module. This means that you can create Views and Content Types on your development server, save them as a 'Feature’ (which is a Drupal module with some extra hooks) and then install that module on your production server. Voila! Your settings appear on the production server instantly. No need to manually export/import anything. This radically simplifies deployment and development scenarios.
Even better, because Features are stored in code and not in the database, there are far fewer occasions when you might need to take copies of database tables. If you wipe your database, you still have all of your Views/Content Types/etc. And to add icing to the cake, storing these settings in code means that they can be committed to source code control (I use git, but any version control system would be suitable). With this, you can have a full version history of your major Drupal configuration options, able to roll back to old versions or compare old with new.
Features was created by the guys at Development Seed, and they’re still developing new, ahem, features which make this even more exciting. One of these is the ’Feature Server’ which provides an easy way to distribute Features that you have created. For example, if you have created an image gallery using CCK, ImageField and Views, you can package the settings up as a Feature (which will automatically have the correct dependencies) and distribute it via your Feature Server. Sites using your Feature will check the Feature Server for updates to the Feature, notifying admins of new versions just like new versions of modules on Drupal.org.
One of the modules that I mentioned integrating with Features earlier was the Context module. Context solves the frustrating problem of getting Drupal to display the correct blocks of content in sidebars, footers and headers around particular pages. In the traditional block configuration page, which hasn’t changed much since I first started using Drupal four years ago, you can optionally enable/disable the block based on user permissions and on a match with the URL path. This works well if you have a simple URL structure on your site, but can quickly become troublesome on sites with complex URL structures. And heaven help you if you change your URL structure - all of your blocks will need to be updated too. If you want to use any other information to control block visibility, your only other option is to write a PHP snippet to control it, or install one or more custom modules.
Context solves this by creating a simple UI for selecting from a wide range of criteria to control block visibility. You can select criteria such as node content type, location in the menu trail and the traditional URL path. Context can also be used to disable whole regions (for example, disabling a sidebar on the home page) and to set custom theme variables. It’s a far superior way to control aspects of your site’s appearance based on context, and I expect that it will develop further to allow for more fine-grained control.
My other choice of essential module is, in fact, not a module at all. Drush is a command-line script which can be used to perform many common administrative tasks from a shell prompt, rather than via the web interface. It can also do a few things that the web interface can’t (without custom modules), such as downloading modules, clearing the cache and taking a backup of your database. For a developer, this speeds up common tasks considerably and, in particular, makes setting up new sites incredibly straightforward.
There’s lots more that I would like to mention, including drush_make and the Aegir hosting platform, but I’ll have to return to them another time (if you want to know why these are a big deal, read this post).Share