adding colours / sizes / options to the ecommerce module (difficult)

[nicolaas]

Right now, the ecommerce module does not allow the user to select a particular product type variation, but in the real world, the consumer often needs to decide on "colour", "size", etc... I am aiming to create a "patch" for the ecommerce module that fixes this... see http://groups.google.com/group/silverstripe-dev/browse_thread/thread/5179eb0da368ff7b for some background...

[cmswarrior]

hey,

How far have you gone? i am about to start working on adding the features you requested.

[sminnee]

The shopify model for this works well. They have a single list of "variations", which could be sizes, colours, or whatever else: http://www.shopify.info/tour/products

To keep things simple I think it's acceptable not to allow for uploading different images linked to the different variations. However, the following information could be added:

• SKU / Product Code
• Price
• Inventory
• Weight

We could use a table list field or a complex table field to list variations, linked to a ProductVariation? data type.

If people want to add both sizes and colours for a product, they would have to list each combination "Small Red", "Large Red", "Small Blue", "Large Blue". I think that this is more than acceptable and will keep the complexity of the system manageable.

cmswarrior and nicolaas - it would be good to see what progress you've made so far.

[sharvey]

One idea I've been thinking about is having a system like the payment class - so a Product has_many ProductAttributes?. Colour, Size etc all extend from ProductAttributes? like Payment has "DPSPayment" and "Cheque" sub-classes.

Once you extend ProductAttributes? with your given attribute it automatically creates a ComplexTableField? which can be easily overloaded on the sub-classes to extend the functionality.

[smagnusson]

critical now, simply to the excessive wait.

[rlouis]

The first issue of this problem is the ability to add a DataObject? to our shopping cart !

To do so, I have separated the product type with the OrderItem? class which is I think the solution. the Product php file has now a class named Product_OrderItem.

Have a look at the OrderItem? class and you'll see that now, you can save of course informations like colours, size, option but also manage some price relations which is really important.

For instance, if you wanna buy an iPhone with a plan ! This is a many many relation between the type of iPhone and the plan.

I have already made some tests with EventTickets? DataObject? and it works fine. There are still some little problems that I have to fix.

This system has to work perfectly for Ecommerce 0.7

[sminnee]

On the contrary, this is the most important feature for e-commerce 0.6...

[nicolaas]

I have had a really long look at this. The cart is already very messy and hard to understand so you dont want to make the cart more difficult by having information about the type of product. Instead, each product (yellow t-shirt, brown t-shirt, etc... ) should be its own product rather than having multiple options for each product.

At the same time, we will need to make it appear in the e-commerce module as if it different products were one product with several options (yellow, brown, etc...). This can be done by grouping and adding more features to the group (e.g. duplicate product) or something like this.

I never finished this task, because I simply felt out of depth without any discussion about this with the core SS team.

[nicolaas]

I think the cart is really complex already, especially because it uses both sessions and the database, thereby having two versions. Simplifying the cart will make the whole e-commerce module more workable.

[rlouis]

Hi Nicolaas,

We can not create a page for every king of product(yellow, brown, ...). This is just not the solution.

Moreover, this kind of relation is gonna happen more than once. I mean, the shirt with the color, size setting is just one of the situation where you can have this king of complex relations.

But you also have for instance some cell phone with a many many relation with plans.

That's why I have created the OrderItem? class to be able to manage every kind of relations between DataObject?.

I am gonna create the files to add to a project to use the ecommerce with a shirt type of page.

As for the cart, you are right, I have had a look to 4 ecommerce sites and usually the cart only shows the number of items in the cart, the subtotal and the total.

[rlouis]

This archive contains the code for a jersey with size and color and sex attributes.

Add this archive to your project and play with the form a little bit !

Have a look as well in the CMS !

[rlouis]

Jersey Product Page with Size, color and sex management

[nicolaas]

we will be working on this during the coming week. If anyone has any additional suggestions then please let me know.

[nicolaas]

