autocomplete not working, instant search not working

Adding details from https://www.ads-software.com/support/topic/does-not-work-with-flatsome/ to below and will respond to all.

It doesn’t work with flatsome theme.

1. autocomplete/livesearch is not working. Basically the wordpress autocomplete is used instead of algolia.

2. If you try to implement “instant search” it looks totally broken out of box design wise. Not only that but you don’t get the “instant search”. You still have to press “enter” to get any result.

3. Obviously it’s not working with woocommerce not even in a trial mode. I didn’t buy the woocommerce/pro version because the standard version failed to work (see above).

Our website is “https://vip-pro.co.uk/”

Does Flatsome offer enhanced search functionality outside of what I’ll call standard search behavior? If yes, have you toggled those off so that there is fewer potential sources of conflict?

I’m looking at the output in the network tab of browser tools, and seeing errors with assets like this:

• https://wp-assets.vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css?ver=2.7.1
• https://wp-assets.vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/js/algoliasearch/dist/algoliasearch-lite.umd.js?ver=2.7.1
• https://wp-assets.vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/js/autocomplete.js/dist/autocomplete.min.js?ver=2.7.1
• https://wp-assets.vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/js/autocomplete-noconflict.js?ver=2.7.1
• https://wp-assets.vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/js/instantsearch.js/dist/instantsearch.production.min.js?ver=2.7.1

All appear to be returning 404 errors and “NS_ERROR_FAILURE” so things not working makes sense if the assets aren’t able to be loaded.

I am seeing some autocomplete-like behavior with the search field, but I suspect at the moment that that comes from Flatsome.

The biggest issues at least based on what I can presently see, is that the libraries aren’t being loaded, and at least with the search field, possible conflict with other autocomplete-like behavior.

As a sudden followup, https://vip-pro.co.uk/wp-content/plugins/wp-search-with-algolia/css/algolia-autocomplete.css?ver=2.7.1 appears to work. Note that there’s no wp-assets URL parameter at the start of this one.

It seems that the “offloading” plugin didn’t work properly so I had to disable it in order to make assets load.

Now instantsearch libraries are loading and autocomplete works as well. The only major issue is that the suggestions list are disappearing if the search box is not in focus. This is an annoying behaviour on mobile because the client may loose focus easily (i.e. press done) and the suggestions list disappears as well.

Another issues is that I expected to get a list of “did you mean x, y z?” suggestion on typos or anything like that.

Curious if the offloading part can be cleaned up to make work, so that you still get the benefits of everything. That’s a different support topic though.

Not sure if Instantsearch is presently being used. Doesn’t appear to be. So worst case, “integrate with native search” is being used here.

Regarding suggestions, I assume you’re referring to examples like at https://www.algolia.com/doc/guides/building-search-ui/ui-and-ux-patterns/query-suggestions/js/ ? or perhaps more at https://www.algolia.com/doc/ui-libraries/autocomplete/guides/adding-suggested-searches/ given the autocomplete detail?

We don’t have that in the out-of-box template at the moment, and details that need to be kept in mind is that our out-of-box version is still version 0.38.x.

We’re working on a way to get Autocomplete 1.x included as an option, but it will definitely be a bit more hands on with implementation too.

The biggest detail is that Autocomplete 1.x has users placing say a <div id="autocomplete"></div> where they want the search field to appear. Previously it could be attached to any <input name="s" ...></input> field.

I’ve disabled the instantsearch because it is totally broken. Now it’s using the native theme with algolia in background.

Basically if I want to use instantsearch I have to somehow modify the plugin myself and rebuild the whole page from scratch adding functionality such displaying the price, variations and Add to cart buttons/ajax functionality. I was hoping that the plugin will take advantage of the theme layout and functionality, not just throw search results from algolia on a clean canvas. Ideally it should use the native theme layout but process it instantly (i.e. on the frontend).

Correct me if I’m wrong.

Even so if I were to implement instantsearch I think it would better to use the current autocomplete box but like a fullscreen overlay so that the user doesn’t have to enter a first query and then enter and then search again “within the instant search box” in order to take advantage of instantsearch. Again the fact that the plugin doesn’t provide the item price and Add to cart links out of the box makes the use for ecommerce pointless.

• This reply was modified 8 months, 2 weeks ago by themihai.
• This reply was modified 8 months, 2 weeks ago by themihai.

Regarding the “totally broken” part, there’s chance that javascript errors are still being thrown, that we can help troubleshoot if needed.

Regarding template customization, we have a lot of documentation on that topic and how to do it safely from your active theme, so there’s nothing to do with extensive PLUGIN modification.

That said, you’re right in that there’s no easy or viable way to have the Instantsearch template inherit from the active theme’s search result template. It would be a separate customization and getting each part desired to display, to also be part of the indexed objects in Algolia. Thus relying on the native search would be the most appropriate route here.

Again the fact that the plugin doesn’t provide the item price and Add to cart links out of the box makes the use for ecommerce pointless.

