[UX][D8] Create/select layout for specific content type from the content type add/edit area.

[bobchristenson]

This is the "sibling" issue of #1131 and part of the #345 meta-issue. Also part of #378. See https://github.com/backdrop/backdrop-issues/issues/2894#issuecomment-435840573 for details/screenshots.

The Field Layout experimental module in D8 core seems to be doing this:

One of the nice improvements that went in Drupal 8.3 was the Field Layout module, which provides the ability to apply pre-defined layouts to what we call "entity displays". Instead of applying layouts to individual pages, you can apply layouts to types of content regardless of what page they are displayed on. For example, you can create a content type 'Recipe' and visually lay out the different fields that make up a recipe. Because the layout is associated with the recipe rather than with a specific page, recipes will be laid out consistently across your website regardless of what page they are shown on.

https://www.youtube.com/watch?v=mJBHQJFHqws https://www.youtube.com/watch?v=YC3zDt_cR2g

---

Newer issue by @stpaultim

Description of the need

Field blocks are one of the most powerful and useful features that are very hard to find or discover in Backdrop CMS. Over the years I have enjoyed watching the expressions of joy on the face of site architect's as I show them this feature, while growing increasingly frustrated that almost no one (including myself) finds it on their own or through documentation.

In modern Drupal, with the new layout buider installed a site architect is able to enable layouts, click manage layout for that content type and they are presented with a customizable layout that already has visible field blocks for all of their fields. It's quite easy to discover and use this ability to drag and drop fields from one region to another within the core UI.

I think that we can simulate this experience in Backrop CMS and make field blocks a much easier feature to find and use.

Proposed solution

I haven't decided on what I think is the best workflow for this yet. But, I'll share this idea to get the discussion going and I welcome ideas for how to improve on this.

1. Add a "Create Custom Layout" option to the drop down for each content type on the Content Type page.

Clicking on this link, would take person to a preconfigured layout that looks something like this:

This would already be completed and saved but could be edited:

Alternatives that have been considered

I have not yet considered many alternatives. I am sure there are more complicated and far reaching solutions to this problem, but I see this solution as a step in that direction. Since this PR does not really add or change any functionality in Backdrop CMS, it just brings an important feature closer to the surface where folks will be much more likely to find and use it on their own.

Is there a Drupal or Backdrop contributed module that accomplishes this?

The Layout System is quite different in modern Drupal, but there is a workflow very similar to this built into Layout Builder.

Additional information

In Modern Drupal, one would accomplish the same thing on the Manage Display page for a content type:

Clicking on the Manage Layout option in DRUPAL takes one to this page with field blocks that one can easily reorder or drag and drop into other sections/regions.

Concerns

I'd want to make sure that we're not confusing this feature with existing features to manage the display of content types.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop CMS now includes an easy to use wizard that makes it much easier to use the existing layout system to create custom layouts for content types and along the way helps new site architects find hidden features and better understand the layout system.

---

Original issue summary by @bobchristenson

As I started using Backdrop and learned about Layouts, I expected to be able to choose a default layout per content type in the UI. So, for example, I expected to be able to edit my content type (ie. /admin/structure/types/manage/page) and in the 'vertical tabs' see a "Layout" tab.

In that tab I'd envision a simple selector that would default to the 'default' layout template, but listed all available/active Layout templates. You'd choose one and that would be used in the backend for the content type.

I don't know a lot about Layouts, but it seems that technically making a selection here would enter a layout based on path (node/%) and would add a visibility condition for that content type....more or less making it a more streamlined (and obvious) process for per-content-type-layouts.

You'd then be able to manage/delete/whatever this layout in the Layouts screen (if you deleted the Layout or removed the condition/path, it would default the content type selection back to Default)

Just a perspective from a D7 user coming to Backdrop...hope the idea is helpful!

ADVOCATE: @stpaultim

[Graham-72]

At the moment you can set up one layout per content type, so if you want to use two or more page layout options in a site you need to define separate content types for each. You can then choose which layout will be applied by choosing the content type when creating the node e.g. content types might be 'Page type A', 'Page type B' etc. But what you cannot do AFAIK is edit a node from being one content type to another.

I am trying to think of an example where one might want to do this. Perhaps one layout might be single column, another two column? Is this what you have in mind?

One can do quite a bit with blocks, either custom blocks or ones produced by views, placing these in different regions of the layout. But in all cases one has to consider that screen width is going to impact on layout in a responsive site and it is often difficult for the site designer or editor to be in full control.

