Upgrading and Merging two Movable Type installations
Suppose you have two different versions of Movable Type running somewhere within your infrastructure. They each running different versions of Movable Type and your desire is to upgrade them and, here is the kicker: merge them. Oh boy.
This document will help you do just that. Here are the issues we will be tackling:
- How to pragmatically perform the upgrade itself.
- Resolving user namespace collisions between the two blogs.
- Physically merging the two installations.
- Resolving plugin conflicts between the two installations.
- Testing to make sure everything works.
Before you begin we strongly recommend you read this document first, in its entirety. Then, once you are finished, start over and follow the instructions documented.
What you are about to embark on is not simple in the slightest. While it is possible you might get lucky and encounter almost no issues along the way, no one should enter into this process assuming that it will be easy or without complication. Therefore, it is advisable to follow this very important recommendation:
- Make sure you test the procedures outlined below on a staging or test environment first.
I will assume you know the mechanics of how to do that, but in case you don't here is the 50,000 foot view of that process. For each Movable Type installation:
- Create a clone of the MT database. I use mysqldump for that and
import the dump file into a newly created database.
- Create a copy of all of the installation's published
- Create a copy of all of the installation's Movable Type files
- Set up the new copy of MT to connect to the database clone you
- For each blog, change its publishing settings so as to make
sure you don't overwrite the files on your live site.
- Republishing the site and make sure there were no errors. In theory, if you did everything properly, there should be no errors.
From this point forward you should be doing all of your work in the copy of your site you just made. Now for the next very important recommendation:
- as you follow the procedures outlined in this guide, take notes as to what worked, what didn't, and most importantly what you did to resolve them.
What we are endeavoring to create by following the procedures outlined in this document is a step-by-step set of instructions you can reliably execute against your production system. Why is this important? Well, mainly the path to a successful upgrade alone relies on users first attempting an upgrade in an environment separate and distinct from their production/live site. As you conduct your test and take notes about what you did along the way, you are essentially building a script for yourself that you will follow when you finally upgrade your production/live site.
Upgrade Your Installations
Your first step will be to upgrade each individual install to use the same version of Movable Type - preferably the most up-to-date version available. Don't worry about synchronizing the installations in any way. Just focus on getting the software upgraded, and resolving any publishing problems that result.
Before we begin, you should have a SQL dump of each installation (assuming you followed my advice above). If you don't have this, please create one now. This is important because you may want to re-execute the upgrade again during some phase of this process to further test modifications you have made to your procedures. Having something to roll back to then can be very useful.
Now, do the upgrade. Consult the official Movable Type upgrade guide on the detailed mechanics of this process. Or if you consider yourself an expert at this, use this cheat-sheet:
- If the system you are upgrading uses Berkeley DB (only relevant
for MT3.x), upgrade it first to MySQL.
- Download the latest version of Movable Type.
- Unzip the Movable Type archive.
- Copy the contents of the archive over your old version of MT.
If need be, also copy MT's static files to their desired web
- Attempt to login to MT. You should be prompted for the upgrade.
Conduct the upgrade. For large installs you may want to use the
command-line upgrade script (found in
$MT_HOME/tools/upgrade) which you may find to be more reliable.
When Movable Type has completed the upgrade you should be taken to the MT4 dashboard. Now go through the pains taking process of republishing each blog. For each blog:
- Take note of any publishing errors that occur. Right down the error you received and the blog it was associated with.
- Resolve the error, and write down exactly what you did to resolve it.
Tip: Before I begin, I often like to take peak inside each
plugins directory. This helps me to
mentally prepare myself for what issues I might be facing. If I am
lucky the installation does not venture too far off from the
default installation. In most circumstances, most of the plugins
you will find are probably obsolete in some way, but they should
still technically function. You should do your client the favor and
inform them which plugins are obsolete and work with them to
upgrade their templates down the road.
Post Upgrade Steps
At this point you should have upgraded each of your installs. Now let's test to make sure upgrade went without a hitch. The following steps will go a long way to ensure your system is operating within expected parameters.
Plugin Sanity Check
Navigate to your System plugin listing. Make sure each of your plugins has loaded properly. If one of them failed it should be obvious - an error icon should appear below the plugin's name. If any plugins failed to load, please take the steps necessary to resolve the issue.
Check the Activity Log
A lot of small transient errors or warnings may be occurring silently - without your knowing it. It is best to resolve all of these issues before proceeding since any system operating in a nominal state should not produce a single error or warning. Look for errors and resolve any that you find.
Publish Your Site
In 99% of cases, if a blog can publish its templates without producing an error, then the blog is fully functional. That being said, it is important to compare the output of template being republished with the live site to ensure that your test data does not differ from production -- remember, in theory they should be virtually identical given that you are working off a near clone of your live site.
- Checking for missing tags - One tool that is especially useful in diagnosing an upgrade is the Unrecognized Tags plugin by Six Apart Services. Once installed you can navigate to the System Dashboard. Then from the Tools menu, select: "Unrecognized Tags." This will kick of a process by which all of the templates in your installation will be analyzed, and a report generated containing all the tags your templates utilize that are "undefined" or unrecognized by the system. When an unrecognized tag is found this is usually an indicator that a plugin providing the tag is not installed, or that it failed to load, or that it is incompatible with your version of Movable Type.
Performing the Merge
By now you should still have two Movable Type installations that have been completely upgraded and tested. You should never attempt to merge two installations that are not both operating nominally or as you would expect.
Our preference when merging installations is to merge them one blog at a time. This makes it easier to trouble shoot issues if any arise during the merge process.
Begin by selecting the installation between the two installs you have that you will merge the blogs from the other installs into. The selection you make will become your main and only install of Movable Type. We usually pick the blog with the fewest number of blogs and/or authors.
Then for each blog you are going to move into the main install:
- Navigate to that blog's dashboard and select "Backup" from the
- Export all of the blog's contents and download the XML file
that is generated by Movable Type.
- Login to your main install and navigate to the System
- From the "Tools" menu select "Restore."
- Upload the XML file you downloaded in step 2 above.
- Select the new paths and URLs for the blog created by this process.
Then repeat the above for each blog you are going to merge into the main install.
Trouble parsing the backup XML file generated by Movable Type
We have encountered clients that have followed the above process only to find that Movable Type could not successfully restore from the backup file generated by Movable Type. We have found in almost all circumstances that this problem stems from encoding problems found in the content of the blog being moved. To fix the issue you need to manually encode the string properly in the backup generated, or consult with someone familiar with encoding issues to help you automate the process.
When we have worked with exceptionally large datasets for which encoding problems seemed intractable, we resorted to using the older, but sufficient Import/Export functions found in Movable Type to facilitate the migration. This process will move authors, templates, entries and comments for you, but not much more than that. So the end result is not a full fidelity copy of the original, but it is sufficient for most.
Once this process has been completed successfully in your test environment, re-execute this process in your live site.
If the content you seek to merge is considered to be business or mission critical, we strongly recommend you consult with a qualified Movable Type professional. They will be able to more quickly resolve issues that arise and advise you accordingly.