I was migrating this WordPress blog early this morning from Bluehost to a dedicated Rackspace Cloud Server that I’m already using for a web application I’m writing. It was almost painless! Just ran into a few minor post-migration issues.

The reason I’m migrating is mainly because I want more control, like being able to use my own self-signed SSL certificate without paying extra, for example. I figured since I’m getting very low traffic it really wouldn’t cost me anything extra to host it on Rackspace.

For example, according to Bluehost, my monthly bandwidth transfer is roughly 2.3GB. I’m not sure if that’s for both inbound and outbound. Either way, Rackspace only charges 18 cents/GB for outbound bandwidth (inbound is free). So even if I’m using 3GB a month, it’s only an extra 54 cents to my monthly cost. Rackspace’s connection is also way faster.

The migration steps are pretty straighforward, basically:

1. Install PHP, MySQL, Apache.
2. Install WordPress.
3. Restore the database.
4. Copy over your themes, uploads, plugins, and other directories that a plugin might be using (in my case I had an extra “gallery” directory for the NextGEN Gallery plugin that I’m using to store my pictures).
5. Restart Apache.

Here are the issues I ran into after migration and their solutions:

Issue #1: Special characters in my posts after the database restore

I figured this was an encoding issue and it turned out that I didn’t specify the SQL compatibility mode when I originally restored my database backup. In my case, I simply restored/imported the database again using phpMyAdmin and set it to ANSI.

Issue #2: 404 (Page Not Found) errors when accessing permalinks

This actually involved two things:

Part 1. Insufficient permission to the WordPress files for the user account running the Apache daemon.

When I checked the Permalinks settings in the WordPress administration, there was a message at the bottom that says:

If your .htaccess file were writable, we could do this automatically, but it isn’t so these are the mod_rewrite rules you should have in your .htaccess file…

All I had to do was change the owner of the WordPress document root to the user account running the Apache daemon, example:

sudo chown -R www-data /var/www/calazan/wordpress

Part 2. Enable the AllowOverride directive in the Apache configuration so the .htaccess file can override the settings.In my case, I changed the setting in my config file (/etc/apache2/sites-available/default) for the virtual host serving WordPress. I simply set the AllowOverride option to All instead of None.

DocumentRoot /var/www/calazan/wordpress
<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>
<Directory /var/www/calazan/wordpress>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
</Directory>

Issue #3: 500 (Internal Server Error) error when publishing or updating posts

This one I actually just discovered a few minutes ago right after I published this post! The post published but returned a 500 response. I tailed my error.log in /var/log/apache2 and showed the Twitter Tools plugin was causing it. The error message was:

PHP Fatal error: Call to undefined function curl_init()

It looks like I was missing a package which turned out to be php5-curl, so I just had to sudo apt-get install php5-curl (thanks to this post).

That’s pretty much it, seems to be working well so far. Now I gotta start monitoring resource usage as I’m now running 3 web applications and 2 database systems (PostgreSQL and MySQL) on this virtual server. I’m mostly worried about memory usage as I only have 256MB here currently :D.