I have dreamt of a home page being a grid of regions, with the ability to drag and drop blocks into the different regions, together with the ability to specify the arrangement of blocks for each of the layout width break points. All under the day-by-day control of a site editor! Just like laying out a magazine page but with versions for widescreen, tablet and mobile phone.

[bobchristenson]

What you suggest (different layouts per node) would be ideal, but that's not what I'm suggesting here. What I'm suggesting is much simpler...just a UI tweak.

I'd expect that lots of people would like to define which layout template to use for which node type (not individual nodes). So all I'm suggesting is a UI component in the content type configuration screen that allows you to choose (via a dropdown) which layout template that node type uses.

This is just a friendlier way than figuring out that you have to go into layouts, create a new node/% layout, set conditions for content type, etc.

My suggestion is more of a UX addition that I think most people would want rather than a whole new functionality.

[jlfranklin]

Per-node layouts and per-content type layouts would make great contrib modules.

[olafgrabienski]

@bobchristenson - I like your suggestion to make Layouts visible in the content type configuration because the Layouts UI is not very intuitive in making clear how to create a Layout for a content type. For experts, it would however be a nice configuration shortcut!

So the request indeed isn't about a new functionality but about better user experience. As such, it reminds me the Better node-type permissions introduced in Backdrop 1.3.0.

@jlfranklin For the reason mentioned above I don't agree with the issue status "contrib candidate". What do you think about it?

[klonos]

This feature is available in D8.6 core via the (experimental at the moment) Layout Builder module. Once the module is enabled, a "Use Layout Builder" option becomes available in the "Manage display" tab of content types:

...once this option is enabled, the standard list of fields in that tab is replaced by a "Manage layout" button:

...which then takes users to the actual Layout Builder:

Notice that the D8 layout builder works differently than Backdrop in that it allows configuring only the layout of the main content area. To manage other areas of the page, one needs to use the traditional block administration page.

The D8 Layout Builder has a more frontend-like feel, and there is dummy/placeholder content in place of the fields already configured in the content type (image, body text, tags, links, comments). These are actually field-blocks that can be dragged from the main area into other "sections" that can be created.

