WordPress lives in a very complex ecosystem with many different setups and scenarios. When an issue is reported it is of course impossible to recreate the exact same environment for testing, and likely it is not even necessary. Having different test setups though can decrease the testing time, actually the setup time by minutes.
At one point I did have 4 or 5 different test sites for different testing purposes. Here is the list of the most common ones.
Local test site
This is the starting point. If you are doing support you must have a local test site. It’s easily accessible and usually does not depend on network availability.
There are multiple methods of setting up a local test site on the different platforms. Many years ago I used run an Apache server (on Windows) with MySQL, then I discovered XAMPP portable (MAMP for Mac is very similar) and was running with that for 8 years or so. That was great because I could run it anywhere from a pendrive. After a bit of server setup I could start manually installing WordPress and the rest.
Then about 2 years ago someone recommended Local by Flywheel, which has a one-click WordPress install option, site blueprints, hot switching PHP versions and a lot more. I haven’t touched XAMPP since I first installed Local, so I guess it’s time to delete it. 🙂
And there are probably a bunch of other similar tools. Choose the one that works for you the best, fastest.
Live test site
If you own a domain name, then it is quite easy to set up a live test site, under a subdomain for example.
Live test sites can be useful when you need functionality that requires a live connection, like testing email sending, or online purchases with payment gateways.
Yes, there are ways to do this on a local test site as well, but might require extra setup, which some users are not familiar or comfortable with. S0 it might be easier to do it on a live test site.
A simple vanilla installation
A vanilla installation is one that has only the basics. No customization, nothing. A fresh WordPress installation with on the the plugin(s) you are testing.
A vanilla setup is useful and absolutely needed if you want to test reported bugs of your plugin.
Of course, if you want to test for a conflict with another plugin, you can install those as well. Just remember do deactivate / remove them before testing something new.
A multilingual setup
If you have a plugin / theme that is popular with multilingual users, then it is definitely worth having a separate test setup for that.
WPML is a popular plugin for setting up multilingual sites. And it requires – I think – at least 3 plugins to be installed and activated.
Imagine having only one test site for everything. You just ran some tests for a simple bug. Then A multilingual request comes in. You need to go to Plugins, activate the 3+ WPML plugins that you need and check if the setup is still correct, because you don’t remember what you did the last time. This will take at least 2-3 minutes to set up, which you can save if you have a separate setup ready to go.
A WordPress multisite setup
The reason for this is the same as above. And it’s even more useful because switching a multisite setup on or off is quite complicated.
There still might be other scenarios that can be useful for you. You will probably realize this after having done some different tests and realize a certain pattern. Once you realize take the extra time to set up a separate environment. It will take some time, but will save you much more in the long run.
A useful tool
During running different tests I often found myself needing a fresh installation. I could go and delete the test site and set up a new one, but that again costs time.
Plugins to the rescue! There are some nice plugins that will help you with resetting your WordPress site to a state as if you just freshly installed it. The added benefit is that it will leave all the plugins installed, so you don’t need to install them again. When you do the reset all your plugins will be deactivated and their settings deleted.
This year (2019) in September I participated at WordCamp Zürich in Switzerland. I applied with a talk about how a support exchange, and thus reaching a resolution can be made faster. And I thought it would make a great blog series.
This is the fifth set of tips for Support Agents in the Faster Support – For Both Sides series.