2015-03-26

I usually work with Python and Django, but recently a friend asked me to help out with some work for a small WordPress site. The first step was getting a clone of the live production website onto my Ubuntu laptop so that I could play about without breaking anything important! Since I'm a total WordPress newb, I thought I'd document how I did this...

The site was hosted on GoDaddy, and the first thing I did was enable SSH login (cPanel settings), and logged into the server:

I then made a tar archive (basically a zip file) of the html dir, where all the wp goodies reside, to make it easily to download everything to my local machine:

Now exit the server and log back in with sftp to get the tar file you just made:

Back in the local terminal, extract the tar, tar -xvjf....

I'm assuming you've already got the LAMP (Linux Apache MySQL, php) stack running and in working order, and if not there are plenty of guides on installing these prereqs and getting the basic install of wordpress running locally on top. You should at this stage be able to visit 127.0.0.1 (or 127.0.0.1:8888 depending on your apache settings) in your browser and see the default wp install, if not fix this before continuing with this guide.

With the html site extracted copy it over to your apache root directory (first make a backup of any existing directory there, perhaps a default wp install), usually:

will do the trick for a default apache install (i.e. virtual host has root /var/www/html, check /etc/apache2/sites-enabled/000-default.conf if in doubt)

You need to make sure at this stage that the permissions are sufficiently liberal. On your local machine (not many security concerns) doing:

should suffice (remember apache runs as the www-data user).

Cloning the db

The easiest way on GoDaddy was simply to make a backup of the db from cPanel, but you could use phpMyadmin if you have it installed, or do it like a ninja with some straight SQL commands. However you do it, make note of where the db dump got saved, and login and grab it with sftp. Let's say this file is called wpdump.sql

To import the db into your local mysql, you should first create an empty db (or multiple empty dbs if your site uses more than one db) with the same name(s) as the one(s) you had on the live server. First login to mysql as the root user:

and create the database with matching name to the live db (you should have created this root user during mysql installation) . Let's say the db is simply called wordpressdb:

With this db set up it's time to import the live database that you backed up and downloaded:

Now with a bit of luck you will find the db has been successfully cloned. To double check:

should show something like

If you prefer to do this all with a GUI then mySQL Workbench seems pretty good.

Finally create the db user matching the one defined in your wp-config.php file's DB_USER define, let's call this user imaginatively wpuser:

and grant them the needed privileges, flushing them to update mysql:

You will need to grant these privileges on any other dbs your site uses too if you have multiple dbs.

/etc/hosts

Whilst not strictly necessary, this just makes life esier. Add your site to the /etc/hosts file to save having to type 127.0.0.1 to access the install, e.g.

Update wp-config.php

Need to update some settings here so wordpress knows to use the local db, and with which user to connect to it. NB it's important to make a distinction between your MySQL user (the user which can connect to the MySQL db, which we called wpuser, and for which we granted the necessary privileges to manipulate the wordpressdb), and the WordPress users for your site itself (i.e. the users that can login through the wp admin, and can be found in the wp_users table of the wordpressdb). Inwp-config.php we are concerned with how to connect to the MySQL db, and we want the appropriate MySQL user, i.e. wpuser.

You could try localhost, but 127.0.0.1 seems to sometimes prevent various connectivity errors.

Finally you'll want to add

to wp-config.php file on your local dev machine. To give a simple example of why this last step is necessary:

Let's say you include your theme includes your css style sheets in front.php with

where $themePath is some shortcut variable defined in functions.php as

(see get_bloginfo docs). Then without updating the wp site URL this $themePath is going to point to your live site, not your local dev site. None of your changes to the CSS locally are going to be reflected in your local clone.

Debugging and testing

FIrst make sure apache2 is running:

and if not start it with service apache2 start. Then point your browser over to mytestsite.com (or mytestsite.com:8888 if you set the apache2.conf to Listen 8888 etc)

The first time I did this I got Error Establishing a Database Connection, ugh. I got this both when I tried to access the root, and also when trying to access /wp-login.php, but not when I tried /phpmyadmin. Hmmm? To debug this I found a nice little snippet of php online somewhere:

and then visiting mytestsite.com/testcon.php I discovered it was an authentication error, reset the password for wpuser and all was good.

If you get this error, you could also try changing the DB_USER in wp-config to your MySQL root user. Also check that your user definitely has the required privileges, and that MySQL is definitely running on the port you expect (try sudo netstat -tlpn | grep mysql to find out, the default is 3306).

Another useful way of debugging what is going wrong is tailing your apache server logs during an attempt at loading the page:

(this is the default dir, but if your logs are not here, check your apache conf for where they are being written)

MySQL workbench GUI may be an easier way to quickly scan to see if all settings are good for user and edit them if not.

Permalinks

At this stage things were beginning to take form for me. I could got see the root page of my site, and also login to the admin at /wp-login.php. Weirdly however none of my relative URLs worked, e.g. /about-us just went to an apache 404 error, saying file does not exist on this server. Basically apache was just dumbly looking in /var/www/html for a file called about-us. Wordpress uses permalinks to allow users to prettify the slug of given page, and clearly something was going wrong with that.

After some googling, I discovered I needed to first enable the apache module mod_rewrite, which is used to map a given URL to a file system path.

and needed to set the permissions to allow this rewrite for my /var/www/html dir:

before finally restarting apache. Hurrah, all the links now worked!

Show more