The goal of this issue is to improve the Panels API so that developers can easily:
- Create a new Panels display
- Export a Panels display to an array for storage somewhere (ie. allowing Panelizer to store in a field)
- Import a Panels display from an array (validating against a schema)
- Change configuration on the Panels display, ie. set layout, place blocks, etc
- Render the Panels display
This is an alternative approach to solving the same problem as #2626944: Create Panels value object which can be serialized/unserialized with a schema to validate it
Basically, the difference is that #2626944 makes a new value object, whereas the goal of this patch is to continue working directly with PanelsDisplayVariant
objects but improving the API in an incremental way, and adding a PanelsDisplayManager
service for creating, exporting and importing
However, the goal of having an easy to use Panels API to support modules like Panelizer, Mini Panels, etc is the same.
Here's some example code using this patch:
$panels_display_manager = \Drupal::service('panels.display_manager');
// Create and configure a new Panels display.
$panels_display = $panels_display_manager->createDisplay();
$panels_display->setLayout('twocol');
$panels_display->addSelectionCondition([
'id' => 'node_type',
'bundles' => [
'page' => 'page',
],
'context_mapping' => [
'node' => 'node',
],
]);
$panels_display->addBlock([
'id' => 'entity_view:node',
'label' => 'View the node',
'provider' => 'page_manager',
'label_display' => 'visible',
'view_mode' => 'default',
]);
// Export the display for storage somewhere.
$config = $panels_display_manager->exportDisplay($panels_display);
// Import the display from storage (validating against the schema first).
$panels_display = $panels_display_manager->importDisplay($config, TRUE)
Comment | File | Size | Author |
---|---|---|---|
#21 | interdiff.txt | 490 bytes | dsnopek |
#21 | panels-display-manager-2631854-21.patch | 10.3 KB | dsnopek |
|
Comments
Comment #2
dsnopekComment #3
dsnopekHere's my first pass at this. It really should add all the API improvements with block placements from #2626944: Create Panels value object which can be serialized/unserialized with a schema to validate it, but that'll have to wait until we kill (hopefully) the
BlockVariantInterface
and can do our own thing. It also doesn't add the schema or validate against it yet, but there's a @todo for where the validation should go. This should be enough to start rendering in my Panelizer WIP, though!Comment #4
dsnopekHere's some stuff that should have been in the last patch, but got lost somehow!
Comment #5
dsnopekHere is a much overdue updated patch! It includes the schema for Panels display variants, and validates against it on import. There is an issue with the layout settings schema from layout_plugin, which depends on this issue to fix: #2646156: Define layout_plugin.settings typed config so config validates!
Unfortunately, that means the tests will fail on Drupal.org until there is a layout_plugin release. :-( Running the tests here anyway, because I want to make sure the failure is what I expect!
Comment #7
dsnopekThe failure is what I expected! So, that's good at least. :-)
Also, some merge junk snuck into that patch -- here's a cleaner version.
Comment #8
dsnopekHrm. In practice, this also sort of depends on this core patch because otherwise some blocks will fail validation (including the CTools EntityField block): #2392057: Config schema fails to expand dynamic top-level types
However, the test case here passes - I think the temporary solution is just for Panelizer (or other modules that use this service) to just call
importDisplay($config, FALSE)
to prevent validation from running until it's fixed.Comment #9
dsnopekUpdated the issue summary to make the goal, approach and outcome of this issue clearer.
Comment #10
dsnopekComment #11
dsnopekComment #12
EclipseGc CreditAttribution: EclipseGc commentedThis should all get moved to ctools schema because we're using functionally the same thing there. #2646284: Move panels block plugin schema to CTools.
Shouldn't need this. block.settings has it in core.
This shouldn't have to exist. I realize that ctools BlockDisplayVariant has this in the default config, so we're going to want a ctools issue to fix this. #2646286: Remove selection logic/conditions from the BlockDisplayVariant
I'd really like to not name things "Managers" which are not Plugin Managers.
I'd almost like to see this be "public function createDisplay($layout = 'onecol', $builder = 'standard') {" so that I can change this stuff during calling this method instead of having to call public methods on the returned object.
Either we need to elaborate on this in the validate method, or we need to remove this.
since we're not typehinting the parameter here, this should probably be elseif (is_string($builder)) and throw an exception if the parameter is not a string or a DisplayBuilderInterface object.
Same comment as the previous issue.
Comment #13
dsnopekThanks!
#12.1/3: Per our discussion, @EclipseGC is going to open the issue for this!
#12.2: Removed it, and everything still validated. You were right!
#12.4: PanelsDisplayExporter? PanelsDisplayFactory? Both of those are inaccurate when looking at all the methods together - I'm leaving this as PanelsDisplayManager for the time being... But if someone can come up with a better name, I'd be fine to change it!
#12.5: Done! But I made the arguments use NULL as there default, so that later we can look up the actual default configured for the current site (like we do in D7).
#12.6: Ok! We don't actually need the version stuff for anything right now, and it'd be easy enough to put back in later when we do need it, so I've removed it. It was more there as an example of the type of things that we might do in
importDisplay()
andexportDisplay()
to convert a Panels display to it's "canonical export format".#12.7/8: Done!
Comment #14
dsnopekI've posted a patch on #2646284: Move panels block plugin schema to CTools. that will allow us to do the following:
This should address #12.1 and make it so #12.3 isn't the responsibility of this patch. :-)
Comment #15
dsnopekAlright! Now that #2646284: Move panels block plugin schema to CTools. is in, I've updated this patch. That should address all the review from #12 - but we should hold off on merging this until after a CTools and Layout Plugin release, so that we don't break the tests. More review is definitely welcome, though!
Comment #16
dsnopekThis will be affected by #2644024: Store builder and layout in plugin collections which I'm going to try and get a patch ready for in a little bit!
Comment #17
dsnopekOk, I'm not going to postpone this on #2644024: Store builder and layout in plugin collections because that one isn't 100% essential for the -beta. Here's a straight re-roll for the most recent run of commits.
Comment #18
dsnopekRemoved some unnecessary stuff per discussion with EclipseGC on Hangouts.
Comment #19
dsnopekLet's throw this one at testbot and see what happnes! :-)
Comment #21
dsnopekThis was a simple conflict with #2558575: Provide simple UI for changing the layout which got committed last week. This patch should fix it!
Comment #22
japerryLooks good to me, added!