Taking Drupal sites offline via mysql and the command line

Drupal-powered websites can be put into an “offline mode.” This is much better than most alternatives (such as taking the web server offline), especially for search engines, as the message and HTTP status codes given to users and robots alike will tell them to patiently come back later.

I’ve found that putting the site into offline mode makes database backups go much faster on heavily trafficked sites (which is obvious). However, for a particular site I was working with, this needed to be done in an automated manner, and on a dedicated database server that did not have access to the Drupal installation.

Most people take their Drupal sites offline through Drupal’s web-based administration interface. They can also be put offline through the Drupal Shell. Neither were suitable for me: the former cannot be automated easily, and the latter requires access to the Drupal installation. Fortunately, Drupal sites can easily be taken offline by setting things in the database, which can easily be done via bash scripts and the command-line MySQL client.

Given your database user is my_db_user, password my_password, and database my_drupal_db, the backup script would look something similar to:


\#!/bin/bash

\# Take site offline
mysql --user my_db_user --password=my_password my_drupal_db << EOF
UPDATE variable SET value='s:1:"1";' WHERE name = 'site_offline';
DELETE FROM cache WHERE CID = 'variables';
EOF

\# Do stuff here while the site is offline (e.g. backup)

\# Bring site online
mysql --user my_db_user --password=my_password my_drupal_db << EOF
UPDATE variable SET value='s:1:"0";' WHERE name = 'site_offline';
DELETE FROM cache WHERE CID = 'variables';
EOF

Update: The original version of this article had some problems on some setups with the variables table being cached. I added another SQL statement to make sure this cache is flushed so the site actually reflects its configuration.

Update: This method really doesn’t work that well, and the more I think about it, there isn’t a way to get around writing something that interacts with Drupal. I’m working on a script that will be more fool-proof.

Like this article? Please support my writing! Flattr my blog (see my thoughts on Flattr), tip me via PayPal, or send me an item from my Amazon wish list.

Comments

Michael's picture

What I’ve discovered is you also have to empty table cache_page and clear cookies in some cases before your site will come online - this was so in the case of one of my sites also. For good measure I cleaned out all of cache table as well. At least it got the site up.

Samat's picture

I keep hitting cache issues as well… and I’ve slowly realized this method won’t work well. Clearing all the caches (which on large sites, may be several gigabytes) really isn’t an ideal solution. Also, how do you handle situations where part of your cache is in memcached?

I’m writing a script that will simply login into the website and set the site online/offline mode programmatically. I’ll make it available here when it’s complete.

ChrisH's picture

thanks after migration (different url, different subdirectory) in which I duly put the site offline, I could not get in my site anymore, thanks to this database intervention the site is up again!