Guide CyberPanel WordPress Staging (Clone): Why It Came Out Empty and How We Fixed It - Printable Version +- AdminsForum (https://adminsforum.com) +-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels) +--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel) +---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials) +----- Forum: CyberPanel Websites & OpenLiteSpeed Guides (https://adminsforum.com/Forum-cyberpanel-websites-openlitespeed-guides) +----- Thread: Guide CyberPanel WordPress Staging (Clone): Why It Came Out Empty and How We Fixed It (/Thread-guide-cyberpanel-wordpress-staging-clone-why-it-came-out-empty-and-how-we-fixed-it)

CyberPanel WordPress Staging (Clone): Why It Came Out Empty and How We Fixed It - JAY - 10-26-2026 CyberPanel WordPress Staging (Clone): Why It Came Out Empty and How We Fixed It A staging site is a private copy of your live WordPress where you can test updates, a new theme or a plugin before touching the real site. CyberPanel has a one-click Clone/Staging button for this. We used it on our test WordPress ( Code:Copy cyber.adminslab.com ) and it took two tries and a few fixes to get a staging copy you can actually trust. Here is all of it. Before you start Create a DNS A record for the staging name (ours: Code:Copy staging.cyber.adminslab.com , at Cloudflare, DNS only) so CyberPanel can issue SSL for it. Run the check in Step 1 first. It decides whether your clone works at all. Step 1: Make sure /usr/bin/wp exists CyberPanel's staging code calls WP-CLI at the fixed path Code:Copy /usr/bin/wp . Many people (and the official WP-CLI install steps) put it in Code:Copy /usr/local/bin/wp instead, which is what we did in our WordPress install guide. Check: Code:Copy ls -l /usr/bin/wp /usr/local/bin/wp Ours said Code:Copy ls: cannot access '/usr/bin/wp': No such file or directory . The staging code first checks that Code:Copy wp works (it does, through your PATH), so it doesn't install its own copy, and then every later command fails quietly. Fix it with a link: Code:Copy ln -s /usr/local/bin/wp /usr/bin/wp Step 2: Start the clone Open your website in Websites > List Websites > Manage and click Clone/Staging. The page asks for one thing, the staging domain: The staging site is created as a child domain of the live site, in its own folder ( Code:Copy /home/cyber.adminslab.com/staging.cyber.adminslab.com ) with its own new database. Type the name and click Start Cloning. The progress bar shows "Creating domain", "Creating and copying database", "Fixing permissions" and so on. A minute later the panel reported success. On our first try, that message was wrong: Our first run (before Step 1): "Successfully Installed", but the staging folder held only CyberPanel's Code:Copy index.html , 8 KB in total. No WordPress, no database copy. The only clue in Code:Copy /home/cyberpanel/error-logs.txt was the SSL step. Always check after a clone: Code:Copy du -sh /home/yourdomain.com/staging.yourdomain.com ls /home/yourdomain.com/staging.yourdomain.com To retry, remove the empty child domain and its folder first. From SSH: Code:Copy cyberpanel deleteChild --childDomain staging.yourdomain.com rm -r /home/yourdomain.com/staging.yourdomain.com Second run (after Step 1): the folder had the full site (120 MB) and Code:Copy wp-config.php pointed to a new database. That's when we found the next problems. Step 3: Fix the four leftovers Run these as the site user from the staging folder. Ours: Code:Copy cd /home/cyber.adminslab.com/staging.cyber.adminslab.com S='sudo -u cyber2602 wp' 1. Stale object cache: WordPress still thinks it's the live site. Code:Copy $S option get siteurl returned Code:Copy https://cyber.adminslab.com , the live address. But the staging database itself already had the staging address: Code:Copy $S db query "SELECT option_name,option_value FROM wp_options WHERE option_name IN ('siteurl','home')" returned Code:Copy http://staging.cyber.adminslab.com for both. The difference came from the Redis object cache: the clone copied the live site's LiteSpeed Cache settings, including Redis database 2, and most likely the staging copy cached its options while they still held the live URL, before CyberPanel replaced them. Give the staging site its own Redis database and flush it: Code:Copy $S litespeed-option set object-db_id 3 $S cache flush After that, Code:Copy option get siteurl matched the database. (Don't flush while staging still uses the live site's database number: Code:Copy wp cache flush empties the whole Redis database, live cache included. See Redis object cache on CyberPanel.) 2. http instead of https. The staging database had Code:Copy http://staging... although CyberPanel had issued SSL. Replace it everywhere: Code:Copy $S search-replace 'http://staging.cyber.adminslab.com' 'https://staging.cyber.adminslab.com' --all-tables --report-changed-only WP-CLI made 9 replacements. 3. Google can index your staging site. Code:Copy blog_public was Code:Copy 1 (copied from live). Turn on "Discourage search engines": Code:Copy $S option update blog_public 0 After purging LiteSpeed Cache ( Code:Copy $S litespeed-purge all ) the staging pages carried Code:Copy <meta name='robots' content='noindex, nofollow'> . For a real lock, also password-protect the staging site. 4. CyberPanel's index.html. The staging folder still had the "CyberPanel Installed" Code:Copy index.html next to WordPress's Code:Copy index.php . Delete it: Code:Copy rm index.html . After these fixes, the staging copy was correct: Staging now answered with its own https address, Code:Copy blog_public 0 , its own Redis database ( Code:Copy 3 ). The live site was untouched: Code:Copy https://cyber.adminslab.com , Code:Copy blog_public 1 . Things to know Same Linux user. Staging runs as the live site's user and counts toward the same package limits (a domain, a database). See packages and limits. No automatic push back. Changes you make on staging stay there. Copy them to live yourself (or redo them on live once they work). Cron. Our live site had WP-Cron disabled and a real cron job (cron guide); the staging Code:Copy wp-config.php was rebuilt without Code:Copy DISABLE_WP_CRON , so staging uses normal WP-Cron. That's fine for testing. Emails. A staging copy can send real emails (order mails, newsletters). Disable mail plugins or use an SMTP catcher on staging. Delete it when done. Code:Copy cyberpanel deleteChild --childDomain staging.yourdomain.com , then remove the folder and the staging database. More CyberPanel guides Fail2ban brute-force protection Change PHP version per website Git deployment from GitHub SSH key login, passwords off Create a website Issue SSL and fix failed certificates Subdomains, addon domains and aliases Rewrite rules, force HTTPS, HSTS Install WordPress with LiteSpeed Cache Cron jobs and a real WP-Cron Redis object cache for WordPress Databases and phpMyAdmin Email, DKIM, SPF and DMARC Email forwarding, catch-all, plus-addressing Mail queue, spam senders, blacklists CyberPanel DNS vs Cloudflare Packages and website limits Deploy Laravel on CyberPanel Backups: create, restore, schedule File Manager and FTP Reset the admin password from SSH Log files and config locations Check and restart services First steps after install ModSecurity + OWASP rules (fix) CLI cheat sheet Install CyberPanel on Ubuntu 24.04 Firewall explained Install PHP extensions Change PHP settings (php.ini) Update CyberPanel safely Server Error (500) after a fresh install Packages, users and ACLs Upgrade CyberPanel safely Real visitor IPs behind Cloudflare Docker apps on your domain with SSL Import a large SQL file over SSH Remote MySQL access for one IP Move WordPress to CyberPanel by hand Fix "Error establishing a database connection" Fix PHP2Shell (CVE-2026-109618/109619) Run your own nameservers (PowerDNS) CyberPanel on a small VPS: RAM tuning Tested on CyberPanel 3.0 (build 8, OpenLiteSpeed edition) on Ubuntu 24.04, October 2026. Menu names can change slightly between versions.