Skip to content

Conversation

MiguelAxcar
Copy link
Contributor

@MiguelAxcar MiguelAxcar commented Aug 25, 2025

Description of the Change

This PR intends to extract common HTTP functionality into a new HTTPClient base class.

Reasons

  • Reduce duplicated logic across providers and improve architecture
  • Open room for integrating https://github.com/WordPress/php-ai-client once it has a release
  • Minor: honestly, I was itching to do this after seeing some repeated code while working on #972

Integrating https://github.com/WordPress/php-ai-client may be a good idea for the future as it would give ClassifAI a standardized way to communicate with AI providers, reduce the amount of custom request code maintained, and align with a broader WP ecosys standard.

My idea / proposal is to land this refactor first to centralize the shared HTTP code in HTTPClient, handling potential adjustments, then wait for php-ai-client to have a release then add a small bridge with minimal changes to integrate it.

How to test the Change

  • Test the whole Critical Flow (instructions)
  • Verify success and errors for all providers and features
  • Run a full feature and regression test
  • Click through all admin UI flows, verify that no new notices or fatal errors will show.

Changelog

Developer - Consolidate API request logic with HTTPClient abstraction
Developer - Add HTTP client for local providers
Fixed - Fatal error thrown by is_embeddings_generation_in_progress() when provider key is invalid

Credits

Props @MiguelAxcar

Checklist:

$response_message = wp_remote_retrieve_response_message( $response );
$status_text = $response_message ? $response_message : __( 'Unknown error', 'classifai' );

// Try to extract specific error message from the server response
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Former code had chance for improvement:

$message = $json['error']['message'] ?? esc_html__( 'An error occurred', 'classifai' );

It should be checking on $json['error']['message'] only if $json['error'] isn't a string itself.

It's expected now for users to see much more details from providers on errors instead of former An error ocurred message only.


use Classifai\Providers\Provider;
use Classifai\Providers\OpenAI\APIRequest;
use Classifai\Providers\Localhost\APIRequest;
Copy link
Contributor Author

@MiguelAxcar MiguelAxcar Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer using OpenAI for local providers, now they have its own clients

Comment on lines +1731 to +1733
if ( null === self::$scheduler_instance ) {
return false;
}
Copy link
Contributor Author

@MiguelAxcar MiguelAxcar Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was throwing a fatal error when key was empty / with error.

Comment on lines +46 to +47
$this->username = get_username();
$this->password = get_password();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kept specificities from Watson auth

@MiguelAxcar MiguelAxcar changed the title [WIP] Consolidate API request logic with HTTPClient abstraction Consolidate API request logic with HTTPClient abstraction Aug 25, 2025
@MiguelAxcar MiguelAxcar marked this pull request as ready for review August 25, 2025 18:49
@MiguelAxcar MiguelAxcar requested review from dkotter, jeffpaul and a team as code owners August 25, 2025 18:49
@vikrampm1 vikrampm1 moved this to Code Review in Open Source Practice Aug 25, 2025
@jeffpaul jeffpaul added this to the 3.7.0 milestone Aug 26, 2025
@jeffpaul jeffpaul added the needs:code-review This requires code review. label Aug 26, 2025
@iamdharmesh
Copy link
Member

Thanks for the PR @MiguelAxcar.

I noticed we already have a similar ongoing PR (#994), which is doing the same thing along with integrating the php-ai-client. It’s currently implemented only for OpenAI, with plans to extend it to other providers as well. @dkotter, since you’re the author of that PR, I’d like your feedback on the potential next steps for this one. Whether we should update #994 to extend the base class for all providers (I’d prefer to keep it small initially and focus on php-ai-client or wp-ai-client integration, then handle other providers in a follow-up), tweak this PR to make it useful for #994, or keep it on hold until the ongoing discussions in #994 are finalized. Thanks!

@dkotter
Copy link
Collaborator

dkotter commented Sep 10, 2025

Thanks for the PR @MiguelAxcar.

I noticed we already have a similar ongoing PR (#994), which is doing the same thing along with integrating the php-ai-client. It’s currently implemented only for OpenAI, with plans to extend it to other providers as well. @dkotter, since you’re the author of that PR, I’d like your feedback on the potential next steps for this one. Whether we should update #994 to extend the base class for all providers (I’d prefer to keep it small initially and focus on php-ai-client or wp-ai-client integration, then handle other providers in a follow-up), tweak this PR to make it useful for #994, or keep it on hold until the ongoing discussions in #994 are finalized. Thanks!

Yes, thanks for the work here @MiguelAxcar and I did take a look at this to see if there was anything I should be implementing with the work I was doing in #994. That work is still early stage, as the PHP AI Client (and now the WP AI Client) are still in early development, but we're likely to take at the very least a similar approach that is in that PR.

For now, I'd like to leave this PR open but we're likely to consolidate our approaches here once the AI Client is more stable. I'll come back to this PR at that point and decide next best steps.

@MiguelAxcar
Copy link
Contributor Author

Thanks @dkotter @iamdharmesh for the feedback.

My intent here is to first land a provider-agnostic HTTP layer (auth/headers/errors/timeouts/specificities) and migrate providers onto it, while php-ai-client gets more matured and reach a release.

As mentioned by Dharmesh #994 experiment bridges only OpenAI; great exploration of course, awesome to see this in action first hand btw, but potentially never shipped or will need changes to work. Given that, I would suggest keeping this (or another) PR focused on consolidating the HTTP client across providers, then introduce the PHP AI Client bridge as a small, targeted follow-up, using results from #994 experiment / exploration,

That order keeps the blast radius small, preserves parity, and makes the php-ai-client bridge mostly mechanical per provider.

Happy to help split/cherry-pick pieces to get this in smoothly, or any help I could provide for this.

@dkotter dkotter modified the milestones: 3.7.0, 3.8.0 Sep 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs:code-review This requires code review.
Projects
Status: Code Review
Development

Successfully merging this pull request may close these issues.

4 participants