Hosting

Migrating a WordPress/WPMU/BuddyPress Website

Migrating a WordPress site can be something of a scary challenge, but we do it a lot, and we’ve become used to it. There are many good reasons to move a site – for example, you might set one up in a subfolder, and decide to move WP to the root. Or perhaps you’ve built a site on localhost and now need to put it on a live server.

If you do it incorrectly, you stand to lose all your widget settings, some file links and so on. This wasn’t a problem with ‘classic WP’ years ago, but these days there are many many paths stored away in the database, in various forms, and catching them all can be somewhat tricky.

Here I show you the steps we take moving a localhost site to a live domain. We’re using WPMU which is running the BuddyPress plugin suite.

The Local Install

media_1254926142419.png

Here’s our site on our localhost. As you can see, it’s pretty basic, but everything’s there that needs to be there – we know all elements of the install works, and now we want to pop it onto a live server. In this lesson, we’re going to use FileZilla and ftp the files across from our local install.

Copying the Files

media_1254926439240.png

On the left you can see we’ve navigated to our local filesystem for this install. On the right, we’re connected to the server. There are already files there, because we have an old install running. You should delete all the files and replace them with the new ones in this case, but if you are replacing a site do make sure you have a copy of everything. Merging sites is much harder than migrating – and way beyond the scope of this tutorial.

So – select and drag all the files from one side, to the other.

Moving the Database

media_1254927088021.png

Our preferred tool for administering databases is mySQL Administrator. A free tool that really simplifies a lot of DB Admin tasks. Use this to take a backup of your database. You’ll need to create a new backup project.

1. Click Backup
2. Create New Project
3. Select the Schema you’ve been using
4. Click to move it across, selecting ALL tables (unless you have multiple installs in one database, in which case, just the tables for the install you’re interested in)
5. Give it a name
6. Save Project
7. Execute the Backup

Backup Done

media_1254927164402.png

You should now have a backup.

Because the server we’re using doesn’t allow connections on Port 3306, we’re going to use phpMyAdmin there. This is no problem at all, but if you were using mySQL administrator you could use the restore tools there. If you’re doing this kind of project you should really know how to use these tools anyway – I’m only explaining these steps for completeness sake and showing you a migration I’m doing myself that’s likely to be typical.

Editing the SQL

media_1254927350304.png

A database backup is done simply as a big set of SQL statements that you can run. If you’re migrating to a different database you’ll need to edit the CREATE and USE statement to tell it which database to use.

Be very careful with this database dump by the way – database dumps are a very easy way for hackers to get into your system and find out lots of information you’d rather not give away.

Importing The Database

media_1254927962875.png

Now you need to Import the Database. We’re using phpMyAdmin for this. If you have any tables there already, it’s probably best to drop them. All of them. Like I say, if you’re merging you’re going to need more help than this guide can provide.

1. Click on the Import tab
2. Select your file (if it’s bigger than your sever’s upload limit then you’ll have to speak to your admin guys about how to do this.
3. Press the Go button!

Once the import has run successfully you should see a message saying something like "Import has been successfully finished, 95 queries executed." – and it can be an awful lot more than 95 queries! It can also take quite some time. If you need to handle large datasets it’s far easier to use the mySQL Administrator tools – phpMyAdmin can get clunky.

Visit the Site

media_1254928211787.png

If you try to visit the new uploaded site at the moment you’ll get a Fatal Error because all sorts of things are confused.

You need to change the wp-config.php file.

Changing wp-config.php DB Settings

media_1254928518189.png

Change 1, 2, and 3 to match your server’s database settings.

Change 4 to the appropriate path. Most installs are in the root directory, so that would mean $base = ‘/’;

Change 5 to the domain name in use.

Change 6 from ‘/buddypress.11/’ (or whatever your local path is) to the new path, like in 4, so in most cases that will be ‘/’ also.

Search & Replace on the Database

media_1272277924659.png

You now need to run a search and replace on the database – including all incidences of code within serialised PHP strings. There is an excellent and free utility written by Interconnect IT, called the Safe Search and Replace Tool.

I can’t emphasise enough that it’s important to handle serialised PHP correctly. If you don’t, then settings will go missing, fields will get corrupted, and your site runs a severe chance of not working on the new location. It’s a pain, but it’s important.

So, download the program, place it in your blog’s root folder and then run it by visiting the appropriate URL.

If you’re getting confused at this point, perhaps you shouldn’t run the program. Just saying, because it can cause plenty of damage!

Running the Script

media_1254930511307.png

Simply visit http://www.example.com/searchreplacedb.php in your browser to fire off the script. This will run. If you experience a time-out, or too much output, you may need to go into the script and remove any echos that are slowing it down. I’ll probably comment this out in due course anyway, but for diagnostics purposes I’ve left it. Once run, you should see something like the above at the bottom. Even a very large search and replace should only take a few seconds.

Some Tweaks

Check that you can navigate your site in its new location.

You may have to modify .htaccess to fix paths, and you may need to check your uploads folder for media. But that’s it. All should be good.

Extra Steps for WordPress MU

media_1254930620452.png

If you’re using WordPress Single User, then that’s it. You’re all done!

But in this example, we’re running BuddyPress on WordPress MU, and that means one extra step. In phpMyAdmin you need to open up (1) wp_blogs, (2) click the browse tab, and (3) click the edit tab for each row. If you have a lot, you may wish to run another searchreplacedb.php against the database, looking for localhost.localdomain and buddypress.11 and swapping them appropriately.

Categorised as: Wordpress

The Difference Hosting Can Make

It’s quite apt that on the day that WordPress.com appears to have broken (it’s not serving any front-end pages on this blog at the time of writing if you’re logged in) I’m making a post about hosting.

So to the gist of this post.

We provide hosting to clients, and only clients.  You can’t just ring us up and ask us to host your site.  We’re quite picky about what hits our server. Read more

Managing Risks With Web Hosting

We’ve had some clients recently who’ve been burned by other web designers and their hosts. At first we wondered how… our own uptime so far this year, removing planned outages, has been 99.966% – ie, we had three hours downtime on a Sunday morning due to a routing problem at our hosts.

It’s unusual to have even that much downtime, but it can happen. Machines can break, drives fail, and availability isn’t always easy to guarantee.

But if it’s happening a lot, or you run a mission critical website, then this can be a major issue. Imagine spending £200k on a national advertising campaign, and the day it goes live the web server’s having a nap. The developers are on an office day out, and the hosts put you on hold when you call.

In web hosting there’s an awful lot of people making false economies – they run major companies on cheap, consumer level hosting that costs perhaps £15 a month… or less! This may be fine if the site isn’t generally that busy, but any spike in traffic and the machine won’t have the resources to keep the site going. Not only that, but because you’re sharing a box with possibly thousands of other websites, the poor server may well be over-stuffed and overworked anyway.

There’s a few steps to consider when dealing with this:

  1. Properly assess risks. If you could lose £100,000 of business when your website fails, it’s obviously wise to spend more than a few hundred pounds a year on it. But there’s no point spending £10k a month on a site that generates very little trade, just for the sake of avoiding ten minutes of downtime.
  2. Make sure what goes on the server is only ever fully tested code written by people you can trust. Our own web consultancy, Interconnect IT goes to great lengths to make sure the code supplied is reliable.
  3. Consider bringing in house code-reviews and creating your own testing requirements.
  4. Load test your server with the predicted maximum level of traffic. If you don’t, how do you know its adequate? And you can’t predict the load just on raw visitor numbers either – some websites are much more demanding on server resources than others.
  5. Make sure the site is suitably protected from attacks by hackers and even malevolent rivals.

Ultimately any website is a reflection of your business – if it’s cheap and unreliable, it’ll say that to your potential clients.