Home / Upgrading sites from Drupal 6 to Drupal 7 - time to test it out!

Upgrading sites from Drupal 6 to Drupal 7 - time to test it out!

With the second alpha release of Drupal 7 just out the door, a lot of effort has recently gone into making it possible to upgrade sites from Drupal 6 to Drupal 7 (which is obviously a requirement for Drupal 7 to be released).

What's in store? Some new features for module developers, as well as an easier time for site administrators. Here's a quick rundown:

First, thanks to a lot of recent work by many people, the second alpha release of Drupal 7 should make it possible to at least test out upgrading a very basic Drupal 6 site to Drupal 7 (without the entire world crashing down upon you). Some things are known to be broken, and some sites will certainly hit edge-case bugs that no one has found yet, which is why it's really important that people start testing out the upgrade path now... If you find problems, the issue to coordinate at is here; see the instructions on that issue for how to participate.

Second, there is now a new "update dependency system" in Drupal core, which in the long run will make contributed module database updates much less painful than they used to be.

The problem in Drupal 6 was that updates are by default not run in a predictable order - if you have a contributed module that is closely related to other contributed modules (for example, as part of a package like CCK) and those modules' database updates need to be performed in a certain order in order to work correctly, things are quite difficult. Module authors had to resort to some strange, coordinated hacks to make that work, which often required site administrators to run update.php a couple times in a row in order for it to complete.

Starting last year, though, Clemens Tolboom, Damien Tournoud and others began some great work on integrating the update system with Drupal's new "depth-first search" sorting algorithm. More recently, a bunch of us coordinated to finish the patch, and it was committed.

What's the result? If you're a module developer, Drupal now provides you with a simple system to tell it which other module's updates yours depends on, and the rest is handled automatically.

As an example, suppose that big_momma_module is a major important module in the Drupal community, and you maintain small_baby_module, which depends on it. The big_momma_module maintainers just released a new version with some major changes to the database schema, and small_baby_module needs to make some database schema changes of its own to keep up with it. But in order for that to work, you don't want your module's update to run on anyone's site until after the main module's database updates have been performed.

All you need to do to accomplish this in Drupal 7 is to implement the new hook_update_dependencies(). Let's say the database update functions in question are called big_momma_module_update_7001() and small_baby_module_update_7000(), and you've already written yours. In that case, add this code and you are done:

<?php/** * Implements hook_update_dependencies(). */function small_baby_module_update_dependencies() {  // This tells Drupal 7 that it must run the big_momma_module_update_7001()  // update function before it runs small_baby_module_update_7000().  $dependencies['small_baby_module'][7000] = array(    'big_momma_module' => 7001,  );  return $dependencies;?>

There are more complicated things that can be done with this hook as well (for example, maybe big_momma_module could write some logic that enforces this kind of ordering on all the "small_baby_module"-style modules that depend on it, and that way ensure that everything will work correctly without each sub-module author needing to worry about a thing), but the above are the basics. And the site administrator will get a smooth experience of running update.php a single time and not being prompted to run it again.

All in all, if you're a developer working on porting your module to Drupal 7, now is a great time to start using this system to get your database updates from Drupal 6 working. And regardless of whether you are or aren't a developer, now is a great time to test everything out on (backups of) your Drupal 6 sites.


Posted on by wmostrey (not verified).

Since you mention CCK: almost every site I create for clients uses CCK but it looks like a complete (data) upgrade path from CCK to Fields might not happen:

http://drupal.org /node/366364#comment-2600092

As is mentioned by Nathanial Catchpole: "[I]t's absolutely critical that this in place fairly soon, because without it there'll be very few D6 sites able to port to D7 at all"

Posted on by mwoodwar (not verified).

On my clean install of the current 7 alpha, I immediately ran into problems with the handling of apostrophes, and quotes in all forms, pages,articles, blocks etc..

I get some variation of can'///t in the first case, and /"thisquote/" in the second. It doesn't seem to matter which format, with or without wysiwyg, and can't be corrected in edit as it just reappears when posting.

After searching through the queue here, I don't see anyone else with this issue, so I assume it is some php setting or something on my server, but I don't know where to look?

I understand (very clearly thanks all) that this is not a support forum, and that since I'm the only one experiencing this, it's probably me...but I never had this behaviour with 6.x , and don't know where else to turn.