Product option prices showing as differences

[nathanbright]

Template based on original from recent upgraded CC4

We have some standard (I would have thought) product size options. In the admin of the product options we appear to be required to enter the price and weight as the difference from the "base" product. So for instance, a base product Aromatherapy Oil 10ml, £5.30, then a larger one 25ml, costing £9.50, we have to enter it's price difference of £4.20

The customer facing product page options drop-down then displays this as "25ml (+ £4.20)" rather than telling the customer the actual price - strange. I've re-coded the product page template to calculate and display the whole price

But the customer facing invoices and receipts have this differential pricing string in them, inserted in the core code (I assume, can't find where it is done in template code if it is). I.e. I can see by using Smarty {debug} on the receipt page that the product options string has been coed by concatenating the title and price difference strings again. To convert to actual price I would have to do string manipulation

Is this expected behaviour? I feel like I've overlook something fundamental as I can't recall seeing this displaying of the difference in price on other websites?

I see that the demo site only has one product option, "Installation service + £50", where this makes sense

And now I come to look, I cannot see other sites using this mechanism, they appear to make different sizes as different products

 

[bsmither]

This is the way CubeCart is coded, since the days of CC3. The best work-around (so far) is to make separate products of "related" items, then show those related items on the same page as any of those items. (And that 'Related Items' is a mod.)

In CC6 with Foundation skin, there is javascript that will dynamically update the item's displayed price to include the sum-total of all options selected. (You mention having one specific option that causes a change in price - size - but what happens when there is more than one option that would affect the item's price?)

In an experiment, I have made the Kurouto skin (running in CC6) do the same dynamic updating of the displayed price. So, to the customer, viewing the item's page is just a bit more straightforward.

Internally, CubeCart keeps the cost of the item and the price differentials of the options very separate.

[havenswift-hosting]

This is the way CubeCart is coded, since the days of CC3. The best work-around (so far) is to make separate products of "related" items, then show those related items on the same page as any of those items. (And that 'Related Items' is a mod.)

I would strongly advise against this "solution" for several reasons :

1) Having multiple option versions of essentially the same product creates more work for the store owner but is MUCH less user friendly for your customers

2) Maybe more importantly, this is a terrible situation from an SEO perspective.  It is hard enough for E-Commerce stores to get good rankings for product pages as it is, but having multiple products for each different option combination creates duplicate content issues.  It is often hard enough getting great SEO friendly descriptions for products but having 2,5 or 30 products that differ only by the colour or size means it is impossible.

It is not that difficult to create a solution to display prices "correctly" to get around this historical way that CubeCart deals with option pricing

Ian

[nathanbright]

Thanks for confirming I've not overlooked something

Ian makes good points, especially re SEO

As I say, I've coded the skin to show absolute prices. Ian, do you find you have to edit "core code" to implement this for the receipts / invoices? Guess I'll have another look at the code to see if I can head off that string concatonation

Nathan