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

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
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

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented

First child issue: #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue tags: +Drupal core ideas

 

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented

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

naveenvalecha
He/Him
Primary language Hindi
CreditAttribution: naveenvalecha as a volunteer commented

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

EclipseGc’s picture

EclipseGc CreditAttribution: EclipseGc at Acquia commented

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

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick at Acquia commented

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

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented

#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

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
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

eaton CreditAttribution: eaton at Lullabot commented

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

Crell CreditAttribution: Crell at Platform.sh commented

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

swentel CreditAttribution: swentel at eps & kaas commented

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

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick at Acquia commented
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

mpotter CreditAttribution: mpotter at Phase2 commented

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

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
Parent issue: » #2811175: [plan] Add layouts to Drupal
xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Status: Active » Needs review

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented

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

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
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

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Component: Idea » Prototype

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue tags: -Drupal core ideas

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

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented

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 build 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

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick at Acquia commented
Issue tags: -Needs product manager review

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

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue summary: View changes

 

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
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

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
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

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
Issue tags: -Needs release manager review

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

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented
Issue summary: View changes

Added issues per #2796173-191: Add experimental Field Layout module to allow entity view/form modes to switch between layouts

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented
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

eaton CreditAttribution: eaton at Lullabot commented

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

xjm
she/her
Primary language English
CreditAttribution: xjm as a volunteer commented

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

EclipseGc CreditAttribution: EclipseGc at Acquia commented

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

eaton CreditAttribution: eaton at Lullabot commented

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.

tezalsec’s picture

tezalsec CreditAttribution: tezalsec commented

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

zenimagine CreditAttribution: zenimagine commented

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

Kris77’s picture

Kris77 CreditAttribution: Kris77 commented

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

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett at Acquia commented

Please open an issue in the Display Suite issue queue.

tezalsec’s picture

tezalsec CreditAttribution: tezalsec commented

issue created: https://www.drupal.org/node/2897810

dqd’s picture

dqd
(formerly "diqidoq")
CreditAttribution: dqd as a volunteer and commented

Meh ... @Maxim75 this is not the right issue. You have hijacked a Display Suite issue, which is about another topic. I will try to tinker and detangle this gallimaufry ...

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented

I think we're going to love this feature. :)

Some (apparently) missing feature in the Field Layout's?

We implemented a very similar system on Drupal 7 as an lightweight alternative to using DS or panels, and these were the core things that could be considered lacking comparing the two.

Region settings

To provide an easy option to add settings to the layout that contrib could expand on, opposed to just the one settings form per layout.

i.e. something similar to the field settings cog exposing the form.

A couple use cases

HTML attribute insertion - classes, id, etc per region.

Bootstrap Layouts - sets element & attributes per region

Nested regions

Appears possible to define and render anything, though via the current field UI above looks flat and sequential.

i.e. Field Groups

Preview screenshot

It's a nice have feature if you start defining heaps of various templates. We worked out that we could effectively use about 12 separate templates to cover most non-landing page layouts.

i.e. Panels icon attribute

Probably moving out of scope, but we also implemented a way to configure the container elements & attributes, entity URL control, plus some bespoke media handling, providing a template based layout system that handled about 98% of the day to day theming requirements. All probably best left for contrib.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented

Does it makes sense to file core issue about moving field_layout module to contrib as it does not has beta version?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

@andypost: after consulting @tim.plunkett I opened #3007167: [META] Enable layout builder for form displays, and deprecate field_layout for that.

matthieuscarset’s picture

matthieuscarset CreditAttribution: matthieuscarset as a volunteer commented

Is this idea still relevant/active?

My understanding is that field_layout is not needed anymore because layout_builder now provides the expected functionalities.

Shouldn't we mark this idea as Closed (won't fix) and remove it from this list?

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

@matthieuscarset layout builder can be configured for view modes, but not for form modes - this is still only handled in core by field_layout. see #3007167: [META] Enable layout builder for form displays, and deprecate field_layout

donquixote’s picture

donquixote CreditAttribution: donquixote as a volunteer commented

I don't like layout builder as a universal replacement for traditional entity displays.
It seems to me that it targets a specific type of user that does not really exist in the projects I work with.
But perhaps I don't see the full picture.

Having field_layout in core is nice, but it being experimental may scare people (including me) from using in production.

The field_layout module (similar to display suite) is also limited in that it only allows one layout per view mode.
An alternative would be to insert layouts into a display, similar to field groups.
Doing this in contrib is always going to be messy. But in core it could work.

We could also make it easier to insert other dynamic elements into a display.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
Related issues: +#1875974: Abstract 'component type' specific code out of EntityDisplay