Digitizer Site Worker for Aura -- WordPress 插件

开发者	benkalsky
更新时间	2026年9月18日 06:17
PHP版本:	7.4 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

SiteAgent turns every WordPress site into one an AI agent can safely operate — update, maintain, audit, and fix. Once the site is connected to Aura and its approval key is provisioned, mutating actions are gated behind human approval and recorded in a full audit trail; safe batch updates and block edits are snapshotted so they can be rolled back. It's the on-site half of Aura, the governed control room agencies use to run whole fleets of client sites alongside their servers, CDN, and DNS. Plugin and core updates are the riskiest thing you do on a live client site. SiteAgent makes them safer: safe batch updates run behind health checks and roll back automatically if the site breaks, and every plugin in that path is zip-snapshotted first. With Aura's approval key in place, an agent can't silently push a change — mutating actions wait for a human to approve them. Think of it as the undo button for AI on your clients' sites. Install this plugin on any WordPress site to connect it to Aura — no SSH, no wp-admin juggling, no manual logins. What You Can Do

Monitor site health — See WordPress version, PHP version, installed plugins & themes, database info, and disk usage in real time.
Update plugins, themes & core remotely — Push updates to any connected site from the Aura dashboard, no wp-admin login.
Safe batch updates with auto-rollback — Run chunked updates with health checks; if an update breaks the site, the plugin restores the previous version automatically.
Per-plugin rollback — Every update is zip-snapshotted first; restore any plugin to its last good state on demand.
Bulk translation & database upgrades — Update all language packs and run WordPress database migrations remotely.
One-click connect (magic link) — Connect a site to Aura straight from wp-admin — no manual token copy/paste.
AI-agent ready (27 MCP tools) — Exposes machine-readable, JSON-schema tools for AI-driven management, including SEO/accessibility/performance/broken-link auditors, on-site SEO-meta read/write (Rank Math, Yoast, SEOPress), and Gutenberg block read/edit. Read tools run on demand; mutating tools are approval-gated through Aura, and every call is audited.
Zero frontend impact — The plugin only registers REST API endpoints. No scripts, no styles, no database queries on visitor-facing page loads.

How It Works After activation, click Connect to Aura on the Settings → SiteAgent page for a one-click magic-link connection, or copy the Site Token shown once and paste it into your Aura dashboard manually. From that point, Aura communicates with your site over a signed, authenticated REST API to pull health data and push updates. Security Defence-in-depth protects every request:

WordPress Application Password — Standard WordPress auth with capability checks (manage_options / update_*). Only authorized administrators can trigger actions.
Hashed Site Token — A per-site token sent via the X-Aura-Token header. Only a SHA-256 hash is stored (never the raw token), compared timing-safely. Tokens from older versions migrate to a hash automatically.
Brute-force throttling — Repeated bad-token attempts from an IP are blocked.
Signed magic-link connect — The onboarding callback is HMAC-signed with a one-time secret and timestamp, so the token exchange can't be hijacked or replayed.
IP / Domain allowlist (optional) — Restrict API access to your Aura instance, with Cloudflare and reverse-proxy header support.

You can rotate the token anytime from Settings → SiteAgent → Regenerate Token. REST API Endpoints Core endpoints under /wp-json/aura/v1/:

GET /status — Full site health report
GET /updates — Check available updates (core, plugins, themes, translations)
POST /update/core / /update/plugin / /update/theme / /update/translations — Apply updates
POST /update/database — Run WordPress database upgrades
POST /connect — Magic-link token exchange (public, HMAC-signed, 10-minute expiry)

Version 2 endpoints under /wp-json/aura/v2/:

GET /health — HTTP, PHP fatal, white-screen and DB connectivity checks
POST /update/batch — Chunked batch updates with auto-rollback on health failure
POST /rollback/{plugin} — Restore a plugin from its most recent backup
POST /rules — Receive Aura's signed operator ruleset; carrying unbind: true it ends this site's binding instead

While a site is disconnected by Aura, every write endpoint answers 403 aura_site_unbound and reads keep working; the disconnect answer carries cleanup_complete and leftovers (what the site still holds), and GET /status reports unbound until the site is reconnected or the remaining Aura data is removed from the settings screen. MCP tools under /wp-json/aura/mcp/:

