Add layout configuration options to the content type admin area.

[bobchristenson]

CURRENT PR TO TEST: backdrop/backdrop#4685

This is the "sibling" issue of #1131 and part of the #345 meta-issue. Also part of #378. See #2894 (comment) 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

---

Translations needed

New strings:

• Manage layout

[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 #2608 (comment):

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: #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.

[quicksketch]

This looks great! I really like how this works and the way it surfaces the ability to add field blocks. I also like that it brings together the ability to configure a display mode (under Manage Display) and an overall node-page layout (under Manage Layout). I found the whole thing to be intuitive and it seems like the sort of thing that should have been there all along.

I flagged one incorrect message shown when there's no layout added for a particular node type: https://github.com/backdrop/backdrop/pull/4685/files#r1741113906

And this needs test coverage.

[docwilmot]

I flagged one incorrect message shown when there's no layout added for a particular node type
And this needs test coverage.

Working...

[quicksketch]

The PR at backdrop/backdrop#4685 was updated by @docwilmot to add test coverage.

I looked through the changes and there are some things that aren't ideal. A fair amount of code is copied out of Layout module's normal layout_settings_form() and into layout_entity_admin_add_form(). And the code to pull out a bundle label is repeated in 3 separate places. I'll work to clean this up a little bit further.

The good news is the test coverage looks pretty good and they're all passing.

[quicksketch]

I cleaned up the code as best I could without doing any really big changes. Still should be passing all tests and (relevant) code style is all passing. This is ready for review.

[jenlampton]

I'll give this a test in the sandbox.

[jenlampton]

This is really coming along :) I think it feels really smooth, and I'm finding things exactly where I'm looking for them. Kudos!

I did find one problem that's pretty major, and that's that when you 1) already have a layout for node/% for all node types, and then use the Add Page layout link to add a layout, the new layout won't be used.

That's because the original node/% layout comes "first", and the first match will be the one that renders the page. Because the original node/% layout matches all node types, it will match, and it will appear as though my brand new layout isn't working at all :(

On the Layouts overview page at admin/structure/layouts there is a handy "reorder" button that allows you to change the order, so you can fix the problem (assuming you know what the problem is).

One quick-and-dirty solution would be to add a "reorder" button to this page also. On this node-type only page there's no concept of order, so it makes it less likely that people will instinctivelyk now what to do from here, even if we do add a button.

Can we adjust the weight of layouts when they are created, so that a type-specific layout always comes before one with no visibility conditions? I think this would be nice to see globally for all layouts - but it's especially important now that we're exposing this miniature list of only 1 or 2.

[quicksketch]

@jenlampton I updated the PR so that problem should now be fixed. When adding a layout at the same path (i.e. node/%) it loops over all current layouts at that path and set the new layout to have a weight one less than the lowest weight, ensuring the new layout always takes effect, even if another layout already exist at the same path. I think this would likely be the expected behavior, especially when there only the generic node layout vs. a type-specific layout.

[jenlampton]

It works!

I've done a quick code review also and everything looks good to me. I found one place where we may need an access check but all other refactoring can be done after code-freeze.

[quicksketch]

Access check has been added to the link from the content type. Nice catch @jenlampton!

[quicksketch]

It's been a whirlwind to complete this before 1.29.0, but we made it! I merged backdrop/backdrop#4685 into 1.x.

Again, huge props to @docwilmot for his patience and perseverance as we suggested several different approaches in this issue. We appreciate you!

This was a big effort by a lot of people. Thank you @herbdool, @klonos, @stpaultim, @jenlampton, @olafgrabienski, @argiepiano, @bobchristenson, @Graham-72, @hosef, @yorkshire-pudding, and @avpaderno all for your feedback, reviewing, and refinement on the solution.

[stpaultim]

Yes, big thanks @docwilmot. As you know, I was very excited about this issue and am so happy that you stepped up and helped with the code.