Abilities API: add filters for input and output validation

[priethor]

The Abilities API currently validates ability input and output against JSON Schema using WordPress's built-in rest_validate_value_from_schema(), which supports only a subset of JSON Schema Draft 4 (aligning with WordPress core). This approach is reliable for core compatibility but limits extenders to dated JSON Schema features, missing newer ones like $ref references for composability and reusability, and not keyword to exclude patterns.

Developers extending the Abilities API that need more expressive schema validation have no way to override the default validator without forking or monkey-patching.

Proposed Solution

Introduce two hooks to allow custom validation:

/**
 * Filters the input validation result for an ability.
 *
 * @since 7.0.0
 *
 * @param true|WP_Error $is_valid Validation result (true or WP_Error).
 * @param mixed         $input    The input being validated.
 * @param string        $name     The ability name.
 */
apply_filters( 'wp_ability_validate_input', $is_valid, $input, $name );

/**
 * Filters the output validation result for an ability.
 *
 * @since 7.0.0
 *
 * @param true|WP_Error $is_valid Validation result (true or WP_Error).
 * @param mixed         $output   The output being validated.
 * @param string        $name     The ability name.
 */
apply_filters( 'wp_ability_validate_output', $is_valid, $output, $name );

Related

• GitHub Issue: ​https://github.com/WordPress/abilities-api/issues/149
• GitHub PR: ​https://github.com/WordPress/abilities-api/pull/150

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

[juanmaguitar]

Because of the lack of activity in the last 3 months and due to the Beta1 freeze happening in 24hrs I'm punting this to "Future Release"

[gziolo]

Worth noting that similar extensibility was explored earlier in ​https://github.com/WordPress/abilities-api/pull/37, which proposed ability_input_schema and ability_output_schema filters. However, the filters proposed here are more powerful — they operate on the validation result rather than the schema itself. Schema-level filtering can already happen at registration time, whereas these hooks give developers control over the validation logic, which is the actual constraint point for supporting newer JSON Schema features.

That same PR also proposed ability_permission_result and ability_execute_result filters. It might be worth considering whether those should be part of the parallel effort as well, to provide a complete set of extensibility points across the ability lifecycle.

I'd be happy to see this proposal included in WordPress 7.1.

One thing to address: the add_filter() calls in the new tests use anonymous closures and are never cleaned up with remove_filter(). Since PHPUnit runs tests in the same process, filters added in one test can leak into subsequent tests and silently affect results. Each test should store the closure reference and remove it after assertions, e.g.:

@gziolo Actually, this isn't a concern because the hooks get reset after each test is run, regardless of whether the tests run in a separate processor not.

In set_up:

​https://github.com/WordPress/wordpress-develop/blob/4d3b0b9ab132dfcf83cfb66f2939eba176b2584d/tests/phpunit/includes/abstract-testcase.php#L117-L119

In tear_down:

​https://github.com/WordPress/wordpress-develop/blob/4d3b0b9ab132dfcf83cfb66f2939eba176b2584d/tests/phpunit/includes/abstract-testcase.php#L228

@westonruter, thank you so much for pointing me to that logic. That’s perfect. I’m glad it existed as this is the very well designed default behavior 👍

I intend to land this PR as soon as 7.1 cycle starts.

[gziolo]

I proactively followed up with #64989 to expand filtering in other aspects of the execution lifecycle for individual abilities.