[meta] Drupal 8 (Commerce 2) Version

Yes, I think there is a need for this module for Commerce 2.0. Though, I wouldn't start coding before we have discussed, what that module should do and how we should design it. The commerce 2.0 port isn't exactly fast moving. The last alpha was released in april. I will ask one of the commerce project members how mature the product code design is. Currently they are concentrating there efforts on solving cart, checkout and payment issues, i think.

https://contribkanban.com/board/commerce2x

Before we start coding, let us discuss what we are aiming for. Which use cases should the module cover? What do we understand as an "product bundle" in the context of this module? Whats the best architecture to get there ... and so on. As soon as we have agreed to a certain level on that, we could ask the commerce people for some feedback.

Changed the issue summary

This arcticle by Yan Loetzer summarize my thoughts about the right place to develop this module. At least until there is a serious release candidate. So lets go to github for now:

https://github.com/olafkarsten/commerce_product_bundle

At this state of planning I would really discuss real world use cases and than derive an model from that. I will scan the issue queue and my private mails during the next days for a collection of all the question "Can we do that or this or ... with the module?".

A Product Bundle could be such a simple thing like a collection of existing product variations. I remember someone selling music. Singles and Albums. Singles are available individually or as a set, in this case a complete album. If the costumer buys the album, he gets access to all singles of that album. This is a valid use case for a product bundle with a fixed set of purchasable entities. Neither quantity of the purchasable entities nor variants can be selected by the user. This could be the case for physical products too.

Or a classic: Set of X T-Shirts. The user may select the one ore more attributes of each shirt. Price may be fixed or varies depending on the selected attributes, e.g. the size of the Shirt.

In many countries bundles have serious tax implications. In the EU you often have multiple VAT rates depending on the type of the product. If you combine them in a bundle, it really gets tricky with price calculation and how to display the price components. Sample: Bundle with one can of olive oil, one ceramik bottle and a pouring spout. In Germany the vat for the oil is 7% and for the other products is 19%. Even for bundles you have to display the amount that counts for the 7% and the amount that get taxed with 19% separately to the user.

Other use case I remember: Bundle of mainboard and cpu. The cpus the user can select depends on the mainboard the user has selected. Some kind of hierarchical product relations.

Architecture:
The bundle should implement PurchaseableEntityInterface, see https://drupalcommerce.org/blog/42500/commerce-2x-stories-products

I think we must implement the PurchaseableEntityInterface. ;)

Nice to have? The module should allow other modules to act on the purchased products, not just the purchased bundle. This would allow support for commerce license and commerce file.

At the moment, i would even judge that as a must have. But I'm not settled on this :D.

Question: During reporting we break out sales by SKU, how to determine a price for an individual SKU if the only have a bundle price?

We need to determine the price of an individual SKU for other reasons too (see my previous comments about tax rates). I think we have multiple scenarios here. Splitting the bundle price based on the ratio of the single product prices is a possible strategy. But it should be possible to alter the rules by the user, I guess. But in other scenarios the bundle price may have a logic that depends an the price of the selected skus. Need to give this some further braintime :D

So beer- and bedtime for now :D

For that to answer, we have to dig in the current code of commerce. Maybe one can do something on the view level with formatters and viewmodes whatever.

We can question this anyway: "Must we really treat the bundle as a single product" from an coders point of view. That the user should see something that looks like one product, okay - but thats a view thing, not necessarily a model requirement, right? I remember people demanding, to show each product with its selected attributes in the cart/checkout view or even that the user can change the attributes of the bundle products, except the quantity, in the cart view.

Currently my mental model from a bundle is more a wrapper of individuell products than an product itself. On the view layer we have different, often conflicting requests. Some people only want to see the name of the bundle. On the other end someone may want (or legally must) show all the products with all selected attributes of the bundle. And I'm pretty sure there are demands for all things in between. :D
That means for me, that we need a changable view thing - however we do this in D8 / Commerce 2.0.

On the model layer we need to make the individuell products transparent anyway. Otherwise the other contribs (license, file) wouldn't be able to act on them.

Thats the crux of the matter. Sometimes it looks totally simple. At a first glance we often want to act the bundle as a single product. But if you dig a little bit around, it could get quite demanding.

Hmm, I'm not ready to code, yet.

Last evenings I browsed to the docs and forums of other e-commerce suites out there. Spree, magento, oxid, prestashop ...

After reading a couple of the bundle issues there, I think we are on the right track.