Another thing that can be done is to allow per-content item layouts (#1131).

[adriannolt]

When asking on Gitter about applying layouts to non-full/default view modes, I was referred to this issue. Is this the place to discuss being able to use layouts on all view modes, is there another issue, or should I open one?

[olafgrabienski]

Is this the place to discuss being able to use layouts on all view modes, is there another issue, or should I open one?

@adriannolt I've searched the queue and found issue #2608 with the following suggestion in https://github.com/backdrop/backdrop-issues/issues/2608#issuecomment-291273853:

I think in future every view mode should be configured in Layout UI.

It follows an interesting discussion about the topic. I consider to read it and to decide then if you open a new issue (then it'd be helpful to copy some comments over) or to revive one of the existing issues.

[adriannolt]

@olafgrabienski Thank you for your pointers. I will comment on those issues over there. That said, I also love the idea of this issue, so that, from a content type's manage display area, I would be able to directly access and edit a layout for that page.

[stpaultim]

This is such a great idea, that I reinnvented it for (probably the 5th time) here: https://github.com/backdrop/backdrop-issues/issues/6434

I was not aware of this issue before or I would have posted my thoughts here. I'm inclined to keep the newer issue going, since it already has a PR ready for testing and some momentum. But, I think it's become a duplicate of this one.

The PR by @docwilmot looks a lot like what this issue is asking for. More so than I had originally envisioned myself, but I like where it's going.

@bobchristenson Should we close this one in favor of the new issue or do you think this one is different? (@klonos ?)

[jenlampton]

Should we close this one in favor of the new issue

We usually close the newer issue in favor of the older one, I'm going to copy the comments from that issue over here.

[jenlampton]

Comments from @stpaultim

I'm not sure how to create a PR to do this. But, I THINK that this should be a relatively easy PR to create for those with better programming skills than I have, because it seems like all it's doing is preconfiguring a layout using existing tools and configuration.

Any feedback on the difficulty level for this feature and or suggestions on how to get started with a PR? Maybe help with some pseudo code?

---

We talked about this issue in the DEV meeting today. Here is a link to the exact spot in the discussion: youtube.com/live/h7FkJEQpT1E?si=21jYMtZ4FbTLPKe_&t=32m16s

This will come up again at Backdrop LIVE. events.backdropcms.org/discussions/backdrop-live-april-2024/what-can-we-learn-from-modern-drupal-layout-system

[jenlampton]

From @docwilmot

This sounded like a good idea. Had a look last night. Will have a PR to demo this evening.

[jenlampton]

From @stpaultim

Looking forward to testing it.

[jenlampton]

From @docwilmot

POC PR up now.

• Adds a "Manage layouts" tab to all entity bundle configuration pages (page nodes: admin/structure/types/manage/page/layouts, user: admin/config/people/manage/layouts, taxonomy)
• That page shows all layouts overriding that entity type's display (eg node/%, user/%, taxonomy/term/%), and any layouts overriding the bundle type e.g layout with a page content type visibility condition.
• Allows adding a new layout with visibility conditions set automatically
• New layouts have all that bundle's field block in the content region automatically

Not fully tested, YMMV!

[jenlampton]

From @stpaultim

@docwilmot - It's very exciting to see progress on this. Not sure if your ready for feedback, but I'll give some easy and obvious feedback and ask a few questions.

1. Layout page for all content types is full of these errors.

Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in layout_context_required_by_path() (line 2131 of /var/lib/tugboat/core/modules/layout/layout.module).
Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in layout_context_required_by_path() (line 2138 of /var/lib/tugboat/core/modules/layout/layout.module).

2. All the field blocks are currently showing up in the footer. I think that they should be in whatever region the "content" block was.

3. Currently, the content block remains on the new layout. I would assume we should remove this block, since the field blocks would replace it. I don't think we need the "content" block on these new layouts.

4. In your PR, each entity type or content type has it's own layout page that shows layouts for that content type. I had not imagined this. I guess, I don't expect that content types are likely to have more than one layout and it seems excessive to have an entire page to list one layout. Is this an interim step in developing this feature or are you imagining that this layout page for each content type is useful?

5. I like that you are thinking about other entity types than content types. I had not thought that far out yet. But, I can see how this same feature could be very useful for vocabularies/taxonomies. Good work on this.

6. Just a note: I tested creating a layout through the content type interface and it showed up in the layout interface as expected. I also tested creating a layout through the layout interface that had a visibly rule specific to one content type and it showed up in the Content Type interface as expected.

I think, I'll leave my comments here for now, since I assume this PR is still in progress and may still be changing.

But, I love where this is going!

[jenlampton]

From @hosef

I like the idea, but I am not sure about having all the field blocks in there by default. Usually I just want the default content block and then 1-3 fields moved to other regions.

[jenlampton]

From @stpaultim

@hosef - For me, the most important part of this is to provide easy access to field blocks. If they are not all visible, then how do you decide which ones to make visible? And if the content block is visible, then some data is duplicated, unless you also change the display settings.

Any specific proposals for how you think this could work better?

[jenlampton]

From @herbdool

Looks like an awesome feature.

Maybe there's a way to provide an option of using the default content block or add field blocks. The wizard is useful for both approaches (those who just want an easy way to configure the context and visibility; and those who want a more complex layout) so it would be good to figure this out.

[jenlampton]

From @docwilmot

Layout page for all content types is full of these errors.

Should be fixed

All the field blocks are currently showing up in the footer.

Fixed

Currently, the content block remains on the new layout. I would assume we should remove this block.

Done. Wasn't sure this would be preferred, please see @hosef's comment.

In your PR, each entity type or content type has it's own layout page that shows layouts for that content type. I had not imagined this. I guess, I don't expect that content types are likely to have more than one layout and it seems excessive to have an entire page to list one layout. Is this an interim step in developing this feature or are you imagining that this layout page for each content type is useful?

This seemed the more logical way to do it for me. I suppose a single layout page per entity instead of per bundle may make more sense though, so I'm open to other ideas.

I like the idea, but I am not sure about having all the field blocks in there by default. Usually I just want the default content block and then 1-3 fields moved to other regions.

This is reasonable, but then if we're hoping this feature will make field blocks more visible, how could we do that? Pick a random field block and enable it in a random region? Open to suggestions

[jenlampton]

From @stpaultim

I would not want to loose the auto placement of field blocks, I think it's an important part of this feature. But, @hosef has made a good point that some content types have a lot of fields and there is still value to having to this feature, even if you don't need field blocks.

So, I think the option (suggested by @herbdool) to either keep the default content block or replace them with field blocks could be nice. BUT, I don't know if it's necessary. I'm anxious to hear what others think. My view of this feature is changing slightly as I see it develop.

I think it was @hosef that suggested today, that the UI could provide a list of all available field blocks and let the site admin choose which ones to expose. That sounds cool to me, but I don't want to stall progress if that is difficult to accomplish. Maybe that is a follow-up improvement?

I don't know if @docwilmot is ready for additional feedback, but I noticed a fresh update to PR and gave it a peek. It's much better already.

~~1) Most of the errors are gone. There is still one error showing up, but I'm guessing he is aware of that and working on it.~~

~~Warning: Undefined variable $rows in layout_entity_admin_form() (line 73 of /var/lib/tugboat/core/modules/layout/layout.entity.admin.inc).~~

2. Field blocks are now placed in content region by default instead of the content block. Good work on that.

I'm relucant to test this too hard yet, until we get other feedback on the progress made so far.

---

I'm trying to test this, but @docwilmot is making changes so fast, that he is breaking my test environment (I love it).

OK, I couldn't resist.

1. Maybe a little text here that says something to the effect: "Layouts used for this entity type." I would prefer "content type", but that would not always be accurate when used with other entity types.

2. Instead, maybe it says here "No layouts have yet been created for this entity type."

Just looking for some words to reinforce that the layouts on this page are ONLY for one entity type and that this is not a list of all layouts.

This is what a content type layout page looks like after a layout has been created.

---

@docwilmot Do you think it's a problem that I start out on the Layout page for a content type. /admin/structure/types/manage/post/layouts.

But, after I create the layout I'm in the layout section with no direct way back to the layout page for the content type? /admin/structure/layouts/manage/post_layout

This feels like a very minor problem, if a problem at all?

[jenlampton]

from @docwilmot

I think the normal layout block add page should be the definitive place to do layout stuff. I think we should consider this PR to just be making a shortcut to lead to that location. I think some good help text on the entity layout page, and a message after layout creation explaining what happened, maybe even a link back to the entity layout page?

Not sure. Usually this is when @jenlampton and @klonos come in right?

[jenlampton]

From @hosef

I think that if they start in the content types section, they should end up back there after going through the wizard. I can see new users getting confused by ending up somewhere else when setting up a new content type.

---

Also, in relation to the field blocks: I have worked on sites in the past that had hundreds of fields, and the idea of having to delete all the field blocks when I just want to use a display mode for most of them and a small number of field blocks sounds like a nightmare.

I think Herb's idea of providing an option of which thing to do would be the best option.

[jenlampton]

from @klonos

Thanks @stpaultim for bringing this issue here to my attention. I have not read the whole thread yet, but it seems to be a duplicate of #2894 ...right?

[jenlampton]

from @jenlampton

Wow, thanks for the quick PR @docwilmot !

Adds a "Manage layouts" tab to all entity bundle configuration pages

Instead of "Add layout: I'd like to see two different action links on this new page. Recommendations for link text the weekly meeting were: Create a layout for all content and Create a layout for [Page] content.

Create a layout for all content will create a layout for node% with no visibility rules, and Create a layout for [Page] content will create a layout for node%, and also add the visibility condition for node type = . Page.

(What we talked about in the meting was... ) In both cases the result of clicking the action link should land someone on the "Mange blocks" interface, skipping the "Add new layout" form entirely, but assuming sensible defaults (like copying the default layout + layout template).

The layout state should be saved at this point (but it should not yet be stored in configuration) - so people can get to the "manage blocks" to see what it does, but a "cancel" here would not result in a layout existing.

This is what a content type layout page looks like after a layout has been created.

If a layout already exists for node/%, that one should appear in the list of layouts also. Maybe we can separate it the same way we do "Default layouts" on the manage layouts page?

I like the idea, but I am not sure about having all the field blocks in there by default. Usually I just want the default content block and then 1-3 fields moved to other regions.

I agree with @hosef, I think the opposite is far preferable. The most common use-case is that people will only have one or two field blocks, and all other fields are shown via by the display mode. Placing all the field blocks will create a lot of work for people to remove them.

I don't think we need the "content" block on these new layouts.

~People probably will not understand they need that "existing content" block in order to get the page to work properly. (Isn't there even a warning showing on the page when it's missing?)~ Was this fixed?

I think the normal layout block add page should be the definitive place to do layout stuff.

I agree with this -- all the new stuff should just be taking people to & from the current manage layouts interfaces.

I think that if they start in the content types section, they should end up back there after going through the wizard. I can see new users getting confused by ending up somewhere else when setting up a new content type.

I agree, but it can probably be done using a destination parameter (we don't need a separate interface).

[jenlampton]

from @olafgrabienski

The most common use-case is that people will only have one or two field blocks, and all other fields are shown via by the display mode. Placing all the field blocks will create a lot of work for people to remove them.

Agreed, the 'one-or-two-field-blocks' use case is probably very common. However, it's not so much work to remove multiple blocks from a layout (hit "Remove" for every block, and save the layout). That said, I also like the suggestion to provide an option to choose the use-case.

A possible alternative: place all the field blocks in a disabled state. This way, people see at first sight which blocks are available and can enable only those useful for them.

[jenlampton]

from @docwilmot

(What we talked about in the meting was... ) In both cases the result of clicking the action link should land someone on the "Mange blocks" interface, skipping the "Add new layout" form entirely, but assuming sensible defaults (like copying the default layout + layout template).

I considered this but I dont think it is the most logical way to approach it. The user would end up with a layout with the wrong template each time (if the default template really was already sensible, the user wouldnt need a different layout for node pages), and have to go through several clicks to re-configure and save a new template each time, instead of selecting their preferred template up front.

---

I like the idea, but I am not sure about having all the field blocks in there by default. Usually I just want the default content block and then 1-3 fields moved to other regions.

I've added a switch for choosing either field blocks or main content block.

If a layout already exists for node/%, that one should appear in the list of layouts also.

This already happens. The UI doesnt yet indicate the difference between the two though, since its mostly a cut and paste of the core layout list so far. Will add details.

Recommendations for link text the weekly meeting were: Create a layout for all content and Create a layout for [Page] content

This is good. Note FYI, this PR adds layout pages for all entities, not jsut nodes, ICYMI.

[jenlampton]

from @jenlampton

this PR adds layout pages for all entities

I saw this in the demo, but forgot to mention it: these aren't Layout pages, these are all Layout overrides since they use an existing path, we should be careful not to confuse people by using the wrong terminology :)

[docwilmot]

these are all Layout overrides since they use an existing path, we should be careful not to confuse people by using the wrong terminology :)

To clarify, when I say "layout pages" I'm referring to the admin/structure/types/manage/card/layouts or admin/structure/taxonomy/tags/layouts page, not the node/% page.

[stpaultim]

Just reading through the recent comments to see what decisions still need to be made. I think that if @docwilmot has a little time and motivation, this issue could be a candidate for 1.28 release.

• [x] On the layout page for each entity type, have two links Create a layout for all content and Create a layout for [Page] content More info

• [ ] Decide on whether or not clicking on create new layout links takes people directly to "manage blocks" page? More info

• [x] Resolve potential UX issue dealing with switch between admin/structure/types/manage/page/layouts and /admin/structure/layouts/manage/page_layout. This seems like it might confuse site architects that are configuring a content type and then find themselves in the layout configuration with no direct link back to where they were.

• [x] RELATED to previous point - if one is on the list of layouts for a content type and delete a layout. One does not come back to this page as expected, rather one is taken to admin/structure/layouts, which is a bit confusing.

• [x] Fix these words. No layout pages have been created yet. More info

[stpaultim]

In the last comment, I listed the outstanding issues from recent comments. Here are my thoughts on some of them.

1 - I don't object to this idea. But, I fear that it complicates the PR a bit and might slow us down with what could be seen as a slightly different issue, creating a layout for all content. Until now, this issue is focused on adding a layout for specific entity types. I do think the suggestion is good and would be happy to see this in this PR, but I can also envision this as a follow-up issue.

2 - After clicking create layout link, should person select layout template and whether to use "content" block or "field blocks" OR go directly to block management page. At this stage, I'm inclined to keep the process as it is, because I REALLY want to see the option to replace the "main content" block with field blocks. This is, in my opinion, the most powerful aspect of this feature.

If there is an option to Create a layout for [Entity] content with field blocks - then I can see why we might skip this following page. But, since not everyone would like to replace the "main content" blocks, I think it's important that we give the person this choice somewhere before they get to the manage blocks page.

3 & 4 - I think this is a real problem, but I'm not sure of the best solution. Could there be a link here back to the page to manage all layouts assigned to "Posts"?

5 - How about these words? `No layout overrides have been created for this entity type yet."

Atten: @docwilmot and @jenlampton