Product Variation is without context in view based listing of Products when using Layout builder for managing product display

I'm not sure if this is related.

So

I have a product with LB (layout builder) enabled.
I am displaying variation fields in LB.
If the current product has no variations entity, then I get this error.

@lukasss That is a different issue reported at #3185884: Layout Builder for product with empty variation field not working

Patch from #4 did not work for me. It looks wrong with implementation of hook_entity_prepare_view().

As described at https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... , the third parameter $displays is keyed by bundle name not by view mode name.

I corrected it and it is now working for me.

This needs tests. I haven't worked on the layout builder integration myself and I don't really want to commit a fix blindly without making sure this doesn't break anything else.

I don't think it needs to be committed. The above patch is just a workaround.

I have tested the patch on my side, it works as expected, but I have improved it a bit.

This is due to the fact that the ProductVariationContext only works in a single instance.

You may want to investigate more in something like this code:

      // @todo Simplify this logic once EntityTargetInterface is available
      // @see https://www.drupal.org/project/drupal/issues/3054490
      elseif (strpos($this->routeMatch->getRouteName(), 'layout_builder') !== FALSE) {

commerce 8.x-2.29
10# not applay

Patch #17 works as expected.
Thank you, @Christian.wiedemann!

I have exactly the same error...will this be fixed? how to apply #17? it is a merged request? Where is the patch url?

i applied the patch, the error is gone, but in a view i get so many duplicates of the same sku, before I did not have any when I used fields in view, so is this related to patch?

MR includes .idea/ PHPStorm config, which is probably not desired.

This doesn't work for views unfortunately. The LazyContextRepository statically caches the first product variation, so in views with multiple products, the product variation will always be the first variation in the list of rendered entities, i.e. all results in the view will only show data for the first product's variation. I'm working on a fix but it may not be possible without overriding the LazyContextRepositoy.

So I've overridden the context repository in commerce_product. I'm not sure if this is the best approach, but take a look and let's see if we can get this merged and working.

The patch is based of the diff from Merge request !83, with an extra service override.

#23 works
drupal 9.5.5

Setting the status to "Needs work" as we really need tests coverage to ensure this doesn't break in the future again.

#23 works for me. I've not been able to get the MR to apply.

Commited the patch from the MR, thanks everyone!! Committed.

A new release including this fix was tagged yesterday (2.34) and it already introduced 2 critical issues so decided to revert it and we'll target a proper fix in 2.36 I guess.

See #3351579: Commit of 3180541 leads to out of memory error and #3351333: Error: Call to undefined method Symfony\Component\HttpFoundation\RequestStack::getMasterRequest() for reference.

I’ve found one more problem with those changes. As it uses "hook_entity_prepare_view" when we try to render multiple products programmatically it adds the last one to the request attributes. As a result, we have incorrect data from variation(price, SKU, etc.) because it will be taken from the last product in the render list.

One more issue with the patch is that Drupal does change the already existing context. So, for example, if we going to display multiple products, even though we find a way to set the correct variation entity in the context for every product on the page, the data from the first variation will be shown for all of them.

While #23 works for me without any of the problems other folks have experienced (yet), I think I have an example of #39 too. On product A, I have a "Similar products" entity reference field, which references product B. Next, I'll make a view called "Similar Products", intended to be displayed on product A. It'll take the current entity as the argument (A), relationship load the entity from A's Similar Product field (B), then relationship load the variants from that relationship (B's variants). At this point, if I display the product variant View field "Image", then B's variant's images will be displayed (both in the View preview and on the product A entity). But, if I tweak the View from Fields display to Rendered entity display, then I will see the correct B's variant's image on the View preview but, on the product A entity, the image will always show Product A's Image instead.

@tBKoT: patch branch needs to be rebased.

we have the same problem. Is there already a working patch for this problem?
We use :

commerce: 8.x-2.36
D10.1.6
PHP 8.2.13

@Mav_fly: Have you tried the patch from the merge request?

The code of referred modeules does not correspond with te proposed changes. We use the latest Drupal code 10.1.6 and php version 8.2.13.S
So the patches can't be executed.

@tBKoT:

I’ve found one more problem with those changes. As it uses "hook_entity_prepare_view" when we try to render multiple products programmatically it adds the last one to the request attributes. As a result, we have incorrect data from variation(price, SKU, etc.) because it will be taken from the last product in the render list.

We're still using the hook_entity_prepare_view(), so I guess this comment is still valid? Because this hasn't been RTBCED yet, I'm a bit reluctant to get this in for 2.37, so we should look aim to include the fix in 2.38.

@tBKoT: For the new event subscriber introduced, could we conditionally register it using a service provider instead?
Also, I wonder if we can get an RTBC here...
@Morbus Iff? @Dubs? Anyone?

Patch with the latest changes in MR 83

@tBKot: Thank you! Committed!

With this patch committed, looks like #40 is still an issue for me.

Hi @morbus-iff
Could you describe a bit more how I can reproduce the issue? I've tried a bunch of manipulations to catch the issue you faced with. Is it possible to add step by step on all your way to add "Similar products" on the product page? Especially the display configuration for product and variation as you use "Rendered entity" display

When applying the patch on Drupal 10.3.1
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2024-02-05/3180541-48.patch

I'm using the Commerce Core 2.39 (tried also with dev version)

My error code:

Drupal\Component\Plugin\Exception\MissingValueContextException: Required contexts without a value: commerce_product

Here is the Call stack:

Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping (\home\user\site\public_html\core\lib\Drupal\Core\Plugin\Context\ContextHandler.php:150)
Drupal\block\BlockAccessControlHandler->checkAccess (\home\user\site\public_html\core\modules\block\src\BlockAccessControlHandler.php:92)
Drupal\Core\Entity\EntityAccessControlHandler->access (\home\user\site\public_html\core\lib\Drupal\Core\Entity\EntityAccessControlHandler.php:109)
Drupal\Core\Entity\EntityBase->access (\home\user\site\public_html\core\lib\Drupal\Core\Entity\EntityBase.php:329)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion (\home\user\site\public_html\core\modules\block\src\BlockRepository.php:63)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build (\home\user\site\public_html\core\modules\block\src\Plugin\DisplayVariant\BlockPageVariant.php:138)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare (\home\user\site\public_html\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php:270)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse (\home\user\site\public_html\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php:128)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray (\home\user\site\public_html\core\lib\Drupal\Core\EventSubscriber\MainContentViewSubscriber.php:90)
call_user_func:{/app/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111} (\home\user\site\public_html\core\lib\Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher.php:111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch (\home\user\site\public_html\core\lib\Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher.php:111)
Symfony\Component\HttpKernel\HttpKernel->handleRaw (\home\user\site\vendor\symfony\http-kernel\HttpKernel.php:186)
Symfony\Component\HttpKernel\HttpKernel->handle (\home\user\site\vendor\symfony\http-kernel\HttpKernel.php:76)
Drupal\Core\StackMiddleware\Session->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\Session.php:53)
Drupal\Core\StackMiddleware\KernelPreHandle->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php:48)
Drupal\Core\StackMiddleware\ContentLength->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\ContentLength.php:28)
Drupal\page_cache\StackMiddleware\PageCache->pass (\home\user\site\public_html\core\modules\page_cache\src\StackMiddleware\PageCache.php:106)
Drupal\page_cache\StackMiddleware\PageCache->handle (\home\user\site\public_html\core\modules\page_cache\src\StackMiddleware\PageCache.php:85)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php:48)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php:51)
Drupal\Core\StackMiddleware\AjaxPageState->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\AjaxPageState.php:36)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle (\home\user\site\public_html\core\lib\Drupal\Core\StackMiddleware\StackedHttpKernel.php:51)
Drupal\Core\DrupalKernel->handle (\home\user\site\public_html\core\lib\Drupal\Core\DrupalKernel.php:741)
{main} (\home\user\site\public_html\index.php:19)