Problem/Motivation

The Field UI allows the rearranging of fields for a given piece of content, both for the authoring form and for the content display.
Each type of content can have multiple "view modes" (full, teaser, etc.), each which can have their own arrangement of fields. There is no concept of regions or sections, the fields can only be ordered.

In the contributed module space, modules like Panelizer and Display Suite enhance the display of content by adding support for layout, alongside many other functional improvements.

Also currently a contributed module, Layout Plugin is a module that drives the Layout mechanism of the above modules, but has no UI of it's own. It simply discovers and exposes layouts as an API.

Proposed resolution

Add the ability to choose a layout for each view mode, within Field UI.

Because entity displays are used for forms, this will allow site builders to customize the layout of the authoring form. Fields can be shown or hidden, and rearranged into any chosen layout. Each type of content can have multiple "form modes", each with a layout.

Entity displays also control the rendering of content. Different "view modes" are used when content is displayed in different places: shown as a paged list of teasers, when displayed in a sidebar as a bulleted list of titles, when shown as a canonical representation on its own page, etc.
These too can each have their own layout, with fields rearranged and toggled as necessary.

The first iteration will begin by hardcoding a few example layouts (one with top/bottom, one with left/right).

Proposal roadmap

Must-have

  • In order for Field Layout to become stable, the Layout API on which it depends must be stable first. So every must-have for #2811175: [plan] Add layouts to Drupal also is a must-have for this module.
  • #2840832: Add layout templates based on Panels layouts to core
  • Usability review of UI texts
  • Complete module handbook page as linked from hook_help()
  • Usability and accessibility review and testing of the user interface. (Out of scope: fixing existing usability and accessibility problems with the field UI.)

Should-have

Could-have

  • #2820210: Add Settings Tray support to field_layout
  • #2846395: Increase module weight of field_layout
  • Per-entity overrides
  • Front-end UI to change layouts (determined to only be desired after per-entity overrides lands
  • Explicit followup issue added to the @todo for:
    +++ b/core/modules/field_layout/src/Entity/FieldLayoutEntityViewDisplay.php
    @@ -0,0 +1,24 @@
    +  public function getDefaultRegion() {
    +    // This cannot be provided by the trait due to
    +    // https://bugs.php.net/bug.php?id=71414 which is fixed in PHP 7.0.6.
    +    return $this->getLayoutDefinition($this->getLayoutId())->getDefaultRegion();
    

    and similar in core/modules/field_layout/src/Entity/FieldLayoutEntityFormDisplay.php.

  • Full integration with Context system to allow Panels-esque placement of other non-field content (block placement in Field UI?!)

Not in scope

Remaining tasks

Create child issues

Comments

tim.plunkett created an issue. See original summary.

tim.plunkett’s picture

Issue summary: View changes

This plan was discussed by the following people:
Gábor Hojtsy, xjm, japerry, tim.plunkett, Bojhan, DyanneNova, stevector, dsnopek, ted.bowman, alexpott, yoroy, dobe, hestenet, Crell, swentel, aspilicious

tim.plunkett’s picture

xjm’s picture

Issue tags: +Drupal core ideas
tim.plunkett’s picture

In the child issue, I've started on an experimental module called "Field Layout", which is just what I picked to get started.

@swentel suggested "Entity Layout", since we're not configuring the layout of the fields, but of the entity.
@Wim Leers further pointed out that we're dealing with entity display objects, so "Entity Display Layout" would be more accurate.

Any objection to calling the experimental module "Entity Display Layout"? Note that this name is just for the experimental phase, it would ideally be subsumed by the Entity Display system and Field UI once stable, there would not be a stable standalone module.

naveenvalecha’s picture

+1 for the Entity Display Layout b/c that sounds accurate for the layouts

EclipseGc’s picture

Is this going to be view mode based? I.E. are we coupling view modes with layouts?

webchick’s picture

Just... Layout? :) Please? :) Because hopefully eventually this module will be expanded to cover all of Drupal's layout needs?

tim.plunkett’s picture

#7 It's tied to entity displays, which are indeed per-view mode (an exported config file for an entity view display might be called core.entity_view_display.node.article.teaser.yml, for example)

#8 That's an interesting thought. On one hand, someone coming to Drupal doesn't care about the distinction between blocks and fields, they just care about Layout. But it's not this module's job to bridge that existing gap.
However, Layout should be something baked into all of core. If I were writing this as a patch, and not as an experimental module, it would just be changes to \Drupal\Core\Entity\EntityDisplayBase and friends, and \Drupal\field_ui.

tim.plunkett’s picture

Title: [plan] Add layouts to entity view modes » [plan] Add layouts to entity displays (both form and view)
Issue summary: View changes

Trying to rewrite this to better convey the significance.

eaton’s picture

Really fantastic to see this come together. Even if it ONLY applied to edit forms, it would be a huge benefit — right now we can use field groups to break up the main content area in node forms, but moving tags into the right side along with authoring information (for example) requires squirrelly digging into the intersection of FormAPI and the theme system when it really shouldn't. It'll make a big part of tailoring the authoring experience in Drupal much, much, MUCH smoother.

