Search: Include Support for WooCommerce Variable Products

[donalirl]

Impacted plugin

Jetpack

Steps to Reproduce

On a site with Jetpack Search + WooCommerce:

1. Create a variable product with at least one variation.
2. Add an SKU to the variation.
3. Search for variation using its SKU
4. Search for the variation using the variation's name

A clear and concise description of what you expected to happen.

I expected the variable product to appear in search results.

What actually happened

The search returned no results. You can successfully search for the parent product (i.e. the title of the main product, not its variations) but searching for specific variations does not return a result.

Other information

#4453600-zen

Browser

Other / Not applicable

[bluefuton]

cc @gibrown @robfelty 🙂 Would it be possible to add variable products to the index?

[gibrown]

Added to our active project list. It needs a bit of experimentation I think to figure out how we want to index them and whether we need a separate record for each variation or not. We should probably review the priority of these.

[CodeAllNightNDay]

@gibrown Hi there. I wanted to check if there were any updates on this that I could give to the user aside that were working on it.

#4554949-zen

Thanks!

[gibrown]

@CodeAllNightNDay there are not unfortunately. I'll nudge it into "Next" but we still have a fair bit of uncertainty. I highly doubt we'll get it done by the end of the year.

[tameryldz]

Etkilenen eklenti

Jet paketi

Üreme Adımları

Jetpack Search + WooCommerce içeren bir sitede:

1. En az bir varyasyona sahip değişken bir ürün oluşturun.
2. Varyasyona bir SKU ekleyin.
3. SKU'sunu kullanarak varyasyon arayın
4. Varyasyonun adını kullanarak varyasyonu arayın

Ne olmasını beklediğinizin açık ve özlü bir açıklaması.

Değişken ürünün arama sonuçlarında görünmesini bekliyordum.

Gerçekte ne oldu

Arama sonuç döndürmedi. Ana ürünü başarılı bir şekilde arayabilirsiniz (yani varyasyonlarını değil ana ürünün başlığını) ancak belirli varyasyonları aramak bir sonuç döndürmez.

Diğer bilgiler

#4453600-zen

Tarayıcı

Other / Not applicable

[tameryldz]

https://join.skype.com/Ebdf7Wh4ffX0

[mriyazuddin]

Hey folks, any update on this? I have a user eagerly waiting for a resolution.

4554949-zd

[bluefuton]

@mriyazuddin as @gibrown mentioned above, "I highly doubt we'll get it done by the end of the year." It's on our radar for the next few months but we won't be able to solve it for the user immediately.

[upwardmomentum84]

Reported here 37696676-hc

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 4453600-zen
• [ ] 4554949-zen

[robfelty]

Thanks for the update. The Jetpack Search team is now focusing on Jetpack Stats, and the Jetpack data team is currently focused on Elasticsearch upgrades for the next several months. That means it is still unlikely to happen soon unfortunately.

[zwiesman31]

@jartes (not sure if you're the right person to tag), but this is a big issue for WooCommerce sites trying to find a scalable search option. We (Pressable) are starting to run into this, and with A8C's directive for Pressable to focus on the mid-market and more Woo sites, it would be REALLY awesome to get this Woo Variable Product issue resolved asap. Any chance this can be prioritized?

[mdbitz]

Reviewed the underlying data on this and we have the full product_variant data in the WP.com Cache Site via Jetpack Sync.

The issue is that we are explicitly skipping product_variation post types during indexing. (See line 1016 of wp-content/plugins/elasticsearch/indexing/wpes-lib/src/indices/jetpack-search-v7-post-doc-builder.php ). This will need to be adjusted so that variations have records in the jetpack-search index. Additional logic in the builder may need to be adjusted to ensure that the permalink and other attributes are set properly as well.

Note guid/permalink in the remote db are not the actual urls used by WooCommerce and so will need to be generated/filtered.

Ex. https://almost-limited-violin.jurassic.ninja/?post_type=product&p=14 Actual https://almost-limited-violin.jurassic.ninja/product/custom-hand-written-book/?attribute_subject=Dragon

cc @mreishus

[mreishus]

I've also found 2 other things stopping it in the example I set up. The product variation is getting these two post metas set in the shadow copy:

    {
        "meta_id": "126",
        "post_id": "15",
        "meta_key": "_jetpack_post_is_public",
        "meta_value": ""
    },
    {
        "meta_id": "127",
        "post_id": "15",
        "meta_key": "_jetpack_post_is_excluded_from_search",
        "meta_value": "1"
    },

Which trigger these two stops:

• fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Scyhtvaf%2Srynfgvpfrnepu%2Svaqrkvat%2Sjcrf%2Qyvo%2Sfep%2Svaqvprf%2Swrgcnpx%2Qfrnepu%2Qi7%2Qcbfg%2Qqbp%2Qohvyqre.cuc%3Sn%3Qgehr%26e%3Qn1921o19%26u%3Q1016%231069-og
• fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Scyhtvaf%2Srynfgvpfrnepu%2Svaqrkvat%2Sjcrf%2Qyvo%2Sfep%2Svaqvprf%2Swrgcnpx%2Qfrnepu%2Qi7%2Qcbfg%2Qqbp%2Qohvyqre.cuc%3Sn%3Qgehr%26e%3Qn1921o19%26u%3Q1016%231074-og

Possibly set by this:

• fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Szh%2Qcyhtvaf%2Swrgcnpx%2Sflap%2Spynff.wrgcnpx%2Qflap%2Qfunqbj%2Qercyvpnfgber.cuc%3Se%3Q192o1914%26e%232247%2Q2251-og
• fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Szh%2Qcyhtvaf%2Swrgcnpx%2Sflap%2Spynff.wrgcnpx%2Qflap%2Qfunqbj%2Qercyvpnfgber.cuc%3Se%3Q192o1914%26e%232256-og

[mreishus]

It seems that when woocommerce registers the product_variation post type, it sets public to false:

		register_post_type(
			'product_variation',
			apply_filters(
				'woocommerce_register_post_type_product_variation',
				array(
					'label'           => __( 'Variations', 'woocommerce' ),
					'public'          => false,
					'hierarchical'    => false,
					'supports'        => false,
					'capability_type' => 'product',
					'rewrite'         => false,
				)
			)
		);

This dates back to 2013 in this commit.

This means exclude_from_search gets set to true (since it's not provided, it defaults to the opposite of public).

wp eval 'var_dump( get_post_type_object( "product" )->exclude_from_search );'
bool(false)
 wp eval 'var_dump( get_post_type_object( "product_variation" )->exclude_from_search );'
bool(true)

That in turn means the replica shadowstore sets _jetpack_post_is_excluded_from_search meta to 1 and _jetpack_post_is_public meta to empty string.

Edit: I was able to add a workaround for this in one of the PRs.

[mreishus]

PRs:

• Add product variation attributes to the cache site sync: 185272-ghe-Automattic/wpcom
• Jetpack sync - https://github.com/Automattic/jetpack/pull/43933
• Add product variations to the ES Builder: 185277-ghe-Automattic/wpcom

[gibrown]

I don't think that each product variation should be stored as a separate document in the search index. Mostly each variation is a different SKU and different attributes (e.g. different color shirts). So in search you probably want a single ES doc but to combine the posts into a single document in a coherent way. We may need new fields for some of this that combine the different SKUs into a single field that can get matched against. It also brings up questions about if we should fix this bug around partial matches: https://github.com/Automattic/jetpack/issues/38938. That's part of why there are multiple bugs organized into this project: https://github.com/Automattic/jetpack-roadmap/issues/2283

[mreishus]

If they were combined into a single document, would there be difficulty bringing the user to the variation that matched their search? With different documents, we could set the individual link like so:

• Clicking on the red shirt brings you to /product/productshirt/?attribute_size=S&attribute_color=Red, which prefills the variation selections.

If they were lumped into one document, then we could show the parent "ProductShirt" entry when they searched for the red shirt SKU or description. But could we indicate to the user which variation matched? Or is that what we'd be giving up in as a tradeoff to have fewer documents in the search?

[mreishus]

Here's a separate approach for putting the SKUs and Description in the main document - 185530-ghe-Automattic/wpcom - please check it out @gibrown