[wp-trac] [WordPress Trac] #64990: Add filtering support to `wp_get_abilities()`

[WordPress Trac]

#64990: Add filtering support to `wp_get_abilities()`
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.1
Component:  Abilities API                        |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note                                           |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * keywords:  2nd-opinion has-patch has-unit-tests => has-patch has-unit-
     tests needs-dev-note
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 == For the dev note purposes

 The implementation follows the proposal's pipeline and semantics. A few
 specifics that should be reflected accurately in the dev note:

  * '''Arg and filter renamed.''' The per-item caller callback is
 {{{item_include_callback}}} (not {{{match_callback}}}), the per-item
 filter is {{{wp_get_abilities_item_include}}} (not
 {{{wp_get_abilities_match}}}), the boolean parameter is {{{$include}}}.
 Framing proposed as "should we include this item?" rather than "did this
 match?".

  * '''{{{namespace}}} accepts a single string only.''' Unlike
 {{{category}}}, which accepts {{{string|string[]}}} with OR logic within,
 {{{namespace}}} currently takes one string. Document the as-shipped shape,
 but note that this is expected to change — see the follow-up below.

  * '''REST endpoint exposes {{{category}}} and {{{namespace}}}, not
 {{{meta}}}.''' The PHP {{{meta}}} arg (AND logic, nested keys) is fully
 supported, but it is not surfaced as a REST query parameter. Describe the
 PHP {{{meta}}} arg without implying REST parity, until the decision
 changes later to extend params in the REST API.

  * '''New private helper.''' {{{_wp_get_abilities_match_meta()}}}
 recursively evaluates nested meta conditions (AND across keys, descending
 into sub-arrays). It's underscore-prefixed and not part of the public API
 — out of scope for the dev note, but worth knowing it exists when reading
 {{{wp_get_abilities()}}}.

 == Follow-up tasks

  1. '''Align {{{namespace}}} shape with {{{category}}}''' — accept
 {{{string|string[]}}} with OR logic within. Alternatively, limit that to a
 single string aligning with how the current REST API contract is
 implemented. Best landed before the dev note publishes, so the public
 surface is consistent from day one.
  2. '''Expose {{{meta}}} filtering on the REST endpoint''' — decide
 whether to add a {{{meta}}} query parameter so the REST surface reaches
 parity with the PHP API, as the original Phase 2 suggested.

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