Impalement Multiple Queries Search to the plugin

hey @terencetansm

Trying to make sure we’re following correctly, can you point to a place where they recommend that as an alternative? Perhaps one of their discourse threads where someone had a similar issue.

I think at the API/code level we kind of already do multiple queries, but I want to make sure we’re on the same page.

We’re also thinking you could potentially reduce down some of this, in regards to autocomplete, by perhaps using the “all posts” option listed at the top of that settings page, and that would make use of the “searchable_posts” index that also would get indexed when using the Search settings page.

We also have ways to remove specific content types from being indexed in case some are trickling in that you don’t want.

• This reply was modified 2 years, 4 months ago by Michael Beckwith.

Hi Michael,

Thank you for the quick reply.

To make sure I explained it correctly, please refer to the screenshot I captured from the API Logs here: https://tinyurl.com/2cecl7y3.

As you can see, every single character I key into the search bar will do a search in 3 different indices.

Then, I got the idea of Multiple Queries here: https://support.algolia.com/hc/en-us/articles/4406981829777-How-does-Algolia-count-records-and-operations-)

Here’s the screenshot of the paragraphs I am referring to: https://tinyurl.com/2yf6szao

Hope this clarifies my question.

As for using the All Posts option, do you mean to only select the all posts option and deselect any other options? Will that allow me to search for product categories or custom post types as well?

Thank you so much for advising.

Checking on most of this.

The “All posts” would only be for searchable posts. If you’re intentionally trying to include taxonomy terms, which it does appear to be the case, then that would still end up being separate indices to search through.

Been looking over this a little bit this evening, and I’m not going to say it’s impossible, but I think this is going to be some decent refactoring of our default autocomplete template.

Probably the biggest hurdle at the moment is that we admit that WP Search With Algolia ships with Autocomplete version 0.38, and we haven’t attempted upgrading everyone past version 1.x thus far. This is because they vastly refactored how they handle things.

You can see an upgrade guide for them at https://www.algolia.com/doc/ui-libraries/autocomplete/guides/upgrading/. A quick example of what we need to be careful about is https://www.algolia.com/doc/ui-libraries/autocomplete/guides/upgrading/#container where they went from an <input> container to just a div and they render the input for you. FWIW, we are aware of the lift to upgrade, and have an open issue over at https://github.com/WebDevStudios/wp-search-with-algolia/issues/232

I was able to confirm that the version of AlgoliaSearch library that we ship with, does have multipleQueries already.

For example I pasted this right after our var client = algoliasearch( ... ) line in the autocomplete.php file, and it showed 1 request against these three indexes specified:

const queries = [{
	indexName: 'wp_terms_category',
	query    : 'hello',
	params   : {
		hitsPerPage: 3
	}
}, {
	indexName: 'wp_terms_category',
	query    : 'hello',
	params   : {
		hitsPerPage: 3,
	}
}, {
	indexName: 'wp_searchable_posts',
	query    : 'hello',
	params   : {
		hitsPerPage: 3,
	}
}];
client.multipleQueries(queries).then(({results}) => {
	console.log(results);
});

The next big part that I’m seeing that we don’t have right by default for this would be our sources construction. We’re piecing just the sources to use, and passing in later to be used alongside the query value that gets calculated internally from what I see.

For the code above, we’d need to piece together the queries by specifing the index names to search in, as well as provide the query value ourselves, where we’d then get our response back. Then we need to render those in a template afterwards.

So, not impossible I must believe, but in terms of getting this done asap, it will probably be a case of overriding what we ship by default, and to various degrees overhauling our default autocomplete template to make it work with modern Autocomplete versions.

Hi Michael,

Thank you so much for your detailed explanation and went further to check the possibility.

Do you think it will be in the team’s plan to include this in future plugin updates?

Thank you!

We’re going to need to more sooner than later, but we’re still figuring out how to best go about this for the larger plugin user base. I have to believe most people have customized their templates instead of leaving in the default form, so we’ll also need to provide an upgrade guide.

That said, I know I’ve been working on a client project where we’ve done the Autocomplete upgrade, so I hope I can get an initial guide out of that.

I don’t have any hard promise timelines though.

@michael Beckwith:

Because of plugin API is being called multiple times for each keystroke (on separate indexes – screenshots below) which indicates that there is an issue with the code in the plugin.

https://prnt.sc/aDzM6AHbFcKH

For what it’s worth, I think that’s actually the expected behavior when not using mulit-index search and if/when queuing up many indexes to be searched.

So, we know that we need to get Autocomplete 0.38 upgraded especially if we want to aid in helping with this topic. We also have 5000+ active installs to potentially worry about, as opposed to one. We’re definitely not forgetting this need, by any means, but we need to figure out our approach so that it’s as minimally breaking as possible.

As some followup, I have a branch in the works that upgrades our Autocomplete template to be compatible with version 1.x but it’s also definitely going to be a big update process for users as well.

One major thing to note is that Autocomplete 1.x expects to be attached to a <div id="autocomplete"></div> markup however the ID isn’t hardcoded, and can be whatever you want. Previously we were able to attach ourselves by searching for an input that had name="s" due to how WP has default search functionality.