Comments

bojanz created an issue. See original summary.

mglaman’s picture

Assigned: Unassigned » mglaman

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.

mglaman’s picture

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.

mglaman’s picture

Panelizer uses the following to build the entity context form.

    if (strpos($data_type, 'entity:') === 0) {
      list(, $entity_type) = explode(':', $data_type);
      /** @var EntityAdapter $entity */
      $entity = $edit ? $context->getContextValue() : NULL;
      $form['context_value'] = [
        '#type' => 'entity_autocomplete',
        '#required' => TRUE,
        '#target_type' => $entity_type,
        '#default_value' => $entity,
        '#title' => $this->t('Select entity'),
      ];
    }

And contexts do not support configuration forms. Conditions do, which read values from passed contexts.

mglaman’s picture

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

    $contexts = $panels_display->getContexts();
    $contexts['@panelizer.entity_context:entity'] = $this->getEntityContext($entity);
    $panels_display->setContexts($contexts);

However this doesn't help us inject it, in general, for admin.

mglaman’s picture

Status: Active » Postponed

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.

millionleaves’s picture

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.

mglaman’s picture

I can do a quick review. But I think that it's going to be just as hindered.

mglaman’s picture

Status: Postponed » Active

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.

mglaman’s picture

Assigned: mglaman » Unassigned
Status: Active » Closed (outdated)

I think we can close this as outdated. We have Layout Builder support and that replaced Panels and Panelizer