Allow filtering of Provider credentials

[dkotter]

Description of the Change

This PR takes just the Provider credential filtering out of #1038 in order to make both of those PRs easier to review and test and hopefully get this piece merged in sooner.

The work here was heavily inspired by the work done in #1020 (and supersedes that PR) and was originally done in #1038 to ensure any changes we make around credentials management also work when we move Providers to be global.

Here's a high-level overview of changes here:

• Introduce a new CredentialResolver class that will pull just credentials out of our settings
• Add new methods on the Provider class that get all credentials for that Provider or a specific credential field. These all pass through new filters (classifai_provider_credentials_{$provider_id} and classifai_provider_credentials) making it easy for other to hook in and change those credentials
• More standardization on how API requests are made, making it easier to ensure all credentials pass through our new filter and setting us up for the future where we will integrate the new WP AI Client for these requests

Closes #1019

How to test the Change

Practically all Feature/Provider combinations are touched by this update though in general, this is all fairly minor changes. Testing to ensure Features still work as expected (that API requests work) is what is needed here.

Changelog Entry

Added - New methods on the Provider class that allow you to get all credentials or a specific credential, pulling the credentials from the larger Feature settings
Added - New filters, classifai_provider_credentials_{$provider_id} and classifai_provider_credentials, that allows developers the ability to override AI credentials prior to those being used
Changed - For filters that run when API requests are made, the Feature name, not the Feature option name is now passed as an argument. If you have code that relies on that argument, updates will be needed

Credits

Props @fabiankaegy, @dkotter

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

[peterwilsoncc]

I've added a few notes inline.

Primarily, I think we could make the filter easier to use by including the provider name in the filter. Secondly, I'm wondering about back-compat with the type change.

[peterwilsoncc]

Nitpick: align name and descriptions with spaces.

It's a little mixed but for the most part the docblocks are aligned in this manner.

[dkotter]

Updated in 593bb5d

[peterwilsoncc]

Back-compat: The type changes here will affect any third party developers making use of the class, resulting in a fatal error.

• Do we need to handle this situation?
• Does this affect developers registering custom features/providers?

If it's possible to handle this without breaking back-compat it would be nice to do so.

🔢 This same change is made in a few of places.

[dkotter]

So the plan here is to get rid of these individual APIRequest classes and instead use a single APIRequest class for everything, that uses the PHP AI Client when possible. This is likely coming in the next release so I wasn't overly worried about back-compat here as that change will also break things.

That said, not hard to maintain back-compat for now so I've updated the approach to do that: 97d126c and 04d2bca

[peterwilsoncc]

This looks good to me code wise and is generally working when testing.

As discussed in Slack, I was having trouble with classifai_provider_credentials_ms_computer_vision filtering. Running this code and enabling "Descriptive Text Generator" was allowing me to save the settings without a warning but the features list was showing the warning "This Feature is enabled but needs a Provider configured. Please click the Settings button to complete the setup."

add_filter(
	'classifai_provider_credentials_ms_computer_vision',
	function( $creds, $feature_id, $feature_provider_settings ) {

		$creds = array(
			'endpoint_url' => 'https://eastus.api.cognitive.microsoft.com/',
			'api_key' => '', // Cognitive Services | Computer Vision from the internal docs
		);


		return $creds;
	},
	10,
	3
);

I added an xdebug break point within the filter and it wasn't hit when I saved the features settings.

After our discussion, I put some junk values in the API settings and the filter began working as expected

[dkotter]

After our discussion, I put some junk values in the API settings and the filter began working as expected

Yeah, the issue here is a couple checks we run when most Provider settings are saved (varies slightly on a Provider by Provider basis). The first is a check like this:

if ( ! empty( $new_settings[ static::ID ]['endpoint_url'] ) && ! empty( $new_settings[ static::ID ]['api_key'] ) ) {

So if the credentials we want (in this case the endpoint URL and API key) aren't passed in, we don't try and authenticate. This used to make sense as there's no reason to authenticate if we don't have the needed credentials. But now that credentials don't need to be set in the UI and can instead be set by a filter, this check can cause problems.

Second, we have checks like this:

if ( ! ( $is_authenticated && $is_endpoint_same && $is_api_key_same ) ) {

In this case if the credentials we have saved aren't different from the credentials being submitted, we also don't try to authenticate again. This is a less likely issue to run into but could cause problems.

Both of these should be addressed but unless you think differently @peterwilsoncc, I'm inclined to merge this in and address these problems in a follow-up PR, allowing us to get this part of it released sooner (and hopefully get some real user testing on it to see if there are additional follow-ups needed).