August 19, 2026 — WordPress AI 1.3.0 shipped August 18, and it is the release where the permission model finally says no by default. 1.0.0 gave publishers request logs to see what their AI was doing; 1.1.0 encrypted the connector credentials and disciplined the wasteful calls; 1.2.0 let the AI draft replies and run summaries in bulk. 1.3.0 does something quieter and, for enterprise publishers, more consequential — it stops handing out abilities. The read primitives that internal tools have been building against are no longer registered automatically; a site now has to opt in before any of them are exposed through the Abilities API or MCP. Around that line sit two editor experiments that move machine writing into translation and permalinks, a classification pass that tightens auto-tagging, and a fleet-management layer that lets a platform team carry settings, observe requests, and clean up on uninstall. For newsrooms, the story is not a new feature — it is that the AI’s reach is now a switch someone has to deliberately flip.
Key Themes
- Five abilities including
core/read-contentandcore/read-usersare no longer registered automatically, and external exposure through the Abilities API and MCP now requires enabling a single Custom Abilities experiment. - Two editor experiments — Content Translation and Slug Generation — put machine output into the two surfaces that carry the most editorial weight: the published text and the permalink.
- Content Classification produces more relevant category and tag suggestions and exposes three new filters for tuning taxonomy candidates and confidence thresholds.
- Settings import/export, a Site Health section, and a public
log_ai_request()API turn the plugin into something a multi-site publisher can manage and observe as a fleet. - Deleting the plugin now removes its settings, transients, scheduled events, and request-log table, and the post-meta keys migrate from an
ai_to awpai_prefix.
Jump to: 🔒 Opt-In Abilities · 🌐 Editor Experiments · 🏷️ Classification · 🛠️ Fleet Surface · 🔐 Security & Lifecycle · 💡 Takeaways
🔒 Opt-In Abilities
The headline change in 1.3.0 is a breaking one. Five abilities — ai/get-post-details, ai/get-post-terms, core/read-settings, core/read-users, and core/read-content — are no longer registered automatically. A single Custom Abilities opt-in under Settings > AI > Admin Experiments now controls whether they are exposed externally through the Abilities API and the Model Context Protocol. The plugin’s own internal features keep working whether or not the toggle is on; what the switch governs is the external surface — the primitives a house AI tool, an MCP client, or a third-party integration can call. Sites or integrations already wired to those abilities have to enable the experiment after upgrading or the calls stop resolving.
Why this matters: This is the governance inflection the series has been circling since 1.0.0. Read-only Abilities arrived in 1.2.0 with least-privilege field defaults, but they were still on — any MCP client that authenticated could enumerate them. 1.3.0 flips the default from present-but-scoped to absent-until-enabled, which is the posture a security team actually asks for: external exposure of content and user reads is now a deliberate, auditable decision rather than a property of having the plugin installed. For a publisher, this is the difference between “our CMS advertises a way to read every user’s email over MCP” and “someone signed off on exposing that.” The cost is a real migration — the Abilities toolkit work covered in this month’s developer roundup means more internal tooling depends on these calls than a year ago, and every one of those consumers breaks silently until the experiment is enabled. Audit what reads through the Abilities API before you upgrade, then turn Custom Abilities on deliberately, not reactively.
🌐 Editor Experiments
Two experiments push machine output into the editor. Content Translation lets an editor translate a post without leaving the editor — the plugin translates supported Paragraph and Heading blocks, optionally the post title, and replaces the originals in place for review before publishing. Slug Generation suggests a concise, search-friendly permalink from the title and content, surfaced in the permalink controls and the pre-publish flow, where an editor can edit, regenerate, and apply it; the interface previews normalization and blocks invalid slug values. Both are opt-in experiments, and the experiments list was reorganized in this release so admin and editor experiments are grouped separately.
Why this matters: These land on the two surfaces with the least review tolerance. A machine-translated paragraph published under the masthead is not a convenience — it is an editorial artifact a reader will hold the brand to, and for international media groups running the same story across editions, unreviewed translation is a correctness and trust exposure, not a workflow win. Translation belongs to a bilingual desk with sign-off, not a one-click replace. Slug Generation is lower-stakes but not zero: permalinks are permanent addresses that get shared, cited, and indexed, so a regenerated slug on an already-circulated URL is a link-integrity decision. The right posture is to let the model draft and a human own the commit — the same accountability line Type-ahead Text drew for article bodies, now extended to language and address.
🏷️ Content Classification
Content Classification got a relevance pass: the model now receives better taxonomy context, distinguishes broad categories from specific tags, and filters out low-confidence results. Three new filters put that behavior under developer control — wpai_content_classification_available_terms constrains the candidate terms offered, wpai_content_classification_min_confidence sets the minimum confidence threshold for a suggestion to surface, and wpai_content_classification_candidate_pool_size caps how many candidates the model considers. Focus movement through the classification workflow was also made more predictable for keyboard and assistive-technology users.
Why this matters: Taxonomy is editorial governance wearing a technical costume. The categories and tags a newsroom applies are how it declares what a story is — they drive section pages, feeds, ad adjacency, and archive structure — so a model that over-suggests broad categories or hands out low-confidence tags is quietly editorializing at scale. The confidence filter is the important lever: wpai_content_classification_min_confidence lets a publisher tune the plugin toward precision over recall, so auto-tagging stops proposing terms it is only half-sure about. Set it against your own taxonomy discipline, and use wpai_content_classification_available_terms to keep suggestions inside a curated vocabulary rather than the full term soup.
🛠️ Fleet Surface
Three additions make the plugin manageable across many sites. Settings import/export, from a menu on the AI settings screen, lets an administrator export non-sensitive settings to JSON and import them elsewhere — credentials, API keys, and tokens are excluded from exports and never overwritten on import. A new AI Plugin section in Site Health reports configuration and runs status tests. And a public WordPress\AI\log_ai_request() function lets MCP servers and ability consumers write their own activity into the AI Request Log, alongside new per-ability filters for customizing system instructions, prompts, and provider preferences without forking the plugin.
Why this matters: This is the layer a platform team running a fleet of newsroom sites has been missing. Import/export means a governed baseline configuration can be promoted across properties without hand-editing each one, and the deliberate exclusion of secrets means that baseline is safe to move — you are shipping policy, not keys. More important is log_ai_request(): the request log from 1.0.0 only saw the plugin’s own calls, so any house tooling built on the Abilities API was invisible to it. Now that tooling can write into the same log, which closes the blind spot that made “we log our AI” a partial claim. Wire your internal agents to it so the audit trail is one surface, not two.
🔐 Security & Lifecycle
Security tightened across the board: additional sanitization of LLM-generated content, nonce verification before bulk alt-text and summary generation, custom image-URL validation (public status, allowed MIME types, no redirects), configurable download limits, and a wpai_bulk_action_max_items filter to cap how many items a bulk request can touch. Two lifecycle changes carry the most operational weight. Deleting the plugin now removes its settings, transients, scheduled events, and request-log table — deactivation still preserves everything. And the post-meta keys migrated from an ai_ prefix to wpai_ (ai_generated → wpai_generated, and so on); the plugin auto-migrates, but third-party code referencing the old keys needs updating. The AI_Service class and get_ai_service() helper are deprecated for removal in the next major.
Why this matters: The bulk cap directly hardens the batch-spend exposure flagged in 1.2.0 — wpai_bulk_action_max_items is the guardrail that keeps one dropdown click from firing a thousand provider calls. The deletion change matters for data-handling posture: a plugin that leaves a request-log table full of prompt content behind on uninstall is a retention question, and 1.3.0 makes removal clean and explicit while keeping deactivation non-destructive. The meta-key migration is the one to plan for — any dashboard, export, or editorial report keying on ai_generated to flag machine-assisted content will read empty until it is updated, and for a publisher that field is the disclosure signal.
🔧 Also in 1.3.0
Provider defaults were bumped to more recent models for all three default providers, and the plugin no longer sets a custom temperature on requests, improving compatibility with models that reject the parameter. Content Resizing now preserves links, emphasis, inline code, and inline HTML rather than flattening them, and meta descriptions survive with Yoast SEO active. Bulk actions no longer re-execute when a list is sorted or paginated — a quiet fix that prevents accidental repeat spend. Groundwork for embeddings landed from the PHP AI Client for environments that support them. On the horizon, the 1.4.0 milestone lines up Internal Link Suggestions, Text to Speech, native vector search, and — again — C2PA content provenance for text and images. Worth the arc note: the 1.1.0 recap told publishers to watch C2PA slip to 1.2.0, the 1.2.0 recap watched it slip to 1.3.0, and it has now slipped to 1.4.0. Provenance is still a roadmap item a full two quarters past its first target — build your AI-disclosure posture on editorial process, not on a platform feature that keeps moving.
💡 Takeaways
- Audit what reads through the Abilities API before upgrading — five abilities stop registering automatically in 1.3.0, and any MCP client or house tool that depends on them breaks silently until you enable the Custom Abilities experiment on purpose.
- Route machine translation through a bilingual desk — Content Translation replaces published Paragraph and Heading blocks in place, and an unreviewed translation under the masthead is a correctness and trust exposure, not a shortcut.
- Tune classification for precision — set
wpai_content_classification_min_confidenceand constrain terms withwpai_content_classification_available_termsso auto-tagging respects your taxonomy instead of editorializing at scale. - Wire internal agents into
log_ai_request()— the AI Request Log can finally record calls made by house tooling, so consolidate your audit trail onto one surface rather than two. - Update anything keying on the old
ai_meta prefix — the migration towpai_is automatic in the database but silent for your dashboards, and for a publisher that field is the machine-assisted disclosure signal.
The full release post is available on Make WordPress AI.