WordPress 7.1: What Actually Shipped, and What We Got Wrong

A week ago we told you WordPress 7.1 would arrive without the two AI capabilities everyone had attached to it, and promised to come back on release day and mark our own homework. Here is the mark. The headline call was correct. Two supporting details were not, and one was wrong in a way that makes the story worse for WordPress, not better.

Update (2026-08-20): security section extended, one count corrected, inspection basis clarified.

WordPress 7.0.4 shipped on August 12, a week before this article, fixing an authenticated remote code execution flaw. It is now covered in the security section, and anyone on 7.0.3 should read that first. The 7.0.3 fix count has been corrected from eleven to twelve after recounting the announcement’s own list. A third release candidate followed on August 12 carrying that backport, so the tree examined here was RC2, not the final build.

The prediction, scored

Our reading of the June roadmap was that embeddings and streaming would be described as arriving in this release, would live in a standalone PHP library one layer below WordPress, and would not be callable from a plugin on day one. That held.

In the shipped tree, the bundled AI client library exposes no embedding generation and no streaming. The highest @since annotation in its prompt builder is 1.3.0. There is no EmbeddingBuilder class, no AiClient::input() entry point, and no generateEmbedding() or generateEmbeddings() on the client. The only embedding-shaped thing present is isSupportedForEmbeddingGeneration(), a probe present since 0.1.0 that tells you whether a provider could do embeddings, not how to ask for one.

So: right call. The interesting part is the two things we got wrong.

Where we were wrong: the library was tagged, and core still did not take it

Our August 12 piece said the library’s most recent release was 1.3.1 from March, framing the embeddings work as sitting on an untagged trunk WordPress could not reasonably have picked up in time. That framing was generous and wrong.

Pull request 244, "Add embedding generation APIs," merged into trunk on July 15, 2026 across 28 commits. The same day, version 1.4.0 was published to Packagist. A tagged, installable release with the embedding APIs existed thirty five days before WordPress went out, and the copy vendored into core is still on the 1.3 line.

The AI team said so plainly. In the July 15 contributor summary, Jeffrey Paul wrote: "PHP AI Client 1.4.0 includes the embedding-generation APIs needed by the WordPress implementation. Streaming remains under review and was not included in that release." The same summary records the consequence: "The WordPress integration for generating embeddings did not make the Beta 1 cutoff. Its Core ticket is currently targeted for WordPress 7.2".

The blocker was never the library. It was the WordPress side of the integration, and the decision to hold the vendored copy steady rather than bump a dependency after feature freeze. Which is what a release process is for.

The second error: we tested the wrong class

Our beta test grepped the bundled prompt builder for a generateEmbedding method and reported its absence. Right answer, wrong instrument.

In the released 1.4.0 API, embeddings are not on the prompt builder. They live on a separate EmbeddingBuilder, reached through a new AiClient::input() factory annotated @since 1.4.0. Had WordPress bundled 1.4.0, our test would still have come back empty and we would have reported a false negative with confidence.

The correct test, run against the release candidate tree, looks for EmbeddingBuilder and AiClient::input(). Both are in the library’s trunk. Neither is in wp-includes/php-ai-client/. A real absence, not a lucky guess.

Streaming: the promise that did not survive contact

Embeddings were held back at the WordPress layer. Streaming failed one level further down.

Pull request 255, "Add support for streaming," is still open: 71 commits across 38 PHP files, adding an SSE parser, a StreamingTextGenerationModelInterface, chunk accumulation and a StreamedGenerativeAiResult. None of it is merged, so none is tagged, so none is bundled.

A public commitment was made here and quietly missed. On June 19, Jason Adams explained the architecture and said: "This means streaming will be available within WP 7.1, but not as something naturally supported by WordPress." That promises the lower bound only, the library primitive rather than a WordPress API. Even that did not arrive.

