WordPress 7.1 Adds Standard Filtering to Abilities API

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Every time I read a new dev note from the WordPress 7.1 cycle, I find myself running the same test in my head: if an AI agent showed up at my client’s admin tomorrow and started calling things, would the platform give it a menu it can read, or a black box it has to guess through? The Abilities API is quietly answering that question, one dev note at a time, and this week’s answer is the discovery half.

Two weeks ago the execution side got its middleware seams. This week the discovery side gets a proper filter pipeline. Both land in WordPress 7.1, which ships in exactly one week at WordCamp US in Phoenix. If you have been putting off reading the Abilities API dev notes until GA, you have run out of buffer.

I have watched enough waves of “programmable admin” go by to know the difference between an API that agencies can build on and an API that spawns a plugin marketplace of duct tape. This one is landing on the right side of that line, and the ergonomics matter more than they look.

What is actually new

Milana Cap’s August 5 dev note, Filtering registered abilities with wp_get_abilities() in WordPress 7.1, documents an optional $args array that turns a raw registry read into a first-class discovery query. The function is not new; the pipeline is.

You can now pass any combination of category, namespace, meta, item_include_callback, and result_callback. Core matches the declarative arguments first (category, then namespace, then meta with strict comparison), then runs your per-item callback, then applies the new wp_get_abilities_item_include filter for each candidate. Once the array is assembled, it hands off to your optional result_callback and finally to the wp_get_abilities_result filter for a site-wide pass. The order is deliberate and, more importantly, documented.

The signature is boring, which is what I want:

$abilities = wp_get_abilities( array(
    'category'  => 'data-export',
    'namespace' => 'my-plugin',
    'meta'      => array( 'public' => true ),
) );

The REST layer inherits the same vocabulary. GET /wp-json/wp-abilities/v1/abilities?namespace=my-plugin&category=data-export is now a query that means what it says, and the built-in readonly, destructive, and idempotent annotations get coerced from string to boolean on their way in. That is the small kind of API design that decides whether an LLM tool call succeeds or hallucinates.

The note is explicit about one thing worth quoting: filtering “controls which abilities are returned during discovery. It does not determine whether the current user may execute an ability.” The permission_callback stays load-bearing. Discovery and authorization are two different jobs and 7.1 keeps them that way.

Read this alongside the July 29 dev note on the four execution lifecycle filters (wp_pre_execute_ability, wp_ability_normalize_input, wp_ability_permission_result, wp_ability_execute_result) and the picture snaps into focus. Execution middleware landed first. Discovery middleware landed second. Between them, you now have the seams to shape both what an agent can see and what an agent can do — without patching core, without wrapping the registry, without a third-party layer.

Everything above is pinned for GA. RC1 shipped on August 5 per the 7.1 Release Candidate 1 announcement, and the surface is documented in the 7.1 Field Guide alongside the 300-plus other tickets landing on August 19.

Why it matters for WordPress and WooCommerce people

The Abilities API is the surface that AI agents, workflow tools, and internal admin scripts will call. If you are running a WooCommerce store, “call” eventually means someone asking a chat model to add a coupon, refund an order, or export a customer list — and that flow starts with the model asking WordPress what it is allowed to do.

Before this dev note, everyone who wanted to expose a curated subset of abilities to a specific integration ended up writing their own discovery wrapper. Some grepped the registry, some hooked rest_pre_dispatch, some invented their own option-driven allowlist. All three flavors accumulate the exact kind of technical debt that Matt Mullenweg called out a week ago in Defensive Data Design: the platform’s job is to make the safe path easy and the destructive path visible, and doing that consistently only works if there is one canonical way to filter what an agent sees.

For agencies the practical win is smaller and more immediate. Every custom admin dashboard I ship in the next twelve months will need to answer “which abilities does this client’s finance team get, and which does the shop manager get” — and until this week the honest answer was “we roll our own filter in a mu-plugin”. Now the answer is wp_get_abilities with a meta constraint and a small allowlist, versioned in the theme or mu-plugin, one file to review at handover.

The REST integration is the other quiet win. If you are building an internal tool, an MCP server, or a scheduled workflow that reads the abilities collection, you now get filtering as query parameters. That removes two round trips and about forty lines of client-side glue from the average integration.

What I would do (or not do) about it

This week, before RC3 lands and the branch tightens further: pull the dev note up on one screen and your production Abilities registrations up on the other. For every ability, decide three things — the category it belongs in, the meta flags you want to filter on later (public, internal, scope), and whether it needs the destructive annotation. Those three decisions are the design surface. Once they are set, wp_get_abilities gives you the query language for free.

Next: rewrite any bespoke discovery wrapper you shipped in the last twelve months against the new pipeline. Use item_include_callback for tenant-level rules, result_callback for shape transformations, and reach for the two filters (wp_get_abilities_item_include, wp_get_abilities_result) only when the logic legitimately belongs outside the caller. Every line of custom registry-grepping code you delete is a line the next agency owner does not have to reason about.

Do not, and I mean this, ship an admin UI plugin for configuring Abilities API filters this quarter. The whole point of the API is that discovery is declarative and versioned with the site. Wrapping it in a settings screen that stores rules in wp_options is exactly the pattern the API was designed to retire — and the moment those rules live in a database row, they survive one theme migration and vanish on the second.

Do not stack this audit on the WordPress 7.1 GA update window on August 19 either. Read the note this week, sketch the categories and meta this weekend, ship the refactor the week of August 24 when 7.1 is on production and the dust has settled. Two moving pieces per change window is still the ceiling that keeps Saturdays free.

The version numbers get the headlines; the seams get the work. This is one of the seams.