Often the users are demanding some plain product grouping/listing feature, were you have listings of products, qty fields (may have attribute selectors too) but only one single "Add To Cart" button on the page. After adding the products with a qty value greater than 0 to the cart, thats it. Often there is an dedicated admin section for setting up those "grouped products". All things happen on the view layer only, in this scenario. I think, that feature should be implementent by an own module - not here.

All other features/issues revolves around the more sophisticated use cases we collected above. Some sounds pretty simple and some quite demanding. I'm in the process of browsing the current commerce code base and grasp how all the product logic works in D8/commerce 2.0. This will take some time.

One thing i learned the last evenings: The admin ui for setting up bundles is a crucial part of the puzzle. It should be possible for nontec-users to setup an product bundle.

For sure I will ask some smarter people from the commerceguys crew (irc, #drupal-commerce), to give us some feedback.

For D7 there is a module Commerce Add to Cart Extras that provides some kind of grouped product feature.

Some notes:

good read: Discussion about product architecture #2683605: Re-Design and Re-Purpose Product Type

Line items are now called order items #2603478: Rename line items to order items

If you setting up an evironment to develop a bundle thing, you likely need some more products/product variations. For a convinient way to create multiple variations have a look at issue: #2755529: Product variant bulk creation. The patch from #12 worked for me.

Regarding the concerns of product attributes and component SKU prices, I propose the following:

1. Bundles contain bundle variations just as products contain product variations

Since products are not purchasable entities, but their product variations are, and variations are the ones that have the SKU/price/stock/etc, I think bundles in this module must be of product variations.

Just as products contain product variations, bundles would contain bundle variations. This would allow us to bundle SKUs as bundle variations, and for bundles of different attributes to be offered, however at an administrative and UI cost (needing to create bundle variations for each combination of attributes).

However, I would say that the use case of product bundles in this consideration of attribute variations may come close to the different use case of offering discounts when combining products ... in which case offering a discount when someone buys a shirt and a pair of pants in the same order, regardless of the attributes selected. I think this use case is different than bundles, and can be handled by another module.

2. Bundle variations = N ((SKU @ Y Price) x Qty)

Since product variations (SKUs) are the ones with price, attributes, inventory levels, I think bundle variations should be defined as collections of quantities of SKUs at a new price. The bundle variation is then a purchasable entity with reference to the collections of quantities of skus at new prices; bundle variations can proxy the details of components SKUs at different places in the system, allowing other components to act on them for actions/reporting.

I've updated the issue summary with what has been discussed so far, and have put my recommendation in this comment into the Proposed resolution. Of course I am not trying to hijack anything and I expect we will update the issue summary and proposal as discussion continues.

Added link to "other module" (Commerce Bundle) which is designed to support the use case I propose we exclude--that is: offering discounts when combinations of products OR variations are purchased.

I answered that question in #16.1:

Since products are not purchasable entities, but their product variations are, and variations are the ones that have the SKU/price/stock/etc, I think bundles in this module must be of product variations.

Discounts on combined products, regardless of selected variation (aka SKU), is handled already by the Commerce Bundle module.

...after some quick prototyping I realize we'll need something like a field collection or 'bundle item' for each [SKU/Price/Qty] set in a bundle. Also thought about the pros and cons of offering a product bundle be purchasable vs. a product bundle variation being purchasable (side note: I don't really like the name 'product bundle variation'), I sketched this out as I was thinking about the ui complexity and entities:

Thanks for the input. I'm with steveoliver on that bundle must be of product variations. Not only for this module.

I'm not buying that we should split use cases in two modules. IIRC commerce product bundle was develeoped by one guy thunziker in the early days of commerce1 and d7. No best practices had yet been emerged. Somewhat later comes commerce bundle and tried to solve the same problem. Both projects didn't manage to ship a stable release. I havn't seen any public discussion on what and how to tackle the thing. Short trip to the history :)

I think one of the issues since the very beginning is naming things in commerce and this module. Bundle, product bundles, entity bundles, bundle variation, product variation, attribute variations ...if you don't have a deep understanding of the commerce vocab, you easily talking about different thinks.

Another problem is the UX: The setup of bundles in backend for the shopadmin as well as the one for the customer (Add to cart form).
To be honest. I havn't seen any product bundle implementation in one of the bigger commerce suites that isn't a nightmare for either the developers, shopadmins or enduser - or all of them.

