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.

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.

jorgefilipecosta · 2026-02-26T01:52:35Z

package.json

 	},
 	"gutenberg": {
-		"ref": "23b566c72e9c4a36219ef5d6e62890f05551f6cb"
+		"ref": "336a47b80b566256ce5035cae56b2ab16f583dad"


This change is here just for testing it will not happen on this PR, it will happen during the Gutenberg package sync.

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.

felixarntz · 2026-02-26T04:08:20Z

src/wp-includes/connectors.php

+			return null;
+		}
+
+		$registry->setProviderRequestAuthentication(
+			$provider_id,
+			new ApiKeyRequestAuthentication( $key )
+		);
+
+		return $registry->isProviderConfigured( $provider_id );
+	} catch ( \Error $e ) {
+		return null;


I think for both of the return null cases, we'll want to add some kind of messaging, at least for debugging.

could use _doing_it_wrong for the first one (because that would be doing it wrong on the developer side) and wp_trigger_error for the second one.

Done with 31ab71c. I still need to look into it, because we most likely will need to pass here some generic translatable message instead of the code-generated error message.

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.

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.

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 😅

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

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

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!

Choose a reason for hiding this comment

Uh oh!

felixarntz left a comment

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!

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!

gziolo commented Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jorgefilipecosta commented Feb 26, 2026 •

edited

Loading

github-actions bot commented Feb 26, 2026 •

edited

Loading