| 1 |
<?php |
| 2 |
/** |
| 3 |
* Charitable abilities hooks. |
| 4 |
* |
| 5 |
* The wp_abilities_api_* hooks exist only in WordPress 6.9+, so on older cores |
| 6 |
* these callbacks never fire and nothing registers. That is the entire |
| 7 |
* version-guard strategy — no polyfill, no vendored dependency. |
| 8 |
* |
| 9 |
* Note the version guard covers REGISTRATION only. `wp_after_execute_ability` |
| 10 |
* is core 6.9.0 but `wp_ability_invoked` is 7.1.0, so on 6.9 and 7.0.x |
| 11 |
* abilities work while denial logging and invocation counting do not. See |
| 12 |
* Charitable_Abilities_Usage for the clamp that stops that reporting a |
| 13 |
* negative failure count. |
| 14 |
* |
| 15 |
* @package Charitable/Functions/Abilities |
| 16 |
* @copyright Copyright (c) 2026, WP Charitable LLC |
| 17 |
* @license http://opensource.org/licenses/gpl-2.0.php GNU Public License |
| 18 |
* @since 1.8.13 |
| 19 |
* @version 1.8.13 |
| 20 |
*/ |
| 21 |
|
| 22 |
if ( ! defined( 'ABSPATH' ) ) { |
| 23 |
exit; |
| 24 |
} |
| 25 |
|
| 26 |
add_action( 'wp_abilities_api_categories_init', array( Charitable_Abilities::get_instance(), 'register_category' ) ); |
| 27 |
add_action( 'wp_abilities_api_init', array( Charitable_Abilities::get_instance(), 'register_abilities' ) ); |
| 28 |
add_filter( 'charitable_log_types', array( Charitable_Abilities::get_instance(), 'register_log_type' ) ); |
| 29 |
add_filter( 'charitable_log_sources', array( Charitable_Abilities::get_instance(), 'register_log_sources' ) ); |
| 30 |
add_filter( 'charitable_system_info_sections', array( Charitable_Abilities_System_Info::get_instance(), 'render' ) ); |
| 31 |
add_action( 'wp_ability_invoked', array( Charitable_Abilities::get_instance(), 'log_ability_invocation' ), 10, 3 ); |
| 32 |
|
| 33 |
/* |
| 34 |
* Priority 9, strictly before set_error_http_status() at 10. That method's own |
| 35 |
* "never override a status something upstream set deliberately" guard would |
| 36 |
* otherwise leave core's 404 in place on every one of the six gated slugs, and |
| 37 |
* charitable_capability_unavailable would never be constructed. See |
| 38 |
* Charitable_Abilities::intercept_gated_ability() for the full reasoning. |
| 39 |
* |
| 40 |
* That method reads the ability name from `$request->get_param( 'name' )`, |
| 41 |
* which core has already parsed off the route by this point - the slug |
| 42 |
* arrives as a literal slash (`charitable/get-donor`), never a `~` or any |
| 43 |
* other encoded separator. There is no tilde anywhere in core's REST API. |
| 44 |
*/ |
| 45 |
add_filter( 'rest_request_after_callbacks', array( Charitable_Abilities::get_instance(), 'intercept_gated_ability' ), 9, 3 ); |
| 46 |
add_filter( 'rest_request_after_callbacks', array( Charitable_Abilities::get_instance(), 'set_error_http_status' ), 10, 3 ); |
| 47 |
|
| 48 |
/* |
| 49 |
* Usage counting. Three seams, because core gives us three different facts and |
| 50 |
* no single hook carries all of them: |
| 51 |
* |
| 52 |
* - `wp_ability_invoked` fires for every call, and the handler above records |
| 53 |
* both the invocation and a permission denial from it. |
| 54 |
* - `wp_after_execute_ability` fires ONLY on success — a WP_Error out of |
| 55 |
* do_execute(), or a failed output validation, returns from execute() before |
| 56 |
* it. There is no "ability failed" action in core, which is why `failed` is |
| 57 |
* derived rather than counted. |
| 58 |
* - The write gate records its own refusals from inside |
| 59 |
* Charitable_Abilities_Registrar::gate_write_callback(), where it already |
| 60 |
* knows it is refusing. |
| 61 |
* |
| 62 |
* Counts accumulate in memory and land in one option write per request on |
| 63 |
* `shutdown`. |
| 64 |
*/ |
| 65 |
add_action( 'wp_after_execute_ability', array( 'Charitable_Abilities_Usage', 'record_success' ), 10, 1 ); |
| 66 |
add_action( 'shutdown', array( 'Charitable_Abilities_Usage', 'flush' ) ); |
| 67 |
|