Thats why I think, we have to discuss this more deeply. I didn't see that we are settled and can agree to split up in two or more modules at this point in time.

I also disagree on that: "Product attributes (variations) are not selectable in bundles -- bundle variations provide pre-set collections of variations at new prices." - That seems to narrow for most of the use case I see in the wild. But maybe I misunderstand the intention here. So lets look at the graphics.

@steveoliver

The sku in your bundle item is a reference to an product variation, right?

Lets discuss a real world use case:

https://www.obermeyer.com/outfits/womens/bombshell-down-parka

Pretty common sales pattern nowadays to offer entire outfits, styles from celebs etc.
Is that a bundle in our sense (note the add to cart button on the top left)? What if the sales people requests a little change. The entire outfit costs 699$. But to get the discount, you couldn't remove an item from the cart. Is that a bundle? What if the sales people request to remove the single add to cart buttons and let you only pick the entire outfit.

If I understand that correctly, one need to Implement the PurchasableEntityInterface to make a entity purchasable. The default product implementation is only one possible implementation. Maybe we will see some other ones in contrib.

Shouldn't we take a reference to any entity that implements that interface on our bundle item? Than we have multiple options for the interface implementation on the bundle itself. Forward the call to the referenced entities (e.g. getPrice()), preset values (price field bundle item) or preset values on the bundle itself.

@olafkarsten,

Re. #22: Yes, Bundles reference Product variations (I call them SKUs since SKUs are the UUID of merchant land).

Re. #23: The Obermeyer "Outfit" usecase is not really a bundle - it is an arbitrary set of SKUs without their own SKU, only in a custom display page with custom add to cart form, validation. Once added to the cart, individual items can be removed without a change in total price. These outfits have no SKU, no promo. NoSKUBundleWithoutPromo

The use case I am thinking about is where SKUs are offered at different prices, requiring specific quantities of each SKU, and the whole new bundle entity having its own SKU and sometimes even packaged in its own way at the merchant. This makes me think of the possible implications/opportunities this has for packing and shipping. (re commerce_shipping).

Re. #24: Yes, Product module's ProductVariation is the only purchasable entity for the Default Order item type in the Order module. In contrib/custom code there will eventually be others. So I do think we should support bundling any entity that implements Commerce Core's PurchasableEntityInterface.

PurchasableEntityInterface has a getPrice() method, but no getSKU -- that comes from the Product module. We may not always have a SKU for the referenced products. But we will have the Entity ID and Qty.

I also had the same idea to reference entities first, then get their price and use their price as the default (newPrice) value for each item in a bundle.

This is how I'm starting to think of bundles:

