Upgrading Drupal 6 to Drupal 7

Submitted by webroot on Thu, 04/28/2011 - 14:34

Upgrading from Drupal 6.20 to Drupal 7.0

Work in progress!! Don't upgrade the production server yet!

First: Visit Drupal's Guide for some precautions, notes and general guide.

Second: Create a "Test" Drupal site that is a mirror of your backup site. We'll test an upgrade on this site.

Here is a copy of the upgrade process that I will follow step by step. I'll add comments and notes specific to my setup as I go along.

** My comments are in this font..

I'll also add notes specific to the environment that I'm on.

Note: DO NOT run install.php at any time during an upgrade!.

It will empty your content from the database.

Upgrade Steps

Backup your existing site and database.
** Doesn't apply, working off a new "Test" site created locally. I imported and mirrored the Host site.
Log in as user ID 1 (the site maintenance user). ** Done
This is the user name that you created during the installation process for your site.
Put your site in maintenance mode ** Done
Go to the site maintenance page (Administer > Site configuration > Site maintenance or http://www.example.com/admin/settings/site-maintenance). Select "Off-line" and save the configuration. If you have defined a custom maintenance theme in your settings.php file, comment it out before proceeding.
Change all themes to Garland (default) ** Done
Go to the Themes page (Administer > Site building > Themes or http://www.example.com/admin/build/themes). Enable "Garland" and select it as the default theme. If you have been using a separate theme for administration, select "Garland" for your administration theme as well. You can find the administration theme setting at (Administer > Site configuration > Administration Theme or http://www.example.com/admin/settings/admin)
Disable non-core modules ** Done
Go to the Modules page (Administer > Site building > Modules or http://www.example.com/admin/build/modules). Disable all modules that are not listed under "Core - required" or "Core - optional". It is possible that some modules cannot be disabled, because others depend on them. Repeat this step until all non-core modules are disabled.
If you know that you will not re-enable some modules for Drupal 7.x and you no longer need their data, then you can uninstall them under the Uninstall tab after disabling them.
Remove default settings file ** Done
On the command line or in your FTP client, remove the file sites/default/default.settings.php

I did: prompt% mv default.settings.php 6x-default.settings.php
Remove all old core files and directories
Remove all old core files and directories, except for the 'sites' directory and any custom files you added elsewhere. If you made modifications to files like .htaccess or robots.txt, you will need to re-apply them from your backup, after the new files are in place.

On Mac S.L 10.6.7 I made a "Old-6x" folder and moved everything into that folder. I also moved .htaccess from command.
Remove uninstalled modules ** Done
If you uninstalled any modules, remove them from the sites/all/modules and other sites/*/modules directories. Leave other modules in place, even though they are incompatible with Drupal 7.x.
Download Drupal 7
Download the latest Drupal 7.x release to a directory outside of your web root. Extract the archive and copy the files into your Drupal directory. ** No mention of the "sites" folder. So I'll copy everything except "sites". I used the folders to copy everything over. Then I used the command line to copy over .htaccess and fix it.

On a typical Unix/Linux command line, use the following commands to download
and extract:

wget http://drupal.org/files/projects/drupal-x.y.tar.gz

tar -zxvf drupal-x.y.tar.gz

This creates a new directory drupal-x.y/ containing all Drupal files and directories. Copy the files into your Drupal installation directory:

cp -R drupal-x.y/* drupal-x.y/.htaccess /path/to/your/installation

If you do not have command line access to your server, download the archive using your web browser, extract it, and then use an FTP client to upload the files to your web root.
Re-apply modifications to core files ** Done, see #9 above.
Re-apply any modifications to files such as .htaccess or robots.txt.
Make your settings.php file writeable ** Done, they mean writeable by www for Drupal
Make your settings.php file writeable, so that the update process can convert it to the format of Drupal 7.x. settings.php is usually located in sites/default/settings.php

As super user, I did: prompt# chmod u+w settings.php
Run the update script ** Done
Run update.php by visiting http://www.example.com/update.php (replace www.example.com with your domain name). This will update the core database tables.
If you are unable to access update.php do the following:
- Open settings.php with a text editor.
- Find the line that says:
  $update_free_access = FALSE;
- Change it into:
  $update_free_access = TRUE;
- Once the upgrade is done, $update_free_access must be reverted to FALSE.
Backup your database ** This is a "test" install site so I won't do this. When I do it live, I'll use phpMyAdmin to backup the database. If all is good however, I may just use the Backup and Migrate Module. We'll see.
Backup your database after the core upgrade has run.
Upgrade fields ** Doesn't apply, not using CCK. yet..
If you were using CCK (and perhaps additional modules) to create fields for your content types, you will need to upgrade the data in those fields as a separate step. Download the Drupal 7 CCK module, and turn on Content Migration. Go to Structure > Migrate Fields or http://example/com/admin/structure/content_migrate for a page to walk you through the migration process. There are now several types of fields in core, but not every type. You might need to download Drupal 7 versions of contributed modules to support other types of fields. (For example, the new References module handles node and user reference fields.)
Update contrib modules and themes * First, re-run the update.php
Replace and update your non-core modules and themes, following the procedures at http://drupal.org/node/948216
Check the Status Report ** Done
Go to the Status Report page (Administration > Reports > Status or http://www.example.com/admin/reports/status). Verify that everything is working as expected.
Make sure setting.php is secure ** Done
Ensure that $update_free_access is FALSE in settings.php.
Remove your site from Maintenance Mode ** Done
Go to the Maintenance Mode page (Administration > Configuration > Development > Maintenance or http://www.example.com/admin/config/development/maintenance). Disable the "Put site into maintenance mode" checkbox and save the configuration.

Upgrade did work according to the instructions. I did have some hiccups with some of the modules as I re-integrated them. So before I do the actual production site I'll upgrade another test site on my local machine.

Then I'll try a "test" upgrade on our local server site. Notes to follow.

2. Module and Theme Inventory

Identify the modules that are installed (including ones that are installed and not enabled). To do this, you can either look at the listed modules on the Modules admin page (Administer > Site building > Modules), or in your sites/all/modules directory.

Identify which theme is active on the site by looking at the Themes page (Administer > Site building > Themes), which shows all installed themes, and which ones are enabled.

Write down the complete list of modules and themes installed on your site. You can use this as a checklist when upgrading contributed modules as well as when you disable and re-enable modules during the actual Drupal upgrade.

Disable and Uninstall Unused Modules

After taking inventory of your modules, you may become aware of modules that your site is not actually using. It is always recommended to disable and remove modules that are not actually in use for both security and performance reasons. During an upgrade you also save yourself from having to update or upgrade unused modules.

Contributed Module Upgrade Planning

Answer the following questions for each of the modules in your inventory:

Is there a version of the module for Drupal 7? You can find out by visiting the project page on Drupal.org for each of your modules.
Has the module moved to Drupal core? Drupal 7 core has incorporated several key contributed modules into its release. For a full list see Drupal 6 contributed modules that are in Drupal 7 core.
Is there an upgrade path for the version of a module you have and the version that is available for Drupal 7? In some cases module authors release multiple versions of a module (e.g. module_name 6.x-1.x and module_name 6.x-2.x) and only one of those versions will be available for Drupal 7.
Does the Drupal 7 version of a module introduce any new dependencies? In some cases new version of modules will have dependencies on other contributed modules that they did not have in previous versions. When you upgrade your site you will need to make sure to install the modules your module depends on.

Theme Upgrade Planning

If your site uses a contributed theme, you will need to research whether your theme can be upgraded to Drupal 7.

Is there a version of your theme available for Drupal 7?
Is your theme based on a theme framework like Zen or 960? What is the upgrade path for those frameworks?

If your theme is entirely custom or is a modified version of a contributed theme or even based on a theme framework, you will need to plan on spending time upgrading the code for your theme at some point prior to upgrading your site. See Converting 6.x themes to 7.x

Identify Core Customizations and Contributed Module Customizations

As a rule you should never 'Hack Core' i.e. modify core modules or files.
If, however, you have modified your core Drupal files and modules, it is entirely your own responsibility to make note of those changes and plan your upgrade accordingly.
The same is true of modified contributed modules.

Document your Upgrade Plan

Using your module and theme inventory and the research you did planning for your module and theme upgrades begin documenting your overall upgrade plan. This plan should include steps found in UPGRADE.txt. Make a list of steps and checklists that you can refer to as you proceed through the upgrade process. There are too many things that are easily forgotten when performing an upgrade and having everything written down ahead of time will save you time and aggravation. Also, having a document like this ahead of time provides you with a place to take additional notes during the upgrade. These notes may prove valuable the next time you have to do an upgrade.

Consider documenting the following as part of your upgrade plan.

Modules that cannot be upgraded and what alternative choices exist.
Modules requiring an upgrade before upgrading the core codebase.
Special upgrade instructions (if any) for each module.
The order in which modules should be upgraded.
A plan for testing whether the upgrade was successful.

Add new comment