Site icon WebDevStudios

Integrating WP Search with Algolia: Settings and Configurations for WooCommerce

Michael Beckwith

Ever since WebDevStudios forked the WP Search with Algolia (WPSwA) plugin and took over support and maintenance, we have received requests regarding extra support when used with WooCommerce. Our product development team provides this with the premium add-on WP Search with Algolia Pro.

However, our stance has been that due to complexities with WooCommerce, we are not planning to add any official support to the free plugin WP Search with Algolia. That does not mean there is zero ability for the plugins to work together; it’s just that integration is up to individual site owners to adjust to their own needs.

This has left a proverbial hole in our free Algolia support. Going into the end of 2021 and the beginning of 2022, I was assigned tasks regarding integrating WPSwA with a WooCommerce-based website.

At the time, I was still saying, “We don’t have official support for WooCommerce.” Yet, I was chomping at the bit for this opportunity and hands-on experience.

There were definitely hiccups and interesting challenges along the way, but I feel the gained knowledge has proved invaluable. I want to discuss with you here how I handled various parts of what I learned, including WP Search with Algolia’s settings and configurations for WooCommerce.

At the time of this writing, we are using version 2.2.0 of the plugin, available on both WordPress.org and GitHub. Also, for these examples, we are focused on simple products in WooCommerce. Other product types will need more exploration and work.

I am covering our overall setup in three parts:

  1. Settings and index management with WPSwA
  2. Template customization
  3. Facet widget customization

Today’s post covers part one only—WP Search with Algolia settings and configurations with WooCommerce.

After all three parts are addressed, we will provide a plugin version holding all the code presented in these blog posts. We encourage modifying this plugin version to meet your own fine-tuned needs For the sake of brevity, I assume you already have an Algolia account and WPSwA setup, including Application IDs and various API keys.

WP Search with Algolia Settings and Index Management for WooCommerce

Settings Management

It is definitely possible to control and manage indices configuration in the Algolia.com dashboard. Those settings are reflected on your website when using search.

WPSwA, on the other hand, is also set up to manage these settings. This is done via code rather than UI, using WordPress’ extensive hooks API. Whenever you see UI or instructions to “Push Settings,” the settings provided via custom code are pushed to your Algolia instance.

Controlling the settings via custom code may sound odd, but it is actually extremely handy. It allows not only version control of the configurations, but also allows for consistently deploying those settings across various indices and between development sites. All you need to do is trigger some UI and everything is configured for you.

We are providing configuration code to help with WooCommerce integration, but if you prefer managing it via the dashboard, remove that code and avoid the “Push Settings” UI.

Index Management

When I say index management, what I mean is managing what information gets pushed when a given product object is updated or removed. Some parts are already handled for you, while others will need manually added and a re-index run.

Not every change around index management requires settings deployment, but does need a re-index of the content. We let you know when each is needed.

For index management, we’re focusing on two indexes specifically. The first one is the posts_product index and the second is the searchable_posts index.

When you enable individual content types on the Autocomplete settings page and click to index that content type, a corresponding table is added to your Algolia instance. In the case of our WooCommerce intent, we want the “Products” row which creates the index of “posts_product.”

The searchable_posts index is a bit more encompassing with less to click. It indexes all of the content types that are considered searchable by WordPress.

If you have registered your own post type before, you may recall the “Show In Search” option. This is the same.

Any time that we’re adding information to the products in our indexes, we use the following two filters available to us in the WPSwA plugin:

algolia_post_product_shared_attributes
algolia_searchable_post_product_shared_attributes

Meanwhile, whenever we’re modifying the settings for the related indices, we use the following filters (also available in the WPSwA plugin):

algolia_posts_product_index_settings
algolia_searchable_posts_index_settings

Note: the final version of supplied code is different compared to isolated snippets, but should have all parts covered by the post in the end.

SKUs

We’re starting with one of the most common questions I’ve seen regarding WooCommerce integration. How do we get a product’s SKU value indexed?

function add_product_data_to_autocomplete_and_instantsearch( $shared_attributes, $post ) {
	$product = wc_get_product( $post );

	if ( ! $product ) {
		return $shared_attributes;
	}

	// We need to make sure the SKU is a part of each index, in order to search by it.
	$shared_attributes['sku'] = $product->get_sku();

	return $shared_attributes;
}
add_filter( 'algolia_post_product_shared_attributes', __NAMESPACE__ . 'add_product_data_to_autocomplete_and_instantsearch', 10, 2 );
add_filter( 'algolia_searchable_post_product_shared_attributes', __NAMESPACE__ . 'add_product_data_to_autocomplete_and_instantsearch', 10, 2 );

First, we hook into the shared attributes data where the attributes to be indexed are set and data included. This hooks in before the final data is sent to Algolia, and is a perfect spot for us to include extra information.

