Connectors: Backport Gutenberg PR #75833 PHP integration by jorgefilipecosta · Pull Request #11056 · WordPress/wordpress-develop

jorgefilipecosta · 2026-02-26T00:34:13Z

Trac ticket: https://core.trac.wordpress.org/ticket/64730

Summary

Backport the PHP integration pieces from Gutenberg PR Add: Connectors screen and API gutenberg#75833.
Register the Settings > Connectors submenu (options-general.php?page=connectors-wp-admin).
Register default connector settings for:
- connectors_openai_api_key
- connectors_anthropic_api_key
- connectors_gemini_api_key
Add API key masking and server-side validation wiring for settings reads/writes.
Expose invalid_key in /wp/v2/settings responses for requested connector fields when validation fails.
Pass stored connector keys into the WP AI client provider registry on init.

Notes

JS/TS/runtime artifacts for Connectors will be included on the Gutenberg sync; this PR covers the missing PHP glue.
Includes guard checks so behavior is a no-op when the AI client (or Connectors render callback) is unavailable.

Testing Instructions

Visit wp-admin/options-general.php?page=connectors-wp-admin and verify the Connectors page appears under Settings.
Verify Connectors appears between General and Writing in the Settings submenu.
Install all AI provider plugins.
Set API keys for every supported provider.
Remove the key and set it again for every supported provider.
When a incorrect API key is provided then it isn't possible to save it.
API keys are properly masked on the frontend (including REST API response).
Deactivate the AI provider plugin from the Plugins screen and activate the plugin again from the Connectors screen.
Uninstall the AI provider plugin from the Plugins screen and install the plugin again from the Connectors screen.
Revoke a key that was valid on the provider website and veify the screen does not says connected anymore.

github-actions · 2026-02-26T00:34:23Z

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jorgefilipecosta, gziolo, flixos90, noruzzaman, mukesh27.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2026-02-26T00:42:48Z

Test using WordPress Playground

The 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

All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

package.json

felixarntz

@jorgefilipecosta Thanks for preparing this!

There are of course still several things in here that need iteration, but given it's all private and we need this in Beta 2 tomorrow, I think we can proceed.

I left a few minor comments, that (other than the registry related ones) would be great to address before commit. But overall I think it's good to go in.

We'll need to iron out the whole registry bit and improve DX of registering a connector for Beta 3.

src/wp-includes/connectors.php

felixarntz · 2026-02-26T04:10:54Z

src/wp-includes/connectors.php