We don’t believe this part to be true. It’s more that for people using WP Search with Algolia for eCommerce solutions, things need some extra refinement and work to meet each site’s needs. We strive to provide a solid entry point that covers the basics regardless of eCommerce usage, and help as much as we can to point to how to customize to meet that.

Woocommerce products, for example, do get indexed automatically with regards to instantsearch/native search because they’re registered as searchable, but specifics about the products aren’t included in that index, yes. We also made the decision to make a good amount of that as part of our Pro addon, as that’s a decent amount of extra considerations.

We’re definitely always looking for ways to help on the eCommerce product front with what gets indexed and how, including documentation on how to implement. A work in progress for sure.

>> We strive to provide a solid entry point that covers the basics regardless of eCommerce usage

Does the Pro addon provide an out of the box instant search solution for WooCommerce? I mean, do the products displayed have “add to cart” buttons and the price displayed?

At the moment, the Pro addon helps out with getting WooCommerce based data included in the indexed objects, but nothing with regards to template display.

That said, I know that I’ve been personally working on some template copies and extra code customizations to help provide a more eCommerce focused starting point, but it’s not ready quite yet for distribution.

Looking over what I have thus far, some of the customizations will include:

• Grid vs List display for Instantsearch results
• Price in result item display
• “View details” single product links
• Product attribute inclusion for potential facet-based widgets
• Woo based image sizes inclusion
• Price range slider widget

Among others I am not recalling off the top of my head. At least at the moment, this isn’t planned to be part of Pro, and would instead be a free thing once completed.

That sounds like a great list but for woocommerce I think “add to cart” links are mandatory for a majority of shops.

Another question: It looks like the sort option(i.e. by popularity or by price) is not working. Is it working on the Pro addon?

https://vip-pro.co.uk/?s=lash&post_type=product

I have “add to cart” link indexing as an enhancement idea in our internal notes, so it’s definitely something we want to include, but just haven’t yet. As said, work in progress to help provide as robust a potential solution as possible, while still being flexible enough to be customized for each shop’s individual needs.

Another question: It looks like the sort option(i.e. by popularity or by price) is not working. Is it working on the Pro addon?

If you’re referring to something with this with what’s already implemented on your site, for which I’m not seeing UI for, potentially not on the working front. Not a pro-only feature. The “integrate with native search” uses the pre_get_posts filter to intercept the query being made to send the search phrase to Algolia, and then return the IDs that it determined were best fit for the results, and those returned IDs are passed to the post__in parameter. That type of granular ordering control is really best for Instantsearch which has its own sortBy widget available that can be configured with index replicas. See: https://www.algolia.com/doc/api-reference/widgets/sort-by/js/

That said, I also know that we have a algolia_search_order_by filter, that can be used to set an orderby value before the query is being passed into the index’s search method. https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-search.php#L144

However I have not used this before, so I’m not completely sure what value should be passed in exactly. I do know it’s default null, and if NOT null, it will search in a replica that it will look up. By the looks of things, if you have a replica named “wp_searchable_posts_date_asc” with “date” being the attribute name, you’d want to pass in “date” to the filter. To conditionally change these in your filter callback, probably a case of checking for $_GET parameters to set the value returned.

For what it’s ultimately worth, the Pro addon is doing 3 primary things at this time.

1. Indexing extra WooCommerce-based product data based on chosen settings.
2. Enabling for checking on “noIndex” settings for content, in conjunction with various SEO plugins, based on chosen settings.
3. Enabling ability to have multisite installs push content from each site in their network, into a single index. Essentially allowing for global searching.

I purchased the pro plugin. I think there should be individual checkmarks for price and SKU.

I would like to display only the price (without the SKU) in the autocomplete list. Still, I would like the SKU indexed (for search purpose).

For what it’s worth, the Display product data option on the WooCommerce settings page can be used to toggle both off, but at that point it’s once again a matter of individual template editing to get just the parts back in the output.

That said, this is a quick modified version of the quick output we append. You’ll want to turn off the setting first so that you don’t get duplicate display, and then this can go wherever you have customizations set at.

function wds_algolia_support_hit_template_content_output() {
	ob_start();
?>
	<p>
		<# if ( data.price || data.sale_price ) { #>
			<?php esc_html_e( 'Price:', 'wp-search-with-algolia-pro' ); ?>
			<# if ( data.sale_price ) { #>
				<# if ( data.price ) { #>
				<s>data.price_formatted</s>
				<# } #>
				data.sale_price_formatted
			<# } #>
			<# if ( ! data.sale_price && data.price ) { #>
				data.price_formatted
				<# if ( data.max_price ) { #>
					- data.max_price_formatted
				<# } #>
			<# } #>
		<# } #>
	</p>
<?php
	echo ob_get_clean();
}
add_action( 'algolia_autocomplete_after_hit', 'wds_algolia_support_hit_template_content_output');
add_action( 'algolia_instantsearch_after_hit', 'wds_algolia_support_hit_template_content_output' );