A staging site is an independent clone of your production site, password-protected and accessed only by you or your developers. The staging environment is used for testing and development of new plugins, themes or everything related to the production site that would lead to visual or server issues. At times, these issues can be so stressful and long-lasting resulting in a negative effect on your visitors, Google ranking, sales, etc. We will mention a few common situations that every WordPress developer faced at least once, and we will show you how by using the staging environment you can do these changes without stress.
Quick presentation how WordPress staging environment works
Soon, we will also write a complete deep guide to present you how easy is to work with a staging environment, meanwhile, here is a simple video. In this video we will:
- Create a staging environment
- Change our theme on our cloned site
- Install social share plugin
- Push changes to our production site
Most common situations when to use the staging environment
Let’s see some common situations where it’s much better and stress less to make changes to your WordPress site.
1. Installing a new plugin
Sometimes with the activation of a new plugin, your site may not work properly, and very often this error is called WordPress White Screen of Death (WSOD). To fix this error, you need to delete the plugin manually and hope that everything will be as before. If this happens to you on your WordPress staging environment, you just need to recreate it, and that won’t affect your production site.
2. Testing a new or existing plugin
Some plugins can make massive changes on your site; furthermore, you’ve surely noticed that they strongly recommend you to make a “backup” before testing. The risk can be so high that you can lose all the images, for example, when using a plugin for deleting all the unnecessary images from the disc that are not used in WordPress Media. There is another type of plugins testing, typically they add or modify the visuals of your site, such as the social sharing plugin or image slider. While testing this kind of plugins, there is no need showing our visitors something that we just want to see how it works and afterward configure config parameters and finally, make a decision whether to use it. When you use WordPress staging environment, all of these tests are made on your cloned site, and if everything is correct, with a single click, you can push the changes to your production site.
3. Updating a plugin
Very often, we encounter problems when we are upgrading a major version of a plugin, e.g. from 1.1 to 2.0 version. Sometimes, even if we have no problems with itself plugin update, other plugins are closely related to it. For example, when we would try to update WooCommerce from 2.6 to 3.0, it is possible to have no problem with the WooCommerce, but with the payment or order processing plugins related to WooCommerce.
Another example is the connection of the theme with the plugins; usually, the new versions of the plugins are created first and afterward, the developers make their themes compatible with the new versions of the plugins. Check Flatsome, one of the best-selling WooCommerce themes, on the right side you can find compatibility information.
By using a staging environment, all these plugin updates will be done on the same cloned site, and if the theme and the other plugins are compatible, you will afterward push the changes to your production site.
4. Updating WordPress
How many times didn’t you make an update to the major version of the WordPress (e.g. 3.8 to 4.0) because you were not sure whether the theme and the other plugins were compatible with the new version of WordPress? If updating your WordPress site was so stable and comfortable, the “Auto WordPress Major Update” would be an active default option by now.
Can you imagine now, how easy and stressless is the testing on the staging environment. You simply make the update on your cloned site and later, after you make sure that everything is working and compatible, with only a click the changes are reflected on your production site.
5. Changing WordPress Theme
You can change a theme with a single click, but afterward, depending on the theme features, you will need several hours to set all the parameters. This process can take quite a lot of time, and that’s why you do not want to make your production site look like a development site because you already have active visitors. It is unpleasant, I know, and that’s why you need to modify, test the new theme and everything else in the staging environment and after everything is set correctly, push the changes to your production site.
6. Working on a live site with CDN and caching
If you make changes to a CSS, JS file or image that always have the same URL and you use CDN; you have two ways to review the new changes, temporarily disabling the CDN or deleting the CDN cache with every change. Both ways would have an adverse effect on the performance of your site.
The same goes for Full Page caching, very often you need to empty the cache to be able to see the new changes. This could have an adverse effect that would dramatically slow down your site.
7. Switching to new PHP version
Rare are the developers that test a new version of PHP before changing it. Since each plugin is made by a different developer, which means that each plugin owns a different level of quality and compatibility, it is always wise to test the new PHP version before changing it on the production site.
8. Developing custom code/plugin
By coding a custom code, you, in fact, go through a testing process. Sometimes the errors can be huge and thus you can come up to the well-known “WordPress White Screen of Death” error. We understand the need that you shall develop your code on the current state of your site, but the risk is high. Now imagine doing the same on another site exactly same as your production site and when everything is ready and tested, to push all those changes to the production site.
Conclusion
When developing or maintaining a WordPress site, these are the common problems that you may encounter, so we can accept it as a general rule that we need to use the staging environment whenever we update a plugin, WordPress Theme or the WordPress itself. The same is when we change the CSS, JS file or any file that may impair functionality or visual effect of the site – it is always recommended to use the staging environment.
When using staging environment, you always work on a cloned site, same as your production one and you shouldn’t be concerned in case something goes wrong, even if it does and you are unable to return it to its original state, you just need to restore your staging environment. Finally, after you make the changes and tests and everything is good, with a single click, you can push the changes to the production site.
In one of our next posts we will go over all these examples practically, so subscribe to our blog so that you won’t miss the tutorial.