Copying an Existing WordPress or Other Database-Driven Site to OS X Server

Moving an existing WordPress site or other database-driven site from cPanel to OS X Server takes only a few minutes, and it provides a great opportunity to do a little house-cleaning. Preparing a ‘template’ directory in advance can save a little time if you’ll be moving several sites or creating some new ones along the way.

The aim of this series all along has been to run through the steps of setting up a new Mac OS X Server from scratch in order to replace an existing hosting setup on WHM/cPanel. (See “Setting Up Your Mac Mini Server Like Your Livelihood Depends On It — Especially if It Does”.) Earlier articles have covered several topics up through the process of enabling the web server itself, beefing up security and performance, and of moving sites that aren’t database-driven from cPanel to OS X Server. It’s worth having a look at that last article (“Moving an Existing cPanel Site to OS X Server”) first for a few helpful extras on things like reducing the TTL of your DNS records, moving SSL certificates from one host to another, etc.

The task of moving a database-driven site is only slightly more complicated. I’ll use WordPress as an example here, but the general process will be very similar for other software packages which rely on database storage.

The general philosophy of the approach I’ll outline below is this: let’s start fresh and transfer only what is needed to the new server, leaving behind any accumulated detritus from years past. You don’t have to do it this way, of course: you can copy your entire existing installation of WordPress or other database-driven package with a single rsync and a database dump and import. That’s quicker and easier, but it doesn’t offer as much of an opportunity to clean things up.

In case you have several sites which you’ll be moving, you can make things a little easier if you start by downloading a copy of WordPress, getting ownership and permissions set up how you need them, and then copying the whole set of files in turn to each individual site you’ll be hosting on the server.

With WordPress downloaded and the expanded, you can set ownership and permissions to the account of a single web maintainer, if you’re using the suggestion from one of the earlier articles in this series. (See “Basic Configuration and Preparing the Way for Extra Software OS X Server Needs”.) If ‘webuseraccount’ is that user, and ‘wordpress-blank’ is the name of your initial copy of WordPress, you can set the permissions like so:

At this point, you have a choice. If you’re only going to be transferring existing WordPress sites to your server, then anything else you need that isn’t in this fresh set of WordPress files will just be grabbed from your existing server via rsync, so there’s no need to add anything else to it.

On the other hand, if you’ll also be setting up any additional new WordPress installations, from scratch, you can take the opportunity to add some extras to this fresh initial copy, in preparation for rolling it out to one or more new sites. For example, if you normally use any extra directories in your WordPress installations which are not part of the default configuration — perhaps storing images in a different folder in /wp-content, or including a /cache folder within /wp-content, it’s handy to set those up now. For directories where WordPress itself will need write access, there’s no need to change any permissions. Instead, just set ownership to match the user under which Apache runs, which is ‘_www’. For example, to create a /cache folder in /wp-content, we could:

WordPress also likes to have an /upgrade directory inside /wp-content, so if you’re not using the SSH2 upgrade method outlined in a separate article, we can set that up now:

If you are using SSH2 upgrades, this step is unnecessary: WordPress will automatically create the /upgrade directory it needs via SSH2, and it will have the ownership and group of the user whose SSH2 keys were used. (See “Enabling WordPress to Work with SSH2 Upgrades — Without Extravagant Permissions”.) This will be the web overseer account, if you’ve opted for the single management account approach.

With the source ‘template’ of WordPress files ready to go, next you can create a new virtual host for the web service, being sure to check the box to enable .htaccess for the site, as well as any other web apps you may wish to have active.

In preparation for copying files from your old host to your new OS X Server, remember that the WordPress installation on the new server is going to be in exactly the same state as the one on your old server. So if, for example, you are running anything that needs to refer to the server by IP address, you should shut that off before making the move. In addition, both of the leading caching plugins for WordPress can be distinctly flaky if they don’t find everything ‘just so’. If you use a caching plugin, it is probably safest to shut it off before the move, and then re-enable it on the new host after the move. If you choose to leave them running, just be sure to copy over all the cached files to the new server when you make the move.

(In my particular case, I’ve been using my own high performance caching plugin for several years now that I wrote in part to get away from some of the flakiness I’ve experienced with the other two. Using this home-grown caching solution, I’ve had no problem at all just copying the entire cache and leaving the caching plugin activated. So it is possible, and no double it’s possible with the other two as well — who knows, maybe they’ve improved quite a bit since I last worked with them. In any case, just take care and watch out for any problems so you can tackle them quickly if they do arise.)

Then, all the files which you need from the old installation can be copied to the new installation, for example using rsync, as described in the earlier article about copying an existing cPanel site to OS X Server:

This is almost but not quite the same as the familiar ‘-az’ shorthand for ‘archive’, and it works well for files such as those which have been uploaded and subsequently managed by WordPress, because the ‘-p’ flag preserves permissions; however, if you’re transferring files or directories where your old host required more liberal permissions than OS X Server (where many things can be locked down more effectively than the approach often used on WHM/cPanel hosts), it is better to omit the ‘-p’ flag and set the permissions more appropriately yourself.

If these are files which were uploaded or created by WordPress (such as images), you can then set their ownership and group to the Apache user:

If you’ve used the ‘template’ suggestion, the primary directory hierarchy you’ll need to copy will be /wp-content, but be sure also to include your .htaccess file and wp-config.php file in the list of those you transfer.

Next, you’ll need to create a database and a user for the WordPress installation. If you’ve followed along with the earlier article about setting up MySQL (“Installing, Configuring and Performance Tweaking MySQL for OS X Server”), you’ll already have MySQL ready to go, and you may also have already downloaded Sequel Pro for remotely managing your databases. Sequel Pro makes it easy to complete the whole procedure very quickly.

Start by creating a database — preferably with the same name as the one used by your existing WordPress installation — and a user who has full privileges for that database. For the extra paranoid, it may be a good idea to give the user a different password than on your previous installation.

Now if you head over to the site you’re planning to move, you can log into cPanel and use phpMyAdmin to export all the tables you want to keep from your existing installation into a single gzipped file, ready for import by Sequel Pro. If you’re like many people who have been using WordPress for more than a year or two, your installation may well have acquired some detritus over the years from old plugins that added unnecessary database tables; well, this is your opportunity to clean house! (Just don’t leave behind any of the WordPress tables that are supposed to be there, of course…)

Next, it’s back to Sequel Pro to import the database, placing it right where you need it on your server.

Update the wp-config.php file for your new installation with the new database user password, and your new WordPress installation should be able to talk to the database as if nothing had changed.

In addition, if you’ve enabled SSH2 support on OS X Server as described in the earlier article, you’ll also need to change the paths to your public and private keys.

If the domain you’re moving included email accounts, you’ll also want to enable support for the domain explicitly in the mail service, as well as adding user accounts as needed. (See “Mail Services on Mountain Lion Server”.)

If you have previously set up .htaccess-based protection for /wp-admin, to prevent unauthorized users reaching that part of your installation, you will need to update this protection (unless you have specifically copied over the password file from your previous machine and want to continue using that older method of password protecting directories). Using the method I outlined previously (“Password Protecting Directories, Files or Whole Domains via a Web App”), you can enable this protection very easily by adding some digest authentication code to the start of the .htaccess file which lives at the root of your WordPress installation.

If your site uses a digital certificate, check the previous article on copying an existing cPanel site to OS X Server for details of moving your existing certificate identity to the new server.

As described in that same article, now it’s time to flick the DNS switches and officially make the move!

• macOS
• WordPress