Allow empty credentials when saving settings

[dkotter]

Description of the Change

We added the ability to easily filter Provider credentials in #1043. One comment on that PR flagged an issue with some Providers, where if you want to filter credentials you first need to add in dummy credentials in order for our pre-save checks to pass.

As a quick explanation, we had some checks in place where we wouldn't authenticate credentials if those credential fields were empty (no need to authenticate if we don't have an API key set, as an example). But in situations where you're overriding credentials, you shouldn't be forced to enter any credentials (dummy or not) in the admin first.

In investigating, found out that about half of our Providers worked fine but the others did not. In comparing those, the ones that work didn't check if credentials exist first before trying to authenticate and instead rely on the authentication check failing to alert the user that something is wrong. You could argue that's not the best user experience but it does more or less accomplish the same thing.

In order to keep this PR as simple as possible, I decided to follow that same approach on all the Providers that weren't working:

• AWS Polly
• Azure OpenAI
• ElevenLabs
• IBM Watson
• Azure TTS
• Azure AI Vision

All Providers should now have an authenticate_credentials method (most already did but not all) and we use that method as one of the first checks when sanitizing settings. If that check fails, we show an error message but we still save all settings (including any credential fields, even if blank).

How to test the Change

In particular, test the Providers listed above:

1. Create a new plugin and hook into the new classifai_provider_credentials, overriding the credentials for the Providers you want to test
2. Install that plugin and ClassifAI into a new environment
3. Choose a Feature one of these Providers uses, configure any settings you may want (leaving credential fields blank) and then hit save. Ensure it authenticates correctly
4. Optional: test that the Feature works as expected
5. Disable the custom plugin and re-save a Feature, again leaving credential fields blank
6. Ensure an error message shows

Changelog Entry

Added - Ensure all Providers have an authenticate_credentials method that we can use to validate the credentials are valid
Changed - Allow all settings to be saved, including credential fields, even if they are blank. This is mostly to support those using the new classifai_provider_credentials filter to override credentials

Credits

Props @peterwilsoncc, @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]

This looks good to me.

For testing I used two approaches:

• created filters for various credentials
• Added a break point at the code point below to ensure the provider settings were saved

  classifai/includes/Classifai/Features/Feature.php

  Line 508 in 119271a

  update_option( $this->get_option_name(), $new_settings );

I've dropped a question inline as to whether we need a follow up ticket.

[peterwilsoncc]

Should we add this filter to the other providers?

Unrelated to this ticket/PR, not a merge consideration.

[dkotter]

So this was added specifically to help mock API responses for AWS Polly in our E2E tests. All other requests we mock using the pre_http_request filter but because we're using the AWS SDK here, these requests don't filter through the WordPress HTTP API and thus that filter never fires.

That said, I'm not opposed to more standard hooks here though I think worth thinking through once we look to standardize on using the PHP AI Client to make our requests (where possible)