How To Setup A WordPress Development Server

You should have a development environment for every live WordPress site you own or work on.

You'll hear terms like "staging site", "local server" or "development environment".

Yes there are often nuances between them, but basically they're just a copy of your live site.

You really should have at least one copy of your live WordPress site. This is where you test any updates or play around with new plugins or themes.

Once your site goes live, that should be the end of testing on that server.

Sometimes it's unavoidable, due to overly restrictive plugin developer licensing situations. But in any other case, just build a clone somewhere.

How to setup a WordPress Development Server:

  1. Setup your local environment
  2. Install WordPress
  3. Install a good text editor
  4. Install a testing suite
  5. Create a git repository
  6. Connect your development folder with git
  7. Start developing

Definition of terms

Others might use these terms differently, but I typically think of four different types of setups:

Live Website

The Live Website is the one attached to your domain. It's the one the public visits and that goes on your business cards.

Staging Site

The Staging Site is pretty much an exact copy of Live Website. It will often be on the same host (as an Addon Domain). But it might be on a different host.

This will be your last testing place to make sure everything's going to work on the Live Website.

The Staging Site will usually be accessible to anyone with an internet connection. You'll block search engines from seeing it. You might also put it in "Maintenance Mode", so only logged in users can see the site.

Local Server

A Local Server, in this context, is a copy of your WordPress site that sits on your computer.

It is great for rapid testing. No one will ever see it, so you can play with concepts and break things without fear.

Local Servers are free to setup and usually low on disk usage.

If you've got a Local Server setup on a laptop, you can work on your website from anywhere in the world, without worrying about an internet connection.

Then when you're ready, you just roll out those changes to the Staging Site, then the Live Website.

Development Environment

A Development Environment will often be the same thing as the Local Server.

Depending on what site you're building, you might have a separate Development Environment that has testing tools (like PHPUnit) installed.

What types of development servers should you have?

The exact setup you go with for a project depends on how many people are involved, how big the project is, and how much custom programming you'll be doing.

If I'm working on my own projects, I'll usually have the Live Website with a Local Server on my desktop.

If you're working with a client, you'll need a Staging Site as well.

On my bigger projects, I'll have all four. Yes, two copies of the website on my desktop. One with testing tools and a connection to GitHub repositories.

Setup your local environment

The "local environment" is the set of files and folders on your computer that allow WordPress to run offline, as well as the databases.

There are a number of different options for your local environment.

Some of the more popular ones are WAMP, MAMP and Local by Flywheel.

For years I've used XAMPP. It's free, open source and gets the job done. It's available for Windows, Mac and Linux.

Install WordPress

If you're starting from scratch, then install a clean version of WordPress.

Otherwise, install WordPress from a backup. Basically, migrate the site to your local environment.

Install a good text editor

You can get away with just using Notepad++. I did that for years.

That was until I discovered Atom. It's free, open source, works on Mac, Windows & Linux, and you can get it here.

You might prefer a more complete Integrated Development Environment ("IDE") like Visual Studio or PHP Storm. I just find Atom to be lightweight, intuitive and so easy to use.

We'll also be using the easy git integration in a later step.

Install a testing suite

If you are developing a WordPress plugin or theme on this install, you need to have a testing suite.

If you're just doing a bit of theme customization, you can skip this step.

As someone who resisted learning Test Driven Development ("TDD") and Behavior Driven Development ("BDD") for way too long... just take a day to learn it. It will save you huge amounts of time.

For WordPress development on a local environment, you should install the free testing suite Codeception, which you can get here.

Codeception is built on PHPUnit, and has an easy to use system for unit tests and acceptance tests.

If you don't already have Composer, get that setup first. That's available for free here.

If you're on Windows, you should also install ConEmu for running the tests. You could do it just in the standard Windows Command line if you had to. I just like that ConEmu allows you to have color coordinated responses.

Create a git repository

Whether you're customizing a child theme or building your own plugin from scratch, it's a very good idea to use git to keep track of your progress.

The main reason is so you don't keep lots of copies of a folder "just in case" you change your mind on some changes.

You can always go back and see what you changed when.

There are two main options for this. You could use GitHub or BitBucket.

