Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I think Panels would be fixed if we just provide a CurrentVariationContext type thing. Depends on the product context, and returns the current default variation. Which would be the ->default, or from ?v=. This provides the divs and such for injected fields to work.
I wish the context was that simple. Panelizer's context selection is based on available typed data definitions. When you add "entity:commerce_product_variation" it shows an autocomplete search.
I wonder if there's a way to override and custom that setting form to get one from current product context.
For Panelizer, we would have to replace PanelizerEntityViewBuilder. This is set in panelizer_entity_type_alter
// Replace the entity view builder on any entity where we have a Panelizer
// entity plugin and the entity itself has a view builder.
foreach ($panelizer_manager->getDefinitions() as $entity_type_id => $panelizer_info) {
if (isset($entity_types[$entity_type_id]) && $entity_types[$entity_type_id]->hasHandlerClass('view_builder')) {
$entity_types[$entity_type_id]->setHandlerClass('fallback_view_builder', $entity_types[$entity_type_id]->getHandlerClass('view_builder'));
$entity_types[$entity_type_id]->setHandlerClass('view_builder', '\Drupal\panelizer\PanelizerEntityViewBuilder');
}
}
This sets all of the contexts. For instance there is
protected function getEntityContext(EntityInterface $entity) {
return new AutomaticContext(new ContextDefinition('entity:' . $this->entityTypeId, NULL, TRUE), $entity);
}
What we really need is to override \Drupal\panelizer\PanelizerEntityViewBuilder::buildPanelized, I think.
Here we could inject the variation context manually
I don't think we can do this. There's too many places in Panelizer where the contexts are gathered, not a single method which can somehow be overridden. It'd require too much work within Panelizer to fix.
millionleavesCreditAttribution: millionleaves as a volunteer and commented
Just checking - this issue is about Panels, but you've focused on Panelizer in your comments. Is adding support for Panels a simpler prospect and/or is Panelizer support a separate issue?
I use Panels in my sites to create variants that override node layouts. I can then place fields and blocks (including Views blocks consisting of node fields) into the variant layout.
I would like to be able to do the same with Products, and have product and product variation fields available for placement within the layout either directly or via Views blocks. If this is possible today, I haven't found the way.
Yeah. Page Manager and Panelizer expand upon \Drupal\ctools\Form\ManageContext which only provide contexts based off of typed data.
However in \Drupal\page_manager\Entity\Page::getContexts there is an event, page_manager.page_context. There is a change we can use this to inject the current variation context as entity:commerce_product_variation and support page overrides of Products.
That would expose the variation entity field blocks.
Comments
Comment #2
mglamanI think Panels would be fixed if we just provide a CurrentVariationContext type thing. Depends on the product context, and returns the current default variation. Which would be the ->default, or from ?v=. This provides the divs and such for injected fields to work.
Comment #3
mglamanI wish the context was that simple. Panelizer's context selection is based on available typed data definitions. When you add "entity:commerce_product_variation" it shows an autocomplete search.
I wonder if there's a way to override and custom that setting form to get one from current product context.
Comment #4
mglamanPanelizer uses the following to build the entity context form.
And contexts do not support configuration forms. Conditions do, which read values from passed contexts.
Comment #5
mglamanFor Panelizer, we would have to replace PanelizerEntityViewBuilder. This is set in
panelizer_entity_type_alter
This sets all of the contexts. For instance there is
What we really need is to override \Drupal\panelizer\PanelizerEntityViewBuilder::buildPanelized, I think.
Here we could inject the variation context manually
However this doesn't help us inject it, in general, for admin.
Comment #6
mglamanI don't think we can do this. There's too many places in Panelizer where the contexts are gathered, not a single method which can somehow be overridden. It'd require too much work within Panelizer to fix.
Comment #7
millionleaves CreditAttribution: millionleaves as a volunteer and commentedJust checking - this issue is about Panels, but you've focused on Panelizer in your comments. Is adding support for Panels a simpler prospect and/or is Panelizer support a separate issue?
I use Panels in my sites to create variants that override node layouts. I can then place fields and blocks (including Views blocks consisting of node fields) into the variant layout.
I would like to be able to do the same with Products, and have product and product variation fields available for placement within the layout either directly or via Views blocks. If this is possible today, I haven't found the way.
Comment #8
mglamanI can do a quick review. But I think that it's going to be just as hindered.
Comment #9
mglamanYeah. Page Manager and Panelizer expand upon \Drupal\ctools\Form\ManageContext which only provide contexts based off of typed data.
However in
\Drupal\page_manager\Entity\Page::getContexts
there is an event,page_manager.page_context
. There is a change we can use this to inject the current variation context asentity:commerce_product_variation
and support page overrides of Products.That would expose the variation entity field blocks.
Comment #10
mglamanI think we can close this as outdated. We have Layout Builder support and that replaced Panels and Panelizer