search

silvershop / silvershop-core

SilverShop is an e-commerce shopping cart module for the SilverStripe CMS
http://silvershop.github.io
BSD 2-Clause "Simplified" License
113 stars 119 forks source link

Remove the 'modifiers' concept from shop? #128

Open jedateach opened 11 years ago

jedateach commented 11 years ago

Modifiers are a way of abstracting away different types of order sub total lines. These can be additive (shipping cost, payment surcharge), or subtractive (coupons, credit notes). Modifiers have been around pretty much since the start of the ecommerce module.

Benefits include:

Whilst the original intention has been for developers to create their own modifiers, to be plugged into the system as desired, this has only really been done by core developers creating things like custom shipping methods. Also, I'm seeing more and more cases where one system relies on another. Some examples:

Shipping methods were the main way in which modifiers have been historically used. We have a separate shipping system now, which I believe was a step in the right direction. It only relies on modifiers to store the shipping value, but all the shipping methods and calculations are separate. Plus, it's relatively easy to have multiple shipping options.

Solution

My initial thoughts are to 'hard code' a lot more features, although I'm not entirely sure how this should happen.

It may be that we still want to retain the ability to order sub totals, and what totals are available.

Or, on the other hand, we could take a 'convention over configuration' approach. This would mean the most, if not all, of the ordering and what is available is hard coded. This may give us subtotals like:

As you see, this convention approach could get quite complex, and realistically it would be nice if the subtotals were optional, and orderable.

Related: #127

jedateach commented 11 years ago

@nimeso @wildflower do you have any thoughts on this?

wildflower commented 11 years ago

I'm guessing when you say orderable you mean a sort order when they're displayed, or a sequence that they should be applied in a particular order of precedence.

If you have a % rate coupon discount to apply on an already discounted Sale Price item, which modifier/discount should win or should it be cumulative.

Sometime coupons could be %15 off or $10 off, possibly on only a selection of products - just Lego and not Barbie

You've mentioned discounts on shipping only (which I've come across as a project request) the whole coupon thing should be separate module I believe simply because of the complexity in all the use cases.

I guess modifiers provide hooks you can swing off for this type of processing?

VIP member pricing was another big issue (in a previous role), and whether coupons should apply to those prices or if there was an absolute minimum price for a product (cost plus a slice of profit) and how that should be calculated.

I guess a barebones system needs a flat tax calculation for GST/VAT at least in NZ/AU/UK - (America goes silly with all it's state taxes rules - which are probably easier to ignore for us)

I guess it depends how "complete" you want 1.0 to be

I haven't read the modifier bits of code or how it holds together yet

jedateach commented 11 years ago

Thanks for your feedback @wildflower.

Modifiers

Yes, I mean order of display and calculation. Modifiers calculations will start by taking the subtotal of the order items, perform any changes, and then pass the new subtotal to the next modifier, and so on. Sometimes you want tax to be calculated before, or after, or somewhere between everything else.

Modifiers are set up by adding them to an array of modifier class names. For example:

Order::set_modifiers(array(
    'OrderCouponModifier',
    'ShippingFrameworkModifier',
    'FlatTaxModifier'
));

Individual modifiers can currently be accessed by $order->getModifier('ClassOfModifier',true), where the second argument forces a write.

Discounts

You've brought up some good points and ideas about discounts. I'm currently trying to flesh out the discount module more. I see it that there are multiple places where discounts could be introduced.

Definitely a valid point about how discounts are combined, or not. Unit tests are definitely mandatory to ensure the

shop 1.0

Regarding 1.0 completeness, I guess it doesn't need to be full featured, but desire that the core is written in a way that keeps these features in mind. It does make sense to abstract the core, and allow additional features to be added via submodules, however I'm beginning to see more and more inter-reliance on some modules. Speaking about discounts, I see discounting as a core part of ecommerce, that can simply be ignored if not desired.

any further thoughts?

jedateach commented 10 years ago

For the mean time, modifiers are here to stay. I'm going to remove the '1.0' milestone from this issue.

jedateach commented 10 years ago

Relates to #41

jedateach commented 9 years ago

The following notes have been moved from https://github.com/burnbright/silverstripe-shop/wiki/Modifiers-Upgrade-Plan

March 2012

The modifier system needs some serious thought. It is difficult to understand how it should be used. The code is not clear and concise. MVC "View" code is coupled with "Model" code. What is possible to do with modifiers is not well understood, documented, or unit tested.

Definition of modifiers: Non-item deductions or additions that affect the order total.

Here is a breakdown of possible types of lines that would show in an order:

Some lines should not be classed as a modifiers, but just an extra piece of displayed information.

Why even use modifiers?

Advantage of having modifiers as their own set/class of lines?

Could these simply be applied to an order as additional fields? eg: ShippingCost, TaxCost, Discount. New additional fields can be added via decorators. Yes, but modifiers will be considered the default solution.

Shipping was once done with ShippingCalculators ...I wonder if that should be adopted once again?

Requirements

This is what I think you should be able to do:

Plan

To Consider