WP_REST_Abilities_V1_Run_Controller::register_routes │ public │ WP 6.9.0

Registers the routes for ability execution.

Method of the class: WP_REST_Abilities_V1_Run_Controller{}

No Hooks.

Returns

null. Nothing (null).

Usage

$WP_REST_Abilities_V1_Run_Controller = new WP_REST_Abilities_V1_Run_Controller();
$WP_REST_Abilities_V1_Run_Controller->register_routes(): void;

Notes

• See: register_rest_route()

Changelog

WP_REST_Abilities_V1_Run_Controller::register_routes() WP REST Abilities V1 Run Controller::register routes code ^{WP 6.9.1}

public function register_routes(): void {
	register_rest_route(
		$this->namespace,
		'/' . $this->rest_base . '/(?P<name>[a-zA-Z0-9\-\/]+?)/run',
		array(
			'args'   => array(
				'name' => array(
					'description' => __( 'Unique identifier for the ability.' ),
					'type'        => 'string',
					'pattern'     => '^[a-zA-Z0-9\-\/]+$',
				),
			),

			// TODO: We register ALLMETHODS because at route registration time, we don't know which abilities
			// exist or their annotations (`destructive`, `idempotent`, `readonly`). This is due to WordPress
			// load order - routes are registered early, before plugins have registered their abilities.
			// This approach works but could be improved with lazy route registration or a different
			// architecture that allows type-specific routes after abilities are registered.
			// This was the same issue that we ended up seeing with the Feature API.
			array(
				'methods'             => WP_REST_Server::ALLMETHODS,
				'callback'            => array( $this, 'execute_ability' ),
				'permission_callback' => array( $this, 'check_ability_permissions' ),
				'args'                => $this->get_run_args(),
			),
			'schema' => array( $this, 'get_run_schema' ),
		)
	);
}