Upgrading from Drupal 7 alpha to Drupal 7 alpha

Alpha to alpha upgrades are officially unsupported and the HEAD2HEAD module focuses on precisely that, continuous changes in CVS HEAD not upgrades between the alphas.

UPDATE: Head2Head does have an alpha2alpha module, use that. Consider the below a learning exercise... in examining existing modules that may solve your problems carefully!

Newer update! See Upgrading from Drupal 7 alpha 6 to Drupal 7 beta 2.

We need to upgrade from Drupal 7.0, alpha 5, 2010-05-23 to Drupal 7.0 Alpha 6, released July 9.

Diffing between two system.install files (where most of the database setup and changes are kept) reveals a lot of things changed, but some seem to still be covered in update functions that have new numbers so ought to run... correctly or not is rather a different question.
diff -up dgd7/drupal/modules/system/system.install drupal-7.0-alpha6/modules/system/system.install

We'll try an upgrade and then diff the difference between PHPMyAdmin MySQL database schema dumps.

Diffing the alpha 5 and 6 default.settings.php files reveals some important-looking changes there, too.
diff -up dgd7/drupal/sites/default/default.settings.php drupal-7.0-alpha6/sites/default/default.settings.php

So we make a patch... and apply it.

ben@ubuntu:~/code/dgd7/drupal$ diff -up sites/default/default.settings.php ../../drupal-7.0-alpha6/sites/default/default.settings.php > ../alpha5-alpha6-default-settings-php.patch
ben@ubuntu:~/code/dgd7/drupal$ patch -p0 < ../alpha5-alpha6-default-settings-php.patch
patching file sites/default/default.settings.php

Then we tweak it so we can apply it to settings.php too.

We change the first line from --- sites/default/default.settings.php etc. to:

--- sites/default/settings.php 2010-06-30 15:50:59.147495292 -0700

And we delete the lines that just changed the $Id$ string.

Running the modified patch, it all succeeds except for one hunk. Looking at the .rej file, we see fortunately that it was simply the line deleting the $db_prefix variable (it has been moved into the $databases array). We make this change ourselves and delete the reject table.

ben@ubuntu:~/code/dgd7/drupal$ vi ../alpha5-alpha6-default-settings-php.patch
ben@ubuntu:~/code/dgd7/drupal$ patch -p0 < ../alpha5-alpha6-default-settings-php.patch
patching file sites/default/settings.php
Hunk #5 FAILED at 172.
Hunk #6 succeeded at 214 (offset 6 lines).
Hunk #7 succeeded at 269 (offset 6 lines).
1 out of 7 hunks FAILED -- saving rejects to file sites/default/settings.php.rej
ben@ubuntu:~/code/dgd7/drupal$ vi sites/default/settings.php.rej
ben@ubuntu:~/code/dgd7/drupal$ vi sites/default/settings.php
ben@ubuntu:~/code/dgd7/drupal$ rm sites/default/settings.php.rej

Because we've made some patches that are not in yet, we try to do the whole upgrade with the diff shell script method. For this to apply cleanly we have to remove bartik (which we added from the d.o patch that got committed without modifications) and undo our default.settings.php changes! Because settings.php does not exist in the core download (because it is for site-specific customizations), we need to keep the version we modified.

ben@ubuntu:~/code/dgd7/drupal$ rm -rf themes/bartik
ben@ubuntu:~/code/dgd7/drupal$ rm sites/default/default.settings.php
ben@ubuntu:~/code/dgd7/drupal$ git checkout sites/default/default.settings.php

ben@ubuntu:~/code/dgd7/drupal$ ~/scripts/version-upgrade-diff.sh 7.0-alpha5 7.0-alpha6

It applied beautifully, and going to dgd7.localhost/update.php brings us a very encouraging-looking page:

12 pending updates
system module

* 7055 - Converts fields that store serialized variables from text to blob.
* 7056 - Remove pid from indexes and unique keys of {url_alias}.
* 7057 - Increase the size of session-ids.
* 7058 - Remove cron semaphore variable.
* 7059 - Migrate upload.module to file.module.

block module

* 7006 - Recreates cache_block table. Converts fields that hold serialized variables from text to blob. Removes 'headers' column.

dblog module

* 7004 - Converts fields that store serialized variables from text to blob.

filter module

* 7009 - Converts fields that store serialized variables from text to blob.

user module

