We just published a brief article about Staging Sites in WPCloudDeploy and ended up with a number of questions – perfect for a related article!
Do you have to reactivate your plugin and theme licenses on staging sites?
The answer to this question is – it depends on the plugin/theme authors’ policies as well as what you want to accomplish on the staging site.
Some themes and plugins force you to activate or reactivate a new license for every domain before you can use all the features – so your staging sites will need to be reactivated for those.
Other themes and plugins will allow you to use the unlicensed plugin but without the benefits of automatic updates. If you don’t need these in your staging sites then there is no need to activate the license.
Yet some others might automatically bypass all license checks if the site is a local site or have a .dev domain.
So, the answer to this question does depend on each plugin and theme authors’ policy.
CloudFlare: Is “development mode” needed?
Development Mode in Cloudflare tells it not to cache anything. So, generally, you want to turn this on for staging sites.
Unfortunately, this mode usually automatically turns itself off after 4 hours.
So what you really need to do is turn off the Cloudflare proxy service – which just means flipping the orange “cloud” toggle off for your staging domain.
Is caching needed in staging sites?
If you’re using your staging site for active development then you want to see your changes as you make them. So you do not usually want caching of any kind enabled.
But at some point you will need to test your changes with caching enabled. Then, you have two choices:
- Turn on caching for your current staging site or
- Push the site to a new pre-rollout site, turn on caching there and test. If it all works properly, you can then push the pre-rollout site to the production site
There is one exception to this – you can generally leave your object cache enabled (usually Memcached or Redis).
Should I enable password protection on my staging site?
Generally, yes. This way the public do not have access to the site as you develop it and you do not have to do strange things with attempting to hide your WP login screen (which can sometimes break other plugins).
To do this in WPCD, use the HTTP BASIC AUTHENTICATION option in the MISC tab for your site.
What should I do about Stripe, Paypal and other subscriptions?
This depends on how your plugins manage subscriptions.
WooCommerce, for example, handle the subscription renewals itself locally on your site. But it also detects when a site has been copied and turns off renewals until you explicitly turn them back on.
Other plugins depend on Stripe and Paypal to handle the renewals and then notify them via a webhook about the renewal. In this case you usually don’t have to do anything since the renewals will automatically end up on the production site.
BUT, you might want to direct the Stripe and Paypal notification and IPN sandbox hooks to your new staging site so that your test transactions are handled properly. If you are using other payment providers, you might need to do something similar as well.
What should I do about emails?
If you have subscriptions on your site and you send out notification renewal reminders or receipts, then you want to turn off all outgoing emails.
Plugins like Disable Emails will block all outgoing emails. If you find that emails are still being sent, check the FAQ at the bottom of that plugin’s wordpress.org page for some ideas.
Google Analytics? Other JS Scripts?
Google Analytics is smart and will likely not record any impressions from your staging sites.
Other scripts might not be so smart so you will need to check with the publisher to see how these are handled when a site is copied. (Though, these days, the expectation is that JS scripts that send data back to an SaaS site are keyed to a particular domain and any data that isn’t from that domain is ignored.)
How do I push my site back to production without overwriting production data?
Ah, this is the hardest thing to do in WordPress development and one of the most frustrating and error-prone things you will need to handle.
Short answer is, there is no good answer!
Professional developers will create a custom script or plugin that’s purpose-built for the site. Generally, each project will have a unique set of merge and data management requirements when pushing data back to production so a custom script or plugin is generally called for.
Or you can do it manually – usually with a ‘todo’ list that you’ve created as you developed/modified the site.
Because WPCD allows you to have multiple staging sites, you will be able to test your custom plugin / script (or your todo list) on a separate site other than the current staging site before pushing everything back to the production site.
With WPCD you can make as many separate copies of your production site as you like, push your changes from staging to those copies and test your custom DB merge scripts.
There are some tools that try to make the merging process easier but can sometimes cause more issues than they’re worth. Check out https://wpmerge.io/ for example.
Wrapup
Do you have other questions about WordPress staging sites? If so, shoot them our way and we’ll update this article!
Was This Article Useful? Or do you have questions or comments about it (or our products & services)? We'd love to hear from you!
Automatic Notification Of New Articles
Sign up to get automatic notifications of new articles. This is a different list than our standard list - you only get new articles once a week (usually on Mondays). No other emails will be sent unless you sign up for our general list as well.
Follow us on Twitter! We post a lot of cool things there first. To keep up, click the "X" below!