New to MainWP. Previously my manual update testing workflow involves pushing the entire live/prod site to a staging environment where I test all plugin/theme/core updates before applying to live.
With MainWP, I think I want to connect all my production AND all my staging sites. This would allow me to bulk install updates on all the staging sites first – run whatever tests I need to, and then push the same updates to all the production sites.
The issue I need help figuring out: each time I push a production site to override the staging environment, it will break the MainWP Child <> MainWP connection. How do others handle this? Is my best bet to just exclude the MainWP-related database tables when doing that push? I see two potentially relevant database tables:
wp_mainwp_child_changes_logs
wp_mainwp_child_changes_meta
If I exclude those two will I get the outcome I described above, where both environments stay connected as separate sites in MainWP?
Hope this makes sense. Thanks!
You’re right to think about excluding/restoring MainWP-specific data, but the two wp_mainwp_child_changes_* tables are not the connection data. They are used for MainWP Child change/activity logs.
The connection is stored in the child site’s wp_options table. If you refresh staging from production, preserve or restore the staging site’s MainWP Child option rows, especially mainwp_child_pubkey, mainwp_child_server, mainwp_child_nonce, mainwp_child_connected_admin, and mainwp_child_openssl_sign_algo. Also preserve mainwp_child_uniqueId if you use the Unique Security ID setting.
If your staging tool cannot exclude individual wp_options rows, the practical fallback is to reconnect the staging site after each refresh.
In that case, clear the copied production connection data from Child Site’s WP Admin > Settings > MainWP Child Settings > Clear Connection Data, then reconnect the site from MainWP Dashboard.
Thanks @bojan that’s helpful to understand. Looking at the Staging Extension with the WP Staging plugin as a setup that might work here. My hosting environment doesn’t offer the option to exclude individual wp_options rows, but if I can trigger staging site creation from MainWP in bulk for update testing that would solve the problem.
WordPress® is a registered trademark of the WordPress Foundation, and WooCommerce® is a registered trademark of WooCommerce, Inc. MainWP is an independent product and is not affiliated, associated, or endorsed by the WordPress Foundation, WooCommerce, Inc., or Automattic Inc., except where noted under the Jetpack® API and Trademark License Agreement. All product names, logos, and brands are property of their respective owners and are used for identification purposes only.