Richard Aber

Thank you @jdingman, I’ve made a copy of it locally, if you’re concerned about leaving the gist up.

Howdy @jdingman,

We haven’t been able to reproduce the issue.

It may have been a momentary hiccup on the remote API end, have you tested upgrading again just to see?

If it still doesn’t work when you test upgrading again, then perhaps more information about your local environment setup would be helpful?

You could go to Tools -> Site Health -> Info and click the “Copy site info to clipboard” button, then paste it into a gist or something so it can be shared with us.

Howdy @jdingman,

I’m not currently seeing any issues connecting to the API with version 1.4.0 in my local development environment, which is also not accessible from the interwebs.

Could there be a proxy involved? That could cause issues, as the plugin does not currently support proxies.

Howdy @matchlessweb,

I just visited the URL you referenced, and I’m not receiving the described error.
Is it possible that this is cache related (Cloudflare, CDN, browser)?

Howdy @johntyb

I have opened an issue in GitHub to gather more information and track the issue here https://github.com/WebDevStudios/wp-search-with-algolia/issues/76

Can you confirm if you running WP Search with Algolia version 1.3.0?

Would it be possible to downgrade to a previous version (like 1.2.0 for example) and see if that has any impact?

Also, if you could provide any more details, such as your PHP version, that could be useful.

• This reply was modified 4 years, 8 months ago by Richard Aber. Reason: enable follow-up notification
• This reply was modified 4 years, 8 months ago by Richard Aber. Reason: Ask about PHP version

Howdy @joncampbell,

I am unable to reproduce the issue locally.

When I check my database for the term “Marketing & Finance”, indeed I see the ampersand as an HTML entity in the database:

mysql> SELECT * FROM local.wp_terms WHERE name LIKE "%Marketing%";
+---------+-------------------------+-------------------+------------+
| term_id | name                    | slug              | term_group |
+---------+-------------------------+-------------------+------------+
|     202 | Marketing & Finance | marketing-finance |          0 |
+---------+-------------------------+-------------------+------------+

However, when I check my Algolia index record, the ampersand does not appear as an HTML entity there:

{
  "term_id": 202,
  "taxonomy": "category",
  "name": "Marketing & Finance",
  "description": "",
  "slug": "marketing-finance",
  "posts_count": 1,
  "permalink": "https://algolia.test/category/marketing-finance/",
  "objectID": "202"
}

If I search for “Marketing” in my test site, the autocomplete drop down does not display the ampersand as an html entity, but as the decoded & character.

Can you determine if the ampersand is encoded as an HTML entity in your Algolia index? Also, where the value is visibly output, can you check that the code is using the triple-stash style for unescaped output {{{ value }}}.

Glad to hear that it helped. I’m going to mark this as resolved.

Howdy @jpvanmuijen,

I imagine the error you received is because the shared_attributes function in the linked example did not return the $attributes array.

First, make sure you have you read and followed the instructions for WPML integration found at https://community.algolia.com/wordpress/wpml.html

Following those instructions will ensure that the content itself has a wpml.locale attribute in the index for faceting, and will expose a window.current_locale JS variable in the page, which you can use for further customization.

From there you should be able to customize the Algolia JS widgets in the autocomplete.php and instantsearch.php templates for your use case. There is additional documentation about customizing those templates here https://community.algolia.com/wordpress/customize-autocomplete.html and here https://community.algolia.com/wordpress/customize-search-page.html.

I believe the data.label and config[‘label’] in autocomplete.php is what you would want to look further into… You might be able to use the data.label in conjunction with a custom JS var to swap the text to another language.

I have created some example code in this gist to do such a thing, and tested it locally. Note that my default language is English, and I used Spanish (very badly translated by Google) in my example code. So you will need to adjust for your language.

Give that a shot and let us know if it helps solve your issue.

Howdy @codesplice, we released WP Search with Algolia version 1.2.0 today.

1.2.0 now uses the filterable hitsPerPage param when it calls $query->set( 'posts_per_page', $params['hitsPerPage'] );.

Let me know if you get a chance to test the filter code from our previous discussion with 1.2.0, and see if that resolves the issue you were experiencing, so you don’t have to hardcode $posts_per_page = 25; directly in the class-algolia-search.php file.

Howdy @saschinger,

“Use Algolia in the backend” is a server-side, PHP powered search. This is similar to the standard WordPress search experience, in that a user’s search terms are submitted to the website’s server. It differs from a standard WordPress search in that the search query is not run directly against WordPress’ database, but against Algolia’s search index.

“Use Algolia with Instantsearch.js” is a client-side, JavaScript powered search. This is a “faster” search experience, and is performed completely on the client side (directly in the browser) via JavaScript. The user’s search terms are not submitted to the website’s server, the Instantsearch.js sends the user’s search terms directly to the Algolia search index, and receives the results directly from the Aglolia search index, and updates the search page without a reload.

The differences between those two options really boil down to speed versus theme compatibility. The “Use Algolia with Instantsearch.js” option provides a faster, smoother, search experience, but it might not “look right” depending on your theme. The “Use Algolia in the backend” option is a little slower experience, but is more likely to “fit in” with your theme.

I would suggest trying the “Use Algolia with Instantsearch.js” option. If it looks good with your theme, use that. If it doesn’t look good with your theme, switch to the “Use Algolia in the backend” option.

Now that you have a little more information regarding the two options, I’m going to go ahead and mark this as resolved.

Howdy @kzeni I am marking this as resolved, per our discussions in Issue #9 on Github.

Howdy @lipaonline, I’m marking this as resolved, since having more records in the index than posts is expected behavior.

Howdy @kzeni, I’m going to mark this as resolved since your PR was indeed accepted and merged.

Howdy @codesplice, Thank you for testing that.

I see now, a little further down the in the same method, that $posts_per_page is used again in a call to $query->set( 'posts_per_page', $posts_per_page );, so indeed filtering the hitsPerPage search param will not suffice.

It looks like we might need to use the filtered hitsPerPage value in that call to query set. I’ll take a look at what might be necessary to improve that for a future release, and have opened an issue in the project’s GitHub to track it.

If you could provide any additional information, such as the theme and any plugins that might be affecting the number of search results per page differing from the posts_per_page option, that might prove helpful.

Howdy @codesplice,

We use the value of the posts_per_page option when we query the Algolia index in class-algolia-search.php.

You can see just below the line you modified that the $posts_per_page variable is used as the value of the hitsPerPage key in the $params array.

There may be a custom search implementation provided by either your theme, or another plugin, that does not use posts_per_page when it runs it’s own search, and that is likely related to the issues you describe, which sounds like it could be pagination related.

You could try hooking into the algolia_search_params filter to override the hitsPerPage value to 25, and see if that works, rather than modifying the plugin directly.

Try something like this, and let us know if it works.

function yourprefix_algolia_search_params( $params ) {
	$params['hitsPerPage'] = 25;
	return $params;
}

add_filter( 'algolia_search_params', 'yourprefix_algolia_search_params' );

• This reply was modified 5 years, 3 months ago by Richard Aber.