Problem
ddev push pressable imports the local dump with a raw wp db import -, so every row the platform owns is replaced by the local site's copy. Seen on a Pressable staging site (WordPress 7.1, PHP 8.5.10) after pushing a ~240 MB WooCommerce site from a stock DDEV project:
- Jetpack disconnected.
jetpack_options and jetpack_private_options are not in the local dump, so after the push Manager::is_connected() is false and there is no jetpack_options[id]. Reconnecting needs a browser session on the staging site, which on a clone with placeholder admin emails meant minting a reset link by hand first.
- Platform plugins deactivated. The pushed
active_plugins row drops jetpack and automattic-for-agencies-client, which Pressable had active on the clone.
- Pressable's admin user gone. The pushed
wp_users and wp_usermeta replace the remote set, so the platform-created admin disappears and the only logins are the local site's.
None of this is surprising for a full-database replace, and the README's Safety section warns that push overwrites the remote database. But these three are platform state, not site content, and the provider already knows it is about to replace them. For comparison, Studio Sync's importer preserves the Jetpack connection options across the same kind of full push, so Jetpack came back connected as soon as it was re-activated.
Proposed change
Before wp db import -, capture on the remote:
wp option get jetpack_options --format=json
wp option get jetpack_private_options --format=json
wp option get active_plugins --format=json
After the import and the URL rewrite, restore the two Jetpack options and set active_plugins to the union of the pushed list and the platform plugins that were active before. Print a line saying what was restored.
The admin user is harder to restore cleanly (users and usermeta rows, and post_author references in the pushed content). Two options: document it in Safety as a known consequence with the wp user create recovery, or offer a push-side table exclusion so wp_users/wp_usermeta can be left out, the way PRESSABLE_DB_TABLES already works for pull.
At minimum, a Safety bullet listing the three consequences and the recovery steps would have saved the guesswork.
Notes
Problem
ddev push pressableimports the local dump with a rawwp db import -, so every row the platform owns is replaced by the local site's copy. Seen on a Pressable staging site (WordPress 7.1, PHP 8.5.10) after pushing a ~240 MB WooCommerce site from a stock DDEV project:jetpack_optionsandjetpack_private_optionsare not in the local dump, so after the pushManager::is_connected()is false and there is nojetpack_options[id]. Reconnecting needs a browser session on the staging site, which on a clone with placeholder admin emails meant minting a reset link by hand first.active_pluginsrow dropsjetpackandautomattic-for-agencies-client, which Pressable had active on the clone.wp_usersandwp_usermetareplace the remote set, so the platform-created admin disappears and the only logins are the local site's.None of this is surprising for a full-database replace, and the README's Safety section warns that push overwrites the remote database. But these three are platform state, not site content, and the provider already knows it is about to replace them. For comparison, Studio Sync's importer preserves the Jetpack connection options across the same kind of full push, so Jetpack came back connected as soon as it was re-activated.
Proposed change
Before
wp db import -, capture on the remote:After the import and the URL rewrite, restore the two Jetpack options and set
active_pluginsto the union of the pushed list and the platform plugins that were active before. Print a line saying what was restored.The admin user is harder to restore cleanly (users and usermeta rows, and
post_authorreferences in the pushed content). Two options: document it in Safety as a known consequence with thewp user createrecovery, or offer a push-side table exclusion sowp_users/wp_usermetacan be left out, the wayPRESSABLE_DB_TABLESalready works for pull.At minimum, a Safety bullet listing the three consequences and the recovery steps would have saved the guesswork.
Notes
mainplus fix: run WP-CLI against the docroot and keep PHP notices out of captured values #4 and feat: print the push target and refuse production environments #5 applied. Neither PR touches this.