hook_cart_item() calls op 'remove' for two fairly different things:
- the user removes an item from their cart
- the user checks out their cart (and the cart is emptied by uc_cart_complete_sale().)
This on the surface makes sense, but if a 3rd party module wants to maintain its own data about products, it makes that very awkward, as it's impossible to tell from within hook_cart_item() what is happening.
I would suggest the latter case be op 'checkout' rather than 'remove'.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 744956_cart_empty.patch | 2.82 KB | Island Usurper |
| #1 | 744956.ubercart.hook_cart_item-op-remove-checkout.patch | 3.25 KB | joachim |
Comments
Comment #1
joachim commentedHere's a patch.
This seemed the best approach short of writing a whole new cart emptying function for when checkout takes place.
I've filled in missing docs at the same time as adding them for the new parameter and op I am introducing.
As far as I can tell, no modules in the Ubercart package do anything on op 'remove', so no changes are needed anywhere other than uc_cart.module.
Comment #2
ldweeks commentedAny chance this will be committed to ubercart? I've run right up against this problem (ie, I want to store extra info about products), and now I'm stuck.
Thanks...
Comment #3
ldweeks commentedI actually got off my duff and applied the patch and tested it. It worked great for me. The fact that you left the 'remove' option working the way one would expect means, I think, that very few people will be affected adversely by this patch.
I like it!
Comment #4
ldweeks commentedMarking this as tested. I've been using it for a week now with no problems.
Comment #5
Island Usurper commentedThanks for the patch and the review. Committed.
Comment #6
longwaveNeeds porting to 7.x.
Comment #7
Island Usurper commentedAnd it's ported.
Comment #8
longwaveCommitted.