Algolia as a wp_query replacement for Elementor Pro website

Probably the first thing to note here is that the Search page settings make use of the wp_searchable_posts index in Algolia, and with the Autcomplete settings, each content type there will create a wp_posts_* index, like wp_posts_product etc, with the last part being the content type slug UNLESS you use the All Posts option. That will also re-use wp_searchable_posts index. I’m assuming you checked just Products for the Autocomplete, meaning it has its own index.

Because of that, each index also gets its own settings and configurations.

This has me now curious if you’re managing your index settings/configuration via the Algolia.com dashboard, or if you’re doing any of it via code and the “Push settings” UI that the plugin offers. If via code, then we can help identify the appropriate filters to use so that you can have 1 combined code-based settings that push to BOTH indexes, and get things sync’d up.

Another thing to note is that with the “Use Algolia with the native WordPress search template” setting, essentially what’s happening is that our plugin intercepts the query being made, sends that query off to Algolia, where it performs it’s search, and returns the determined post IDs. Then once back in WordPress, those IDs are interjected into the search query as part of the “post__in” parameter, basically telling WordPress “Fetch these specifically and display as the results”.

Regarding autocomplete template editing, anything CSS can be done via your stylesheet, and the markup should be plentiful with IDs and classes. Setting SCRIPT_DEBUG to true in your wp-config.php file should also help keep the dropdown open long enough to inspect things.

Regarding potential markup changes, or like removing titles/descriptions, check out our template customization wiki pages at:

• https://github.com/WebDevStudios/wp-search-with-algolia/wiki/Customize-Templates
• https://github.com/WebDevStudios/wp-search-with-algolia/wiki/Customize-the-Autocomplete-dropdown

I know we’re still on version 0.38.x at the moment (linked to Algolia’s 0.38 docs), but we’re trying to get upgraded as a second option.

The main part of the autocomplete.php template file you’re likely wanting to touch up would be at https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/templates/autocomplete.php#L21-L36

Wow, what an extensive answer, thanks a lot!

I had chosen a custom index name prefix in the plugin: wp_algolia_
And then hit “Push Settings”. Having only selected Products on the autocomplete, indeed.
So our relevant index in Algolia was called wp_algolia_posts_product with 56k records.
I just set it back to the default one and pushed again (wp_posts_product), it’s still not working…
I had done it through the UI, however, if it is necessary so that our custom search page can also pull the results from Algolia, we can switch to code.

It’s our search results page that isn’t using the Algolia query for some reason:
https://ericksonstock.net/?s=children+on+house

I have enabled define( ‘WP_DEBUG’, true );

You mention that the “Use Algolia with the native WordPress search template” setting should intercept the query being made and then give different results than the default WordPress ones, right?
Is there any way I can check exactly what query is being processed when searching on the website?
We are using a plugin to display the images that is configured to load them using AJAX and it has an option that says:
Posts source: Current query posts
There might be a chance that whatever method it’s being used to intercept the query is not being taken into consideration when displaying our search results….

We also plan it to take into account product tags first, and then other taxonomies afterwards, because they are being used as keywords. Also to have it not take into account common conjunctions (like on/at/in/of/a/over/and so on), but I suppose that can all be done through the Algolia dashboard…

Thanks for the help on the autocomplete question too! I’ll look into the markup for the autocomplete template, I don’t have any more questions on that regard.

I just set it back to the default one and pushed again (wp_posts_product), it’s still not working…

The prefix alone isn’t going to get autocomplete and the search settings to both point to the same index. It would just give you a wp_algolia_post_products and wp_algolia_searchable_posts indexes instead of versions with just wp_ in front.

Here’s the index I reference when editing the Autocomplete settings, that would be the same as the index used by the Search page settings, regardless of “Use Algolia with the native WordPress search template” or “InstantSearch”. Both set up the same searchable_posts index:

Regarding debugging/confirming that Algolia is being used with just “Use Algolia with the native WordPress search template”, I’ve never really had to trouble shoot that one too much. A not officially tested, non code, method that I can think of off the top of my head would be to do a search for a product that you know is public and published in your WordPress install, but is not indexed. If you get a result, then my head says that that’d be a WordPress-database only search. If you don’t get a result, because it’s not in Algolia index, then that would say to me the index is being used.

The file that powers the Algolia + native search, in case curious:

https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-search.php

Also to have it not take into account common conjunctions (like on/at/in/of/a/over/and so on), but I suppose that can all be done through the Algolia dashboard…

Yes that’s largely handled by Algolia natively, and they have configuration options for other optional items.

My biggest pro-tip regarding setting/configuration would be either handle all of that through code/API, and the “push settings” buttons, or handle exclusively through the Algolia.com dashboard.

The reason I say that, and I learned through personal experience, is that the “Push settings” buttons will push any customized settings, and then original defaults for non-customized settings, to the index and overwrite all of it. If Bob went in and made a change via the Dashboard, and then 2 hours later Joe clicked “push settings” after making some code-side adjustments, Bob’s changes just got lost.

There’s definitely benefits to doing all code based, like version control and consistency across dev environments, thus why it’s part of the offering, but just need to decide where to manage.

Once again, thanks for the continued support!
I did the test you mentioned and now know for sure my search page isn’t using Algolia whatsoever, even though the “Use Algolia with the native WordPress search template” setting is activated.

So, to make sure I understand, it’s my last doubt… if I wanted to use Algolia for it (search page, not autocomplete), I would have to use All Posts (searchabe_posts), correct?
So, to set it up to only return products, would I have to just mark “All Posts”, push settings, index that, and only then ON the Algolia dashboard, have it only consider the products?

