The perfect starting point to integrate Algolia within your PHP project

| Q | A | ----------------- | ---------- | Bug fix? | no | New feature? | yes | BC breaks? | no
| Related Issue | Fix #... | Need Doc update | no

Describe your change

This PR will provide PHP 8 Support for the library. Atm this is blocking https://github.com/laravel/scout/pull/425

I'll keep the PR in draft until I've fixed the build.

| Q | A | ----------------- | ---------- | Bug fix? | yes | New feature? | no | BC breaks? | no
| Related Issue | Fix #546 | Need Doc update | no

Describe your change

Automatically enable JSON_UNESCAPED_UNICODE option for request payload encoding.

I've tested this on a real index an it does work as expected — the document is indexed perfectly fine.

This is a port of #545 onto 2.x master version. Reincarnation of #577 with a unit test added.

I have some work in progress over here: #62 The problem is that travis does not seem to be aware of any applicationId, and I suppose the apiKey is not injected either.

Locally everything works fine, is there a trick here to tell travis about my custom appId and apiKey so my tests turn to green?

We abstracted an interface for the failed hosts retrieval so that users can easily choose their caching strategy based on what is best according to their environment.

By default we push the new File Based cache strategy, but if the tmp directory is not writable, we fallback to the in memory strategy.

User can provide an implementation of FailingHostsCache as a replacement of this strategy.

Because of the current design of the Client, the FailingHostsCache implementation needs to be provided at Client initialization because that is where the ClientContext is instantiated and during that instantiation we need to rotate the hosts.

Regarding the BC static to non static, given it has only been available in 1 version and was only used internally + wasn't even called statically, I think we are safe doing the change.

TODO:

• [x] Unit tests
• [x] Choose if we push the file based cache by default or if we keep the in memory strategy
• [x] Implement in memory cache invalidation for long running PHP processes > 5min
• [x] See what we do about the static to public method signature of addFailingHost (BC) that was only introduced in last version

Started correcting some docblocks, and refactored some small pieces.

Please note that I have not a deep understanding of the behaviour of this client yet, so please tell me if some changes may break something. Hope the tests will catch problems though.

• [x] Run php-cs-fixer and add a basic .php_cs config
• [x] Add missing return tags
• [x] Enhance the docblocks
• [x] Use more fine grained params and return types
• [x] Try to refactor some pieces of code that are repeated a lot
• [x] Better format long docblocks

Do you guys see any interest in these adjustments if they do not introduce BC issues?

Please react on the changes so I can adjust the PR.

Fixes #32

Added support for custom curl options like CURLOPT_PROXY, CURLOPT_PROXYPORT... On construct you can specified an array with curl options:

$options = [
    'curloptions' => [
        CURLOPT_PROXY => 'tcp://1.2.3.4:80',
        CURLOPT_PROXYPORT => '8080',
        CURLOPT_PROXYUSERPWD => 'USERNAME:PASSWORD',
        //...
    ]
];

$client = new Client(
            'app-id',
            'admin_api_key',
            null,
            $options
        );

if a bad curl option is given, proper exceptions are thrown :

• InvalidArgumentException when not an array
• OutOfBoundsException when not a valid curl option

Hi

I would like to submit a PR to add a public method to the ObjectIterator which enables getting the number of the records in the index available in the api response when the broweObjects method is called. something along these lines

public function getNbHits() { return isset($this->response['nbHits']) ? $this->response['nbHits'] : null; }

Would that be acceptable ?

Thank you.

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests? | yes | Doc? | no | Fixed tickets | https://github.com/algolia/algoliasearch-client-php/issues/283

Description

This PR catches an Exception code to distinct different type of AlgoliaException..

a simple add object method like this

$index->addObject( [ "avg_rating"=> 1.23456, 'objectID' => '573' ]);

will result in an avg_rating of 0 on my algolia online records. However when i change avg_rating to 1 or 1.0, it is stored as 1. It seems that it cannot store any decimal point numbers. I am using the codeigniter framework. Does anyone else have that issue?

Resolves: #181

This PR will rotate the hosts array at each failed connection attempt. ClientContext holds the state and the Client simply ask for a rotation by passing the "justUnresolvable" host as argument.

Shared state between different instances of the Client: Given the current design of the Client, sharing state between different Client instances is not feasable. Also I don't think it is a big issue because most of the time, there will only be one instance of the client per PHP thread.

If for some reason a user wants to share the state between multiple instances of a the client, he could simply override the ClientContext on all the Client. Shared state between different PHP processes In PHP processes don't share state between them, every process spawning is an attempt to recover connection to the main host. In a future version of the API Client, we could create an abstraction around the state to share it via storage layer (ideally in memory k/v store), but for now this will be overkill and very messy to implement.

Let me know your thoughts @maxiloc @JanPetr @redox

Hi.

I added some new exceptions to make error handling easier. We have a project where we need some specific processing depending on the error returned by the API, and it would be nice if we can have it thrown directly by the client api. :)

