Quick tip: Workaround for "table blocked_ips doesn't exist" during Drupal 6 to 7 upgradesSaturday, 7th Dec 2013Problem/Motivation

Recently I've been working on a couple of Drupal 6 to 7 site upgrades. A lot of people recommend taking the Migrate approach (which is in Core for upgrading to Drupal 8 now), which is fair enough, but for D6/7 it is possible to upgrade directly, if that makes more sense to you.

One thing that you'll find if you want to attempt a direct upgrade is that taking a scripted approach is pretty much the only way to stay sane. You'll want to be leveraging drush heavily and doing a lot of dry runs to make sure everything runs perfectly before the final deployment.

While there is a whole host of fatal errors and circular logic that you'll be working through before you can reliably do smooth test runs, some of these errors are far gnarlier than others. There is one error that I found particularly frustrating until I stumbled upon the solution.

Once you've disabled all your Drupal 6 modules, pulled your database into Drupal 7 and then want to do anything using drush (like run all the outstanding upgrade hooks) you might see a fatal error complaining about the blocked_ips table not existing. If you visit http://yoursite.com/update.php in the browser, you likely won't see this error because update_prepare_d7_bootstrap() will be used during bootstrap, which contains a workaround in it for this exact problem. Drush, however, will choke on just about any command you give it until the blocked_ips table is created.

The problem is, the "blocked_ips" table doesn't exist in Drupal 6 and isn't created until system_update_7002() during the upgrade. Creating the table manually ahead of time lets you use drush, but then causes system_update_7002() to fail so you still won't get very far. In order to keep everything neatly scripted, without killing kittens, we want to use drush to run all our update hooks. It looks like we have a bit of a "catch 22" here but it turns out that there is a fairly simple, practical solution.

Solution

The clue for a solution can be found in update_prepare_d7_bootstrap(). Amongst various other workarounds and fixes we have:

  // The new {blocked_ips} table is used in Drupal 7 to store a list of
  // banned IP addresses. If this table doesn't exist then we are still
  // running on a Drupal 6 database, so we suppress the unavoidable errors
  // that occur by creating a static list.
  $GLOBALS['conf']['blocked_ips'] = array();

Luckily this is really easy to replicate ourselves. All we need to do is add the same configuration to our settings.php file temporarily, during the migration.

I like to maintain a separate settings.migrate.inc file, so this line would look something like this in context:

/**
 * @file
 * Configuration for our D6-7 migration.
 */
  global $conf;

  // Allow free access to update.php during the migration.
  $update_free_access = TRUE;

  // Avoid "table blocked_ips doesn't exist" errors in drush.
  $conf['blocked_ips'] = array();

All of this is alluded to in the issue summary at https://drupal.org/node/517742 but for some reason it took me a long time to figure this one out. I thought I'd leave some explicit notes and hopefully save someone else from some drama.

On a related note, I'd also like to point out that there are other errors that will stop drush from bootstrapping a Drupal 6 database on a Drupal 7 codebase, at least until you visit update.php directly at least once. update_prepare_d7_bootstrap() has some extra logic to repair a few tables in the database that will be missing in Drupal 6 but are required for a Drupal 7 bootstrap. The easiest way I found to fix this up was simply adding wget http://yoursite.com/update.php very early in the upgrade script (before any drush @foo updb calls). This cleaned up a lot of other cryptic errors straight away but unfortunately didn't help me with the missing blocked_ips table.

Syndicate: planet drupal