[UX][D8] Create/select layout for a specific page from the content add/edit form.

[klonos]

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

---

Original issue summary

Related to #1126

I would like to see another vertical tab that allows people with proper permissions to select a layout for a single piece of content right there from the content add/edit form. This should populate/be reflected to the respective layout visibility conditions.

[bd0bd]

This is the best solution in my mind.

[docwilmot]

I wonder if youre being caught out by the ambiguous layout terminology. Keep in mind that a "layout" is a selection arrangement of blocks at a certain path +/- certain visibility conditions. A "layout" isn't the template. You can have a dozen layouts all using the same two-sidebar template.

Having said that then, you wouldnt be able to create a layout on the node add form, since there wouldnt be the UI to arrange blocks. You also cant select a different template from that form either, since the template is bound to a layout.

And also when a layout is created is is created with a path, which for entities is dynamic (you cant create a layout for node/5, you create node/% and add a URL visibility condition for node/5).

So really the most you could do on the entity add page is add that path to the visibility conditions for a particular layout which already exists for <entity>/%, which would be unnecessary usually since the entity would already likely match.

[klonos]

Yes exactly, auto-create the node/5 visibility condition for an already created layout is what I meant with "This should populate/be reflected to the respective layout visibility conditions.".

...have to run. I will return with more details on this idea here (and a better issue title perhaps).

[quicksketch]

I'm not sure about this suggestion. Nodes are content (blog posts, articles, etc.) while Layouts are configuration (and can be moved via Config manager between sites). Tying together content with configuration like this is going to make a lot of non-portable configuration that won't work across environments.

Pages that have unique layouts probably shouldn't be nodes in the first place. For example if you had a homepage layout or a landing page layout (e.g. /photos, /videos, /news, /blog, etc), those shouldn't be nodes, they should be entirely configuration of various blocks.

[kriboogh]

I can easily imagine a situation where you have a content type "page" with a image and a body (as an example), and for page A (node/1) you want to use a 2 column template with the image left and the body right. For page B (node/2) a single column template with the image on top of the body. And for page C (node/3) a 2 column template with the body to the left and image to the right.

As a content editor, it would be nice if I could make this choice when editing a node. A bit like the panels+panelizer+in-place-editor solution in Drupal.

[sutibun]

@kriboogh ooh, that's a great example. It hit home. Especially when I am trying to use a one column layout to tell a visual story for the about page (e.g. /about) but for subpages (e.g /about/history.html ) a two column would be better

Maybe you can't create new layouts nor templates from the add/edit form but maybe you can select preexisting ones.

Now, that would make Backdrop hot.

[bd0bd]

Especially when I am trying to use a one column layout to tell a visual story for the about page (e.g. /about) but for subpages (e.g /about/history.html ) a two column would be better

It is a build in option in the CMS I have used for about 4 years on. It is strange that until now you (and Drupal) do not have this option.

[sutibun]

@bd0bd I'll bite. What's the name and website of that CMS?

[biolithic]

I think this is kind of a "system vs page" thinking problem.

"Page thinking" may be "I make the about page (by making and saving the node) and therefore at mywebsite.com/about I can see the about page. This is like making the html file about.html and therefore the physical file is "about".

"System thinking" may be "I can make different kinds of content, one node may be the main content of the about page". Then, at the address /about in the Layouts module, I can choose what content/blocks appear at that address for different types of users. This is like in a Single Page Application such as Angular in which you define the routes first (/about), then afterwards attach whatever blocks of content should appear there.

I don't think either are wrong, I just think Layouts were developed with "routes/layouts first, then plug whatever content you want into them" mentality. This is just speculation that may shine clarity.

On Wed, Sep 23, 2015 at 2:21 PM, bd0bd notifications@github.com wrote:

Especially when I am trying to use a one column layout to tell a visual story for the about page (e.g. /about) but for subpages (e.g /about/history.html ) a two column would be better

It is a build in option in the CMS I have used for about 4 years on. it is strange that until now you (and Drupal) do not have this option.

— Reply to this email directly or view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1131#issuecomment-142702985 .

[quicksketch]

Especially when I am trying to use a one column layout to tell a visual story for the about page (e.g. /about) but for subpages (e.g /about/history.html ) a two column would be better

