Let's assume a product with multiple variations, "Drupal Commerce Hoodie".
There are two different titles that each of its variation can have:
- The short title: "Small, blue"
- The full title: "Drupal Commerce Hoodie - Small, blue"
When the variation is shown in the context of a product (variation listing in the admin UI, add to cart form on the frontend), it makes sense to use the short title. When the variation is shown outside the context of a product (autocomplete, shopping cart, invoice), it makes sense to use the full title.

Right now we assume that the $variation->title stores the full title, and use that as the label. This was primarily done to make autocomplete easier. We don't even have a getter for the short title, it is constructed on the fly in ProductVariationListBuilder and ProductVariationInlineForm.
We also have $variation->getOrderItemTitle(), which returns the same label.

Note: If a product always has a single variation, we can assume that both the short and the full title are equal to the product title, since the variation title isn't useful (there is no variation listing, no need to select variations on the add to cart form).

Problems

1) There is no getter for the short title, leading to duplicated logic between ProductVariationListBuilder, ProductVariationInlineForm, etc.

2) The ProductVariationTitleWidget uses the full title instead of the short title by default, and provides no configurability.
This surprises users from time to time: #2988677: Delete the product title in the variations.

Ideally we'd use the short title by default and offer the full title as a configuration option (to maintain BC primarily, since some users obviously don't mind).

3) Neither the short nor the full title are customizable.
Users might wish to exclude a certain attribute from the short title, or change the attribute separator (e.g. "/" instead of ",").
Users might also wish to change the format of the full title (separator after the product title, etc).

4) The full title can become outdated
We need to regenerate all variation titles when a product title (or its translation) changes. We currently don't do that.
#2929721: Auto generated product variation title does not change when product title changes.

5) Users who turn off title generation sometimes expect the title to be the short title, instead of the full title
See #2923799: Allow product variations to be named after the product name and variation title..

Competition

Shopify considers the variant title to be the short title: https://help.shopify.com/en/themes/liquid/objects/variant#variant-title
The full title is constructed for the line item: https://help.shopify.com/en/themes/liquid/objects/line_item#line_item-title

BigCommerce uses the short title in the admin UI: https://support.bigcommerce.com/s/article/Adding-Products-Beta#variations
Variations/variants don't seem to have any title actually stored, according to the REST API docs.

Proposed changes

1) Follow Shopify's lead and make the $variation->title represent the short title.
Fix ProductVariationListBuilder and ProductVariationInlineForm to use the ->label() getter.
This automatically fixes ProductVariationTitleWidget as well.

2) Introduce a getter for the full title.
How do we call it? Full title? Long title? Something else?

We make $variation->getOrderItemTitle() proxy to it.
The full title is always generated on the fly. This allows us to bypass the translation problem.
We can even make it a computed property on the entity.

We default the pattern to "$product_title - $variation_title".
This covers products with multiple variations, and products with a single variation that do not generate a title.
If the product has a single variation and the title is generated, we should only do $product_title.
We worry about tokens later (since we have IF/ELSE logic here).

3) Add an option to ProductVariationTitleWidget to use the full title instead.

4) Write a custom autocomplete handler for product variations (we need this anyway cause of #3083123: Product variation autocomplete should allow matching by SKU)
The handler would either search by SKU only, or by SKU and product title. It would show the a custom label ("SKU: Full title")

5) Write a custom product variation selection widget which allows selecting first the product, then the variation (if multiple)
This is long overdue.

6) Allow the title to be generated via Token (pattern on the product variation type).
Default pattern for products with multiple variations:
Title: "[commerce_product_variation:attributes]"
[commerce_product_variation:attributes] prints a comma-separated list of attribute display names, same as today.

