So in trying to map out everything required to do this properly for our various requirements, I stumbled on the fact that we need a Display config entity that roughly corresponds to the display table from D7 and earlier.

Why?
At first this didn't seem necessary. We can easily define the configuration requirements into our DisplayVariant plugin and store all of this within page_manager's config entities, however our needs are more nuanced then that, and this would require any module wishing to use panels displays to do this same work for themselves, and there are at least 3 or 4 of these: PageManager's Panels implementation, Mini Panels, Panelizer and Panels Everywhere . More over, we've discussed the possibility of this becoming a fairly complete definition of how a page is to be rendered and that Display Suite could make use of something this generic as well (if they so chose).

How?
A new config entity, it'll need to track the machine name (obviously), the layout, and then the blocks & configuration and it will also need to figure out what contexts were mapped into which blocks and determine how many contexts and of what type(s) were mapped into the blocks. (visibility conditions will need to be attached to the block configuration as well) With this information it'll set the required contexts of the display object. This is actually super useful as a baseline requirement of a display object and also happens to map identically to mini-panel's needs.

When?
Nowish would be good. This is basically the generic storage mechanism for this data and minipanels, panelizer, and others can all leverage it directly as soon as it exists.

Eclipse

CommentFileSizeAuthor
#2 2561963-2.patch52.49 KBrlmumford
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

EclipseGc created an issue. See original summary.

rlmumford’s picture

Status: Needs work » Needs review
FileSize
52.49 KB

Here's a first crack at this.

  • Added a PanelsDisplay entity that stores the block and layout configuration for the PanelsDisplayVariant.
  • Stripped the block collection code out of PanelsDisplayVariant and put in in the PanelsDisplay entity.
  • PanelsDisplayVariant::build() now passes straight through to PanelsDisplay::build()
  • PanelsDisplayVariant::buildConfigurationForm() now loads the entity add/edit form for the PanelsDisplay entity.
  • Added a 4 routes for managing the blocks on a panels display. These are currently set to use the PanelsDisplay update access for their access, but this currently is just set to true. I don't know how best to control the access; If a PanelsDisplay is used on a page manager Page we probably want to defer to the Pages update access.
  • The only contexts available to the display are currently whatever the PanelsDisplayVariant passes in, I guess we will consider the contexts set on the page as the 'Required Contexts' for the display and then make it possible to add more contexts an relationships in the display itself.

Either way, this has basically replicated the current PanelsDisplayVariant functionality but uses a PanelsDisplay config entity instead. Shall we leave new functionality to later issues?

rlmumford’s picture

Issue tags: +D8panels
EclipseGc’s picture

Status: Needs review » Closed (won't fix)

After a discussion with merlin, we're not doing this. Panel displays should be stored in whatever mechanism makes sense per use case.

Eclipse

andypost’s picture