Ensuring a Price on products

Ok, so I've been kicking this question around for a couple of days regarding prices on products. I'm at the point where I'm mocking up an Add to Cart form display formatter for the Product Reference field. I started to get worried about depending on there being a price for a product... if we're using a default Price field on products, someone could accidentally delete the default Price field or maybe add another. How will the shopping cart know which price to display? How will I display the price on a node that references the product for that matter?

I did a little bit of poking around in the node module, and it does appear that the Body field is created automatically by the node module whenever a node type is saved with $type->has_body == TRUE. (i.e. whenever you save the form w/ a title for the body field filled in.) If you delete the Body field but re-save that form, the Body field will get recreated... of course you'll have lost all the data on any nodes of that type that had a Body.

Anyways, if we're going to use a Price field that isn't inherent to the product itself (i.e. like the product_id or created timestamp), then we need to be able to ensure we know how to find the appropriate price of a product. This would be fine and simple if we could ensure there would always be a single value Price field on every product, but what if there are more? What if someone adds a second Price field or turns one into multiple value? Do we want to program restrictions on what people can do with the Price field? Should we consider using Rules to determine the proper Price field value to use?

Lots of questions to be answered, including how in the world we'll get these prices to display elsewhere in a product display node or View than right beside the Add to Cart form.

Ryan Szrama
Posted: Feb 12, 2010


Ryan Ryan Szrama on February 12, 2010

On a side note, it turns out that deleting the Body field from one node type deletes it from every node type. Whoops! Let's not duplicate that functionality... ; )

(Patch available for testing here.)

redben on February 12, 2010

Maybe on the product type form (thinking from ui seems easier), have a fieldset "Pricing Scheme", and not exposing the price as a regular field. The price setting fieldset allows the user to choose a price scheme: Simple pricing (default implementation), Scheduled pricing, donation...etc
There would be a pricing api that lets developers implement special pricing schemes.
- When a product type is being created the selected pricing handler which implements certain hooks is given the chance to create its fields/tables.
On product loading the handler is invoked to alter the query if necessary to include his fields (à la Views)

Another way could be, instead of a fieldset, have these "pricing schemes" implemented as different field types (Simple price field, scheduled price field, complex xyz price field...etc)
And in some way, having a validation on product type creation that checks if one of these fields (they might have some kind of common signature) are present. If not, then validation fails...

Well...just my thoughts