* 7008 - If 'user_register' variable was unset in Drupal 6, set it to be the same as the Drupal 6 default setting.
* 7009 - Converts fields that store serialized variables from text to blob.
* 7010 - Update the {user}.signature_format column.
* 7011 - Updates email templates to use new tokens. This function upgrades customized email templates from the old !token format to the new core tokens format. Additionally, in Drupal 7 we no longer e-mail plain text passwords to users, and there is no token for a plain text password in the new token system. Therefore, it also modifies any saved templates using the old '!password' token such that the token is removed, and displays a warning to users that they may need to go and modify the wording of their templates.

One error:

Update #7010
* Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'signature_format' in 'where clause': UPDATE {users} SET signature_format=:db_update_placeholder_0 WHERE (signature_format = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => 1 [:db_condition_placeholder_0] => 0 ) in user_update_7010() (line 670 of /home/ben/code/dgd7/drupal/modules/user/user.install).

We'll make a simple module to try to help us with this, and the inevitable other issues that will come up as we move from alpha to alpha to beta.

cd sites/default/modules/
mkdir alpha2alpha
cd alpha2alpha/
v alpha2alpha.info

; $Id$
name = Alpha to Alpha
description = "A very rough attempt to aid Drupal 7 alpha upgrades, starting with alpha5."
core = 7.x
files[] = alpha2alpha.install

We can get the format for the missing signature_format column from the user module's implementation of hook_schema:

user.install:

<?php
/**
 * Implements hook_schema().
 */
function user_schema() {
[...]
  $schema['users'] = array(
[...]
      'signature_format' => array(
        'type' => 'int',
        'size' => 'small',
        'not null' => TRUE,
        'default' => 0,
        'description' => 'The {filter_format}.format of the signature.',
      ),
[...]
  );

  return $schema;
}
?>

In this case, simply changing the default from 0 to 1 should get us the same effect. I think signature_format made it into 6, not sure in any case how it was missing from (my?) alpha5, but as it wasn't there at all we don't need to run user_update_7010() to update the default formats so long as we set it right in the first place.

<?php
// $Id$

/**
 * @file
 * Provides alpha to alpha update hooks.
 */

/**
 * Add a signature format column to users.
 */
function alpha2alpha_update_750001() {
  db_add_field('users', 'signature_format', array('type' => 'int', 'size' => 'small', 'not null' => TRUE, 'default' => 1, 'description' => 'The {filter_format}.format of the signature.'));
}
?>

[note: in our file, the last closing ?> is never used.]

Haha. We cannot enable the alpha2alpha module because of the error caused by the missing column!

Error
The website encountered an unexpected error. Please try again later.
Error message
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.signature_format' in 'field list': SELECT base.uid AS uid, base.name AS name, base.pass AS pass, base.mail AS mail, base.theme AS theme, base.signature AS signature, base.signature_format AS signature_format, base.created AS created, base.access AS access, base.login AS login, base.status AS status, base.timezone AS timezone, base.language AS language, base.picture AS picture, base.init AS init, base.data AS data FROM {users} base WHERE (base.uid IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => 0 ) in DrupalDefaultEntityController->load() (line 122 of /home/ben/code/dgd7/drupal/includes/entity.inc).

OK, that was ridiculous. Could not even visit the modules page with this error, or run drush en alpha2alpha. Way too fragile, Drupal. The damn user signature format is not a critical field! Anyway, had to put the module into the database -- into the system table -- manually, because i don't know any way to get Drupal to scan its files.

Then, had to fight with Drupal to keep enable it (had to add an empty .module file for it to be recognized as a module, otherwise it deleted the row), and still had to reset the values a couple times to keep a status of 1 (for enabled) and schema_version that wasn't -1 (which apparently means schema updates are never run) but zero.

This last may have been related to my next problem, which was that i had an overly large schema version-- 750001 rather than 75001 (for 7 alpha 5, although oops that should be 6, first update).

But even 75001 is too big a number, so let's go with 7601. As in function alpha2alpha_update_7601().

And it finally worked.

user module
Update #7010

* Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'signature_format' in 'where clause': UPDATE {users} SET signature_format=:db_update_placeholder_0 WHERE (signature_format = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => 1 [:db_condition_placeholder_0] => 0 ) in user_update_7010() (line 670 of /home/ben/code/dgd7/drupal/modules/user/user.install).

alpha2alpha module

No idea why it tried the user module queries first. It listed them second on the previous page. Does it have problems with alphabetical order?

But the site is back!!

And we went back to update.php to finally get user module its last updates, not that it deserves it.

The alpha2alpha upgrade module is attached, rename it to alpha2alpha.tar.gz.

Nope. Not there yet. On viewing a node:

Undefined index: default in field_get_display()

and no fields shown at all.

Resaving each content type does fix that scarier error, and more importantly the field shows up, but this makes me wonder (since i can't even find the head2head process accounting for this at all) if i should wait for the betas, and rebuild everything from there.