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
Comment | File | Size | Author |
---|---|---|---|
#2 | 2561963-2.patch | 52.49 KB | rlmumford |
Comments
Comment #2
rlmumfordHere's a first crack at this.
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?
Comment #3
rlmumfordComment #4
EclipseGc CreditAttribution: EclipseGc commentedAfter a discussion with merlin, we're not doing this. Panel displays should be stored in whatever mechanism makes sense per use case.
Eclipse
Comment #5
andypost