Proposal: Provide extensibility for individual abilities

[gziolo]

Filters

It should be possible to allow extenders to modify the behavior of registered abilities. I propose we make the following extensible:

• input schema – allow modifying the schema of the input passed to the action
• output schema – allow modifying the schema of the produced output
• permissions check – allow changing the condition for executing the ability
• execution result – allow modifying the output result

Example for how to revoke access to the ability:

$filter_cb = static function ( $permission, $ability_name ) {
	if ( 'test/filter-ability' !== $ability_name ) {
		return $permission;
	}

	return false;
};

add_filter( 'ability_permission_result', $filter_cb, 10, 2 );

Actions

It should also be possible to fire action before and after ability execution to allow developers to hook into the ability lifecycle for monitoring, logging, or extending functionality.

Example for how to log the succesful ability execution:

$action_cb = static function ( $ability_name, $input, $result ) {
	if ( 'test/action-ability' !== $ability_name ) {
		return;
	}

	my_plugin_log_ability_result( $ability, $input, $result );
		
};

add_action( 'executed_ability', $action_cb, 10, 3 );

[justlevine]

Due to the very short timeline until core merge, if we're unable to wait for MCP Adapter / AI Experiments / users to provide concrete use cases we should try and rubber-duck these ourselves.

We can also see try and gather use cases from WP Feature API but I'd be wary about using it as code inspiration as the needs and considerations for a WP Core API are different than that plugin. (e.g. Automattic/wp-feature-api#10)

[gziolo]

New Proposal

I would like to extend the proposal to include actions triggered during the ability execution. I sketched a new PR to illustrate it:

• Add execute actions to the ability object #56

It adds extensibility hooks to the ability execution flow by introducing two action hooks that fire before and after ability execution. This allows developers to hook into the ability lifecycle for monitoring, logging, or extending functionality.

Example:

$action_cb = static function ( $ability_name, $input, $result ) {
	if ( 'test/action-ability' !== $ability_name ) {
		return;
	}

	my_plugin_log_ability_result( $ability, $input, $result );
		
};

add_action( 'executed_ability', $action_cb, 10, 3 );

Additional notes

Technically speaking, it would also be possible to use ability_class property when registering abilities and extend WP_Ability class with some custom handling for execute or do_execute, depending on which stage you want to log needed information.

Both approaches would work. It feels to me like WP core should support both to cater to different types of devs. OOP is for larger plugins, but hooks are convenient for folks who like to apply some changes to items that are already registered by someone else.

One important consideration here. In the case where ability_class is set when registering an ability, extending it further with additional logic would become rather cumbersome and invites conflicts or race conditions.

[justlevine]

Hey @gziolo et al, please take a look at my filter counterproposal to #37. I believe that single-filter approach provides even more flexibility/extensibility than the multi-filter approach, while dealing with my concerns about future-compat and lifecycle unreliability I expressed on that PR. Array shapes FTW again.

• dev: add register_ability_args filter [Proposal] #74

[gziolo]

please take a look at my filter counterproposal to #37. I believe that single-filter approach provides even more flexibility/extensibility than the multi-filter approach, while dealing with my concerns about future-compat and lifecycle unreliability I expressed on that PR.

I will have a look. I don't consider these two as mutually exclusive. They both play different roles. Something like wp_ability_args is also a well-established practice that I would be in favor of.