Line-item by product type instead of content type

I totally agree. I'm not sure if this needs to be resolved in core, but I have a local "Customizable Products" module that I hacked together at Austin that I think this would be a perfect feature for. Let me add it in and test it out and see if we can get the code online ASAP. I'd love to have a co-maintainer on it when it's up if it's something you think you'd be interested in.

Ahh, I gotcha. Well, what we can do is get the project online (fixed a bug I had in it a couple days ago and am close to posting now) and then have you track along with me. I can review your patches and what not to make sure you get the Drupal process and then go from there. No need to rush into things, but I'd be happy to help onboard you to start maintaining over time.

Just a heads up - I added the Customizable Products module but don't seem able to move this issue to its queue right now. (The Version select list isn't populating properly for me when I change the Project; guess the cache needs to catch up or something.)

See more here: http://drupal.org/project/commerce_custom_product

Whenever possible, let's move this issue to that project's queue and turn it into a feature request.

Now we can move it :)

Maybe we can open some discussion on the differences between this and commerce custom line items as I'm not sure if we're duplicating effort here. Maybe we could base this one in CCLI as a dependency or it's just that CCLI is probably going to get in commerce core eventually and this specific need is more for contrib space.

That'd be another issue, pcambra, so I went ahead and opened it. : )

#1369570: How is this module different from Commerce Custom Line Items (Types)?

Hi

I'm facing this as well. We need to find a way to reduce the complexity of the Product display -> Product type -> Line item type relationship. It would make more sense if we could select line item type on the product type, and not on display type.

This would probably have to go into commerce core and commerce_cart. Line item type would be a setting on Product type, and the Add to cart-widget would not care about Line item type. commerce_product_line_item_new would then use this setting to create the Line item using the correct type, and commerce_cart_add_to_cart_form would have to create a new Line item on ajax refresh if the active products Line item type change.. or something like that. :)

Atle

@atlea: I hope rszrama is cool with me quoting him from IRC, (on 2012-03-07 in #drupal-commerce,) but it looks like he essentially agrees with you:

[9:20pm] jeffschuler: rszrama: did you have a particular vision for how commerce_custom_product could be made to not require additional product display content types?
[9:20pm] rszrama: jeffschuler: my thought was something like altering the product form to map to a particular product line item and then altering the add to cart form to make use of the proper line item type for the currently selected product

@facine - I'm working on a site with the same issue you describe in your summary: a number of products that need different kinds of customer input and, as a result, a number of custom line item types, each with it's own content type for display.

Are you still using your customized field format function above? Does it work well and do you feel like the approach is OK in a live environment, at least until there is an official solution?

Following up on comment #8 above:

We need to find a way to reduce the complexity of the Product display -> Product type -> Line item type relationship. It would make more sense if we could select line item type on the product type, and not on display type.

What is the relationship among these three? I've spent the past couple of days watching videos, and still don't get it. I tried playing around and was able to get a display node to associate with a particular line item and a particular product, but shouldn't it be possible for a display (or maybe that's a product) to not be associated with any line item? Shouldn't the manage display allowing an "Add to Cart" form have an option for no line item?

Product types define the fields that a product may contain in addition to its title and SKU. You can have any number of product types, like t-shirt, shoes, etc. that you use to create products. One of the ways a product can be displayed is through a node display using a product reference field, which is where the Add to Cart form display formatter comes into play. The node with a product reference field using an Add to Cart form display formatter will display with the appropriate form to add the referenced product (or one from a group of referenced products to the cart). As far as building the display and presenting the product data is concerned, line item types don't really come into the picture.

Where line item types come into play is when you're trying to represent a product in the shopping cart. When you click the "Add to cart" button, a product line item is created that references the precise product that was chosen. This is then attached to your current shopping cart order (or a new order if you didn't have one yet). The reason you have to select a product line item type in the Add to Cart form display formatter settings is because different product line item types can have different fields on them that collect additional information related to the purchase of the product from the customer. In the case of a donation, for example, you might use the basic default product type to create your various donation campaigns (or a custom donation campaign product type for that matter) and a custom product line item type with a donation amount price field attached to it that you expose through the Add to Cart form. This would let the customer say how much they want to donate, and you could then use that information in a product pricing rule to make sure the unit price of the donation product line item in the cart stays constant. If I'm not mistaken, this is how http://sosense.org implemented their donation amounts.

As you can see, then, there's no way to make specifying the line item type optional. If you only have one product line item type on the site, then you don't have to worry about it at all, but there will always be a product line item type used to represent a product on an order once it's been added to the cart.

