Thoughts about setting up staging sites

At Advanced Ads, we are using a lot of test sites to identify issues, ask users to reproduce a problem, or have environments with more complex setups at hand. I am currently onboarding new members to our support team which gave me the chance to look at our current workflow to set up these sites. I ended up with a faster and more secure setup and documented my thoughts about it in case anyone might look for something similar.

How I got started

When it was just me === team, my “test” site was plugins.local. A local installation with everything installed and set up that I might need to develop and improve our plugins.

You reported a potential conflict between Advanced Ads and BuddyPress? Let me set up BuddyPress with some dummy data on that site and see if I can reproduce the issue and fix it there.

With each new plugin and content, the whole site was closer to cause more problems than solve some. It was also not a solution that allowed customers to reproduce an issue without setting up a staging site on their own or sending me a login.

Then it grew

I needed a more scalable solution when the team and the customer base grew. So I set up a bunch of WordPress sites on a subdomain of our main domain.

In the first phase, I created /blog_1, blog_2, etc. We set them up as we needed them, meaning that some of them were dedicated to specific plugins or themes, like BuddyPress or Newspaper, others were shared with users so that they could try to reproduce their issues in an environment that allowed us to work on it.

The problem with these URLs was that they were not changed. We reset them after an issue was resolved, but they still existed. Yes, they were set to not be indexed by search engines and users lost their access when we reset them, but still…

This issue remained even after I started using random blog IDs, like /blog_07v3ood.

The biggest problem with this setup was, that it was set up on the server we used for our business website. At least, we used a different database for the test sites, but still. An ill-minded user could have caused us a lot of harm.

What I looked into

So I went looking for a solution with these basic requirements:

• running on another server
• quickly create new sites with random URLs
• easy to reset
• accessible to our external users

It came down to two alternatives.

1. using a dedicated third-party service
2. using a new hosting with a new domain

Third-party staging services

I found a few services that offer staging sites. They are mostly dedicated to creating staging sites for internal projects, but could be used for our purposes as well. The price for what we were looking for moved between $99 per year for 12 sites or $49 per month for 100 sites.

I finally decided against these solutions because both were missing company information and when asking one of them about that, the reply took a few days and was not very friendly and welcoming, not to say, didn’t offer any information about who they are.

When asking other business owners about suggestions, the staging option from WP Engine was mentioned more than once. We don’t host with them but I have access to a test site and know that it was rather quick to import a complete site to them. Though that was not what I was looking for.

Setting up our own test domain

I ended up purchasing a new package and domain with our hosting company. The package I ordered is a cheap shared hosting, which is still fast enough for our purpose. It comes with a dedicated TLD and database, so it cannot affect our main site intentionally or accidentally.

I installed WordPress on that site together with the following plugins:

• WP Staging to create copies of the sites in a subdirectory
• FakerPress to create dummy content, if needed
• WP Reset to reset an installation
• Advanced Ads

Everyone in our support team also has an admin account on that site.

Basically, that main site is set up as the optimal blueprint for new test sites.

Whenever anyone in our team needs a new test site, they go to the main installation and use WP Staging to create a copy in a subdirectory. It just takes one click and maybe a minute until all files and data are copied.

Once the copy is created, the person who set it up removes the user accounts and maybe plugins which are not needed. If the installation is meant to be shared with an external user then this user receives a new login.

We also use these test sites to reproduce single issues for our developers.

An internal naming convention helps us to quickly know from the URL who created the test site and what it is meant for. This part could be improved though since it is often not enough to know about the status of the site, e.g., whether the issue is removed or not.

The old test sites are now used for internal purposes only, like the static setups I mentioned that we keep in order to not repeat the same setup process of specific themes or complex plugins.