Drupal Fails to Upgrade: one possible cause.

A cautionary tale for those who maintain Drupal websites and have big mouse-clicking fingers (like me).

Recently when applying a security release (6.19 to 6.20) to a production site, I came across a situation where replacing the core Drupal files at the root of the site and running update.php silently ‘failed’. Try as I might I could not get the site to accept that the core files had been overwritten and where now version 6.20. Google for once was of no use.

When I copied the production site down to my local server, I could frustratingly reproduce the failure. As I tend to when I don’t have ‘Clue One’ about a problem, I had a look around the system to see if there was anything obviously amiss. This is a complex site built by good external developers who had organised the none-core modules under a sites/default/modules folder structure, with separate folders for custom, altered and standard modules. Under the standard modules folder, amongst forty-odd others, was a folder labelled ‘drupal-6.19’. I suspect this was because I collect all the modules and core files to be uploaded during a maintenance window in one place and carelessly copied everything into sites/default/modules.

The alarm bells started ringing and when I looked at the site [system] database table, where the file path to all modules used by the site is stored; I found that the site was running off the core modules in the sub-sub-sub folder ‘drupal-6.19’

I postulated two possible fixes. The most straight forward was to copy the contents of Drupal core 6.20 into the folder ‘drupal-6-19’ and run update.php. The site would be updated, but with a rather add file structure that might come back to bite me (or more importantly, someone else) on the backside latter.

The second fix was more complex, but in my mind more correct. The fix is straight forward, but a requires you to be happy altering Drupal database tables ‘by hand’.

• Put the site into maintenance mode;
• Delete the extra Drupal core files folder under the modules folder - in this case ‘drupal-6.19’.
• Export the [system] table from the database as a SQL file and save a backup locally.
• Load the [system] table into your favourite text editor - TextMate in my case.
• Find and replace the file path that is pointing towards the sites/default/ modules folder so it redirects to the root modules folder. This was:
  ‘sites/default/modules/contrib/drupal-6.19/modules/...’ that was replaced with ‘modules/...’ This redirects the file path back to the core modules at the site root.
• Drop the original live [system] table.
• Import the altered [system’] table.
• Run update.php. In my case this upgraded the site to 6.20, as I had previously copied over the 6.20 files to the site root during my failed upgrade attempt.
• Clear caches and take the site out of maintenance.

You have now returned your site to the more traditional file and folder organisation.