How should magentos configurable products work with algolia


running algolia on magento 1.9.
We have a lot of configurable products that cover simple products which differ in most aspects. We use color and size as super attributes.
I would expect a behaviour similar to this:
I have a configurable product “Master” that has 4 child products, 2 sizes (small, big) times two colors (white, black). This give small white, small black, big white, big black. The configurable itself has neitehr color nor size.
Now I should be able to facet for, e.g. black, and get a meaningfull result.
This could be:
a.) Showing the configurable, but using data from any of the 2 black results (i.e. only one size&price is picked), which would link to the product page with the swatch for black preselected.
b.) Showing both black simple products next to each other, linking to the product page with the swatch for black and the size preselected.
Ideally I’d have a.) with a hint that multiple options are possible, and a switch to change bevhiour to b.) (aka: Show all variations).

Currently nothing of this works, It always shows the configurable, but I can’t even facet for a value only carried by in the simple product.
The simple product is set to be not visible in search, currently.

What am I doing wrong here, and what is actually the desired bevahiour (I know there is a config option regarding the product image, but this is all more than just about the image)?


Any chance to get that understood?

Certainly someone must have thought that through?

Hello Alex!

I’m super sorry for the late answer on this one!
Actually this should work as you describe in variant A.

In this case, only one record is indexed - the configurable product. And attributes size and color should have values [small, big] and [white, black]. I just tested it and it works OK.

Could you send me a screenshot of your configuration? I don’t get why those attributes are not indexed at all on your side :confused:

Thanks for the feedback.
I think something is missing in the logic here.
If I check the index, the super attributes configurable_color is indexed ok-ish:
“configurable_color”: [ “bianco”,“nero”],
configurable_size is not indexed at all.
However, I still don’t get my head around how this is supposed to work in the end. How do you know, which thumbnail to show for bianco or nero? The index record has only one. It does have all the sku’s of the child products, though.Same for all the other attributes (e.g. price, short description etc) that are shown on search result page.
This get’s more complex as you’d need to also store the other potential facets. Say I have a length attribute in my products.
The “big” simple products might have length=1000, the small ones length=100. I would expect that when I filter my search, I get the correpsponding response (or at least in both cases find the configurable). However, the algoila index only stores the value from the configurable product.
My config, uh, that’s quite some piece of data, try or .


To elaborate why my size attribute is not in the index for faceting:
People use all kinds of weird namings for sizes. Therefore we have a search size attribute (options: very small, small, average, large, very large) plus length/width/etc attributes that detail the sizes. The super attribute configurable_size is only used on the product page to pick a size by name (that could be “Magnum”, or “Mini” or anything).
I could obvisouly get the configurable_size attribute into algolia, but this still doesn’t solve the issue how you do the mapping: User selects length=1000, pick a simple product with that property, update the result with values (image, description, price) from this product.

@jan.petr Ping
We are going live soon and now in the process of upgrading Algolia Plan, but this is still blocking

Hello Alex,

I’m super sorry for the late answer.

The way how it should work is that attributes should be overridden by value from children products.

Let’s say you have configurable product which has 2 child products with different colours and size.

The indexed record should look like this:

color: ['color_from_simple_product1', 'color_from_simple_product2'],
size: ['size_from_simple_product1', 'size_from_simple_product2']

Then when you refine the extension is currently not able to disable corresponding price / description / name if it differs in child products. It’ll always display the value from configurable product.

The only thing it could display today is different image for each color, but it has to be indexed in color attribute. Then the extension is able to pick up the color from search query or filter. This feature was introduced in 1.11.0 version of Magento 1 extension.

Would that work for you?
Is your data indexed differently?

Hi Jan,
thanks. No, this is not what is happening. I’ll debug my way through this to see why.
Won’t that blow up our record size as well? When I have say 20 child products, my configurable product algolia entry will contain each attribute 20 times (i.e. one per child)? Not an issue if they differ just in color&size, but if it is others (say, description) looks problematic.


Ok, getting there. Documenting this on the go for anyone coming from google:

First, I learned you have hard-configured the color attribute to color. Fair enough.
Then, I see you only index the child products value if the parent products value is unset. Not sure if I was aware of this (Is that documented?). We tend to put a “sane” default into the parent product. I just changed the logic in ProductHelper.php:921 to always index child value for the moment.

Next, I found that you store the color (and all other attributes) as described above as array in the index, but in order to have the image url, there is an extra attribute images_data that will be used, with form like so:

images_data { blau : URL1 , grün : URL 2, schwarz URL 3 }

I’ve got that in my index now, fine.

Then, I saw that js/algoliasearch/internals/frontend/common.js has a transformHit function that is responsible for the magic. We do run our own transform function, so this wasn’t executed. I have added the call back to the algolia code to our modification. Again, I might have overlooked that this is required in the docs.

Then I realized the images_data attribute is not in the index query results. I can’t actually see why it would be included there in the first place, so I have added that to our override of Algolia_Algoliasearch_Helper_Config:getAttributesToRetrieve

Tadaa. Feature is working.

However, this is not what we are after. As you have explained, only the image will switch, and also only if the user searches for color, not e.g., for size.

Having now went all the way into the source and back out, do you have any objections why the following won’t work:
a.) Index all child attribute values.
b.) don’t filter out duplicates (no array_unique in ProductHelper:963)
c.) on client side js, grab the correct child product based on current filters
d.) update hit according to values from child
e.) potentially think about a more cleverer de-duplication for child attribute values (i.e. not just drop the array_unique from b)