Default patterns for products with a single variation:
Title: "[commerce_product:title]"
(Does this make sense, or should we hide the pattern and have all variations have a title like "Default"? That's what Shopify does)

(7) Show the product title on product variation creation / edit / delete form, so that, when working with product variations, you always know the product context. Maybe even linked to the product? (from #18)

(8) Eventually expose the product variation title as field #2353867: [META] Expose Title and other base fields in Manage Display which would allow to provide field formatters for the different title displays. That would bring us UI by design, consistent UX and extendability by field formatters. (from #18)

Comments

bojanz created an issue. See original summary.

bojanz’s picture

bojanz commented
Issue summary: View changes
bojanz’s picture

bojanz commented
Issue summary: View changes

Adding initial proposal for a fix. Not yet complete, I believe we can further simplify this.

bojanz credited MrPaulDriver.

bojanz credited bbuchert.

bojanz credited mglaman.

bojanz’s picture

bojanz commented

Closed #2923799: Allow product variations to be named after the product name and variation title. as duplicate, crediting people from that issue.

Paul's main point from the issue is:

I am simply asking for hardcoding of Product Name - Variation Title; to be displayed where 'Generate variation titles based on attribute values' is NOT enabled.

bojanz’s picture

bojanz commented
Issue summary: View changes
mrpauldriver’s picture

mrpauldriver commented

Thank you for looking at this @bojanz

rhovland’s picture

rhovland
he/him
Primary language English
Location Oregon
commented

This was a big pain point for us when we were setting up our site.

We are using the Product variation title widget because the attributes system was unsuitable for our use case.

Editors have to fill out the variation name manually so it includes the product name. If we leave out the product name then items in the cart make no sense. However the full variation titles in the add to cart form are too verbose and take up a lot of space.

We ended up creating a separate field on the variation called "option label" where editors would enter only the variation name.
We created a custom widget based of Product variation title. This custom widget modified how variations were displayed on the add to cart form.

Your proposed changes to handling of variation titles would remove the need for the extra field and custom widget. Order items should be created using the product name + (optional) variation name.

If this change happens then the variation title needs to be optional since products with a single variation don't need a named variation.

int_ua’s picture

int_ua commented

Maybe I'm missing some use-cases but to me it looks like getting rid of the mandatory title for product variations would've avoided a lot of issues and misunderstanding. I was pretty happy without the title field in the product variations at all until I found out that when the field is simply hidden translations are not being registered as finished: https://www.drupal.org/project/commerce/issues/3180256

zenimagine’s picture

zenimagine commented

If you have a patch, I would like to test it

int_ua’s picture

int_ua commented

Looks like it's impossible at all? https://www.drupal.org/project/drupal/issues/2358537

tonytheferg’s picture

tonytheferg commented

Really for 1:1 simple products it would be great to just pass the product title to the variation.

aaronbauman’s picture

aaronbauman
he/him
commented

Really for 1:1 simple products it would be great to just pass the product title to the variation.

Seems like this is what's happening now behind the scenes, but for all products and their variants.

Why doesn't the variant title show up in fields and field manager like every other entity?
Seems like the UI part of it should be a simple fix at least.

finex’s picture

finex commented

I've the following use case: a bookstore where every product (book) has two variations: the physical paper book and the digital ePub version.
The product title is the book title, to keep the variation select field compact, the variation titles are: "paper book" and "digital download".

When the user add the product to the cart, the variation title is shown, this is not a problem during the checkout because I'm able to change the views in order to also display the product title.

What I'm trying to solve now is to do the same on the order details page (both backend and frontend) and in the receipt email.

The problem could be easily solved updating the commerce_order_item table with a concatenation of the product and the variation title.

Now I can join the order item data with the product, but if the product title is changed or the product is deleted, I loose the information.

How should I resolve this issue?

EDIT: I've tried to subscribe on CART_ENTITY_ADD in order to change the order item title but the save() method on the OrderItem does not work. I've also tried to manually update the table with an UPDATE query, but the checkout still use the original cached value and I've not understood how to invalidate the related caches. So I've currently created a local patch to change the "getOrderItemTitle()" method on the ProductVariation class, instead of the default logic I concatenate the product title with the variation title. This workaround looks fine on my specific use case, but it should be solved in a more elegant way. I'm open to suggestions.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Yeah we just ran into EXACTLY the same discussion, so we can confirm this is Major ;)
We'll discuss this internally and try to contribute...

What does the Centarro team think about this?

Regarding

When the variation is shown in the context of a product (variation listing in the admin UI, add to cart form on the frontend), it makes sense to use the short title.

Even in the admin area it often makes sense to show the full product + product variation title, otherwise the product variations are missing their product context.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Related issues: +#2358537: Remove 'not null' constraint from node title field/column.('Title' field present in node entity should not be mandatory.), +#3083123: Product variation autocomplete should allow matching by SKU, +#2353867: [META] Expose Title and other base fields in Manage Display

Okay I read through the points in the issue summary now and also the comments. Some comments seem to address related, but different problems, as it seems to me. I really like the plan from the issue summary, but would suggest to eventually split some of them into separate issues, especially (5) and (6) from "proposed changes"?

1) Maybe it would make sense to create a META issue or make this one a meta issue? (I think better a new one with less noise). The separate points should then become sub-issues.

2) Regarding #2358537: Remove 'not null' constraint from node title field/column.('Title' field present in node entity should not be mandatory.) I don't really like the idea to not have labels per product variation and I'd say that's a related topic, but an edge-case and should not be part of this issue, while having a better visible bottom-up relation from product variation title to product title is a logical important thing.

