Feature #64990: Add filtering support to wp_get_abilities() via $args array#11531
Feature #64990: Add filtering support to wp_get_abilities() via $args array#11531Vedanshmini26 wants to merge 7 commits intoWordPress:trunkfrom
wp_get_abilities() via $args array#11531Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
@Vedanshmini26, I missed your PR. This is a great start, and it covers the scope for extending I see several unrelated changes like |
Vedanshmini26
force-pushed
the
filtering-wp-abilities
branch
2 times, most recently
from
f79e1f4 to
cc38e90
Compare
Vedanshmini26
force-pushed
the
filtering-wp-abilities
branch
from
cc38e90 to
0350d8e
Compare
|
@gziolo I've removed the unrelated changes. Can you please check it now once? |
| $category = isset( $args['category'] ) ? (array) $args['category'] : array(); | ||
| $namespace = isset( $args['namespace'] ) && is_string( $args['namespace'] ) ? rtrim( $args['namespace'], '/' ) . '/' : ''; | ||
| $meta = isset( $args['meta'] ) && is_array( $args['meta'] ) ? $args['meta'] : array(); | ||
| $match_callback = isset( $args['match_callback'] ) && is_callable( $args['match_callback'] ) ? $args['match_callback'] : null; | ||
| $result_callback = isset( $args['result_callback'] ) && is_callable( $args['result_callback'] ) ? $args['result_callback'] : null; |
There was a problem hiding this comment.
This is worth double-checking with other similar functions to see whether silently dropping args with incorrect types is the established best practice.
There was a problem hiding this comment.
I checked against similar WordPress query functions — get_posts(), get_terms(), and WP_Query all silently cast or ignore args with incorrect types without triggering warnings. For example, get_posts() accepts 'category' as either a string or an integer and handles both without complaint. Our implementation follows the same established pattern: category is cast via (array), which safely handles both string and array inputs, while namespace, match_callback, and result_callback are guarded with is_string()/is_callable() checks and silently fall back to their defaults when the type is wrong.
If stricter developer feedback is desired, _doing_it_wrong() calls could be added in a follow-up, but silent dropping/casting is consistent with how WordPress core query functions have always behaved.
gziolo
left a comment
gziolo
left a comment
There was a problem hiding this comment.
All good now. I left some minor comments.
The only missing part is detailed unit test coverage, as noted earlier.
… and rename private helper to _wp_get_abilities_match_meta - Rename wp_get_abilities_match_meta() to _wp_get_abilities_match_meta() per WordPress private function naming convention - Add tests/phpunit/tests/abilities-api/wpGetAbilities.php covering: - category filter (single string, array OR logic, non-existent) - namespace filter (prefix match, trailing-slash normalisation, non-existent) - meta filter (single key, AND logic across keys, nested arrays, missing key) - match_callback per-item inclusion/exclusion and argument passing - wp_get_abilities_match filter hook exclusion and argument passing - result_callback result reshaping and argument passing - wp_get_abilities_result filter hook reshaping and argument passing - Combined category + meta and namespace + match_callback filters
…riable use declarations to one-per-line
…-per-line in result filter test
…_include in filter callbacks
|
@gziolo I've resolved the PR comments and added the unit test coverage. Can you please look into it? |
|
Yes, I will have a closer look later, but it should be good as is. Looking at WordPress 7.0 Release Party Updated Schedule, we can commit these changes in mid-May because WordPress |
gziolo
changed the title
wp_get_abilities() via $args array
2 participants
Core Trac Ticket: https://core.trac.wordpress.org/ticket/64990
Problem
wp_get_abilities() accepts no arguments and always returns the full registry. Callers who need a subset — by category, namespace, meta properties, or any combination — must retrieve all abilities and filter manually. As the number of registered abilities grows across core, plugins, and themes, several consumers have independently built ad-hoc filtering to work around this gap:
The MCP Adapter checks meta.mcp.public and meta.show_in_rest with its own array_filter pass
WooCommerce (v10.3+) introduced a woocommerce_mcp_include_ability filter that performs namespace-prefix matching (str_starts_with( $ability_id, 'woocommerce/' ))
The REST API controller already supports ?category filtering, but implements it with its own post-retrieval array_filter rather than delegating to wp_get_abilities()
This duplication signals a missing primitive. Each consumer reimplements the same patterns with slightly different semantics and no shared hook point for ecosystem-level participation.
Root Cause
wp_get_abilities() was shipped in 6.9 without filtering support. The REST API controller added its own array_filter logic for show_in_rest and category filtering instead of a shared primitive, creating a mismatch between what the PHP and REST APIs support. There was no per-item or result-level hook for plugins to participate in ability filtering without monkey-patching call sites.
Solution
Extends wp_get_abilities() to accept an optional $args array, following the established WordPress convention of array-based arguments (get_posts(), get_terms()). When called without arguments, behaviour is completely unchanged — no BC break.