obviously c is the pain point, as I need to re-implement the faceting logic in JS. However, this would give me the ability to facet for other attributes than color AND also update price/description etc.

Hello Alex!

You’re completely right and I have to admit, there are gaps in documentation for the use-cases like yours where you re-implement transformHit method etc. It’s great you went through it and made it work!

About your proposition - I see one issue. To make it work at 100% of times you’d need to index completely all child products to have all differences you might want to display.

It can be done:

  1. As separate records - then you’d need to implement a filter logic to display only parent products and child products use only as “data holders”. This approach would mean you’d need use much more of records quota.
  2. Index child products in attribute what would mean the record would be too big and might not fit into Algolia index (20kb limit) and will cause a big traffic as the data will need to be transported from Algolia to a browser each time a user searches.

Do you see any way how to avoid that?

Hi Jan,
was distracted by other stuff (as always), but had to have a thought again.
I guess only straight forward way is approach 1. I will index all products separately. This will obviously blow up the record count, but this is the only clean approach. I have implemented a nice logic to show differences of child products on the product page (see, e.g. and select Produktvarianten). This basically does a diff on the attributes and only lists thoses in the table that differ among the children. As you can see, sometimes even the text fields/description field is different. Indexing that in one record would not work and quickly hit the 20kb I guess.
Also from an architectural approach, 1 record = 1 product seems to make sense.

I will then need to have some client side magic to merge the child products display-wise into the configurable. Should not be to hard. Products are automatically loaded iva infinite scroll. Only challenge I see is ranking: I’d need to make sure that all child products are returned in one go, I. e. not that there are 200 other products between them (otherwise I might miss some). Any Idea how I can get the ranking to always give me, ideally first the configurable than ALL matching children of that one?


Hello Alex (@alex1),

yes, that makes the most sense to index everything.

To always return the right product, you can use distinct query parameter: Grouping results | Algolia

You’ll need to assign the same attribute to all records which are related. For example configurable_id = XX and then you’ll be able to use attribute configurable_id as attribute for distinct. Algolia will return only 1 record from this group - always the most relevant one.

Does it make sense to you? Would that work?

Hi Jan (@jan.petr),

didn’t get what you want to achive first, but the brilliant tutorial at Item variations | Algolia got my head around what you are trying there! Good job!

This approach is less heavy for the client side UI. I won’t have access to the other results in this case, so I guess I’ll just store their amount in the object to give a hint to the user (i.e. “5 other colors, 3 other sizes available”).
I’ll see if I can try that out this week.

Hello sir,
I also using algolia filter in my magento store. I have a problem with configurable product like as discussed above.
Suppose I have a configurable product “Master” that has 3 child products, 2 sizes (small, big) times two colors (white, black). This give small-white, small-black, big-white. The configurable itself has neitehr color nor size.
But when I select big in size and black in color then also showing “Master” product in filter result. Which is not expected. Expected result is “master” product should not be shown.
So please can you help me how can I configure for correct result.

this is what we did:

  1. Observer on algolia_after_create_product_object that stores the color&size attributes of all children of a familiy and the parent sku in each child. This basically means a getParent->getChildren exercise (chache this!) on each child.
  2. Observer on algolia_before_products_collection_load that adds a filter to only return simple products (we currently don’t even index the configurables, though this is still under debate)
  3. Extension of Algolia_Algoliasearch_Helper_Config that overwrites getAttributesToRetrieve in order to add the attributes added in step 1.
  4. Our Algolia parameter-generation code [1] sets the attributes in step 1 as additional attributes
  5. Index setting has distinct filtering for parent attribute: { “distinct”: true, “attributeForDistinct”: “parent” }
  6. Hit template modified to show the number of colors/sizes and a popup with those.

Result is basically what you want to achive, check Garten- und Landschaftsbau The weirdo looking numbered icons next to the cart button are the available colors & sizes in the respective family. If anyone has a proper design to sort that, I’m more than welcome to hear about it.

The algolia way of using the backend to configure all those attribtues is not usable for us with just so many attributes. We have a small tool that generates the algolia attribute/facet configuration based on static information about some attributes and the normal properties (i.e. magento is_searchable etc) of them and stores all that in the database.

Hello sir, thanks for reply.
Sir, as per your suggestion, I think it is slowdown filter process. So can you explain me alternative solution. Because if we store data and apply it on filtered result than it will slowdown the result. So, can Algolia provide another way for this issue?

which filter process? you mean index query? Documentation says distinct does have an impact, but I currently can’t measure it, it is still as fast as always.

Hello sir, Thanks for reply.
But I think your solution is very crucial for large no. of attributes and more time consumptive. So, can I use any another way for solve this issue. Sir, can you share your code for reference?

the question of simple/configurable handling doesn’t depend on attribute count. Obviously when you have many super attributes, this doesn’t work like this, because we have hard-coded them. Still, this should be doable with a naming scheme.
In the meantime, we have extended the whole thing a bit further:
When the user doesn’t serach or facet (except for hand pinked attributes), we will return the configurable. If the user starts to drill deeper by faceting or searching, we switch to simple. Will provide a seperate post on this.
I can’t share code, sorry.