Connector Field Registry Proposed for WordPress 7.1

Twenty years of shipping WordPress work has taught me one thing about extensibility: the moment a feature lands with a single supported field, someone on my team ends up building a fake settings page next to it to hold the second one. It happened with widgets. It happened with the customizer. It happened with the block editor. And in WordPress 7.0 it started happening with the shiny new Connectors screen, which only knows how to render one thing: an API key.

That is fine if every AI provider you ever integrate is OpenAI, Anthropic, or Google with a single key. It is not fine the day a client asks you to point WordPress at a self-hosted Ollama server (needs a URL), or an OpenAI organisation ID, or a default-model dropdown, or a Bedrock region. Today those all require a bespoke admin page or an experimental React override, and the buyer of your plugin ends up hunting for settings in three different corners of wp-admin.

This week Gutenberg picked up the proposal that closes that gap. It is not merged yet, but it is the concrete answer to a promise the 7.1 roadmap already made in writing, and it is worth paying attention to now because the API shape is still being debated in public.

What is actually new

Andrei Lupu opened Gutenberg PR #79373 on June 20, 2026, proposing a PHP field registry for connectors — the missing companion to the Connectors screen that shipped in WordPress 7.0’s Connectors API. The PR resolves issue #78647, which Lupu filed on May 25 after two community connectors (Ollama and Osaurus) independently built their own settings pages just to hold a server URL.

The API mirrors register_setting(). A new public function register_connector_field() takes a connector ID, a field name, and an args array with the fields WordPress developers already know: type, control, label, description, default, sanitize_callback, auth_callback, show_in_rest, choices, setting_name, env_var_name, constant_name. Supported controls at the moment: text, URL, email, number, password, textarea, select, checkbox. The Connectors admin screen then renders and persists them automatically, batching every field on a connector into a single Save button.

Under the hood the PR adds a WP_Connector_Field_Registry class in lib/compat/wordpress-7.1/, plus companion helpers unregister_connector_field(), wp_get_connector_field(), wp_get_connector_fields(), and wp_get_connector_field_value(). On the JavaScript side a DefaultConnectorSettings component renders the typed controls and posts one batched update to REST. Backwards compatibility is handled cleanly: any existing connector that only ever registered an API key gets an implicit api_key field synthesised for it, so nothing breaks.

Test coverage is not decorative — 39 PHP tests under Tests_Connector_Field_Registry and 14 JavaScript tests in packages/connectors, and everything passes phpcs, eslint and tsc. Review is requested from spacedmonkey. The PR is still open with four explicit questions to reviewers: whether register_connector_field() should be a global function (like register_setting()) or a registry method (like the existing Connectors API), whether registration should gate on the owning plugin being active, whether PHP and JS should ship in one review or split, and whether select should accept a choices_callback for runtime lookups.

The strategic context is not subtle. The roadmap to 7.1 committed, verbatim, to “explore more general, declaratively-defined connection forms (URLs, a default-models dropdown, and more) in PHP.” This PR is that exploration, in code, ready to review.

Why it matters for WordPress and WooCommerce people

If you build or maintain any plugin that talks to an external service — an AI provider, a shipping calculator, a translation engine, a CRM connector, an ERP bridge — you have written a settings page. Probably several. Each one has its own layout, its own field names, its own sanitisation, its own REST endpoint. The Connectors screen was supposed to be the place all of that consolidates for AI providers. Right now it only consolidates one field. Ship this PR and it consolidates the rest.

For agencies running enterprise WordPress and WooCommerce builds, the practical win is boring in the best way: one screen, one save button, one REST surface, one place your client hunts for the model selector. It also means the credential envelope grows in a governed way — env_var_name and constant_name are first-class in the args array, so a devops team can put secrets in the environment or wp-config the same way they already put database passwords, instead of forcing an API key into the database via a bespoke UI.

For WooCommerce specifically this pattern is the seed of something bigger. Once WordPress has a supported declarative way to say “this integration needs an URL, a token, a region, and a default model,” the WooCommerce Abilities work and the payment/shipping registries can reuse the same shape. Nothing in the PR forces that, but it is the direction of travel.

The other reason to care right now: this is exactly the kind of API where the first ten adopters set the vocabulary. If you have opinions about whether select needs runtime choices, or whether auth_callback is the right hook for per-role visibility, PR #79373 is the room where that gets decided. Beta 1 lands July 15.

What I would do (or not do) about it

If you ship a connector plugin today: do not migrate anything yet. The PR is unmerged, the API name may still flip between global function and registry method, and the JavaScript rendering piece may get split into a separate review. But do read the PR now, and drop your feedback on the four open questions before Beta 1. This is the cheapest time to influence the shape.

If you build custom connectors for clients: keep your current bespoke settings pages, but write them in a way you can swap out later — put the field definitions in an array in one PHP file, keep sanitisation in named callbacks, keep the storage keys consistent with what setting_name would produce. When the registry lands you will replace fifty lines of admin-menu wiring with ten lines of register_connector_field() calls and delete the rest.

If you are a hosting or agency ops team: the env_var_name and constant_name support is the part I would prepare for now. Standardise how you name environment variables for AI credentials across your fleet, because once the registry ships, that naming becomes the interoperability layer between your infrastructure and every connector plugin the client installs.

What I would not do: do not spin up yet another bespoke admin page for a new AI provider integration next week. Wait three weeks. If PR #79373 does not land in Beta 1 on July 15, you can ship your bespoke page then with a clean conscience. If it does, you will have saved yourself a rewrite.

WordPress wins these fights by making the boring cases boring. A field registry for connectors is exactly that kind of quiet, high-leverage plumbing — the sort of change nobody demos on stage but everybody depends on six months later.