Michael Beckwith

Hmm. $client should be an instance of https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.11.3/vendor_prefixed/algolia/algoliasearch-client-php/src/SearchClient.php with the listApiKeys() method being defined at Line 223 to 226

We’re definitely getting into the proverbial weeds here.

I’m also suddenly curious if a second application would succeed, but understand if you don’t want to take that route. It could always be deleted afterwards.

So the assert_valid_credentials method can be found at https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.11.3/includes/class-algolia-api.php#L195-L244

Would be interesting to:

1. verify the 2 parameters are coming in as expected.
2. Add a log line in the catch block for $client->listApiKeys() call
3. Verify the $client->getApiKey( (string) $api_key ); call is what we’re expecting based on dashboard values. Maybe use a try/catch around that as well.
4. Check if we get to the if ( ! empty( $missing_acls ) ) { ... } section where we throw our own exception.

Did it allow you to successfully re-activate too? or is that still causing errors? Trying to determine urgency of a potential code reworking for the details

Are you getting errors like “headers already sent” or similar? or is it a complete white screen or “your site has experienced an issue” type message?

The line in question is definitely a new one from the latest release, but we hadn’t been experiencing this issue thus far.

In case it helps, what version of PHP are you running on, in case that’s contributing to the issue?

Hi @ethos-unlimited

A lot of our recent work has been focused on getting this type of issue stabilized and better handled.

I know we have a release going out today that adds in extra checks for current site domain+connecting user and will force disconnect if there’s a mismatch.

An example of when this would come up is if say you’ve cloned down the production install to a staging or local copy. Curious if you can confirm if that type of thing has been done for this site in question.

Also curious if there’s anything in general hosting error logs around the times that manual reconnection had to be done. Hopefully not the case, but possible that new tokens and whatnot don’t save successfully somehow, but the previous refresh token was used already.

Did anything get logged for that?

Regarding “All API Keys” listing, I assume this to be expected, but we have zero control with what shows there. That’s an Algolia.com question.

Out of extra curiosity, have you reached out to Algolia support regarding this? They may be able to help deduce why the app/api pairings aren’t validating, or at least if they SHOULD.

I still believe we’re likely failing at a spot with this:

try {
	$acl = $client->getApiKey( $search_api_key );
} catch ( AlgoliaException $e ) {
	return false;
}

Which is a step that includes their PHP SDK

What are the restrictions shown when visiting https://dashboard.algolia.com/account/api-keys/restricted?applicationId=YOURAPPLICATIONHERE ?

Fill in the actual application ID for that URL. We’re wanting specifically the “Search-only API Key”

Primary being “post” post type?

Don’t really need to move TOO much, since the issue at hand is scheduled posts not self indexing. So primarily we’d want/need the theme/plugin environment more than database. Also to ensure we don’t accidentally push non-production data to the prod Algolia index, change out the prefix value to have it create a temp index in Algolia that you can delete afterwards.