3) What I'd also like a lot would be to simply have field formatters for the title, so you could simply select:

  • "Short title"
  • "Full title"
  • "Product title"
  • "Token"
  • ...?

and easily extend this by custom field formatters!
But that might depend on #2353867: [META] Expose Title and other base fields in Manage Display.

4) One thing that would improve UX / SBX a lot (at least in our workflow) and might be solvable quite easily is to show the product title well visible on the product variation admin form (/product/43/variations/9/edit). Currently it's barely visible in the breadcrumbs. I'll add that to the issue summary as (7)

So how should we proceed? Any chance to first get some Centarro feedback here to push this into the direction they like?

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
jsacksick’s picture

jsacksick commented
Version: 8.x-2.x-dev » 3.0.x-dev

So how should we proceed? Any chance to first get some Centarro feedback here to push this into the direction they like

Honestly, this wasn't really on my radar, this issue was initially opened 5 years ago and afaik, this never was a major concern on any of the projects I've been working on.

I had that one on my radar instead #2929721: Auto generated product variation title does not change when product title changes.
This late in the project lifecycle, this should target 3.x.

jsacksick’s picture

jsacksick commented

@Anybody: Could you elaborate on the pain points you're currently experiencing? Are there no way to work around those?

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

@jsacksick thanks! The issue summary already points out the things we experienced very well.

The final thing that lead me here, is the slight visibility of the parent product in the product variation CRUD forms. (e.g. /product/43/variations/9/edit)
Product variations have a very strong relation to their parent products (can not exist without), but working on such a form you feel to be "somewhere".

The same happens to us in other places where product variations are shown, especially in the admin backend. As a workaround you can prefix all product variations with the product name, but that leads to other issues.

So all in all we came to the same conclusions suggested in the issue summary to be able to bring the product variations closer to their parent product con(textually) all over the projects.

And yes of course there are workarounds, but it seems to us that this is a conceptual thing that should be improved in general and we're willing to help, as it would help us and our clients.

jsacksick’s picture

jsacksick commented

My concern is that, I certainly wouldn't expect changes (as a merchant) around how the title is handled for variations if I'm already running a live site, which is why I feel it is too late to change anything in Commerce 2 at this point.

Regarding:

The final thing that lead me here, is the slight visibility of the parent product in the product variation CRUD forms. (e.g. /product/43/variations/9/edit)

This is relatively easy to fix, by altering the route and specifying a different title callback. I'm guessing for some merchants, it might actually make sense to output the SKU in there too?

Also, the product title is visible in the breadcrumb.
Additionally, for a variation type that opts in to automatically generate variation titles, without actual attributes, the parent product title is going to be used.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Thanks @jsacksick yes it should definitely be backwards-compatible.

This is relatively easy to fix, by altering the route and specifying a different title callback. I'm guessing for some merchants, it might actually make sense to output the SKU in there too?

Would you accept this in Commerce Core or does it have to be solved in contrib?

For the other points, can you tell which of the proposed changes from the IS you would accept for Commerce 2 and which could be considered for Commerce 3 future?

We'd then create a META issue, split the proposed points into subissues and start working on them where it makes sense based on your decision.

In general my late hope is that one day you'll perhaps see the points yourself, at least partially, so we can revive it ;) I don't think I'll be able to convince you that most of this makes a lot of sense, if you don't run into this yourself :P
And yes, Commerce 3 would be fine for the large parts, as I think this is a conceptual thing. And of course especially for breaking changes!

Thank you for taking the time here!

jsacksick’s picture

jsacksick commented

Just to clarify, I don't disagree that there are things that can and should be improved. But changing this now will lead to other issues and other people complaining that it doesn't work like the way it used to be, that's all I'm saying...

It's hard to find the right behavior that'd satisfy everyone here... Depending on the business and what's being sold (digital vs physical etc)...

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Thanks, yes totally with you! :)
We just need a direction to go, so we don't waste valuable time. So let's wait for your and your teams feedback! Thanks!!

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Related issues: +#2923799: Allow product variations to be named after the product name and variation title.
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Title: Rework product variation title handling » Rework product variation label handling

FYI: I've started a (yet simple) contrib module to implement possible improvements to the product variation label / title.
https://www.drupal.org/project/commerce_better_product_variation_label

We can of course implement different strategies, for example as submodules, as a first step to resolve this in contrib, before it gets (partially) moved into Commerce possible.

If anyone is interested to help or become Co-maintainer, contact me!