Overview
WordPress 7.0 did not ship a built-in chatbot. It shipped the plumbing every plugin author needs: a Connectors UI, a Connectors API to register external services, and a provider-agnostic PHP entry point, wp_ai_client_prompt(), so plugins can ask whatever LLM the site admin configured.
What shipped (architecture in brief)
– A provider-agnostic PHP SDK (wordpress/php-ai-client) is bundled as an external library.
– A WordPress wrapper (WP_AI_Client_Prompt_Builder) adapts the SDK to WP conventions: snake_case methods, WP_Error returns, HTTP transport integration, hooks, and the Connectors infra.
– Settings > Connectors is the admin surface where providers and API keys are managed. Core ships no providers; official provider plugins (OpenAI, Anthropic, Google) are separate.
Key facts for plugin authors
– Core bundles zero providers. Provider implementations are separate plugins.
– Provider plugins auto-register with the Connectors registry; no extra registration UI code is needed in most cases.
– Plugins never manage or see credentials directly. You describe what you need and WordPress routes the request to a configured provider/model.
– On a fresh 7.0 install, AI calls return WP_Error until a provider plugin and key are added. Handle that from day one.
Where credentials live (priority)
For API-key based connectors WordPress resolves keys in this order:
1) Environment variable: {PROVIDER_ID}_API_KEY (e.g. ANTHROPIC_API_KEY)
2) PHP constant in wp-config.php (e.g. define(‘ANTHROPIC_API_KEY’, ‘sk-…’))
3) Database setting created via Settings > Connectors (e.g. connectors_ai_anthropic_api_key)
Note: keys stored in the DB are masked but not encrypted (as of this writing). Prefer environment variables in production. The Connectors UI shows the source of the key.
Connectors API basics
Three small helper functions are available after init:
if ( wp_is_connector_registered(‘openai’) ) {
$connector = wp_get_connector(‘openai’);
echo $connector[‘name’]; // ‘OpenAI’
}
$all = wp_get_connectors(); // All registered connectors keyed by ID
To override connector metadata you use the wp_connectors_init action: unregister, modify, register against WP_Connector_Registry (the registry prevents duplicate IDs).
Using the AI Client: wp_ai_client_prompt()
wp_ai_client_prompt() returns a fluent builder. Chain configuration methods and then call a generation method. Example:
$text = wp_ai_client_prompt(‘Write a haiku about WordPress.’)
->generate_text();
if ( is_wp_error($text) ) {
// No provider configured, invalid key, rate limited, etc.
return;
}
echo wp_kses_post($text);
Important surface points:
– Generation methods return WP_Error on failure. Treat failure as a normal outcome.
– Builder methods include using_temperature(), using_max_tokens(), using_system_instruction(), with_history(), top_p/top_k, stop sequences, etc.
– generate_texts(4) returns multiple variations; generate_image() returns a file DTO; as_json_response($schema) restricts output to a JSON schema for structured responses.
Model selection and preferences
Because plugin code cannot assume which provider is configured, model selection is preference-based: you pass a list of preferred models and the AI Client picks the first available compatible model.
$result = wp_ai_client_prompt(‘Summarize the printing press history.’)
->using_temperature(0.1)
->using_model_preference(‘claude-sonnet-4-6’, ‘gemini-3.1-pro-preview’, ‘gpt-5.4’)
->generate_text_result();
Treat preferences as hints. If your feature depends on specific capabilities, inspect the returned GenerativeAiResult for provider and model metadata.
generate_*_result() returns a GenerativeAiResult that includes token usage and provider/model metadata and serializes cleanly via rest_ensure_response().
Feature detection
Support checks are local and free (no network calls). Gate UIs using these:
$probe = wp_ai_client_prompt(‘test’);
if ( $probe->is_supported_for_text_generation() ) {
// Show AI UI
}
Small runnable example (core AI work in five lines)
This is the distilled part of a small admin tool that summarizes a post. The code below highlights the AI usage and guards you must include:
– Guard for older WordPress versions
– Feature detection before showing UI
– WP_Error handling
Example snippet:
if ( ! function_exists(‘wp_ai_client_prompt’) ) {
return; // Requires WP 7.0+
}
$probe = wp_ai_client_prompt(‘probe’);
if ( ! $probe->is_supported_for_text_generation() ) {
echo ‘No AI provider configured. See Settings > Connectors.’;
return;
}
$summary = wp_ai_client_prompt(‘Summarize the following in three sentences:\n\n’ . $post_content)
->using_temperature(0.4)
->using_max_tokens(300)
->generate_text();
if ( is_wp_error($summary) ) {
// render error message
} else {
// render $summary
}
Gotchas and best practices
– Never assume AI is available. Gate UI with is_supported_for_*() checks.
– Core provides no spend limit. A plugin can exhaust the site’s API credits once a key is configured. Use the wp_ai_client_prevent_prompt filter to block prompts (for non-admins, large-scale jobs, or unsafe patterns); prevented prompts flip support checks to false.
– Keep prompts server-side. There is a separate client-side wp-ai-client package, but it’s not in core, requires admin capability, and is not recommended for distributed plugins. Use a protected REST endpoint that calls wp_ai_client_prompt() on the server.
– Model preferences are hints. Always check returned provider/model metadata if behavior depends on a specific model capability.
– Migrating existing plugins: require WP 7.0, remove composer dependency on the php-ai-client, and replace old AI_Client::prompt() calls with wp_ai_client_prompt(). If you need to support older WP versions, provide a conditional autoloader for the client classes.
Who’s already using it
Otter Blocks integrated the 7.0 native connectors: their AI features now route through the WordPress-level provider so one configured provider powers all Otter AI features. Otter keeps a legacy OpenAI key fallback for backward compatibility — a clear example of the intended pattern.
Final note
The 7.0 AI connectors are intentionally unflashy but well-shaped: centralized credentials, a provider-agnostic API, WordPress-style errors and detection. Most plugins will require only a few lines of AI code while leaving credential and provider management to the site admin and Connectors UI. If you’re building on this, consider: what guardrails and spend limits will your plugin expose to protect site owners?