wp-includes/abilities-api/class-wp-ability.php:623Checks whether the ability has the necessary permissions.
$inputmixedoptionalnullbool|WP_ErrorOne hook fires while WP_Ability::check_permissions() runs, in this order:
Filters the result of an ability's permission check.
public function check_permissions( $input = null ) { if ( ! is_callable( $this->permission_callback ) ) { return new WP_Error( 'ability_invalid_permission_callback', /* translators: %s ability name. */ sprintf( __( 'Ability "%s" does not have a valid permission callback.' ), $this->name ) ); } $permission = $this->invoke_callback( $this->permission_callback, $input ); /** * Filters the result of an ability's permission check. * * Fires after the registered `permission_callback` returns. Plugins can use this to layer * additional authorization rules on top of the ability's own permission logic — for example, * multi-factor authorization gates or temporary permission elevation for trusted contexts. * * Filters can return `true` to grant, `false` to deny, or a `WP_Error` to deny with a specific * error code and message. The filter receives whatever the `permission_callback` produced. * Any other return value is coerced to `false`. * * @since 7.1.0 * * @param bool|WP_Error $permission The permission result returned by `permission_callback`. * @param string $ability_name The name of the ability. * @param mixed $input The input data for the permission check. * @param WP_Ability $ability The ability instance. */ $result = apply_filters( 'wp_ability_permission_result', $permission, $this->name, $input, $this ); if ( ! is_bool( $result ) && ! is_wp_error( $result ) ) { $result = false; } return $result; }Introduced in 6.9.0. Unchanged from 6.9.7 through 7.1.0.
Signature, return type and hooks compared across 3 parsed releases.
src/wp-includes/abilities-api/class-wp-ability.php, and regenerated for each WordPress release so it tracks the code rather than a snapshot of it.