Hi Everyone interested in this topic.

I got rather experienced "outsider" to have a look at this ticket and this was his advice:

1. Ecommerce should be completely replaced with a new module. The new module can reuse at least some of the existing code, e.g. the payment processing, but the product/order object model is too deeply ingrained to be able to easily replace it within the existing module.

2. Abandon the idea of ProductGroups?. Products should be able to go anywhere just like any other page, they don't need special holders. Categorisation can be done through the config system in the Catalog page (see below).

3. Create a new Catalog page, which ultimately will have product search functions but whose main purpose is to hold the config system in the CMS admin for product categories (Colour, Size) and classifications (Red, Blue, S, M, XL). The config system is just a series of table editing components in the CMS admin, all held within the catalog page definition.

4. The Catalog has the following data tables associated with it:

category (Colour, Size, Meal, Vegetarian, Dairy-free, etc., one record for each, user-editable),

classification (Red, Blue, S, M, XL, Breakfast, Lunch, Yes, No, etc., one record for each, each record has a key saying which category the classification belongs to, and also a key indicating which special order field is associated with the classification),

and orderfields (Breakfast delivery time, Packaging type, etc., one record for each, are extra fields that will appear on the checkout page depending on which classifications the user chose for each product in the cart, or will always appear in the cart if the appropriate boolean flag is set).

There are two kinds of category - user defined, and predefined - separated only by a boolean flag on the category table. Predefined categories contain fixed values, e.g. Vegetarian, Meal, which are set by the admin whilst creating the product. User-defined categories contain things selectable by the user at order time, e.g. Colour, Size. Classifications can have images associated with them for ease of identification.

5. Products have attributes associated with them which are predefined and used to provide extra information beyond a name and description, e.g. Weight, Volume, Material, SKU, etc. These are populated via the CMS admin page. They are free-text and arbitrary.

6. Orders contain lists of products PLUS the list of classifications the user selected when adding the product to the basket. It is easy to check whether a product is the same as one in the basket already by checking the product ID PLUS the IDs of all the classifications the user selected.

7. The checkout, cart and payment system remains largely the same in function. The system will continue to use session data until the order is placed, at which point it persists it to the database.

8. Products are defined in the CMS admin section by selecting the classifications in each category that is permitted, as defined by the catalog page in CMS admin. It will show a series of checkboxes for each classification available, grouped by category. For predefined categories only one classification is selectable, and it will apply to the product at all times. For user-defined categories, multiple classifications are selectable, and the user can choose between them when placing the order. Only classifications selected in the admin page will be presented to the user - therefore you can define 10 different colours, for instance, in the catalog, but each product may be available only in a subset of 3 of those, but a different subset for each product.

9. Products have an extra trick allowing the classification to change the product image, price, or in-stock flag depending on the classification selected in the order. This is done by a table of rules. The rule table contains one record per rule, which allows entry of a rule that matches one or many combinations of classification. (e.g. the rule would match all sizes but only red colour). The rules only apply to the product within which they are defined. Each rule then contains an out-of-stock flag to indicate that the combination of classifications on this product is out of stock. It also has a price modifier column indicating that the combination of classifications will increase or decrease the price by a certain amount or percentage.

Finally it also has an image column indicating the image to use for the particular combination of classifications for this product. All three of these things are optional, but at least one of them must be specified for the rule to actually have any effect. The system will apply all rules that match the currently selected classification, so if there's a rule that says XXL size costs 20% more for all colours, and another rule that says red colour costs 10% more, you'll get a 30% markup on the price.

I would be keen to get some reaction on this.

My personal view would be to either execute as recommended above or keep the current model, but change it so that you can easily create 100s of products, many of which are almost identical combinations of each other. In that way, we keep the core of the current code, but create a new interaction layer that allows the user to create many different combos of products without too much hassle.

[sminnee]

There's a lot of content here. Many of the ideas are good, but I don't think that abandoning the existing ecommerce module is the way to go.

