Technology

Copying WordPress Locally

I’ve been using WordPress for about six years now and think it’s a truly great piece of technology. I love using it for my blog and have deployed word press on a number of other sites around the web. One of the things I’ve struggled with though is copying a WordPress instance down to my local machine. I could certainly do it, it was just a long and tedious manual process. Copying WordPress locally shouldn’t be so difficult.

  1. manually login to the remote server and
    • compress all the site files
    • export the database
    • compress the database file
    • transport all of the compressed files back to my local machine
  2. import the database
  3. create custom SQL statements to change http://oldhost to http://newhost
  4. unzip all the supporting files locally.

The process was straightforward, but tedious and a waste of time. I would often work on a site that was somewhat out of date or have missing assets as I updated the database without downloading all of the new files.

I’ve been fortunate to meet up with the WordPress Sydney group. Each time I go I’ve learned something new which makes me even more excited about working on my own site. Good Meetups inspire their members to get deeper into the topic. WordPress Sydney is no exception.

The March meeting spoke of moving WordPress installs in between machines. I’m specifically interested in moving my hosted version down to my local Mac. Well, the organizer, introduced WP-CLI as one of the tools in his arsenal. Automation is the key to making everything simpler and more predictable. Now that I had a tool to automate WordPress maintenance, I now had no excuse for an out of date development system.

Note: this article makes one big assumption: data only flows from my production server to my laptop. Git is the right system to use for two way transfer between the development and production instance of WordPress. If you are using Git, the database parts of the scripts are likely still useful.

0.Install an *AMP system

Install a *AMP (Linux, Mac, Windows) set up on your development system to run WordPress. Mac and Linux users have everything they need built-in but a preconfigured solution may be easier. Windows will be a bumpier road, but not impossible.

1. Establish trust between your local and remote systems

The transfer script will need to have access to the production system to download the database. The script needs be able to login with SSH without using a password.

2. Install WP-CLI

WP-CLI needs to be installed on both the host and target systems. WP-CLI does the heavy lifting for us.  Installation on my Macintosh was straightforward. However, every web host is different. The installation process for WP-CLI on BlueHost was a bit nonstandard.

3. Install the remote script

This script makes a backup of your database on the remote system. The local script will invoke this script over SSH to get a current copy of the database.

backupscript.sh

echo 'Exporting WordPress DB'
echo '----------------------'
rm -r wordpress_db_backup.sql.gz
php-cli bin/wp-cli.phar db export --path=public_html/ wordpress_db_backup.sql
gzip wordpress_db_backup.sql

The line with php-cli bin/wp-cli.phar is a BlueHost specific workaround for shared hosting. It’s just using the standard database export from WP-CLI.

Test the installation of this script by running the command on the local system.

4. Install the local script

importsite.sh

echo 'Export remote database'
echo '----------------------'
ssh you@remote.com backupsite.sh

echo 'Copying database files locally'
echo '------------------------------'
scp you@remote.com:wordpress_db_backup.sql.gz path_to_local_website/
gunzip /path_to_local_website/wordpress_db_backup.sql.gz

echo 'Syncing remote files locally'
echo '----------------------------'
rsync -avz -e ssh you@remote.com:public_html/* /path_to_local_website/

echo 'Importing database'
echo '------------------'
cd  /path_to_local_website/
wp db import --path=/path_to_local_website/ /path_to_local_website/wordpress_db_backup.sql
rm /path_to_local_website/wordpress_db_backup.sql

echo 'Reconfiguring URLs'
echo '------------------'
wp search-replace  --path=/path_to_local_website/ www.danradigan.com localhost

The big win is using rsync to copy all of the new content down incrementally rather than having to version all of the content in Git or have massive content downloads when I refresh the site.

Caveat: I’m not sure why, but I had to specify full paths when setting up these two files.

I do have to say, I’m going to miss the WordPress Sydney group. Their great bunch of folks with good passion and insight about the WordPress platform.
wordpress_sydney-1

2 replies »

  1. I’ve often wondered why wordpress couldn’t store local links as relative URL’s in database? It would alleviate the database manipulation steps.

    Like

    • Dave,

      I’ve actually wondered the same thing. It seems strange to me that WordPress insists on using absolute URLs for everything. For things like site name in the base URLs I get it. But for internal links between pages and images it just doesn’t make sense.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s