Almost all of the time you'll be using Private Repositories.

For a long time, you had to go GitHub Pro (for $7/month) if you wanted to use Git. They changed that in January 2019. Now the free version does what we need.

Some organizations prefer BitBucket, primarily because the free version allowed unlimited private repositories. But now GitHub has that feature, we'll just use that in these demos.

Sign up for the free plan of GitHub, if you haven't already.

Once you're logged in, click "New" to create a new repository.

The repository is where we'll store our project files.

Be sure to call the repository something obvious for the project.

You'll be setting the repository to private, so only you and any team members you give access to will ever see this. There's no need for secrecy or ambiguity in the naming.

Make sure you set the repository to Private. You can always make it public later if you want.

A public repository is available to the whole world. Open source projects should be made public, but not the inner workings of your client or early development projects, in my opinion.

You can add a description if you like. I don't usually bother, because it's just for me and my team, and we know what it is from the name.

Click "Create Repository".

That's it for the GitHub side of things.

When you have files in the repository, they'll show up in the Code tab. But until then, you get a helpful list of commands.

The commands I use are a little different, but I'll go over them in the next section.

Connect your development folder with git

While you could connect your entire install with git, this is overkill. Every time any of your plugins gets an update, you'll be storing a copy. That will get bloated very quickly.

Since you'll likely only be working on one theme or plugin at a time, just connect that folder with git.

For this demonstration, I'm imagining working on a child theme. Since I generally use GeneratePress, I'll be using a child theme for that (which you can see the creation in an earlier post here).

With the child theme installed and activated, the /wp-content/themes/ folder looks like this:

Inside /intelliwolf-gp-child/ we have these files:

This is while we have the basic child theme setup, before any development work is done.

Now that everything is ready in the website, pull up the command prompt.

If you don't already have git installed on your computer, I recommend you go here, follow the prompts and install it.

On Windows 10, go to Cortana in the taskbar, type CMD and choose "Command Prompt". On Mac, go the terminal. And on Linux, you already know :)

Navigate to the development folder using cd /folder/ replacing /folder/ with the path to your specific folder.

For my example, I used the command:

cd c:/htdocs/dev/wp-content/themes/intelliwolf-gp-child/

The following are the commands, in sequence, that I use to connect my development folder with GitHub. Hit Enter after each command. Anything in parentheses is something you need to do, not type.

  1. git init
  2. git add .
  3. git commit -m "Initialize"
  4. (enter GitHub password)
  5. git remote add origin [email protected]:mikehaydon/example-project.git
  6. git remote -v
  7. git push origin master
  8. (enter GitHub password)

In practice, that looks like:

The child theme folder now has an additional folder called .git:

Start developing

Now you're all setup and ready to start developing.

You won't need to install the testing suite or text editor in the future, which will make the process a lot quicker.

When you make any significant changes, you'll commit them to git, so you can track them later.

Let's open up the folder in Atom and start developing.

Go to the /themes/ folder, right click the child theme and select Open with Atom.

You'll see a project with your files on the left. Opening, say functions.php will show something like this.

This is the "One Dark" Atom theme.

For this example, I've changed the white to red in the palette (see this post for the code used).

When you hit save, the file you changed gets a color change in the file list. This makes it very easy to see what has changed since the last commit.

I have the git-diff and github packages installed in Atom. I think they're installed by default. If not, go to File->Settings->Install and install them.

When you're ready to commit the changes, hit CTRL+9 to pull up the Git sidebar.

Click Stage All.

Write a brief note in the Commit message area about what changed.

Click "Commit to master".

You don't have to push to GitHub every time you make a commit, but if you're leaving your work for a bit, it's best to click "Publish" in the bottom toolbar.

There will be a popup asking for your GitHub password. I've tried many things to not have to enter it, but it's still requiring it. Apparently that's not an issue on Macs.

After Atom has uploaded the files to GitHub (which is the same as git push), the Publish item will change to Fetch.

Just repeat those steps. Make changes, commit, rinse and repeat. Publish as required.

So this was how I setup my development server for WordPress. There are many variations and ways other developers do it. Find the steps that work for you. Hopefully this helped simplify your search.

Leave a Comment