I'll have a think about this and post an update shortly.

[nicolaas]

my recommendations would be as follows:

1. setup two e-commerce modules

1. for small shops
2. a more abstract engine that can be used as a core for a wider range of projects (bookings, large shops, etc...)

OR

2. keep the existing model, but allow for rapid creation and management of many products (which are really product versions) by creating an additional layer between products and product groups - lets call them subgroups. From a DB point of view, we will stick with the product x quantiy model, but in the front-end and CMS they are presented as product versions, while the product subgroups are presented as products.

In this idea - in the CMS, each time you create a product subgroup (presented to the user as a product), you setup all the basic settings for the product (e.g. cost, weight, size). You can then select combinations that exist (e.g. size, colours, etc...) and these products will be automatically created (i.e. each size in each colour). From there, the user can then edit individual products (e.g. make the XLa bit more expensive).

I have been promoting this idea, but I dont think anyone else likes it. I am curious to know whether this is because i can't explain it very well or because it is a stupid idea ;-) Two big advantages I can see are that it allows all the flexibility for each product on a version level (i.e. out of stock, change price, number of items in stock, additional pictures, etc...). Secondly it retains that the current cart setup of product x quantity. Drawbacks are that you get lots of products and that it would not work in situations where the combinations are limitless.

[nicolaas]

looking more closely at the code provided by Romain - so far it works awesome.

[nicolaas]

Hi

Using Romains files, I have come up with the next step. It is not a big step, but it is going in the right direction.

Note that I have used the latest ecommerce build (09 August 2008) to test these.

I have made a small change in the Product.php file (removed the Product_Attribute class (line 179) - which was empty anyway).

I have created an extension of the productPage (productAttributeProductPage - name will have to change), and a dataObject that contains productAttribute_types definitions.

My goals from here are as follows:

1. find a way to enforce unique indexes on the productAttribute_type so that the combo can not be added twice.

2. Remove the fields from the ProductAttribute?_type class so that we can add them using a decorator. This will allows the person setting up the ecommerce module to customise outside of the core files of the module. I would need some guidance here as I am not sure about the best way to go about it.

3. Find a way in the front-end to only allow the user to select existing combos. This would be best done by supplying a javascript array that interacts with the dropdowns.

The idea in the end is that the ecommerce module installer can quickly add additional fields (size, colour, etc...) to the module without having to touch any of the core files.

[nicolaas]

second step

[nicolaas]

my first attempt in putting together a map of the classes involved in the product/order relationship. I think this clearly shows how confusing this module is. Could anyone help me make this more understandable?

[nicolaas]

I have created a visual diagram (see PDF attachment) of the alternative to the solution proposed above (i.e. adding a has_many table with attributes to a table and allowing these combinations to be ordered instead of the product itself).

The advantages of the alternative are:

1. more flexibility with individual product versions (e.g. yellow, Small, female all black jersey, not just all black jersey) - allowing each variety to be edited individually, contain one or more images, and generally enjoy all the other features that the product class has to (and in the future - will) offer (e.g. versioning, search engine listing, meta tags, other additional fields, etc...)

2. future developments on the ecommerce module can be kept a lot simpler as there is no need to always cater for buying a product or a product version. That is - only products are sold. This will keep a lot of things a lot simpler (e.g. sales analysis, product management, temporarily out of stock, etc...)

3. A much greater flexibility for the user to add attributes to products, create more attribute options, delete options, vary options, regularly change options, etc... This does not only apply to the input, but also to output including the front-end of the website AND reporting (i.e. easier to compare within and between productAttributes and productAttributeGroups)

I am sure that I would have missed a major pitfall for this approach (and please let me know if I am wasting my time), but on the whole it seems a lot cleaner than any other option. The main thing is that it allows maximum flexibility for the end user, therefore allowing the ecommerce module to be applicable to the greatest number of situations, allowing a lot more developers to employ it without modifications to its core.

[nicolaas]

an overview of an alternative approach to product attributes