[wp-trac] [WordPress Trac] #64098: Introduce Abilities API

[WordPress Trac]

#64098: Introduce Abilities API
--------------------------------------------------+---------------------
 Reporter:  gziolo                                |       Owner:  (none)
     Type:  feature request                       |      Status:  new
 Priority:  normal                                |   Milestone:  6.9
Component:  General                               |     Version:  trunk
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch 2nd-opinion has-unit-tests  |     Focuses:
--------------------------------------------------+---------------------

Comment (by jorbin):

 Thank you @gziolo. The additional context is helpful and I'm glad we are
 having this discussion.

 The comparison to the REST API feels off though since that was developed
 over a considerably longer amount of time. It went through multiple
 iterations before the [https://make.wordpress.org/core/2015/09/21/wp-rest-
 api-merge-proposal/ proposal to merge in a multi step manor] was shared a
 month before beta 1 wheras this never had a merge proposal published just
 a ticket opened a week before beta. One week ago
 [https://github.com/WordPress/abilities-
 api/issues/105#issuecomment-3392491695 initial abilities were still be
 discussed and considered].

 > Having a formal API for defining and exposing those interactions ensures
 WordPress remains relevant as part of the AI-native web, while simplifying
 the developer experience through a unified, self-authenticating interface
 accessible via PHP, REST, or MCP.>

 Can you go a bit deeper on what you mean by "self-authenticating"? I'm not
 finding anything in [https://github.com/search?q=repo%3AWordPress
 %2Fabilities-api%20%22self-authenticating%22&type=code the github repo] or
 in slack that describes the API in such a way.

 > Merging the Abilities API in 6.9 gives plugin authors and extenders the
 opportunity to validate the approach during the release cycle,
 establishing a solid foundation for iterative improvements in future
 versions of core.

 The iterative improvements are much more constrained once backwards
 compatibility needs to be paramount.

 > There is also an open PR https://github.com/WordPress/abilities-
 api/pull/108 that is almost ready to land which proposes 3 basic read-only
 core abilities that we can ship together with API in WordPress 6.9. This
 is going to be the most challenging process to identify what WP core
 should offer as built-in abilities, and leaving that to the ecosystem
 might be the best idea. Our intuition tells us based on the prototypes
 floating around, is that WordPress core should offer CRUD operations for
 handling content and it's tracked in https://github.com/WordPress
 /abilities-api/issues/84. However, that's much larger effort than the API
 itself, so this is something we would like to experiment with in the AI
 featured plugin.

 Again, I very much agree that identifying what abilities to ship initially
 is a challenge, but those abilities also will help ensure that the API is
 flushed out for all of core's needs which also means that the API is much
 better for extenders needs.

 > I think it's important we do try to get this into 6.9 so that plugin
 developers can ship without worrying about trying to ship copies of the
 feature plugin in their own code, because the abilities API seems to be
 the foundation AI exposure, and quite frankly, waiting another x months
 puts us all at a disadvantage.

 There is no featured plugin. There is a composer package which is supposed
 to make it esier to embed than trying to ship a copy of a feature plugin
 in your code (which also is something you should never do, but I digress)


 > Strategically, the API also prepares WordPress for the growing
 importance of AI-driven and cross-system integrations. Transformer-based
 systems increasingly rely on structured, callable actions—“abilities”—to
 describe functionality in a machine-readable, executable form.

 I completely agree, and it's the biggest reason that I am in favor of
 merging despite the API not feeling as tested or mature as I think a new
 API of this importance should be. What I would like to find though is a
 way to ensure that what is shipped in 6.9 (and thus supported by Core for
 the long run) is something that is easily maintainable and isn't going to
 make future iterations harder.

 A couple ideas to help with that:

 - Come up with a big list of core abilities and do at least some psuedo-
 code to see if the API will work well for them.
 - Before the final beta, have five (or more) plugins that are already in
 the repo ship abilities that use the version that gets committed to core.
 - Implement abilities in WP-CLI and make sure that the API solves the
 needs there.
 - Identify if there are other places that should use the abilities API
 (the command palate is one that stands out off the top of my head) and ask
 maintainers of those to also come up with an initial implementation.

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