Add support for the WordPress Abilities API

Summary

Add first-class support for the WordPress Abilities API so Perform's core functionality can be discovered and, where appropriate, executed through WordPress' standard abilities registry.

The Abilities API is available in WordPress 6.9+ and provides a standardized registry for plugin functionality with labels, descriptions, JSON schemas, permission callbacks, categories, and optional REST exposure.

References:

• https://developer.wordpress.org/apis/abilities-api/
• https://developer.wordpress.org/apis/abilities-api/getting-started/
• https://developer.wordpress.org/apis/abilities-api/rest-api-endpoints/
• https://make.wordpress.org/core/2026/03/24/client-side-abilities-api-in-wordpress-7-0/

Why this matters

Perform already has several discrete performance capabilities that could be useful to admin tooling, automation, and AI-assisted workflows. Registering them as abilities would make those capabilities easier to discover and integrate without adding custom public endpoints.

This should also position Perform for WordPress' newer automation surface while keeping compatibility with older WordPress versions.

Proposed scope

Start with a conservative Phase 1:

• Register a perform ability category when the Abilities API is available.
• Feature-detect the API with class_exists( 'WP_Ability' ) or function_exists( 'wp_register_ability' ) before registering anything.
• Do not raise Perform's minimum WordPress version only for this feature.
• Register read-only abilities first, for example:
  • perform/get-modules: list Perform modules and enabled state.
  • perform/get-performance-status: summarize enabled optimization areas.
  • perform/get-cache-status: report page cache/CDN/menu cache status where available.
• Consider a small, safe action ability only if it can be permissioned and documented clearly, for example cache purge. If included, mark it accurately with ability metadata and keep it behind manage_options or the existing Perform settings capability.
• Avoid exposing destructive or broad write/fix abilities until there is a dedicated policy and UX decision.

Security and compatibility requirements

• No fatal errors on WordPress versions below 6.9.
• Every executable ability must have a strict permission_callback; nonces must not be treated as authorization.
• REST exposure must be deliberate. The Abilities API keeps abilities hidden from REST by default, so only expose abilities via show_in_rest when the output/action is safe for authenticated external access.
• Use complete input and output schemas for every ability.
• Avoid leaking filesystem paths, cache internals, secrets, tokens, or environment-specific values in ability output.
• Keep output stable enough for integrations, but do not expose internal class names or unstable implementation details.
• Multisite behavior must be explicit: document whether abilities operate per site or network-wide.

Acceptance criteria

• Perform registers an ability category and initial abilities only when the WordPress Abilities API is available.
• Older supported WordPress versions continue to load Perform without notices, fatals, or behavior changes.
• Registered abilities are namespaced consistently, documented, schema-backed, and capability-protected.
• Any REST-exposed ability requires authentication and respects the same capability checks as the equivalent admin action.
• Tests or runtime validation cover both API-present and API-absent environments.
• Developer documentation or inline docs explain the supported abilities and security model.

Implementation notes

A small integration class is likely cleaner than adding registration logic to module bootstraps directly. Suggested shape:

• src/Integrations/AbilitiesApi.php or equivalent namespaced integration.
• Hook category registration into wp_abilities_api_categories_init.
• Hook ability registration into wp_abilities_api_init.
• Reuse existing Perform services/helpers instead of duplicating module or cache status logic.
• Keep initial output read-only and minimal; expand action abilities later once the policy surface is clearer.

Start with the proposed src/Integrations/AbilitiesApi.php (or equivalent) and read the existing Perform services/helpers for module and cache status. Register the category on wp_abilities_api_categories_init and abilities on wp_abilities_api_init, feature-detecting the API first. Done means read-only, namespaced abilities have complete schemas and capability checks, older WordPress versions remain unaffected, and API-present/API-absent behavior is tested and documented.