Configuration profiles and deployments

Plugin support is included in EMCP Tools 3.19.0 and later. Open Account → Configuration as a workspace owner on a paid Cloud plan. Connect your sites with Gateway access before capturing or comparing settings. Older plugin versions do not provide the managed settings reader.

Capture and compare

A workspace owner on a paid Cloud plan can open Account → Configuration. The source and comparison sites must have active Cloud connections and Gateway access issued by a WordPress administrator.

1. Choose a source site and name a new profile, or select an existing profile.
2. Choose Capture current settings. Cloud reads the source and saves a new, immutable revision. Capturing does not change WordPress settings.
3. Select a revision and one to ten explicit target sites.
4. Choose Preview differences. Each site reports its differences or a connection/compatibility failure. Failed sites do not stop comparisons of the other selected sites.

Previews are point-in-time comparisons. They do not approve a deployment. A subsequent capture adds a revision; it does not edit earlier revisions. If another administrator captures first, reload before retrying the newer revision.

Controlled deployment and rollback

Managed apply requires the managed deployment tool from 3.19.0 or later on every target. Each deployment needs a saved review and explicit approval. Installing the plugin or capturing a profile never applies settings automatically.

1. Select a saved revision and up to ten targets, then choose one target as the canary.
2. Choose Prepare deployment review. This reads fresh settings and saves the exact target list, site identities and before-images. It does not apply settings.
3. Review the displayed changes, including tool/module access and behavior changes. Check the approval box and choose Approve canary only, then explicitly apply to that canary.
4. Inspect the canary result before approving the remaining sites. In manual mode, each remaining site is applied separately. Workspaces with background execution enabled use the queue workflow below.
5. If a response is lost, choose Check to reconcile the saved operation. An uncertain result stops further rollout. Reusing an operation ID cannot apply the same change twice.

Apply approval expires fifteen minutes after preparation. A changed target configuration requires a new review; refreshing the page does not renew approval. Reconnected sites also require a fresh review. The saved deployment list survives page refreshes and web-process restarts.

Roll back restores only the option keys actually written by that operation. It preserves unrelated changes and rejects rollback if any affected key no longer matches the value written by the operation. It also restores absence when an option originally did not exist. Rollback remains available after apply approval expires, while workspace access and rollout permissions remain valid. There is no force-overwrite option.

The site requires an InnoDB options table. Settings and the durable operation receipt commit atomically on a dedicated database connection; a failed transaction leaves no partial settings change. These are EMCP-owned preferences and are written without third-party WordPress option-update hooks. Profiles cannot disable Cloud or the managed inspection/deployment tools, which are needed for recovery. Credentials, licences and site identity remain outside this write surface.

Deployment history has separate Active reviews and Archived reviews views, with twenty results per page. Each review shows creation and archive times, its changed settings, latest action/result times, and recovery status. Apply and rollback confirmation times are when Cloud first recorded a confirmed result, which may be later than the site write after a lost response. Older records without timestamps show Not recorded.

Choose Archive review after reviewing the result and checking the confirmation box. Completed or rolled-back reviews can be archived immediately; other resolved reviews must first reach their apply expiry. A running or uncertain operation must be checked before archival. Archiving frees an active review slot, closes further approval/apply, and retains before-images and operation IDs. Archived reviews still allow status checks and rollback, subject to current access, matching site identity, the site journal and conflict checks. An available rollback action is not a guarantee of successful restoration. There is no automatic deletion or unarchive action.

Initial deployment history is limited to 20 active reviews and 20 MiB of combined active and archived history per workspace, with a 3 MiB limit per review. Archiving does not free storage or remove the site’s durable journal. Each site keeps at most 1,000 durable operation records. Capacity exhaustion refuses new work rather than deleting recovery history.

Background execution

Background execution retains the ten-site limit. Review the saved diff, check the approval box and select Approve and queue canary. Cloud records that approval and the supervised worker applies only to the canary. You may leave the page; execution does not depend on an open browser. If background execution is unavailable on your deployment, the page offers manual site commands instead.

When the canary succeeds, the queue pauses at Awaiting approval. Inspect its result, then separately choose Approve and queue remaining sites. The worker processes the remaining saved targets sequentially. A one-site review finishes after the canary. Queueing or restarting a worker does not extend the original fifteen-minute apply deadline.

The page shows queued/running/finished state, per-site outcomes, command counts and timestamps. While a queue is active, it refreshes about every ten seconds while visible, except while you have checked the approval box. You can also refresh manually. Manual site commands and archival are blocked while the review’s background queue is active.

If a reply is lost or a worker stops mid-command, the next attempt checks the same durable operation ID first. A missing receipt permits a retry only while approval and access remain valid. There are at most three background command attempts per site per queued stage, including status checks; exhausted recovery or a rejected result halts the queue for review. Explicit reapproval starts a fresh attempt allowance without changing operation IDs or extending the deadline. A terminal failure on one target prevents further applies in that stage.

Cancel background deployment stops further applies. An already dispatched command may still finish; Cloud retains its result. Uncertain outcomes are checked within the remaining attempt allowance before stopping. Cancellation does not roll back applied settings. Use Check and Roll back after the queue stops if recovery is still needed. Revoked access or changed site identity may prevent automated reconciliation and require operator attention.

Background admission permits at most one running review per workspace and two background commands globally across worker replicas. Each command still consumes the workspace’s existing Cloud request budget. These are initial safety limits, not a fleet-throughput promise.

Included settings

The schema-v1 reader includes stored values for disabled tools, active modules, compact dispatcher mode, strict schemas, content-mirror delivery, site-context delivery, Themer forced rendering, memory approval and automatic memory summaries.

Credentials, tokens, licence details, site identity settings, free-text context, site profiles and management-access policy are excluded. Source site identity is retained only as revision metadata. Custom additions to the legacy settings-sync filter cannot enter managed profiles.

Missing keys in a profile mean leave the target unchanged, not reset it. Not stored in a preview means the target uses its local default or fallback; it does not prove that its effective runtime behavior differs. Tool/module lists are compared as sets. Previews flag tool/module, content-mirror and memory-approval differences for explicit review before any future deployment.

Initial limits and failures

• Up to 50 profiles and 100 revisions per profile in a workspace.
• Up to 256 KiB of settings per revision and 5 MiB of stored revision settings per workspace. This is a separate initial profile-history limit, not an increase to artifact storage.
• Up to ten sites per preview, with two reads in progress at a time. Each site read uses the workspace’s shared Cloud request budget. Gateway also bounds concurrent inspection requests; retry a busy comparison later.
• Unsupported plugins, disabled reader tools, identity conflicts, revoked credentials and unavailable sites cannot produce a ready preview. A site reconnecting during collection must be read again.

These limits apply equally to Freelancer, Agency and Enterprise. An Enterprise licence, whether a new 250-site license or an existing license with a retained allowance, does not increase the ten-site limit for each configuration review.

The existing Cloud settings-sync tool is a separate workflow with different semantics; a managed preview does not constrain or authorize that legacy tool.