Drupal has been in the new today for all the wrong reasons

Millions of websites hit by Drupal hack attack

I’ve been running this blog (or some version of it) for almost 10 years now.

I write to help clarify my own thoughts, or to note down technical details of a task that I have struggled to figure out. I often found myself coming back and have saved many hours of trying to figure out the same thing again a year or more later.

I’ve exported this site from Drupal using wget to create a static html version like

wget  --mirror -p  -e robots=off --base=./ -k -P ./ http://localhost/

Then rsync to the server and use mod rewrite to retain the paged links like frontpage?page=4

I have a site which requires users to be logged in, but the pages are not customised. I was playing with a way to cache the content in varnish while still doing an access check. This method uses an access check pages (test.php below) which then uses ESI to load the real, cacheable content.

I’ve tried it in a dev env, I’m not yet sure if we’ll use this in production.

Varnish config

My build script has been getting more complex lately and I’m quite pleased with it.

We tend to have several versions of code on the go, version x is live, x+1 is in UAT, and x+2 is in development. With all these versions around it’s important to keep track of changelogs, and to upgrade correctly x to x+1, and then x+1 to x+2 as we have found that going direct from x to x+2 can fail to uncover some bugs. Specifically this happens if a drupal update hook gets edited after it has been released to the client, but before it has run on live. Our builds always start from a copy of the live site.

On a project I’m working on at the moment we have a problem, files are going missing.

We don’t know which part of the system could be trashing these files (user uploaded images in this case) and they are on a shared filesystem so there are plenty of places to point fingers.

In a busy team, with ongoing testing I often find we have a production version of the site, a version under test, and another version being actively developed.

In fact it can be less clear than this if release planning isn’t a priority, some teams simply churn out releases some of which get tested and eventually released.

This can lead to developers being unsure which update hooks have actually run on production (or will have run by the time the next release goes live).

In this case it’s important for somebody to manually review all install files that have been edited and check that we don’t end up releasing update hooks that have been edited after they have been run.

This script fires up a visual diff tool for the changed files.

I’ve been working on a project for a while on my main dev machine, but needed to run it on my laptop too.

Usually copying a site across is quick but this time I re-installed the OS too, everything went OK except for some reason I couldn’t log in to my drupal site.

Eventually I noticed that while the site appeared to be working, every page was being served with a 404 header.

I’m used to how svn export works, and have used this in a number of release scripts.

Git doesn’t quite have an equivalent

The code in chapter 7 of pro Drupal development has a bug.

The $instance array that you need to pass to field_create_instance() needs to be as below.