Connectors: Allow custom env var and constant names for API key source detection

[jorgefilipecosta]

_wp_connectors_get_api_key_source() determines where a connector's API key is stored by checking, in order: environment variable, PHP constant, and database option.

The environment variable and constant names are derived automatically from the connector ID using the convention {UPPER_ID}_API_KEY (e.g., openai → OPENAI_API_KEY). This works well for connectors that follow this pattern, but some connectors use established constants or environment variables with different names. There is currently no way for a connector to specify which constant or environment variable holds its API key.

Steps to Reproduce

1. Register a connector whose API key is stored in a PHP constant with a non-standard name:

   $registry->register( 'my-service', array(
       'name'           => 'My Service',
       'type'           => 'ai_provider',
       'authentication' => array(
           'method'       => 'api_key',
           'setting_name' => 'my_service_api_key',
       ),
   ) );
   

2. Define the constant in wp-config.php:

   define( 'MY_SERVICE_KEY', 'sk-test-123' );
   

3. Check the connector's keySource on the Connectors settings page.

Expected Results

keySource is 'constant' because the key is defined via a PHP constant.

Actual Results

keySource is 'none' because the function only checks for MY_SERVICE_API_KEY (derived from the connector ID), not MY_SERVICE_KEY.

Proposed Fix

Add two optional fields to the connector authentication config — constant_name and env_var_name — so connectors can specify which constant and/or environment variable holds their API key. When provided, these override the default derived name. When omitted, the existing behavior is preserved.

Registry changes (class-wp-connector-registry.php):

 if ( 'api_key' === $args['authentication']['method'] ) {
     // ... existing credentials_url and setting_name handling ...
+    if ( ! empty( $args['authentication']['constant_name'] ) && is_string( $args['authentication']['constant_name'] ) ) {
+        $connector['authentication']['constant_name'] = $args['authentication']['constant_name'];
+    }
+    if ( ! empty( $args['authentication']['env_var_name'] ) && is_string( $args['authentication']['env_var_name'] ) ) {
+        $connector['authentication']['env_var_name'] = $args['authentication']['env_var_name'];
+    }
 }

Key source detection (connectors.php):

-function _wp_connectors_get_api_key_source( string $provider_id, string $setting_name ): string {
-    $constant_case_id = strtoupper( ... );
-    $env_var_name     = "{$constant_case_id}_API_KEY";
+function _wp_connectors_get_api_key_source( string $connector_id, string $setting_name, string $env_var_override = '', string $constant_override = '' ): string {
+    $constant_case_id = strtoupper( ... );
+    $default_name     = "{$constant_case_id}_API_KEY";
+
+    $env_var_name  = '' !== $env_var_override ? $env_var_override : $default_name;
+    $constant_name = '' !== $constant_override ? $constant_override : $default_name;

This is fully backwards-compatible: connectors that do not provide custom names continue to use the auto-generated {UPPER_ID}_API_KEY convention. All existing call sites pass the new fields from the connector config using null coalescing defaults.

PR: ​https://github.com/WordPress/wordpress-develop/pull/11363

## Summary

The connector key source detection derives the environment variable and PHP constant name from the connector ID using a {UPPER_ID}_API_KEY convention. This works for connectors that follow that pattern, but some connectors use established constants or environment variables with different names.

This adds two optional fields to the connector authentication config:

• constant_name — custom PHP constant name to check
• env_var_name — custom environment variable name to check

When provided, these override the default derived name. When omitted, the existing behavior is preserved.

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

## Test plan

• [ ] Existing AI provider connectors continue to detect keys via OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.
• [ ] A connector registered with 'constant_name' => 'MY_CUSTOM_KEY' correctly reports keySource: 'constant' when that constant is defined
• [ ] A connector registered with 'env_var_name' => 'MY_CUSTOM_ENV' correctly reports keySource: 'env' when that env var is set
• [ ] Omitting both fields preserves the default {UPPER_ID}_API_KEY behavior

[desrosj]

Reclassifying as a blessed task. I'm guessing that the default bug type was left because this seems like an enhancement. But since it's refining the implementation of a new feature in 7.0, a task is appropriate.

[huzaifaalmesbah]

## Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11363

Environment

• WordPress: 7.0-RC2-62153-src
• PHP: 8.3.30
• Server: nginx/1.29.6
• Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
• Browser: Chrome 146.0.0.0
• OS: macOS
• Theme: Twenty Thirteen 4.5
• MU Plugins:
  • Ticket 64960 Test - Custom Key Source Detection 1.0
• Plugins:
  • Query Monitor 3.20.4
  • Test Reports 1.2.1

Steps taken

1. Registered a connector with custom constant_name => 'MY_SERVICE_KEY'
2. Defined constant define( 'MY_SERVICE_KEY', 'sk-test-123' )
3. Checked keySource detection via _wp_connectors_get_api_key_source()
4. Verified backward compatibility with default naming
5. ✅ Patch is solving the problem

Expected result

• Connector with custom constant_name should detect the constant and return keySource: 'constant'
• Connector with custom env_var_name should detect the env var and return keySource: 'env'
• Default naming convention should continue working.

Additional Notes

• Maybe fix already exists in trunk via commit ​54624070b4
• PR ​#11363 has merge conflicts because trunk already contains the fix
• Applying this patch on 7.0 branch resolves the issue

Closing this issue as we went following an alternative by @gziolo.

[jorgefilipecosta]

Closing this issue as we followed a better implementation proposed by @gziolo.