Change our AI connector check from looking at configuration to looking at if authentication is set

[dkotter]

What?

Adds new helper functions that check if a connector has authentication in place, going from ENV var to constant to API key in the database. Use this in place of our new is_connector_configured check.

Why?

In #537 we added a new is_connector_configured function and use that when determining if we have AI credentials. In testing something else, I was seeing lots of extra requests being made and realized that the $registry->isProviderConfigured( $connector_id ) check that we run in is_connector_configured makes an actual API request to validate credentials.

While this can be great in some circumstances, by attaching that to our has_ai_credentials function, this ends up running all the time (basically every admin page load).

The original code here never verified credentials, it just checked if we had an API key set. As reported in #536, the issue with that check is it didn't consider ENV vars or constants and we fixed that with this new is_connector_configured function.

But I don't think it's ideal to make all of these requests so this PR adds new functions that are now used instead of is_connector_configured that bring us back to just checking for the existence of credentials, though now checking ENV var, constants and API keys in the database to resolve the original issue. This matches the original intent discussed here.

How?

• Adds a new has_connector_authentication and get_connector_api_key_source, the latter mirroring what WordPress Core does in _wp_connectors_get_api_key_source and the former being used as a replacement for is_connector_configured
• We retain the is_connector_configured function in case we want to use this at some point in the future. For example, likely could replace our has_valid_ai_credentials with this, or use it within that

Use of AI Tools

AI assistance: Yes
Tool(s): Cursor
Model(s): GPT-5.5
Used for: Investigating the issue and researching a few approaches to resolving. Execution and testing done by me

Testing Instructions

See testing instructions on #537 to ensure that issue is still resolved

Changelog Entry

Added - New helper functions that are used to determine if we have valid AI Connector credentials.
Changed - Use the new has_connector_authentication instead of is_connector_configured to avoid unnecessary API requests.

[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: dkotter <dkotter@git.wordpress.org>
Co-authored-by: LukasFritzeDev <lukasfritzedev@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 78.57143% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.01%. Comparing base (05766ce) to head (b99f38f).

Files with missing lines	Patch %	Lines
includes/helpers.php	78.57%	6 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #603      +/-   ##
=============================================
+ Coverage      74.00%   74.01%   +0.01%     
  Complexity      1738     1738              
=============================================
  Files             85       85              
  Lines           7490     7517      +27     
=============================================
+ Hits            5543     5564      +21     
- Misses          1947     1953       +6     

Flag	Coverage Δ
unit	74.01% <78.57%> (+0.01%)	⬆️

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.

[dkotter]

@LukasFritzeDev wondering if you might have time to review this and ensure it still resolves your reported issue in #536? In testing some other things, realized the approach we took in #537 introduced some unintended side effects so I've switched things to the approach you mentioned here

[LukasFritzeDev]

wondering if you might have time to review this and ensure it still resolves your reported issue in #536? In testing some other things, realized the approach we took in #537 introduced some unintended side effects so I've switched things to the approach you mentioned here

This approach resolves the described issue. I tested both, using env and constant. The warning in the AI settings page is not shown and the state in the status widget is shown correctly (if a valid token is set).

I noticed a small regression, if an invalid token is set.

• (Out of scope:) Connectors page shows »Set up«, indicating the configured credentials are invalid
• A warning in the AI settings page is shown
  • This in another warning than before
  • It’s shown because the settings page evaluates two properties: hasCredentials and hasValidCredentials (Code)
• The widget shows a success icon implicating a valid connection
  • This is, because the widget uses AI_Status_Widget->get_ai_connectors which uses has_connector_authentication (Code)
  • But the function has_connector_authentication introduced by this PR only checks for existance and does not validate the token.
  • Maybe we should use has_valid_ai_credentials in the widget?

---

Just out of curiosity: What are the “unintended side effects” you noticed?

[dkotter]

I noticed a small regression, if an invalid token is set
A warning in the AI settings page is shown
The widget shows a success icon implicating a valid connection

Are these regressions based on how things currently work in the latest released version? Or are these regressions as compared to the changes made in #537? If it's the latter, that may be fine though I can look closer early next week when I'm back online.

Just out of curiosity: What are the “unintended side effects” you noticed?

So our has_ai_credentials function is used in quite a few places. And with the change in #537, this function was calling is_connector_configured which in turn makes an actual API request to each provider to see if the connection is valid. This meant that in essence, every single page load in the admin would fire off multiple API requests.

Noticed this while testing some changes to the Connector Approval experiment as I was seeing multiple blocked requests on each page load whereas I wasn't seeing those previously. While these requests are meant to be lightweight and not use many tokens, still not ideal to fire off that many requests and potentially burn through a users token budget.

[LukasFritzeDev]

Are these regressions based on how things currently work in the latest released version? Or are these regressions as compared to the changes made in #537?

the later one.

As suggested, I guess we might simply use has_valid_ai_credentials to fix this.

[jeffpaul]

Testing on Playground and locally and am seeing issues where connector API keys either aren't saving or somethings off:

When I initially set up locally, I was able to save an OAI key and activate AI features but then going back to Connectors I got the error above and then the expected one on the AI settings page:

[dkotter]

As suggested, I guess we might simply use has_valid_ai_credentials to fix this.

@LukasFritzeDev In giving it more thought, I think it's fine to make an API request on that dashboard page so I've reverted the dashboard widget to use the is_connector_configured function, which I think fixes that issue for you.

Testing on Playground and locally and am seeing issues where connector API keys either aren't saving or somethings off

@jeffpaul In theory, none of the code changes in this PR should be impacting that screen (in fact, the saving and validating of those credentials is entirely done by the Connectors API, not something we touch at all).

That said, there was a bug with the Connectors Approval experiment that was fixed in #595 that is now merged into this PR that could have caught you. Basically if Connectors Approvals was turned on and the Connector wasn't approved for the AI plugin, validating credentials was being unintentionally blocked and would lead to the issue you were seeing.

So assuming that is the issue you were having, that should be resolved in this PR now since develop has been merged in

[jeffpaul]

Retested via Playground and AI functionality continues to work as expected, thanks!