Upgrading from MT 3.33 to MT 6.1.2

| No Comments

Upgrade Type

  • Parallel installation of MT6 to new subdomain mt6.tweezersedge.com.
  • Upgrade on copy of MT3 MySQL database

If something went wrong during the upgrade, I could revert back to the original version, or recopy the database and try again. Plus, I will have the original installation as a reference point if I wanted to see how something was in the old installation, which I had not looked at in the past 10 years.

  • Install MT files to single directory

My web host allows execution of .cgi scripts from any directory, so I did not need to install the MT files to a cgi-bin directory, nor did I need to install the mt-static files separate from the main MT files.

  • Copy MySQL database

To copy the original database, I used phpMyAdmin in cPanel to create a new database, then exported and downloaded the MT 3.33 database to a file, then used phpMyAdmin again to upload the export file and import it into a new database.

To make things easier for me, I granted the MT 3.33 database user permissions on the MT 6 database (again, using phpMyAdmin), so the database user and password would be the same between the databases.

  • Set the permissions on all .cgi scripts to 0755.

Review and copy plugins

Reviewed the plugins installed on the MT3 installation and copied over those plugins which were not already included with MT6, were not made obsolete by MT6, or provided functionality that I no longer wanted to use. I will describe which plugins I kept or did not keep and why in a separate blog post.

mt-config.cgi config file

  • Copied mt-config.cgi config file from MT3 installation to MT6 installation.

  • Updated CGIPath, StaticWebPath, StaticFilePath directives for new installation location.

  • Updated Database, DBUser, DBPassword, DBHost directives for new database copy.

  • Removed many directives included in MT3 config file by default which were set to default values, plus their inline documentation, to make mt-config file much smaller.

  • Added new 'ImageDriver ImageMagick' directive to file.

  • To help defend against spammers: Added CommentScript, TrackbackScript, SearchScript, CommunityScript directives and specified script names that were the original name plus '-' plus a random 8 character sting. Renamed corresponding scripts on server.

  • Added 'LaunchBackgroundTasks 1' directive: Background tasks are a good thing, but this directive has a default value of '0'

  • Added '# DebugMode 0' directive (commented out): In case Movable Type installation becomes completely inoperable and Debug Mode cannot be set from the System Overview > General page. Directive is initially commented out so setting Debug Mode from within Movable Type is not overridden and blocked.

  • Added 'RPTProcessCap 1' directive: Limit maximum number of RPT (run-periodic-tasks) workers to 1. This seemed important to do on a shared server. This directive is ignored unless Proc::ProcessTable perl module is installed (described below).

mt-check.cgi script

Browsed to mt-check.cgi script to see which perl modules were missing. I am on shared hosting, so I had to use cPanel to install as many of missing modules as I could.

Modules that I did not install were those having to do with Plack/PSGI (unable to run Movable Type under PSGI), Cache::Memcached (unable to run memcached server), and Cache::File (no interest in accepting commenter sign-ins from Yahoo! Japan).

Proc::ProcessTable

The Proc::ProcessTable perl module is not checked for by the mt-check.cgi script but it is required for the RPTProcessCap configuration directive to limit the number of tools/run-periodic-tasks processes that can run at one time. I installed this perl module via cPanel.

Sys::MemInfo

The Sys::MemInfo perl module is not checked for by the mt-check.cgi script, but it is required for the following configuration directives to function correctly:

I doubt I will use any of the above config directives, but in case I do, I went ahead and installed this perl module via cPanel.

Modify perl scripts to find cPanel perl modules

In order for a script to find the perl modules I was installing via cPanel, I needed to add one of the following to the top of the script:

#!/usr/bin/perl
use cPanelUserConfig;

or

#!/usr/bin/perlml

I chose the first option. I edited each of the .cgi scripts in the MT6 installation directory and added use cPanelUserConfig; on the second line of each script. I also made the same modification to the tool/run-periodic-tasks script.

Run the upgrade

I browsed to the URL of the mt.cgi script, which redirected to the mt-upgrade.cgi script to perform the actual upgrade. After logging in as a System Administrator, the upgrade proceeded normally and successfully completed with no errors.

I will describe what I found within Movable Type 6 in a future post.

Leave a comment