Fix AI credentials detection

[LukasFritzeDev]

What?

Closes #536

• add shared API key detection that checks environment variables, PHP constants, and stored settings
• use the shared detection for both the credentials helper and dashboard widget connection state

Why?

if the provider API key is set up using constant in wp-config.php or an ENV (instead of providing the key via the connectors settings page)

• Settings › AI shows an error saying “The AI plugin requires a valid AI Connector to function properly.”
• the Dashboard widget shows ❌ instead of ✅ for the connector

How?

• Add helper function has_api_key_configured that checks environment variable, PHP constant and database option.
• Use the helper in has_ai_credentials and AI_Status_Widget to get the correct state information

Use of AI Tools

AI assistance: Yes
Tool(s): IDE Code completion
Model(s): Devstral-Small-2-24B-Instruct-2512
Used for: IDE Code completion

Testing Instructions

• Run e2e tests
• manual tests
  • Setup provider API key as described in issue has_ai_credentials returns false if key is configured via constant #536
  • Go to Dashboard: Connector should show connected state
  • Go to Settings › AI: said error must not be shown

Screenshots or screencast

Before	After
	No error

Changelog Entry

Fixed connector status in settings page an dashboard widget if key is configured using env or constant

[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: LukasFritzeDev <lukasfritzedev@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

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

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 73.16%. Comparing base (7fafa86) to head (728f98c).

Files with missing lines	Patch %	Lines
includes/Admin/Dashboard/AI_Status_Widget.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #537      +/-   ##
=============================================
+ Coverage      73.06%   73.16%   +0.09%     
+ Complexity      1731     1730       -1     
=============================================
  Files             85       85              
  Lines           7466     7467       +1     
=============================================
+ Hits            5455     5463       +8     
+ Misses          2011     2004       -7     

Flag	Coverage Δ
unit	73.16% <83.33%> (+0.09%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[LukasFritzeDev]

I’m not sure how to test this in the e2e tests. Sure, we could add a test spec for this, but this would require to set the config value in .wp-env.test.json and this would break other tests. Should set up an additional env with the value and run a seperate test script for this? Do you have any other ideas?

[justlevine]

I’m not sure how to test this in the e2e tests.... Do you have any other ideas?

I don't think we need explicit e2e testing for this, since the outcome - behavior when there are/arent creds - hasn't changed. What's changing here is the internal handling for where credentials can be sourced from, so PHPUnit (Integration) testing should be enough IMO.

[gziolo]

Why don't you check directly on the AI provider instance whether it's configured? The connectors for AI providers gets registered automatically based on the info stored in AI provider registry. In fact, the names for the env variable and PHP constant are standardized there.

[dkotter]

I’m not sure how to test this in the e2e tests. Sure, we could add a test spec for this, but this would require to set the config value in .wp-env.test.json and this would break other tests. Should set up an additional env with the value and run a seperate test script for this? Do you have any other ideas?

I agree with @justlevine here that we don't really need an E2E test for this. That said, we do load a test plugin in our test environment and so you could use that to help with this. As an example of something I've done before, you could add something like this in the e2e-request-mocking.php file:

// Set the OpenAI API key as a constant when override param is set.
add_action(
	'init',
	static function () {
		if (
			isset( $_GET['ai_api_key_override'] ) &&
			! defined( 'OPENAI_API_KEY' )
		) {
			define( 'OPENAI_API_KEY', 'valid-api-key' );
		}
	},
	1
);

And then in your E2E test, do the following:

1. Remove credentials from OpenAI
2. Go to the settings page and ensure the admin notice shows
3. Refresh the settings page with the query param ai_api_key_override added
4. Ensure the admin notice no longer shows

Could then replicate this for the dashboard widget

[dkotter]

Why don't you check directly on the AI provider instance whether it's configured? The connectors for AI providers gets registered automatically based on the info stored in AI provider registry. In fact, the names for the env variable and PHP constant are standardized there.

@gziolo Not sure I completely follow? Is this around the question about E2E tests? Or a suggestion on how the code in this PR could be better? Need to do a full review but in looking quickly, does look like it pulls the env and constant name from the Connector Registry.

As far as I know though, that registry doesn't tell us if a Connector is actually configured. Let me know if that's not correct though.

EDIT: Reading again, I think what you're referring to is the AI Client Registry, not the Connectors Registry. In that case I do think we can use that instead though it's not super different from the approach taken here

[gziolo]

@dkotter, I'm talking about production code and the fact that AI providers need to be configured before they get discovered by the connectors registry. Even when the AI provider uses db setting, it's the connector that sets everything on the AI provider instance. See:

https://github.com/WordPress/wordpress-develop/blob/7938204d20159fa863e6d34af352bb7557524354/src/wp-includes/connectors.php#L626

[dkotter]

the fact that AI providers need to be configured before they get discovered by connectors registry. Even, when the AI provider uses db setting, it's the connector that sets everything on the AI provider insrance.

I think we're saying the same things, apologize for the back and forth (see my comment here on recommended changes that I think matches what you're saying).

If we just use wp_get_connectors, it never tells us what connectors are actually configured. But yes, if we use AiClient::defaultRegistry, that should only give us AI providers that have been configured. I'd argue this is more confusing than it needs to be and maybe having a is_configured key as part of the data wp_get_connectors returns would be nice but regardless, we can work around that here with a better approach than we currently have

[LukasFritzeDev]

As suggested, I’ve refactored the function has_api_key_configured so that it uses $registry→sProviderConfigured instead of custom logic.

When it comes to testing:

so PHPUnit (Integration) testing should be enough IMO.
#537 (comment)

I’ve not yet added any tests, because I’m still not sure how to add those.

• The helper function has_ai_credentials seems not to be tested directly. Should we add tests for this?

• The Settings_Page evaluates the property that is generated in the filter function for script_module_data_' . self::PAGE_SLUG in JS. I did not find any tests for the filter function. https://github.com/WordPress/ai/blob/develop/includes/Settings/Settings_Page.php#L82-L82

• AI_Status_Widget->render uses the helper. https://github.com/WordPress/ai/blob/develop/includes/Admin/Dashboard/AI_Status_Widget.php#L64-L64 There are tests for this that check the status icons if the correction option is set. Tests could be added that check for the checkbox if the provider key is set via db option, constant or ENV. Would this be a good strategy?

If one of these strategies should be implemented, we would need to mock the AiClient::defaultRegistry. I’m not sure how to do this the best way. Any advice?

[dkotter]

@LukasFritzeDev Thanks for this PR! I've added some basic unit tests and things look good to me!