>> All righty. All right. It's going to be a fairly introdetect ‑‑ introductory presentation. This is me. This is the required speaker slide. UNL, university of Nebraska Lincoln for about a year now. If you want to read the rest of that, the slides are posted. So starting out first, what is layout builder? This is from Drupal.org. [ Reading definition from Drupal.org ]
Or if you have been working with people who are familiar withdrew pal, and they used panels, I just tell them this. Layout builder is panels in Drupal core, basically. We don't quite have feature parity yet, but this is a huge step forward. And that feature parity is coming.
So what are we going to talk about today? We're going to implement layout builder for content type. We're going to allow per‑entity customizations. We're going to layout builder modal and enable builder restrictions. We will talk about inline blocks and a live demo.
This is 884 with a standard install profile. At this point, I have also created the second custom block type. So the first thing when we talk about layout builder is we need to talk about view modes, because that's where layout builder works, that's the level that it works at. A view mode is something that you can use on content. If you are not familiar with them, it's a different way to display the same content differently, depending on where it is. So things that have view modes are nodes, taxonomy terms, users and custom blocks to name a few. An example of where you might use these is let's say you have an article content type. We all know what we expect the page to look at. When we go there and we look at the node. Basically all the content is going to be there. Maybe there's tags. Maybe there's a featured image. It's very prominent on the page. We might also use a teaser view mode. Same content, but maybe it's put together with a view, and maybe it will include summary text, a headline and a smaller version of that picture. So these are things that are turned on by default in Drupal core. We can use layout builder for them. We're going to go to manage, display for basic page. And all of us who have built sites have seen this screen before. And it's going to be a table of fields. We can re‑order them. How do we want them to be formated, labeled, etc. When I turn on layout builder, we have a check box, and we're going to check the box. We will talk about the second box here in a second. I'm going to click save. And now that table disappeared. When you click manage layout, it's going to take us to layout builder. So let's click the button. The first thing I will mention about layout builder is it's always presented on the frontend themes and not necessarily on the backend. So as you are working you get to see in realtime what you're doing, which is a cool feature. When we look at ‑‑ when we just checked our box, all it did is take the existing fields and dropped them into a single column, layout. So to the end user right now, as far as they're concerned, nothing has changed. There's also a toggle here to show content preview. When you go to the box, you get the labels for them. This can be useful. A lot of times I'm building, I may toggle this on and off several times. Because we're not actually working with a particular node here, Drupal is dropping in Lorem Ipsum to represent the body.
Okay. So let's go ahead and add a section. So we have layouts. In this case, we have four and this is what Drupal core ships with. This is a bit of Drupalism. You may need to train your users on that terminology. Let's insert a two‑column section. So we have this pops up on the right‑hand side. And we have configuration that is available to us. We're just going to read this 50/50. There is an option to add an administrative label. This is only something that shows up on the back‑end. Some would call it a section. Now we can start adding blocks to it. I want to go back for just a second. You can write your own layouts. And if you are building a site, you will probably get this anyway. What ships probably won't meet exactly what your designer wants you to implement. The instructions for it online are super easy to use. Really all you need is a few things. You need a yml definition, what the name of it is. Machine name. Then you have a twig template that renders out the mark‑up. You will need CSS, of course. Seems you will extend the layout default class, which is what you're seeing right here. That allows you the opportunity to go ahead and you can add additional fields here. If you want to add classes to a section. Maybe you're working with a design system where classes will be used. Maybe you want to ‑‑ maybe not give them that much power, so maybe they can select a background color for the section. You can go and refer to the settings and respond accordingly. Okay. Blocks. So anything that is a block can be inserted into the layout builder. So let's click add a block. And we get everything. So this is by default what you get from Drupal. And 95% of these, your users will never use. So, there's a module we can use to pair this down. If any of you watched Susanne's presentation this is one of the things she identified. I would never give all of this to every user. I always use layout builder restrictions. So let's say for this particular basic page we want to insert ‑‑ this is a demonstration. I don't care about the settings, but there is configuration. And then you want to, you know ‑‑ yeah. So if we save this, let's go add a basic page. The zoom thing is trying to hide my tabs. There is some lorem ipsum. So it will save it. And so, the way it's configured right now, that layout would just set up is going to be used for every basic page on the site. Effectively, what we've done is something we might have done previously with Twig templates for a particular content type. This allows us to do it in browser using layouts that we have available. I will point out that we have neutral tabs here. When we check the second box, we will get another tab there. Let's check the second box. This allows each content item basically to override the default. When you create a new node that is layout builder enabled, by default, it's still going to use that layout to find. Now we have the layout tab, so we can override it. This is unique to this particular piece of content. So next thing we're going to do ‑‑ let's set up block. So there's these things called ‑‑ it says create custom blocks. And then it calls it an inline block. It's just a custom block. But it's special. It is special in that it is an inline block and created inside of layout builder. And it's tied to one and only one entity. In this case a node. So it gets revisioned along with the particular nodes. That's all an inline block is. When you go to add one of these. Before I click add block, I want to add that this tiny settings tray is not a great place for this. We're going to fix this for a second. Okay. So it's been inserted. Now save it. There are some settings. And they also allow you to insert CSS from 7. Whatever your theme is will be loaded on this page, and maybe you want to override it.
That's a huge UX improvement. On every site that I have layout builder enabled, this module is also enabled.
All righty. And there is a settings page. Layout builder restrictions uses plugins. So it ships with one plugin enabled already. You can write your own. And I don't know if any exist, but it would certainly be possible in which you can have your own module that provides a layout restriction.
So now you load this page and we get more configuration options. So by default, everything is still allowed. We can restrict this. Let's say we want folks to be able to use one, two, and three column layouts. In terms of blocks, these are all the different categories. So let's go ahead and pair these down. What I'm doing is if you check the button for choose specific whatever, and don't check any box, you have effectively disallowed that entire category. Okay. Going to go ahead and safe that. Next we're going to talk about ‑‑ okay. So now that we have a new tool, we have the issue of where do we use this tool? Do we use it everywhere? Do we just stop using Twig templates for all of the content types, etc.? Well, it kind of depends. You need to look at the individual use cases. What you're building, what it needs to do. And in my case, at university of Nebraska, the CMS that we're building, the decision we have made at this point is we're only using layout builder for one content type. We have other content types that we're still using the traditional twig templates. That's the decision we have made there. I have done some freelance sites where I have implemented layout builder. There's one instance where I used it fairly extensively as I was building things out. The reason being is that in terms of the layouts that I needed, I already had everything that I needed. I didn't need to reinvent the wheel. And it was quick and easy in that particular case to go ahead and use existing layouts to drop content like I showed here. Like I said, it was quick and easy, and kind of a benefit, too. It saved me a decent amount of time. I never needed to touch code or template files at the node level. So that's what I have done on some freelance projects. As you get into it and you start using layout builder more and more in your projects, you may find the same thing. You have to review it on an entity by entity basis. I think at this point, we need to talk about current issues. I knew there was more to talk about. The first one is you currently can't reorder sections. So that page that I started to build there, if I changed my mind and wanted to move that two column below the one column, you can't currently do that. I would have had to add a new section and make sure I have my section settings copied to the new one, too. And I would have had to drag and drop, move all of my content down to the new section and then delete the old section, which is kind of a huge UX nightmare. So there is an issue out there. I have done some work on it. And somebody posted another version this morning. The next one is visibility controls. They need to log in and see content on that page. You can toggle that behavior based on the user this functionally works. The tests all passed. I think it probably needs somebody's user expertise to use it and take a look at it. I'm not sure if I like the work flow the way it is right now. If you want to use it on your site, that's great. Hopefully if we take it a step further and this is an opportunity for some of you out there to contribute back to Drupal core as well and take it for a test drive and post your feedback.
The next one, support for third‑party settings for components. When you place a block in layout builder, technically it's referred to as a component, even though that's not the language they use on the frontend. This can be foreign. You know how you can have settings that you can add to sections? This would allow you to do the same thing for blocks. The most obvious case is if you want to use the block class module. So, this is something, we haven't deployed this yet. But to add to the CMS, which is wrapping up development this month and it will be something that we need and I imagine many of you will need that, too.
And then we get to the issues with form names. So this first one, basically what that's for is in the settings tray, you have a form in there. The form doesn't pass validation. Validation works in the sense that it refuses to accept the submission, but it fails silently. The user gets no feedback. They click the submit button and nothing happens. They never get displayed the error. So that first one fixes that one. The second one, this one's a nasty bug. This is actually pretty bad. The page I was building there, I could revert the node to a previous revision basically we will call it a revision mismatch validation. I can no longer edit those blocks. So the only way that I can edit those in my blocks is to delete them and recreate them. So that's a big boo boo. That's a big problem. Unfortunately this one, there's no patch. It's being blocked by an upstream issue also in Drupal core. If anybody has coding experience and wants to tackle those, this is a big need for layout builder right now, because it's a bad bug.
Okay. That wraps up the presentation. Don't forget contribution day is Saturday. And then if you would like to provide your feedback on this presentation, here is a link. So there is that. And now we have time for questions. Because Chris did leave a little bit of time. I think you all should be able to unmute yourselves. Is that right?
>> Yes, we can unmute ourselves.
>> Okay. I want to see if there is anything in chat here?
>> What are your thoughts about inline blocks versus paragraphs?
>> Okay. So I purposely didn't bring up paragraphs, because it's hard to talk about paragraphs without bashing the way that some people still use them and I used them before we had layout builder. Paragraphs, the only way that I use them now is for basically repeatable fields. If there are complex data structures where things might be nested, I use them in that place in layout builder. But I don't use paragraphs like I did in sites before we had layout builder.
>> [ Off mic ].
>> Original want?
>> Content edit point?
>> It is a big change. I think that for users that are not technical, it will take a little bit more training. Once they did it, they have liked it. They just dive right in. For those of you who watched Susanne's research presentation, if you haven't watched it, go back and watch that video. It was very, very good. She talked about dropping users in and, you know, different points at which you might need to. One area that she identified is add a custom block to the very top of the add block form. A lot of you ‑‑ not block. Some users needed to block them. We can't currently do that. I don't know if there's an issue for that. If there's not, I would be curious for someone to open that. I suppose it's just a matter of time before we will need that, too.
>> Chris, one other question in the chat. When you use layout builder restrictions, do you have to go back and allow specific blocks whenever you add them?
>> So ‑‑ there is actually an issue about that right now. It's a little complicated. If a new category shows up, if I to do a web form, and the current behavior would be allowed by default. Users do that instantaneously. If I add a new, if there's a new block that becomes available, a specific category that's already ‑‑
>> Sorry, Chris. I had to mute everybody, and that muted you as well.
>> Okay. I'm unmuted again though, right?
>> Yes, you are.
>> Okay. So I think I just barely finished answering that question before the mute thing happened.
>> Maybe. That's cool. There's a module. I will have to take a look at that.
>> So if everyone will unmute themselves and let's give Chris a big round of applause. That was really awesome.
[ Applause ]
>> All right. Thanks.