=== Wonderful Sync ===
Contributors: wonderfulplugins
Tags: staging, sync, divi, deployment, migration
Requires at least: 6.2
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.0.3
License: GPLv3
License URI: https://www.gnu.org/licenses/gpl-3.0.html

Move staging changes to live – Divi design, Theme Builder, pages, media, menus – without touching orders, users or comments.

== Description ==

https://www.youtube.com/watch?v=EnByY7u0kBI

You rebuild a site on a staging copy. Meanwhile the live site keeps taking orders, comments and form entries. Copying the whole database back would wipe all of that.

Wonderful Sync moves only what you changed on staging:

* **Changes since the clone:** record a baseline right after cloning. Wonderful Sync lists every page, layout, menu, medium and design setting that is new, changed or deleted since then.
* **Divi first:** Theme Builder templates and layouts, Divi Library, theme options, presets, global colors and variables. Divi's CSS cache is cleared after every transfer.
* **Conflicts instead of overwrites:** if a page was also changed on live since the clone, you see it and decide. Nothing is overwritten silently.
* **IDs and URLs fixed on the way:** new objects may get other IDs on live; references in Divi modules, menus, Theme Builder templates and the front page setting follow. Staging URLs become live URLs, also in JSON and serialized data.
* **Snapshot and rollback:** the live site saves every object it is about to change. A transfer can be rolled back; objects edited on live since then, or whose state is unknown after an interrupted transfer, are only restored when you confirm it. Keep a regular backup as well.
* **Never synced by design:** users, comments, orders, form entries, stock and sales figures, SMTP and payment settings, site URL, search engine visibility, caches. The live site applies these rules itself and refuses such data even inside a bundle. Fields whose names look like licence or API keys keep the live value, and values that cannot be inspected safely (stored PHP objects) are not transferred. Plugins that store secrets under ordinary names are not recognised automatically: classify them with the `wonderful_sync_classify` filter and check the Inventory tab before the first transfer.
* **Plugins and themes:** never copied. The preview lists plugins and themes that are missing, inactive or in another version on live, and blocks Divi data if Divi on live is older.

Transfer directly over the REST API with an application password, or as a bundle file you upload on the live site. Everything also works with WP-CLI (`wp wsync`), for scripts and AI agents.

Full walkthrough (4 minutes): live to staging, Divi presets, media, menus, block editor posts.

https://www.youtube.com/watch?v=VCwTylRMnrE

== Installation ==

1. Install and activate the plugin on the staging copy and on the live site.
2. On staging, open Wonderful Sync in the admin menu and record the baseline right after cloning.
3. On live, open Wonderful Sync > Settings and create access for the staging copy (user name and application password are shown once).
4. On staging, enter the live URL, the deploy user and its application password under Connection.
5. Make your changes, then open Changes, select what should go live and click Preview on live site.

== Frequently Asked Questions ==

= Does the plugin send any data anywhere? =

Only to the live site you connect yourself, over HTTPS (plain HTTP only between two local test sites, when WONDERFUL_SYNC_ALLOW_LOCAL_TARGETS is set). No third-party service is involved.

= What happens to orders and comments made on live while I work on staging? =

They stay. Users, comments, orders and form entries are never part of a changeset, and the live site refuses them even if a bundle contained them. Pages deleted on staging are moved to the trash on live; their comments stay. Menus, categories and tags are never deleted on live – the preview lists them. Mails that a transfer would trigger are not sent.

= Which user should I connect with? =

On the live site, go to Wonderful Sync > Settings and create access for the staging copy. This creates a user with the role "Wonderful Sync access" and an application password. That user can apply and roll back changes through Wonderful Sync and nothing else.

= What can the staging copy change on the live site? =

Pages, posts, media, menus, Divi design and layouts, and display settings such as the site title, front page, widgets and image sizes. It cannot install, activate or edit plugins and themes, manage users or log in, and it cannot change permalinks, discussion and moderation rules or other administration settings. There is no service in between: the two sites talk directly, both belong to you, and the access can be revoked by deleting the user or its application password. Content is written unfiltered only when WordPress allows unfiltered HTML for that user, and never when DISALLOW_UNFILTERED_HTML is set.

= Where are snapshots stored? =

In a folder with a random name inside the uploads directory, protected by .htaccess. The live site checks that the folder cannot be downloaded from the web before it accepts a transfer. On nginx, or when the site cannot reach itself, define WONDERFUL_SYNC_STORAGE_DIR in wp-config.php with a writable directory outside the web root.

No baseline is recorded while the folder may be public. `wp wsync storage` shows the result of the check and why it failed. After setting the constant, `wp wsync storage --move` moves existing files out of uploads.

= Can I bring changes from live into staging? =

Yes. Wonderful Sync > Live → Staging on the staging copy lists what changed on the live site since the baseline, for example new blog posts. Selected changes are copied into the staging copy with the same checks, conflicts and rollback. A later transfer to live then does not overwrite them.

= Can I undo a transfer? =

Yes. Wonderful Sync > Transfer log on the live site lists every transfer with a rollback button. Objects that were edited on live after the transfer are only restored if you confirm it. Plugins and themes are not part of a transfer and therefore not of a rollback.

= Do I need Divi? =

No. Pages, posts, media, menus and site settings work with any theme. Divi gets extra support, and image IDs in Flatsome's UX Builder shortcodes are mapped as well.

= Does it work with Pods? =

Yes. Relationship and file fields of pods travel with their posts and terms, IDs are mapped on live. Pods, field groups and fields can travel too; this can be switched off in the settings.

== Screenshots ==

1. Changes on the staging copy since the clone: design, layouts, content and site settings.
2. The live site checks the package and shows what will happen.
3. A page changed on both sites: both versions side by side.
4. Result of a transfer.
5. Live to staging: changes made on the live site, taken over into the staging copy.
6. Transfer log on the live site with a rollback for every transfer.
7. Inventory: what may move and what always stays.

== Changelog ==

= 1.0.3 =
* Videos in the readme, German screenshots.

= 1.0.2 =
* Admin menu moved below the core menus.
* Permalinks and discussion settings are no longer transferred.
* Creating access for the staging copy asks for confirmation.
* DISALLOW_UNFILTERED_HTML also applies to WP-CLI transfers.

= 1.0.1 =
* No baseline in a snapshot folder that may be public.
* Clearer storage warning, with the reason when the check fails.
* New: wp wsync storage, and --move to move files out of uploads.
* Divi announcements cache is no longer listed as a design change.

= 1.0.0 =
* First version: baseline, changeset, preview with conflicts, transfer over REST or package file, snapshots and rollback, inventory, WP-CLI.
* Live → Staging: copy changes made on live into the staging copy.
* Flatsome image IDs in UX Builder shortcodes.
* Pods: relationship and file fields, and the Pods structure.
* Divi: fonts, Theme Builder conditions, menus and categories in modules, dynamic content, references in presets.
* Each object is written in its own database transaction.
