drupal

http://petermoulding.com/drupal_versus_write_your_own_code

There are two questions that I think are easy to conflate here:

1. This is a content-based site; should I use an off-the-shelf CMS like Drupal or write my own?

2. This is not a content-based site; what should I do?

To me the answer to the first question is a no-brainer: the advent of free CMSes like Drupal and Joomla have made the concept of a CMS into commodity software. Although the ease of customization of Drupal has sometimes been overstated, I find it hard to believe people who claim that, even with customization, they couldn't get at least one off-the-shelf CMS to do what they wanted for their (often quite straightforward) site; it's worse when that's followed by the second claim that their experience meant it was a good business decision to build an entirely custom offering. In short: custom CMSes make me want to weep!

Even if you don't choose Drupal, there's very rarely a use case for writing your own CMS for a CMS-driven website: after all, what fraction of organizations would propose to write their own word-processing software to put together a spreadsheet, rather than e.g. bodging the requirements with macros?

Answering the second question is much trickier. Drupal, especially if you embed it in a well-tuned LAMP stack in preparation for high traffic, is optimized (very broadly) for delivering managed content. User interaction is best kept at a minimum for performance, as otherwise you start to find yourself jumping through quite narrow hoops (Varnish edge-side includes, anyone?) to get the site to be both performant and interactive for each and every site visitor.

Even then... as you move away from Drupal, you find yourself either having to adopt a lightweight web framework, or having to spend time rewriting even simple things like drupal_not_found(), drupal_add_js() or user_access(). Who really wants to have to wrangle HTTP headers themeslves? And yet, the more a site looks like a blended content/application offering, the harder it is to make the call. Splitting the site build up into smaller features, and building it in a way that lets you make that call on a feature-by-feature basis, is one way to forever postpone that decision; maybe having a framework like Symfony in core to call upon is another way.

One of our clients' Drupal sites is already using Webform Protected Downloads to restrict access to file attachments. This module depends on Private Upload, although there is - confusingly - another module called Private Download that does something very similar: runs files stored in certain directories through PHP, so that Drupal can check whether or not the visitor and their context permits them access.

Because the client is moving to a slightly different setup, including taxonomy- and role-based access control using TAC Lite, then they need both of these "Prviate *load" modules in place at the same time. Rather neatly, we've found that they don't conflict at all: except for one bug, which you might even manage to avoid. 

Each module has a configured subfolder, which it maintains, and for any file in its subfolder, the module makes the decision. But Private Upload is over-generous in its decision about what counts as its files: if its subfolder is e.g. "private", but Private Download is using "private_download", then Private Upload spots that the latter begins with the text of the former, and assumes that they're its files too! That is, Private Upload checks for files beginning "private...", not "private/...."

Quick to fix, if you spot it before you have installed and are running both modules: just make sure that the folders have wildly different names. Or apply the patch I submitted.

You’ve been a very good boy. We’ll miss you.

Drupal’s Twitter Pull module is a useful one: not just for its own UI elements, but also for getting tweets to format yourself. However, in a recent version change, it lost its $tweet->time_ago property on the tweet objects.

You can recreate this straightforwardly using the following PHP:

<?php 
$tweet->time_ago = format_interval(time() - $t->timestamp);

It’s a minor pain but if you’ve exposed your own theme implementations to preprocess hooks - and why wouldn’t you? - then it should be easy to put in e.g. your template.php.

The RobotsTxt module effectively requires a hack to Drupal core in order to function. This is because core Drupal contains a static robots.txt file, and webservers like Apache are configured by Drupal’s .htaccess file to serve static files preferentially to asking Drupal for the content. Every time Drupal is upgraded (or you deploy the site to a new staging or development instance), that hack has to be repeated.

One solution which Johan hit upon a while ago was to patch Drupal’s core .htaccess file, to send any request beginning /robots.txt to Drupal rather than serving any file on disk. It still constitutes a hack to core, but as a patch file accessible at a URL it can be incorporated into e.g. drush make files, and applied automatically when Drupal core is upgraded.

The patchfile-based hack is a big improvement, but it still leaves the RobotsTxt module complaining that there’s a problem. This is because it checks for the robots.txt file on disk, not for the /robots.txt URL, which is the real acid test for whether the module is working properly. So now we’ve also added this patch for robotstxt_requirements(), which checks the URL instead.