bioneural.net

It's amazing how much detritus accumulates in your server directories and MySQL tables over the years. Add to the mix a propensity to hack core files to the point where you dare not upgrade your packages, and you have yourself a fine mess. I hope it wasn't too obvious, but bioneural.net had developed Diogenes syndrome. It was time for a clear-out and makeover. If you're thinking that sounds like work, it is. What follows is not riveting reading, but if you're contemplating doing the same, perusing what this involved for me might help you judge how many days to set aside—and maybe bug-fix your own migration.

Why upgrade?

There were multiple reasons why I felt a major overhaul was called for:

• My host (mt) told me I needed to upgrade from my (ss) product to the (gs) product that had superseded it, and that if I took no action I would "loose the benefit of choosing [my] own migration timeline";
• The (ss) product was stuck at MySQL 3.23.58 and PHP 4.4.1, whereas the (gs) upgrade offered MySQL 4.1.11 and PHP 4.4.7 or 5.2.2;
• Such upgrades would bring security fixes, as would upgrading Gallery from 2.1.2 to 2.2.4;
• WordPress 2.3.1 (current as of this writing) requires MySQL 4.0 or greater, so I was stuck on WordPress 2.0.11;
• I wanted to configure ecto 3 to work with WordPress's new integral tagging system (ecto 2 did work with UTW and some hacks to xmlrpc.php);
• I made a number of hacks to core WordPress files (xmlrpc.php, wp_rss2.php, etc.) which makes updating a pain—something I'll try to avoid in future;
• My WordPress theme was a heavily-hacked edition of K2 Beta Two r163 and I've been unable to benefit from the many releases since;
• More to the point, my customised theme was plain incompatible with WordPress 2.3.1;
• I'd also hacked a number of WordPress plugins and thus using old versions, so time to start over and once again resist hacking in the interests of smoother updating.

Preparation

In case of disaster I wanted to ensure I had full backups. I therefore:

1. Made screen captures of all my current WordPress options and settings;
2. Downloaded the entire contents of my server to a backup directory on my local drive (which took a very long time, largely I think due to Gallery);
3. Used a backup plugin to download core WordPress tables, core tables plus UTW tag tables, and all tables;
4. Created a backup of my Mint settings and data;
5. Used phpMyAdmin to backup my Gallery albums etc. (not the images, but I downloaded those as above);

From (ss) to (gs)

The (mt) migration tool completed in around 12 hours or so, and seemed to go (ok).

After adjusting my FTP login I uploaded an info.php file which confirmed I was now using MySQL 4.1.11 and PHP 4.4.7 5.2.2 (after switching the default version in the control panel):

<?php phpinfo(); ?>

Although bioneural.net was there, tekoru.net wasn't. Prior to the upgrade tekoru.net was a sub-domain that pointed to ../category/project-koru/. To fix this I first had to re-create the alternate domain in the (mt) Account Center. Unfortunately visiting tekoru.net then showed

Forbidden

You don't have permission to access / on this server.

The reason? The new domain directory /domains/tekoru.net/html/ was empty. This could be fixed by adding an index.html file (with appropriate content) or, alternatively, using .htaccess to redirect visitors elsewhere. Thus I simply had to move the pre-existing redirect rule from my .htaccess file in /domains/bioneural.net/html/ to a new file in /domains/tekoru.net/html/ to restore normality:

## Redirect tekoru.net to www.bioneural.net/category/project-koru/
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?tekoru\.net$ [NC]
RewriteRule ^(.*)$ http://www.bioneural.net/category/project-koru/$1 [R=301,L]

Upgrading WordPress

I had reason to be concerned this wouldn't go well, since I had tried and failed to import an export of my WP database into the new WordPress running in a MAMP environment (ending up with a blank page when trying to update the database). The live upgrade from 2.0.11 to 2.3.1, however, went almost flawlessly:

