If you run a small business site, blog, or community project using WordPress, this guide is for you.
While consulting clients with WordPress websites and dealing with support, I’ve learned that Staging can be challenging to understand.
Having a copy of your data to play around with is magical because it enables non-technical users to try updating plugins or snippets without risking the appearance or functionality of their website.
WordPress can be complicated
WordPress for regular projects means using the CMS, the plugins that extend it, and themes. This is mainly using the community code rather than building something from the ground up.
You won’t need a version control system if you are not building your plugins or a custom theme.
Changelogs can be hard to read, but since most of the changes will probably not affect your website, they can help you understand what is happening with its components.
That’s why I think that for a regular site, having a Staging version where you can update everything at once to detect incompatibilities is the fastest and safest way to update or explore new functions.
If you know me, I prefer to enable auto-updates for everything. That is because I know which robust plugins to use.
That being said, Autoupdates are often not available in Staging environments. So, how would you know if something is going to break?
Sometimes, turning off auto-updates for critical plugins and manually test updates is best.
Or you could create a mirror of your site in a public folder and hide it from indexing and behind a wall, for example, for registered users only.
I’m talking from theory since I only enable auto-updates for non-critical sites with low budgets. I always have an established way to restore or have someone help if there is an emergency.
Changing a theme or redesigning in Staging
In general, Staging works well for testing quick things.
Suppose your redesign takes more than a few hours, or the site is critical. In that case, I don’t suggest using a staging environment but rather a mirror: a separate WordPress instance, even on another server.
In my case, I like working on my own server since I know exactly how it behaves. When the development is ready, I migrate it to the production server, always having enough time to test, maybe even in a subdomain or subfolder.
Consider that for most Staging environments, you’d need to have a way to backup your work if your hosting doesn’t support backing up your Staging. You could use a plugin for this. Remember that staging is not meant to back up your production site but rather explore or test features.
Also, if your theme stores configuration mainly in the database rather than files, like block themes, you could lose information when synchronizing to the production staging. There are always workarounds like exporting all your changes to files with plugins like the Create Block theme.
There are no shortcuts or magic plugins
Even with powerful tools like WP-CLI to manipulate the database, avoiding synchronizing is the best strategy to reduce risk.
The consequences of working on a Staging site can add up. Keep it simple, and if possible, apply changes to production. Try to keep your staging and production databases aligned to ensure smoother deployments.
This will require working as a team, not only on the technical side but also on the content side, so both versions are ready to deploy in case something goes wrong.
If you’re curious about staging environments or want to try one yourself, check out DreamPress Managed Hosting — or contact me. I’d be happy to help.
Jos Velasco.
CC0 licensed photo by Michelle Frechette from the WordPress Photo Directory.
Leave a Reply