+ * @param string $key         The API key.
+ * @param string $provider_id The WP AI client provider ID.
+ */
+function _wp_connectors_set_provider_api_key( string $key, string $provider_id ): void {


I think this function should return bool, to have an idea whether it worked or not.

Updated the method in 31ab71c. We might want to revisit this method if we are looking at supporting multiple auth methods. In that case, we might want something more like:

function _wp_connectors_set_provider_auth( string $provider_id, string $auth_type, array $auth_params ): void {

This way we would have a general purpose util that devs can use elsewhere, too.

src/wp-includes/connectors.php

felixarntz · 2026-02-26T04:28:04Z

src/wp-includes/connectors.php

+	return array(
+		'connectors_gemini_api_key'    => array(
+			'provider' => 'google',
+			'mask'     => '_wp_connectors_mask_gemini_api_key',
+			'sanitize' => '_wp_connectors_sanitize_gemini_api_key',
+		),
+		'connectors_openai_api_key'    => array(
+			'provider' => 'openai',
+			'mask'     => '_wp_connectors_mask_openai_api_key',
+			'sanitize' => '_wp_connectors_sanitize_openai_api_key',
+		),
+		'connectors_anthropic_api_key' => array(
+			'provider' => 'anthropic',
+			'mask'     => '_wp_connectors_mask_anthropic_api_key',
+			'sanitize' => '_wp_connectors_sanitize_anthropic_api_key',
+		),
+	);


This is fine for now (i.e. Beta 2), but as discussed earlier today we should enhance this to allow properly registering a provider with all its base information in PHP, and notably reduce the barrier of entry.

First of all, of course this will require a proper registry.

In terms of this function, we would then want to use the registry, and for the 3 ones here, they would continue to be hard-coded, but overridable by the registry. This will allow us to make updates to the provider plugins (which is more appropriate for timing, since we can't quickly ship a new Core release when some of the metadata might be worth a change), and the hard-coded Core references would only be "starting points" / "fallbacks" for when the provider plugins are not active yet.

For the AI connectors specifically, we should as much as possible rely on what the WordPress\AiClient\AiClient::defaultRegistry() already offers:

name

description (coming in Adds optional description to providers php-ai-client#210)

credentialsUrl

authenticationMethod (e.g. "api_key")

Ideally we can simply iterate through those providers and then register the connector for it based on this information. We could support a "merge" behavior, where it would still be allowed to pass in additional information for the provider that may not (yet) have a 1:1 mapping in the WordPress\AiClient provider registry.

We should be able to avoid the need to provide all these callbacks, ideally this is handled centrally in Core, based on the authenticationMethod given.

And as for React UI for the fields, there should be a built-in component that is automatically used based on the given authenticationMethod. For flexibility with more advanced processes (e.g. Jetpack might add some kind of one-button click flow for better UX), we should of course still allow using a custom render component. But for the regular AI provider connector, we need to simplify this so that a single PHP array is all that's needed.

None of this is a blocker for this PR. But wanted to capture it here.

cc @gziolo

Cool, as noted in #11056 (comment), I plan to work on all the described changes. It seems like a viable path forward, which would make the dev experience for AI provider authors very compelling 💯

felixarntz · 2026-02-26T04:32:21Z

src/wp-includes/connectors.php

+			'connectors',
+			$option_name,
+			array(
+				'type'              => 'string',


This works for now, but is problematic and needs to be improved before stable release: Not every credential is a single string. A connector may require two fields (e.g. ID and secret, username and password, ...). We need to abstract this in a way that it's not enforcing a single option per provider usage - or at the very least, if we use a single option, it also needs to allow for more complex data, e.g. an object / associative array with multiple fields in it.

Once we have the connector registry, I think a good idea might be to have an settings field in there that allows an array and then handles these things. Or it could even be a register_settings PHP callback.

(Again, for some predefined authentication methods like "api_key" we could auto-populate this.)

cc @gziolo

I refactored _wp_connectors_get_provider_settings(), so it generates all necessary settings for registered (hardcoded for now) providers. The current shape will allow us to iterate further while moving most of the logic to that function. I will continue working on it based on the proposed design after Beta 2.

src/wp-includes/connectors.php

- Change catch blocks from `\Error` to `Exception` (global namespace). - Add `_doing_it_wrong` when an unregistered provider ID is passed. - Add `wp_trigger_error` to surface exception messages in catch blocks. - Change `_wp_connectors_set_provider_api_key` to return `bool`. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

tests/qunit/fixtures/wp-api-generated.js

…cks. Replace six identical per-provider mask/sanitize wrapper functions with `_wp_connectors_mask_api_key` used directly and sanitize closures built from a provider map in `_wp_connectors_get_connectors()`. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

… boilerplate. Rename `_wp_connectors_get_connectors` to `_wp_connectors_get_provider_settings` and dynamically assemble setting names, labels, and descriptions from a minimal provider slug/name map. Add `label` and `description` to `register_setting` calls so they appear in the REST API schema. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gziolo · 2026-02-26T10:08:18Z

tests/qunit/fixtures/wp-api-generated.js

 mockedApiResponse.settings = {
+    "connectors_gemini_api_key": "",
+    "connectors_openai_api_key": "",
+    "connectors_anthropic_api_key": "",


I don't know if that matters that much, but we use Claude in the UI instead of Anthropic, similar to Gemini instead of Google. We could be more consistent, but it isn't a blocker to me.

Great catch, I missed this. Actually, I think we should use Google, Anthropic, and OpenAI in the code.

I'm fine using Claude and Gemini in the UI because that's probably more intuitive to many users, but the providers are Anthropic and Google - no question there.

So I think on the code level we should consistently go with those names, i.e. the company names.

This is exactly what @jorgefilipecosta did in 0b6f6c1, plus he prefixed it with _ai_ to avoid confusion about which service it ties to.

Looks like that commit also changed the user-facing names though?

I'm personally fine with that, but on the Gutenberg PR it was discussed to use Claude and Gemini for the names in the UI, because more people know these names in relation to AI.

We should still use Anthropic and Google everywhere in the code, but potentially the user-facing name can be adjusted as such.

Since that was discussed on the Gutenberg PR, I wouldn't want to "silently" override that decision again here.

gziolo · 2026-02-26T10:11:16Z

src/wp-includes/connectors.php

+ * @access private
+ */
+function _wp_register_default_connector_settings(): void {
+	if ( ! class_exists( '\WordPress\AiClient\AiClient' ) ) {


@jorgefilipecosta, do we need this check in WP core? I bet we don't.

Well we don't excatly "need" but I would prefer to be defensive here, in the same way code normally checks for the inclusion of build generated functions function_exists( 'wp_connectors_wp_admin_render_page' ), AI client also seems like an external lib we had conversations in the past about some constant that makes AI client not even load etc, so I think being defensive here may be good.

WP AI Client development moves to the WP core. PHP AI Client is only treated as an external library.

gziolo · 2026-02-26T10:14:20Z

I need to re-test the branch after all the refactoring applied based on the feedback provided, but it looks like we are good to go if it still works as expected 😅

mukeshpanchal27 · 2026-02-26T10:53:14Z

I need to re-test the branch after all the refactoring applied based on the feedback provided, but it looks like we are good to go if it still works as expected 😅

Go for it.

gziolo

All good on my end.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/wp-includes/connectors.php

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

tests/phpunit/tests/connectors/wpConnectorsMaskApiKey.php

Introduces a reusable mock provider trait for registering a controllable test provider in the AI Client registry. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Uses snake_case parameter names in interface implementations and fixes array alignment in data provider. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gziolo · 2026-02-26T11:52:50Z

@felixarntz and @JasonTheAdams, I added some basic testing coverage so we can iterate on the codebase with more confidence. The part with test trait for the AI provider (4c380a9) was modeled after tests for WP AI Client. I would appreciate a sanity check in case you discover some obvious mistakes or immediate room for improvement. I will take care of it in follow up commit, as I don't consider non-production code a blocker.

Adds `wp-includes/connectors.php` (loaded from `wp-settings.php`) and registers a Settings > Connectors submenu when the AI client and Connectors admin page renderer are available. Registers connector API key settings in `/wp/v2/settings`, masks key values on option reads, validates keys against provider configuration, and returns `invalid_key` for explicitly requested connector fields when validation fails. Stored connector keys are also passed to the AI client registry on init. Gutenberg PR at WordPress/gutenberg#75833. Developed in #11056. Props jorgefilipecosta, gziolo, flixos90, justlevine, westonruter, jeffpaul, JasonTheAdams, audrasjb, shaunandrews, noruzzaman, mukesh27. Fixes #64730. git-svn-id: https://develop.svn.wordpress.org/trunk@61749 602fd350-edb4-49c9-b593-d223f7449a82

github-actions · 2026-02-26T13:35:16Z

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 61749
GitHub commit: 3cd3d3b

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

Adds `wp-includes/connectors.php` (loaded from `wp-settings.php`) and registers a Settings > Connectors submenu when the AI client and Connectors admin page renderer are available. Registers connector API key settings in `/wp/v2/settings`, masks key values on option reads, validates keys against provider configuration, and returns `invalid_key` for explicitly requested connector fields when validation fails. Stored connector keys are also passed to the AI client registry on init. Gutenberg PR at WordPress/gutenberg#75833. Developed in WordPress/wordpress-develop#11056. Props jorgefilipecosta, gziolo, flixos90, justlevine, westonruter, jeffpaul, JasonTheAdams, audrasjb, shaunandrews, noruzzaman, mukesh27. Fixes #64730. Built from https://develop.svn.wordpress.org/trunk@61749 git-svn-id: http://core.svn.wordpress.org/trunk@61055 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Backport connectors screen

a931561

jorgefilipecosta added 3 commits February 26, 2026 00:53

unit test updates

409f90f

lint fix

e26814d

Tests: Update REST API JS fixture for connectors settings

81a4100

jorgefilipecosta commented Feb 26, 2026

View reviewed changes

package.json Outdated Show resolved Hide resolved

felixarntz approved these changes Feb 26, 2026

View reviewed changes

noruzzamans reviewed Feb 26, 2026

View reviewed changes

src/wp-includes/connectors.php Show resolved Hide resolved

src/wp-includes/connectors.php Show resolved Hide resolved

src/wp-includes/connectors.php Show resolved Hide resolved

gziolo reviewed Feb 26, 2026

View reviewed changes

tests/qunit/fixtures/wp-api-generated.js Outdated Show resolved Hide resolved

gziolo and others added 2 commits February 26, 2026 10:26

gziolo reviewed Feb 26, 2026

View reviewed changes

gziolo approved these changes Feb 26, 2026

View reviewed changes

Tests: Add unit tests for _wp_connectors_get_provider_settings().

9920293

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

mukeshpanchal27 reviewed Feb 26, 2026

View reviewed changes

src/wp-includes/connectors.php Show resolved Hide resolved

Tests: Add unit tests for _wp_connectors_mask_api_key().

0625624

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

mukeshpanchal27 reviewed Feb 26, 2026

View reviewed changes

tests/phpunit/tests/connectors/wpConnectorsMaskApiKey.php Outdated Show resolved Hide resolved

gziolo and others added 2 commits February 26, 2026 12:39

Tests: Add unit tests for _wp_connectors_is_api_key_valid().

4c380a9

Introduces a reusable mock provider trait for registering a controllable test provider in the AI Client registry. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Tests: Fix PHPCS warnings in connector test files.

21201c5

Uses snake_case parameter names in interface implementations and fixes array alignment in data provider. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

jorgefilipecosta added 3 commits February 26, 2026 11:54

update setting names

0b6f6c1

inline and simplify _wp_connectors_set_provider_api_key

b9eccfe

revert the gutenberg update temporary test change

52fbdca

github-actions bot closed this Feb 26, 2026

jorgefilipecosta mentioned this pull request Feb 26, 2026

Sync connector PHP behavior with Core backport changes WordPress/gutenberg#75968

Open

Conversation

jorgefilipecosta commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Notes

Testing Instructions

Uh oh!

github-actions bot commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 26, 2026

Test using WordPress Playground

Some things to be aware of

Uh oh!

Uh oh!

felixarntz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

felixarntz Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo commented Feb 26, 2026

Uh oh!

mukeshpanchal27 commented Feb 26, 2026

Uh oh!

gziolo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

gziolo commented Feb 26, 2026

Uh oh!

github-actions bot commented Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jorgefilipecosta commented Feb 26, 2026 •

edited

Loading

github-actions bot commented Feb 26, 2026 •

edited

Loading

felixarntz Feb 26, 2026 •

edited

Loading