POST /tools/list / POST /tools/execute — Enumerate and run AI-agent tools
GET /context — Full site context for AI decision-making

AI Agent Tools (MCP) SiteAgent ships 29 built-in tools for AI agents. Read tools return information and run on demand; write tools change the site and are queued for human approval through Aura — an agent can never silently mutate a production site. Read tools:

get_site_context — WordPress/PHP/theme/plugin/disk/performance snapshot with detected issues
get_database_info — Database size, largest tables, autoloaded-options weight, expired transients
scan_security — Scored security posture (file-edit lockdown, debug exposure, SSL, default admin/prefix, open registration, PHP version)
scan_seo — SEO posture (search-engine visibility, permalinks, XML sitemap, site title) plus a sampled content audit (thin content, missing excerpts/featured images)
scan_a11y — Accessibility audit over sampled content (images missing alt text, non-descriptive link text, heading structure, document language)
perf_check — Performance posture (persistent object cache, OPcache, page-cache plugin, PHP version, autoload weight, active plugin count, memory limit)
scan_broken_links — Link triage over a content sample with no outbound HTTP (empty/anchor-only links, dev/staging hosts, unresolved internal links)
list_users — Users with roles and post counts, administrators flagged (never returns secrets)
check_health — Live health gate: HTTP status, PHP fatals, white-screen, database connectivity
scan_error_log — Tails and severity-groups the error log, surfacing recent fatals
check_vulnerabilities — Plugin update-currency check against WordPress.org (a version check, not a vulnerability/CVE feed; covers wp.org-hosted plugins)
check_core_checksums — Core-file integrity against the official WordPress.org checksum manifest (modified/missing/unexpected files, fetched over HTTPS only)
scan_executable_files — Uploads-directory observations: PHP/executable files, .htaccess overrides, and symlinks (reported, never followed)
audit_admin_accounts — Privileged-account facts: administrators with recency, admin capabilities outside the role, application-password counts, multisite super admins
audit_cron — Bounded WP-Cron inventory with sub-60-second-schedule and unresolved-callback fact-flags
audit_mcp_exposure — Which other MCP servers are registered on this site, and how many abilities pass the discovery rule such a server applies (abilities are registered site-wide, not per-plugin, so a server resolving targets from that registry picks up mutating ones outside SiteAgent's approval path). The counts describe the abilities, not what any server currently serves. Reports only; changes nothing
audit_agent_code — Executable code an AI agent authored or can author on this site: Angie code snippets (recorded, agent-authored, live per environment), the SiteAgent Power Pack's execute-php / file-write / wp-cli flags, and third-party exec stores. Counts and presence only; never file contents, never a verdict. Reports only; changes nothing
audit_rules — Whether a signed operator ruleset is present and how old it is, 24h block/warn counts, expired-but-listed rules, and the enforcement points in this build. Reports only; changes nothing
get_seo_meta — Read a post/page's SEO title, description, and focus keyword from the active SEO plugin (Rank Math, Yoast, or SEOPress)
list_page_blocks — Read a page's Gutenberg block structure (block names, attributes, nesting)
snapshot_get — Retrieve a stored snapshot of page content (reversible write metadata)

Write tools (approval-gated):

elementor_replay_ability — Executes an approved held Elementor write (destructive, requires Aura approval): claims the hold, re-judges it against the current ruleset, and runs the original Elementor mutation as the user who asked
update_plugin_safely — Backup, update, health-check, auto-rollback on failure
clear_caches — Flush object/opcode caches and detected page-cache plugins
cleanup_transients — Remove expired transients to reduce autoload bloat
cleanup_orphaned_assets — Find and remove unused media (dry-run by default)
backup_plugins — Zip-snapshot one or all active plugins as a rollback safety net
set_seo_meta — Write a post/page's SEO title / description / focus keyword on the active SEO plugin (Rank Math, Yoast, or SEOPress) — on-site, so it works even when a WAF blocks the plugin's own REST endpoint
update_page_block — Update a Gutenberg block's content or attributes (snapshot-first, reversible)
create_page_from_blocks — Create a new page from a Gutenberg block spec (draft-first)

Tools are classified by verb so the Aura Fleet gateway applies the right risk and approval policy automatically. Pro: the SiteAgent Power Pack Everything above is free and ships in this plugin. Agencies that need an agent to fix a site — not just report on it — can add the SiteAgent Power Pack, a separate companion plugin that registers higher-capability tools through this plugin's own tool registry. It is not included in this download and is not distributed on WordPress.org — the tools it adds execute code, so they don't belong in a hosted repository. It comes with the Aura Agency and Studio plans, or as SiteAgent Pro. What it adds:

read_file — read a text file from inside wp-content (jailed; refuses wp-config.php).
db_query — a single read-only SQL statement (SELECT / SHOW / EXPLAIN), row-capped.
write_file — write a file inside wp-content, snapshot-first so it can be rolled back.
run_wp_cli — run an allowlisted WP-CLI command, with no shell and no metacharacters.
execute_php — run a PHP snippet against the full WordPress API.

These are governed harder than anything in the free set, deliberately:

Off until you arm them. The write and code tools do nothing until the site owner sets an explicit constant in wp-config.php for each one. Installing the Power Pack alone enables no writes and no code execution.
Human approval, cryptographically enforced. Once the site holds Aura's approval key (provisioned when you connect the site), each of these calls requires a single-use, signed grant bound to that exact tool and its exact parameters — one only the Aura dashboard can mint, after a human approves the action. A leaked Site Token cannot run them. (Until a site has that key, the gate is dormant — so connect the site from Aura before arming anything.)
Reversible where it can be. File writes are snapshotted first, so there's a previous state to restore.

The safety model is governance, not a sandbox: execute_php is powerful by design. The controls are the constant you set, the human who approves the call, and the audit trail — not a promise that arbitrary code is safe. Learn more at my-aura.app/siteagent. About Aura Aura is a full-stack operations dashboard by Digitizer that brings servers, applications, DNS zones, and CDN pull zones from Cloudways, Hostinger VPS, Cloudflare, and Bunny.net into a single unified interface. SiteAgent extends that reach into every WordPress installation — so you can manage your entire infrastructure, including WordPress sites, from one place. Free to Use The plugin is completely free and open source (GPLv2+). You need a free or paid Aura account to connect your sites. Sign up at my-aura.app. Links

2.18.3

Security: redaction now reads a URL the way a browser's URL parser does. A backslash used as the path separator under http, https, ws, wss, ftp or a protocol-relative prefix (https://hooks.zapier.com\hooks\catch\1/…, also percent- or HTML-encoded) is redacted whole, including the part after the first backslash that earlier releases left in place.
Security: hostname characters a URL parser normalises away (fullwidth and mathematical letters, the ideographic full stop, zero-width and soft-hyphen characters — Unicode 18.0.0's IDNA mapping table) are mapped before matching, so ｈooks.zapier.com and hooks。zapier.com are redacted like hooks.zapier.com.
A URL parser's userinfo (a@b@host, an encoded slash or backslash inside it) and an empty port (host:/) are read as the parser reads them in the backslash and encoded forms above; a plain https://host:/path with nothing encoded is still matched by the older rule that wants a port digit (tracked as #121).
Redacting a very large field with millions of words now takes about three times the field's size in memory instead of eighteen.
Kept as they are: a backslash after a bare host with no scheme, Windows and UNC paths, file: URLs.

2.18.2

Security: redaction now decodes HTML references (including the double encoding WordPress itself produces on save and render), percent escapes and JSON escapes before looking for webhook URLs, so encoded or double-encoded Make, Zapier, Slack, Discord, IFTTT or Telegram hook URLs are now redacted.
The whole encoded word is replaced, not just the part that decoded into a match.
An encoded word whose host only looks like a webhook host is redacted too.
More than four encoding layers are replaced as a field.

2.18.1

Security: receiver URLs are now redacted even when their /, : or @ are percent-encoded or HTML-escaped, including numeric character references left without a trailing semicolon. Before this, an encoded Make, Zapier, Slack, Discord, IFTTT or Telegram hook URL could reach an agent unredacted.
The redaction walk now runs under a total node budget, so a self-referencing payload no longer runs until the request times out; a snapshot payload that exhausts the budget is withheld as payload: null, payload_redacted: true instead.
The gateway's early placeholder/grant check now only fires for a caller the IP/Origin allowlist and token throttle would already admit, so a throttled or disallowed caller no longer learns whether its token was right.
A legacy plaintext token is migrated before an MCP-path grant is verified.

2.18.0

Security: known webhook endpoints no longer leave the site in a REST response an AI agent reads — Aura's gateway tools, an MCP client using an Application Password, or any logged-in non-browser caller. Make, Zapier, Slack, Discord, IFTTT and Telegram hook URLs, and Elementor Pro form webhooks on any host, are replaced with aura-redacted:v1:<kind>, including inside Elementor page data and snapshot payloads. People in wp-admin, public visitors and Aura's own system calls see the real values.
An agent write that carries a redacted placeholder is refused (aura_redacted_placeholder): leave that field out and the stored value is kept.
Aura's own page snapshots stay complete: a signed header proves the read is Aura's (aura_unredacted_grant_invalid when it does not verify).
audit_rules reports redacted_24h and placeholder_refused_24h; /status reports redaction.

2.17.5

Plugin updates: on a host where PHP may not write or delete .php files (WP Engine is the proven case), every Aura-driven plugin change — the self-update, a single or batch plugin update, update_plugin_safely — is refused before anything is touched, with code: aura_php_writes_blocked (or aura_upgrade_dir_unwritable when wp-content/upgrade cannot be written at all). Such a host failed every update at unpack, and the restore that followed deleted the plugin's non-PHP files: SiteAgent's own readme.txt, and a plugin's CSS, JS and images. The check creates and removes a temporary file, and runs only when WordPress writes files directly.
Restore: a restore checks that it can finish — PHP can write .php files in the plugins directory, and every directory of the plugin is writable — before it deletes anything; otherwise it answers stage: preflight and leaves the directory untouched. A failed install that changed no file is no longer restored at all (restore_skipped: unchanged).
/status reports the host's last recorded answer as host: { php_writes, checked_at }, so Aura can stop sending updates to such a site.
update_plugin_safely returns the refusal's code and message (it lost both before).

2.17.4

Self-update: a package that carries the version already running is refused before anything changes. The verified download is inspected in place, the plugin is not backed up, and no install runs. Before this, a same-version request backed the plugin up, reinstalled over the live directory, refused and restored — and on one host lost readme.txt on every run. The refusal answers code: aura_self_update_same_version. An archive that cannot be read falls through to the previous path.
Self-update: when the post-install version check fails, the message now says what the evidence supports. A verified package with a different version means the upgrader did not replace the plugin directory (aura_self_update_not_replaced); without that proof both causes are named (aura_self_update_version_unchanged).
Self-update: a restore that cannot finish reports which stage failed (clear or extract), and the message says what is on disk. A failed clear can remove some files before it stops, so the directory is no longer described as untouched.

2.17.3

Snapshots: an overwrite_file() record now stores the sha256 of the content it wrote (replaced_with_sha256), and restoring that record puts the old bytes back ONLY while the file still holds exactly what the write left there. A file edited since is refused untouched (aura_file_changed_since); a file already holding the old bytes answers already and is not rewritten; a record taken without that hash — a direct POST /aura/v2/snapshot, or a Power Pack older than 0.2.5 — is refused as unfenced (aura_snapshot_unfenced), because nothing proves what it would be writing over.
Snapshots: every engine write to a path records a write_seq, taken under that path's lock and strictly increasing per target, so two writes to one file can be ordered after the fact — Aura rolls a run back in that order.
Snapshots: a file restore that cannot act says why with a code instead of a bare failure — aura_file_changed_since, aura_snapshot_unfenced, aura_snapshot_voided (the create's rollback record is gone) and aura_path_locked (another write to the path is in progress) — each answered as an HTTP 409 refusal rather than a 500. Restoring a created file that is already gone answers already.

2.17.2

Snapshots: every engine write to a path — create_file(), the new overwrite_file(), and the restore of a created file — runs under a per-path lock, so two agent writes racing one new file can no longer interleave in the same inode (a concurrent in-place overwrite passed the inode check). After a publish the target must hash to the recorded content, else the record is voided as interrupted and the staged bytes kept.
Snapshots: overwrite_file() replaces an existing file the way the engine creates one — old bytes snapshotted, new content staged beside the target with its own mode, then renamed over it: a reader sees the old file or the new, never a truncated one, and a short write touches nothing. The Power Pack's write_file adopts it in 0.2.5.
Snapshots: on a host without flock() the record and path locks are mkdir() directories (atomic everywhere; a lock older than five minutes is a crashed holder and is broken) instead of running unlocked, which let a stage sweep retire the record of a publish that then completed.
Snapshots: without link(), an executable created file that was edited since is verified in place and left where it is on file_changed_since — the claim by rename came first and the put-back refused exec bits, stranding the edited file under its .aura-restore-* name.
Snapshots: delete() removes the record's lock file with the record.

2.17.1

Snapshots: create_file() publishes without link(). Most managed hosts put link() in disable_functions for web PHP (Cloudways does), and 2.17.0 refused every new-file create there (unsupported_filesystem). Without link() the target is now claimed with an exclusive create — it refuses an existing path and returns an inode this call owns — and the bytes are written into that handle; ownership is checked by inode after the write, so nothing that took the path meanwhile is ever overwritten. What this mode gives up is the empty-to-complete jump: a reader in the milliseconds of the write can see the file grow. A short write leaves the entry empty, never truncated content. Restoring a created file that was edited since puts it back the same way instead of leaving it aside under its .aura-restore-* name. A publish interrupted mid-write is reconciled by the stage sweep: the record is voided and marked interrupted, the file is never deleted by a restore. create_file() answers published: link | write.
audit_agent_code: power_pack.create_publish says how a create lands on this host (link or write).

2.17.0

New read-only tool audit_agent_code: executable code an AI agent authored or can author on this site — Angie code snippets (recorded, agent-authored, and which are live in the environment the loader includes, correlated per snippet directory in both environments), the SiteAgent Power Pack's execute-php / file-write / wp-cli flags, and third-party exec stores (EMCP Pro sandbox, Atarim exec abilities). Counts and presence only; never file contents, never a verdict. Bounded (200 directory entries per environment, coverage.truncated), null for anything unreadable, { error } per subtree.
Snapshots: create_file() creates a NEW file with the engine owning the whole create — staged beside the target under a non-PHP name, recorded, then published with link() (atomic, no-clobber) — so no target ever exists without its record and no partial content is ever visible. Restoring the record claims the path with an atomic rename, verifies the claimed file, and removes it only while its bytes still match; a file edited since is put back and refused (file_changed_since), never deleted. The Power Pack's write_file adopts it in 0.2.4.
Tool metadata lists an empty parameter map as {} rather than [] (SA#83).
Generic SiteAgent mutations (batch entry, generic single update, generic rollback) renew the self-update lease between phases and heartbeat it from inside the upgrader's own sub-phases, so a slow download, unpack or install is never seized as stale, and a lost lease stops the entry rather than racing its successor (SA#80).
Every Aura-driven mutation of SiteAgent's own files — self-update, generic single update, the batch entry, the guarded rollback — refuses on a multisite network with aura_self_update_multisite_unsupported: the update lock is per site while the plugin directory is shared (SA#79). Other plugins are unaffected.
A rule-blocked call now says to scope the rule out of the site with sites, or release it.

2.16.2

/status's door fragment carries observation, a per-site door-version witness bumped atomically by every door-state mutation (never by a mere poll) and clock-floored so a restored backup can never reissue a value it already served, so Aura can order overlapping polls by the site's own witness instead of request timestamps; elementor.governor reports the current value. The observation witness requires InnoDB for wp_options and 64-bit PHP; without them ordering falls back to Aura's own request order for that site (elementor.governor reports why via observation_unsupported: engine or php32).
/status also accepts door_observation_seen — Aura's own last accepted observation, echoed back — so the site can bump its witness forward, clock-floored, when a restore rewound its own copy behind Aura's. Accepted for ANY non-negative integer the site's own witness could ever report (no magnitude ceiling — the witness only counts up); honoured only within a fixed headroom below the class ceiling, silently ignored (200, no bump, no error) above it.
elementor.governor reports counters_as_of beside the four _30d rolling counters, which observation does not cover; the counters themselves are int|null.
interrupted / running / held are null, not [], when their own queue could not be read, and observation is withheld entirely whenever any read behind the fragment was unreadable.
New door_write_unsupported reason reconnect_guard_unavailable: a governed write refuses outright on a $wpdb replacement that cannot disable reconnects, rather than risk a mutation replaying on a session this plugin no longer controls.
Door writes report a committed tri-state (true / false / unknown) and answer a retryable 503 with may_have_run: true whenever a commit cannot be proven — claims, holds, acks, and rotations alike; replay() now forwards claim()'s own error instead of a generic one.
Hold references and pending log-row reservations are derived from the request's own identity, so a retry after an ambiguous commit finds and reuses its own prior write instead of risking a duplicate.

2.16.1

/status door fragment and audit_mcp_exposure's elementor.governor carry binding, the site's current binding generation, so Aura can label a departed client's door-log entries without inferring the generation from the rows.

2.16.0

Elementor MCP door governance: every write through Elementor >= 4.3's official MCP server is held for approval in Aura unless an operator allow rule covers it; block refuses; every write that runs is snapshotted first on the site and recorded in a per-site door log Aura drains. New tools elementor_replay_ability, snapshot_get; new routes /aura/v1/door/reject, /aura/v1/door/ack; /status carries door; audit_mcp_exposure carries elementor.governor. Rules gain the allow effect and the design_system / page_create targets.

2.15.0

audit_mcp_exposure reports an elementor block: Elementor >= 4.3's official MCP module state, every elementor_mcp_consent row, every Elementor MCP… Application Password across all users (full detail), and the other Application Passwords of edit_posts users as counts. Every list is bounded (50 / 50 / 200) with a truncation flag beside it; no usermeta value over 256 KB is decoded; a scan that fails is reported as { error } in its place, never as an empty list. Read-only.
aura_worker_app_password_list() accepts an optional byte bound, enforced in the same statement that returns the value.

2.14.0

Feature: a self-update can now undo itself. Before installing, SiteAgent archives its current build — best-effort: a site without ZipArchive or with an unwritable backup directory still updates, and the result says backed_up: false so the caller knows this one had no way back. After installing, SiteAgent asks the new build to prove it came up. The proof is written by the build itself: a boot beacon recorded the first time the new code serves a request, and a fatal beacon recorded by a shutdown guard when the new code dies while loading. A build whose own records say it broke is rolled back to the archived one, and compiled copies are asked out of the opcode cache (best-effort — a host that restricts opcache_invalidate() may serve the old compiled code until its cache revalidates). The result reports exactly what happened (backed_up, verified, rolled_back). When neither record appears, the update stands and says it was not verified, never guessed.
Feature: one SiteAgent mutation at a time. Every path that can replace SiteAgent's own files — the self-update, the generic plugin update, a batch entry, the rollback endpoint — runs under a single per-site claim: taken by a conditional insert, seizable only after its holder has gone silent for ten minutes (a request that dies never releases), and released only by its owner. The self-update additionally renews the claim between its phases, so a slow step costs the lease nothing once the next phase begins. An overlapping request is answered "in progress" and touches nothing.
Hardening: backups follow a symlink only while its target stays inside the plugin folder — a link pointing out of the tree makes the backup report itself incomplete instead of copying unrelated files into an archive. Restores never delete through a symlink, root or child, and refuse to run at all when a link cannot be removed. A package carrying the version already running is refused, because its boot records could not be told apart from the old build's. Backup filenames carry a per-operation suffix, so two backups started in the same second never overwrite each other.

2.13.0

Feature: Aura can now disconnect a site in two phases, and the site refuses changes the moment it is told to. When Aura sends a disconnect, SiteAgent records it and every mutation on the site — SiteAgent's own write endpoints, MCP write tools, grant-signed calls, and any WordPress REST write made with the Application Password or site token of the departing connection — is answered 403 aura_site_unbound until the site is reconnected. Reads keep working, /status keeps answering, and Aura's own ruleset endpoint stays reachable so the disconnect can be finished or retried.
Feature: a departing connection's Application Password stops working everywhere, not just on the REST API. WordPress authenticates Application Passwords on XML-RPC as well, so a credential the disconnect could not revoke is now refused where WordPress decides whether it authenticates at all. Your own Application Passwords are untouched, and so is admin login.
Feature: the cleanup is proven, not assumed. SiteAgent revokes the Application Password(s) Aura minted, clears the stored ruleset and the gateway public key, forgets the connect bookkeeping, and deletes the site token LAST — and only when Aura says the disconnect is final. Every step is idempotent, runs in one fixed order, and continues past a step that failed. An interrupted disconnect finishes itself on the site's next page load (throttled, at most once every five minutes), so a site Aura can no longer reach still converges.
Feature: the answer to a disconnect now names what is still owed: leftovers lists the credentials or stores this site could not prove it had released (app_passwords, options, ruleset, grant_pubkey), alongside cleanup_complete. An empty list means only the shared site token was still outstanding; a non-empty one means Aura must keep waiting.
Feature: the settings screen tells you when Aura disconnected the site ("Disconnected by Aura at …") and offers Remove remaining Aura data — an admin-initiated teardown that runs the same proven cleanup, and only clears the disconnect record once everything it names, the site token included, is gone.
Feature: manually connected sites (those with no gateway public key, which therefore cannot verify a signed document) can be disconnected with a bare { "unbind": true, … } body on POST /wp-json/aura/v2/rules, authenticated by the site token alone. A site that DOES hold a gateway key refuses the bare form and requires the signed envelope.
Safety: every ruleset push now runs under the site-wide claim the connect flow already used, so a push, a disconnect and a reconnect can no longer interleave. A site already busy answers 503 aura_site_busy, which is retryable. A claim left behind by a killed request is taken over after two minutes rather than blocking the site indefinitely.
Safety: reconnecting (magic link) and Regenerate Token now settle the previous connection's outstanding cleanup BEFORE installing a new token, and release the disconnect record only after the replacement connection is installed and read back — so a reconnect that fails halfway leaves the site still refusing the departed connection instead of quietly reviving it.
Fix: a disconnect record damaged in the database is now REPAIRED — rebuilt from the site's own state, under the claim — and then torn down through the ordinary path. Previously a damaged record was a permanent dead end: the site refused every change and no control could clear it.
Diagnostics: /status reports unbound: { at, site_ref } while a disconnect is outstanding, and app_password_probe_unproven: { count, at, owner } when the site cannot prove an Application Password was revoked — the usual reason a disconnect never finishes. Both are bounded and contain no secrets.
New error codes: aura_site_unbound (403 — the site is disconnected), aura_site_busy (503 — retry), aura_unbind_incomplete (409 — something is still owed; the answer lists it), aura_unbind_unreadable (409 — the disconnect record could not be read, which is NOT the same as an incomplete cleanup), aura_unbind_unrepairable (409), aura_unbind_marker_stuck (500 — everything was removed but the record itself would not delete), aura_unbind_marker_malformed (500), aura_unbind_store_failed (500) and aura_ruleset_client_mismatch (409 — a disconnect addressed to a different Aura client), which the bare unkeyed form now checks too.
Compatibility: a 2.13 site that is never sent a disconnect behaves exactly as 2.12 did. Nothing on the site changes until Aura asks for one.

2.12.0

Feature: a rule can now apply to some of a client's sites instead of all of them. Aura's signed ruleset names the site each document was issued for, SiteAgent stores that identity, and a rule that lists the sites it applies to is enforced only where it belongs. Rules that name no sites are client-wide exactly as before.
Safety: a site that cannot prove its own identity — an older record, a document issued before this field existed — enforces EVERY rule rather than skipping the ones it cannot place. Scoping only ever narrows on proof.
Upgrade: the identity is recovered offline from the ruleset already stored, by re-verifying its signature locally. No new network traffic, and a site whose ruleset has not changed since the upgrade is repaired on its next request rather than waiting for the next push.

2.11.0 and earlier

WordPress.org truncates a Changelog over 5,000 words, and this plugin's history is longer than that. The entries for 2.11.0 and every release before it were moved out of this file verbatim and are kept in full at: https://github.com/Digitizers/SiteAgent/blob/main/docs/changelog-archive.md

SiteAgent for Aura

标签

下载

详情介绍:

安装:

屏幕截图:

升级注意事项:

常见问题:

更新日志: