Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Meta issue for price resolution:
Price resolution is a key feature of product bundles. Bundles may provide a fixed price, or bundle items may override the price of each product/variation, or the prices of each product/variation may be totaled. Handle this.
The first problem is in finding a way to calculate the price of the bundle if bundle items have variable/user-selectable variations -- see https://github.com/olafkarsten/commerce_product_bundle/commit/0603099437.... Since the bundle item doesn't contain the state of the selected variations (but the default product bundle order item type does), and by default price resolution does not pass anything to PurchasableEntityInterface::getPrice, we are currently relying on the default product variation for each product bundle item.
Price logic is:
1) If bundle has own price, use this.
2) If bundle hasn't an own price, calculate the price out of the bundle items.
ToDo
#2934102: Implement a PriceResolver
#2934708: Add a bundle specific formatter for the commerce price field
#2934716: Write tests for price resolution.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | interdiff-2831613-9-11.txt | 565 bytes | lawxen |
| #11 | 2831613-11.patch | 683 bytes | lawxen |
| #9 | 2831613-9.patch | 771 bytes | lawxen |
| #9 | interdiff-2831613-7-9.txt | 628 bytes | lawxen |
| #9 | interdiff-2831613-4-9.txt | 649 bytes | lawxen |
Comments
Comment #2
steveoliver commentedComment #4
steveoliver commented@olafkarsten, I thought I had commit access to this repo, but anyways... here's a small typo fix.
Comment #5
lawxen commented@steveoliver After applying the 2928976-5-current-store.patch and 2831613-4.patch
I create a product bundle like this:
got error
Comment #6
lawxen commentedComment #7
lawxen commentedComment #8
olafkarsten commentedWhy a check against a zero price? We do this twice in getUnitPrice(). Imho a price of 0.00$ is valid, or did I miss something?
Comment #9
lawxen commented@olafkarsten
Oh, yes, you are right.
we should do like commerce_variant http://cgit.drupalcode.org/commerce/tree/modules/product/src/Entity/Prod...
change getUnitPrice to get('price')
Comment #10
olafkarsten commented:D Nice trick, but hey - we are not commerce_product_variation, so we cannot access it's properties directly. We coding against the interface, in this case the PurchasableEntityInterface::getPrice(), which is implemented by commerce_product_variation. The return value is either a valid price object or null. Thats fine for us too, I guess. No further checks needed. But we have to fix our own interface documentation. I will do that.
Comment #11
lawxen commented@olafkarsten thanks for the analysis
I just change the code, documentation need your help.
Comment #12
olafkarsten commentedThanks, I'll do the interface docs and some test coverage.
Comment #13
olafkarsten commentedCommitted the current status quo. Thanks!
But I don't think we are done here, so leave it open.
Related Issue: #2929365: Make sure we don't fail fatal in case variations reference is not set on ProductBundleItem
Comment #15
olafkarsten commentedComment #16
olafkarsten commentedComment #17
steveoliver commented(I'm not actually doing anything on this at the moment). :)
Comment #18
olafkarsten commentedLet's make this a meta issue for price resolution.
Comment #19
orbistertius commented@olafkarsten, I was reading the issues of this module thinking about using it in a proyect. But this issue is a key. My idea to make this work would be a module creating a variation type holding a reference field to variations of other products. You are limiting the creation to only one variation per product, the use of a reference field inside the variation would make it possible to change the variations of the products included by creating more variations but if the bundles are offering a lot of variations UX would suffer because you need to recreate the bundle as many times as there are mixes of product variations.
Perhaps it is possible to decouple the creation of the bundle variations from the normal entity form and use your bundle form, with multiple variations per product added to the bundle, but variation entities created are all possible mixes of product variations selected.
Hope this gets the conversation going...
Comment #20
olafkarsten commentedLets clearify some wording first:
We have product bundles and product bundle items - a product bundle can have (reference) as many product bundle items as you want. A product bundle item can have (reference) as many product variations as you want, but the variations must belong the same product.
But part of this isn't materialized in actual code yet. We need to figure out how to track the current state of the bundle - means, which of referenced variants is the selected / active one.
I think this is, want you asked for, but I'm not sure.
Comment #21
olafkarsten commented