How To Set Up a Local WordPress Environment Without Using a Plugin

The first step in any new project should always be to set up a good local development environment. Editing directly on the live server is not only dangerous (you’re pretty much guaranteed to mess things up where people can see them!), but it’s also a pain in the butt. You have to upload files every time you make a change in order to see the effect.

Staging environments are pretty handy too. That’s where you can test out all your code on an almost live environment and see if you run into any new bugs that you weren’t seeing on local. They’re also a good way to show progress to your clients.

Chances are, you probably knew all of that already. Otherwise, you wouldn’t have gone searching for an article titled, “How To Set Up a Local WordPress Environment Without Using a Plugin.” So let me get to what you’re looking for…

How to Create a Local Version of Your WordPress Site

Step 1.) If you haven’t already, install WordPress on your live server, using your live URL. In this example, that will be

Step 2.) Log in to your live server via SFTP or FTP and download everything from the folder where your site lives, including all the subfolders and their contents. This will take a while.

Step 3.) Export a copy of your MySQL database. It depends on your host, but chances are that you’ll use phpMyAdmin for this, so we’ll assume that for the rest of this tutorial.

Step 4.) Create a local MySQL database and import that dump into it. The local database does not have to have the same name as the live database.

Step 5.) Assign a virtual domain name to your localhost folder. In our example, that is http://example/. This is important so that you can use relative paths (both in your code and in the HTML you post inside of WordPress) and have it work in both environments. For example, /wp-content/uploads/2018/10/image.png works whether we’re on the live site or on local, when we have things set up this way.

Step 6.) Open up wp-config.php on your local machine and search for these lines:

/** The name of the database for WordPress */
define('DB_NAME', '(your live database name)');
/** MySQL database username */
define('DB_USER', '(your live database username)');
/** MySQL database password */
define('DB_PASSWORD', '(your live database password)');
/** MySQL hostname */
define('DB_HOST', '(your live database host)');

Step 7.) Replace those lines with this:

if ((!empty($_SERVER['HTTP_HOST'])) && ($_SERVER['HTTP_HOST'] == 'example')) {
	// this is your local development site
	define('DB_NAME', '(your local database name)');
	define('DB_USER', '(your local database username)');
	define('DB_PASSWORD', '(your local database password)');
	define('DB_HOST', 'localhost');
} elseif ((!empty($_SERVER['HTTP_HOST'])) && ($_SERVER['HTTP_HOST'] == '')) {
	// this is your staging site
	define('DB_NAME', '(your staging database name)');
	define('DB_USER', '(your staging database username)');
	define('DB_PASSWORD', '(your staging database password)');
	define('DB_HOST', '(your staging database host)');
} else {
	// this is the live site
	// you don't need to define WP_HOME and WP_SITEURL because WordPress pulls them from the database
	define('DB_NAME', '(your live database name)');
	define('DB_USER', '(your live database username)');
	define('DB_PASSWORD', '(your live database password)');
	define('DB_HOST', '(your live database host)');

Note: You can just comment out the staging part if you’re not ready to set that up yet.

Step 8.) Navigate to http://example/ in your browser. You should see a working copy of your live WordPress site, but at the local URL! Yeehaw!

Note: If you get redirected to the live URL, you might have to edit your .htaccess file.

How to Create a Staging Version of Your WordPress Site

After setting up your live and local sites, it’s time to set up your staging environment.

Step 1.) To start, create a new subdomain through your web host with its own folder. (Don’t have the subdomain point to the same folder as the live site!)

Step 2.) Create a new MySQL database.

Step 3.) Go back and add your staging URL and database info to wp-config.php. (See code above.)

Step 4.) Log in to your server via SFTP or FTP and upload everything from your local site to your staging site folder, including all the subfolders. Again, this will take a while.

Step 5.) Open up phpMyAdmin on your local machine and export your database. Important: Check the Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER statement checkbox.

Step 6.) Log in to your staging database via phpMyAdmin, double check that it’s your staging database and not your live database, and then import the file you exported from local.

Step 7.) Navigate to in your browser. You should see a working copy of your live WordPress site, but at the staging URL! Woohoo!

How to Upload Your Local WordPress Site to Your Live Server

You’ve tested the site on staging and it looks amazing. It’s time to share it with the world. Here’s how:

Step 1.) Log in to your live database via phpMyAdmin, and export everything as a backup in case things go wrong.

Step 2.) Upload all the files that you modified from local back to the live site via SFTP or FTP.

Step 3.) Import the same export from local that you imported into the staging database.

Step 4.) Navigate to in your browser. You should see your live site with all of the recent changes made. Yippee!

Final Notes

Make sure to use relative URLs (starting with a slash) and not full URLs! Otherwise, you’ll bounce users from one environment to another. Not good.

For SEO reasons, you should block robots from indexing your staging site. You can use a PHP if statement to add a noindex meta tag to pages on the staging site, or you can serve up a different robots.txt on staging via .htaccess logic. Either way works.

Double check your URLs before exporting/importing database files! Bad things will happen if you don’t.

In all of this, you’ll have to watch out for file permission errors. You might need some CHMOD magic to get everything to work.



This article was published on July 11th, 2018 by Robert James Reese. Before using any of the code or other content in this post, you must read and agree to our terms of use.