1. Deactivate all installed plugins;
2. Overwrite all WP files except for wp-content (which requires more care);
3. Run /wp-admin/upgrade.php;
4. Apply a fix to wp_settings.php to resolve a database error related to WP-Cache;
5. Install and activate Full Text Feeds to compensate for a daft decision on the part of the WP development team;
6. Download up-to-date versions of some of my WordPress plugins, activating them one-by-one to test for compatibility;
7. Removed comments.php from the default theme (I've found that doing so, in conjunction with other methods, significantly reduces spam);
8. Import UTW tags (Manage > Import > Ultimate Tag Warrior) into the new native tagging structure (they now populate the new wp_terms, wp_term_relationships, and wp_term_taxonomy tables).

Cleaning out old WP tables

Using phpMyAdmin I dropped various disused or redundant WP tables. Most had been created by deleted plugins e.g. wp_tags as used by UTW, making my table list over twice as long as the default (shown):

Mint

The transition from (ss) to (gs) had no adverse effect on Mint; as with WordPress to migration tool automatically changed the database name. However, I wanted to move the Mint tables into their own database.

1. Drop backup and old Mint tables from the WordPress database in phpMyAdmin;
2. Export current Mint tables (prefixed with mint_) to file;
3. Create new database for Mint;
4. Import the file containing Mint tables;
5. Update /mint/config/dp.php with the name of the new database;
6. Tell mint about the change with /mint/?moved;
7. Delete the Mint tables from the WordPress database.

Gallery

The transition from (ss) to (gs) broke my Gallery 2.1.2 installation. Before I could upgrade to the current 2.2.4 version I had to get the old one working again, in order to run the Gallery Upgrader.

I edited gallery2/config.php to change the name of the database and also the location of the data directory. Gallery came online again, but the Upgrader often returned me to step one, and I could not get past the system checks at step two. I was seeing the following error:

Error: Some files and or directories in your storage directory are not writeable by the webserver user. Run chown -R webserverUser /domains/bioneural.net/html/gallery2/g2data/ OR run chmod -R 777 /domains/bioneural.net/html/gallery2/g2data/.

I tried chmod 777 to g2data via SSH in Terminal:

chmod -R 777 /home/32398/domains/bioneural.net/html/gallery2/g2data

But still no joy. Attempting cache maintenance (/gallery2/lib/support/index.php?cache) gave a shed-load of errors similar to this (contracted):

Warning: mkdir(/domains) [function.mkdir]: Read-only file system in .../gallery2/modules/core/classes/GalleryPlatform.class on line 624

Warning: rename(.../gallery2/g2data/cache/module/archiveupload/0/0/0.inc) [function.rename]: No such file or directory in .../gallery2/modules/core/classes/GalleryPlatform.class on line 487

Scanning the Gallery Forums wasn't much help, although as suggested here, I tried a test.php with the line:

<?php if (is_writable('/domains/bioneural.net/html/gallery2/g2data')) { print "yay"; } else { print "boo"; } ?>

I got "boo". It was (mt) Tech Support who came to the rescue. For (ss) Gallery's config.php read:

$gallery->setConfig('data.gallery.base', '/var/www/html/gallery2/g2data/');

For (gs) I had changed this to:

$gallery->setConfig('data.gallery.base', '/domains/bioneural.net/html/gallery2/g2data/');

But, as (mt) pointed out, it should be:

$gallery->setConfig('data.gallery.base', '/home/32398/domains/bioneural.net/html/gallery2/g2data/');

Gallery was back up! Thus I was able to get a "yay" out of test.php:

<?php if (is_writable('/home/32398/domains/bioneural.net/html/gallery2/g2data')) { print "yay"; } else { print "boo"; } ?>

With the old version working, I then upgraded by uploading the new files. Once again transferring the multitudinous Gallery files by FTP is a lengthy process. Once again the Upgrader kept returning me to the beginning step of the upgrade process for no apparent reason. It was very frustrating, but eventually I managed to click through to the last step and complete the process:

ecto

Configuring ecto 3 to work with the new WP integral tagging system is not difficult. Just set it up as below:

Unfortunately it doesn't seem to play perfect; I'm noticing some odd "tags" are being downloaded—not tags at all but image file names, for example. Hmm...

Regaining the bioneural.net look-and-feel

I just love BBEdit's Compare two front documents option (in the Search menu). By opening the corresponding files from both the latest version of K2 and from my theme and running this crosscheck I could see where my edits and other codes changes occurred. The majority of discrepancies were in 4 files:

• header.php
• sidebar.php
• theloop.php
• style.css

I haven't finished rebuilding my customisation of K2 as I write this. Actually I began developing my own theme from scratch but have put this on hold, figuring that my site would be down for less time if I simply re-hacked K2 to incorporate my modifications.

Miscellaneous issues

• Restored various scripts e.g. iBox;
• Restored SimplePie, updated syntax on my Links page (with help from (mt) here too, since I created the cache directory in the wrong place);
• Edited Quoter plugin (as here) to stop pre-quotation of earlier comments in the comment-textarea;
• Disabled wp-forecast as cause of errors in K2's Ajax-powered live search, live commenting, and rolling archives;
• Edited Gallery slideshow template (as instructed here) to alter defaults for description, time interval, and image size (example). NB fix for RSS feeds using Siriux theme is no longer necessary;
• Dropped Subscribe to Comments plugin as my subscriber database was being subjected to attack (also a source of bounced e-mails);
• Dropped the Prototype JavaScript framework (and the dependent effects scripts of script.aculo.us and Reflection.js), migrating to jQuery (as per K2 and WordPress itself);
• To overcome the loss of Ajax-mediated K2 functions with the wp-forecast plugin active, rename wp-forecast/functions.php to wp-forecast/funclib.php and within that file and within wp-forecast-admin.php change require_once(”functions.php”); to require_once(”funclib.php”);.

What did I learn? I may not have any more patients, but I do have more patience than I thought.