[wp-trac] [WordPress Trac] #64791: Connectors: Extensibility API allowing plugins to register custom connector cards

[WordPress Trac]

#64791: Connectors: Extensibility API allowing plugins to register custom connector
cards
-------------------------+------------------------------
 Reporter:  gziolo       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------
Description changed by gziolo:

Old description:

> The Connectors screen needs a formal extensibility API so that third-
> party plugins can register their own connector cards — including custom
> UI for OAuth flows, multi-step configuration, or non-API-key
> authentication methods — without being limited to the default API key
> input card.
>
> The Connectors screen was introduced in
> [Gutenberg#75833](https://github.com/WordPress/gutenberg/pull/75833).
> [Gutenberg#76014](https://github.com/WordPress/gutenberg/pull/76014)
> added dynamic registration from the WP AI Client PHP registry, so
> provider plugins using `AiClient::defaultRegistry()->registerProvider()`
> with `api_key` authentication now appear automatically. This was a
> significant step, but the extensibility story remains incomplete.
>
> === Current behavior
>
> - Only providers with `api_key` authentication are surfaced on the
> Connectors screen. All other authentication methods are filtered out.
> - Every connector card renders the same default UI: a text input for the
> API key, with save/remove actions.
> - Third-party plugins can register a provider in PHP and have it appear
> on the screen, but they cannot customize how their card looks or behaves.
> - There is no mechanism for plugins to add connector types that go beyond
> AI providers (e.g., OAuth-based services, webhook configurations, or
> other integration patterns the Connectors screen could support in the
> future).
>
> === Expected behavior
>
> Plugins should be able to:
>
> 1. **Register a connector card with custom UI** — for example, an OAuth
> flow with an "Authorize" button and token status, or a multi-field
> configuration form.
> 2. **Register connectors using authentication methods other than API
> keys** — OAuth, app passwords, bearer tokens, etc.
> 3. **Provide card metadata from PHP** without needing to enqueue their
> own JavaScript for simple cases. The current `script_module_data` bridge
> from PHP to JS is a reasonable pattern, but the API should be explicit
> about what metadata plugins can provide (name, description, icon,
> credentials URL, authentication type, status).
> 4. **Inject custom rendering on the JS side** when the default card
> layout is insufficient — via a formal JS API that was marked as
> experimental initially.
>
> === Proposed scope
>
> - Define a PHP API for registering connector cards with metadata (name,
> description, icon, credentials URL, authentication type, custom fields).
> - Provide a JS-side API for plugins that need custom card rendering.
> - Ensure the default API key card remains the automatic fallback.
> - Document the extensibility API with examples for both PHP-only and
> PHP+JS integration patterns.

New description:

 The Connectors screen needs a formal extensibility API so that third-party
 plugins can register their own connector cards — including custom UI for
 OAuth flows, multi-step configuration, or non-API-key authentication
 methods — without being limited to the default API key input card.

 The Connectors screen was introduced in
 https://core.trac.wordpress.org/ticket/64730
 (https://github.com/WordPress/gutenberg/pull/75833).
 https://github.com/WordPress/gutenberg/pull/76014 added dynamic
 registration from the WP AI Client PHP registry, so provider plugins using
 `AiClient::defaultRegistry()->registerProvider()` with `api_key`
 authentication now appear automatically. This was a significant step, but
 the extensibility story remains incomplete.

 === Current behavior

 - Only providers with `api_key` authentication are surfaced on the
 Connectors screen. All other authentication methods are filtered out.
 - Every connector card renders the same default UI: a text input for the
 API key, with save/remove actions.
 - Third-party plugins can register a provider in PHP and have it appear on
 the screen, but they cannot customize how their card looks or behaves.
 - There is no mechanism for plugins to add connector types that go beyond
 AI providers (e.g., OAuth-based services, webhook configurations, or other
 integration patterns the Connectors screen could support in the future).

 === Expected behavior

 Plugins should be able to:

 1. **Register a connector card with custom UI** — for example, an OAuth
 flow with an "Authorize" button and token status, or a multi-field
 configuration form.
 2. **Register connectors using authentication methods other than API
 keys** — OAuth, app passwords, bearer tokens, etc.
 3. **Provide card metadata from PHP** without needing to enqueue their own
 JavaScript for simple cases. The current `script_module_data` bridge from
 PHP to JS is a reasonable pattern, but the API should be explicit about
 what metadata plugins can provide (name, description, icon, credentials
 URL, authentication type, status).
 4. **Inject custom rendering on the JS side** when the default card layout
 is insufficient — via a formal JS API that was marked as experimental
 initially.

 === Proposed scope

 - Define a PHP API for registering connector cards with metadata (name,
 description, icon, credentials URL, authentication type, custom fields).
 - Provide a JS-side API for plugins that need custom card rendering.
 - Ensure the default API key card remains the automatic fallback.
 - Document the extensibility API with examples for both PHP-only and
 PHP+JS integration patterns.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64791#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform