Author Blog

Joe Webster's thoughts on intelligent e-Learning and web development

Wordpress Site Migration

By admin in Web Development

Over the last 8 years, I've had the opportunity to develop a number of small-scale websites for sole proprietors, non-profits, and small businesses. Freelancers know that sites like this have an inherent problem that developer/designers have to try to overcome. Specifically, we have to deal with the combination of a low budget high client expectations.

One of the ways I've been able to increase my success at overcoming this challenge is by learning to develop with the open-source blogging software Wordpress. Most of my clients don't need blogs, but they can definitely use Content Management systems, and that's how I use Wordpress.

For clients with an existing site, I sometimes develop out on my own hosting space, and migrate to the client's production environment when I have signoff on the finished site. This is one of the sticky points of Wordpress development. You need to move all the php and themes (easy), and you also need to move the content database (not so easy). I've tried several methods for site migration, and here's what works best.

  1. First, disable any plugins possible. Depending on how you built the site, pages might be dependent on certain plugins, and it might be destructive to turn them off -- in this case don't. Just turn off any that aren't critical.

  2. Now open the development environment's hosting console, and open MySQL Admin. Select your database, and select the "Export" tab. Select "Save to file" and click OK.

    Note: You cannot use the export/import buttons in the Wordpress admin console to get a database export. This does not generate everything you needed, and worse still, it results in scrambled ID's. I tried this once, and luckily it was on a very small site. Still, it took a few unbillable hours to get everything straightened back out.

  3. Here's a step you might not expect. There are some edits that need to be made in that exported information. Open the file in Wordpad, and delete any system messages at the beginning. Comments are okay.

  4. There's another critical fix you need to make to the sql file. Whenever you upload a document, current Wordpress versions store an absolute URL for the file. This may be fixed in a future release, but for now, it means your database is peppered with your development URL. Yuck. Luckily, a global find and replace can fix this. Just replace the base URL for the development site with the base URL for production. Once that's fixed, you're back in business. Let's rebuild the database.

    Note: You might also notice that Wordpress stored a machine path to the file on the development server. I've never bothered to fix this path, and it's not caused a problem, so I don't expect it's in use.

  5. Login to your client's hosting console, and create a new MySQL database. This is not necessarily as easy as it would seem. Your clients will be using discount shared hosting plans, and these don't always work as expected. If possible, allow yourself a few days in case you have to haggle with tech support.

  6. With the database created, go into the production enviornment's MySQL admin, and this time run an import. Run your SQL query, and if you followed step 2 above, it should execute quickly, and you will now have a fully functioning and populated content database.

  7. Back up the client's existing site through FTP. No matter how big it is.

  8. Back up your development site through FTP.

  9. Make a copy of your development backup, and in this copy adjust wp-config to connect to the production database. (See number 5--you might get hung up here trying to get the host to provide the correct connection string information.)

  10. The remaining steps would be best to execute at a low-traffic time. There might be a few hours of site downtime, so make sure the client is aware. When you're ready, delete any unneeded files on the client's existing site. If that's not possible, at least change the filename for the homepage so that the site will default to Wordpress's index.php.

  11. Upload your modified development backup from step 9.

  12. Test! Allow a couple hours. Tweak anything that needs to be adjusted, and then turn on plugins one-by-one and test them. Don't be surprised if you hit a few bumps along the way. You might have to switch permalinks back to the default and then switch back to pretty links to get them working. In a worst case scenario, if there's an emergency and you have to abort the site launch, just remove your wordpress files (wp- files and directories and index.php) and restore the site backup from 7.

When everything is reactivated and working, you've successfully migrated the site. Congratulations!

Tags:
Comments (3)

Comments

  1. Zumcorp @ 5/15/2009 3:38:53 PM

    Excellent article. I tried it and works very well. I like the trick of editing the domain replacement in wordpad instead on the DB.

    The only hing that I would change is the part of doing the backups using FTP. It takes a lot of time and it may not be necessary if you have the development and production environment in the same server. If this is the case, maybe with unix cp commands one can make all the necessary backups.

    Thanks!

  2. Zumcorp

    Zumcorp @ 5/21/2009 1:00:18 PM

    Hello Jwebster

    I have found a problem when I do this for real.

    My way of work is to have a test domain where I can do all the changes, and when I'm done, I transfer the DB data and the folders to the production environment, and then I configure the production domain to target the new prduction environment created.

    As mentioned in my earlier post, I followed it for a test and worked perfectly... but when I tried for a go live I faced a problem.  By some reason, when I try to launch the login screen, it keeps launching the url of the development environment, not the production env.

    I double check that the DB script is rid off any reference to the development environment, and I even did a grep to the folders looking for something references to the dev environment, but I find nothing.

    Any clue why is this happening?

    Thanks!

  3. Zumcorp

    Zumcorp @ 5/22/2009 2:34:42 PM

    The procedure was fine. I made the mistake of not updating the wp-config.php, so I basically was making the production domain to target to the development DB.
    Beware with that.

Add comment


(Will show your Gravatar icon)





 

our services

Webster Interactive offers design and programming consulting, with an emphasis in Microsoft and Adobe technologies.

Our consultants advocate best practices, web standards, and programming patterns.

connect with Wsbster Interactive

  • LinkedIn
  • Twitter
  • deviantART
  • Facebook
  • Krop

Connect with Principal Developer Joe Webster.