[wp-trac] [WordPress Trac] #64596: Allow ability names to contain multiple slug fragments (2-4 segments)

[WordPress Trac]

#64596: Allow ability names to contain multiple slug fragments (2-4 segments)
--------------------------------------+-------------------------
 Reporter:  jorgefilipecosta          |       Owner:  justlevine
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.1
Component:  Abilities API             |     Version:  6.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by justlevine):

 @gziolo - I agree with your rationale about not wanting Abilities to
 handle too many roles, but disagree with the specific examples you gave of
 overreach (IMO hierarchy and routing are potentially justifications _for_
 slug fragments), and as a result your conclusion. 😅

 > This also gets awkward once abilities are exposed through REST.

 As noted in [https://core.trac.wordpress.org/ticket/64345#comment:12 | the
 other ticket] I believe versioning **altogether** is an antipattern, our
 official implementation should encourage versionless deprecation, and yes
 if someone still wants to implement versioning we should corral them
 towards Ability metata.

 That said, I believe your illustration is an example of why ''versioning
 specifically'' is a bad idea in the name, and not that the name shouldn't
 support multiple slug fragments. Just like it'd be a bad idea to do `/wp-
 json/my-namespace/v1/math/v5/calculator` or `wp my-cli-commands math v5
 calculator`, even though as you note both are technically supported.

 As a reminder, Abilities are a primitive, so I'd encourage you not to view
 it as "overlapping REST", but rather being able to serve as the underlying
 foundation for e.g. [https://developer.wordpress.org/rest-api/reference
 /block-directory-items/#list-block-directory-items| wp/v2/block-
 directory/search ]

 > [...] rely on categories, metadata, schema, and discovery filters for
 grouping and querying. Unless there is a strong use case that cannot be
 handled by the existing structured mechanisms.

 There are a few noted in this thread, but IMO the biggest one (besides for
 being able to support "downstream" Adapter use cases like REST and WPCLI)
 is discovery and progressive disclosure.  An easy way to visualize would
 be CLI or Command Palette autocompletions: `woo/get-%` or worse a semantic
 "Get %" (since the namespace is ''also'' not intended for categorization
 but a deconfliction mechanism) is an unusable list of potentially
 [https://github.com/WordPress/ai/issues/21| hundreds or thousands
 abilities]. Slug fragments solve this intuitively with 0 additional
 compute or additional roundtrips.

 Hierarchical grouping does not serve the same purpose as categorical
 metadata, and an API for querying/filtering isn't a substitute either. I
 go through this in a fair amount of detail above, so to avoid redundancy I
 won't rehash here.

 Perhaps you can share an example you're concerned about that doesn't
 involve an obvious antipattern like versioning? It would really help me
 better understand and evaluate them. (e.g. if it's just versioning and
 you're concerned enough to block the behavior, we could simply prevent
 `/v#/` with a negative lookahead or a negated char group if we wanted to
 optimize prematurely). I suggest rubber-ducking what the ability would
 look like translated by ''multiple adaptations'' e.g. REST + CLI + Command
 Palette, instead of just REST.

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