[wp-trac] [WordPress Trac] #64455: WordPress Core Abilities

[WordPress Trac]

#64455: WordPress Core Abilities
------------------------------+---------------------
 Reporter:  jorgefilipecosta  |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  AI                |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by jorgefilipecosta):

 Hi @peterwilsoncc, thank you for looking into this issue and bringing
 important discussion points.

 > @jorgefilipecosta Are you able to write up a merge proposal for this on
 the make/core blog? cc @flixos90 @jeffpaul

 I'm happy to write a post on Make/Core to get wider visibility on this.
 That said, I wanted to clarify, for future tasks, aren't merge proposals
 typically intended for larger efforts developed outside of core (e.g., a
 feature plugin) that need to be merged in? In this case, abilities are
 being developed incrementally, one by one, via PRs directly against core.


 > As the existing REST API endpoints include these abilities, the proposal
 would need to make clear why the new endpoints are needed instead of a
 proposal to expand the existing endpoints to allow for using the extended
 features.

 On the question of why new abilities rather than expanding the existing
 REST API endpoints, I believe this is addressed in the "Why WordPress
 Needed Abilities" section of https://make.wordpress.org/ai/2025/11/21
 /meet-abilities-wordpress-new-functional-core/. The key point is that the
 REST API alone was not a sufficiently standardized layer for sharing
 functionality across different contexts. The Abilities API was introduced
 precisely so that plugins and core can expose their functionality in a
 standardized, machine-readable way that can be consumed by CLIs, MCP (via
 the MCP Adapter), browser-based MCP clients, and more. The REST API is one
 transport channel for ability consumption, but it's not the only one.

 For example, core has already introduced `core/get-site-info` and `core
 /get-user-info`, both of which could technically be done via the REST API,
 but we still standardized that information as abilities. The same
 reasoning applies to post management, setting management, etc.
 If we accept the premise that the Abilities API is the standardized way
 for core and plugins to declare what they can do (which we did, given that
 the Abilities API is already part of core) then it follows that core
 itself should expose its own base functionality (like creating, reading,
 and querying posts) as abilities. These are foundational operations, and
 without them, features like the WP AI Client
 (https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-
 client-into-wordpress-7-0/), which integrates directly with abilities,
 wouldn't be able to perform basic, useful tasks like post and setting
 retrieval/manipulation.

 > I'd also like to see details on how the performance and security
 implications of including these features has been evaluated.

 Regarding security: the post abilities follow the same pattern established
 by the existing abilities. Each ability has a `permission_callback` that
 checks whether the current user can perform the action using the existing
 roles and capabilities system. For the specific case of `meta_query`,
 `tax_query`, and `date_query`, the intent is not to expose new
 information. A consumer could already use the REST API to retrieve all
 posts and then filter by meta, taxonomy, or date client-side, it would
 just be a very inefficient way of doing it. To avoid accidental data
 leakage, we will rely on the `show_in_abilities` pattern that was
 introduced for settings, so only meta keys or taxonomies that explicitly
 opt in will be queryable; the rest will be filtered out.

 Regarding performance: we are not creating new query logic ourselves. The
 plan is to rely on already existing core functions (like `WP_Query`,
 `get_post`, `wp_insert_post`, etc.) to retrieve and update the
 information. Plugins and core are already using these functions
 extensively, so they should be solid in terms of performance. If a
 performance issue were to surface, it would likely need to be addressed in
 those existing functions rather than in the ability layer itself.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64455#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform