TL; DR: Is there any reason why the simple products associated to a configurable product have to be in the same attribute set as the configurable product itself? I mean, is there any technical reason? I know the "common sense" reason. If you sell a pair of shoes then all the versions depending on color and size have to be shoes also.
Long version: I had a task to "merge" some configurable products. I mean from 2 or more to make only one. I didn't want to do them manually because of the amount of products and I didn't want to go through $product->load(..)->set...()->save() because of the amount of time it took to run the script. So I short-circuited the process because I was sure that none of the simple products overlapped. There was a unique combination of size and color. I did this:

    ->saveProducts($mainConfigrableProduct, $simpleProductIds);

where $simpleProductIds is an array of all simple product ids associated all to the configurable products that need to be merged.
This worked perfectly for most of the products, but there were a few that has issues.
If I called

$productIds = $product->getTypeInstance()->getUsedProductIds() 

I would get all the simple product ids, but in the backend only a few of them appeared. After digging for some time I found out that the only ones that were shown were the ones in the same attribute set as the configurable product. The other attribute set is very similar to the first one, just some minor differences but it contains the configurable attributes (size and color).
And now the strange thing. In the frontend I expected to see either all the products ($productIds in the code above) or only the products in the same attribute set. Well there was something between.

  • 20 associated product ids - 5 sizes, 4 colors
  • 10 associated products in the backend - 5 sizes, 2 colors - the other 2 colors (10 products) were in a different attribute set
  • 15 combinations in the frontend - 5 sizes 3 colors (???)

I was able to solve the issue by changing the attribute set for the products that didn't appear, but I'm still puzzled.

Note: Don't try this at home. Or you can try it at home but not on a live server.


After asking around this are the reasons I've got. Hope its satisfying for you, even though its probably what you expected.

  1. The adminhtml interface was made with the intention to make it hard for merchants to totally screw up.

For that reason many features that are provided by Magento as a Framework are not possible through the user interface.
The reason why only products in the same attribute set are selectable as associated simple products for configurables is because that's what was in the specs.
As you said, it kind of makes sense that way.

  1. Another reasons is thinking of the purpose of attribute sets. One of the reasons they exist is to reduce the number of attributes and options that have to be loaded and processed during a request. Applying this thinking to configurables makes sense, since it is a relatively resource expensive product type.

Because the backend was built in that way, the frontend logic for configurable never was expected to deal with simple products from different attribute sets.
Thats why the restrictions aren't implemented completely there.

Probably it would be easy to make configurables work with simples from different attribute sets. It just wasn't intended that way.

I didn't ask further and didn't look myself to see what code interaction exactly produced the strange result on the frontend. Probably its not important, since if I understood correctly you where asking for the reasoning behind the decision to exclude simple products from attribute sets different to the configurable, not the code explanation.

  • Thanks Vinai. I was hoping deep in my mind for a "mind blowing" reason. It would have been fun :). This is a satisfactory explanation. As for the "strange result", there is no need to dig in the code. I will do that when I will get bored. I still have the DB dump and the way to reproduce the same result. Most probably is because I was screwing directly in the database. I will post a result when/if I will find one. – Marius Oct 19 '13 at 16:03
  • 2
    Tsk tsk, @Marius - don't touch the db ;) – philwinkle Oct 19 '13 at 16:04
  • 4
    @philwinkle. I know, I know, the universe will explode if do it. What can I say? I like to live dangerously. In my defense, I said "don't try this on a live server". – Marius Oct 19 '13 at 16:07
  • 1
    Still waiting to get my mind blown, too... :) – Vinai Oct 19 '13 at 17:30

We use an extension called RapidFlow by Unirgy ( which I can't recommend highly enough ) for import and export. One of the features in the Pro version allows changing of attribute sets. Another is creation of products via CSV import. Occasionally we create new simple products for configurables, and sometimes by accident those simple products have different attribute sets than their parents.

Rapidflow will happily import these products, and change attribute sets. We tend not happy with the results. Configurable products that are configured by attributes outside of their attribute set fail to render in the product admin and must be repaired. If we don't change the attribute set of the parent, as you have noted, the children simply fail to be properly associated with their parent. They exist as Magento entities, can be edited, but will not appear as children on the front end product page, or the configurable parent's associated product list.

So, from a purely technical stand point, it is possible for simple products to be in a different attribute set than their parent. But as this behavior is not supported, even in EE, and so Occam's Razor says that when they were designing Magento the Varien devs didn't see the need.

  • 1
    Thanks for the response (and extension recommendation) but this does not answer my question. I said that I've managed to resolve my issue by changing the database directly. I know I shouldn't do that but I had a good knowledge of what I was doing - and a database backup :). I was just curious to why this restriction exists. As far as "Varien devs didn't see the need" I have a feeling you are wrong. If you implement a restriction it must be a reason for it. – Marius Oct 17 '13 at 8:08

Your Answer