That's a bit dense, but I hope it helps.

Thanks Ryan,
That does help, but not entirely. Here's an example situation:
I have three products for sale:

1. The over-used, slogan-bearing T-shirt, available in several sizes and colors
2. A monogrammed bathrobe, also available in several sizes and colors
3. Toothbrushes, with selectable bristle stiffness, but nothing custom

I figure I'd have the above three product types, each with its own gamut of items, and a matching display node for collecting the various options.
I'd create two custom line item types:

1. slogan with a text field for exposing the desired phrase
2. monogram, for argument's sake with three select lists of capital letters

The T-shirt display would show the slogan line item type on its add to cart form, and the bathrobe display would show the monogram line item type on its add to cart form. I expected the toothbrush display wouldn't have any line item on its add to cart form, but that's not possible. The only way to prevent someone trying to put a slogan or monogram on a toothbrush is to select the built-in "product" line item type.
Is it that the built-in "product" line item type must always be there as a default? Is it's being called "product" have any relationship to the built-in "product" product type? Is there a naming convention going on here, or did the word "product" just get re-used? Also, the term "line item" is used for these custom settings and also for the items in the shopping cart. What distinguishes them from one another?

Your setup sounds correct with respect to the t-shirt and monogram product line item types. You have to have these so you can expose the necessary custom fields to the Add to Cart form. But remember, even though you're using these with custom fields, there are is still the one default field that must always be present for a line item type to function as a product line item type - a product reference field. This is why even your toothbrush display must still use a line item type - when it's added to the cart, it still has a product reference field value.

One way to think of this form is that the Add to Cart form is functionally a line item add form (as if there was a line-item/add/line-item-type URL like you have for node/add/node-type). The end result is going to be a line item gets created. It's not that the Add to Cart form is showing you a line item; it's prompting you to fill in values to create the line item that ends up in the cart. That's why you must always specify some line item type in the Add to Cart form display formatter settings - that form simply exists to create a line item.

Great, thanks for the link!

Thanks again, Ryan!
I went back and re-read your earlier comment (#13) along with #15, and I think it finally makes sense to me. (Struck in the head by the holy cinder block of enlightenment.)

lol Glad you got the idea; it can be hard to relate in text. I seem to communicate better with a lot of hand waving and a shared screen. ; )

as to #16: sandbox module implementing this:
first of all, really want to thank you for your efforts, @facine!

reviewing this was a bit difficult though, because it seems mostly copy-paste of commerce_cart_add_to_cart_form() and friends.
what i found different is essentially one line that swaps out the line item type in add_to_cart_form, and the corresponding settings in field_formatter_settings_form.

correct?

as always with copy-paste development, this is very difficult to merge in.
you want some idea how to give your improvements a chance? read on.

i think what you do can and should be done in some lines of hook_form_alter.
(if we have to call commerce_cart_add_to_cart_form() again to re-do its job, that is not nice but we can afford it.)
(also we will get the add-to-cart views field for free that you module seems to omit.)

