Troubleshooting Guide: Fixing Common WooCommerce and Page Builder Issues After Cloning a WordPress Site

Cloning a WordPress production site to a staging environment is a common and useful practice for testing updates, plugins, and new features—like setting up a WooCommerce store—without affecting the live site. However, the process can sometimes introduce issues that didn’t exist on the original site.

Below is a step-by-step guide to diagnosing and resolving typical problems that may arise after cloning a WordPress site, especially when WooCommerce and page builders like Cornerstone are involved.

1. WooCommerce Admin: “There was an error getting your inbox”

Cause:
This message usually appears due to a failure in WooCommerce’s API communication. It can result from incorrect site URLs, SSL misconfiguration, or blocked outgoing requests on the server.

Solutions:

Ensure WordPress URLs are correct: Go to Settings > General and check that the WordPress Address (URL)and Site Address (URL) match the staging domain.
Regenerate WooCommerce API keys: In some cases, old API tokens may not work properly on a new domain.
Check server firewall or security plugins: They might block external requests to WooCommerce’s inbox notification API.
Temporarily disable security plugins to see if they are interfering with the inbox retrieval.

2. HTTP ERROR 500 / “There Has Been a Critical Error on Your Website”

Cause:
This is a generic server error that occurs due to PHP fatal errors, often caused by plugin conflicts, memory limits, or incomplete site cloning.

Solutions:

Enable WP_DEBUG in wp-config.php to identify the specific error:

php

define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);

Then check the log file at /wp-content/debug.log.
Increase PHP limits, which you’ve already done:

ini

memory_limit = 512M max_execution_time = 300 max_input_vars = 10000 post_max_size = 256M

Make sure these values are correctly reflected in your hosting environment (check via phpinfo()).
Check file permissions: Ensure that files have 644 and folders have 755 permissions.
Plugin conflict test: You’ve already deactivated all except WooCommerce, which is great. Try activating only essential plugins one-by-one to identify the culprit.

3. Cornerstone Error: “The preview could not load due to the iframe response being incomplete”

Cause:
This issue typically arises due to:

PHP errors or warnings
Plugin conflicts
Incomplete server responses
Improper staging URLs in database

Solutions:

Inspect browser console for failed network requests or JS errors.
View the server logs (e.g., error_log) to identify any PHP issues when loading the iframe.
Search the database for old domain references using a tool like Better Search Replace. Replace any lingering URLs from the production domain.
Temporarily switch to a default theme (e.g., Twenty Twenty-One) and check if Cornerstone preview loads.
Test with minimal plugin setup to rule out conflicts.

4. Woo Checkout Editor Plugin Not Working

Cause:
A plugin not reflecting changes often points to:

JavaScript errors preventing it from executing
Cache issues
Incompatibility with the current theme or other plugins
Corrupted or incorrect database entries during the cloning process

Solutions:

Clear WooCommerce and object cache if using caching plugins or server-level caching.
Try using the plugin on a default theme to rule out theme-specific conflicts.
Inspect DOM structure to ensure fields are being rendered at all (Developer Tools → Elements tab).
Temporarily downgrade the plugin to a previous stable version to test functionality.

5. General Best Practices for Cloning and Testing WooCommerce on a Staging Site

A. Use a Proper Cloning Tool
Tools like WP Staging, Duplicator, or All-in-One WP Migration help avoid serialization issues and broken links after migration.

B. Replace All Domain References
Use a serialized-safe tool to update all URLs in the database from productiondomain.com to stagingdomain.com.

C. Disable Scheduled Tasks in Staging
Avoid sending real emails or syncing live API data from staging by disabling WooCommerce scheduled tasks:

D. Ensure HTTPS Is Fully Configured
Mixed content or insecure iframe issues can arise if HTTPS is not enforced or misconfigured. Install a valid SSL certificate and use plugins like Really Simple SSL to enforce HTTPS.

6. When All Else Fails: Restore Step-by-Step

If you’ve tried all of the above without success:

Create a fresh staging clone using a more robust migration method.
Begin testing functionality before installing additional plugins.
Keep the staging environment clean and as similar to production as possible.

Conclusion

Cloning a WooCommerce site is a powerful way to test changes, but it’s not always seamless. By carefully reviewing errors, checking server configurations, resolving plugin conflicts, and ensuring domain references are clean, most common issues can be resolved efficiently.

For persistent problems, deeper analysis of server logs and plugin behavior will often reveal the root cause. Keeping a methodical, layered troubleshooting approach will save time and prevent recurring issues.