Clone WordPress to a Softaculous staging site (and push it back)

Softaculous has shipped a proper staging workflow for WordPress since version 5.7 — separate from the older Clone feature — and most resellers still hand-roll subdomains and wp search-replace instead of using it. The staging flow keeps a parent/child relationship between live and staging, takes a snapshot before every push, and gives you a one-click rollback if the merge breaks the site.

This guide covers the cPanel flow end-to-end: spinning up the staging clone, what gets copied and what does not, how the push-to-live merge actually works, and the three places it routinely goes wrong on busy WooCommerce sites.

Create the staging clone

Open cPanel → Softaculous Apps Installer → Installations, find the live WordPress entry, and click the Create Staging icon (the small fork glyph, not the regular Clone icon — those are different features and the difference matters for the push step later).

Fill in:

• Choose Domain — pick a subdomain that already exists in cPanel. If staging.example.com is not in the Domains list, create it under Domains → Create A New Domain first; Softaculous will not create the DNS record for you.
• In Directory — leave blank to land in the docroot of the subdomain. Anything else, and the rewrite step in the push phase has to handle a path prefix and frequently misses absolute URLs in serialised options.
• Database Name — accept the auto-generated cpuser_wpsNN value. Reusing the live database breaks the staging concept entirely.
• Table Prefix — leave at the suggested wpsNN_ so the staging tables do not collide if you ever consolidate databases.

Click Create Staging. Softaculous copies the docroot via cp -a, dumps and restores the database into the new prefix, runs wp search-replace for the staging URL, sets WP_DEBUG=false and DISALLOW_FILE_EDIT=true in the staging wp-config.php, and registers the parent/child link in its own metadata. On a 2 GB site with a 400 MB database this takes 30-90 seconds on local NVMe.

Work on the staging site

Visit the staging URL and log in with the same credentials as the live site — staging is a copy, including user accounts. From here, treat it as a normal WordPress install: update plugins, change the theme, run a database migration plugin, test a WooCommerce checkout flow against Stripe's test mode.

Two things to know:

1. File ownership is the cPanel user, so SSH/SFTP edits work without chown. The plugin update path is the standard WP admin one — no FTP credential prompt.
2. Scheduled tasks are disabled. Softaculous adds define('DISABLE_WP_CRON', true); to the staging wp-config.php and removes the cPanel cron entry. If you need to test a cron-driven plugin (Action Scheduler, automated WooCommerce reports), trigger it manually with wp cron event run --all.

Push staging back to live

Back in Installations, find the parent live install. There is now a Push to Live icon next to it — only appears when a staging child exists.

The push form gives you three checkboxes that decide what actually gets merged:

• Files — copies the staging filesystem over the live one. Defaults to "Customize files to push" so you can deselect plugin folders that live should keep, or new uploaded media in live that staging does not know about.
• Database — replaces the entire live database with the staging copy, after running wp search-replace to swap the staging URL back to the live URL. This wipes any orders, comments, or form submissions that landed on live during your staging work. For active WooCommerce sites this is almost never what you want — push files only and replay the schema change in live by hand.
• Backup before push — leave this on. It snapshots the live install into the Softaculous backups directory so you can roll back in one click. The default location is /home/cpuser/softaculous_backups; check disk space before pushing a 5 GB site.

Click Push to Live. Softaculous puts the live site into maintenance mode (drops a .maintenance file), runs the diff, swaps in the new files and/or database, clears any LSCache pages it can see, and removes the maintenance flag. Downtime is typically 5-20 seconds for a files-only push, longer if the database is large.

Roll back a broken push

If the merge breaks the site — white screen of death, plugin incompatibility, theme regression — open Softaculous → Backups, find the snapshot tagged pre_push_<timestamp>, and click Restore. This re-applies the pre-push files and database in place. The staging child stays untouched, so you can fix the issue there and try again.

If the WordPress admin is unreachable, restore from SSH:

cd /home/cpuser/softaculous_backups
ls -t | grep pre_push | head -1
softaculous --restore wp.<timestamp>_pre_push.tar.gz

The softaculous CLI is in /usr/local/cpanel/3rdparty/bin/ on cPanel boxes — add it to PATH if it is not picked up.

Three things that break the push

Worth knowing before you commit to staging as the workflow for client sites:

1. Custom database tables outside the WP prefix. WooCommerce extensions (Subscriptions, Memberships, several booking plugins) write to tables like woocommerce_subscriptions rather than wp_woocommerce_subscriptions. Softaculous only diffs tables that match the install's prefix — anything outside it is silently skipped on push. Add them to a manual mysqldump if they matter.
2. Serialised option values with absolute URLs. Plugins that store full URLs inside PHP-serialised arrays (Elementor, some form builders) are usually handled correctly because Softaculous calls wp search-replace rather than a raw sed. But custom plugin tables outside the WP schema are not searched. Test with wp search-replace --dry-run against the staging-to-live URLs first.
3. Files in wp-content/uploads that exist in live but not staging. Default push is files-only, deselect everything except themes and plugins, and you preserve them. The moment you tick "All files", the file diff removes anything live has that staging does not — including yesterday's customer uploads.

For sites where customers write to the database constantly, treat Softaculous staging as a code and config staging tool, not a content one. Push files, then run schema migrations in live by hand. The Imunify360 file change scanner will pick up the file changes — that is expected, not an alert to chase.

Next steps

• New to Softaculous? Walk through installing Softaculous on cPanel and grab a Softaculous license.
• Pulling a site from another host into Softaculous? Use Remote Import for WordPress before you start staging.
• Comparing your options? See Softaculous vs Installatron — staging works differently on each.