Bundle:

  Has SKU: (bool)
  Unique SKU: (bool)
  Bundle SKU: (string) (constraint: Unique SKU if Unique SKU is true)
  Items:
    - (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
    - (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
    - (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
  Third party settings:
    Shipping: []
    Other: []

This is how I think of Obermeyer outfits:

Suggestion:

  Insist together: (true)
  Items:
    - (ref:Product)
    - (ref:Product)
    - (ref:Product)
    - (ref:Product)

Thinking about names for these use cases / entities:

Bundle => Promo Purchase Bundle
Suggestion => Purchase Suggestion

Maybe slightly more explicit and descriptive?

To clarify the "suggestion" use case from my understanding of the Obermeyer Outfit example:

1. Business logic does not consider the collection of suggested items as its own entity (SKU).
2. Item price is not altered by the purchase suggestion.

Because of #2 and the fact that each of Obermeyer's outfits' products' attributes happen to be the same price, coincidentally for the display, item attributes (e.g size) can be selected and their Outfit "bundle price" doesn't need to change.

Fu... - timezone. My brain is dead now. Will come back tomorrow or monday.

I don't consider the obermeyer example as a bundle as it is now. But it only needs some little changes and you have one. At least in my mind. What if the Outfit cost some bucks less than the summed up single items. And you do not let the user change the quantity in cart?

I feel the definition of a bundle you suggest is to narrow. But I can't argue any more today. :D Thanks for your thoughts. The bundle model in #25 is kind of what i have in mind. But I'm not so restrictive, in that it must have some predefined qty or MUST have another price than the referenced entity. My experience is, that often the users request some more or less configurable product bundle. Mostly some kind of composite or mix/match (see below). Of course some fixed presetted bundles are requested too, but not that often. But thats only in my world. There are many others out there.

I think that is an good read here (by the woocommerce people). Good overview of the most common use cases.
https://docs.woocommerce.com/document/group-bundle-products-woocommerce/

This is exactly what I mean with nightmare. You have to select between 6 Modules for very similiar things (look at it from an shopadmin point of view). If you change a little bit of the requirements you end up with a "product bundle" instead of a "grouped product" and have to wire up all the stuff again.

Good Night :D

Okay, quick sidenote: I scanned the issues on both commerce bundle and this module. You find feature requests for every single use case the woocommerce docs talking about.

We can exclude one use case as clearly not a bundle. That is "Grouped Products" (the obermeyer example). It's mainly an UI Issue. But it's an often requested one, so we should have that functionality in commerce contrib space elsewhere.

All other use cases I would consider as valid "bundles". But I think one only need the destinction beetween static and dynamic bundles.

For the static bundle II like the model from #25.

Has SKU: (bool)
Unique SKU: (bool)
Bundle SKU: (string) (constraint: Unique SKU if Unique SKU is true)
Items:
- (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
- (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
- (int:Qty) x ((ref:Purchasable entity),(Price:newPrice))
Third party settings:
Shipping: []
Other: []

The other ones are dynamic product bundles. The Bundle Items are not static properties. Customers may select between a number of bundle items and may adjust quantities. It's not only about promotions, ist about composition. E.g a Camera Kit - body, lens, filter ... Or an computer component - Mainboard, CPU, Cooler. This seems much more coupled to an traditional product model - like the default implementation in commerce 2.0.

I would like to discuss, if there is a common base. Maybe we can define an common interface and than implement both cases - may it in different modules or in one.

@Steveoliver What are your thoughts on shipping/packing implications?

I'm thinking about how to solve the vat/tax issues :/.

In either case the bundle items must be transparent to the outside world. An AvailabiltyChecker needs to check the availability for each item, the price resolver need to know the prices of the items, a vat/tax resolver needs to know all about the single items, and the bundle.

I wonder if we get away with implementing Traversable and getBundleItems(). In case of a dynamic bundle, this would return the presettet defaults or the state of selection in the add to cart form. In any case - static or dynamic - it will return a collection of purchasable entities. From the outside it should look like the same thing.

@olafkarsten, As you've pointed out there are at least a half dozen unique types of bundle scenarios. As we discussed on IRC and a little in this issue, I think we should separate each use case into it's own [sub] module and keep any common base interfaces in the core commerce_product_bundle module.

Re: shipping/packing, just like in WooCommerce Product Bundle, I think bundle contents should be able to be shipped in their original packaging, or assembled in a package with their own physical properties.

This shipping/packing override functionality seems like a candidate for a base interface implementable by different "bundle" scenarios. ShippingOverrideBundleInterface?

To your point about pricing ("price resolver need to know the prices of the items"), I think this also points to an interface different bundle use cases could implement. PricingOverrideBundleInterface?

I've created a separate issue for identifying base interfaces: #2825548: Base interfaces for bundle implementations where we can flesh this out.

I'll create at least one new issue for the sub-module implementation of the static bundle use case I've presented so far.

Re: entity architecture: I think we need at least these entities:

Bundle content entity (of type dynamic/static, with/out pricing and shipping overrides, etc.)
BundleItem content entity (containing details about each bundle item, e.g. price, qty)

I will work on the interfaces for these entities in the other issue -- discussion of these and potential other (config?) entities could continue here.

@steveoliver Thanks for that. I have to dig into commerce 2.0 more deeply. I havn't understand yet how all the resolvers works, whats there job und where and who constructs/injects them. I didn't find any docs or flow diagrams, so I guess I have to setup an full installation and lets xdebug go through step by step.

Thats why I would really like to see some comments from mglaman or some other teammember of commerceguys.

Side note: As reading this, it seems important to get the most flexible solutions in commerce contrib too. Thinkable, that we will see more contrib product architectures as layer beetween other systems. So we should this keep in mind.
http://buytaert.net/content-and-commerce-a-big-opportunity-for-drupal (Read the comments, too)

Looks like you've been very diligent in your research so far.

I would be happy to help out with architecture, let's start by discussing on IRC.

EDIT: Spoke to olafkarsten on IRC. Looks like we're on the same page.

We agreed to point the commerce_bundle project to commerce_product_bundle for D8.

We also agreed that the implementation needs to be tied to commerce_product, we can't make this generic for any kind of PurchasableEntity. We can try to revisit that once we have an alpha going, but I'm not optimistic.

I like the idea of using WooCommerce bundles as an example to follow. Talking to Ryan and Matt (my fellow Commerce Guys), then Olaf, we all agreed that it's important to support attribute selection. Every second bundle project needs it, and it still leaves room for allowed variations to be reduced to 1 by the admin, therefore removing the attribute widgets.

That leaves us with the following data model:
- Bundle
Body, items, optionally a price in the future for per-bundle pricing
- BundleItem
Referenced via $bundle->items.
References 1 product, N variations, min_quantity, max_quantity, price.
The variations field is optional, used to narrow down the available variations for the selected product. If it's empty, we take the variations from the product. The price is also optional, if empty we take the one from the selected variation.
If min_quantity and max_quantity are the same, we hide the quantity widget.

The add to cart form widget goes through all bundle items. If there's only one variation, it can just render it and optionally show a quantity widget next to it. If there's more than one variation, it needs to show the attribute widgets. We'll need to move the commerce ProductVariationAttributeWidget logic into a trait or service so that it can be reused here.

Now, the next place to make a decision is the cart. We have two options:
1) Single order item per bundle.
This means that Bundle implements PurchasableEntityInterface. The "bundle" order item type also needs to store the selected variations and their quantities (which could be done using entity_reference_quantity). The order item quantity is then calculated by summing the variation quantities.

2) Multiple order items per bundle (one per bundle item)
This would require placing a "bundle" reference field on all order item types (hook_entity_bundle_info_alter()), creating an order item per bundle item, altering out the remove/update buttons for order items that have that reference field. Then changing the styling to group the related rows together (I think Views can do this using its table grouping). We'd also need to do altering on the admin side.

Both Ryan and me currently prefer #1 since it's the simpler approach (and quicker to code).

We also discussed taxes, which are going to be tricky. We'll need to reimplement tax resolving for bundles, and think about how to provide a UI for bundle-specific tax overrides (products can be taxed with different rates in a bundle compared to no-bundle). But that's in the future. Rome wasn't built in a day.

So, rock on folks :)

Updating issue summary.

Removing old image from issue summary.

Naming Issue:

I did a quick search over the core codebase and got xxx results for bundles (entity stuff). Bundle as name - as much as I love short ones - seems to generic and to error-prone for our module. I strongly suggest we use ProductBundle, ProductBundleItem instead.

EDIT:
Changed the body field (product bundle) to description. Body is so bloggish :/.

Products use a body too, it's fairly standard speak for "large blob of text that a piece of content has". And both products and bundles are content, after all. D8 has mostly used description to indicate admin-oriented text.

okay, okay - don't like that convention ;P Changed it to body.

Hi,

I really need this functionality or else i'm forced to use D7 :-(

Is there any update on this or do you need any help?

Ootsie, there's a link to the 8.x version on Github in the issue summary. I am already using this 8.x version in production. There are also several open issues with related Github PRs that you are welcome to join in on. If you need specific answers or guidance, #drupal-commerce on IRC is usually a great place for discussion.

Awesome!

Are there known bugs or a list of features that needs to be implemented before the module will get a stable release?

https://www.drupal.org/project/issues/commerce_product_bundle?version=8.x

That is pretty much what we have.

The current code works with static product bundles (somewhere in the issues are definitions/wording stuff).

For more sophisticated use cases, which likely require dynamic bundles, we have some work to do.

Can we please push https://github.com/olafkarsten/commerce_product_bundle to drupal.org?

+1 for pushing to d.o ... I think this will help with testing

We have patched D7 commerce_bundle to save the product price within the bundle item rather than merely referencing it, and also added a discount % widget for setting a % off the original product price within the bundle item. Would love to try and help with this project to get dynamic / drop-down select functionality with commerce_product_bundles for D8!

This module seems dead in the water, Is there any development taking place on this?

I am looking into porting commerce_bundle module instead as the base code for that module has been much more stable, and it has the specific functionality I need in moving to drupal 8/9

I know it's used in production in really large web applications for simple use cases (static bundles). And sure, if nobody helps with patches or sponsors some development time, than it is difficult keep the efforts going.

(subscribe)

And sure, if nobody helps with patches or sponsors some development time, than it is difficult keep the efforts going.

Very good point, and sorry for coming across with an attitude. :) I can see after a closer look that quite a bit of work went into this module.