(I didn't move the AlgoliaException.php to keep compatibility.)

• Algolia Client Version: N/A
• Language Version: N/A

Description

Consider using a static analysis tool (like PHPStan or Pslam), in order to catch basic errors, like the class not found issue introduced recently.

Currently there is no way to verify that code that is not covered by tests isn't broken. With static analysis all code would be automatically type checked, which should make it (nearly) impossible for these kind of errors to happen.

It shouldn't be too much work to set it up with real low strictness, which should catch any basic errors. At a later point it could be configured to be more strict, catching more specific errors.

If you need any help with setting this up, i'd be more than happy to help.

Hi! I'm working with @julienpa to get the applications of my company on a new Algolia architecture, and I'm facing issues where some of the cronjobs I have to run appear to be stuck sometimes.

I'd like to be able to easily implement custom logic where I start logging the taskID with an increasingly high log level when exceeded an arbitrary duration, and I would like that logic to kick in whenever I call wait() on a response.

This seems to result in this method being called: https://github.com/algolia/algoliasearch-client-php/blob/ffef644ac41411f64e4522157ed53fb825b0908a/src/SearchIndex.php#L604-L620

It would be great if the current implementation of the retry logic could be extracted in a separate class, and if there was an interface I could implement with my custom logic and if I was able to inject my custom implementation in the configuration so that it replaces the default implementation.

Right now, the workaround would be to extend the SearchIndex, override that method, extend SearchClient and override initIndex so that it returns the overridden SearchIndex.

• Algolia Client Version: 3.2.0
• Language Version: 8.1.2

Description

It seems like the current implementation of the exception is misleading:

https://github.com/algolia/algoliasearch-client-php/blob/ffef644ac41411f64e4522157ed53fb825b0908a/src/RetryStrategy/ApiWrapper.php#L151-L196

To day, I got the following exception Impossible to connect, please check your Algolia Application Id.

Turning on logging revealed that this was in fact due to a missing feature on a new infrastructure we are testing:

^ array:3 [
  "level" => "debug"
  "message" => "Algolia API client: Host failed."
  "context" => array:7 [
    "body" => array:1 [
      "numericFilters" => "document_update_time < 1650806228"
    ]
    "headers" => array:4 [
      "X-Algolia-Application-Id" => "redacted"
      "X-Algolia-API-Key" => "redacted"
      "User-Agent" => "Algolia for PHP (3.2.0); PHP (8.1.2); Guzzle (7)"
      "Content-Type" => "application/json"
    ]
    "method" => "POST"
    "query" => []
    "retryNumber" => 4
    "host" => "https://mlnqxjqtya-1.algolianet.com/1/indexes/int_products_gb/deleteByQuery"
    "description" => "Retriable failure on mlnqxjqtya-1.algolianet.com: Not Implemented"
  ]
]

I would expect never to get an exception that is plain wrong. Before getting this issue, I had a problem where my index name was wrong, but it was diagnosed in the same way: Impossible to connect, please check your Algolia Application Id..

What I would expect would be the last error to be remembered and used in the exception message. Also, the exception type is wrong: the host was not unreachable, it was missing a feature.

• Algolia Client Version: 3.2.0
• Language Version: 7.4

Description

Hi there,

I'm using the client to retrieve product recommendations based on the bought-together and related-products models. Some of our indexes don't have enough events to train models so they shouldn't be used for recommendations, but it's possible that we misconfigure this somewhere, or that the number of events drops for indexes that did have enough events at some point.

Where there's no trained model (but the index does exist) I get the following exception:

(stack trace limited to vendor namespace only)

Fatal error:  Uncaught Algolia\AlgoliaSearch\Exceptions\NotFoundException: Index ai_recommend_webshop-products-se:related-products.indice.bin does not exist in ./vendor/algolia/algoliasearch-client-php/src/RetryStrategy/ApiWrapper.php:217
Stack trace:
#0 ./vendor/algolia/algoliasearch-client-php/src/RetryStrategy/ApiWrapper.php(167): Algolia\AlgoliaSearch\RetryStrategy\ApiWrapper->handleResponse()
#1 ./vendor/algolia/algoliasearch-client-php/src/RetryStrategy/ApiWrapper.php(101): Algolia\AlgoliaSearch\RetryStrategy\ApiWrapper->request()
#2 ./vendor/algolia/algoliasearch-client-php/src/RecommendClient.php(85): Algolia\AlgoliaSearch\RetryStrategy\ApiWrapper->write()
  thrown in ./vendor/algolia/algoliasearch-client-php/src/RetryStrategy/ApiWrapper.php on line 217

I would like to catch this kind of exception, but it is identical in type to the exception I get when the index doesn't exist:

Fatal error:  Uncaught Algolia\AlgoliaSearch\Exceptions\NotFoundException: Index does not exist in ./vendor/algolia/algoliasearch-client-php/src/RetryStrategy/ApiWrapper.php:217

Ideally this would be a different kind of exception so my code can handle missing/untrained models but doesn't handle missing indexes since that's a much more grave error. Attempting to parse the exception message seems a little unreliable, as those messages might change without us noticing.

Steps To Reproduce

1. Request a recommendation from an existing index without a trained model.

| Q | A | ----------------- | ---------- | Bug fix? | no | New feature? | no | BC breaks? | no

Describe your change

This bootstraps a new way to test our API client, where (for PRs) we test the formed requests instead of calling Algolia directly.