Last updated November 17, 2009. Created by rfay on October 18, 2008.
Edited by LeeHunter. Log in to edit this page.
The standard upgrade process described in these pages is based on the assumption that you'll only have to do the upgrade once, but the best practice is that no significant major version upgrade should be done on a live production system. Upgrading a system live on the production site is a prescription for failure. You must do a test upgrade in a controlled environment (a copy of your production server). And upgrades can be quite tedious if you have to do the process many times, which can be the case when:
- An upgrade fails and the problems need to be worked out bug by bug
- Significant development work needs to be done to complete an upgrade
Here is a recommended approach that facilitates the basic upgrade process so it's not so tedious when it has to be done again and again. It's quite unlikely that you would need this approach on a minor upgrade.
In this example I'll work on upgrading from Drupal5.x to Drupal6.x. The idea is general, so it would work for any drupal upgrade.
- Create a separate directory (and optionally a subdomain) for the upgrade from version of Drupal. For example, I set up a directory /sites/drupal5base and pointed a subdomain called drupal5base.example.com to it.
- Populate it with the copied contents of the site you're upgrading.
- Create a database for the base site (I called mine drupal5base).
- Change sites/default/settings.php to point to the drupal5base database.
- Create a directory (and optionally a subdomain) for the upgrade to version of Drupal. For example, I set up a directory /sites/drupal6upg and pointed a subdomain called drupal6upg.example.com to it.
- Populate the directory with the contents of the upgrade Drupal release (drupal6 in this case).
- Create a database for the upgrade site (I called mine drupal6upg)
- Change sites/default/settings.php to point to the drupal6upg database.
Now, the process of upgrading is more about copying databases, and has less likelihood of messing up your original site. You can repeat it many times without moving a lot of files around. Here is the basic process (leaving out some of the steps that are listed in all the upgrade tutorials. You need to do those anyway, but you're doing them here on a copied database.)
- Copy your site database to the from database (drupal5base in this case.) You can do this easily with phpmyadmin - just go to the "Operations" tab of your site database. Optionally, you can download the database as a file and then reload it into the drupal5base database.
- Do the things that one needs to do with your drupal5base site. (Turn off contrib modules, change to a standard base theme, etc.)
- Copy the drupal5base database to the drupal6upg database.
- Run the update.php on drupal6upg.example.com and work out success or failure.
- Repeat as needed. (You can normally repeat just the copy from drupal5base to drupal6upg, without having to populate drupal5base ever again.)
- When it all works, you can take the live site into maintenance mode, copy it into the drupal5base database, do the prep (turning off contrib mods, etc.), copy the drupal5base database to drupal6upg, do the update.php again, verify that everything works, and then you can copy the files and the database from drupal6upg back to the live site (after setting it in maintenance mode and deleting the existing files).
- Make sure to update the settings.php on your upgraded live site to point to the correct database.
A couple of tips that will help with avoiding trouble:
- You may want to change the site name and the front page of the drupal5base and drupal6upg sites while you're working on this. It helps to avoid mistakes if it's very obvious to you which site you're working on.
- Putting your development sites (drupal5base and drupal6upg) on a machine that's different from the live site helps to avoid mistakes as well. The biggest mistake is forgetting the settings.php and updating the wrong database.
Comments
Don't forget Add AUTO_INCREMENT value!
When you're copying one database to another in phpMyAdmin, check "Add AUTO_INCREMENT value," or your copy will get hung up on the users table.
The UID field is set to auto-increment (number entries sequentially), and if you don't check the box, the new database will start them off at 1 and then you'll have duplicate entries, which will stop the whole operation. Checking the box includes your existing UIDs with the data to be imported.
I have a knot on my fool haid from beating it against the wall. I hope I can help others escape the same fate! ;-)
To avoid the AUTO_INCREMENT problem
I've also noticed this auto increment problem on the users table.
What I usually do is simply run an "optimize table" query on every table after having imported the MySQL dump. This can be done in phpMyAdmin.
But the thing is that you can forget to do this operation! So the solution is to install the DB maintenance module. It will keep your database optimized with the help of a configured cron task.
By the way, if I can, I never use phpMyAdmin to create my dumps because you may dammage your dump. I always try to use the mysqldump command line tool :
myslqdump --user=your_username --password=your_password your_database > your_dump.sqlPatrick Janser
This is how I have always
This is how I have always done upgrades from D5 to D6, using subdomains. Then, when the D6 sites tests out with the D5 content: I simply delete all D5 files from live site (root) and COPY the D6 sites into root; change base_url in the settings.php file. Then, viola, you also have your D6 testing site. [I am always shocked to learn that a company/organization does not have a testing site.]
Never understand why the other approach, of merging the D6 into the D5 (live) site, is most often described. You always want to do the migration on a production site plus you need a testing site.
Bigger issue is with D5 sites that have not used the best practices of installing all modules, custom themes, and files to the /sites directory. Then, there is the decision of whether to employ the best practices on the D6 site or not. Tricky if there are embedded links to the D5 file structure. Sadly, this has been the case every time with my migrations.
If you migrate a Joomla site (or even WordPress) to Joomla, you definitely want to create a duplicate site to prep that data for export.