Skip to content

WPPilot 1.12.0 — WordPress 7.1 support

Choose a tag to compare

@wppilot-labs wppilot-labs released this 12 Sep 10:50
· 143 commits to main since this release

WordPress 7.1 support. Tested against 7.1; the minimum is still 6.9 and every change here is inert on 6.9 and 7.0. No ability was added, removed or renamed.

Read the registry when enforcing, the filtered list when advertising

WordPress 7.1 changed what wp_get_abilities() answers. Every call now runs the wp_get_abilities_item_include and wp_get_abilities_result filters, the bare no-argument one included, so the function reports what a site publishes rather than what is registered. WPPilot was reading it in both senses.

Discovery keeps calling it: a site that filters its registry means the filtered list, and the MCP tool list, the prompt list and the capability count should all narrow with it. The ability policy and the Abilities screen read WP_Abilities_Registry instead. A rule enforced across the registry cannot be applied to a list something else narrowed first — an ability another plugin hid from discovery would have kept its registration and stayed executable through every path that does not go through discovery, while the screen reported it as switched off.

The safety profile now binds every caller

wp_ability_permission_result runs inside WP_Ability::execute() and in the standalone permission checks the REST API and WP-CLI perform, so core REST, WP-CLI, the AI Client, another MCP adapter and WPPilot Chat all get the refusal MCP already gave. Until now the profile was enforced by unregistering what it refuses, which has to stand down on the Abilities screen so that screen can list disabled abilities — a request to it that also executed an ability ran under no profile at all. The filter only ever denies: a call something upstream already refused keeps that refusal.

Also in this release

  • An ability registered with 7.1's channel-independent public flag is served over MCP. mcp.public stays authoritative, and the fallback follows core's own precedence: the channel's flag, then public, then false.
  • Advertised tool schemas go through wp_prepare_json_schema_for_client() where it exists. Every ability on the site is exposed, not only WPPilot's, and a schema authored for WordPress carries a property-level required: true and the PHP-only sanitize_callback, validate_callback and arg_options keys — a client validating arguments against the advertised schema dropped the field or refused the tool. Input validation is unchanged; the ability's own schema still decides what a call may send.
  • The change ledger records the risk of the ability that actually ran. Both execution hooks hand the WP_Ability to their callbacks now, so the ledger stops looking the name up after the write — a lookup that came back empty, and recorded a plain "write", when the ability being recorded had switched the safety profile or disabled something and the policy had unregistered rows mid-request.
  • The compatibility block published to clients carries tested_wordpress_version and a wordpress_capabilities map, probed by asking for the function or class that implements each capability rather than by comparing version strings.

Install

Download wppilot.zip below and install it from Plugins → Add New → Upload Plugin. The GitHub "Source code" archive is not installable: it unpacks to a differently named folder.

Requires WordPress 6.9 or newer and PHP 8.0 or newer.