Test Major WordPress Changes Without Melting Down Your Website

Have you ever seen some cool new thing that WordPress can do, either natively or with a plugin, and as soon as you try it you’re locked out of a broken website? And of COURSE, you used a staging server or something, because who would try something like that on a live site? Well, I would, and I’ve broken my site and spent hours figuring out what broke and how to make it right.

This post is about never doing that again.

What is a Local Testing Environment?

If you’re someone who has a fairly normal, non-customized WordPress site on a commonly used host, you know that they provide a web server for you and there’s a database in that mix somewhere.

A local testing environment is like having a server, except on your own computer. It allows you to make changes to your site and preview them, without affecting the live site. Fortunately in this day and age, setting up a local testing environment is as easy as downloading a program and installing it — you don’t even need a system administrator.

Once you have the system set up, you can create and destroy as many WordPress sites as you want, testing things over and over again, without jeopardizing your live WordPress site.

Why Should You Use a Local WordPress Testing Environment?

1. Better Safe Than Sorry.

If your site provides any kind of value to you, you’ll want to keep it available to visitors. When installing a new plugin, theme, or even a new version of WordPress without testing it somewhere else first, you run the risk of your site crashing utterly.

2. Stage It and Go Live.

Some (not all) local test environments have integrations with your live server, allowing you to make changes on your own computer and push those changes automatically to the live server. This gives you a staging site, and you’ll never have to do the same thing twice before going live.

3. It’s so Easy, Anyone Can Do It.

Installing a local environment is simple and painless. Given that, why not spin up a test server and test out your site?

Choosing your Local WordPress Testing Environment

There are two popular, mainstream local testing apps available to download for free. Let’s take a look at both options and see which app is the right fit for you.

DesktopServer by ServerPress

Our first testing environment option to explore is DesktopServer. There is a free version and a premium membership version available. The free version works perfectly fine for simple testing, and the paid version has advanced tools for developers like WordPress multisite support, internet sharing for easy collaboration, easy live deployment, and more.

DesktopServer comes with a number of add-ons including Airplane Mode, so you can browse locally without an internet connection. You can also make the admin bar change color locally, so you don’t get confused about whether you’re looking at local or production and do something terrible by mistake. DesktopServer’s add-ons all come included with the application.

Finally, it is important to note that DesktopServer runs its services as local applications. This means Apache and MySQL will run as normal programs on your computer, so you can add multiple local WordPress sites without slowing your computer down. With Local by Flywheel your computer will become quite slow after you create 10 sites or so.

To get started with DesktopServer, simply download the file from their site, double-click it, and it will install everything you need. This process might take a little time, so be patient.

Once installed, select “Yes” to Start Apache and MySQL services. Apache is the web server that serves pages, and MySQL is the database that holds your content.

Now you are ready to create a new development website.

Additionally, one of the great features of DesktopServer is that it can import a backup file from most common WordPress backup plugins. For example, if you use BackupBuddy from iThemes, in the screenshot below you’d choose “Export, Import, or share a Website”. From there, you could upload a recent backup of your site and you’d immediately have a clone of your site, running locally.

Local by Flywheel

Next, we’ll take a look at Local. Local is a product owned and released by a web host called Flywheel, but it works with any site and any host. It does have some custom integrations with Flywheel that you can take advantage of if you host there.

Here’s what Local looks like:

To install a new WordPress site in Local, start by clicking the green plus sign in the white circle in the bottom left. You’ll be asked for a site domain name. I used local-store for my site. Then click Continue.

Next, we choose our hosting environment. Unless you know what you’re doing I recommend simply choosing Preferred. Then click Continue again.

After choosing your hosting environment Local will ask you for a WordPress username, password, and email address. Enter those and click Add Site.

After you’ve clicked Add Site, Local will finish installing and configuring WordPress for you. You can click View Site in the top right of the Local panel.

