Cloning a live WordPress site to a local Mac test environment

As you customize WordPress and extend its functionality with various plugins, and the usual barrage of software updates starts arriving, it becomes increasingly useful to have a local environment to try things out.

A local environment allows you to safely test new plugins and themes, new versions of existing plugins and themes, new versions of WordPress, and all sorts of other changes, without affecting the live site. If anything goes wrong, you can always roll the local site back to a known good state.

The steps necessary to create a local WordPress environment are already well documented. There are also instructions for moving an existing WordPress site from one server to another. By combining these together, you can work out how to make a clone of an existing self-hosted WordPress site in a new local test environment.

However, many of the steps are not obvious—especially if you created your live WordPress site via a one-click install, as I did, using Fantastico or similar—and some of the existing how-tos out there aren’t all that clear. Having gone through this process myself, and cloned a live WordPress site to a local Mac OS X environment, I thought it would be useful to describe the full end-to-end process in simple ABC steps.


The strategy I’ll follow is to configure the local site as closely as possible to the live one.

We’ll create a local domain, so the local site can be accessed using a normal-looking URL. This is partly for psychological reasons—it looks more convincing—but also because this makes it easier to view the local site from a mobile device such as a phone or tablet, which I’ll cover in a future post.

Throughout these steps I’ll assume that the live site has the URL, and for the local site, we’ll define a new hostname for the URL

I will also assume the local WordPress environment will run on Mac OS X. If you’re using another OS, a few of the steps will be different, but the overall principle remains the same and many of the steps will still be applicable.

Setting up a local domain

