This post will cover a number of points you may also encounter when migrating a site/blog from a proprietary database to a WordPress installation.

Ponder weak and weary

There are various reasons why a site or blog may need to be migrated to WordPress. Mine was the simple matter of time. Supporting, expanding and maintaining your own CMS -although very fun- can be an extremely time consuming thing to do. Any idea you would like to present on your site, you yourself would have to develop it.

WordPress on the other hand has a large number of users and developers that constantly generate a steady stream of features, ideas and updates. WordPress itself is written with in expandability in mind and has extensive libraries with Plugins, Widgets and Style templates. Mind you, it still needs work when it comes to defining and deciding on its presentation standards. For example, some templates include the Prototype and Scriptaculous Javascript frameworks, but so do some widgets and plugins. In some cases attempting to load these libraries multiple times will cause them to fail altogether.

Another problem I encountered with WordPress is that some plugins use javascript and capture the Windows.Onload without extending it. This was solved on this site by writing a plugin that allowed for that event to be extended. Existing plugins needed to be edited to facilitate this “standard” way of adding functions to the Windows.Onload event.

Beyond the threshold

Once you’ve decided to migrate to WordPress, you should consider the content you would like to see on your new site. These may include posts, pages, links, RSS generated pages, photo galleries and content-styles (more about that later).

WordPress allows you to import posts using RSS and your links using OPML. There are a number of gallery plugins available and your RSS generated links can be encapsulated in sidebar Widgets.

Sandboxing

If you want your migration to be risk free, consider setting up a “beta” environment that you can play with until you feel comfortable enough to switch your site over to WordPress completely. I did this by setting up a sandbox subdomain (wp.0xtc.com) where my wordpress installation resided. Once I was content that the content was fully migrated I switched the directory names of the root and the subdomain on the web server. Mind you, I did have to edit some of the configuration files and update some tables until that step was fully completed, but this was far minor to having to restore a database and file structure in case things didn’t work out.

This is how 0xtc.com was migrated:

• Created a subdomain for testing and sandboxing.
• Installed a fully functional WordPress installation in the subdomain.
• Downloaded and Installed plugins and widgets that mimicked features that were on my proprietary site.
• Downloaded and tested about 80 templates until I found one I was happy with.
• Created a custom RSS.php that generates all posts in full content and categorized in an RSS XML file.
• Moved all images on my site from a subdirectory on 0xtc.com to their own subdomain. Resource separation in this way allows for a much needed flexibility. This also meant that in preparation for the migration, I had update the posts table to reflect this separation.

UPDATE posts_table SET post_content = replace(post_content,'"/mp/images/','"http://images.0xtc.com/images/')

• Created a script that connected to both databases and imported comments. This is an excerpt of the business part of the script.

foreach ($postsInfo as $p) {
 $sql = "SELECT *, UNIX_TIMESTAMP(Sent) AS date FROM ".PREFIX."Comments where itemnum=\"".$p[Id]."\" and status=2 order by date desc";
 $commentsInfo = $mpage->DoQuery($sql, 1);
 $sql = "SELECT ID FROM wp_posts WHERE post_title like \"".mysql_real_escape_string($p[Title])."\"";
 $npostId = getstuffdone($sql,1);
 if ($npostId){
  foreach ($commentsInfo as $c) {
   if ($npostId){
    $sql = "INSERT INTO wp_comments(comment_post_ID, comment_author, comment_author_email, comment_author_url, comment_author_IP, comment_date, comment_date_gmt, comment_content, comment_approved, comment_agent,user_id)
    VALUES
    (\"".$npostId[0][ID]."\",\"".$c[Name]."\",\"".$c[Email]."\",\"".$c[SiteUrl]."\",\"".$c[IP]."\",\"".$c[Sent]."\",\"".$c[Sent]."\",\"".mysql_real_escape_string($c[Title].'<br />'.$c[Content])."\",\"1\",\"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11\",\"0\")";
    getstuffdone($sql);
   }
  }
 }
}

• A bit of SQL needed for updating comment counts in the wp_posts table.

UPDATE wp_posts SET comment_count = (SELECT COUNT(comment_post_id) FROM wp_comments WHERE wp_posts.id = wp_comments.comment_post_id)

• Installed NextGEN Gallery
• Made sure everything works. What didn’t work? Mostly AJAX and javascript related issues. Fixed it by writing a plugin that implements Netlobo’s Windows Onload Manager on WordPress. Edited Prototype.js and a number of other plugins to support this.
• Created a plugin for content-styles. These are CSS selectors that relate to the content. (classes such has leftimg and rightimg for example position images in articles.)
• Created a plugin for content-scripts. These are javascript functions that relate to the content. (One javascript function for example adds target=”_blank” to links with rel=”external”)
• Imported links from the old site to WordPress by exporting the links table as XML and re-writing the XML to OPML

< ?xml version="1.0" encoding="ISO-8859-1"?>
<opml version="2.0">
    <head>
        <datecreated>Wed, 02 Jan 2008 19:23:00 GMT</datecreated>
    </head>
    <body>
        <outline text="Church of Reality"
        description="If it's real - we believe in it! Tricking religious people into thinking since 1998."
        type="link" url="http://www.churchofreality.org/"
        category="Religion">
....
        </outline>
    </body>
</opml>

• Migrated gallery. This not only was the physical moving of files to predefined directories, but also, -once the pictures were imported- the titles and descriptions were added to the NextGen tables as well using a PHP script.

foreach ($postsInfo as $p) {
    $sse = basename  ( $p[URL] );
	if ($p[Content]=='...' || $p[Content]==''){$p[Content] = $p[Title];}
	if ($p[Title]=='...' || $p[Title]==''){$p[Title] = $p[Content];}
	if ($p[Content]==''|| !$p[Content]){$p[Content] = '---';}
	if ($p[Title]=='' || !$p[Title]){$p[Title] = '---';}
	$sql = "UPDATE `ratemyzi_wordpress`.`wp_ngg_pictures` SET `description` = '".addslashes(strip_tags ($p[Content]))."', alttext = '".addslashes(strip_tags  ($p[Title]))."' WHERE `wp_ngg_pictures`.`filename` LIKE '%".$sse."%' ;";
	getstuffdone($sql);
}

• Unfortunately, the OPML category anchor isn’t automatically transformed into a link category as it does when importing posts using RSS. I had to manually assign categories to the links. No big deal, but if it had been a larger number of links, I would’ve had to write my own version of the OPML import script.
• There were a number of site specific pages that were not migratable. These included tools and other technologies written around the MagnablogTC code base. I didn’t want any superfluous 404 errors, so I prepared a subdomain that would function as a fall-back for those pages. The subdomain is simply a running live version of the old 0xtc.com.(magnablog.0xtc.com). Using SQL replace a number of times on both the old and new content tables, the focus separation was complete.
• Switched content of /0xtc (the place the webserver looked for 0xtc.com) with the /magnablog folder. Switched the sandbox environment with 0xtc.com. The site has been live and kicking since.

…and these was site

This post will be updated as I recall more of the strenuous journey that brought me here.Stay tuned.