In the code above, we are utilizing the passed-in $post object to retrieve a WooCommerce product object. If we have a found product, we use the get_sku() method to retrieve and set the value in a new “sku” index. Once done, we return the updated $shared_attributes array.

Since we changed what gets indexed on product objects, we need to run a sync on both the Autocomplete and Search pages. Having the SKU on both will be important in a moment.

Adding the Ability to Search by SKU

Next, we need to amend the settings for our posts_product and searchable_posts configurations.

function amend_posts_products_and_searchable_settings( $settings ) {

	$settings['searchableAttributes'] = 'unordered(sku)';

	$settings['disableTypoToleranceOnAttributes'][] = 'sku';
	$settings['disablePrefixOnAttributes'][] = 'sku';

	return $settings;
}
add_filter( 'algolia_posts_product_index_settings', __NAMESPACE__ . 'amend_posts_products_and_searchable_settings' );
add_filter( 'algolia_searchable_posts_index_settings', __NAMESPACE__ . 'amend_posts_products_and_searchable_settings' );

Here, we are adding the “sku” attribute into our list of attributes considered searchable, and telling Algolia they should be unordered.

We are also disabling typo tolerance for the “sku” attribute. This means that a sku of “40025” won’t be included when you typed “40026.”

Lastly, we are also adding the “sku” attribute to the list to disable prefix searching on. That means if you were to type “400,” neither “40025” nor “40026” are considered as a result.

All of this helps ensure that SKUs can be searched exactly, both when showing suggestions in the search bar, as well as with the final results themselves.

Product visibility and availability

Product visibility

Let’s say you’ve gone through the effort to manage your merchandise. Sometimes, you want to remove a product’s catalog visibility on the frontend.

For this, we’re going to mark the product as should NOT be indexed, if its WooCommerce visibility is marked as “hidden” or “catalog” only. We will be making use of these available filters to achieve this.

The filters are passed a boolean value for the current determined status of if it should be indexed or not, and then a post object itself.

algolia_should_index_post
algolia_should_index_searchable_post

function exclude_visibility_and_outofstock_products( $should_index, $post ) {

	if ( false === $should_index ) {
		return $should_index;
	}

	$product = wc_get_product( $post->ID );
	if ( ! $product ) {
		return $should_index;
	}

	$product_visibility = $product->get_catalog_visibility();
	if ( in_array( $product_visibility, [ 'catalog', 'hidden' ] ) ) {
		$should_index = false;
	}

	return $should_index;
}

Here, we return early if it’s already been determined elsewhere that it should not be indexed. Why do extra work?

If the product is still considered indexable, we move to retrieve a product object and check its current visibility value. If that visibility is “hidden” or “catalog,” then we set $should_index to false and return our filtered value.

This post would not be indexed and WPSwA would move on to the next item.

Product Availability

Perhaps you don’t want to show products that are presently out of stock or are on backorder. Users should only see what they can buy now. Using the same function above, we can add a few more checks to potentially prevent the indexing of a given product.

function exclude_visibility_and_outofstock_products( $should_index, $post ) {

...

	$product_visibility = $product->get_catalog_visibility();
	if ( in_array( $product_visibility, [ 'catalog', 'hidden' ] ) ) {
		$should_index = false;
	}

	$stock_status = $product->get_stock_status();
	$statuses_to_retain_indexability = [ 'instock' ];
	if ( ! in_array( $stock_status, $statuses_to_retain_indexability ) ) {
		$should_index = false;
	}

	return $should_index;
}

In this amended code, we are utilizing the $product object to get the stock status. By default, WooCommerce stores either “in stock,” “outofstock,” or “onbackorder.”

For our purposes here, we only want to show items in stock. If the found status is not in our array, set $should_index to false and return the final value.

Bonus points: How could this information be used in conjunction with Yoast SEO content settings?

Extra product information

When it comes to your products, the SKUs don’t have to be the only thing you index. Any detail about the product that you can fetch can be included as part of it’s indexed object.

For the sake of the rest of this post, I’m going to add both the price (with currency symbol) and short description to my products. Don’t forget to re-index!

$product = wc_get_product( $post );

if ( ! $product ) {
return $shared_attributes;
}

...

$currency_symbol = html_entity_decode( get_woocommerce_currency_symbol() );
$shared_attributes['price'] = $currency_symbol . $product->get_price();
$shared_attributes['short_desc'] = $product->get_short_description();

return $shared_attributes;

Conclusion

Whew, we have accomplished a fair amount here. We have successfully integrated WP Search with Algolia’s settings and configurations for WooCommerce. Additionally, we marked some of our attributes as being searchable and added a fair bit of product information to our products in Algolia.

Lastly, we also configured our install to control whether or not a product should even get indexed, based on catalog visibility or current availability. Next time, we will get into how to make use of this information when performing a search and how to customize the display of everything.

If you’re ready to have WP Search with Algolia integrated with specialized settings on your WooCommerce website, contact WebDevStudios.

Exit mobile version