How to model a large catalogue with many different types of products and attributes


Hi guys!

I am an experienced full-stack web dev, but new to PimCore. I’m organising a large catalogue of many types of items in PimCore and have looked through the documentation many times, but I still don’t know how to tackle two basic issues I have organising my product data into classes. I hope some more experienced PimCore users or devs can shine some light on this.

Issue 1: how to model general product attributes that apply to all products in the catalogue.

All of the products in my catalogue will have a name and a description, so I thought it made sense to make a Product class that has these fields and make all of my specific product classes subclasses of that Product class so I wouldn’t have to add name and description fields to each subclass individually.

I tried to set this up, but in the object editor of the specific subclass the layout fields that I added to the generic Product superclass don’t show up. Am I missing something here? Should my approach actually work? If not, what would be the PimCore approach to modelling this?

Issue 2: how best to model products with multiple options, ie. variants over more than one dimension.

For example, T-shirts with both color and size options (let’s say, 3 colors and 3 sizes for a total of 9 variants). I would want to create one single T-shirt product in the object tree and then add 3 color options and 3 size options for an (automatic) total of 9 variants. I want the T-shirt to appear as a single product in the e-commerce frontend and let the end customer determine the value of both options.

I am wondering if it is at all possible to do this in a way that allows me to specify the 3 color options and the 3 sizes independently of each other. The examples I find in the documentation all show me a fully expanded object tree covering all options (eg., 1 T-shirt object, with 3 subobjects for each size, each with 3 subobjects for each color in that size). Although data inheritance helps with the management of this info, a change in the available colors would still have to be made once for every size option. I can’t imagine there is not a better way to set up object variants in multiple dimensions in PimCore, but days of searching have led me nowhere. Am I missing something here? Or does PimCore actually force you to create objects/variants for every combination of product options? If not, what would be the PimCore approach to modelling this?

I hope someone with a little experience in this field is willing to shed some light on these two issues. Thank you so much!!



I think you can use field collections for that?


I think the examples here are for the same use case as yours?


Hey Andrew, thanks a lot for your input!

With regard to Issue 1: would you be so kind to explain in a bit more detail how you would use FieldCollections to solve the issue of shared fields between objects of different classes? I’m not convinced it is the way to go, but maybe that’s just because I don’t know how.

As far as I can see, to solve my question specifically that approach would involve:

  • creating a ‘basic fields’ FieldCollection containing name and description
  • adding that FieldCollection to every product class I make

So that would still involve adding the basic fields to every specific class, just in a cleaner way. Also, FieldCollections don’t support inheritance, so that would break the logic of variants later on. I would suspect there to be another way to do this.

Is there no way to define the basic fields once in a base class, and then have every class be a subclass of that baseclass to take advantage of the defined data and layout fields? It would be great if you could explain briefly how to use FieldCollections to solve the problem.

With regard to Issue 2:

  • The page about Inheritance gives an example where only the property color changes in subproducts, and all variants are added manually
  • The page about Variants gives an example where only the property size changes in subproducts, and are all variants are also added manually

I understand I can apply the same approach to multiple attributes by adding variants for all combinations of all possible attribute values manually in the object tree, making use of data inheritance to lessen the management burden. But as explained in my question, I don’t want to manually add 9 variants if I have 2 attributes with 3 values each. I want to add 1 Product + 2 attributes with 3 values each, independently of each other. In my specific case the numbers of attributes and values are much higher, so the manual approach would be unmanageable. I am not sure this is possible with PimCore, but I would imagine so. What is your view on this?

Thanks again!



The way Pimcore classes are defined it doesn’t allow you to do so, because the design includes both layout and properties. I’m guessing that’s why the Data inheritance option only works when using the same class. (someone correct me if I’m wrong).

I don’t think it’s right to think of Pimcore classes as object orientated classes.

You can use Classification store instead of Field collections. Classification store allows inheritance, but through Data inheritance (so the objects have to be of the same class).


As far as I know there is nothing automatic available that will generate combinations for you.

For a project we did where a lot of variants were involved we added a “Generate variants” button. The administrator would on a product instance define the available options, in your case available colors and sizes, and then click the “Generate variants” button triggering a generation of variants.

Hope this give you some options on how to do things.


That is very helpful, thanks a lot, Andrew!

If anyone else has examples of how they tackled these issues that’d be very interesting to hear as well.


following some thoughts on our two issues:

ad 1)
Pimcore DataObject classes cannot inherit from each other. The way to go would be to create one product class (that contains all common product attributes) and then use object bricks or classification store groups to model category specific attributes.
Then on object level, the corresponding object brick or classification store group can be added to the product object (depending on its category or other criteria).

ad 2)
As you already noticed, the default way of dealing with different variants of a product is to create an object instance for each variant and utilize data inheritance to reduce data maintenance effort (like in the demo). Also as Andrew already pointed out, adding some helper functionality like a generate variants button is easily possible.
The reason why we create a unique data object for each variant most of the time is, that normally each SKU has a unique product number and also in terms of e-commerce it needs to be possible to reference the exact variant that was ordered.
As an alternative you of course could use data structures like field definitions or block to follow your approach and have to attributes (like color, size, etc.) and add multiple values to them and then deal on the output channel with the variant generation. It is really up to your use case and your system what fits better.
An hybrid solution would be to define possible variants with variant attributes, and then generate the actual object variants on the fly when one is ordered.

Hope this helps a bit further…



Very helpful Christian, thanks a lot!!


Is it anyway to relate object brick item with object some fields value?
I see that there is no restriction to use any item from long list of object’s bricks while editing object. I think that only appropriate item (ie dependent on established realtion to category)have to be at that list.
attached sample of possibility to attach crazy set of object’s bricks


not in the core product by configuration yet. Of course you could add some custom validation rules etc.