Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
Is there actually an AI provider plugin that's installable? I looked at the Google AI Provider repo, but all it has is a readme. |
|
Given how merging works in WordPress (a single SVN commit) I'm switching this to a draft PR. It's useful for testing! |
Hi @joedolson! I just released 1.0.0 of three providers which can be used as plugins: |
| /** | ||
| * Manages AI API credentials for the various providers. | ||
| * | ||
| * Collects provider metadata from the SDK, registers settings for storing | ||
| * API keys, and passes stored credentials to the SDK for authentication. |
There was a problem hiding this comment.
If I'm following correctly, it seems things are set up in this PR to only support API key authentication (and only rendering a single API key field per provider), is that accurate?
If so, if someone wanted to build out a provider that needs additional settings or doesn't need an API key, is there anyway for them to make this code work?
For instance, if I build a provider for Ollama, it doesn't need an API key at all but would be nice to have a setting for the API URL. Or if I wanted to support Azure OpenAI, I'd need an API key field, an endpoint URL field and a deployment name field.
I could manage all that in my own settings screen and maybe that's the answer, just limits the number of providers we can actually support here
There was a problem hiding this comment.
And I guess just to be super clear, not overly concerned with the (likely) edge case where a provider doesn't need an API key. More so concerned about providers that have settings beyond just an API key and how they would go about registering/saving/retreiving those settings.
I know there's been discussion around discoverability in regards to the individual AI providers. Could make a case that instead of hiding the page when no providers are registered we instead update the page to provide instructions on how to find and install a provider? |
| id="<?php echo esc_attr( $id ); ?>" | ||
| name="<?php echo esc_attr( $name ); ?>" |
There was a problem hiding this comment.
There's a chance both $id and $name are empty. Might be better to not render these attributes in that case instead of rendering them as empty attributes
| type="<?php echo esc_attr( $type ); ?>" | ||
| id="<?php echo esc_attr( $id ); ?>" | ||
| name="<?php echo esc_attr( $name ); ?>" | ||
| value="<?php echo esc_attr( $value ); ?>" |
There was a problem hiding this comment.
Something we just fixed in ClassifAI that came in from a security review was to ensure credentials (like API keys) were obfuscated prior to rendering in our settings screens. While I know this will render as a password input, you can still easily inspect the source and get the value of the input.
I also realize only those with the manage_options cap can access this page which limits scope but there still could be a scenario where someone that we don't want to have those API keys has the right access to get to this page and then could copy keys after inspecting the source.
I do think this is an edge case so not saying it needs to be changed, just fresh on my mind as I just adjusted this behavior myself a few days ago :)
jorgefilipecosta
left a comment
jorgefilipecosta
left a comment
There was a problem hiding this comment.
When there are no providers we render save without any field:
I think we should say there are no providers yet and tell the user to install a provider first.
4 participants
Trac ticket: https://core.trac.wordpress.org/ticket/64591
Merge Proposal: https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-client-into-wordpress-7-0
This is a part of #10881. I meant for this to stack on that so the changes in this are clear, but unfortunately I can't stack because both branches are in my forked repo.
Summary
Adds an AI Services settings screen under Settings > AI Services where site administrators can enter API credentials for AI providers. Without this,
wp_ai_client_prompt()has no way to authenticate with any provider.WP_AI_Client_Credentials_Managercollects provider metadata from the SDK, registers the credentials option with sanitization, and passes stored API keys to the SDK on each requestinitso plugins that register providers are picked upPorted from the
API_Credentials_ManagerandAPI_Credentials_Settings_Screenin the wp-ai-client plugin, adapted to core conventions (no namespaces,_doing_it_wrong()instead of exceptions, no text domain, etc.).Open question
The Settings > AI Services menu item is currently hidden when no cloud providers are registered (since the page would be empty). Is this the right behavior, or should the page always be visible with a message like "No AI providers are currently available"? Hiding it is cleaner but could be confusing if someone is looking for the page before installing a provider plugin.
Test plan
wp_ai_client_prompt()can authenticate using the stored keynpm run test:php -- --group ai-clientUse of AI Tools
This is a compilation of work from the PHP AI Client and WP AI Client repositories, with some changes made in porting to core. Claude Code was used in both the original development of those packages as well as the porting over and creation of the tooling. All code was generated by Claude Code and reviewed by myself and @felixarntz.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.