=== StagePatch ===
Contributors: hexcorp
Tags: staging, deployment, content sync, migration, woocommerce
Requires at least: 6.4
Tested up to: 7.1
Requires PHP: 8.1
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Stage content changes and apply them as a patch: inside one site with the built-in workspace, or from a staging site to live. Never merges databases.

== Description ==

**Workspace: a staging area inside your site.** Switch the mode to Workspace and edit as usual. Opening a live page or post opens a staged copy; visitors keep seeing the live version. Publishing a new post keeps it staged, and Trash stages a deletion. Editors preview the whole site as it will look (admin bar → Workspace → staged view), then StagePatch → Workspace runs a dry run against the live content, shows conflicts field by field, and applies everything with a rollback snapshot. No second site, no copying databases.

**Two sites: staging to live.** StagePatch runs on both sites. On staging it records what you change: pages and posts, their meta and terms, menus, widgets, theme mods, allowlisted options and media. On live it validates the patch, shows a dry run with conflicts, applies with a rollback snapshot, and can undo.

It never touches orders, customers, users, sessions, cron or transients. WooCommerce orders in HPOS or legacy storage are excluded by construction, and product stock, price and sales meta are never recorded even when products are opted in.

* Patch, not merge. The same plugin runs as workspace (one site), recorder (staging) or applier (live).
* Stable identities: objects that existed when staging was cloned share IDs; new objects get a uuid and are mapped to their live ID on apply.
* References inside content (block attributes, galleries, captions, menu targets, thumbnails, theme logos) are rewritten to live IDs.
* Every apply is preceded by a dry run with a three-column conflict view, and a rollback snapshot of every touched object.
* Move the signed zip by hand (StagePatch Pro pushes it over REST).
* WP-CLI: `wp stagepatch workspace|batches|export|import|apply|rollback`.
* In the workspace, the free plugin stages pages, posts and the other allowlisted post types (including block-theme navigation and templates) with their meta and terms. Menus, widgets, theme settings and options are edited live; StagePatch Pro stages those too.

== StagePatch Pro ==

The free plugin is complete: record, review, export a signed patch, import it on live with a dry run, apply with a rollback snapshot, undo, all from the admin screens or WP-CLI. StagePatch Pro adds pushing a batch straight from staging to live over REST (Application Passwords plus signed requests, chunked uploads) with live's dry run shown inline, and extends the workspace: settings, widgets, theme settings and menu locations saved in the admin are held until applied, and classic menus can be staged as a copy from Appearance → Menus. It is a separate add-on sold at https://github.com/hexcorpIO/Stagepatch.

== Installation ==

**Workspace (one site)**

1. Install and activate.
2. Under StagePatch → Settings set the mode to Workspace.
3. Edit pages and posts as usual, preview the staged site from the admin bar, then review and apply under StagePatch → Workspace.

**Two sites (staging and live)**

1. Install and activate on both sites.
2. Set the same shared secret (16+ characters) under StagePatch → Settings on both sites, or define `STAGEPATCH_SECRET` in wp-config.php.
3. On live, set the mode to Applier. On a fresh clone of live, set staging to Recorder: this captures the baseline.
4. Work on staging. Review StagePatch → Changes, create a batch, export it (`wp stagepatch export`), then upload the zip under StagePatch → Import on live, review the dry run and apply.

== Frequently Asked Questions ==

= What does the workspace change about editing? =

Nothing visible to visitors. Editing a live page opens a staged copy of it (the list shows "Has staged edits"); the Save button in the editor saves the copy. Publishing a new post keeps it staged until you apply. Trash on a live item stages its deletion. Drafts stay drafts and are edited directly. Quick Edit and Bulk Edit are turned off for live items because they write live rows directly. Only a person editing is staged: writes from WP-CLI, cron and background plugin code go live as they always did (the `stagepatch_workspace_person_editing` filter can change that).

= Can editors stage while an administrator approves? =

Yes. Editors can stage, preview, discard and mark items "Ready for review" from the editor panel or the Workspace screen. Applying, rolling back and dissolving batches need the `stagepatch_apply` capability, which administrators get by default; grant it to any role with a capability plugin. The Workspace screen preselects items marked ready.

= Can I undo a staged change without applying? =

Yes: Discard on the Workspace screen, in the editor panel or in the list table throws the staged copy away and the live item is untouched.

= What is edited live in workspace mode? =

Media uploads, categories and tags, comments, users, and, without StagePatch Pro, menus, widgets, theme settings and options. WP-CLI writes are never staged.

= Does it support multisite? =

No. StagePatch is single-site only and refuses network activation. Activate it on the individual staging and live sites.

= I use nginx. Are uploaded bundles protected? =

Bundles and rollback backups live under `wp-content/uploads/stagepatch/` with unguessable names, plus `.htaccess` and `web.config` files that Apache and IIS honour. nginx ignores those files, so add a rule such as `location ~* /wp-content/uploads/stagepatch/ { deny all; }`.

= A large push times out. What now? =

Live keeps working after the connection drops and finishes the apply; staging shows an error because it stopped waiting. Open StagePatch → Import on live, or run `wp stagepatch batches`, to see the batch as applied. A second push is refused as already applied, so nothing is written twice. For very large batches, apply the exported zip on live with `wp stagepatch apply` instead of pushing.

= Which PHP extensions are needed? =

The zip extension (ZipArchive) on both sites, and GD or Imagick on live to regenerate image sizes.

= Does it merge databases? =

No. It records individual changes and replays them. Live data it does not know about is left alone.

= What happens when live changed the same page? =

The dry run flags a conflict and shows staging before, staging after and live now, field by field. You choose per conflict: take staging, keep live or skip.

= Can I undo? =

Yes. Every apply stores a snapshot of each touched object. Rollback restores them, and a failed apply rolls back on its own.

== Screenshots ==

1. The Changes screen on staging: every recorded edit with a before/after diff, ready to batch.
2. StagePatch Pro's Push to live screen with the inline live dry run, including a conflict found on live.
3. The Import screen on live: upload a bundle, verify its signature, review the dry run and resolve conflicts.
4. After apply: the titled apply log and a one-click Rollback to the pre-apply snapshot.
5. Settings: choose recorder (staging) or applier (live) mode and set the shared signing secret.
6. StagePatch Pro license activation.
7. The Workspace: staged items on one site, the dry run against the live content, and Apply to live.

== Changelog ==

= 1.0.0 =
* First public release. Everything listed below under 0.x is included.

= 0.2.0 =
* Workspace mode: stage edits inside one site. Live pages and posts are edited as staged copies, new posts stay staged when published, Trash stages a deletion, editors preview the staged site, and StagePatch → Workspace applies with a dry run and a rollback snapshot.
* Block editor panel for staged copies; list tables show what is staged.
* `wp stagepatch workspace [--apply]`.
* Review workflow: "Ready for review" per item and a `stagepatch_apply` capability so editors stage and approvers apply.

= 0.1.0 =
* Initial release.
