Abilities API: Avoid _doing_it_wrong() on REST lookups of unknown abilities.

[dhrupo]

Trac ticket: https://core.trac.wordpress.org/ticket/65644

Summary

The Abilities REST controllers resolve an ability (or category) from the name/slug in the request URL and return a 404 when it does not exist — calling wp_get_ability() / wp_get_ability_category() directly:

$ability = wp_get_ability( $request['name'] );
if ( ! $ability ) {
    return new WP_Error( 'rest_ability_not_found', __( 'Ability not found.' ), array( 'status' => 404 ) );
}

Those functions delegate to WP_Abilities_Registry::get_registered() / WP_Ability_Categories_Registry::get_registered(), which deliberately call _doing_it_wrong() for an unknown name to flag developer misuse. Because the name is client-controlled, a routine 404 for a non-existent ability fires _doing_it_wrong() on every such request — including via the run endpoint's permission_callback, so unauthenticated requests trigger it too.

Core's rest_api_default_filters() suppresses the trigger_error() output during REST requests (see #64260), but the doing_it_wrong_run action still fires, so the notice surfaces in Query Monitor, in doing_it_wrong_run listeners / logging plugins, and in the test suite — the not-found REST controller tests currently carried @expectedIncorrectUsage. Existence-probing a public endpoint should not emit a developer "doing it wrong" warning.

Reproduction

POST /wp-json/wp-abilities/v1/abilities/non/existent/run returns the expected 404, but (surfaced via Query Monitor / the doing_it_wrong_run action) _doing_it_wrong() fires:

WP_Abilities_Registry::get_registered was called incorrectly. Ability "non/existent" not found.

See the before/after screenshots on the Trac ticket.

Fix

Guard each REST lookup with the non-warning existence helper before calling the getter:

$ability = wp_has_ability( $request['name'] ) ? wp_get_ability( $request['name'] ) : null;

A missing ability then yields a clean 404 with no _doing_it_wrong(). The registry getters keep warning on direct misuse (that behavior is intentional and separately tested — unchanged here). Applied to all five lookup sites across the run, list, and categories controllers.

Testing

Removed the now-unnecessary @expectedIncorrectUsage annotations from the four affected not-found REST tests, which now assert a clean 404.

• Before the fix, those tests fail: Unexpected incorrect usage notice for WP_Abilities_Registry::get_registered.
• After the fix, they pass.

Full suites green:

Abilities REST controllers: 67 tests
--group abilities-api: 361 tests, 962 assertions

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.8
Used for: Locating the affected call sites, reproducing the notice, implementing the guards, and updating the tests. All changes were reviewed by me.

[github-actions]

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props dhrupo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The 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

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.