Why Staging Environments Are Critical for WordPress Sites

By Jeff Smith
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

This article is part of a series created in partnership with SiteGround. Thank you for supporting the partners who make SitePoint possible.

Have you ever thought about the way you organize your WordPress development? Do you use version control? How about staging environments?

The WordPress Development Process

The advent of WordPress – one of the most consumer-friendly content management systems ever to exist – has created a different kind of development model. The accessibility of WordPress, and pre-made themes and plugins for it, allows web developers to quickly and easily create sites when requirements are low.

But it goes further than that – some of these developers don’t fully understand the languages on which the platform and their plugins are built (or understand it at all). When considering run-of-the-mill PHP or JavaScript developers, for example, many still don’t practice proper programming techniques, using things like tests, separate environments, or version control. Now, consider that the development of a simple WordPress site can be done by someone with far less training or experience (or done by a veteran programmer with the goal of being hasty). The percentage of cut corners in terms of security and maintenance concerns almost certainly goes up.

Bearing all of that in mind, the final nail in the proverbial coffin is the fact that WordPress updates and maintenance can be done so easily from right within the platform. The ability to update the platform or almost any plugin in place is fantastic, but it also means that “Cowboy Coding” – making changes directly on the live site – is very convenient and very tempting. That is, until disaster strikes.

About Staging Environments

The life cycle of many WordPress websites begins in a separate development environment in which it is built (hopefully it isn’t being built right in a live production environment). Once built, it is migrated to a production environment. And that is where things can sometimes fall apart.

What if the live, production hosting is slightly different than the dev environment, is missing some dependencies or software, has different versions, etc? Or what if updating a plugin causes the site to crash? What if a theme update breaks your child theme and you can’t immediately diagnose what is wrong?

These problems can be often prevented by using staging environments, which are often overlooked by WordPress site managers, yet are just as important for them as for other web platforms.

Setting up a Staging Environment

The goal behind setting up a staging environment is to set it up to be as identical to your live production environment as possible. Use the same hosting service, or the same kind of VPS. Mimic the live environment as closely as possible. use the same WordPress version, the same plugins, and the same configuration. One neat tip would be to use a backup/migration plugin to create a mirror copy of your website when it is first created (or do so now, if you have an existing site but no staging environment) so that the two are identical to start. Then, you can set up a subdomain (or another domain altogether) to access the site, such as staging.example.com.

Once you have the staging site, using it is simple. Any time you want to make changes on your production site, simply make them to the staging site first. Look for major issues when updating themes or styles. Test for problems in functionality when updating things like carts or other more detailed plugins or custom code. Ensure that permalinks are still working after a change. When updating the WordPress platform and plugins, do them here first as well. That way if something goes wrong… you can catch it before it’s on the site that everyone actually cares about!

Choosing Hosting

You’ll want to choose a host that accommodates your needs. For those of you who are familiar with web server management, spinning up a second VPS when you have need of a staging site is an adequate solution. Depending on how often you make changes, you could even shut it down and save some money while you’re between development cycles!

If you have shared hosting, you’ll be looking for a host who provides this sort of thing out of the box, to avoid having to set up two mirrored shared hosting accounts or packages. Some web hosts provide this kind of functionality as part of their hosting package, and it’s ever so easy to use. Our hosting provider such as SiteGround does this, and they have a tutorial that will walk you through using their staging environment, if you’re interested. We’ve also just published a tutorial on keeping your development and live WordPress environments synchronized.

