{"id":1923,"date":"2026-05-18T09:30:46","date_gmt":"2026-05-18T07:30:46","guid":{"rendered":"https:\/\/www.unleash-wp.com\/blog\/?p=1923"},"modified":"2026-05-18T10:15:08","modified_gmt":"2026-05-18T08:15:08","slug":"wordpress-7-0-developer-prep","status":"publish","type":"post","link":"https:\/\/www.unleash-wp.com\/blog\/wordpress-7-0-developer-prep\/","title":{"rendered":"Prepare for WordPress 7.0: the developer’s audit list"},"content":{"rendered":"\n

WordPress 7.0 launches on Wednesday, May 20<\/strong>. The headline feature was supposed to be real-time collaboration. That got pulled three weeks before launch after architectural issues with how it interacted with post caches, and it’s been deferred to 7.1. What’s left is bigger for plugin developers anyway: a provider-agnostic AI Client baked into Core, a full JavaScript counterpart to the Abilities API, and a Connectors infrastructure for managing AI provider plugins. Plugin developers now build against a stable AI abstraction instead of hard-coding vendor SDKs. This is the biggest architectural addition to WordPress since Gutenberg shipped in 2018.<\/p>\n\n\n\n

I’ve spent the last weeks running 7.0 RC against blocks and plugins I maintain through Kreo Pulse<\/a> and UnleashWP. The AI stack is the priority before you build against 7.0. The rest is migration work, and one piece of it has a high chance of breaking blocks you’ve already shipped if you don’t audit block.json<\/code> before Wednesday.<\/p>\n\n\n\n

Here’s the pre-launch read.<\/p>\n\n\n\n

\"WordPress
WordPress AI conntectors<\/figcaption><\/figure>\n\n\n\n

The AI Client: the new substrate<\/span><\/h3>\n\n\n\n

The WP AI Client is the centerpiece of the 7.0 release. It sits on top of the [wordpress\/php-ai-client<\/code>]. SDK that Core now bundles as a dependency.<\/p>\n\n\n\n

If you aren’t adding AI features in this release, you can skip ahead. If you are, or if you’re maintaining a plugin that already calls AI providers directly, read this carefully. Direct vendor integrations are what 7.0 lets you stop maintaining.<\/p>\n\n\n\n

Your plugin describes what it wants. Core routes the request to whichever provider the site owner has configured under Settings > Connectors<\/code>. You never touch API keys. Three official provider plugins ship alongside Core, one each for Anthropic, Google, and OpenAI. Custom providers register through the Connectors API<\/a>.<\/p>\n\n\n\n

Keeping the providers as separate plugins is deliberate. Provider APIs change too fast for Core’s release cadence. The abstraction lives in Core, the providers ship updates whenever they need to.<\/p>\n\n\n\n

The basic pattern<\/span><\/h4>\n\n\n
\n$text = wp_ai_client_prompt( 'Summarize the benefits of object caching in WordPress.' )\n    ->using_temperature( 0.7 )\n    ->generate_text();\n\nif ( is_wp_error( $text ) ) {\n    return;\n}\n\necho wp_kses_post( $text );\n<\/pre><\/div>\n\n\n
wp_ai_client_prompt()<\/code> returns a WP_AI_Client_Prompt_Builder<\/code>. Chain configuration on, then call a generation method. Errors come back as WP_Error<\/code> rather than exceptions. The Core wrapper catches exceptions from the underlying SDK and converts them.<\/p>\n\n\n\n
Detect before you render<\/span><\/h4>\n\n\n\n
Not every site has a provider configured. If you build UI around an AI feature that can’t run, your plugin breaks on those sites:<\/p>\n\n\n
\n$builder = wp_ai_client_prompt( 'test' )\n    ->using_temperature( 0.7 );\n\nif ( $builder->is_supported_for_text_generation() ) {\n    \/\/ Safe to render the feature UI.\n}\n<\/pre><\/div>\n\n\n
These checks are deterministic and don’t make API calls. Available variants: is_supported_for_text_generation()<\/code>, is_supported_for_image_generation()<\/code>, is_supported_for_text_to_speech_conversion()<\/code>, is_supported_for_speech_generation()<\/code>, is_supported_for_video_generation()<\/code>. Use them to hide UI, show a notice pointing to the Connectors screen, or skip enqueueing scripts when AI isn’t available.<\/p>\n\n\n\n
Model preferences<\/span><\/h4>\n\n\n\n
You don’t know which models the site has access to. Express a preference and let Core fall back:<\/p>\n\n\n
\n$result = wp_ai_client_prompt( 'Summarize the history of the printing press.' )\n    ->using_temperature( 0.1 )\n    ->using_model_preference(\n        'claude-sonnet-4-6',\n        'gemini-3.1-pro-preview',\n        'gpt-5.4'\n    )\n    ->generate_text_result();\n<\/pre><\/div>\n\n\n
A preference, not a requirement. If none of your listed models are available, Core picks a compatible one. Your plugin needs to function either way.<\/p>\n\n\n\n
The generate_*_result()<\/code> variants return a GenerativeAiResult<\/code> with metadata: token usage, provider, model. Useful for logging and audit trails. The object is serializable and returns cleanly from a REST callback:<\/p>\n\n\n
\nfunction unleashwp_ai_summary_callback( WP_REST_Request $request ) {\n    $result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )\n        ->generate_text_result();\n\n    return rest_ensure_response( $result );\n}\n<\/pre><\/div>\n\n\n
WP_Error<\/code> objects work the same way in rest_ensure_response()<\/code>, with appropriate HTTP codes attached.<\/p>\n\n\n\n
Cache aggressively<\/span><\/h4>\n\n\n\n
The dev note doesn’t say it explicitly, so I will. Every AI call costs money and time. If you’re generating content that doesn’t need to be unique per-request, wrap the call:<\/p>\n\n\n
\nfunction unleashwp_get_ai_summary( int $post_id ): string {\n    $modified  = get_post_modified_time( 'U', false, $post_id );\n    $cache_key = 'unleashwp_ai_summary_' . $post_id . '_' . $modified;\n    $cached    = get_transient( $cache_key );\n\n    if ( false !== $cached ) {\n        return $cached;\n    }\n\n    $result = wp_ai_client_prompt( get_post_field( 'post_content', $post_id ) )\n        ->using_system_instruction( 'Summarize the article in three sentences.' )\n        ->generate_text();\n\n    if ( is_wp_error( $result ) ) {\n        return '';\n    }\n\n    set_transient( $cache_key, $result, WEEK_IN_SECONDS );\n    return $result;\n}\n<\/pre><\/div>\n\n\n
Keying the transient on get_post_modified_time()<\/code> lets the cache invalidate naturally when the post is edited. Skipping the cache layer is the fastest way to surprise a client with a four-digit API bill.<\/p>\n\n\n\n
Govern at the site level<\/span><\/h4>\n\n\n\n
For administrators who want hard limits on what AI calls can happen, the wp_ai_client_prevent_prompt<\/code> filter blocks prompts before they execute:<\/p>\n\n\n
\nadd_filter(\n    'wp_ai_client_prevent_prompt',\n    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {\n        if ( ! current_user_can( 'edit_posts' ) ) {\n            return true;\n        }\n        return $prevent;\n    },\n    10,\n    2\n);\n<\/pre><\/div>\n\n\n
When a prompt is prevented, no call is attempted, is_supported_*()<\/code> returns false<\/code> so plugins can hide their UI, and generate_*()<\/code> returns a WP_Error<\/code>. This is the hook for rate limiting, role-based blocking, time-of-day controls, or quota management. Wire it in on any agency site where you can’t predict which plugins will start making AI calls.<\/p>\n\n\n\n
Don’t expose the JavaScript AI client in distributed plugins<\/span><\/h4>\n\n\n\n
There’s a JavaScript counterpart to the AI Client, available through the [wp-ai-client<\/code>] package. It looks convenient. The dev note is explicit that it isn’t the right choice for plugins shipped through the directory.<\/p>\n\n\n\n
The reason: the client-side API allows arbitrary prompt execution. To prevent untrusted users from sending any prompt to a configured provider and burning through someone else’s credits, it requires a high-privilege capability check. By default that means administrators only.<\/p>\n\n\n\n
Use the pattern shown above instead: a specific REST endpoint per AI feature, with granular permission checks there, and prompt configuration kept on the server. The JS API is fine for admin-only tools you build for yourself or for a specific client. For a plugin in the directory, don’t.<\/p>\n\n\n\n
Migrating from the standalone packages<\/span><\/h4>\n\n\n\n
If you’ve been bundling wordpress\/php-ai-client<\/code> via Composer, the simplest migration is to bump Requires at least<\/code> to 7.0, drop the Composer dependency, and replace AI_Client::prompt()<\/code> calls with wp_ai_client_prompt()<\/code>.<\/p>\n\n\n\n
If you need to keep WP < 7.0 support, you need a conditional autoloader so Composer doesn’t load duplicate class definitions alongside Core’s bundled copy:<\/p>\n\n\n
\nif (\n    ! function_exists( 'wp_get_wp_version' )\n    || version_compare( wp_get_wp_version(), '7.0', '<' )\n) {\n    require_once __DIR__ . '\/vendor\/autoload.php';\n}\n<\/pre><\/div>\n\n\n
The function_exists()<\/code> guard handles older versions where wp_get_wp_version()<\/code> doesn’t yet exist. Composer’s autoloader is all-or-nothing, so the conditional wraps the full autoload. If that’s too coarse for your dependency graph, split the AI packages into a separate Composer setup.<\/p>\n\n\n\n
For wordpress\/wp-ai-client<\/code>, the migration is simpler. It detects the WP version automatically and disables its own SDK on 7.0+ while keeping the REST endpoints and JavaScript API active. Load it unconditionally. The package is likely to be discontinued once those pieces land in Gutenberg or Core (tracked in #64872<\/a> and #64873<\/a>).<\/p>\n\n\n\n
One housekeeping detail. If your plugin’s AI features genuinely require a specific provider plugin to be present, declare that with the Requires Plugins<\/code> header in your main plugin file. The dependency surfaces to administrators on install, which avoids “AI feature broken” support tickets from missing provider plugins.<\/p>\n\n\n\n
The Abilities API: the underrated piece<\/span><\/h3>\n\n\n\n
The Abilities API itself isn’t new. It shipped in 6.9. What’s new in 7.0 is the full JavaScript counterpart and the tighter integration with the AI Client.<\/p>\n\n\n\n
An ability is a named callback with a schema. You give it a name, a description, an input schema, an output schema, a permission callback, and a function that runs when something calls it. The “something” can be your own code, another plugin, an AI agent through the AI Client, or, coming soon, a browser extension implementing WebMCP<\/a>.<\/p>\n\n\n\n
That last part is what makes the Abilities API more than an AI feature. It’s the workflow primitive WordPress hasn’t had: a permission-checked, schema-validated way to expose plugin actions to anything that knows the abilities store.<\/p>\n\n\n\n
The two packages<\/span><\/h4>\n\n\n\n
The client side ships as two packages:<\/p>\n\n\n\n