{"id":291225,"date":"2026-04-02T19:33:16","date_gmt":"2026-04-02T19:33:16","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/auraworker\/"},"modified":"2026-08-23T17:49:12","modified_gmt":"2026-08-23T17:49:12","slug":"digitizer-site-worker","status":"publish","type":"plugin","link":"https:\/\/te.wordpress.org\/plugins\/digitizer-site-worker\/","author":9810718,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"2.10.3","stable_tag":"2.10.3","tested":"7.1","requires":"6.2","requires_php":"7.4","requires_plugins":null,"header_name":"SiteAgent for Aura","header_author":"Digitizer","header_description":"Remote site management agent for Aura dashboard. Enables secure updates, health monitoring, and maintenance operations via REST API.","assets_banners_color":"12132b","last_updated":"2026-08-23 17:49:12","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/my-aura.app\/siteagent","header_author_uri":"https:\/\/www.digitizer.studio","rating":0,"author_block_rating":0,"active_installs":0,"downloads":1070,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"2.0.0":{"tag":"2.0.0","author":"benkalsky","date":"2026-06-11 23:19:26"},"2.0.1":{"tag":"2.0.1","author":"benkalsky","date":"2026-06-12 00:02:20"},"2.0.2":{"tag":"2.0.2","author":"benkalsky","date":"2026-06-18 22:20:58"},"2.1.0":{"tag":"2.1.0","author":"benkalsky","date":"2026-06-24 16:08:30"},"2.10.0":{"tag":"2.10.0","author":"benkalsky","date":"2026-08-21 23:48:43"},"2.10.1":{"tag":"2.10.1","author":"benkalsky","date":"2026-08-22 01:21:59"},"2.10.2":{"tag":"2.10.2","author":"benkalsky","date":"2026-08-23 00:39:23"},"2.10.3":{"tag":"2.10.3","author":"benkalsky","date":"2026-08-23 17:49:12"},"2.2.1":{"tag":"2.2.1","author":"benkalsky","date":"2026-06-25 20:06:07"},"2.2.2":{"tag":"2.2.2","author":"benkalsky","date":"2026-06-25 20:40:16"},"2.2.3":{"tag":"2.2.3","author":"benkalsky","date":"2026-06-29 11:00:51"},"2.2.4":{"tag":"2.2.4","author":"benkalsky","date":"2026-06-29 18:15:03"},"2.3.0":{"tag":"2.3.0","author":"benkalsky","date":"2026-06-29 22:19:56"},"2.6.1":{"tag":"2.6.1","author":"benkalsky","date":"2026-07-04 00:31:59"},"2.7.0":{"tag":"2.7.0","author":"benkalsky","date":"2026-07-04 19:17:30"},"2.7.1":{"tag":"2.7.1","author":"benkalsky","date":"2026-07-04 21:36:05"},"2.8.0":{"tag":"2.8.0","author":"benkalsky","date":"2026-07-11 19:08:09"},"2.8.1":{"tag":"2.8.1","author":"benkalsky","date":"2026-07-13 00:17:58"},"2.8.2":{"tag":"2.8.2","author":"benkalsky","date":"2026-07-15 09:50:40"},"2.9.0":{"tag":"2.9.0","author":"benkalsky","date":"2026-08-20 18:23:53"},"2.9.1":{"tag":"2.9.1","author":"benkalsky","date":"2026-08-20 20:45:25"}},"upgrade_notice":{"2.10.3":"<ul>\n<li>Fix (security): <strong>&quot;Regenerate Token&quot; revealed a new site token without ever\nstoring it.<\/strong> The option was registered as a read-only setting, and the\ncallback enforcing that ran on every write \u2014 not only on the settings form \u2014\nso the handler&#039;s write was discarded while the one-time reveal still\nappeared. Two consequences: an admin rotating a leaked token was told it was\nrevoked when the old token stayed valid, and a site disconnected from the\ndashboard could not be reconnected, because no token the screen displayed\never authenticated. The token is no longer registered as a setting (it is\ndisplay-only, so nothing submits it), and regeneration now stores the new\nhash with a single compare-and-swap, out of reach of any option filter \u2014 a\ntoken is revealed only when that one statement reports it wrote the row, and\na site whose row is missing or empty can be given its first token the same\nway.<\/li>\n<\/ul>","2.10.2":"<ul>\n<li>Fix: a site moved from one Aura client to another while the old client&#039;s\nlast push was still in flight could end up holding the old client&#039;s ruleset\nand refuse the new client&#039;s rules until it was reconnected. The connect\ncallback now names the client the site belongs to (a signed, optional field\n\u2014 older dashboards keep working unchanged) and writes that binding into the\nruleset store itself, so a ruleset for any other client is refused from then\non, whatever was in flight.<\/li>\n<\/ul>","2.10.1":"<p>Fixes audit_rules under-reporting the current hour&#039;s block\/warn counts on\nsites with a persistent object cache, and a spurious 500 when two first\nrulesets race. No change to enforcement. Recommended.<\/p>","2.10.0":"<p>Operator rules: write &quot;do not touch checkout&quot; once in Aura and every connected\nsite refuses the matching change \u2014 even an approved one \u2014 until the rule is\nreleased. No ruleset, no change in behaviour. Recommended for every site.<\/p>","2.9.1":"<p>Security hardening: tools that change your site can no longer be run through\nanother plugin&#039;s MCP server without an approval grant. Recommended for every\nsite, and especially any running a second AI assistant alongside SiteAgent. No\naction required; the Aura connection and read-only tools are unaffected.<\/p>","2.9.0":"<p>Adds five read-only audit tools, including one that reports which other MCP\nservers are registered on the site and how many of your abilities are\ndiscoverable to one \u2014 worth running if anything else here exposes an AI\nassistant. Nothing existing changes behaviour; no action required.<\/p>","2.8.2":"<p>Security hardening: snapshot restores now reject tampered payloads instead of\nunserializing arbitrary objects. Recommended for all users. No action required.<\/p>","2.8.1":"<p>Documentation only \u2014 the listing now describes the optional Power Pack companion\nplugin and its governance model. No code changes; no action required.<\/p>","2.8.0":"<p>Internal snapshot-engine primitives (groundwork for reversible Elementor and\nbulk-post editing, not yet exposed over the API) and a clearer SEO-meta\nwrite-failure error. No action required; existing connections keep working.<\/p>","2.3.0":"<p>Token-only connection: the Aura Site Token alone now authorizes site management. Existing connections keep working \u2014 no action required.<\/p>","2.2.4":"<p>Fixes one-click &quot;Connect to Aura&quot;: the magic-link onboarding now targets the Aura app host (<code>app.my-aura.app<\/code>) instead of the marketing domain, so connect works out of the box. Sites that set the <code>AURA_DASHBOARD_URL<\/code> constant are unaffected.<\/p>","2.2.3":"<p>Accuracy fixes for the auditor tools: <code>set_seo_meta<\/code> refreshes Yoast&#039;s cache, <code>perf_check<\/code> counts all WP 6.6+ autoload values, <code>scan_broken_links<\/code> reports true totals, <code>scan_seo<\/code> scores missing excerpts, and <code>scan_a11y<\/code> checks page language. No content changes.<\/p>","2.2.2":"<p>Adds on-site SEO-meta tools (<code>get_seo_meta<\/code> \/ <code>set_seo_meta<\/code>) for Rank Math, Yoast, and SEOPress \u2014 read and update a page&#039;s SEO title, description, and focus keyword, even where a WAF blocks the SEO plugin&#039;s REST endpoint. Writes are approval-gated through Aura.<\/p>","2.2.1":"<p>Adds two read-only auditor tools \u2014 <code>perf_check<\/code> and <code>scan_broken_links<\/code> \u2014 for performance and link triage across your fleet. No changes to your site; <code>scan_broken_links<\/code> performs no outbound HTTP.<\/p>","2.2.0":"<p>Adds two read-only auditor tools \u2014 <code>scan_seo<\/code> and <code>scan_a11y<\/code> \u2014 for SEO and accessibility checks across your fleet. No changes to your site; run on demand through Aura.<\/p>","2.1.0":"<p>Adds five new MCP agent tools (database info, security scan, user list, cache flush, transient cleanup). Read tools run on demand; cache\/transient tools are mutating and gated by Aura&#039;s approval policy.<\/p>","2.0.2":"<p>Fixes the plugin page screenshot caption rendering on WordPress.org. No code changes.<\/p>","2.0.1":"<p>Documentation update \u2014 corrected feature list, security description, endpoint reference, and admin menu location. No code changes.<\/p>","2.0.0":"<p>Major update: plugin rollback\/backup, site health checks, magic-link admin access, and MCP tools. Tested with WordPress 7.0. Recommended for all users.<\/p>","1.3.5":"<p>Enhanced security with timing-safe comparison and IP whitelisting. Recommended for all users.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3580090,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3580090,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3580103,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3580103,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["2.0.0","2.0.1","2.0.2","2.1.0","2.10.0","2.10.1","2.10.2","2.10.3","2.2.1","2.2.2","2.2.3","2.2.4","2.3.0","2.6.1","2.7.0","2.7.1","2.8.0","2.8.1","2.8.2","2.9.0","2.9.1"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3497775,"resolution":"1","location":"assets","locale":"","width":3454,"height":1886},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3497775,"resolution":"2","location":"assets","locale":"","width":3452,"height":1922},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3497775,"resolution":"3","location":"assets","locale":"","width":3452,"height":1922},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3497775,"resolution":"4","location":"assets","locale":"","width":3454,"height":1924}},"screenshots":{"1":"The SiteAgent settings page in WordPress admin (under the Settings menu) showing the Site Token and connection status.","2":"The Aura dashboard showing connected WordPress sites with health status, WordPress version, PHP version, and available updates.","3":"Remote plugin update in progress from the Aura dashboard \u2014 select a plugin and update it with a single click."}},"plugin_section":[],"plugin_tags":[2353,569,732,2550,41933],"plugin_category":[52],"plugin_contributors":[260321],"plugin_business_model":[],"class_list":["post-291225","plugin","type-plugin","status-publish","hentry","plugin_tags-ai","plugin_tags-automation","plugin_tags-maintenance","plugin_tags-updates","plugin_tags-wordpress-management","plugin_category-performance","plugin_contributors-benkalsky","plugin_committers-benkalsky","plugin_support_reps-godigitizer"],"banners":{"banner":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/banner-772x250.png?rev=3580103","banner_2x":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/banner-1544x500.png?rev=3580103","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/icon-128x128.png?rev=3580090","icon_2x":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/icon-256x256.png?rev=3580090","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/screenshot-1.png?rev=3497775","caption":"The SiteAgent settings page in WordPress admin (under the Settings menu) showing the Site Token and connection status."},{"src":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/screenshot-2.png?rev=3497775","caption":"The Aura dashboard showing connected WordPress sites with health status, WordPress version, PHP version, and available updates."},{"src":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/screenshot-3.png?rev=3497775","caption":"Remote plugin update in progress from the Aura dashboard \u2014 select a plugin and update it with a single click."},{"src":"https:\/\/ps.w.org\/digitizer-site-worker\/assets\/screenshot-4.png?rev=3497775","caption":""}],"raw_content":"<!--section=description-->\n<p><strong>SiteAgent<\/strong> turns every WordPress site into one an AI agent can safely operate \u2014 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 <a href=\"https:\/\/my-aura.app\">Aura<\/a>, the governed control room agencies use to run whole fleets of client sites alongside their servers, CDN, and DNS.<\/p>\n\n<p>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 <strong>roll back automatically<\/strong> 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 \u2014 mutating actions wait for a human to approve them. Think of it as the undo button for AI on your clients' sites.<\/p>\n\n<p>Install this plugin on any WordPress site to connect it to Aura \u2014 no SSH, no wp-admin juggling, no manual logins.<\/p>\n\n<h4>What You Can Do<\/h4>\n\n<ul>\n<li><strong>Monitor site health<\/strong> \u2014 See WordPress version, PHP version, installed plugins &amp; themes, database info, and disk usage in real time.<\/li>\n<li><strong>Update plugins, themes &amp; core remotely<\/strong> \u2014 Push updates to any connected site from the Aura dashboard, no wp-admin login.<\/li>\n<li><strong>Safe batch updates with auto-rollback<\/strong> \u2014 Run chunked updates with health checks; if an update breaks the site, the plugin restores the previous version automatically.<\/li>\n<li><strong>Per-plugin rollback<\/strong> \u2014 Every update is zip-snapshotted first; restore any plugin to its last good state on demand.<\/li>\n<li><strong>Bulk translation &amp; database upgrades<\/strong> \u2014 Update all language packs and run WordPress database migrations remotely.<\/li>\n<li><strong>One-click connect (magic link)<\/strong> \u2014 Connect a site to Aura straight from wp-admin \u2014 no manual token copy\/paste.<\/li>\n<li><strong>AI-agent ready (27 MCP tools)<\/strong> \u2014 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.<\/li>\n<li><strong>Zero frontend impact<\/strong> \u2014 The plugin only registers REST API endpoints. No scripts, no styles, no database queries on visitor-facing page loads.<\/li>\n<\/ul>\n\n<h4>How It Works<\/h4>\n\n<p>After activation, click <strong>Connect to Aura<\/strong> on the <strong>Settings \u2192 SiteAgent<\/strong> 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.<\/p>\n\n<h4>Security<\/h4>\n\n<p>Defence-in-depth protects every request:<\/p>\n\n<ol>\n<li><strong>WordPress Application Password<\/strong> \u2014 Standard WordPress auth with capability checks (<code>manage_options<\/code> \/ <code>update_*<\/code>). Only authorized administrators can trigger actions.<\/li>\n<li><strong>Hashed Site Token<\/strong> \u2014 A per-site token sent via the <code>X-Aura-Token<\/code> header. Only a SHA-256 <strong>hash<\/strong> is stored (never the raw token), compared timing-safely. Tokens from older versions migrate to a hash automatically.<\/li>\n<li><strong>Brute-force throttling<\/strong> \u2014 Repeated bad-token attempts from an IP are blocked.<\/li>\n<li><strong>Signed magic-link connect<\/strong> \u2014 The onboarding callback is HMAC-signed with a one-time secret and timestamp, so the token exchange can't be hijacked or replayed.<\/li>\n<li><strong>IP \/ Domain allowlist<\/strong> (optional) \u2014 Restrict API access to your Aura instance, with Cloudflare and reverse-proxy header support.<\/li>\n<\/ol>\n\n<p>You can rotate the token anytime from <strong>Settings \u2192 SiteAgent \u2192 Regenerate Token<\/strong>.<\/p>\n\n<h4>REST API Endpoints<\/h4>\n\n<p>Core endpoints under <code>\/wp-json\/aura\/v1\/<\/code>:<\/p>\n\n<ul>\n<li><code>GET \/status<\/code> \u2014 Full site health report<\/li>\n<li><code>GET \/updates<\/code> \u2014 Check available updates (core, plugins, themes, translations)<\/li>\n<li><code>POST \/update\/core<\/code> \/ <code>\/update\/plugin<\/code> \/ <code>\/update\/theme<\/code> \/ <code>\/update\/translations<\/code> \u2014 Apply updates<\/li>\n<li><code>POST \/update\/database<\/code> \u2014 Run WordPress database upgrades<\/li>\n<li><code>POST \/connect<\/code> \u2014 Magic-link token exchange (public, HMAC-signed, 10-minute expiry)<\/li>\n<\/ul>\n\n<p>Version 2 endpoints under <code>\/wp-json\/aura\/v2\/<\/code>:<\/p>\n\n<ul>\n<li><code>GET \/health<\/code> \u2014 HTTP, PHP fatal, white-screen and DB connectivity checks<\/li>\n<li><code>POST \/update\/batch<\/code> \u2014 Chunked batch updates with auto-rollback on health failure<\/li>\n<li><code>POST \/rollback\/{plugin}<\/code> \u2014 Restore a plugin from its most recent backup<\/li>\n<\/ul>\n\n<p>MCP tools under <code>\/wp-json\/aura\/mcp\/<\/code>:<\/p>\n\n<ul>\n<li><code>POST \/tools\/list<\/code> \/ <code>POST \/tools\/execute<\/code> \u2014 Enumerate and run AI-agent tools<\/li>\n<li><code>GET \/context<\/code> \u2014 Full site context for AI decision-making<\/li>\n<\/ul>\n\n<h4>AI Agent Tools (MCP)<\/h4>\n\n<p>SiteAgent ships <strong>27 built-in tools<\/strong> for AI agents. Read tools return information and run on demand; write tools change the site and are queued for human approval through Aura \u2014 an agent can never silently mutate a production site.<\/p>\n\n<p>Read tools:<\/p>\n\n<ul>\n<li><code>get_site_context<\/code> \u2014 WordPress\/PHP\/theme\/plugin\/disk\/performance snapshot with detected issues<\/li>\n<li><code>get_database_info<\/code> \u2014 Database size, largest tables, autoloaded-options weight, expired transients<\/li>\n<li><code>scan_security<\/code> \u2014 Scored security posture (file-edit lockdown, debug exposure, SSL, default admin\/prefix, open registration, PHP version)<\/li>\n<li><code>scan_seo<\/code> \u2014 SEO posture (search-engine visibility, permalinks, XML sitemap, site title) plus a sampled content audit (thin content, missing excerpts\/featured images)<\/li>\n<li><code>scan_a11y<\/code> \u2014 Accessibility audit over sampled content (images missing alt text, non-descriptive link text, heading structure, document language)<\/li>\n<li><code>perf_check<\/code> \u2014 Performance posture (persistent object cache, OPcache, page-cache plugin, PHP version, autoload weight, active plugin count, memory limit)<\/li>\n<li><code>scan_broken_links<\/code> \u2014 Link triage over a content sample with no outbound HTTP (empty\/anchor-only links, dev\/staging hosts, unresolved internal links)<\/li>\n<li><code>list_users<\/code> \u2014 Users with roles and post counts, administrators flagged (never returns secrets)<\/li>\n<li><code>check_health<\/code> \u2014 Live health gate: HTTP status, PHP fatals, white-screen, database connectivity<\/li>\n<li><code>scan_error_log<\/code> \u2014 Tails and severity-groups the error log, surfacing recent fatals<\/li>\n<li><code>check_vulnerabilities<\/code> \u2014 Plugin update-currency check against WordPress.org (a version check, not a vulnerability\/CVE feed; covers wp.org-hosted plugins)<\/li>\n<li><code>check_core_checksums<\/code> \u2014 Core-file integrity against the official WordPress.org checksum manifest (modified\/missing\/unexpected files, fetched over HTTPS only)<\/li>\n<li><code>scan_executable_files<\/code> \u2014 Uploads-directory observations: PHP\/executable files, .htaccess overrides, and symlinks (reported, never followed)<\/li>\n<li><code>audit_admin_accounts<\/code> \u2014 Privileged-account facts: administrators with recency, admin capabilities outside the role, application-password counts, multisite super admins<\/li>\n<li><code>audit_cron<\/code> \u2014 Bounded WP-Cron inventory with sub-60-second-schedule and unresolved-callback fact-flags<\/li>\n<li><code>audit_mcp_exposure<\/code> \u2014 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<\/li>\n<li><code>audit_rules<\/code> \u2014 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<\/li>\n<li><code>get_seo_meta<\/code> \u2014 Read a post\/page's SEO title, description, and focus keyword from the active SEO plugin (Rank Math, Yoast, or SEOPress)<\/li>\n<li><code>list_page_blocks<\/code> \u2014 Read a page's Gutenberg block structure (block names, attributes, nesting)<\/li>\n<\/ul>\n\n<p>Write tools (approval-gated):<\/p>\n\n<ul>\n<li><code>update_plugin_safely<\/code> \u2014 Backup, update, health-check, auto-rollback on failure<\/li>\n<li><code>clear_caches<\/code> \u2014 Flush object\/opcode caches and detected page-cache plugins<\/li>\n<li><code>cleanup_transients<\/code> \u2014 Remove expired transients to reduce autoload bloat<\/li>\n<li><code>cleanup_orphaned_assets<\/code> \u2014 Find and remove unused media (dry-run by default)<\/li>\n<li><code>backup_plugins<\/code> \u2014 Zip-snapshot one or all active plugins as a rollback safety net<\/li>\n<li><code>set_seo_meta<\/code> \u2014 Write a post\/page's SEO title \/ description \/ focus keyword on the active SEO plugin (Rank Math, Yoast, or SEOPress) \u2014 on-site, so it works even when a WAF blocks the plugin's own REST endpoint<\/li>\n<li><code>update_page_block<\/code> \u2014 Update a Gutenberg block's content or attributes (snapshot-first, reversible)<\/li>\n<li><code>create_page_from_blocks<\/code> \u2014 Create a new page from a Gutenberg block spec (draft-first)<\/li>\n<\/ul>\n\n<p>Tools are classified by verb so the Aura Fleet gateway applies the right risk and approval policy automatically.<\/p>\n\n<h4>Pro: the SiteAgent Power Pack<\/h4>\n\n<p>Everything above is free and ships in this plugin. Agencies that need an agent to <em>fix<\/em> a site \u2014 not just report on it \u2014 can add the <strong>SiteAgent Power Pack<\/strong>, a separate companion plugin that registers higher-capability tools through this plugin's own tool registry.<\/p>\n\n<p>It is <strong>not<\/strong> included in this download and is <strong>not<\/strong> distributed on WordPress.org \u2014 the tools it adds execute code, so they don't belong in a hosted repository. It comes with the Aura <strong>Agency<\/strong> and <strong>Studio<\/strong> plans, or as <strong>SiteAgent Pro<\/strong>.<\/p>\n\n<p>What it adds:<\/p>\n\n<ul>\n<li><code>read_file<\/code> \u2014 read a text file from inside wp-content (jailed; refuses wp-config.php).<\/li>\n<li><code>db_query<\/code> \u2014 a single read-only SQL statement (SELECT \/ SHOW \/ EXPLAIN), row-capped.<\/li>\n<li><code>write_file<\/code> \u2014 write a file inside wp-content, snapshot-first so it can be rolled back.<\/li>\n<li><code>run_wp_cli<\/code> \u2014 run an allowlisted WP-CLI command, with no shell and no metacharacters.<\/li>\n<li><code>execute_php<\/code> \u2014 run a PHP snippet against the full WordPress API.<\/li>\n<\/ul>\n\n<p>These are governed harder than anything in the free set, deliberately:<\/p>\n\n<ol>\n<li><strong>Off until you arm them.<\/strong> The write and code tools do nothing until the site owner sets an explicit constant in <code>wp-config.php<\/code> for each one. Installing the Power Pack alone enables no writes and no code execution.<\/li>\n<li><strong>Human approval, cryptographically enforced.<\/strong> 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 \u2014 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 \u2014 so connect the site from Aura before arming anything.)<\/li>\n<li><strong>Reversible where it can be.<\/strong> File writes are snapshotted first, so there's a previous state to restore.<\/li>\n<\/ol>\n\n<p>The safety model is governance, not a sandbox: <code>execute_php<\/code> is powerful by design. The controls are the constant you set, the human who approves the call, and the audit trail \u2014 not a promise that arbitrary code is safe.<\/p>\n\n<p>Learn more at <a href=\"https:\/\/my-aura.app\/siteagent\">my-aura.app\/siteagent<\/a>.<\/p>\n\n<h4>About Aura<\/h4>\n\n<p>Aura is a full-stack operations dashboard by <a href=\"https:\/\/digitizer.studio\">Digitizer<\/a> that brings servers, applications, DNS zones, and CDN pull zones from Cloudways, Hostinger VPS, Cloudflare, and Bunny.net into a single unified interface.<\/p>\n\n<p>SiteAgent extends that reach into every WordPress installation \u2014 so you can manage your entire infrastructure, including WordPress sites, from one place.<\/p>\n\n<h4>Free to Use<\/h4>\n\n<p>The plugin is completely free and open source (GPLv2+). You need a free or paid Aura account to connect your sites. <a href=\"https:\/\/my-aura.app\">Sign up at my-aura.app<\/a>.<\/p>\n\n<h4>Links<\/h4>\n\n<ul>\n<li><a href=\"https:\/\/my-aura.app\">Aura Dashboard<\/a><\/li>\n<li><a href=\"https:\/\/my-aura.app\/siteagent\">Documentation<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Digitizers\/SiteAgent\">GitHub Repository<\/a><\/li>\n<li><a href=\"https:\/\/digitizer.studio\">Digitizer<\/a><\/li>\n<\/ul>\n\n<!--section=installation-->\n<h4>Via WordPress Admin (Recommended)<\/h4>\n\n<ol>\n<li>Go to <strong>Plugins \u2192 Add New<\/strong> in your WordPress admin.<\/li>\n<li>Search for <strong>SiteAgent<\/strong>.<\/li>\n<li>Click <strong>Install Now<\/strong>, then <strong>Activate<\/strong>.<\/li>\n<li>Navigate to <strong>Settings \u2192 SiteAgent<\/strong>.<\/li>\n<li>Click <strong>Connect to Aura<\/strong> for one-click magic-link onboarding \u2014 or copy the Site Token (shown once) and paste it into your Aura dashboard manually.<\/li>\n<\/ol>\n\n<h4>Via WP-CLI<\/h4>\n\n<pre><code>wp plugin install digitizer-site-worker --activate\n<\/code><\/pre>\n\n<h4>Manual Upload<\/h4>\n\n<ol>\n<li>Download the plugin ZIP from WordPress.org.<\/li>\n<li>Go to <strong>Plugins \u2192 Add New \u2192 Upload Plugin<\/strong>.<\/li>\n<li>Upload the ZIP and click <strong>Install Now<\/strong>, then <strong>Activate<\/strong>.<\/li>\n<li>Navigate to <strong>Settings \u2192 SiteAgent<\/strong> to connect or get your Site Token.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"do%20i%20need%20an%20aura%20account%3F\"><h3>Do I need an Aura account?<\/h3><\/dt>\n<dd><p>Yes, you need an Aura account to connect your WordPress sites. Aura offers a free tier that includes up to 3 WordPress sites. <a href=\"https:\/\/my-aura.app\">Sign up at my-aura.app<\/a>.<\/p><\/dd>\n<dt id=\"is%20this%20plugin%20safe%20to%20use%3F\"><h3>Is this plugin safe to use?<\/h3><\/dt>\n<dd><p>Yes. The plugin uses defence-in-depth: WordPress Application Passwords (the same standard mechanism used by the block editor), a per-site token stored only as a SHA-256 hash and verified timing-safely, per-IP brute-force throttling, an HMAC-signed onboarding handshake, and an optional IP\/domain allowlist. No data is transmitted unless a request is made by your Aura instance.<\/p><\/dd>\n<dt id=\"how%20do%20i%20enable%20the%20approval%20gate%20for%20write%20actions%3F\"><h3>How do I enable the approval gate for write actions?<\/h3><\/dt>\n<dd><p>SiteAgent can require a per-action, cryptographically signed approval before it runs a state-changing <strong>MCP tool<\/strong> (cleanups, cache flushes, SEO writes, safe plugin updates run through the tool interface). Once enabled, each such write must carry a single-use signature that only the Aura dashboard can mint, after a human approves the action \u2014 so a leaked Site Token cannot run those tools on its own.<\/p>\n\n<p>This gate turns on automatically once the site holds Aura's approval key, which is provisioned securely during connection. <strong>If you installed or updated the plugin but have not reconnected the site since, the gate is dormant<\/strong> and the site runs in the standard token-only mode. To activate it, simply <strong>reconnect the site from your Aura dashboard<\/strong> \u2014 no reinstall is needed.<\/p>\n\n<p>Note: the approval gate currently covers the MCP tool path. Core, plugin, and theme updates performed over the plugin's direct REST update endpoints are still authorized by the Site Token alone (the standard site-management model), so treat the Site Token as a sensitive credential regardless. Grant coverage for those update endpoints is on the roadmap.<\/p><\/dd>\n<dt id=\"does%20it%20slow%20down%20my%20site%3F\"><h3>Does it slow down my site?<\/h3><\/dt>\n<dd><p>No. The plugin registers only REST API endpoints. It does not load any code, scripts, or database queries on frontend page loads. Your visitors experience zero impact.<\/p><\/dd>\n<dt id=\"what%20wordpress%20versions%20are%20supported%3F\"><h3>What WordPress versions are supported?<\/h3><\/dt>\n<dd><p>WordPress 6.2 or higher is required. This is needed for full Application Password support. The plugin has been tested up to WordPress 7.1.<\/p><\/dd>\n<dt id=\"what%20php%20versions%20are%20supported%3F\"><h3>What PHP versions are supported?<\/h3><\/dt>\n<dd><p>PHP 7.4 or higher. PHP 8.0+ is recommended.<\/p><\/dd>\n<dt id=\"can%20i%20restrict%20which%20ip%20addresses%20can%20access%20the%20api%3F\"><h3>Can I restrict which IP addresses can access the API?<\/h3><\/dt>\n<dd><p>Yes. The plugin supports an optional IP whitelist. If configured, only requests from the specified IP addresses will be accepted. Cloudflare and reverse proxy headers (<code>CF-Connecting-IP<\/code>, <code>X-Forwarded-For<\/code>, <code>X-Real-IP<\/code>) are fully supported for IP detection.<\/p><\/dd>\n<dt id=\"does%20this%20work%20with%20wordpress%20multisite%3F\"><h3>Does this work with WordPress multisite?<\/h3><\/dt>\n<dd><p>The plugin is designed for single WordPress installations. Multisite support is not currently available but is on the roadmap.<\/p><\/dd>\n<dt id=\"where%20is%20the%20site%20token%20stored%3F\"><h3>Where is the Site Token stored?<\/h3><\/dt>\n<dd><p>Only a SHA-256 <strong>hash<\/strong> of the Site Token is stored, in the WordPress option <code>aura_worker_site_token<\/code> \u2014 the raw token is never persisted. It is generated on first activation and shown once so you can copy it; the Aura dashboard keeps the only raw copy. Tokens created by older versions are upgraded to a hash automatically on first use.<\/p><\/dd>\n<dt id=\"can%20i%20regenerate%20the%20site%20token%3F\"><h3>Can I regenerate the Site Token?<\/h3><\/dt>\n<dd><p>Yes. Use <strong>Regenerate Token<\/strong> on the <strong>Settings \u2192 SiteAgent<\/strong> page. The new token is shown once. Regenerating invalidates the old token and disconnects the site from Aura until you reconnect with the new one.<\/p><\/dd>\n<dt id=\"how%20do%20i%20disconnect%20a%20site%20from%20aura%3F\"><h3>How do I disconnect a site from Aura?<\/h3><\/dt>\n<dd><p>Simply deactivate or delete the plugin, or remove the site from your Aura dashboard. If you deactivate the plugin, the REST API endpoints are unregistered and Aura can no longer communicate with the site.<\/p><\/dd>\n<dt id=\"does%20aura%20store%20my%20wp-admin%20credentials%3F\"><h3>Does Aura store my wp-admin credentials?<\/h3><\/dt>\n<dd><p>No. Aura uses WordPress Application Passwords, not your main admin password. Application Passwords are scoped specifically for REST API access and can be revoked at any time from <strong>Users \u2192 Your Profile<\/strong> in wp-admin.<\/p><\/dd>\n<dt id=\"is%20the%20plugin%20open%20source%3F\"><h3>Is the plugin open source?<\/h3><\/dt>\n<dd><p>Yes. SiteAgent is open source under the GPLv2 or later license. The source code is available on <a href=\"https:\/\/github.com\/Digitizers\/SiteAgent\">GitHub<\/a>.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>2.10.3<\/h4>\n\n<ul>\n<li>Fix (security): <strong>\"Regenerate Token\" revealed a new site token without ever\nstoring it.<\/strong> The option was registered as a read-only setting, and the\ncallback enforcing that ran on every write \u2014 not only on the settings form \u2014\nso the handler's write was discarded while the one-time reveal still\nappeared. Two consequences: an admin rotating a leaked token was told it was\nrevoked when the old token stayed valid, and a site disconnected from the\ndashboard could not be reconnected, because no token the screen displayed\never authenticated. The token is no longer registered as a setting (it is\ndisplay-only, so nothing submits it), and regeneration now stores the new\nhash with a single compare-and-swap, out of reach of any option filter \u2014 a\ntoken is revealed only when that one statement reports it wrote the row, and\na site whose row is missing or empty can be given its first token the same\nway.<\/li>\n<\/ul>\n\n<h4>2.10.2<\/h4>\n\n<ul>\n<li>Fix: a site moved from one Aura client to another while the old client's\nlast push was still in flight could end up holding the old client's ruleset\nand refuse the new client's rules until it was reconnected. The connect\ncallback now names the client the site belongs to (a signed, optional field\n\u2014 older dashboards keep working unchanged) and writes that binding into the\nruleset store itself, so a ruleset for any other client is refused from then\non, whatever was in flight.<\/li>\n<\/ul>\n\n<h4>2.10.1<\/h4>\n\n<ul>\n<li>Fix: <code>audit_rules<\/code> could report zero blocked\/warned events for the current\nhour. Reading the counters before the hour's first refusal put the bucket in\nWordPress's negative option cache, and the refusal's atomic insert did not\nclear it \u2014 so the count stayed at zero for the rest of the request, and on a\nsite with a persistent object cache until the cache was flushed. Enforcement\nwas never affected; only what the audit reported.<\/li>\n<li>Fix: two rulesets pushed to a site at the same moment, before it held any,\ncould answer the loser with 500 instead of the ordinary \"a newer ruleset is\nalready installed\" decision. Aura retries a 500, so no policy was lost; the\nsite now classifies the database's duplicate-key or deadlock answer as the\nlost race it is.<\/li>\n<\/ul>\n\n<h4>2.10.0<\/h4>\n\n<ul>\n<li>New: operator rules, enforced on the site. A rule is an Aura memory entry\n(<code>rule\/&lt;slug&gt;<\/code>) naming a resource \u2014 the whole site, a page or post by ID, or a\nplugin by slug \u2014 with an effect of <code>block<\/code> or <code>warn<\/code> and an optional expiry.\nAura signs the client's whole ruleset with the same key that signs approval\ngrants and pushes it to every connected site (<code>POST \/aura\/v2\/rules<\/code>), the site\nverifies it and keeps only a newer one (a replayed older ruleset is refused\neven when validly signed). No ruleset means no policy \u2014 nothing is refused. A\nsite that has never been reconnected since signed approvals shipped holds no\ngateway key and cannot verify a ruleset; it says so, and Aura tells you to\nreconnect it.<\/li>\n<li>Enforcement runs on every path a write can take: inside the tool executor\nbefore anything runs or is snapshotted; explicitly on the legacy REST update\nroutes; and at WordPress core's own REST API for posts and pages \u2014 so a rule on\na page holds against Aura's content tools, an assistant with an application\npassword, or another plugin's MCP server alike. A <code>block<\/code> refuses the call and\nnames the rule; <strong>a rule outranks an approval<\/strong> \u2014 a granted call is still\nrefused, and the message says to release the rule first. A <code>warn<\/code> runs and\nattaches the warning. Previews are never blocked; they now report what a call\ntouches and which rule would decide it.<\/li>\n<li>New: <code>audit_rules<\/code> (read-only) \u2014 ruleset presence and age, whether the site\ncan verify one, 24h block\/warn counts, expired-but-listed rules, and the\nenforcement points in this build.<\/li>\n<li>Every mutating tool now declares what a call touches; one that does not is\ncaught by every rule rather than by none.<\/li>\n<\/ul>\n\n<h4>2.9.1<\/h4>\n\n<ul>\n<li>Security (hardening): SiteAgent's tools have been dual-registered as WordPress\nabilities since 2.5.0, and an ability is published to the SITE rather than to\none server \u2014 so any co-installed MCP server that enumerates the site's\nabilities could serve them, including the ones that write. The approval-grant\nenforcement lives in SiteAgent's own REST handlers, which that route never\ntouches, so a mutating tool could run through another plugin's MCP server with\nno approval, no snapshot binding, and no audit entry.\nTwo guards close it. Tools that require a grant now declare a discovery type\nco-installed servers do not serve, and a grant-requiring ability arriving on\nany transport other than SiteAgent's own is refused unless it carries a valid\napproval grant bound to that exact call.\nNothing changes for the Aura gateway path or for wp-admin: a grant the gateway\nminted is accepted here unchanged. Read-only tools stay discoverable to other\nMCP clients, which is what the dual registration is for. Approval-bound reads\n(<code>db_query<\/code>) follow the write rule, as they already did on the gateway path.<\/li>\n<\/ul>\n\n<h4>2.9.0<\/h4>\n\n<ul>\n<li>New: a read-only security-audit surface \u2014 five tools that report what is on\nthe site without changing any of it. <code>check_core_checksums<\/code> compares WordPress\ncore files against the official manifest, <code>scan_executable_files<\/code> looks for\nexecutable files and <code>.htaccess<\/code> overrides under uploads, <code>audit_admin_accounts<\/code>\nand <code>audit_cron<\/code> inventory administrator accounts and scheduled events.<\/li>\n<li>New: <code>audit_mcp_exposure<\/code> answers a question that only appears once a site runs\nmore than one AI assistant \u2014 which OTHER MCP servers are registered here, and\nhow many of this site's abilities pass the discovery rule such a server\napplies. Abilities are registered site-wide, not to the plugin that declared\nthem, so a server resolving targets from that registry (as Angie's does) picks\nup mutating ones that never went through this plugin's approval and audit\npath. The counts are a property of the abilities, not proof that any server\ncurrently serves them \u2014 a server with an explicit tool list reaches only what\nit lists. The tool reports; it changes nothing.<\/li>\n<li>All five report bounded coverage \u2014 <code>truncated<\/code> and <code>cap<\/code>, alongside a pair of\ncounts naming what was in scope and what was reached (<code>total_seen<\/code> \/\n  returned, or <code>files_expected<\/code> \/ <code>files_checked<\/code> for <code>check_core_checksums<\/code>,\nwhich counts files rather than rows). They stop at their caps rather than\ngrowing without limit on a large site, and an empty result under\n  truncated: true means \"nothing found before the cap\" \u2014 it is never reported\nas \"clean\".<\/li>\n<li>Compatibility: declared tested up to WordPress 7.1.<\/li>\n<\/ul>\n\n<h4>2.8.2<\/h4>\n\n<ul>\n<li>Security (hardening): the snapshot\/rollback engine now reads its stored\npayloads back with <code>unserialize()<\/code> restricted to <code>allowed_classes =&gt; false<\/code>,\nso a tampered payload file can no longer instantiate arbitrary PHP objects on\nthe restore path (object-injection defense-in-depth). Restores fail closed on\nany object-bearing or malformed payload. The restore paths are unchanged for\nthe scalar and array data the engine actually stores.<\/li>\n<li>Fix: the self-updater deletes its temporary download with <code>wp_delete_file()<\/code>,\nand the SEO auditor reads WordPress core's sitemap state through the sitemaps\nserver instead of re-firing the <code>wp_sitemaps_enabled<\/code> filter.<\/li>\n<li>Internal: PRs are now gated in CI on PHPCS (security\/correctness sniffs) and\nthe official WordPress Plugin Check, so regressions in the above are caught\nbefore release. No effect on the shipped plugin.<\/li>\n<\/ul>\n\n<h4>2.8.1<\/h4>\n\n<ul>\n<li>Docs: the listing now describes the optional <strong>SiteAgent Power Pack<\/strong> companion\nplugin \u2014 the governed power tools (file read\/write, read-only SQL, allowlisted\nWP-CLI, PHP execution) that are deliberately NOT part of this WordPress.org\nbuild. It states plainly that the write and code tools stay disabled until the\nsite owner arms each one in wp-config.php, that the site must be connected to\nAura first (that provisions the approval key which makes grant enforcement\nactive), and that the model is governance \u2014 not a sandbox. No code changes.<\/li>\n<\/ul>\n\n<h4>2.8.0<\/h4>\n\n<ul>\n<li>Internal: Snapshot-engine primitives for reversible meta and multi-post writes \u2014\n  snapshot_meta (post-meta capture with a <code>meta<\/code> restore kind) and\n  snapshot_posts (multi-post capture with a <code>posts<\/code> restore kind that recreates\na deleted post under its original id). These are groundwork for upcoming\ngoverned Elementor and bulk-post editing; they are not yet exposed over the\nremote snapshot API in this release (which still handles <code>file<\/code> and <code>option<\/code>).<\/li>\n<li>Fix: SEO-meta writes now return a distinct \"Failed to write SEO meta\" error when\na write fails despite input, instead of the misleading \"Nothing to update\".<\/li>\n<li>Docs: Listing repositioned around governed, reversible AI, with the approval and\nrollback guarantees scoped to the paths that actually enforce and snapshot.<\/li>\n<\/ul>\n\n<h4>2.7.1<\/h4>\n\n<ul>\n<li>Self-update integrity: when the Aura gateway supplies the release's SHA-256,\nSiteAgent now downloads the zip, verifies its bytes against that digest, and\nrefuses to install on a mismatch \u2014 so an approved self-update is bound to the\nexact package, not just the URL. Sites without a supplied digest behave as\nbefore.<\/li>\n<\/ul>\n\n<h4>2.7.0<\/h4>\n\n<ul>\n<li>Approval gate now covers the direct REST write endpoints, not just MCP tools.\nWhen a site has provisioned Aura's approval key, plugin\/theme\/core\/translation\nupdates, batch updates, database migrations, rollbacks, self-update, and\nsnapshot create\/restore each\nrequire a fresh single-use signed grant bound to the exact action and\nparameters \u2014 so a leaked Site Token can no longer trigger a code update on its\nown. Sites without the key keep working as before (token-only) until they\nreconnect.<\/li>\n<li>Self-update source allowlist: SiteAgent will only install a self-update zip\nfrom the official GitHub repository (Digitizers\/SiteAgent release downloads),\nover HTTPS. Overridable via the aura_worker_self_update_allowed_hosts filter.<\/li>\n<\/ul>\n\n<h4>2.6.1<\/h4>\n\n<ul>\n<li>Tool self-declaration hardening: six mutating tools (update_plugin_safely,\ncleanup_orphaned_assets, backup_plugins, cleanup_transients, clear_caches,\nset_seo_meta) now explicitly declare themselves non-read-only and\napproval-required instead of inheriting neutral defaults, so any consumer that\ntrusts a tool's own annotations gates them correctly. Grant enforcement and\nthe Aura gateway's verb-based policy already treated them as writes, so live\nbehaviour is unchanged.<\/li>\n<li>cleanup_orphaned_assets now advertises a preview: its dry-run (find orphans,\ndelete nothing) is exposed through the preview API, so the orphaned-media\nsample and count can be inspected without approval before the destructive\ndelete \u2014 which still requires approval.<\/li>\n<\/ul>\n\n<h4>2.6.0<\/h4>\n\n<ul>\n<li>Signed approval grants (G-grants): every mutating (non read-only) MCP tool\nreached over the Aura gateway (X-Aura-Token) path now requires a single-use,\nEd25519-signed grant that binds the exact tool, parameters, site, and a short\nvalidity window \u2014 so a stolen site token can only ever run READ tools, never a\nwrite or a power op. The plugin stores only the gateway's PUBLIC key, so even a\nfully compromised site can't mint its own grants; only the gateway can, and\nonly for a human-approved action. The gateway public key is provisioned over\nthe HMAC-signed magic-link \/connect callback, and enforcement activates only\nonce it is present, so existing deployments are unaffected until they\nreconnect. The WordPress Abilities \/ Application-Password path\n(capability-gated) is unchanged.<\/li>\n<\/ul>\n\n<h4>2.5.0<\/h4>\n\n<ul>\n<li>WordPress Abilities API bridge: SiteAgent tools are now dual-registered as WP\nabilities when the core Abilities API is present, so the official MCP adapter\nand standard MCP clients can discover them (aura\/mcp namespace unchanged).<\/li>\n<li>Hardening (external review): register the abilities category before the\nabilities (else a real Abilities API rejects them); default a missing input to\n{} for parameterless abilities; snapshot engine fails closed when a payload\/\nmetadata write fails, uses an uncollidable \"absent option\" sentinel, and post\nrestore refuses a missing payload instead of wiping the page; Gutenberg\nupdate refuses inner_html on a block with nested children and surfaces the\ninner_html change in its preview; the snapshot REST file endpoint jails targets\nto wp-content and refuses wp-config.php; AURA_WORKER_VERSION synced.<\/li>\n<\/ul>\n\n<h4>2.4.0<\/h4>\n\n<ul>\n<li>Gutenberg (block editor) tools: list_page_blocks (read), update_page_block\n(approval-gated, snapshot-first, reversible), create_page_from_blocks\n(draft-first). Ends the Elementor-only gap \u2014 Gutenberg is core WP.<\/li>\n<li>Snapshot engine gains a \"post\" kind (snapshot_post) so block edits are\nreversible.<\/li>\n<\/ul>\n\n<h4>2.3.0<\/h4>\n\n<ul>\n<li><strong>Token-only connection<\/strong> \u2014 a valid Aura Site Token now authorizes management on its own. After connecting (magic link or Regenerate Token), the plugin runs requests as the connecting administrator, so Aura no longer needs a WordPress Application Password. Existing app-password connections keep working unchanged. No new tools \u2014 the set stays at <strong>18<\/strong>.<\/li>\n<li><strong>Forensics hook<\/strong> \u2014 fires <code>do_action( 'aura_worker_token_run_as', $user_id, $route )<\/code> whenever a request is authorized by token alone and run as an admin, so site owners can distinguish token-run-as from interactive admin actions in their audit log. The admin fallback is now deterministic (lowest-ID administrator).<\/li>\n<\/ul>\n\n<h4>2.2.4<\/h4>\n\n<ul>\n<li>Fix: \"Connect to Aura\" (magic-link onboarding) now targets the Aura app host (<code>app.my-aura.app<\/code>) instead of the marketing domain, so one-click connect works out of the box. (Sites that set the <code>AURA_DASHBOARD_URL<\/code> constant are unaffected.)<\/li>\n<\/ul>\n\n<h4>2.2.3<\/h4>\n\n<ul>\n<li>Fix: <code>set_seo_meta<\/code> on Yoast \u2014 after writing the meta, the cached Yoast indexable is now invalidated so the frontend serves the new SEO title\/description immediately instead of the stale value (previously required a manual save\/reindex).<\/li>\n<li>Fix: <code>perf_check<\/code> autoload weight \u2014 counts all WP 6.6+ autoload values (<code>yes<\/code>, <code>on<\/code>, <code>auto-on<\/code>, <code>auto<\/code>) instead of only <code>yes<\/code>, so the figure is no longer under-reported on newer cores.<\/li>\n<li>Fix: <code>scan_broken_links<\/code> \u2014 the reported counts now reflect the true number of matches; previously they were capped at the 10-item sample limit. Samples remain capped.<\/li>\n<li>Fix: <code>scan_seo<\/code> \u2014 missing excerpts now count toward the score (an <code>excerpts<\/code> finding is reported) instead of being tallied but ignored.<\/li>\n<li>Fix: <code>scan_a11y<\/code> document language \u2014 verified against the rendered <code>&lt;html lang&gt;<\/code> attribute of the home page rather than the configured locale, so a theme that omits <code>language_attributes()<\/code> is correctly flagged.<\/li>\n<\/ul>\n\n<h4>2.2.2<\/h4>\n\n<ul>\n<li>Feature: On-site SEO-meta tools \u2014 two agent tools that read and write a post\/page's SEO meta directly on the active SEO plugin (Rank Math, Yoast, or SEOPress):\n\n<ul>\n<li><code>get_seo_meta<\/code> (read) \u2014 returns the SEO title, description, and focus keyword.<\/li>\n<li><code>set_seo_meta<\/code> (write, approval-gated) \u2014 sets any of title \/ description \/ focus keyword; only the fields you pass change.<\/li>\n<\/ul><\/li>\n<li>Because these run on-site via the plugin's own meta keys (not the SEO plugin's REST endpoint), they work even on sites where a firewall\/WAF blocks those endpoints. Built-in tool set is now 18.<\/li>\n<\/ul>\n\n<h4>2.2.1<\/h4>\n\n<ul>\n<li>Feature: Performance &amp; broken-link auditors \u2014 two more read-only agent tools, scored\/structured and no-AI-cost:\n\n<ul>\n<li><code>perf_check<\/code> (read) \u2014 performance posture (persistent object cache, OPcache, page-cache plugin, PHP version, autoload weight, active plugin count, PHP memory limit, expired transients).<\/li>\n<li><code>scan_broken_links<\/code> (read) \u2014 link triage over a content sample with NO outbound HTTP: empty\/anchor-only links, links to dev\/staging hosts, and internal links that don't resolve locally.<\/li>\n<\/ul><\/li>\n<li>Built-in tool set is now 16.<\/li>\n<\/ul>\n\n<h4>2.2.0<\/h4>\n\n<ul>\n<li>Feature: SEO &amp; accessibility auditors \u2014 two new read-only agent tools, scored and no-AI-cost, governed by Aura's risk policy:\n\n<ul>\n<li><code>scan_seo<\/code> (read) \u2014 SEO posture (search-engine visibility, permalink structure, XML sitemap, site title) plus a sampled content audit (missing excerpts\/featured images, thin content).<\/li>\n<li><code>scan_a11y<\/code> (read) \u2014 accessibility audit over sampled content (images missing alt text, non-descriptive link text, missing heading structure, document language attribute).<\/li>\n<\/ul><\/li>\n<li>Both run fleet-wide through Aura's Fleet MCP Gateway to catch SEO\/accessibility regressions across many sites at once.<\/li>\n<\/ul>\n\n<h4>2.1.0<\/h4>\n\n<ul>\n<li>Feature: MCP ops toolset expansion \u2014 new agent tools governed by Aura's approval\/risk policy:\n\n<ul>\n<li><code>get_database_info<\/code> (read) \u2014 database size, largest tables, autoload weight, expired transient count.<\/li>\n<li><code>scan_security<\/code> (read) \u2014 scored security posture (file-edit lockdown, debug exposure, SSL, default admin\/prefix, open registration, PHP version).<\/li>\n<li><code>list_users<\/code> (read) \u2014 users with roles and post counts, admins flagged; never returns secrets.<\/li>\n<li><code>check_health<\/code> (read) \u2014 live health gate (home-page HTTP, PHP fatals, white-screen, DB) for wrapping updates.<\/li>\n<li><code>scan_error_log<\/code> (read) \u2014 tails and severity-groups the PHP\/WordPress error log, surfacing recent fatals.<\/li>\n<li><code>clear_caches<\/code> (write) \u2014 flush object cache, opcache, and detected page-cache plugins (W3TC, WP Super Cache, WP Rocket, LiteSpeed, Autoptimize).<\/li>\n<li><code>cleanup_transients<\/code> (write) \u2014 remove expired transients to reduce autoload bloat.<\/li>\n<li><code>backup_plugins<\/code> (write) \u2014 zip-snapshot one or all active plugins (rollback safety net) before mutating actions.<\/li>\n<\/ul><\/li>\n<\/ul>\n\n<h4>2.0.2<\/h4>\n\n<ul>\n<li>Fix: Removed an arrow character from screenshot caption #1 that WordPress.org wrapped in emoji markup inside the image <code>alt<\/code> attribute, breaking the plugin page's HTML.<\/li>\n<\/ul>\n\n<h4>2.0.1<\/h4>\n\n<ul>\n<li>Docs: readme rewritten for the 2.0 feature set (safe batch updates, rollback, magic-link, MCP), corrected security description, and added v2\/MCP endpoint reference.<\/li>\n<li>Docs: fixed admin menu location \u2014 the settings page lives under <strong>Settings \u2192 SiteAgent<\/strong>.<\/li>\n<\/ul>\n\n<h4>2.0.0<\/h4>\n\n<ul>\n<li>Feature: Site health checks \u2014 read recent error-log tail, surface PHP\/DB\/disk status in the health report.<\/li>\n<li>Feature: Plugin rollback &amp; backup \u2014 zip-snapshot a plugin before updating and restore on demand if an update breaks the site.<\/li>\n<li>Feature: Magic-link admin access \u2014 generate a short-lived one-time login link from Aura for support sessions.<\/li>\n<li>Feature: MCP tools \u2014 expose site context, safe plugin updates, asset cleanup, and vulnerability checks to AI agents.<\/li>\n<li>Security: Site token is now stored hashed (SHA-256) instead of plaintext; existing tokens migrate automatically on first use.<\/li>\n<li>Security: Brute-force throttling on token authentication (per-IP failure limit).<\/li>\n<li>Security: Signed magic-link connect \u2014 the dashboard callback is HMAC-verified with a one-time secret and replay-protected by timestamp.<\/li>\n<li>Feature: Regenerate Token button under Settings \u2192 SiteAgent.<\/li>\n<li>Fix: Core database upgrade now reports real failures instead of always returning success (verifies db_version reached the target).<\/li>\n<li>Improvement: Tested with WordPress 7.0.<\/li>\n<li>Compliance: WordPress.org Plugin Check fixes \u2014 WP_Filesystem usage (no direct file_put_contents), gmdate(), wp_delete_file().<\/li>\n<\/ul>\n\n<h4>1.3.5<\/h4>\n\n<ul>\n<li>Security: Enhanced authentication with timing-safe token comparison.<\/li>\n<li>Feature: Added optional IP whitelisting for restricted API access.<\/li>\n<li>Improvement: Support for Cloudflare and reverse proxy headers in IP detection.<\/li>\n<li>Fix: Improved compatibility with WordPress 6.7.<\/li>\n<\/ul>\n\n<h4>1.3.0<\/h4>\n\n<ul>\n<li>Performance: Optimized REST API endpoints for faster health reports.<\/li>\n<li>UI: Updated admin interface under Tools for better clarity.<\/li>\n<\/ul>\n\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>Initial release.<\/li>\n<li>REST API endpoints for site health, available updates, core\/plugin\/theme\/translation\/database updates.<\/li>\n<li>Auto-generated Site Token.<\/li>\n<li>Admin page under Tools \u2192 SiteAgent.<\/li>\n<li>Zero frontend performance impact.<\/li>\n<\/ul>","raw_excerpt":"Let AI update and maintain WordPress with Aura&#039;s guardrails: optional per-action approval, an audit trail, and auto-rollback on safe batch updates.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/291225","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=291225"}],"author":[{"embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/benkalsky"}],"wp:attachment":[{"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=291225"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=291225"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=291225"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=291225"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=291225"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/te.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=291225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}