The reason is technical, not political. The July 15 summary notes "maintenance constraints in the Requests library that may affect the streaming implementation. The current technical direction is still for the necessary change to happen within Requests rather than creating a separate implementation in WordPress Core." Streaming needs a transport that holds a connection open for minutes, and WordPress’s HTTP library is the constraint. The August 5 contributor summary is candid: "Embeddings & Streaming support ideally continue to get testing and reviews to ensure those are stable and released, with hope of getting into WP 7.2 later this year."

Not scheduled. Hoped for.

The three core abilities did not land, and the decision is on the record

We also said the read abilities had moved out of this cycle. Confirmed, and the paper trail is clear.

The merge proposal put forward core/read-settings, core/read-content and core/read-users, all read only, all capability gated. On July 13, release lead @annezazu closed the question: "While a tough call, I do think we should punt, point folks to the AI plugin, and iterate our way to 7.2." The rationale was thin adoption evidence and a preference for maturing them in the AI plugin.

The shipped code matches. The core registration file declares exactly three abilities, core/get-site-info, core/get-user-info and core/get-environment-info, each annotated @since 6.9.0. Not one new core ability was added this cycle. If you are building against the Abilities API, your surface for reading site data is unchanged since 6.9 shipped in December.

What WordPress 7.1 did ship for agent builders

This is where our earlier piece undersold the release. The abilities work in WordPress 7.1 is not about new abilities. It is about controlling how existing ones are exposed, the problem you hit once agents start calling your site.

The Field Guide collects the changes. A unified meta.public flag, defaulting to false, carries exposure intent across every channel at once, with the older show_in_rest still present and still taking precedence when set explicitly. An ability stays private unless you deliberately open it. Milana Cap, who authored the change under ticket 65568, described its purpose: "The flag provides a single, high-level way to indicate that an ability is intended to be available to external clients such as the REST API, MCP adapters, and AI agents." The three core abilities were migrated, and each carries 'public' => true in the shipped registration.

Alongside it, wp_get_abilities() gained an $args parameter for filtering by category, namespace, metadata or custom callback, annotated @since 7.1.0. Two validation filters, wp_ability_validate_input and wp_ability_validate_output, supplement JSON Schema checking, and a wp_ability_invoked action gives you one hook for auditing every invocation.

Default deny, a filterable registry, an audit hook. That is the vocabulary of an authorization model, and more consequential than three read endpoints would have been. We spent our August 12 piece counting what was missing and gave this a sentence. It deserved a section, the third correction here.

Security, and the only thing you have to do today

The 7.0.3 maintenance release went out on August 6, 2026, addressing twelve separate issues, including a pre-authentication reflected cross site scripting flaw on the login screen, CVE-2026-64638, a multisite privilege escalation, a server side request forgery in URL validation, and a CSS injection via a filter bypass. The announcement states the forward port directly: "WordPress 7.1 RC2 has also been released, containing all applicable fixes."

Then 7.0.4 followed on August 12, and it matters more than its size suggests. It is a single-issue release fixing an authenticated Author and above remote code execution via malicious file upload on Imagick plus Ghostscript sites, tracked as CVE-2026-65640. Remote code execution reachable by an Author is a materially different risk from stored cross site scripting, and the fix was backported to the 4.7 branch and into 7.1 RC3.

So yes: updating from 7.0.4 does not regress you. If you are on 7.0.3 you are missing that RCE fix and should move regardless of what you decide about 7.1. On 7.0.2 or earlier, the update is the whole point of your day, and our breakdown of the 7.0.3 security release covers what each of the twelve fixes touches.

Everything else is optional. The release candidate announcement counted more than 145 changes since Beta 4, 88 in core and 57 in the editor, and the Field Guide’s headline features are client side media processing, an SVG icon API, 46 accessibility tickets and a persistent admin toolbar. Real work, none of it AI. The Field Guide mentions the AI client once, for a correctness fix to ability call execution.

Which brings us back to Jason Adams in June: "There’s still no visible AI within the default WordPress interface". Two months and one release later, that is still true, and still right. Our earlier look at what the 7.1 AI client actually is stands, minus the two errors corrected above, and the foundations laid in 7.0 remain the layer that matters. Our piece on agent permissions in a CMS covers what the new exposure flag starts to answer.

Frequently Asked Questions