if for some reason the hook_form_alter approach will not work, then we should file a patch that adds a suitable drupal_alter() call in the middle of commerce_cart_add_to_cart_form() where we can hook in and alter line item type.
(i'm quite sure @rszrama will benevolently consider this)

i'll be glad to work together to get this in!

@facine: cool. but to be honest i doubt i will find time for this soon. but who knows...

Not sure how this fits in, if at all, but has anyone considered the possibility of a product type being linked to potentially more than one line item type?
Man, I'm sick of the hackneyed T-shirt, but what if a purchaser has a choice of customizing a T-shirt with either an embroidered name or uploading a graphic file for screen printing?
That's two line item types connected to one product type, right?

hehe Yeah, it would be, but in that case I'd probably just recommend the store use a single line item type and alter the Add to Cart form to make the appropriate fields visible / invisible depending on the type of order. Sure it'll take code, but sometimes that's what the task calls for. : )

Thanks again Ryan!
I have just such a use case in front of me, and your response gives me another way of approaching it.
I was thinking of using something in the product type (a field or taxonomy term, e.g.) to programmatically determine which line item to use.

• I gave my display node a select list field with values corresponding to the divers custom line item type machine names.
• A hook_form_alter keyed to work on the commerce_cart_add_to_cart_form
  1. checks the value of this field buried in the $form_state array against the line item type.
  2. If they don't match, the line item type is reset to match, and the data are sent back to commerce_cart_add_to_cart_form

@msypes, @ryan:
i outlined another approach in #1733386: Model product customization with backreferencing-entities like profile2.
(having this issue here and that solved would make my dream-product-customization module! ;-)

> That's why you must always specify some line item type in the Add to Cart form display formatter settings - that form simply exists to create a line item.

Does that mean that with this module, all products of a given type must use the same line item?

I am looking at a system where the customization may differ *per product*. As such, I've been thinking about a completely different approach where the customization is itself a product, and the physical product has a reference to the customization.

I guess the way to do it that's nearer to the architecture here would be to have each product reference the line item type it creates on adding to the cart.

Even if each individual customization were a separate product, wouldn't you have the same problem of then having to create field configurations for every product? If so, you'd just as well use a unique product line item type per customizable product. I wouldn't be opposed to allowing the product itself to specify the line item type it should use; we could make that an extension of this feature request where you use the product type's setting as the default line item type to use but allow it to be overridden on a product-by-product basis. A little more data to store, but we can always make it an optional feature as well.

> Even if each individual customization were a separate product, wouldn't you have the same problem of then having to create field configurations for every product? If so, you'd just as well use a unique product line item type per customizable product

True.

But having a couple of dozen products to represent the different sorts of customization feels nicer than having a couple of dozen line item types. To me that's starting to feel like the types system is being used for something too heavy.

To give an example, the varieties of customization I'm working with include:

* 10-character name + 2 digits + image on sleeve
* 10-character name + 2 digits + image on sleeve
* 10-character name + 2 digits
* 10-character name + 2 digits
* 5-character name
* 3-character name

This is for a clothing store, so there's a lot of variety in how products can be personalized. I'm not yet sure how to cater for this mix&match approach.

> wouldn't you have the same problem of then having to create field configurations for every product?

Oh wait. Now I get what you mean.

To store the customization in the cart, you need fields on the line item anyway. Hence a line item type.

Hmm... :/

Ryan's just said this on IRC which I need to go and lie down to think about without it hurting my head ;)

yeah, I'm just thinking we could drop a field collection on the product line item type and add the custom UI widget to the product form that lets you say which of the available fields in the collection (or perhaps just fields on the line item type) should be #access => TRUE for that product

#1798006: Add to Cart Line Item type should be determined by product type or product instance will attempt to find a solution to #31.

> > Even if each individual customization were a separate product, wouldn't you have the same problem of then having to create field configurations for every product? If so, you'd just as well use a unique product line item type per customizable product

Looking at my own use case some more, I see that my different customizations are each prices.

I see that it's possible to have customization change the price (#1692960: Refresh price field when a product is customized.), but intuitively it seems that something that's a purchase should be a product.

Facine, if I could, I would kiss you!!!! Your >Commerce Customizable Add to Cart was EXACTLY what I was looking for (taking over my life for over 3 days I might add)!! After doing extensive research on this matter, I can't believe that this has not been addressed earlier. You, rszrama, ryan and the others deserve a round of applause for tackling this issue head on. As someone who is new to Drupal, but not new to Ecommerce, I found so many things about Drupal Commerce that I loved, but associating a Line Item to only a product display/view and not a product type unfathomable. Why, after setting up a beautiful universal way of displaying my products (and sometimes complicated with CSS styles, block settings, teasers, etc.) should I have to duplicate that every single time just because I wanted to have a different line item for a product ridiculous.

Look at a lot of Ecommerce sites out there. Most of them present all of their products the same (Product Display) but present different options for each product as needed in their Line items.

I am currently working on a site for a client who sells all kinds of items (apparel, magnets, novelty items, soaps, etc.). I wanted all the products to be displayed the same way, but with only one exception. Some products required the user to select a size, or a scent of a soap or a dress size or some required no option settings whatsoever.

I have implemented your module along with rszrama's Customizable Products module and have done a full days of research and so far they run like a charm.

This I believe is an issue that should be resolved if not at Core at least with changes to the Add to Cart form in general.

The conversation kind of helped me. The current Commerce book only seem to focus on Commerce Kickstart. We a comprehensive book Commerce that is detailed and clear. With that Commerce will be the go to eCommerce system.

Similar functionality possible with http://drupal.org/sandbox/malberts/1947762

@facine Thanks, nice module! Seems to work for me too.
Is it becoming "oficial"? It's strange for me that after 2 years is still a sandbox project, although I really dont know how this process goes normally.

Thanks again.
Diego.