Connectors: don't clobber third-party custom render in registerDefaultConnectors

[superdav42]

What

registerDefaultConnectors() in routes/connectors-home/default-connectors.tsx was unconditionally setting args.render = ApiKeyConnector for any api_key-authenticated connector, overwriting custom renders that third-party plugin script modules had already supplied via __experimentalRegisterConnector().

This PR makes the assignment conditional on no existing render being registered, so plugin-supplied renders survive while the rest of the server-side metadata (logo, plugin install state, authentication config) still merges on top.

Why

registerDefaultConnectors() runs inside the dynamically-imported routes/connectors-home/content module. By the time it runs, every top-level plugin script module — including any that enqueued on the standard options-connectors-wp-admin_init action — has already executed and registered its connectors. The store reducer spreads new config over existing entries:

[ action.slug ]: {
    ...state.connectors[ action.slug ],   // existing
    slug: action.slug,
    ...action.config,                      // new (wins per key)
}

So whichever caller fires last wins per key, and registerDefaultConnectors() is always last for plugins that enqueue at the standard hook. The result is that any plugin shipping a custom Connectors-page card sees it silently replaced by the generic ApiKeyConnector API-key form.

This is particularly painful for local/self-hosted AI providers (Ollama, LM Studio, WebLLM, etc.) that don't have an API-key concept at all — the rendered form is meaningless and confusing for users.

PR #76722 added JS-extensibility e2e coverage but only for the server-then-client direction (where the test plugin's connector uses auth: 'none', so the clobber path is never hit). The client-then-server direction for auth: 'api_key' connectors was unverified and broken — see issue #77115 for the full root-cause walkthrough and a live reproducer plugin.

How

In default-connectors.tsx, before deciding whether to assign the default ApiKeyConnector render, read the current entry from the connectors store via the same unlock( connectorsPrivateApis ) pattern stage.tsx already uses:

const existing =
    unlock( select( connectorsStore ) ).getConnector( connectorName );
if ( authentication.method === 'api_key' && ! existing?.render ) {
    args.render = ApiKeyConnector;
}

When args.render is omitted, the reducer's spread of the existing entry preserves whatever render the plugin already registered. Server-side metadata (name, description, logo, authentication, plugin) still merges on top of the existing entry as before.

Test plan

Adds a third connector test_api_key_with_custom_render to the connectors-js-extensibility test plugin:

• PHP (packages/e2e-tests/plugins/connectors-js-extensibility.php): registers test_api_key_with_custom_render with type: 'ai_provider' and authentication.method: 'api_key' — exactly the path that hits the clobber.
• JS (packages/e2e-tests/plugins/connectors-js-extensibility/index.mjs): calls registerConnector( 'test_api_key_with_custom_render', { render: ... } ) for it. This is what registerDefaultConnectors() would have overwritten without the fix.
• Spec (test/e2e/specs/admin/connectors.spec.js): a new test inside the JS extensibility describe block:
  • Asserts the custom render's text content ('Custom render survived registerDefaultConnectors().') is visible inside the expected card.
  • Asserts the card has zero API Key labels — i.e. the default ApiKeyConnector form is absent.

This explicitly exercises the previously-uncovered direction. Without the source fix, the new spec fails (the card shows the API Key form instead of the custom content).

• Existing JS extensibility tests still pass.
• New should preserve a custom render for an api_key connector... test passes.
• Manual smoke: install any third-party AI provider plugin that registers a custom connector card (e.g. https://github.com/Ultimate-Multisite/ultimate-ai-connector-webllm) and verify the custom card renders without needing the multi-tick registerConnector workaround.

Closes #77115.

[github-actions]

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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: superdav42 <superdav42@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

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

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @superdav42! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[superdav42]

I don't have permission to apply labels — could a maintainer add [Type] Bug so the required-labels check passes? Thanks!

[gziolo]

Thank you for the detailed report @superdav42 and proposing the solution. That’s a real problem with how JavaScript runs as there is no formalized init action concept on the client which would allow enforcing execution order. We definitely should only set the render default/fallback if it wasn’t set for the connector. More broadly, it would be great also to detect that the registration is coming from the server and never override these properties that were already set on the client even when the custom script runs faster then server data gets processed.

[gziolo]

Reviewed, built and ran the new e2e test locally against a fresh test env — the fix behaves as described. Verified against the connectors store reducer that omitting render from the default registration's args correctly preserves a previously-registered render while server-side metadata still merges on top. Solid root-cause analysis and a well-targeted regression test.

I pushed a polish commit b57b271 with three tweaks to help it land:

1. Prettier — the const existing = unlock( ... ).getConnector( connectorName ); line tripped the All (Static Analysis) CI job. Reflowed to the multi-line form.
2. E2E assertion — card.getByLabel( 'API Key' ) was matching the card itself because Playwright's getByLabel resolves aria-labelledby, and the card's role="group" is labeled by the heading "Test API Key With Custom Render", which contains the substring "API Key". Swapped to card.getByRole( 'textbox', { name: 'API Key' } ) — directly asserts the default API-key input is absent, which is the real invariant.
3. Comments — trimmed the newly added comments in default-connectors.tsx, the test plugin, and the spec so they describe what the code is doing rather than referencing specific function names and internal mechanisms (reducer spread order, dynamic import chain, registerDefaultConnectors, ApiKeyConnector) that will rot as the area evolves.

[github-actions]

I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: e426877