Migrating a WordPress Site – Day 1

Starting a new project today: Migrating an existing WordPress site. I will be …

  • bringing over the existing data
  • creating some new data types
  • turning a new design into a theme
  • creating a intuitive-as-possible admin experience

First steps: Bring over the existing site.

This started out very straight forward:

  • I brought over the old files en masse
  • I set up a virtual host in apache
  • Edited my hosts file for my new dev domain (client.dev)
  • Looked at the wp-config.php file for the database name
  • Created a new, empty db with the same name (It’s not necessary to keep the db name the same, but it’s not big deal to me and it might make things install more smoothly. Does it?)
  • Changed wp-config.php to include my local db name and password.

The site popped right up, but I ran into two significant issues:

  1. I couldn’t access the admin side of things because I didn’t know the admin’s password.
  2. Everything I clicked on in the site was taking me to the live site: clientname.com

I came to find out these two issues were related. For one thing, submitting the login form was sending the info the the live client site. So I couldn’t tell if my attempts to override the admin’s password in the DB were working or not. Also, if I tried to retrieve the admin’s password using WordPress’ basic “lost password” mechanism, I would actually be calling the live site and the old admin would be getting the emails generated by the site. Not good.

I remedied the second issue by doing a search in PhpMyAdmin on the client’s domain in the DB. I found it in a couple places in the wp_options table and replaced it with my local dev domain. Voila! The site was at least no longer redirecting to the client’s domain.

Then I was able to overwrite the admin’s password by following some instructions I found on several different forums. Pretty easy stuff.

Now that I was in the system, I needed to get the site and its plug-ins up to date. The core files were already current (v3.3.2 as I write). Check. Now to the plug-ins. I see a few of them need updating, but when I choose to update them automatically I run into some FTP and/or permissions issues.

I try to turn on XAMPP’s FTP services, but I get a message telling me that I need to turn off a currently running FTP service that’s hogging port 21. I don’t think I have any FTP services, but a quick google search finds the crux of the issue. I need to turn of file sharing on my Mac. That same thread tells me the default XAMPP FTP user name and password are “nobody” and “xampp,” respectively. I like it when problems get cleared up this easily.

Whoops … not so fast. No I’m getting errors from WP about not being able to find the “wp-content” directory. Google to the rescue again. A WP forum thread suggests I need to add these two lines to my wp-config.php file:

define('FS_METHOD', 'ftpsockets');
define('FTP_BASE', 'path_to_my_wp_install');

That doesn’t quite work though, so I do another Google search to see if there are other options besides ‘ftpsockets’ for my filesystem (FS) method. The┬ácodex.wordpress.org site lets me know that there are other options: “direct”, “ssh2”, or “ftpext”. I try “direct” and it works! I am able to easily update my plugins now.

My final addition looks like this:

define('FS_METHOD', 'direct');
define('FTP_BASE', dirname(__FILE__) );

One odd note about changing the FS method. The codex page I linked to above says the following about using “direct” as my FS option:

this is fraught with opening up security issues on poorly configured hosts

Yet WP also lists “direct” as the “Primary Preference”. I don’t get it? If it’s so dangerous why is it the primary preference?

I’m not worried about this for now because it’s just my local environment, but I’ll need to push this to a production server at some point.

So the site is up and running and everything has been brought up to date. Now on to create some new data types.

UPDATE: I have run into this problem again and again and I seem to forget about this blog entry. Anyway, an additional note: Sometimes I am not able to update or install a plugin. I sometimes need to turn on full permissions to allow WP to do what it needs to do. There must be a way to allow WP admin to administer plugins with running chmod 777, but I can’t figure it out. For now, I have more or less had to do this:

chmod -R 777 wp-content