As sort of a poor-man's arrangement, you could make something similar in Backdrop by having two separate content types: Single column page and Two column page. Or you could make a vocabulary that maps to layouts as well. Then you can set up multiple node/% layouts that toggle either based on the node type or vocabulary. Now editors can choose which layout they use when they create content.

[Graham-72]

But if you have a two column layout does it not act as one column if you put nothing in the second column, thanks to the CSS? This is how my site is handling a mixture of one and two column pages.

Correction: I am mis-remembering! This is how I have done things in Drupal using the Zen theme which has templates and CSS to handle this. I guess a layout could be devised that would do the same thing. With Backdrop I am using @quicksketch 's 'poor-man's arrangement' but it does mean setting the chosen template after creating the node. Is that a bad thing?

[sutibun]

... you define the routes first (/about), then afterwards attach whatever blocks of content should appear there.

Wow. If that's correct, I think I may finally conceptually understand how Bd Layouts work without having heavily used it (same with Angular :p)

As sort of a poor-man's arrangement, you could make something similar in Backdrop by having two separate content types: Single column page and Two column page

I can understand that but then that makes the admin section more complicated. I like content types with semantic meanings that anyone can immediately understand like blog, news, event, scene, chapter, etc. Once you introduce presentation names in what should be semantic name it becomes messy. The best way I can understand it is mixing HTML and CSS in the page like it used to be done.

I don't like hacks.

I'm not sure about the vocabulary route (I guess it's the name also) I've only started using vocabulary a bit more in Drupal. I'm not that familiar using it.

I liked the simplicity.

1. I create a page
2. add your content/text
3. click a vertical tab called "layout",
   • either stick with the default layout or
   • choose one of the different preset layouts for this specific content type (e.g. one vs two column layout)
4. Done. Publish.

The process is similar to how if you want to customize the page's URL, you just click the vertical tab called "URL path settings", modify, and you're done. No need to go to the alias section (whatever it's called) to make the changes. The relevant options are all on the edit page.

hehe. Sorry, this is one time I really was thinking solely about myself without consideration if it's right for the community at large. Or, if this might pose a bad UI.

I just liked the idea for myself. Nearly all CMS I've tried force me to modify themes and make exceptions for pages. Too much work for something like this.

No worries. I was just gushing. ^_^

[bd0bd]

@bd0bd I'll bite. What's the name and website of that CMS?

I am sorry very much but would not like to advertise this company and the CMS because of some reasons. If we select a layout file for a parent page then this layout will be automatically used for child pages but we can easily change layout for any child pages if necessary:

[sutibun]

@bd0bd something like that I guess. But, really, that UI is pretty bad. Reminds me of when I had to use an old custom shopping cart system which flopped many times and was frustrating to use.

PS: I wonder if you also hate that CMS because it doesn't always work ... ^_^

[bd0bd]

PS: I wonder if you also hate that CMS because it doesn't always work ... ^_^

Well, I would not like to talk about this matter but ok, I will tell - my business relations has been broken with this company. But the CMS is good, I would prefer to continue to work with it if not these personal problems.

[sutibun]

@bd0bd ah, gotcha.

[sirkitree]

I think the better way to do this is by having the visibility conditions for a layout support node types. That's a first step, not sure if you're wanting something that does this per node but seems like a contrib problem that could be written and then discuss inclusion into core.

Theoreticals aside, here's a screenshot of where I would think we'd want to add visibility conditions to the layout.

I think after "Node: Content Type" (or maybe along with it though each of these should be sep issues I think) then something like "Node: ID" would also make sense.

[quicksketch]

I think the better way to do this is by having the visibility conditions for a layout support node types.

We already support visibility conditions on node types, but only on paths that have a node on them. If you make a Layout at the path node/%, you'll be able to make per node-type blocks as well as entire layouts.

[sirkitree]

Ah! Excellent! Sorry for the noise.

[klonos]

So a few years later, this is now possible 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, which when enabled also allows for an additional "Allow each content item to have its layout customized" option:

...once this is enabled, a new "Layout" tab becomes available for each node of that content type:

This allows each individual piece of content to have its own layout.

[laryn]

https://github.com/backdrop-contrib/layout_nodes