I mentioned above that DesktopServer runs as a local application. Local is different because it creates a virtual machine and installs Linux on it, in addition to the web serving applications.

Local also has a number of excellent add-ons created by their community. They allow you to craft your own workflow and extend the testing capabilities in your set-up. You can review the available options on their site and install them here.

Which Do I Choose?

Both DesktopServer and Local are excellent products, with free versions and support provided.

As a developer, you’ll also be happy to know that both DesktopServer and Local come with Xdebug options built in, and there are docs on how to integrate your favorite programming tool. They also both come with ngrok, so that people outside your local network can view the site you’re working on if you give them your secret URL.

If you install more than a few websites, then DesktopServer is going to be faster because it runs its applications natively. Alternatively, Local might be a little more like your real production server because it’s running inside a Linux container.

Given that both local environments are free, I would really recommend trying both and see which suits your workflow better. They both have far more features than I’ve mentioned here, so I recommend reading through their feature set as well.

How to Set Up A Local Server For Testing

Copy Your Production Website to a Local Copy.

The best way to run tests on your WordPress website is to set up a local server (right on your own computer) and copy your production website into it. Then you can try things, break things, and rebuild easily for more testing.

I’m going to show you how to set up a local server for testing with DesktopServer from ServerPress. Here are the steps we’ll follow:

1. Install the “All-in-One WP Migration” plugin on your production server.
2. Export the production site to a file, and save it to your computer.
3. Use DesktopServer to create a placeholder website on your own machine.
4. Install All-in-One WP Migration into your local site.
5. Import your production site to the local server.
6. Create a blueprint of the local install for easy restoring.

Step 1: Install All-in-One WP Migration on your production site.

In your WordPress admin area, you can click the Add New menu item under Plugins, or go to the main Plugins page and click the Add New button at the top.

Next, search for All-In-One WP Migration, and it should come up as the first result.

Note: Duplicator is the second result and would work just as well, so feel free to experiment if you don’t like All-In-One.

Click the Install Now button in the search results. Once the install is finished the button label will change to Activate. You must click this in order for the plugin to work.

Step 2: Exporting Production.

Once the All-In-One WP Migrations plugin is activated you’ll see a menu item for it in the left column of the WordPress admin. Under that menu item click Export. Then click the Advanced Options link and check off Do not export Spam comments and Do not export post revisions. Those are things you should never need for this testing.

Then click Export To and choose where you want to put the file. For this demo, I’m choosing File and saving it to my computer, but as long as you can access the file it doesn’t really matter where you choose to save it.

Once you click File, you’ll see a progress box, and then offer a box where you can download the exported file. Save it someplace safe and we’ll come back to it in a few minutes.

Step 3: Use DesktopServer to create a placeholder website on your own machine.

For this step you need DesktopServer installed. Earlier we covered some basic instructions, but you should also review this excellent documentation on their site.

Once DesktopServer is installed, choose Create a new development website.

For Site Name, you may make up any valid domain name formatted string. I’m using local-store, but you could use any variation of your real store URL. Because our local domain will have .dev.cc at the end you’ll never have a domain name collision.

The only other thing you need to do on this screen is click the Create button.

It usually takes DesktopServer about 20 seconds to completely install the WordPress software and set up your new local domain name. Once it’s done, click Next.

You’ll be presented with a URL to finish the setup of your new WordPress site.

Note: This site we’re creating is going to be completely replaced by our production import, so things like site name, username, password, etc. are really irrelevant. We’re going to log into this site once, then import Production and all of this will be replaced.

Now that your site configuration is done, go ahead and log into your new local WordPress site.

Once logged into your new site, please make note of the admin bar at the top. It should say DEVELOPMENT WEBSITE.

Step 4: Install All-in-One WP Migration into your local site.

In your new local site, we’ll follow the same steps for Production to install All-In-One WP Migration.

Step 5: Import our production site into the local server.

Once All-In-One WP Migration is installed, you’ll find an Import menu item in the left admin menu. Browse to the file we exported from your production site and begin the import.