Is this going to be view mode based? I.E. are we coupling view modes with layouts?

While it would be awesome to implement a generalized layout management system, exposing a layout per view mode seems like this is a good, high-value first application of the concept. If folks think underlying "entity display layout" plugin type that's being defined could reused (or reused with additions) in other parts of Drupal, I'd say name it "Layout" and treat this as the first implementation.

I think it's valuable enough as is that it should not be held up in hopes of getting a generalized layout system implemented.

EDIT: To clarify, I was talking about the combination of this patch and #2296423, which is a natural iterative improvement on this one.

Crell’s picture

First comment: Aw heck yeah! About time we looked into doing this! Bring it! :-)

My understanding is that the contrib layouts module is sufficiently abstract that it could be used for both view mode layout and other-stuff layout, by design. If the intent here is to use essentially that model but just for view modes, I would agree with Eaton that naming it with the intent that at some point in the undefined future we could/would start using it elsewhere. We don't need to actually use it elsewhere yet in order to make it useful here, just keep an eye toward decoupling it enough that we can later.

A limitation of one view mode gets only one layout is, I think, entirely reasonable at this point and still a epic-sized win over core's status quo today.

TimPlunkett++

swentel’s picture

If we'd go for Layout (which I don't mind), what about we (potentially) move #2296423: Implement layout plugin type in core into the experimental module maybe as well. That was the original idea there, but moving it into the experimental would give us more time to flesh out any needs that we need there as well, instead of being 'stuck' as an Plugin manager that's baked into core. I'm close to open an 8.x-3.x branch of DS. If we could depend then on the 'layout' module which alters entity view modes and exposes the layouts, it seems like a really good path forward to experiment with. While that works out fine for DS, I'm not sure if that would work for the Panels ecosphere, that's something that tim and/or dsnopek could answer better.

webchick’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: entity system » Idea

Moving over to the new Drupal Core Ideas queue while we get this into shape.

mpotter’s picture

I would love to see this for Form displays. Currently we can use Panelizer for node view modes, but still not for form modes. I think a consistent handling of Layout in core that would work for either of these modes would be really nice to have. Right now it's very difficult to alter the node edit form (putting stuff in the right sidebar), which surprised me.

tim.plunkett’s picture

xjm’s picture

Status: Active » Needs review
xjm’s picture

In the initial step for this plan, #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts, the consensus for the module name is "Field Layout". That communicates exactly what the module does once you know what a field is.

The layout API that Field Layout (and other layouting tools) will depend on was added in #2296423: Implement layout plugin type in core.

Based on the largely positive feedback above, I think this plan is also RTBC enough for at least review of the idea and prototype; both it and the initial prototype in #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts are ready for maintainer review.

xjm’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs product manager review, +Needs release manager review, +Needs framework manager review

And adding the tags. I imagine we'll evolve the specifics of the plan as we review the prototype issue, just as we have done with other experimental modules, but we should review them together.

xjm’s picture

Component: Idea » Prototype
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue tags: -Drupal core ideas

(Removing redundant tag; this is already in the Ideas queue.)

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

The summary lists these possible next steps from the original post:

  1. Allow themes to opt to use the new layout system, integrating it with Block UI

    Is this #2811179: Allow themes to provide Layout API integration? Probably part of the scope of #2811175: [plan] Add layouts to Drupal, not this plan.

     

  2.  

    Per-entity overrides

    Could?

     

  3.  

    Front-end UI to change layouts

    I think the API added in #2811175: [plan] Add layouts to Drupal could be stable without a new UI, so part of this one probably belongs here scoped as "Front-end UI to change entity layouts". (#2660124: Dynamically generate layout icons based on well formed config is, I imagine, only the very first step of this). This is at least a "should". I think we will need product management feedback on whether this is a "must" for this module. @webchick said she considered whether or not we would need a new/better UI to be part of the UX gate for the module (i.e., based on user testing of the alpha module).

    Whether or not we offer a somehow unified UI for all implementations is... well, scary. :) But it will depend on what other implementations (if any) we add and support in core, and product manager feedback.

     

  4.  

    Full integration with Context system to allow Panels-esque placement of other non-field content

    Is this #1787942: Allow assigning layouts to pages? I think it's part of the parent issue, not this one.

webchick’s picture

We reviewed this on our Issue Queue Review meeting today.

From a product management POV, the killer feature we are going for here is a "landing page", where you create a page, select a layout, and populate it. However, that is not what we're talking about here. And until we're talking about that (per-node layouts, in a later plan issue), it makes sense for the "could-have" list which contains issues that would expose this functionality to content authors to not be in the "must-have" list.

Nevertheless, this makes for a useful feature on its own for site builders, to be able to set different layouts on a per-content type basis. We are comfortable with the list of must-haves from that POV.

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
tim.plunkett’s picture

Issue summary: View changes

#25:

