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

A week ago we told you that WordPress 7.1 would arrive without the two AI capabilities everyone had attached to it, and we 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.

The prediction, scored

Our reading of the June roadmap was that embeddings and generation streaming would be described as arriving in this release, would in fact 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 copy of the AI client library exposes no embedding generation and no streaming. The highest @since annotation anywhere in its prompt builder is 1.3.0. There is no EmbeddingBuilder class in the bundle, no AiClient::input() entry point, and no generateEmbedding(), generateEmbeddings() or generateEmbeddingResult() on the client. The only embedding-shaped thing present is isSupportedForEmbeddingGeneration(), a capability 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 of this post 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 published release was 1.3.1 from March, and framed the embeddings work as sitting on an untagged trunk that WordPress could not reasonably have picked up in time. That framing was generous and it was wrong.

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

The AI team stated this plainly at the time. In the contributor summary for the meeting of July 15, 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 pull in a dependency bump after the feature freeze. Which is exactly what a release process is supposed to do.

The second error: we tested the wrong class

Our beta test was to grep the bundled prompt builder for a generateEmbedding method and report its absence. We got the right answer with the wrong instrument.

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

The correct test, which we have now run against the release candidate tree, is to look for EmbeddingBuilder and AiClient::input(). Both are present in the library’s trunk. Neither is present in wp-includes/php-ai-client/. That is a real absence rather than 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. It is a large piece of work, 71 commits touching 38 PHP files, adding an SSE parser, a StreamingTextGenerationModelInterface, chunk accumulation and a StreamedGenerativeAiResult. None of it is merged, so none of it is tagged, so none of it could be bundled.

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

The reason is technical rather than political. The July 15 summary notes that "Contributors discussed 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 can hold a connection open for minutes, and WordPress’s HTTP library is the constraint. The August 5 contributor summary is candid about where that leaves things: "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 unusually clear.

The merge proposal for expanding core abilities 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 in the discussion: "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 WordPress AI plugin first.

The shipped code matches. The core registration file in this release declares exactly three abilities, core/get-site-info, core/get-user-info and core/get-environment-info, every one of them annotated @since 6.9.0. Not one new core ability was added in this cycle. If you are building against the Abilities API, your surface for reading site data through it 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, which is the problem you actually hit once agents start calling your site.

The Field Guide collects the changes. A unified meta.public flag, defaulting to false, now 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 to it, and we can confirm each carries 'public' => true in the shipped registration.

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

Default deny, plus a filterable registry, plus an audit hook. That is the vocabulary of an authorization model, and it is a more consequential thing to ship 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, which is the third correction in this post.

Security, and the only thing you have to do today

The 7.0.3 maintenance release went out on August 6, 2026, addressing eleven separate issues, including a pre-authentication reflected cross site scripting flaw on the login screen tracked as CVE-2026-64638, a multisite privilege escalation, a server side request forgery, 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."

So yes: updating from 7.0.3 does not regress you. If you are still 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 fix touches.

Everything else here 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 visible headline features are client side media processing, an SVG icon API, 46 accessibility focus tickets and a persistent admin toolbar. Real work, none of it AI. The Field Guide mentions the AI client exactly once, for a small 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 the right decision. 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 the questions the new exposure flag starts to answer.

Frequently Asked Questions