ConfigOps – Configuration Management

The undo button WordPress forgot

WordPress shows you the settings form. ConfigOps shows you what the save actually changed.

Agent-ready. Human by default.

WordPress Abilities and machine-readable JSON WP-CLI commands let an authorized tool list recorded changes, inspect redacted diffs, control named Change Sessions, and run the restore checks without writing. Compatible MCP adapters can expose the same abilities as agent tools.

Humans retain write authority by default. A service user with the separate configops_apply capability can replace human confirmation for one mutation only by sending dangerouslyRunUndo: true or --dangerously-run-undo. That acknowledgement does not bypass scope, conflict, reference, lock, audit, verification, or compensation checks. ConfigOps exposes no generic option writer, raw SQL tool, or plugin installer.

Visit the ConfigOps website or read the documentation.

Change a supported WordPress or plugin setting as usual. ConfigOps automatically opens an isolated observation for that save, groups the resulting writes, and reduces repeated writes to the same option into the original-to-final change.

A compact evidence card states how many values WordPress wrote, separates likely decisions from housekeeping, and links to the stored diff. Whole-save Undo appears only when every recorded value is restorable and still passes the conflict check.

Version 0.7 adds private Configuration Packs. Save a completed Change Session as a declarative .configops.json desired state, remove individual settings, import it on another website, inspect the complete Apply Preview, and apply it as an ordinary undoable History session.

Packs are not database snapshots. They contain no old values, autoload flags, table names, SQL, or executable code. Complete options containing protected data are excluded before export. Import rechecks the destination’s WordPress and plugin versions, adapter ownership, local references, protected values, current baselines, and site scope before writing. URLs, absolute paths, email addresses, and environment-specific values are warned instead of silently rewritten.

Private Packs remain deliberately local files. Version 0.7 includes no cloud, marketplace, account, synchronization, variable substitution, or drift engine.

One action. The hidden writes behind it. A clear diff. A conflict-checked undo.

What a settings save actually wrote

ConfigOps is not a generic activity log. It does more than report that somebody clicked Save: it records the supported Options API writes caused by the request, separates likely decisions from plugin housekeeping, and attributes the responsible component and code path where possible.

ConfigOps is not a backup. It restores only supported setting values that still match the recorded state, so a later legitimate change is not silently overwritten.

ConfigOps is not plugin-version rollback. It works with configuration values, not plugin or theme code.

What ConfigOps records and checks

• Agent-ready discovery through the native WordPress Abilities API.
• Machine-readable JSON wp configops commands designed for scripts and language-model tool use.
• Read-only restore planning that checks scope, conflicts, references, autoload state, filtered option reads, adapters, and verified generic-array paths without writing.
• Explicit agent undo for one mutation when configops_apply and the dangerously-run-undo acknowledgement are both present; all ordinary restore checks remain active.
• Automatic local evidence for authorized settings changes made through WordPress admin, REST, and WP-CLI requests.
• Plain-language nested diffs that turn option arrays into recognizable settings.
• An immediate link to the recorded diff and whole-save Undo only when every value passes the restore policy.
• Named Change Sessions for planned maintenance, support cases, and investigations that span several requests.
• Private declarative Configuration Packs exported from completed Change Sessions.
• Complete Apply Preview with requirements, matching state, changes, skips, conflicts, and portability warnings.
• One-use, expiring Apply plans with destination drift checks before the first write.
• Pack application recorded in History with Pack ID/version provenance and ordinary whole-session Undo.
• Provenance for the user, request, component, code path, capture-time plugin version, and direct-versus-registered source basis where ConfigOps can determine it.
• Secret redaction before mutation history is stored.
• Conflict checks before every restore.
• Isolated site evidence across network-active WordPress Multisite installations.
• Multi-Network boundaries tied to each site’s real network ownership, including fail-closed foreign-network writes and lifecycle switches.
• A separate Network Admin ledger for Network Options changes.
• Named Network Change Sessions for planned work that spans several Network Admin requests.
• Mutation-level undo for complete Network Options additions and updates.
• Optional experimental undo for verified keys in ordinary, unclaimed associative wp_options arrays.

Safety before convenience

Probable credentials are removed before mutation history is stored. Undo first checks that the current value still matches the observed value. An interrupted or incomplete observation loses whole-save undo instead of pretending its evidence is safe.

Direct writes to custom plugin tables are recorded as value-free warnings. ConfigOps does not store raw SQL and does not claim it can reverse data it does not understand.

Site icons, site logos, and supported Yoast logo and social-image settings show the referenced attachment name, file type, dimensions, thumbnail, and missing state. Yoast publisher-policy, content-ignore, and LLMs.txt page IDs show bounded page identity instead of a bare database ID. ConfigOps never copies or deletes referenced media or content.

All evidence remains in the website database. ConfigOps does not send observation data to pyrra or another external service. Suggested disclosure text is added to WordPress’s privacy-policy guide.

Tested component contracts

The current release includes pinned adapters for:

• WordPress Core 7.0–7.1
• WP Mail SMTP Free 4.7–4.9
• Yoast SEO Free 28.1–28.3
• WooCommerce 10.3, 10.7, 10.9, and 11.0 core settings, feature flags, performance controls, and Point of Sale receipt details

These plugin ranges cover every version line that the official WordPress.org usage API exposed separately on 2026-08-24. CI rechecks that list and fails when a newly visible line has no real-plugin contract. Every contract also audits the release’s published option map, registered defaults, or Settings API and fails on settings ConfigOps still treats as unknown. WordPress.org combines the remaining installations under “other” without disclosing their versions, so that bucket is not advertised as verified support.

The Support contracts screen lists each tested plugin version, mapped settings family, refused operation, and undo level. The WooCommerce contract covers core Options API settings, feature flags, REST and catalog performance controls, and Point of Sale receipt details. HPOS datastore switches and Cost of Goods are explained but not undone; orders, products, tax-rate tables, shipping zones, webhooks, extension gateways, and scheduled jobs are not rolled back. An untested component version keeps its observed evidence but disables automatic undo.

Plugins without a dedicated adapter still retain their source slug and, when WordPress can resolve the owning plugin file, the version observed when the setting was saved. When WordPress Core performs the final write for an option that a plugin registered through the Settings API, the review says Setting registered by instead of pretending that the plugin directly called the Options API. Their nested leaf keys receive readable labels, but ConfigOps explicitly marks the plugin meaning as unmapped instead of inventing semantics.

Multisite in version 0.7

On a network-active installation, each site keeps its own isolated evidence lifecycle. On Multi-Network installations, ConfigOps derives the network from the actual site record after every internal context switch, refuses lifecycle work that crosses networks, and excludes foreign Network Options writes from the current network ledger. An affected open capture is marked incomplete instead of silently appearing trustworthy. Network Admin receives a separate network-wide ledger for supported Network Options API changes, with guarded mutation-level undo for complete additions and updates.

Network option deletes remain review-only because WordPress reports them after the previous value is gone. Named Network Change Sessions can group network-owned evidence, but whole-network-change undo, cross-site aggregation, and bulk operations are not available.

Version 0.7 is a local single-site and Multisite evidence layer plus private, site-scoped Configuration Packs for supported WordPress settings. Packs are not available for the Network Options ledger. ConfigOps is not a staging service, backup, content migration, database synchronization, fleet manager, or generic activity log.