I am just a bit lost on what would be the step by step process to have it only consider products if I am selecting All Posts.

I have also analized the code you mentioned (class-algolia-search.php) and it seems to me it doesn’t explicitly specify the use of the wp_searchable_posts index to intercept WordPress search queries (WP_Query). It doesn’t specify which Algolia index it’s querying. This decision is likely made in a different part of the plugin, perhaps?

• This reply was modified 10 months ago by alesstracker21.
• This reply was modified 10 months ago by alesstracker21.

If you’re making any settings changes to the “Autocomplete” settings page, even if just checking the “All Posts”, that’s only going to affect the Autocomplete functionality. The plugin just conveniently offers the ability to use the same index that’s used by the Search Page settings.

So, to set it up to only return products, would I have to just mark “All Posts”, push settings, index that, and only then ON the Algolia dashboard, have it only consider the products?

The “All Posts” Autocomplete option would include all searchable post types, not just products, unless you used some other filters we have in place to unset searchable post types.

Unless you’ve done some settings changes via code, there’d be no need to push the settings.

However the re-index button would do a bulk re-index of the determined searchable posts.

I have also analized the code you mentioned (class-algolia-search.php) and it seems to me it doesn’t explicitly specify the use of the wp_searchable_posts index to intercept WordPress search queries (WP_Query). It doesn’t specify which Algolia index it’s querying. This decision is likely made in a different part of the plugin, perhaps?

This method, from the file I referenced, is where we do the querying of Algolia and amend the WP_Query, using the pre_get_posts filter.

https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-search.php#L104-L199

Specifically line 148 is where we send the request to Algolia, and the $this->index will already be configured to be going to the wp_searchable_posts index.

The detail of you saying that despite the Search page setting being set to the “Use Algolia with the native WordPress search template” option, but apparently not working at all has me wondering if perhaps this $this->should_filter_query() method is returning false somehow. Perhaps because the query being checked isn’t the main query or an actual search query.

New question, are you wanting ALL of your Algolia functionality to only be considering the product post type? Meaning whether it’s autocomplete functionality or a search of any type, it should only be pooling from products? Or should the search still consider all other content types on the website, but still only products for the autocomplete?

Trying to figure out your intents so that I could potentially provide some extra guidance.

Thanks…yes…I only want it to pool from products both from the search page and from autocomplete.

I am just asking if I need to pick All Posts and then filter only products because you mention the plugin will only take wp_searchable_posts for WP_Query. I only have one index in Algolia and that is wp_posts_product.

Here are some captures of how it all looks like from my point of view.
https://ericksonstock.net/wp-content/uploads/2023/11/algoliahelp.png

The plugin does keep on saying I need to index All Posts.
It sounds counterproductive because I don’t want to search through All Posts, just Products.

Looking back at your original message at the top, you mention potential interest in our Pro Addon

I am remembering that we do have a setting for overriding with just the product post type.

Products only indexing: Makes only “product” post type searchable with Autocomplete and Instantsearch.

May be worth going that route if there’s still interest. If not, then we can still provide a quick code snippet to do the same, but there’s worth elsewhere in the Pro plugin to help out with a lot of things :D.

Regarding the indexes list detail, it sounds like you never actually did an indexing of the content, thus the wp_searchable_posts index was never created and populated. Thus why it wasn’t working so far despite the setting being in place. Sounds like just hesitation cause you didn’t want the rest to be included as well.

We do are interested in using the Pro Addon long term if it works, but right now I am in a development stage and need to check if it really could be a useful solution for us or we need to look elsewhere, and sadly I am not allowed by the company to make payments until I am sure.
So, I will index wp_searchable_posts, if the code snippet you mention for products only is available we would greatly appreciate it so we can try it for the time being at the dev stage, and if we can get it to work, I am sure to get back at you guys with the possibility of going Pro, I have read the other SEO and product tools you have available and they do seem very important.

Thanks a lot!

Since it uses already available filters in the free plugin, I don’t have much issue sharing a code snippet which we essentially use in the pro plugin as well. That version just gets UI available instead of users having to touch code.

function wpswa_support_only_products_indexed( $searchable_post_types ) {
	return [ 'product' => 'product' ];
}
add_filter( 'algolia_searchable_post_types', 'wpswa_support_only_products_indexed' );

Snippet above goes wherever you have that supports filters adding, like active theme functions.php or any custom plugins you may have going for your project.

Any lingering questions or issues here?

Hi Michael…truth is, it didnt work and I didnt want to keep on bothering you…I was still getting the non product results in the list.
It feels it would be much easier to be able to simply replace which index its using for general search. Straight up let me make only a wp_posts_product index and only target that. Because the way it is it forces me to index eveeerything, just to have to find a workaround to delete those undesired items anyway.

After a while I also realized that AJAX wasnt working either…
It returns 0 items, the response goes like:
{“count_posts”:0,”total_posts”:0,”page”:2,”num_pages”:1,”orderby”:”post__in”},”query_ids”:null}

So it seems I might to just have to import their API client and do it manually…

The thing with that index is that the Search Page/Instantsearch settings aren’t going to make use of wp_posts_product as that’s more or less exclusive with the Autocomplete integration. I’m not aware of any way to override the search functionality to use a different index outside of wp_searchable_posts.

Regarding AJAX, not sure how well/easily 3rd party AJAX integration will go with the WP Search with Algolia usage, however I wager there’s at least some better chance with it with regards to just “backend search” and not Instantsearch usage.

Any news or changes on this front @alesstracker21 or are we in a good spot?