Integrating Panels with Core

With Drupal 8.2 and 8.3, Panels users are going to start seeing more and more layout-related features available to them in core. As a result, there are going to be UX conflicts between what core provides and what Panels provides. It's not our responsibility to "chase" core development in Panels, but we can improve the integration between Panels and core. This is beneficial to maintainers as Panels' scope can be reduced over time, and to users who can benefit from the Panels features we contribute back to core.

This issue primarily exists to track gaps between Panels and the new core experimental modules rolled out in 8.2, and modules planned for 8.3. By identifying these gaps, contributors should be able to easily spot issues that they can work on to support this effort.

What follows are the current feature gaps between Panels (and partially, Panelizer), and core. If any list item does not include an issue, please create and/or reference one.

Outside In

• Blocks not placed in Theme regions [1] can be edited and moved using Settings Tray
• Blocks can be re-ordered and moved to other regions using drag and drop
• Block HTML is updated after an edit using AJAX
• #2784589: Provide a method for module to specify that their toolbar items should appear in Edit mode

Block Place

• Blocks can be placed in non-Theme regions [1]
• Block placement uses AJAX
• Block Content entities can be created and placed inline

Field Layout

• Fields can be moved and configured inline
• Block Plugin instances can be placed in Field Layouts
• Field Layouts use Layout Plugins
• Multiple Field Layouts can be set for one Entity View Mode using contexts
• Lots of other stuff I’m missing because I’m not a Panelizer maintainer

Planned but not yet implemented features

• A Layout Plugin that allows regions to be defined in its configuration (Flexible Layouts)
• #2660124: Dynamically build layout icons based on well formed config
• There should be a generic way to attach arbitrary settings onto Block Plugins and have those settings stored in Block Plugin configuration (this would enable “Panels Styles”)

--------------------

Note [1], a.k.a. "What the heck do you mean by theme region": I was trying to abstract things, but the short form is "Block Plugins and Layout Plugins can be used in ways Core doesn't expect".

In Panels, for instance, Block Plugins are placed in a Layout without an associated Block Entity. We would have to abstract any Outside In logic that expects Block Entities or Theme regions to be the only way people interact with Blocks and Layouts.

Outside In would need to search for Layout containers, maybe using something like data-layout-id="panelizer/node/N/en/custom" or "core/theme/bartik" or "page_manager/page/N/variant/N", then reach out to the appropriate providers for forms, configuration, and the like.

Quick Edit kind of does this with fields, in that providers of non-standard fields can define custom Field IDs which let those providers tell Quick Edit how to render the field. That same pattern would need to apply to Outside In as well.

Of course there are UX concerns here, as users would need to clearly understand what context they're using Outside In in.