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!!
Received very helpful answers on the PimCore forums, by user fash:
Issue 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).
Issue 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.