WordPress and Train Wrecks

The Best Laid MySQL Databases and WordPress Installs Go Often Askew

Train Wreck at Gare Montparnasse 1895? Or Jeff Chappell trying to migrate WordPress? Who can tell? The process of uploading/migrating this site from my local WordPress installation under Windows 7 to Dreamhost became an epic sort of nightmare. I’m not inexperienced at this; I’ve moved WordPress from a subdirectory to a site’s root folder, and moved sites from one host to another. It doesn’t always go easy; that first time a few years ago, moving WordPress into the root folder, was not without difficulty. But since then, I have not had very many problems moving WordPress installations around when necessary – particularly now that WordPress has the ability to import and export its data. That is, until the other night, when I decided the latest, greatest version of Jeff Chappell dot com was ready for prime time. It was a cluster … er, duck, yes, clusterduck of epic proportions (I decided there should be no swearing on the site that deems to represent my professional endeavors, not even in the blog – hence, clusterduck). Or a train wreck, if you will. I started out with the preferred method, as illustrated here in the WordPress codex for moving an install to a new server:

  • I uploaded the WordPress files and the theme files from my hard drive to my webhost.
  • I changed the URL settings from within WordPress on my local site, exported the MySQL database from my local installation.
  • I imported/uploaded the database on my Web host, and uploaded a new wp-config.php file to WordPress’ root directory with the new location of said database and the login info.
  • Initially, everything seemed to go fine. I apparently – I stress this word – imported the database without any problems. When I navigated to the site in a browser, I got the initial WordPress install screen. “Victory once again,” I thought.

But alas, victory would not come nearly so easily, in the end. When I actually got into WordPress, I could see all my pages and posts, but there were no tags attached with any post, nor were there any categories for links or pages. Now if this were a new site without any content, or just a few initial pages/posts, it wouldn’t be much of a problem. Easy to fix within WordPress. But, the whole point of this site is to house examples of my news writing and blogging; it’s essentially a post-modern clip file. As such, at the time of launch I had more than 70 posts and 19 pages; the posts use some 70 different tags and several different categories. I rely on both for organization. Needless to say, I did not want to have to go in and re-tag 70-some posts. So I deleted the database entries and tried using WordPress’ export plugin to export its data and uploaded/imported that into the new installation – that kinda worked. Everything seemed to be here, but I couldn’t get the theme files to work, and the pages rendered all sorts of screwed up when viewed in a browser. So I tried it one more time with a fresh installation of WordPress and imported the data using its import plugin (after clearing out the MySQL database one more time) – that seemed to do the trick; everything was where it was supposed to be. Then I uploaded my theme files, and with some minor tweaking everything was hunky dory. Doesn’t really sound like a nightmare in retrospect, but when it’s a half hour before you plan on hitting the sack, and the resultant snafus keep you up for several stressful hours beyond that, well … maybe it’s not an epic nightmare, or even a train wreck, but it’s a royal pain in the butt. But such is life and such are computers; it’s the nature of the beast. Part of the problem initially is that there is a slight version difference between the MySQL I have installed locally and the one that Dreamhost is currently using – at least that’s what I’m theorizing here. In the past, if I was able to import a database at all, I never had any problems after that. Another thing that may or may not have caused a snafu is that when I initially uploaded WordPress, I inadvertently uploaded the local .htaccess file. If I had thought of that ahead of time, I probably wouldn’t have had to resort to a fresh install of WordPresss. So, word to the wise, if you’re moving a WordPress installation, or uploading a local installation where you did your development up to your Web host:

  • If a database import won’t work, try WordPress’ export/import plugin (you can find this in the left-hand menu inside WordPress, under tools).
  • If your local WAMP and WordPress  installation puts an .htaccess file in your WordPress folder, when you go to upload your WordPress files don’t upload that .htacess file. For more on what the .htaccess file is, here is Wikipedia and WordPress. Odds are, you won’t have to mess with this file, but, depending on your Web host, sometimes you may have to use this file to provide WordPress with the rights/permissions it needs. WordPress uses an .htaccess file for permalinks purposes, so moving it along with your WordPress files from a local install to a one on a Web host can muck things up.

Speaking of Permalinks and WordPress and Migrating an Install

I’ve used a couple of different plugins for updating links after moving an installation or uploading it from a local one. Velvet Blues Update URLs is the one I like best; it’s simple, straightforward and effective. As mentioned before, you’ll need to use a plugin of this sort – or go in and do it by hand – to update internal links in posts and pages because these will all link to something like http://localhost/ralph/WordPress screen options: these are turned off by default in WordPress 3.1.whatever/. Obviously you’ll want to get rid of the localhost part of your links and replace ralph if that isn’t part of your actual live domain name; Velvet Blues does this. One thing to note though – Velvet Blues doesn’t update your links used in custom fields. A lot of themes use Timthumb and custom fields to manage thumbnails and featured images – as opposed to WordPress’ own Featured Image function – and you’ll have to go in and fix these manually. But this is usually just a handful of posts, so no worries. There may be other plugins out there that also fix these links; I’ve always used Velvet Blues because it’s simple and I’ve never had a problem with it

Speaking of Custom Fields, Where Did They Go in WordPress 3.1?

One more thing I would note about WordPress, specifically a change in 3.1. This was the first time I had done a clean install of WordPress in some time, as opposed to upgrading. The most recent local install I had installed from scratch was 3.0. Anyway, in 3.1, a lot of the screen options are turned off by default. That means things like excerpts, custom fields, slugs, etc. don’t show up when you go to an add or edit post page, or add/edit page page, for that matter. If you have these options on in an earlier version of WordPress and upgrade via WordPress’ internal automatic upgrade, these options remain ticked off. However when I first looked at my clean install of 3.1 for the first time, I was wondering why I couldn’t see my excerpt and custom fields – both of which this theme uses. It took a little digging for me to figure out the problem – I’m such an old WordPress user I remember when there were no screen “options.” At first I thought it was something to do with the string of other install snafus, but such was fortunately not the case. Just thought I might mention this should any other old users of WordPress perform a clean install of 3.1 and wonder where their Excerpt entry box disappeared to.

Leave a Reply

Your email address will not be published. Required fields are marked *