Developer forum

If your product list only shows main products, it cannot show only options that are in stock (because it is the stock level from the main product that are used as criteria).

If your product list shows all variants, you can filter out the options that are not in stock (because it is the stock level from the variant product that are used as criteria).

Both examples are only valid for products in stock at the time of indexing. If a variant goes out of stock and you do not re-index, you would still have a problem with the facets (Products not in stock are removed by the rendering).

If you want to show only main products in the product list, and only variant options for variants in stock, you need 2 searches - one for the main search, and one just to return you the facet options for the variants. Then in the product list, instead of having facets on your main search, you load the facet options from the secondary search using JSON/partial HTML loading.

BR Nicolai

Thanks Nicolai,

I am trying to replace the regular listing of Products (only with Main Products) based on the old index.

In the previous index, we had the info in the same place. I assumed we gonna have it here as well.

In my project (MBT) I already have to use one query for each Product Category for each shop.

This scenario means that I have to duplicate the current number of queries in order to be able to support the Faceted search.

It's a bit complicated for a supposedly standard feature.

Should I assume this is a work-around until the New Index will support this easier?

Thanks,

Adrian

Hi Adrian

Yes, this is the only option for now.

The reason for the difference is that the old index has a lot of ecommerce logic built into its searches (that makes it slower) - the new index is much more generic, also suitable for other types of data, that makes it much more powerful.

In the new index variants and main products have each own Lucene documents. That gives some new possibilities, like showing only one dimension of variants in the product list, but it also has some drawbacks like the example you mention. We will close those gaps by adding more information on the documents.

I think what you need is another version of the product index, where all data for one product and its variants is collected in one document.

BR Nicolai

Hi Nicolai,

I understand the benefits and the drawbacks.

Another version of the Product Index means a new Schema? Like the ones you are providing out of the box?

Is there any documentation on how to create a new schema?

Thanks,

Adrian

One other issue I am facing but could not find solution for it is scheduling the build for the index.

Is there something I am missing on the settings?

Thanks,

Adrian

Hi Adrian

Yes, a new schema extender and product index builder. There is some documentation in the indexing documentation. Attached is our implementations of the schema extender and product index builders for ecommerce - you can change those if you want.

In the newest versions of DW you can add a task in the repository overview - see dump. In older versions you have to create a scheduled task manually.

BR Nicolai

Hi Nicolai,

Got it. How do I define it Manually? Is it defined in the documentation?

Thanks,
Adrian