We're using Duplicator Pro. Backing up our staging site is relatively painless. But restoring is a nuisance. The whole process seems cumbersome.
First, we use our host SiteGround's backup to take a backup snapshot of the entire domain in case I screw up.
Then we use Elementor's Regenerate CSS & Data button to ensure things are synced.
Then, we make a backup in Duplicator Pro with just a few clicks (using a template we have previously defined.)
And, finally, we copy the backup link to our clipboard.
Restoring the package by pasting the clipboard link into Duplicator Pro to our production site is simple. But the rest seems like such an error-prone series of steps. It's things like:
- Activate the plug-ins which are disabled on staging: Broken Link Checker, Permatters, WPRocket, Speed Optimizer.
- Remove the checkmark on "Discourage search engines from indexing this site" on the WordPress' Settings > Reading panel.
- On the live site, use WinSCP to delete wp_content/backups-dup-pro and maybe some files on public_html.
- On the staging site, in Duplicator Pro, delete the package.
Doing this a handful of times a day gets time-consuming.
I just can't shake the feeling that there has to be an easier, one-click way to deploy changes. We looked at WP_vivid but I was nervous relying on their merging being free from flaws. We used Updraft for off-site backups for years and it seemed smooth. We've never used it from deployment from staging to prod though.
Any thoughts or suggestions?
host with wpengine
I do not understand. Why do you use Duplicator for deploying from staging to production? What’s wrong with SiteGround’s (staging site) Deploy function?
I get it—managing backups and restores can get pretty tedious, especially with so many steps involved. If you’re looking for a more streamlined process, you might want to consider hosting with Cloudways. Their staging environment is top-notch, making it super easy to deploy changes with just a click. No need to worry about all those extra steps; everything is built to be smooth and efficient. Give it a try, and you might find it saves you a ton of time!
Your process definitely includes a lot. I’ve used duplicator in the past, but started using Updraft Plus more. It’s more of a backup tool than a migrator, but the backups are great and separated by type – database, plug-ins, media, etc. So you don’t have to patch in your entire backup if, say, you only changed some theme files or changed a plug in.
Using staging on your host is the best option, as others suggested.
>I just can’t shake the feeling that there has to be an easier, one-click way to deploy changes. We looked at WP_vivid but I was nervous relying on their merging being free from flaws.
There’s never going to be an automatic solution that’s 100% accurate 100% of the time. There are some unique DB merging plugins which seem like they’d fit your use case better than just a regular backup plugin like Duplicator and WP Vivid which is much more granular with the merges, and sensitive to e-commerce situations, but I’ll have to dig up them up later when I have a chance.
Why not try the built-in SG staging feature? I remember they switched to their custom control panel but still offer staging environments, even though cPanel-based providers also provide staging.
I use HostWP.io and create “Staging” environments with a one-click Push to Live. I use the built-in JetBackup for backups and can easily restore individual files, databases, etc.
If I need to stick with a plugin, WPvivid always satisfied me so far for backups, staging, and site migrations.
In my decades of experience, the hosting provider’s “Staging” feature works very well compared to third-party plugins.
I agree completely. There should be a one click or totally automated (CI/CD, continuous integration / continuous deployment) setup like the rest of the online software world uses. There is some stuff in Git and Git{Hub/Lab} to do some of this. But the DBMS part of that stuff is a bit sketchy.
It’s tempting to try to do it exactly right in open source. But that would be a vast project to make perfect. And early versions would be so slagged by bad reviews that it couldn’t succeed in the plugin repo.