 Get started All right My name is Saul Willis. I'm a back-end developer at previous next. I have the good fortune to work with fine folk like we just saw before Sam I have been doing web development for an awfully long time. I think 20 years at last count. I've been in Drupal for about 10 years doing only Drupal Haven't been so active in the Australian Drupal community because I've lived overseas for quite a while spent a little time in South America Helped set up Drupal Chili and these days run Drupal Gold Coast as I live up in the northern rivers of New South Wales It's a bit about me What are we going to talk about the layout builder module? So we're going to briefly introduce the concepts of what it does and how it can help us solve layout problems Look at some best practices UI improvements, which is a very evolving space because it's a relatively new solution in Drupal some performance considerations and then little things like gotchas that are good to know before you get into implementation So what is it as a super high level overview? It is if you've come from Drupal 7 or Drupal 6 space. It is like panels So it's a layout solution and allows control over entity type layouts or also on a per entity basis the same control The version ship with 8.7 was a minimum viable product So it's important to remember that there's a lot of scope for improvements in the in the module and the space The and the UX definitely needs some polish in certain areas but I think guess the takeaway here is that we have a single core based approach to layout which is Which is really awesome So before we dive into layout builder who here has used paragraphs Wow, that is almost everyone. I was not expecting that very interesting Paragraphs is awesome. Don't get me wrong. It is a wonderful tool We still use it a lot of previous next. It is a wonderful tool in the context of data modeling where it doesn't do so well is for layout and That's where we can have sad results for content editors So here's a sample little component That is actually relatively complex So we have three tabs across the top and three accordions Down the page with some text in the second accordion which is currently open As an editor I want to go in and change accordion body to Can you guess what this edit form is going to look like? Yeah, to quote my good colleague Sam. We owe anyone who we've given this to a care package to say sorry so The big pluses of layout builder over this solution is that you can see your content changes as you're making them preview them in real time before you submit it and Layout builder is in core. It's a core supported solution So let's have a look at what an edit form looks like in layout builder So it doesn't map exactly to what we're talking about, but this is the nuts and bolts of what you'll see when you dive into layout builder there's important concepts of a section which is then You can have layouts per section and in those layouts in those sections You can add blocks and blocks is just core terminology for things coming out of the block library Introduce a new concept of non reusable blocks. So these blocks are only targeted potentially at particular pages but there's a lot of if you understand blocks how they work in in Drupal now it maps well into the Into the layout builder space So let's talk about some editorial things that we can do and best practices For looking at Drupal at layout builder How do we model our data? it's Layout builder excels at custom layout. So when you have something that really needs to be different There's not like the other stuff. It does well at that It does well when you need to Lay out your entity page as you normally would and use another potential solution like DisplaySuite or or paragraphs it excels at that too, but it's important not to lose your structured data. That's critical here The fields on the content type are still important We don't want to replicate some of the worst features of something like word process Gutenberg You run the risk of shoving everything into a big blob and not having it understandable So it's a fine line to walk. It's I'll give some pointers about how you can look at those sort of things So this leads us on to metadata versus content This is Form that we should all be familiar with that you're editing a page When you enable layout builder, you'll get a new tab the layout tab So this makes a lot of sense from a Drupal terminologies point of view Your fields are still on your edit page versus your layout Is your new tab where layout builder kicks in? Is this the best for an editor's point of view? That's another question Let's look at an approach we've taken with a client where we implemented layout builder and And tweak this somewhat and I remind you this is work in progress. There's work happening on this in core So this is the approach that we took We split the edit tab into edit metadata and So this contains things that are not directly displayed on the page. So a teaser image teaser text They will display in things like search results and we made edit content the Terminology to refer to the layout tab itself because as a content editor I come to want to change my content That's what I'm seeing on the page. That's where we've mapped it to here So this is still not perfect because we have a confusing thing of still having the content tab with inside of metadata So this is things like title and And some tags for example, these are fields on the node or on the entity that will still display When rendered so not perfect, but again evolving space So if we then move on to edit content, this is where we would see something It's more familiar to anyone's how to play with layout better This is layer builder. We can add sections and control our blocks here Again super important to remember this a work in progress. This is a possible solution. There's there's a lot of work in this space Moving on to Solution that still is not sold by layout builder and this is something where we need a Capacity to allow multiple values of something and repeat that so this is where paragraphs shines. It's it's really good tool for that It's definitely still Encouraged and we are using it in combination with layout builder There's another module called paragraph blocks, which allows you then to drill into your deltas on your paragraphs So you can specifically say I want paragraph three and put that in this area in this region There's a fascinating initiative called fieldable fields in core. It's not really initiative. I guess that's a faux pile But it's it's something that could revolutionize this space Yeah, this is right now a good solution for a lot of this is paragraphs, but it's definitely evolving space so block theming this is The full editorial experience can result in a lot of blocks and this is and Their use can be very dynamic over where they're positioned. So it's probably best to demonstrate this with a video So here we have a component that's up the top It's four columns wide. What happens when we drag that into a single single column We get reflow So that magic is a lot of well a substantial amount of investment ensuring that component can display across different different widths essentially So it's it's another design consideration you have with layout builder because the flexibility offered it results in a Potential different displays If this is not The only solution you can actually lock it down and we'll touch on the layout builder library to Possibly restrict this if this seems sort of too too open-ended and powerful an interesting Problem that we have when editing in layout builder is just the the way that it's been implemented Is it slides in on an off-key off-trait canvas on the right and it's easy to outgrow the Dimensions of that. So there's a couple possible solutions the layout builder modal module Which essentially takes any forms in your in your right hand column and lot and renders it in the modal It's not yet fully accessible and it has a number of implementation issues. So it's yeah It's it has potential, but it's it might not be the solution another relatively straightforward way Is simply widen the canvas tray? So this is the right hand canvas looking wider. So you see that we have more room to move restricting available options, so It can be overwhelming when you introduce a content editor to the block interface Both layouts and blocks when they're exposed to layout builder So The layout builder restrictions module again a contrib add-on allows you to specify sections as Well as which blocks will be allowed in those sections So you can get quite fine-grained control over what you're exposing to your editors on a similar topic. There's The layout bit a library module which I mentioned before which allows you To Avoid giving potentially too much control to the editors. So it allows you to define Which layouts you want them to be able to use so it's a lot more restricted and They can't shoot themselves in the foot Which is Which can be good again. It depends on your your your editor Styling a block. This is a common requirement A Possible solution is the stop the layout builder styles module which allows you pretty simple things you can add in classes on sections and Blocks allows you greater control in when you come to theme so another UI can Possibility in layout in the layout builder world is Quite interesting something new and it's called layout builder everywhere. So it's a relatively new contrived module by Tim Plunkett still very much in development and if there's a lot of similar concepts to its namesake, which is Panels everywhere. So the idea is basically to control the site Chrome So we don't want to be restricted to just our content area We want the same interface for layout builder with the entire content of the site so here's an example of the of Layout builder everywhere enabled you'll see that the different sections of the site Interactable so for want of a better word You can drill into the header section your content section or your sidebar You notice it introduced the concept of view and layout in our toolbar here as well So if we click in the sidebar We'll activate the layout mode and we've essentially drilled into this side bit of Chrome And we are now having the same layout builder interface for that bit of the bit of the the Chrome It's implementation is really interesting. I've only sort of kicked the tires of it briefly, but it has a lot of potential because it also Works in the way that content editors think about their site. It's all just content I want to edit it. So watch this space. I would say Let's move on to performance block blacklist is quite a useful module Drupal exposes a lot of blocks Every field on every entity type by default and layout builder performance can suffer as a result and most of the performance improvements around layout builder probably result help revive or Revolve around trying to help this this dilemma So block black blacklist totally removes a block from ever being exposed within Drupal Either another solution is custom code Which is useful for when you're controlling your entity type and you have full control over and you you understand the need for when you You want or don't want a field exposed in the in the block listing couple of patches that Thankfully on them got recently committed Massive improvement to recursive rendering The second patch is quite interesting in it. It tries to work in the space of automatically removing Blocks that shouldn't be exposed. It's a complex space And it will help layout builder performance in general, but it's again. It's evolving. It's evolving issue Let's briefly touch on some gotchas. These are things that are good to know Probably hopefully before you go implementing layout builder Translation support is interesting Translations specific layouts are not supported in it by layout builder core So thankfully contrived comes to the rescue again. There are two options symmetric Where you can translate blocks, but you can't add or delete them This has a likely path to inclusion in the core layout builder solution Versus asymmetric Translations where you can add or edit blocks as well. It's not simply a one-for-one translation This is unlikely to go into core But it could work for your your use case this unfortunately the two approaches are Totally incompatible. So you've got to choose one up front Form blocks break layout save. This is a curious one So if you have something in your layout builder form that is a form itself That could be a search form a placeholder for search a views exposed filter or web form It's very likely that that will break your save button. It's a real gotcha when you first use start using layout builder So a custom form altar can replace these with placeholders That's the that's the simple straightforward solution and there's definitely ongoing work in core 2 to solve this in a more generic way If more than one editor goes to edit your the same layout builder page at the same time You get you tread on each other's toes. It is not pretty So there's a work-in-progress patch to mimic the views UI locking system that uses temp store So essentially you'll be shown a message when you come to edit it saying this is locked Do you want to break the lock so you don't start treading on people's toes? API access is non-existent currently so Any HTTP request to fetch the layout builder field data will basically return nothing So this breaks things like default content and a slew of modules in that space It's a tricky space with ongoing work. There's considerations around the normalization of the field The validation of the of layout builder itself, which is currently heavily tied to the form API and the UI I should say an access Again, I've got you to think early on There's a lot of great resources around around this the core talks actually pretty bloody good as a tribute to our gate system that It was one of the barriers that had to be of High enough standard to introduce this module to core. So it's a it's a nice resource there there's as a couple of talks from Drupal con Europe recently on the ecosystem and What's next with the second one was Tim Plunkett presenting what's on their radar and The core issue queues the way to get involved with this. It's It's as always with Drupal. It's the it's the source to to help out so There's a lot of evolving best practice in the layout builder space There's definitely ready for use now, which is that I'd love that to be the takeaway here Consider your content architecture. Don't try and shove everything into layout builder There are gotchas things like translation API access you need to Consider these early in the design process But it's awesome to finally have a core-approved way of doing layouts And I look forward to this being the the way that we lay out content in Drupal everywhere That's it. Thank you We have a time for a couple of questions. So If I enable the layout builder for certain node type where it's been saved, is it Config yet or is it saved in content like database? Yeah, it's a really good question. Where is the layout builder data saved if it's enabled for a content type It will be saved in config. So So you enable it for pages on all pages That is in config However, if you then a layout builder is flexible enough that you can Overwrite an individual node page as well. And if you do that that is then stored in content So it's a field that's attached to that entity So the answer is both Thank you for sharing So when you say there's no API access is that means the headless Drupal cannot use this one or what's that mean? Correct. So it's not totally the configure is not exposed Yeah So if you try and access the layout builder or the layout field through a JSON API request Currently in core that field will be totally empty So there's there's a patch that allows you to access it, but it's bypassing a lot of access controls It's bypassing Validation I think is the big hold up here Oh, yeah, so because if you want to submit that field via post request to JSON There's currently all the all the validation is is highly coupled with the UI in the in Drupal So you you're bypassing that all together. So yeah, I think that that's makes sense. Oh, also, I think Headless Drupal Decapable Drupal and the content and the layout It may be not working and because it may serve several front-end So each front-end that can have different layout and yeah, does that support like a multiple layout for one page? Not quite sure what you miss a page will have So it's defined layout. Yes a one page. I have to front-end the website Will use the same page data. I See what you mean. Yeah, so that would be kind of the responsibility of your front-end to render the same layout data in different ways But by default the layout builder is only going to implement one one Type of control of the layout and that's it. It probably could be custom-modified to allow multiples But that would be you'd be getting a lot of work. Yeah, you think about yeah, thank you Yeah, no worries last question Just a quick one. Can it work with view modes? Yes, you can yep That's true, although Yeah, that's a really good point You would still have that. No, we're thinking of a feed here. So Similar, yeah, but you'd still have the only the one fit you would only define the layout once So you unless you had something in the pipeline that changed the output You're still gonna be defining the layout once and you could output them differently per view mode perhaps and they have your front-end consume that It's it's a really tricky space because your front-end app your react whatever it is decoupled is Got it pass and interpret that layout data and do something with it So that's that's why it's it's highly coupled with Drupal right now. So Yeah All right, let's think so one again once again