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.
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
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!
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!
Jeff works for a startup as a technical writer, does contract writing and web development, and loves tinkering with new projects and ideas. In addition to being glued to a computer for a good part of his day, Jeff is also a husband, father, tech nerd, book nerd, and gamer.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers