New Products occasionally not indexed automatically.

This happens when you add products with the WooCommerce API. The product is added, Relevanssi indexes it, and WooCommerce then adds custom fields like SKU. Relevanssi doesn’t see it, because it’s not there when Relevanssi indexes the post, but the post is indexed so “Index unindexed posts” doesn’t help.

This helps:

add_action(
  'woocommerce_new_product',
  function( $id ) {
    relevanssi_index_doc( $id, true, relevanssi_get_custom_fields(), true );
  }
);

This action hook runs after WooCommerce has created the product and makes Relevanssi index the complete product.

Hi @msaari,

I see. Therefore when importing products with WP All Import Pro, this action would take care of the rest of the custom fields to be indexed. Sounds nice. I’ve put that into my funcitons.php thanks!

Please allow me some time for my shop managers to test this, and then I’ll report back with any plausible further issues, or ideally mark the ticket as resolved.

Kind regards,
Konstantinos.

Hi,

I am returning here to report that at first it appeared like the issue had been resolved. Unfortunately, yesterday I had a new example of an indexed product variation. I did not order a manual index in order for you to be able to check this on your end if you need.

The product variation is created in the back end, and can be found on the WP search, but on the front end it can not be retrieved. The SKU is 1823847991244. The URL is https://bonitoshop.gr/

https://ibb.co/25tZRP5
https://ibb.co/zrr4QYC

Would you kindly check this and advise further?

Thank you,
Konstantinos.

How have you set up Relevanssi to handle the variations? By default, Relevanssi doesn’t do much with them. Do you index the variation SKUs for the main product or something else perhaps?

I’ve set it up like follows.

https://ibb.co/mhYZhyT

I’ve also unchecked the “Respect exclude_from_search” checkbox.

https://ibb.co/zFWBPvP

In WooCommerce, the variations are not meant to be accessed directly. Relevanssi can do it – and if you search with the Relevanssi admin search (Dashboard > Admin search), you should be able to find the variation – but WooCommerce themes generally restrict the search only to the product post type. This excludes the variations from the search. That’s why it’s usually better to index the variation SKUs for the main product.

Doesn’t that filter do the same work as enabling product_variation indexing, with the “Respect exclude_from_search” checkbox unchecked, and with the _sku value set in the custom fields to include in the index though?

If not, how do the two approaches differ?

No. It does not index the product_variation post type at all. It adds the variation SKU to the main product post. So, when you search for the variation SKU, it’s not the product_variation post that is returned but the product post, and WooCommerce doesn’t have any problems with that.

I got you! Effectively the product variation SKU gets associated with the product, and upon searching for the variation SKU the product gets returned. That is an acceptable behavior, and my team would be greatly satisfied if it can work like this.

I’m worried about the instances of product variation SKU which don’t get indexed automatically when created or imported through the WooCommerce API, like the example SKU I’ve shared.

Do I just need to apply the extra filter you shared in order to index the product variation SKUs automatically – and not having to worry about it again in the near future – or do I have to perform more configuration to address this? I would be happy to do anything that needs be done.

Please keep in consideration that we are very sporadically adding a new product manually. Usually we import an .xls file with the WP All Import Pro plugin (WC API). So we would need a solution that would work for both ways, with extra attention given to the latter.

Thank you again,
Konstantinos.

The woocommerce_new_product action is a good start, and it may be necessary to modify it so that when a variation is added, the parent product is reindexed.

add_action(
  'woocommerce_new_product',
  function( $id ) {
    if ( 'product_variation' === get_post_type( $id ) ) {
      $parent = get_post_parent( $id );
      relevanssi_index_doc( $parent, true, relevanssi_get_custom_fields(), true );
    } else {
      relevanssi_index_doc( $id, true, relevanssi_get_custom_fields(), true );
    }
  }
);

Something like this, perhaps.

Hi @msaari,

I have used the action you shared and it seemed to work okay, until this morning when I heard back from the shop manager on this 8445413309906 SKU, which has been imported about a week ago. Today they tried to search for it on the front end, and it is not being returned.

Do you have any additional info that could help maybe?

Thank you.

I would recommend adding logging to the functions.

add_action(
  'woocommerce_new_product',
  function( $id ) {
    if ( 'product_variation' === get_post_type( $id ) ) {
      $parent = get_post_parent( $id );
      $return = relevanssi_index_doc( $parent, true, relevanssi_get_custom_fields(), true );
      error_log( "Variation product $id parent $parent indexed with response $return" );
    } else {
      $return = relevanssi_index_doc( $id, true, relevanssi_get_custom_fields(), true );
      error_log( "Product $id indexed with response $return" );
    }
  }
);

That way you can see which product has been processed and what happened. If the indexing is successful, relevanssi_index_doc() will return a positive integer.

I have added it to the functions.php and enabled debugging. Let us wait for some useful information to appear in the log. I’ll return here soon with more information (I hope).

Hi @msaari,

Now that 5 days have elapsed, and we have uploaded new products, I can see there are more SKUs which are not being returned in the search, but I can’t find any useful piece of information in our debug.log to help me narrow down the problem.

Could I share the debug.log with you in some way other than pasting it here? I don’t want to risk disclosing any sensitive information in the public domain.

Thank you.

I’m afraid that goes beyond what I can offer to free version users.

If you look for the product ID (not the SKU) of the missing product in the debugging log, can you find it? Is there a row “Variation product 123 parent 456 indexed with response X” or “Product 123 indexed with response X” for the product ID? If there is, what is “X”?