[wp-trac] [WordPress Trac] #64596: Abilities API: Allow nested namespace ability names (2-4 segments)

[WordPress Trac]

#64596: Abilities API: Allow nested namespace ability names (2-4 segments)
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by justlevine):

 Replying to [comment:14 jorbin]:
 > > That's why we intentionally designed what we merged into 6.9 around
 being about to make this decision in 7.0 in the most graceful possible way
 >
 > Where was this discussed? It wasn't on #64098 which is where the
 decision to merge the abilities API was made.

 As I'm sure you can imagine a lot of design discussion and iteration
 happened before we ported and proposed it to Core for merge consideration.
 As you've pointed out yourself on a few occasions, the team's been
 ~~struggling~~ working to centralize conversation and decisions, and
 outdated PR comments are again flaking on me (thanks GitHub slop team), so
 bear with me:

 I can't find the code-specific discussion on the ability registry class
 (@gziolo maybe you remember? IIRC it was when we were refactoring the
 property validation to allow for ability class overloading), but I see
 that @ovidiu-galatan
 [https://wordpress.slack.com/archives/C08TJ8BPULS/p1756469802852299?thread_ts=1756463145.644499&cid=C08TJ8BPULS|brought
 it up in August], which I called out in
 https://github.com/WordPress/ai/issues/40#issuecomment-3382538219 (and
 some interspersed conversation) and
 https://github.com/WordPress/ai/issues/21#issuecomment-3269403237 .
 |To my best recollection the final decision was made during the [Sep 25
 Contributor call](https://make.wordpress.org/ai/2025/09/25/core-ai-
 contributor-check-in-september-24-2025/) to focus on semantic grouping via
 Categories for 6.9 and revisit after we hit that deadline.

 It then came up a few times on random PRs/calls, and I believe
 https://github.com/WordPress/wordpress-
 develop/pull/10665#issuecomment-3780868863 was when the frictions with
 flat abilities became most visible (cc @jasontheadams)


 >
 > Stepping back, the arguments I see in favor of nesting are:
 >
 > > organizing abilities into logical resource groups
 >
 > As pointed out, ability catagories are the canonical way to group
 abilities.

 I believe I already answered this in my first direct reply to you on this
 ticket, so to repeat: no they are not. They are the canonical way to
 semantically '''categorize''' abilities. In contrast (as I wrote above):

 "Nested namespaces aren't about semantic categorization but about routing,
 discovery, hierarchical control, scope encapsulation, caching, etc etc. No
 matter how Abilities Categories evolve over time it will always exist in
 the metadata plane, as it a potential solution to an entirely different
 set of problems that we can't deduplicate without compromising the schema-
 based isolation that Abilities are premised on."


 A contrived attempt to illustrate the difference:

 {{{
 [Ability Category: Images - it's a conceptual feature grouping]
 core/post/generate-featured-image
 core/media/search
 core/media/edit-image
 woocommerce/products/create-mockup
 my-local-sync/media-library/push-images
 my-local-sync/media-library/pull-image
 my-local-sync/media-library/download-images
 s3-offload/library
 }}}


 Notice how Ability Categories exist entirely independently of ownership or
 structure.

 (Yes this is more similar to traditional post `Tags` than hierarchical
 post `Categories`. I remember you were an integral part of the discussion
 on renaming to Ability Categories to clarify the distinction at
 https://github.com/WordPress/wordpress-develop/pull/9410 so I won't be
 redundant by rehashing here, sharing for other readers.)

 > Expecting people to run a substring search on all of the abilities isn't
 creating logical groups, it's creating unnecessary complication.

 Nobody's expecting this(?). I'm not entirely sure why you think people
 will need to run a substring search to use abilities. They don't use one
 to invoke REST, pretty permalinks, or hooks. Invoking remains the same.

 What it actually allows is ''browsability'' and ''discoverability''. Think
 of scrolling a list of hundreds `core/get-*` trying to find the one you
 want. Conceptually this is the same for typing autocomplete,
 programmatically surfacing and mapping CP commands (and all the other
 programmatic concerns I mentioned above), and of course allowing LLMs to
 efficiently find and discover the correct ability to invoke.

 >
 > > We plan to use this new type of naming for post abilities.
 >
 > Assuming this is referring to #64455, that ticket is no longer in the
 7.0 milestone.

 Post Abilities was the concrete visualization that caused the team to push
 forward the approach, This is an enhancement in and of itself that we plan
 to use for most - if not all - complex abilities.

 We cannot test or iterate on essential Core abilities ''outside of core'''
 (e.g. in the Experiments plugin for feedback) that would benefit from slug
 fragments without nested abilities being in core (the other solutions I
 came up with add a significant amount of tech-debt, like a hook to short-
 circuit the registry validation - which compromises the schema integrity
 of Abilities (it's entire raison d'etre).

 And we obviously don't want to ship a bunch of subpar `core/{verb}-{post-
 type}` to core to only then have to deprecate and cause the actual
 futurecompat friction we both agree is important to avoid.

 > Forcing version detection onto each plugin is forcing pain on to them.

 Again [https://core.trac.wordpress.org/ticket/64596?replyto=14#comment:10
 |not] what's happening here. Nobody is forced into version detection,
 nobody is forced into adding namespaces.

 > And for what? So there can be a second way to create groupings?

 Asked and answered (I hope - 3x times by my count)

 > In order for the abilities API to do namespaces differently than every
 other part of core that does namespaces?

 Again, nope. Different than blocks. The same as every other instance I
 could think of - and
 [https://core.trac.wordpress.org/ticket/64596?replyto=14#comment:6|previously
 listed out for you] - including REST.


 -----

 (I understand I'm not the best written communicator, but it's very
 frustrating for me when I directly and repeatedly reply to your concerns
 and you pivot or "take a step back" and don't actually engage with what I
 replied - and then ignore it all and just restate your original point. I'm
 a part-time volunteer contributor, and I believe we both share the same
 goals which are to prevent trigger-happy folks from merging slop into
 core. If you disagree with a point I raised, that's obvs fine, but call it
 out please don't ignore it. If you don't understand something I wrote,
 highlight it and I'll try to rephrase more succinctly. My offer to answer
 any questions or concerns you have shortly and directly over DM or a call,
 still stands. But I'm not sure how to advance this conversation forward
 resolution if you won't directly engage 😔)

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