WordPress Core Abilities Expansion Proposed for 7.1

Every six months, someone declares that the next generation of AI tools will finally make the content management system irrelevant. I have been hearing that pitch for twenty years, and it keeps failing for the same reason: the CMS is where the rules live. Who can edit what. Which post types exist. What the permalink was in 2019. Whether the checkout page can be updated by a bot at three in the morning. Strip that governance layer away and you do not get a smart agent, you get a very fast intruder.

The Abilities API is WordPress quietly turning that governance layer into a machine-readable contract. It shipped in 6.9, extended to the client in 7.0, and this week it took another concrete step forward with a merge proposal for 7.1. If you build sites for a living, this is one of the more consequential proposals of the cycle, and it lands with the calm of a routine ticket rather than a keynote.

The pitch is not new capability. It is a canonical baseline. That distinction is the whole story.

What is actually new

On July 2, 2026, Jorge Costa published Merge Proposal: Expanding WordPress Core Abilities on Make/Core. The proposal targets WordPress 7.1 and adds three read-only abilities under the core/ namespace: core/read-settings, core/read-content, and core/read-users. All three sit on top of the Abilities API that landed in 6.9 and the client-side abilities work that landed in 7.0.

The mechanics are deliberately boring. core/read-settings returns a flat name-to-value map of settings, filterable by group or by specific field names, gated on manage_options. core/read-content queries post types in single-item or collection mode. core/read-users looks up users individually or as a filtered collection by role and status. Each ability is a self-contained unit with declared inputs, outputs, permissions, and execution logic — the same contract the Abilities API established last year.

The interesting part is the opt-in flag. Nothing gets exposed automatically. Settings and post types have to raise a new show_in_abilities hand to be visible. That is the same pattern WordPress used for show_in_rest, and it means the ecosystem does not accidentally publish its guts the day 7.1 goes live. The initial implementation of core/read-settings is already open as wordpress-develop PR #12141 by Jorge Costa, opened June 9 and iterated through July 2. The behaviour lives in a new internal WP_Settings_Abilities class explicitly designed so the same code can back a future write ability.

Permissions reuse existing WordPress capabilities: manage_options for settings, list_users for user reads, the normal post-type map for content. There is no new permission tier. Advanced querying — meta_query, tax_query, joins across taxonomies — is explicitly out of scope and deferred to 7.2. The proposal also flags that management abilities (core/manage-settings, core/manage-content, core/manage-users) are the next target, with comments, taxonomies, media, themes and plugins queued behind them.

Names lock at Beta 1 on July 15 per the 7.1 roadmap, so the review window is short. Related tickets track under Trac #64605, #64606, #64657, with additional PRs across the WordPress/ai repository (#691, #806, #739, #774) and wordpress-develop (#12141, #12195, #10775).

Why it matters for WordPress and WooCommerce people

If you have ever integrated an LLM with a client site, you know the drill. You spin up a REST endpoint, wire up authentication, write a permission callback, document the shape, then repeat the same work on the next project with slightly different names. Every agency has its own version of the same three routes, and every plugin has its own version of the same three routes on top of that. It works, but it is not a shared vocabulary.

Canonical read abilities change that arithmetic. The moment 7.1 ships, any client that speaks Abilities — a Gutenberg AI Client, a browser extension, a WebMCP agent, a WooCommerce assistant — knows how to ask a WordPress site for its settings, its posts, and its users without the site owner writing custom glue. That is the value. Not new power, but a common protocol.

The opt-in gate matters here too. On a Woo store, you probably want product settings, tax settings and shipping zones exposed to an internal agent, and you almost certainly do not want the SMTP password exposed to anything. show_in_abilities gives you that control at the point where the setting is registered, not buried in a filter three plugins deep. For agencies running the WooCommerce Abilities work, this is the substrate the extension abilities are being built against.

There is a governance dimension that gets undersold in the release notes. Read-only comes first for a reason. When an agent reads settings, the worst case is disclosure. When an agent writes settings, the worst case is downtime. Shipping reads in 7.1 and management in 7.2 is not a delay, it is a design decision. The ecosystem gets six months to notice what breaks, close disclosure holes, and add proper audit trails before write abilities show up. That is exactly how a mature platform introduces AI-adjacent power.

What I would do (or not do) about it

Three concrete things, in order.

First, audit every register_setting() call in your codebase before Beta 1 on July 15. Anywhere sensitive data lives — API keys, webhook secrets, integration tokens, PII toggles — make sure you have an explicit plan to leave show_in_abilities off. The default is off, so this is mostly a review exercise, but on a mature multi-plugin site you will find surprises. Same drill for custom post types that hold internal notes, drafts under embargo, or client-specific compliance content. Do not assume the future write abilities will save you; the read side already exposes structure.

Second, stop hand-rolling AI-facing endpoints for anything a canonical read ability will cover. If you have a client project that currently ships a bespoke /wp-json/myco/v1/products?agent=1 route, plan the migration to core/read-content filtered by post type. You keep the surface, drop the custom permission callback, and inherit the schema everyone else in the ecosystem is standardising against. That is a real reduction in code you have to babysit forever.

Third, do not build against the management abilities yet. They are not proposed for 7.1. If you have an internal tool that mutates settings via a chatbot, keep it on your own guarded endpoint until core/manage-* ships properly in 7.2 with the corresponding audit and validation semantics. Building on unmerged design is where you find yourself rewriting for free two releases later. This is not the file to be a hero on.

A note on WooCommerce specifically. The Woo team has been iterating on their own abilities layer through 10.8 and 10.9 for products, orders, and read-only extension abilities. Those will sit on top of the core primitives once 7.1 lands, so any bespoke work you do now on a Woo site should be a thin adapter over the canonical shape, not a parallel schema. Two schemas for the same product is two schemas you get to maintain forever.

The pattern here is the same one that made WordPress worth twenty years of my career: boring primitives with strong contracts beat clever features with weak ones. Read abilities in 7.1 are boring on purpose. That is the good news.