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.
Problem/Motivation
First step in implementing Mini Panels is to create the configuration entity/entities required to store the details. Since these share a number of similarities with Page Manager’s configuration entities, we’ll also abstract those out so semantics and mechanics can be shared between them.
Proposed resolution
- Create a
MiniPanel
config entity, analogous to thePage
entity - Abstract and share code common to them both
- Abstract the
PageVariant
config entity into aDisplayVariant
config entity that can be used with bothMiniPanel
andPage
entities - Abstract and share common interfaces
Remaining tasks
- Confirm that code being shared is all genuinely common
- Confirm that having Mini Panel variants is a desired feature
- Decide on how best to share the code (dsnopek indicated a preference for composition rather than inheritance)
- Confirm that a common
DisplayVariant
is both possible and desirable - Check that the right methods exist in the right interfaces
User interface changes
Addition of new UIs for Mini Panels that closely resemble Page Manager’s UIs.
API changes
- Share
DisplayVariant
betweenPage
andMiniPanel
(as opposed to havingPageVariant
andMiniPanelVariant
) - Abstract code that would be shared between
Page
andMiniPanel
- Common interfaces that
PageInterface
will extend.
Data model changes
New configuration entities for MiniPanels
and DisplayVariant
and removal of PageVariant
config entity.
Comments
Comment #2
andrewbelcher CreditAttribution: andrewbelcher at FreelyGive commentedWe felt that having variations on mini panels would be a useful feature as there are times when you would have a mini panels with the same purpose and parameters, but differing variations depending on information from the context. We think this is reasonable as this appears to be the direction other panels eco-system modules are considering (e.g. #1978122: Allow Panelizer variants with fall-back to another variant if access requirements fail).
On the basis of that assumption, we started by mirroring
Page
/PageVariant
for mini panels. In doing this, we found that:MiniPanel
/Page
share all their code except parts specific to the fact Page is managing an entire page (source of parameters, routes and using the admin theme) and Mini Panels is rendered via a block plugin (source of parameters). We have made both MiniPanels and page extend a new base class;DisplayBase
. This may change pending the discussion of composition vs inheritance.PageVariant
/MiniPanelVariant
were identical with the exception thatPageVariant
stored a reference to aPage
andMiniPanelVariant
stored a reference to aMiniPanel
. We think that by storing an entity type id and entity id, we can have a commonDisplayVariant
config entity that works with both Page Manager and Mini Panels.Page
andMiniPanel
also (which we’ve put inDisplayInterface
.DisplayVariant
needed to store the parent display to retrieve context set on it (as config entities are no statically cached), so we have added the ability to store (or lazy load) the parent intoDisplayVariant
and set it as part ofDisplayBase::getVariants()
. There are other ways to solve this problem if this is not desireable.page
andmini_panel
are almost identical so have made a common type to contain all the shared elements.One potential problem with using a shared
DisplayVariant
is that there is currently code that rebuilds routes when thePageVariant
is saved/deleted. We have left that in for now so we don’t break Page Manager, but it will need removal. I think that we can either:Comment #3
yanniboi CreditAttribution: yanniboi at FreelyGive commentedHere are some patches :)
We have tried to break things into logical chunks so that there isn’t too much code to review at once.
1 - 2682449-panels-abstract_display_config-3-do-not-test.patch - We have the abstract classes, interfaces, config entities, access and a view builder. Most of this code is identical to page manager, but for the new
DisplayBase
andDisplayVariant
. We also have some schema additions and updates to some tests.Notes
2 - 2682449-panels_mini-create_mini_panels_config-3-do-not-test.patch - This is how mini panels is using the abstract classes.
MiniPanel
simply extendsDisplayBase
and provides a ConfigEntityType Annotation. We also added some config schema and an info.yml file to the module.Notes
3 - 2682449-page_manager-refactor_page_manager_config-3-do-not-test.patch - This is how we have updated Page Manager to use our abstract classes in Panels. We have stripped out a lot of code from the
Page
config entity, similarly to mini panels. There are a few extras, for path, parameters and whether the page uses the admin theme. Also included in this patch is us getting rid ofPageVariant
in favour ofDisplayVariant
and a LOT of code refactoring all of Page Manager (including tests) to useDisplayVariant
.Notes
page_manager_config_translation_info_alter
and\Drupal\page_manager\Entity\PageVariantConfigMapper
.General Notes
Comment #4
yanniboi CreditAttribution: yanniboi at FreelyGive commentedComment #5
tim.plunkettWe agreed this would be in CTools, not in Panels.
Comment #6
andrewbelcher CreditAttribution: andrewbelcher at FreelyGive commentedSpoke to tim.plunkett on IRC - I'll get the abstraction patch updated put it in CTools tomorrow morning, but we'll keep it all in this issue for now to make it easier to figure out what's going on. We can break it out into separate issues when we're closer to committable code.
Comment #7
andrewbelcher CreditAttribution: andrewbelcher at FreelyGive commentedHere are the updated patches with the abstracted code moved to CTools.
Comment #8
DamienMcKennaSounds like separate issues need to be created and linked for this?
Comment #9
andypostAny reason in minipanels? core has block_content that have fields and allows to apply layouts, also you can add other blocks into this enities
It's really not clear why this functionality added!
Comment #10
tim.plunkettYou can't use block_content to place actual block plugins.
Comment #11
DamienMcKenna