1) Yes, removed from this issue
2) Yes, moved up
3) This was #2820210: Add Settings Tray support to field_layout, but isn't happening anymore with this MVP. Still put a "Could" in mentioning the per-entity overrides
4) No, that needs its own issue. Basically, block placement within Field UI. Moved it to "Could"

tim.plunkett’s picture

Issue summary: View changes

Adding #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase as a "Should", if consensus is gathered will move to "Must"

xjm’s picture

Thanks @tim.plunkett! This all looks good to me.

tim.plunkett’s picture

xjm’s picture

Component: Prototype » Active Initiative
Status: Reviewed & tested by the community » Active

The prototype is in, and this is now an active (part of the) initiative also. Great work!

Keeping the FM review tag on for now pending confirmation that this roadmap is correct from that angle as well, though I believe it is based on @effulgentsia's review of the initial prototype.

eaton’s picture

From the Layout sprint in Baltimore, a quick summary of the discussions about status of and next steps for this initiative:

  • #2840832: Add layout templates based on Panels layouts to core An underlying plugin (and accompanying discovery system) that can expose reusable "layouts". These layouts are meant to be "usage agnostic" and are not inherently tied to Drupal's existing theme region system. This is complete, although there may be some internal changes to support the other features outlined below.
  • An entity Form Layout tool that allows site builders to choose a Layout for any entity's add/edit form, and place each customizable field *in a given Layout slot*, much like the Field Groups module allows fields to be assigned to collapsible divs etc. (Already nailed in this issue)
  • An entity Display Layout tool that allows site builders to choose a Layout for any entity bundle's display mode, and place each renderable field in a given layout slot. Again, this would require a UI much like Field Groups.
  • An advanced Display Layout tool that allows content creators to override the bundle's default Layout and field placement for a specific entity.
  • A new field type that allows content editors to choose a Layout and populate its slots with blocks, existing entities, etc. This field type could be added to a node type and used to create simple one-off "Landing Pages" whose structure and data needs are wildly divergent. CraftCMS' "Matrix Field" works in a similar way, and under the hood the D8 release of Panelizer uses a similar way to store one-off layout and structure information on individual nodes.

If this looks good, I can turn it into a plan/meta issue for the next steps, or update the overview for this one and create some new sub-issues.

xjm’s picture

So, trying to parse through #37 and see what might be needed for roadmap updates:

  1. An entity Form Layout tool that allows site builders to choose a Layout for any entity's add/edit form, and place each customizable field *in a given Layout slot*, much like the Field Groups module allows fields to be assigned to collapsible divs etc.

    Isn't this already done by Field Layout, or did I miss something specific?

  2. An entity Display Layout tool that allows site builders to choose a Layout for any entity bundle's display mode, and place each renderable field in a given layout slot. Again, this would require a UI much like Field Groups.

    Isn't this also accomplished by Field Layouts already?

  3. An advanced Display Layout tool that allows content creators to override the bundle's default Layout and field placement for a specific entity.

    This definitely wants its own Ideas issue, I think.

  4. A new field type that allows content editors to choose a Layout and populate its slots with blocks, existing entities, etc. This field type could be added to a node type and used to create simple one-off "Landing Pages" whose structure and data needs are wildly divergent. CraftCMS' "Matrix Field" works in a similar way, and under the hood the D8 release of Panelizer uses a similar way to store one-off layout and structure information on individual nodes.

    This is terrifying and sounds contrib-y to me.

Let me know if I've misunderstood these things; screenshots of Field Layout showing what it's not doing already might help.

EclipseGc’s picture

Just as an FYI, I filed #2874074: Introduce field type that renders arbitrary elements in a selectable layout Saturday after the sprint. Tim and I have been working on functionality and testing, and I think we're at a point where we can begin trying to implement DyanneNova's UI mocks.

Eclipse

eaton’s picture

xjm, you're entirely correct that #1 and #2 are covered by Form Layout and Field Layout — I just hadn't updated those with the correct links before I was felled by DrupalFlu and disappeared. As Eclipse said, #4 is covered by #2874074: Introduce field type that renders arbitrary elements in a selectable layout. I'm catching up on things, but #3 (layout overrides) is IMO a nice-to-have but not required for core as long as the Field Layout mechanism can be hooked into by contrib. Supporting per-bundle/display mode layout control in core is… a radical step forward, to say the least.

Maxim75’s picture

Hi , sorry to place this here, but couldn't find a better location.

Using Drupal 8.3.4, I tried installing the field_layout module to give it a try, but both installing and uninstalling give me this error:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of core/modules/field_layout/field_layout.install).

Now the checkbox says it is installed, but it won't let me uninstall, without the above error.

I should mention I have Display Suite installed as well, is it conflicting?

I wish a clean deinstall of field_layout, what to do? Thanks!

Cheers.

zenimagine’s picture

I also display suite to install and I encounter the same problem

Kris77’s picture

I have the same problem....with display suite installed it is not possible to install FIELD LAYOUT module...

tim.plunkett’s picture

Please open an issue in the Display Suite issue queue.

Maxim75’s picture