To allow the local site to be accessed on a URL such as, you need to create the domain “” by mapping it to localhost ( in your local hosts file.

1. Open a Terminal (Applications → Utilities →, and edit the local hosts file (/etc/hosts) using a text editor such as vim:

sudo vim /etc/hosts

2. Enter your password when prompted, and add the new domain name at end:

» reminder In case you haven’t used vim, or forgot how to use it, you need to press i to go into insert mode, make your change, and then press Esc to get out of insert mode. When you’re done, type :wq to save your changes and quit or :q! to quit without saving changes.

Local host entry

Installing MAMP

As the official documentation says, the easiest way to run WordPress on a Mac is probably to install MAMP, which provides a Mac OS X variant of the LAMP (Linux, Apache, MySQL, PHP) stack. So, wanting an easy life, this is the route I took.

MAMP is a single install that gives you all the software you need to run PHP applications such as WordPress on a Mac. If you’re using another OS then you’ll need to find an equivalent way to install Apache, MySQL and PHP.

  • Download the latest version of “MAMP and MAMP Pro” from Both MAMP and MAMP Pro get installed together, but you only need to use the MAMP variant which is free.

Once MAMP is installed, open its Preferences dialog. Only two configuration changes are necessary to get going.

ports tab

On the Ports tab, set the Apache port to 80 and leave the MySQL port at 8889.

» note Setting Apache to listen on the standard Port 80 makes the local URLs neater, because there will be no port in the URL, but it requires you to enter your password every time you start MAMP (although you only need to restart MAMP when you reboot your machine). If this is too much trouble, you can change it later — for now let’s just stick with Port 80.

Before setting Apache to Port 80, make sure you don’t have another web server already running on your machine on that port—in particular, make sure System Preferences → Sharing → Web Sharing is turned off (note—this option seems to have been removed in Mountain Lion anyway).

Apache tab

On the Apache tab, choose where you want your document root to be. This can be anywhere you like, but for convenience I put it somewhere in my home directory. For example:


Create that folder, if you haven’t already, and click Start Servers to start MAMP’s Apache and MySQL processes. You should be able to see that both Apache and MySQL are running.

MAMP running

At this point OS X may ask Do you want the application “mysqld” to accept incoming network connections? I have found that if you block incoming connections to MySQL, everything works fine—presumably because the incoming connections from MAMP are only from localhost, not other machines. So, if you’re not sure, it should be fine to block incoming connections.

Cloning the live WordPress site

Now that we have the MAMP platform in place, the next step is to clone the live WordPress site on to that platform.

There are only two things you need to copy across in order to completely clone a WordPress site:

  1. Your document root and all the files under it.
  2. The WordPress MySQL database.

That’s it. There are no other secret WordPress configurations or data hidden anywhere else. All the configuration for Apache, MySQL and PHP can be done through MAMP UI, and everything to do with WordPress is carried over when you copy the document root and database.

Incidentally, you can use the same process—copying the document root and database—to make an ad-hoc backup of a WordPress site at any time (either the live site or the local one).

When setting up a web application, I like to start from the front-end and work backwards. This is because when the front-end is done, you can start serving static content and feel like you’re making progress. So, let’s deal with the document root first.

Copying the existing document root

Copy your document root as follows.

  • Log into your hosting provider, find your document root and tar or zip it up, and download the resulting file e.g. to your machine.

Even if WordPress is installed in a sub-folder of your document root, e.g. /blog, you probably want to include the entire document root, including whatever else is there besides WordPress. This allows you to test duplicate your entire web site, and ensures the local site mirrors your live site’s URL structure.

  • Untar or unzip it into the document root you chose above e.g. /Users/user/hosting/docroot/.

» checkpoint Now you should be able to serve static content from your document root.

For example, if you put a test.html file directly in your document root, then you should be able to access it at the URL This means Apache is working. You should also be able to see the MAMP home page at

However, if you visit a WordPress page such as you should get the message “Error establishing a database connection“. This is a good thing (for now), as it means the PHP interpreter has successfully run WordPress and attempted to connect to the database. Since the database does not exist yet, you get that error. We’ll address that in the next step.

Exporting the existing database

To copy the WordPress database over, you first need to export it from your live site as an SQL file.

If your hosting provider offers the web application phpMyAdmin for administering MySQL, then you can do this as follows.

  1. Find phpMyAdmin in your hosting provider’s admin UI.
  2. Open your WordPress database by clicking its name in the left-hand navigation bar. For example your database name might be wpdb.
  3. Click Export.
  4. On older versions of phpMyAdmin you need to tick Save as file, otherwise this is automatic.
  5. Click Go.

» note Make sure you select the WordPress database before you click Export. If you just open phpMyAdmin and click Export without first selecting a database, then it exports a whole load of MySQL system stuff which you don’t need.

The above steps should download a file to your local computer called something like wpdb.sql. This is effectively a backup of the entire WordPress database, including all the tables, schema and data.

In a later step you’ll import this SQL file into the local MySQL server installed by MAMP.

Checking how WordPress will connect to the database

Before you import the data, let’s check how WordPress is configured to connect to the database.

  • Open the wp-config.php file that you copied from the live environment into the local document root, and find the following section.
/** The name of the database for WordPress */
define('DB_NAME', 'wpdb');

/** MySQL database username */
define('DB_USER', 'wpuser');

/** MySQL database password */
define('DB_PASSWORD', '************');

/** MySQL hostname */
define('DB_HOST', 'localhost');

This tells WordPress to find the MySQL server running on the machine indicated by DB_HOST, log in with MySQL username DB_USER and password DB_PASSWORD, then use the MySQL database indicated by DB_NAME.

Make a note of the values for each of those fields.

  • Make sure the DB_HOST field is set to localhost in your local wp-config.php file.

It is NOT necessary to set the MySQL port number in the DB_HOST value. MAMP is already set up such that PHP “knows” the correct port for MySQL automatically via a PHP configuration file. If you set the DB_HOST field to just “localhost” it will work fine.

Importing the database

Importing the data is not as simple as just clicking Import in phpMyAdmin on the local machine. The SQL file we generated will not automatically create the MySQL database in the new environment; it assumes an empty database of that name already exists.

So, first we need to create an empty database with the correct name, then import the data.

  1. Go to the local MAMP home page e.g.
  2. Click on phpMyAdmin to open the local phpMyAdmin provided by MAMP.
  3. Find the “
phpMyAdmin: Create DB

You should see a confirmation message “Database <name> has been created.”

Once you’ve done that, you can import the SQL file.

  1. Select the empty database you just created in phpMyAdmin’s left-hand navigation bar.
  2. Click Import.
  3. Click Choose File
  4. Find the SQL file you exported earlier e.g. wpdb.sql.
  5. Click Go.

Importing may take a while if there is a lot of data. Once it completes, you should see a confirmation message “Import has been successfully finished, <n> queries executed.”

This means all the WordPress data has been loaded.

Ensuring WordPress can authenticate to MySQL

Next you need to ensure that WordPress can authenticate to MySQL. For this, you have a couple of options.

OPTION 1: Change your local wp-config.php file so that WordPress authenticates with the DB_USER “root” and DB_PASSWORD “root“.

The MySQL server installed by MAMP has a single default user “root” with password “root”, which has full privileges on all databases. If you want to get going as quickly as possible, enter these details in the DB_USER and DB_PASSWORD fields.

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'root');

Since this is just a test environment on your local machine, the security of the configuration is not critical, so configuring WordPress to use the root account is probably OK. The root account will still exist anyway, whether you use it or not—and changing its password is not easy.

» note If you do feel tempted to change the root password of the MySQL server installed by MAMP, be aware it is a non-trivial exercise, because it’s hard-coded at least 5 different MAMP scripts and config files which are not very well documented.

OPTION 2: Create a new user in the local MySQL server to match the one used by the live site.

Instead of using the root account, you may want to create a new MySQL user in your local environment — especially if your live WordPress site is using a non-root user, in which case you may want to use the same username in the local site. Reasons for doing this might be as follows.

  • The main WordPress configuration file, wp-config.php, can be transported between environments with fewer changes.
  • When you do a database restore in the local site, you’re following a similar process to what you’d do in the live site, so you get to understand and rehearse the process a bit better, in case you need to do a restore on the live site.

If you choose Option 2, then you need to do three things: create the new user, allow it to log in from “localhost”, and give it full permissions on the WordPress database. Here are the steps in detail.

  1. Open the local phpMyAdmin provided by MAMP.
  2. Select the WordPress database in phpMyAdmin’s left-hand navigation bar.
  3. Click Privileges.
  4. Click Add User.
  5. Enter a username, or paste the username from the DB_USER field in wp-config.php, into the User name field in this form.
  6. Select “Local” from the Host drop-down list (this bit is important!)
  7. Choose a new password, and enter it both in the DB_PASSWORD field in wp-config.php, and in the Password field in this form, twice. (Alternatively just copy the existing live password from wp-config.php into this form — but it’s probably better to choose a new one.)
  8. Ensure that Grant all privileges on database “<dbname>” is selected.
  9. Click Go.

phpMyAdmin: Create User

» note If your wp-config.php is using localhost for the MySQL hostname, then you must choose “Local” from the Host drop-down in step 6 above. Strangely, if you leave it at the default value “Any host” then WordPress fails to connect with an “Error establishing a database connection“. Apparently, “Any host” does not mean any host…

Confirming WordPress successfully authenticates to MySQL

Regardless whether you followed Option 1 or 2 in the previous step, everything should now be in place for WordPress to successfully authenticate to MySQL.

» checkpoint You should now be able to see at least the blog’s home page as a visitor would see it at (or if your site is in a sub-folder). It should look (almost) identical to your live site.

However, there is still one critical thing that needs to be addressed before we can say we’re done:

  • Any links within the WordPress blog still go to the live URL, e.g.
  • It’s not possible to log in. The login process redirects you to the login page on the live site.

»note If you have the MAMP Apache listening on a port other than 80, you cannot access WordPress at all at these stage (even on the other port) because it tries to redirect you to port 80 which fails. This is because the site’s URL, as configured in the database, is implicitly expecting port 80.

Fixing the WordPress URLs

The cause of these issues lies within the WordPress database—which was copied from the live site—as the database is still configured to use the live site’s URLs.

WordPress URLs would normally be set in the following places under the Dashboard:

Settings → General → WordPress Address (URL)
Settings → General → Site Address (URL)

However, now we have a slight chicken-and-egg situation. How can you change the site URLs in the database, when you can’t log in to the WordPress Dashboard to do that, because it redirects you to a different URL, because the URLs in the database are wrong?

The easiest solution is to update the site URLs directly in the database in your local site, so that they use the new domain.

  1. Open the MAMP phpMyAdmin tool again.
  2. Select the WordPress database in phpMyAdmin’s left-hand navigation bar.
  3. Click SQL.
  4. Paste in the following, and update the URL values as appropriate.
  5. Click Go.
update wp_options set option_value="<WordPress Address (URL)>"
where option_name="siteurl";

update wp_options set option_value="<Site Address (URL)>"
where option_name="home";

The values you substitute for <WordPress Address (URL)> and <Site Address (URL)> should be identical to those fields in your live site, except with the live site’s domain replaced with the local site’s domain. Keep any URL path e.g. “/blog” the same, if you have one. For example:

update wp_options set option_value=""
where option_name="siteurl";

update wp_options set option_value=""
where option_name="home";

These two URL fields should fix nearly all the links generated by WordPress, at least as far as basic navigation around the web site goes. This is because for navigation elements, WordPress generally uses relative URLs which are resolved using these two URL fields as the base.

However, media links within blog posts will still be pointing to the live site. There may also be other absolute links that were hard-coded by you or generated by plugins, which are pointing to the live site. They won’t show as broken links though, because your live site is still up and running.

For the purpose of setting up a local environment for testing things out, this may not matter. But if you want to update all the links within blog posts as well, instructions can be found in some of the articles linked from here such as this one.

For additional tips for fixing the URLs—including for WordPress multi-site—see the comment from David Dumonde below.

The end result

After all this, it should now be possible to view the site in your local environment at, exactly as a visitor would see it, apart from the new domain.

Furthermore, it should also be possible to log in to the WordPress Dashboard at, using the same WordPress credentials that you use to log in to the live site.

You should now have a fully operational local clone of your live WordPress site.

What’s next?

In the next post I’ll cover how to access the local WordPress site from mobile devices such as phones and tablets, using the same local hostname e.g. I’ll describe a way to do this using only free software, and without jailbreaking the mobile device or changing its local hosts file.

  • Excellent guide, really helped me out. One note: I had a problem with the site redirecting to the live site whenever I’d refresh the page. It turned out that it was an HTTPS plugin that was doing it. Deleted that plugin from the local directory and all was good!

    • Thanks for the feedback Kurt! Which HTTPS plugin were you using? I’m interested in WordPress security plugins.

      • James, I’m running in to the same problem. However, I’m running on multisite.. any ideas?

        • I’ve only seen WordPress redirect you to the live site if you try and log in and you haven’t updated “siteurl” and “home”. Have you updated these? Tried disabling any plugins? I haven’t used multisite so not sure if that matters.

          • Thanks. It was a caching issue. Shift + refresh fixed the issue.

  • Kevin Latham

    Fantastic guide, but I am getting a DNS error:

    While trying to retrieve the URL:

    The following error was encountered:

    Unable to determine IP address from host name for

    The dnsserver returned:

    Name Error: The domain name does not exist.

    This means that:

    The cache was not able to resolve the hostname presented in the URL.
    Check if the address is correct.

    I followed your steps to update the hosts file using VIM.

    Am I missing something about clearing the cache?

    • I’d use a fully-qualified hostname like If the one in your hosts file is fully-qualified then you need to change the URL to match.

      • Kevin Latham

        PERFECT! Thanks James!

  • never mind, I got my answer. You have to set up a name-based virtual host. In MAMP Pro it takes only a few clicks.

    • Yep! I was just going to say, create name-based virtual hosts in the web server. Glad you found the solution.

  • Dave

    Thanks James! I successfully cloned two sites from a live server onto my local computer. I also set up name based virtual hosts to point to them – Thank you, JP Lew, for the idea. Everything is working.

    Do you have any thoughts about going in the other direction? I am wondering if exporting the databases back to the live site would clobber any data that was added (from site traffic, comments, etc.), since the last time I cloned the site to the local computer.

    I am new to website development/administration, and I am trying to understand all the issues with syncing the databases between the live and local server.

    • Hi Dave, when you import a database it will overwrite all the comments, posts, config etc in the destination site. (Even Disqus stores a copy of each comment in the site’s own DB). Also, since WordPress and plugin upgrades/installs sometimes make changes in both the DB (e.g. new tables/columns) and document root (e.g. new php files), they must be kept in sync – so if you’re going to migrate the DB anywhere I would always migrate the document root at the same time.

      Now, your question about going in the other direction is an interesting one. I do all my content-related work directly in the live site, and I make regular backups from the live site because that’s the most up-to-date, content-wise. If, on the other hand, I need to test new configuration, plugins or upgrades, then I test them first in the local dev site, and if it works I repeat the process manually on the live site. I don’t migrate the DB/doc root to the live site because it would clobber any new content. Then as part of my backup process, I clone everything from live to dev again at regular intervals, to ensure they’re in sync. Re-doing config changes manually in the live site works for me as I only have one relatively simple site to worry about, and I don’t change it very often.

      If I was managing a complex WordPress installation and I developed a major new version of the site, I would want there to be a release process that allowed me to release the new config, whilst preserving the existing content on the live site. And I think that’s what it really comes down to – content vs. config. In any CMS, content is typically updated in production and sometimes released back to dev, whereas config is often updated in dev and then released forward to production. So they’re moving in opposite directions. This duality applies to the document root as well as the DB: for example the “uploads” directory is essentially content (files uploaded by the content authors), and things like php files are basically config (from a release management perspective).

      Sadly, I don’t think WordPress handles this bi-directional movement natively. Actually, it doesn’t even handle uni-directional movement natively, when you think about it… Still, other people have asked the same question, and there may be plugins which help in this regard – but I have not looked into them. In the worst case you could identify the tables/directories containing the content you want to preserve, and back them up and restore them separately.

      If you find a good solution, I’d be interested to know.

      • Dave

        Thanks James, for the detailed reply! I am a newcomer to website design and administration. I am trying to figure out what my workflow is going to be for maintaining my sites. I would like to figure out a way to sync both sites using git. I have had some success managing a few personal code writing projects with git.

        There are some blog posts on using git to push changes from a local dev site to the live site, but they do not address clobbering of the database or broken links to the database! As you and others have said, changing themes and plugins on the local dev site alters the database.

        I cannot figure out how website admins are exporting (or “git push”-ing) ANY changes to their live sites from a local dev site without them going haywire. I will keep studying and asking questions.


  • Andrea

    THX!! Very uselful.

  • Pingback: Setting up a Local Development Copy of a Wordpress Site | Control Alter Ego()

  • Steph Broadley

    Thanks for the tutorial James. I have run into an issue however and wondering if you might know what I’ve done wrong. I’ve posted it on WordPress support but getting no joy.

  • Ann

    Thanks! I have no experience beyond basic tweaking of code and I’ve managed it!

    The site would not load at first but after reading the comments I tried deleting the plugin files and adding them one by one until I discovered it was a plugin that prevented it form loading. No idea why, it was the “buzzsprout podcasting” plugin in case you’re interested.

  • Anna

    Hi, I’m having a problem: the local version of the site works fine but I can’t navigate it. Any link that starts is broken, I get 404 Not found errors.

    Any suggestions?

    Thanks in advance!

    • Did you follow the steps under “Fixing the WordPress URLs” using your own site’s local URL, including the path (e.g. /blog) if it has one?

  • Hi Thanks for your advice..was having a hard time for last few days and finally solved!!
    Just one thing my images are not showing up and as far as i know i have changed all the links in the database. Any Ideas??


    • Great. For broken images you’d need to check what image references are actually being generated in your HTML and take it from there.

  • Your sir, are awesome! Thank you very much for detailing this. I went ahead and opted for the localhost:8888 option instead of changing my host file. That said the directions minus those steps were great. Thanks again!!

  • Fredy

    Nice piece of work. I was wondering if you know where I could find a kind of step by step tutorial on how to move a wordpress website to a new domain and new folder. I’m not an expert in developing websites and as money is short I’ve created myself my own website. By that time I wasn’t sure abut the name for the website but now I am and heve it registered and would like to move everything created to that new “name”.

  • AuContraire

    Wow. I’m exhausted but I have an offline copy of a live WordPress installation working perfectly! Thanks so much. The final hurdle, also mentioned by others here, were a bunch of 404 errors despite the fact that the pages plainly DID exist on the server. and some links that stubbornly referred out to the live site. It turned out to be a plugin causing the misdirect. I disabled all plugins that related to anything “out on the web” like sitemaps, SEO etc and the links reverted to working correctly on the local copy.

  • Luke

    Hi James! Many thanks for your comprehensive guide. I’m having an interesting issue: like several others, I’m seeing my site homepage but getting 404s for every linked page, post, or category. I did follow the steps to fix the wordpress URLs, and they do seem to be fixed, all pointing to my local installation. I have pretty permalinks on my live site and noticed that my original tar of my site root didn’t include .htaccess. After moving it over, I still can’t seem to get the 404s to go away… tried restarting apache, but that didn’t work. At this point, I’m stumped. Any ideas?

    • Do the generated URLs look like you’d expect i.e. same as the live site except with different domain? Do you get 404s for dynamically-generated PHP content only, or also for static content? (Perhaps find an image URL that works on the live site, change to the dev domain and see if you get a 404). The .htaccess file is critical and should have been included in any tar file of your docroot. Are the permissions correct? Is the folder structure of your docroot identical? These are just some thoughts, only you can debug it.

      • Luke

        Figured it out, although I’m still scratching my head about the .htaccess file not making it into the tar. What I did was delete the custom permalink structure from the wp_options in the database, which forced it to revert back to the default ?p=123 format. After that, the links worked, so I was able to log into my wordpress dash and change the permalinks back to the way I wanted, generating a new .htaccess in the process. Whew!

        • Paul

          This tutorial is incredibly helpful. Great work!. I’m getting the 404 error problem that others are getting. Can somebody please explain how to make this work? How does one delete custom permalink structure… does that mean deleting all permalinks and re-inserting them? What is ?p=123 format? The great, in depth nature of this walkthrough is perfect for folks who are new to wordpress and/or MAMP, but the arcane nature of these instructions for removing the 404 errors is beyond me. Still, glad to have at least a finger pointed in the right direction. Thanks for the great post!

        • Nahbois

          Can you share how you deleted the permalink structure in the database, I know this is my problem, but I just am not savvy enough at sql to confidentally delete these from the db.

          • Caroline

            Hi Nahbois – I just went to the permalink settings in the WP dashboard, went to Settings > Permalinks, and then selected the ‘default’ option. This reset them so that I could successfully link to all my pages. I then went back into Permalinks and resaved under the option I originally had, and they still work fine.

  • Amanda

    Finally got this to work after I deleted all plugin files from my test site. Will have to reactivate and find the culprit.
    However, my WordPress admin page looks very strange. My guess is something went wrong with a CSS file? Any ideas?

    • If you want to investigate that, then by digging around in HTML source your docroot, you can work out the URLs of the WP admin CSS files e.g. If they work on the live site, do they also work on the dev site by changing just the domain?

      • Amanda

        Yes, they do. I checked the URLs of both the live site and the test site, and the CSS file appears correctly on both.

        • Not sure if it’s safe to just “delete plugin files”, rather than deactivating the plugins in the admin page. Try replacing the docroot with a fresh tar from the live site, go straight to the admin page and deactivate the plugins?

          Other than that, look for differences between the test and live site, folder structure, file permissions etc. It’s hard to debug these kinds of issues remotely! Good luck.

          • Amanda, giving /wp-admin/admin.php write permissions should do the trick.

  • Eddie H

    Following up to my question, I forgot that when I unzipped my document root files (wordpress files) on my local machine, it created a folder that I forgot to update in my MAMP preference settings. I updated that setting to target the new folder and that did the trick.

    I also kept getting the message “Error Could Not Connect To Database” and turns out I forgot to change wp-config.php username/password to ROOT but after doing that, everything works PERFECT.


  • I am also getting the same screen 🙁 actually i went for the option 2 where i have given same username details as per my live wordpress website. Please help…

    • Try reading the MAMP documentation: and get a feel for how it works. Can you serve simple static content (a test HTML file) from the doc root before even worrying about WP? Did you see how Eddie resolved the issue in his follow-up comment – by setting the doc root correctly in MAMP Apache tab? Generally you need to go through some trial-and-error to diagnose the problem, which I can’t do for you.

  • This is beautiful and thorough! I’d just upgraded to MAMP Pro so the configuration was a little different, but if you keep making sure the actions at the checkpoints work, you should be good. Earlier in my MAMP Pro configuration, I’d changed the root password which clogged up the works a little. If you are having issues and have changed the root password, change it back to see if that helps, then proceed from there.
    When I saw my lovely little dev site smiling back at me locally, it felt amazing. I’d just been hacking away at using MAMP/XAMPP before, but this helped me get my workflow back in order. Many many thanks.

  • This seems like a great tutorial but I have got stuck towards the end. I got as far as “Confirming WordPress successfully authenticates to MySQL” at which point I checked which is my local domain. Instead of showing me the website as it should, it shows me a page titled “Index of /” followed by a list of all files and folders in the database. Do you know why this is or how I can fix this?

  • Sarah

    Thank you so much for this tutorial. I got all the way through and now have a working version of my live site locally. I am also having the 404 issue, after running the SQL query to change the urls. Luke mentions that he deleted the custom permalink structure in the wp_options table, but I do not know how to do this. Tips? Thanks again for a great tutorial!

    • Sarah

      Nevermind, I figured it out. Thanks again! Excellent tutorial! Now do you have any tips about how to set this up to auto-update to sync to the live blog?

      • Last time I checked, I couldn’t find any easy way to release or sync changes between deployments of WP. If there was an easy way, then ideally it would allow you to sync config independently of content, and vice versa (because you’d generally want to release new config from dev to live without overwriting existing content on the live site.) Maybe you could try searching the WP plugins, and let me know if you find anything!

  • Hi

    Great article. I have successfully completed except I used dreamweaver to copy the site from the server and started a localhost folder that way. I am seeing the home page with a 404 warning and all links are clicking through to the live site. I changed the database site and WP URLS accordingly, the 404 has gone and the home page is showing except that the links are now lead to a URL not found warning. Any ideas?

    • Where are the links going vs. where they should be going? By “should be going” I mean compared to the URL pattern on the live site which is working. What happens if you take a good URL from the live site and just change the domain to point to the dev site? Does it work, and does it have the same pattern as a generated link on the dev site?

      See the exchange with Luke some months ago for further ideas.

      • It should be going to the same pages as the live site, except as a dev site on localhost/’testsite’. Is the more normal looking URL important for finding dynamic pages/files? Also, I can find some related files on Dreamweaver like .xml and .js but not layout .php like header footer etc.

        • Also, will changing the localhost url in terminal change to URL for all you localhost sites?

          • Ok, nevermind. I removed the custom permalinks structure and the links follow. However, I still can’t locate the dynamic content to edit in dreamweaver.

          • Guest

            I am having the same issue. I can’t seem to get DW to resolve the dynamic content. Did you find a solution to this?

          • J_OLy

            I am having the exact same issue. No matter what I do, I can’t get DW to resolve the dynamic content and I can do no designing. Did you figure anything out?

  • David Dumonde

    Absolutely the best tutorial on a complex subject. Kudos, James! You saved me a lot of grief.

    Since my production site is running a multisite network, I ran into a couple of hiccups. Here’s how I solved them.

    As you point out in your tutorial, changing siteurl and home does not change all instances where the domain may be coded in the content. This seemed to be especially problematic with my multisite site, and many things were unexpectedly redirecting from my mamp dev site to the production site. My solution was to open the .sql file in a plain text editor (I used TextWrangler) and do a global find and replace to change the production url to the development url. That caught almost everything.

    The only place where I was still getting redirects was in the My Sites menu itself. Most of those links stubbornly clung to the production url, making it impossible to access the Network Admin area to manage Sites, Users, Themes, and Plugins. Redirects to these areas occurred even when entering the url into the browser directly. This had me stumped for a few hours, since I knew the database was clean, until I remembered that when you set up multisite, you are given code to paste into wp-config.php, which contains this code:

    define(‘DOMAIN_CURRENT_SITE’, ‘production.url’);

    Changing the production url to the development url eliminated the last of those pesky redirects.

    Hope this helps others running a multisite network.

    • Some great tips there, thanks for this David. I’ve added a link to this comment in the post.

    • David Dumonde

      A followup: I found an easy way to avoid having to change any of the urls in WordPress at all. I found a free system pref pane called Hosts ( that allows you to easily edit your hosts file. More importantly, it gives you a checkbox toggle to turn each entry off and on.

      Once I installed Hosts, I created an entry in my hosts file that redirected my production url to localhost ( I downloaded a fresh copy of my production database in a .sql file, and then uploaded it to my local database in mamp via phpmyadmin. So now my local database and my production database are identical, with both containing links to the normal production site url (

      Now with the entry CHECKED in the Hosts pref pane, entering in my browser takes me to my local dev site in mamp. With the entry UNCHECKED in the Hosts pref pane, entering in my browser takes me to my production site. Just one checkbox does the trick, without ever needing to change any of the urls in WordPress.

      Obviously, this could make it very easy to accidentally make changes to the wrong site, since the urls are identical and everything else about the site is too. I recommend making some small but highly visible change in the theme CSS ( body { border: 12px solid red; } ) on the local dev site only to make it clear which site you’re really viewing.

  • Pingback: The coffeechat's New Clothes - coffeechatwithperpie()

  • Ben

    I’ve created a blank database as instructed, then when I try to import the database that I downloaded I get an error:

    #1007 – Can’t create database ‘db394650295’; database exists

  • Pingback: Moving WordPress | seungchan moon()

  • Achille

    Great work, many thanks!

  • Pingback: FredrikOlsson <> Installing WordPress Locally()

  • Rich Breen

    This is really great! Thank you so much – in about an hour I was able to get everything up and running locally with the exception of a few broken image links which I’ll sort out.

    For some reason though, I’m unable to get to my admin panel; I see the wp-admin folder inside my wordpress folder, and the index.php file is in there, but when I go to ‘’ I get an “HTTP error 500 (internal server error)”. Any thoughts?

    thanks again,

    • Any HTTP 500 error you see displayed should have a corresponding detailed error message in the web server’s error logs, so look there to find out what the real error is.

      • Rich Breen

        Not much detail: “HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.”

        any thoughts?

        thanks again!

        • Rich Breen

          Here’s the line from the PHP log:

          “[03-Jul-2013 16:46:17 UTC] PHP Fatal error: Call-time pass-by-reference has been removed in /Users/rich/hosting/docroot/wordpress/wp-content/plugins/add-from-server/class.add-from-server.php on line 137”

          Really appreciate any ideas you might have.


          • Rich Breen

            doh! Sorry to bug you, and thanks for your help – I figgered it out; removing the ‘add-from-server’ plug fixed. Thanks for this great post again!


          • Cool 🙂

          • Rich Breen

            Yeah, now I know how to read a PHP error log…
            I see you’re a guitar player too – I’m a recording engineer; let me know if I can ever answer any questions in kind…

            Appreciate your help


  • Pingback: Moving WordPress to a new domain ← Big Messy Tech()

  • Christoffer Ahlbäck

    I’ve tried this now, but I still get a blank page when I try to access my now local site..!
    I’ve gone through all the addresses in the database and changed them to the new address, and everything looks okay to me. After all, I’ve followed these quite easy steps. What’s wrong?

  • Pingback: Как скопировать живой сетевой Wordpress на локальный компьютер? | Лучшее - враг хорошего()

  • Besty

    This is a really good tutorial with a great level of detail, helped me very much. Thank you!

  • Most excellent. Thanks!

  • Boris Kamp

    Great tutorial! thank you very much!
    Do you happen to have a tutorial about exchanging the WP site as well between local and live?
    So lets say I completely change the website offline with MAMP (what im gonna do) how can I easily get it back online on my real live website?


    • Cheers Boris – if you don’t mind entirely overwriting the live site then that should be straightforward: just do the same thing in reverse and copy the database and docroot files back over. But if the live site has changed in the meantime, i.e. there’s new content and you don’t want to overwrite that when you release the revamped website, then I’m not aware of a really simple/automated way to do this; I usually end up just making the same changes again in the live site, so it’s a mostly manual process. Let me know if you find a better solution.

  • Alexis

    A million thank you’s for this excellent guide!

  • Alberto

    Thank you so much, detailed and simple! Just a remark, on my MAMP installation I had to define the DB_HOST variable as “localhost” because with “” I was still getting the DB connection error. Maybe because after defining in the hosts file the “dev-site” as it was then translated as “dev-site” inducing the error for mysql?

    Anyway a small hiccup, solved rather quickly, so thanks again!!!


  • mitiko

    thanks so much! with enough patience and intuition, finally got it to show as a locally hosted site

  • RestoreYourHouse

    BIG thanks for a well thought out, step by step logical post that even someone with no WP or server knowledge could follow (such as myself). One hiccup however that I’d be most grateful should someone figure out (I suspect it is trivial to most who comment here) is fixing URLs. After doing all of the above fixing URL suggestions, both in this post and in referenced links, and running interconnect/it, the “” site can only be accessed by typing in the URL in the browser. Bringing up the “” site and clicking on any links still takes me to the production “” site. But if the URL is modified to reflect “” then the page can be accessed. Any insight appreciated, and again, many thanks!

    • Do you have the correct URLs in Settings → General → WordPress Address (URL) and Site Address (URL) in the dev site? If so, then at least the links generated by WordPress itself should be correct.

      • RestoreYourHouse

        Thank you James, a big thanks. Quitting the browser and MAMP, rebooting the laptop; then the links worked. The odd thing is though, that prior, all images on the dev pages looked fine. Once the URLs were changed, many (but not all) of the images now are little question marks. I then reinstalled the DB, put in the correct URLs, same thing. Believe the first issue was remedied by the quit and reboot (the issue had nothing to do with your excellent instructions). Now puzzling over how to remedy the images.

        On a side note, I see you like color. Here is a favorite app you may wish to visit:

        thank you again

  • Mauri Garay

    This is by far the most detailed tutorial i’ve found. I’m getting the white screen though when i try to go to or I can access but that’s it. I hope you know a solution please

  • StefsterNYC

    This was a great tutorial. I unfortunately got an error when importing the existing DB and for some reason none of the pages or posts are not showing. Anyone have any idea?

  • WordpressQueen

    James – everything worked great except for the final step –
    Fixing the WordPress URLs – this does not seem to be working and still redirects me to login at the original website. Any ideas?

  • digg

    Very useful guide James! Very clear and detailed. My local installation is up and working perfectly following these steps. Thank you!!

  • patrick

    fantastic guide even if I have an empty screen when i try to point on it on local

  • clausfrovin

    Really excellent and detailed guide. Thanks a lot! However, my page still doesn’t work offline. I get the message “Error establishing a database connection“. I have tried all your solutions a couple of times, still with no result:-/ I have tried to install a fresh copy of wordpress and it works, so my MAMP apache and MySQL servers seem to work fine and the database from my webpage (clausfrovin_com) has been imported successfully.

    This is my settings in config.php:

    /** The name of the database for WordPress */
    define(‘DB_NAME’, ‘clausfrovin_com’);

    /** MySQL database username */
    define(‘DB_USER’, ‘root’);

    /** MySQL database password */
    define(‘DB_PASSWORD’, ‘root’);

    /** MySQL hostname */
    define(‘DB_HOST’, ‘localhost’);

    Any suggestions what to do now?

  • Aaron Riddle

    Excellent tutorial! Thank you for the detailed walk-through.

  • arif uddin

    man this is such an amazing tutorial. the one and only in the whole world. none of the tutorial in youtube and online blog could ever plain how it work. finally i can see my wordpress site in my dreamweaver now.

    just could not understand how to deal with the link

    update wp_options set option_value=””
    where option_name=”siteurl”;

    update wp_options set option_value=””
    where option_name=”home”;

    since I am using LOCALHOST/MYSITEFOLDER this part of the tutorial doesnt match with mine. but still this is the greatest ever tutorial on how to edit/modify/setup wordpress in local computer (as well as in dreamweaver)

  • digg

    Hi, just a note about the SQL command to fix the links in database:

    When importing in local phpmyadmin the exported database from live site, usually the tables inside the database comes with a prefix “WordPress######_” or similar.
    You have to adjust this adding your prefix in the sql lines in order to make it works (otherwise you’ll get an sql error).
    It will look like this:

    update WordPress######_wp_options set option_value="YOUR_local_WordPress_Address"
    where option_name="siteurl";

    update WordPress######_wp_options set option_value="YOUR_local_Site_Address"
    where option_name="home";

    I hope it helps, I always forgot this when doing a new local install 😀

    • Matt Kornegay

      I did this manually by going to the wp_options table. I believe the writer forgot to add the database name in before the ‘wp_options’ query because I got an error of the wrong syntax. Or, this is such an old post that there have been changes to the syntax since this article was written.

  • shrnchn

    Thank you for creating this guide! SO HELPFUL!

  • I build that will handle that and much much it offers two solutions a terminal script app and a web app. Both will get latest wordpress and installed it and configure mamp to map and create your lcoal host here is the link

    • Matt Kornegay

      I downloaded and ran your web app. It is not working properly. After entering in the required info I get an issue with it unable to connect with the localhost. I am using FF.

      • are you running MAMP in port 80 or 8888?

        • Matt Kornegay

          I’m running 8888. MAMP Defauts. If I enter localhost:8888 it works, but this causes a problem with the setup for WP Install not to work properly. I will send screenshots to your email.

          • i have created a landing page for the app with clear instructions and fixed minor bugs in the couple weeks give it a try and let me know if your issue has been resolved

          • sorry for the late response, i have created a landing page for the app with clear instructions and fixed minor bugs in the couple weeks give it a try and let me know if your issue has been resolved

  • Matt Kornegay

    I have a problem. I’ve done everything said and though I had a couple of issues I am able to login to my back end locally. I can even pull up my site. However, when I click on any of the page links within my site (other than HOME), I get a 404 Error.

    Not Found

    The requested URL /terms-agreement/ was not found on this server.

    I even did a search and replace through all my DB Tables in order to remove instances of the live site url and replace with the local host. I’ve had to do this with site transfers in the past so the the generated strings attached to the DB tables are replaced properly with creating broken links.

    I have the live site copied to my hardrive (or I wouldn’t be able to view it within my browser locally). So does anyone have a suggestion of what’s wrong?

  • Seriously, thank you so much!

  • Alex

    Thanks very much, James. Could you explain how to use another port other than 80? I’ve developed other sites from scratch using 8888 to avoid having to log in each time. I can only view my copied site when I change it to 80, though my other sites are no longer available.

    Could you tell me where to configure the imported site to use 8888 instead?

  • Devin Connor

    I know this is from ages ago, but I’m having issues as I don’t have a login for any host UI, and have to work off FTP. how do I go about getting the database without access to PHPmyadmin?

    • I believe MySQL has a command-line interface.

      • Devin Connor

        So I’m pretty new to all this, would you know of a good tutorial for that process?

  • Wei Wang

    I followed the steps strictly but still get “Safari cannot open the page because it could not cannet to the server” My URL is set as and in my server.xml file I set the port for https as 8443. I also set 8443 as port in SquidMan and the my mobile device http proxy settings. Anyone can help? Thank you.
    Mac: OSX 10.11 SquidMan 3.1 iOS 9.1

  • WordPress looks very easy to handle but seriously security risks are way too high to deal with. Hackers just got in very easily in my blog, destroying my database. .