You’ll now see notices from several pop-up boxes. One will remind you that the current site you just created is going to be completely removed and replaced with a copy of your production site.

Proceed and you’ll see a progress bar and then a note telling you to save Permalinks twice.

Important note: Now that your local site has been replaced with your Production site, you’ll need to use your Production username and password to log into your local site. The temporary one you created just a few minutes ago is gone.

When you click the Permalinks Settings link, it will prompt you to log in to your site.

Once you’re logged in you might see a prompt to update your database. Go ahead and click it. It’s okay if you don’t see this prompt, it simply means your database is already up-to-date.

Now that your WordPress database is updated, go to Settings → Permalinks and at the bottom of the page, click Save Changes twice. This switches all the links in your local site away from links to your production site.

At this point we’re done migrating the site, you can see the local URL in the browser location bar and your Production site under your local Admin bar.

Step 6: Create a Blueprint.

A blueprint is simply a saved configuration, like a template. It makes it so you can reload all your settings at once, without having to arduously go through them manually every time.

One of the specific purposes of creating a local testing site is to break it and break it often. You want to be able to get back to your stable starting point as quickly as possible, so we want to take what we have right now and save it.

The DesktopServer website has excellent instructions on how to make a Blueprint of your current local site.

When you break your local site, you may either remove it and create new, or make a second local version. Selecting “Create Site” in DesktopServer will give you the option to choose a blueprint. Simply choose it, install, and you should be right back to where you want to be.

Configure Your Local WordPress For Testing

Often when your site breaks it won’t tell you what’s wrong. WordPress is famous for the White Screen Of Death, where you simply get a white screen with no information at all. It can feel quite scary because it looks like you’ve lost everything. Fortunately, that’s almost never the case.

In this section, we’ll take a look at how to make WordPress give you all the information you need when it breaks.

Turn On Debugging

For this step, we want to edit a file called wp-config.php. It’s found in the root folder of your WordPress site. In Windows you can find your local WordPress files in c:\users\{system username}\documents\websites\ and on a Mac you can find them in Documents/Websites/. Go into the folder that has the name of your local site and you should see a list of files and folders that start with wp-. Find wp-config.php. We’re going to open and edit this file. If you don’t have a good code editor, I recommend Sublime Text, but any text editor will do.

Near the bottom of your wp-config.php file you’ll find a line that mentions WP_DEBUG.

If you don’t see a line in the file with WP_DEBUG, that’s fine. Just add it in instead of replacing the existing value.

Replace the WP_DEBUG line with these 4 new lines:

define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, true );
@ini_set( ‘display_errors’, 1 );

The first item turns on debugging. The second tells WordPress to try to write errors to a log file, wherever your system logs things. The third is the real gold — it writes the errors to the screen in the browser. So when it breaks, it will tell you in great detail WHY it broke, what file broke it, and on what line you can find the offending code.

Now when something breaks in WordPress, you know what it is, and how to fix it. You don’t want these debugging tools turned on in Production unless you really can’t help it. There’s no need to tell the world where things are broken in your site.

Once you’re happy with the way things are set up for debugging, don’t forget to add your wp-config file to your Blueprint. There are some excellent documents available on how to do that.

Conclusion

The more you value your website, the more you should value quality testing. Experimenting with a personal blog is one thing. Risking your entire store is another thing altogether.

If you ever want to test something on a website again, don’t do it in production. Someday you’ll be sorry, I promise. We talked about two excellent options for testing your websites locally, right on your own computer. They’re fast, free, and easy to use. You can do this.

Once you have your local server setup then you can really begin to test things. Don’t be afraid! Do all the terrible things the web tells you not to do so that you can experience them and understand how to recover quickly. Then when it happens in production, you already have experience and can recover quickly there too.

I can’t stress enough the value of experimenting on your local server. It will make you a better site owner and provide a whole new level of knowledge and confidence.