Regardless of your situation, if you aren’t using a staging environment to try out your changes before they hit production – get started doing that today!

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Olena Nika

    It is indeed a very informative article and the word ‘critical’ took my attention in the first place. I have some experience of working on projects where we used WordPress. Before we were introduced to staging concept, we were highly in a situation where dev and business people fight on the deadlines and delivery. According to the tech guys, code words well on localhost (which is their preferred mode of testing the code), whereas, when the code is pushed to live server, it messes loads of thing. Staging environment is certainly a great solution for all size of businesses and coders. I now prefer staging environment even for small piece of code changes, plus when we get a reliable hosting solutions with WordPress, life becomes easier.

  • Alain Gaston

    If I host my site on staging environment, does Google crawl it?

    • Jonas

      First Google have to find it. But i recommend ticking “discourage search engines from indexing this site”in general settings, which will set meta robots to noindex, nofollow, in other words, no serious search engine like Google will crawl.

      For more sensitive stuff you can always set a htaccess passord protection or deny access to all ip adresses by default or something to prevent all crawling

      • Tom Braider

        In my opinion, relying on ‘Discourage search engines’ alone is very far from enough. Protecting a staging site with a htaccess password is necessary for at least one reason I can think of besides preventing duplicate content indexing: it is not uncommon for user input data to migrate from staging to production environment. An image inserted by hand might therefore end up on the production website with a hardcoded URL pointing to a staging or development server. For a larger projects this might means dozens or hundreds of hardcoded links that may not be easy to spot unless the staging server happens to be down. A simple internal link audit (which must be done regularly anyway) however will immediately fail due to the htaccess protected parts of a production site and these problems will be fixed at the earliest possible moment.

  • This is an incredibly naive take on staging environments. In a typically competent development shop, there would be three environments: dev, staging, and production. The complications of using a CMS for staged deployment are both well-known and poorly accounted for, since the authors’ purpose for writing the CMS was to make it easy for non-developers to create and publish content. There needs to be a flow of code from dev to staging to production, and a flow of data from production to staging to dev. Tools would need to exist to facilitate this operation, and they are largely bad or don’t exist. The tedium of moving customer-produced data to staging and dev environments from production is what causes most independent contractors to skip staging environments at all. As a contractor, I’ve been asked to repair many sites that would not display content properly due to a prior contractor failing to get this process right, and allowing the customer to produce data in production that could not be displayed properly by code deployed up through staging. It is a HARD PROBLEM. Three paragraphs merely suggesting that it should be done is almost not worth the mention. How about some links to tools or an essay on methods that are known to work marginally well?

    • Jeff Smith

      I’m not sure that “incredibly naive” is a term I’d agree with. You seem to be looking for something that isn’t here, is all. The article is titled “Why Staging Environments Are Critical for WordPress Sites” – and that’s it’s goal, to briefly explain, both to developers, and maybe more importantly, those who work exclusively with WordPress and don’t have the background that lots of developers have, the need for staging environments. It’s unfortunate, but it’s something that needs done. I’ve seen a lack of this sort of thing (and a lack of proper backups, and a lack of any testing at all, etc) in many WordPress sites and with many different individuals and companies.

      That all said, you’re definitely right, it can be complicated. In some instances, it’s more complicated than others. If you’re running a site that only has occasional user input by a handful of users, using staging is a process that operates in a standard way and data mostly needs to flow one direction. In more complex setups, you’re going to need more complex tooling. It might be worth an in depth piece to explore various solutions in detail, or even a few different looks at tools or sets of tools. What do you think?

  • J.M. de Oliveira, Jr

    I love WordPress, but the fact is that it has its conundrums. With that in mind, I only resort to it when clients need an integrated blog in their websites or when they insist to update their own content. And in relation to this, I’m considering using simpler CMS’s.

    • Jeff Smith

      I hear you, there are things that can be frustrating. I find that with most technologies I work with, as if our tools sometimes don’t want to help us do our jobs, haha.

      I’ve actually had clients recently who have specifically asked for WordPress. I think they were shooting for a platform that was easy to update (it is that, most of the time), more easily extendable (by them – that can be a scary thought :D ) and with some developer security (if I flaked, they’d have an easier time finding someone to work on the site). Its prevalence makes it hard for us to ignore, doesn’t it?

  • jimlongo

    I’d say you have local, staging, and production.
    Use GitHub and a deploy strategy (DeployHQ is good) to handle code changes, but data migration is always a bit of a pain.

  • Manuel Romero

    I am wondering about the best practice for dealing with database changes. For example, we test a plugin on Staging and it works. The PHP code and the plugin code has been changed but the plugin has added tables to the database. The client needs to review the changes on Staging and that takes a day meanwhile content other transactions are being updated in the Production database. How to we best migrate the database changes from Stage to Production?

  • Tony Oliver

    Jeff,
    Staging is a no brainer for developers for code, plugins etc.., but what about every day content administrators. Our eCommerce site has admins that are updating content (text, images, options, prices) every day. I would like to have them do these updates in a stage environment, test the content and then publish the updated content to the live site. This process needs to be as simple as a button click. This is a high volume, complex WP site. Any suggestions?