When using the product variations formatter "Rendered Entity" (entity_reference_entity_view) in the product type display configuration (/admin/commerce/config/product-types/TYPE/edit/display), the rendered entity does not have an 'is active' indicator in the Twig template (commerce-product-variation.html.twig).
Our current workaround is to use THEME_preprocess_commerce_product_variation() to get the variation id from the 'v' URL parameter and check it against the variation id, plus get the default_variation from the product and use it as fallback, if the 'v' parameter is not set.
Issue fork commerce-3553792
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
thomas.frobieterComment #5
grevil commentedAlright, this does the trick.
I added the cache context to the variation entity class itself, to be in line with the "Product" entity cache context:
(modules/product/src/Entity/Product.php, line 293-295)
I'd say this won't introduce any issues, since the context is only valid, if the parameter exists in the url. But if one of the maintainers sees problems with this approach, we need to manually set the cache context in the template_preprocessing function or use an alternative approach all together.
Anyway, please review!
Comment #6
anybodyThanks. Now the active marker class still needs to be set on the variation, right?
Comment #7
grevil commentedSure, if we want that on the default template 🤷♂️
Comment #8
grevil commentedDone. Please review.
Comment #9
thomas.frobieterThere is no class added by default: https://git.drupalcode.org/project/commerce/-/blob/3.x/modules/product/t...
So this formatter class does not make sense.
Adding proper classes is not part of this issue.
Lets add it to the docblock instead.
Comment #10
thomas.frobieterComment #11
anybody@thomas.frobieter: FYI: Regularly a select or radio is used to choose the variation and that one has the "selected" functionality. So maybe things should be handled differently, when the rendered entity is used?
I think there should be some kind of "selected" indicator on the selected entity in this case without having to modify templates?
Maybe that means a different (inheriting or wrapping) template should be used?
Comment #12
thomas.frobieterDone. It's still not perfect without the default classes, but, as I said, that's outside the scope of this issue IMO.
Comment #13
thomas.frobieterI agree, but I don't think its up to us to invent new classes on this template. Furthermore "selected" is a technical property, which simply is required to make the select work corretly.
I'm not sure where else this template might be used. The file name tells me that it doesn't just render “Swatches.”
Comment #14
anybodyCorrect. That's what I mean by
.
So let's keep this RTBC'd as a very helpful first step for custom solutions and wait for maintainer feedback. Then in a follow-up the built-in solution should be implemented.
Comment #15
jsacksick commented"is_active" should be sufficient considering we're already in the context of variations.
The MR needs a reroll now that we've converted our hooks to OOP hooks.
Also, wondering what is best between calling loadFromContext or comparing the ?v query parameter, maybe calling loadFromContext() makes more sense so we don't have to duplicate the logic.
Also, we aren't really using this right? It's just there for peoplet o use?
Comment #17
jsacksick commentedI renamed the boolean to just "is_active". Could you confirm that still works for you @grevil, @anybody?
Comment #18
jsacksick commentedComment #20
jsacksick commentedComment #22
anybodyThank you @jsacksick!!
Comment #23
grevil commentedHey Jonathan!
Just tested it locally with the new changes. Still works as expected!
Thanks for taking the time! 👍
Comment #24
jsacksick commentedGreat, thanks for the feedback!