 Hello. Thank you all for coming. My name is Tim Plunkett. I'm a principal software engineer at Aquia on the Drupal Acceleration Team on the co-initiative lead for the layout initiative and the primary author of the layout builder module. Do I need to push this button? Are we good? Great. Thank you. So the good news is layout builder is stable. The other news is that that's not really news. That's been true since May. But so the 8-8 release, which is coming out in a month, will be the second release where layout builder is stable. Still something to celebrate. What's happened since then? 12 bug fixes, a couple more criticals, a couple minor cleanups, one feature that allowed for custom labels for sections, which isn't really that much there. Why is that? The reason is that in the last six months the focus has shifted away from the stable layout boundary core to contrib. Now that there is both a stable layout API and a new module with the UI patterns that have been added, contrib is really where the focus has been. There are a lot of new, it's kind of an experimentation ground for all the new ideas. So I'd like to talk primarily about that. So as the 8.7.0 version we launched was sort of the MVP, the minimum viable product. We had to hit that deadline, otherwise it wouldn't have been stable six months ago and we'd be waiting for it for next month. So we left out, there were some of the things that were left out that we knew would be good but we just didn't have time to land in time. The other thing is that there wasn't really time for user testing. We had had feedback on their initial designs, but from the time we had the designs to the implementation, there was no time to actually validate the implementation and see if it really actually panned out when people were put in front of it. And while the functionality has been really well received, the user experience really isn't quite there yet. And for me, I want it to be just as good to use as it is, the functionality is really not worth it without a nice experience for people, for the content authors, for site builders. The end user of your site won't be able to tell the difference anyway, but as a core module, I think the user experience is really important and we need to sort of improve that. The good news is that there is a contrived module currently called it Layout Builder UX, LB UX, and it's kind of implementing some of the designs that have been proposed. There's been a couple of different improvements suggested. We've only built one so far, but the whole module could eventually be moved into core. There's a lot more work to do. There's both more, as I said, there's designs to be implemented. There's also a lot that could be suggested. A lot of suggestions needed from end users, from the community, from everyone. But one of the struggles there is we don't really have, throughout all of Groupal Core, there's no real way to share designs between designers and developers in the community to sort of iterate on those and comment on those. I noticed that, for example, the Claro initiative used Figma. It's a great success. So far with this work, we've been using a tool called Zeppelin, but it's not really integrated into the Drupal Issue queue at all and there's oriented Drupal Slack. So it has been a real challenge to sort of take those proposals and then work on them as a cohesive group. So if anyone has any suggestions on that, that at a meta level is very important, in addition to the actual designs produced by those tools. Another module we've been working on is called Layout Builder Everywhere, which is maybe not the final name of it. It's kind of a placeholder name inspired by the Panels Everywhere module, if anyone had ever used that. The idea is that you can use the Layout Builder UI to configure the header, the sidebar, the footer, the regions of your page around the main content. It includes a nice little integration with the Toolbar module, which I will show you. It's not quite done. There's a couple of known bugs, but there's a lot that could be done there. And it would be really nice, as you'll see from my demo, that I really don't like the block UI. I worked on the block UI twice. I reread the block UI twice and I still don't like it. And then I think this is maybe the third time in the charm, we'll be able to remove that sort of way of interacting with your Drupal site and really embrace the layout of the UI. So I'm going to take a breakdown and demo these two modules. I'm going to try to do that. There we go. All right, so this is a stock Drupal 8.7.0 install of Umami. This is just, as I said, I've made no changes to this site. So the Umami by default uses Layout Builder, but Layout Builder only currently focuses on this main region. So in order to change this content, there's a Layout tab that once you click it, you can then rearrange your fields. So there's this body field which has all this text. There's the picture, there's these tags. It's not really clear exactly where this tag section ends and where this picture begins or if that's part of this body or if these are all, these paragraphs are one thing. There is an ability to toggle the content preview off, which will allow you to see that this is actually a tags field, image field, body field, et cetera. But this is just sort of the only real way to be able to do that. It's either all or none. You either see your content or you see just those placeholder labels. The other thing is that this, as I said, only affects the things in this blue box. You can't change anything in your sidebars over here in your header. So if you really want to put a new block above this more featured articles, you can't do it from this page. You have to literally go and you open the map, you go to Structure, you go to Block Layout, and then you find, and you don't know what that's sorry, what was it? More featured articles is on the page. You have to go down and read through this sidebar. It's probably the sidebar. So if I just place any old block in the sidebar, you know, I'll save that. Then if I refresh this, maybe it'll be there, but I still don't see it. So if I go back, oh, it's because it's below it, so I have to drag it up and then save it and then go back. And that's a lot. There's a lot of steps there and there's a lot of confusion. I happen to know exactly that Block Layout underneath Structure was exactly how you did that. If you're the content author, if you're just a site builder that has not been building the underlying structure of the site but is more focused on the end part, I don't know how you know that. I don't know how you find that. That's not discoverable. But you know, at the end of the day, there's your block and you're happy with it. That's fine. And you can from here, using Quick Edit, you can, you know, change the title of that. That's nice. But that's not enough for me. So the Layout Builder Everywhere module, this is a new, a different site. Same install, but I've installed one module, which is Layout Builder Everywhere. You'll note that the Layouts tab is gone. It's now up here. We're in View Mode. Now there's a new Layout Mode. If you click Layout Mode, you now see a visual representation of all your regions. All of these regions are all global. You have your sidebar, you have this one down here in the footer, and then you have your content region. So if you click on the sidebar, then you get a nice little Layout Builder UI here. And you want to add a new section. Let's add a one column section for now. And in this block, we can add our powered by true pull. And there it is. And then you can hit Save. And you never had to leave this page. You know, there's no more digging through the admin UI. There's no more wondering where it's going to show up. It's going to show up exactly where you put it at the top. If you want it to be somewhere else, you can move it somewhere else. So that's sort of the idea between Layout Builder, a Layout Builder Everywhere. Going back to this Layout tab, you'll see this is the... So those are stored as configuration. All those changes in the sidebar are stored as configuration. As this is a node, any changes to this node's layout will be stored in the content itself. It will be revisionable. It will be content moderationable, publishable. It will be translatable through the normal entity workflow. But you can even see here this has changed to published drafts, archived. And this still... This inherits, you know, the fields that are defined above it, like the... At the display level, for all articles will have their fields in this order. But maybe on this one, you really like that picture and you want it to be above the tags. So once you save this, you are editing the layout just for this specific carrot. Let's hear it for the carrots article. The thing is, this still doesn't resolve the issue of being able to understand exactly what it is that you're moving around, as I mentioned before. Once you click into here, you still have the same problem. So that's where the... I'm going to install the Layout Builder UX module and wait for it to install. I don't have a third site. It's like I pulled a dish out on a cooking show. Wow. Cool. There we go. So when I refresh this, you'll see slightly different UI here. So now, as you hover over them, it'll tell you exactly... Let's make that a little bigger. Oh, that's too big. There we go. You'll see exactly what field it is that you're manipulating. You can see the section name, you can see the different fields. If I want to relabel this section field, this was the one feature we landed in the last six months to my cool section, then it's labeled as my cool section, which for some people, helps them with their... Mapping out the page, what that section is intended for. Because you can have many different sections, you know, you have a four column, and you could even... You could call it four column, or you could say like, this is important for whatever reason, to communicate to your content authors. That's what they should really be using it for. So that's Layout Builder everywhere and Layout Builder UX modules. They're both available on Google Work as contributed modules. As I said, they may eventually make their way into core. There's a lot more we want to do there, but that's what we got so far. Jumping back in. So Layout Builder Styles. So those two modules were written by me and my team at Acquia. These other modules are written by other members of the community, some of whom have been participating in the Layout Initiative for years, some of whom just had a really good idea and one day decided to help out. Layout Builder Styles is great. It allows you to define specific styles via... Like you provide a separate CSS classes, and then your friend and designer goes and decides what CSS is actually loaded for those classes, and you can name these styles. So I'll show you an example, but the important thing, the feedback we got from Layout Builder was that it's too powerful. It allows you to do too many things, or it gives too much power. And so as you'll see from the next couple modules, most of them are about reining in that raw power. And this module to me is a good fit for my trip, not necessarily for core, and you'll see why. So let's see. If I go... I've already set up one style. I'm going to get rid of my This Is Important section. Not that important. If I go back to my Cool section, you'll see this style drop down. I have no style. I'm going to make it fancy. It's the one style I've set up. So now everything is purple and cursive, because that's fancy means. So if you were to, and if I go and show off the... Let's see, it's under configuration, as I said, that fancy layout push styles. This applies to all sections, and it just applies this thing called my fancy class everywhere to each section. And then in CSS, I have to find somewhere that that fancy means cursive and purple background. So you could even have... Each individual style could have more semantic classes. And you could even have things where it's like fancy right, and it would be like, oh, you know, float right or something. I don't know. I don't really see CSS anymore, so I'm really kind of behind on this, but I know it's really cool. You can also define these styles to be available for both blocks and sections. So this is a section level one, so it'll apply to everything contained within it. If you use it on the block side, it'll be more granular. But once you... If I go back to this, as you add other styles with just any label, cool. What's the... Yeah, cool. Let's see. My cool style section. I don't have any CSS written for this, but so it won't really do anything. But if I go back into my section, now I have cool, fancy, and none. So this is really nice way for your front-end developers to provide you a set of styles and then allow all your content authors to choose from them. Speaking of restricting things, the Layout Builder Restrictions module, by default, everyone on your site can place every block on your site. They can use every layout on your site. That can kind of both be overwhelming for them as just the choices available are things that you may not ever really want to place. Like, for example, the email address of the author of the article you're looking at, not usually something you'd want to, you know, place or move around that much. So you never want people to be exposing email addresses and you just remove this block from being available. The one caveat is that right now it's global. There's no per-role configuration of this. I know that they're working on that. The problem is that when you take the entire list of blocks and then multiply it by the entire list of roles, you get a page even worse than the current permissions page. So we're waiting for, like, three-dimensional VR or something. I don't know how they're going to fix it, but they need to work on something. So, and that's really truly a problem of court software. That's not just a problem in this scope. So if anyone has any ideas of how to solve, if you've ever thought, I really like permissions page and I want to fix that and make it even better, but I want to be, I want it to be more challenging that you can help them solve this problem. And I could show you this, the playable restrictions. So we're buying. It's under content authoring. Nope. Crap, where'd it go? Oh, is it directly on the thing? Right, thank you. I'm working on articles, manage display, yeah, box available for placement. So currently it allows all content fields, all core fields, all custom fields. And then you can, you know, these, yeah, there you go. That's a lot. Imagine that, but then all the roles. You can restrict to say, oh, they can't place any forms, they can't place, you know, any views or inline blocks. And this kind of gives you an idea of all the things that labeled or can place. And then you would hopefully say, you know, this doesn't really make sense in an article, or this doesn't make a sense on this content type. And sort of lock things down for your users. Similarly, similarly, there's also you can risk, as I said, you can restrict the layouts, core, live relationships with only four layouts, one, two, three, four columns. But I know there are many modules, especially for the themes like bootstrap, whatnot, that will ship their own layouts. So this can get, you know, this can get kind of long. And you might not want to let certain authors use certain layouts, or you may never want to ever have just four columns. It doesn't fit in your safe theme. So you don't want that one around. So that's your option there. And there you go. So Oh, thanks. So that's a lot about contrib. But what about core? Like that's that was fun. It was fun six months, a good summer, you know, working away from the core issues. That's kind of a nice break after getting everything stable and in. But what's what's next for core? There are a lot of feature requests, or I think I counted like 57 current open feature requests, which is great. Some of them, you know, just like these modules, they could be done in contrib. You know, you don't always need a core patch to allow new functionality. A lot of this could be able to contribute. I call out three here, visibility conditions, section reordering and nested sections. Those would be very difficult to accomplish via contrib. And I think they do need to be worked on directly in core. They also need people to work on them. Some of these issues, like, for example, the visibility conditions, there's already code in place. It's just not quite done yet. And actually, the I think the blocking issue there is that it needs some design. It looks like Drupal six panels, you know, and we don't want the uploader to look like Drupal six panels, we want to look like the uploader. So trying to figure out the best way to allow authors to say, I really only want this block to show up, you know, for this role to the end user, not just for selection, but like actual display, or I really only want this thing to show up on Tuesdays. Any sort of any sort of condition about when and when things are going to be displayed to the end user, we don't really have in core. We have nothing like that in core and except for on block page, the block UI, which once again, I don't really like the block UI. So we need some help there. A lot of these other things like the section reordering, for example, that just that needs user testing that needs people to actually go and say, you know, this doesn't work in Firefox on Windows computers, or this one doesn't really work if I try to use the keyboard. So anyone who is interested in any things can can participate and contribute. Yeah, so there's 87 bug reports right now. We fixed a lot of the bugs before release and as I said, 13 criticals and majors over the summer. Over half of the bugs already have a fixed proposed, which really lowers the bar to helping push those issues forward. Some of them don't have fixes proposed yet. They're just their known bugs. So that doesn't work. We don't know why. Or we do know why we don't know how to fix it. The good news is that nothing's critical. We got rid of all the critical bugs. That was sort of the caveat to becoming a stable release, including the critical performance bugs fixed over the summer. There on Thursday, I will be available with a table of a bunch of people are going to be working on layouts. So please come find us if you're here on Thursday. And also in the Drupal Slack, we are the layouts channel. And there are people all over the world, 24 hours most of the time, there's someone in there chatting about layouts and lots of lots of very knowledgeable people in there who are very willing to help. So please come answer and ask or ask and answer questions there. Yes, this is more information about the contribution on Thursday. So now I'd like to open it up for questions. The trick here is going to be getting people to the microphone, all the people on the floor. They're, in theory, other people come up to these mics, but you have to ask the mic the question into a microphone. Do we all have a room, a passing one? Yes. Because that's kind of wired in. I could also repeat the question if I can hear you. So let's start. Who's first? Someone has to be first. David? Thank you. What point does Layout Builder become the only sensible default for laying content out in Drupal? And should we just deprecate the blocks interface entirely? So could everyone hear that question? Because I can barely hear. Okay, you can hear it. I can't hear it. I think there is, I think that Layout Builder everywhere, this module, is the first between that and the visibility conditions. I think those are the one, that's the one to punch to remove the block UI. If we land both of those in core, I think we can deprecate the block UI. There is no additional functionality provided by the block UI after those two issues land, which would be wonderful. That's the answer to your second question. First question of it being the de facto approach to laying out your content. There is, show of hands, panelizer. Who uses panelizer or has used panelizer? Okay, so I'd say a quarter of the hands went up. About page manager or panels. About half the hands went up. About display suite, about a third. And then, who has used the paragraphs module, but for layout reasons? I feel so bad for the two thirds of the people who raised their hand. Paragraph, just to jump to the, well, I'll let someone ask the question about paragraphs. But to answer your question, panelizer, there's an upgrade path, or a migration path from panelizer to layout builder that is written. It is not yet complete until visibility conditions lands, because panelizer has visibility conditions permitted. So panelizer's gone. That's done. You don't need that anymore. There is an issue, this was asked yesterday during the keynote, about using the layout builder UI on custom routes, or on pages like page manager defined pages. There is a patch in the, sorry, there's a patch in the page manager issue queue to adopt the layout builder UI, which then will allow you to continue using the functionality that panels is provided in D7, or page manager provides in D8, but with the familiarity of the layout builder UI. So that one's done. Displaysuite, I'd say, Displaysuite is an interesting module, because Displaysuite, the module itself does a couple of things, but there are a lot of Displaysuite extras models. There's a lot of different, Displaysuite field, Displaysuite template, Displaysuite, there's a lot of extra stuff there. The core Displaysuite functionality is already covered by layout builder. In fact, when we wrote the modules in the first place, it was, we want to take the 80% best case of panelizer and the 80% case of Displaysuite and combine them. And that's sort of how we ended up with layout builder. So I can't really say that all of the extra parts of Displaysuite are solved, but they're well on their way. So to sum that up, I think that already layout builder has become the de facto layouting solution for new sites. And even for those that are on panelizer, with the migration path, it should become the de facto solution for all sites that are existing that have been using panelizer. So that would be, that's what I would like to see going forward. Thanks for the question. Who's next? So while testing layouts, we were trying to replace paragraphs with layout build, as you mentioned, but we failed hard with translated blocks and revisions. So the question was about migrating from paragraphs to layout builder, but hit stumbling blocks with regards to translation and revisionability. The revisions things worries me because revisions are supposed to work fine, but if it's revisions and translation, then that makes sense. Layout builder, currently there are two contributed modules that provide layout builder translation approaches. One is layout builder AT for asymmetric translations, and one is layout builder ST for symmetric translations. There are, layout builder itself does neither. It just doesn't supply, provide translation support. And the main reasons we really couldn't pick between the two. And I had, which one were we going to pick? AT or ST? Or do you want to come up and answer it? Guess, phone a friend, Ted, who wrote both of those modules, has got to come up and answer that question. Who wrote the other one? I think it was the guy, the display suite, Svensil. Oh yeah, so the display suite author, Svensil, who's here somewhere, also wrote the other one. Thank you, Ted. So basically we kind of ran out of time for translation. So to be clear, translations work for layout builder in the sense that if you place a field, it will show the right version of the translation. So don't feel like if you have a multilingual site, you can't use layout builder. If you have a view that you place and the view is translated, it will display the right version of the view. So don't, like, there's a lot of use cases that aren't not covered, but the basic use case of if you place something and it's translatable, the rest of Drupal takes care of that. But the ability to have different layouts per translation, our goal for core is what basically the layout builder symmetric translations does. And that is basically like your layout will not change per language. And we wouldn't, the idea right now is we wouldn't let you change the actual layout, but everything you put in the layout as far as inline blocks, other strings, and plugins that declare translatability, you'd be able to translate it, but it'd be in the same place across languages. Asymmetric translations would be that you have a different layout completely per language and it's sign of totally divorced. There's no sinking between languages. If you have a Russian page and an English page, you can have them totally different. That's sort of more of a localization than translation. So the goal for core and the thought from the product managers was having this totally different per language without having the ability to sync them is kind of a no-go on a product management standpoint, because if you want the layout to be the same, but just have like your inline blocks translated, it's very difficult to do that manually. So if you have like six languages and you try to like, okay, I'm going to change this, put this block over here, and now I have to change it in all six languages, that becomes very difficult. But so the first one would be get in the symmetric translations, 9-1, I guess, would be the earliest at this point. And then is there enough use case for the other one? But if you want, take a look at the layout builder symmetric translations and asymmetric translations in contrib and file bugs or whatever. They both, I think, work pretty well and they have a fair amount of usage. Thank you. That was Ted Bowman, Ted Bow on Dribba-Lawr, thank you. So for the paragraphs case, the symmetric translations with inline blocks would be the close one. That's already solved in paragraphs, but what about copyright moderation, like drafts, untranslated? So the content moderation of, well, so revisionable, like content moderation, publishable translations is already, that's a solved problem in theory by the interaction of those two modules. And I didn't think that layout builder complicated that. If there isn't, so if we're stacking all of those things, and there's still bugs, and you're using layout builder ST, file a bug report in that issue queue, because that's a problem. I think also paragraphs makes a different expectation than boredom as far as so. So paragraphs has a very different sort of data model and workflow to get through that. So it doesn't quite line up one-to-one with inline blocks. So there may be a way to solve the problem you need. It would probably be very hard for, the stumbling blocks would be in the migration, not necessarily in building the solution. So we can talk about this more if you're around on Thursday. Next question, there was, okay. How do you see, I know there's currently an issue exposing layout builder information via REST and JSON API, how do you see the future of layout builder working with decoupled solutions in this household? Okay, so the question was, current, well, layout builder does not currently expose any information over REST or through JSON API. And there is an issue to allow that. But assuming that we do that and allow them to read from it, A, which should be easy and fine and safe and not scary. That's one thing. What if we go the full route and allow writes and everything else? And what's the future of that? Honestly, I don't have personally a good idea for the, I don't have a vision for that. I think it's kind of exciting. There's a lot of open-endedness there. I don't think the only reason is that we were trying to land JSON API and layout builder module in the same release at the same time. So the decision by the product managers of Drupal Core was to just turn off all JSON API access to layout builder just so we didn't, on the last day before the deadline, introduce some major catastrophic bug. There's no real reason for it to still be off other than just momentum, that she needs some effort. But I think that in the same way that when we landed layout builder and we took a breath and then a lot of contrib modules sprung up, I think if we enable JSON API access to all the layouts data and then take a breath, I think there will be a lot of interesting stuff proposed, either for core or via contrib. And if you have an idea, please share it. Like there's a lot of cool stuff we can build. So thank you. Yeah, on Thursday, if anybody's around, it would actually be very easy to open that stuff in a contrib module, but nobody's actually done it. So if you're looking to be like, we want to make it be couple of layout builder, let me know and there's definitely, you can open up the event yourself, but then you're on your own. Yeah, so as Ted said, there's, in addition to the patch and the issue that allows you to have access, you could also, if you don't want to run a patch for that, you could enable that access via contrib module, but then as you're on your own, in terms of accidentally letting people mess with your stuff. So that's kind of scary. Was there another hand over here? Yes. One big issue I'm seeing is the roles and the permissions. So for example, having a certain section of the layout builder be accessible for an editor and not for other roles, something like you mentioned during the slides, is that something that's rather picked up by more or that you just offset in the culture? Because that's, for us, for example, that's a new operator for using it. And that's why we use paragraphs for a lot of stuff that would make more granular control of the area. Okay, so the question was about roles and permissions and granularity in terms of editing sections, especially in comparison and contrast to paragraphs. Yeah, there are, when we were working on the module, there was one permission, which was do all the things. We split it into two permissions per content type. So for articles or recipes, you can enable the ability for anyone with that permission to edit the layout of that content. Or there was another permission where you could let anyone who already has edit access to that content be able to edit the layout. So one is where you just want someone who can only do layouts who comes in and can't even edit the words on the page but can move things around. That's one permission. And the other one would be for them to be able to do anything. That does not address your specific concern of being able to lock down individual sections or individual fields or inline blocks. And you're right, there is a gap there. I think that I don't know of any issues where people have raised that as a problem. And more importantly, people haven't told us what they want. So I can ask you very kindly to open that issue and say what is wrong and what you want it to be. The thing with permissions is that every permission is kind of, they're all provided by individual models. So you end up having the same discussion over and over and over again. There's a very long running issue about the block UI, the one I want to kill, that has one permission and it's administer blocks. And it's considered, you only give that to people that you trust. And if there's a security vulnerability related to that permission, then you shouldn't have given them that permission. Like it's just basically like a black hole of permissions. And there was a very long running issue to granularize that more. And yeah, it's a fight you have to keep fighting on every module. So if there's specific things we can learn from paragraphs with regard to that, then we should. Layup by restrictions, does it solve some of that? Layup by restrictions does not solve that because, well, I mean it addresses some of it in terms of saying, oh, you can't add that one field or whatever. But the more complex things like, you can't add the header to the first section or something. Or only people, only certain roles can edit the top of the page. And everyone else can only mess with the bottoms of the page. Any sort of granularity there is currently, must be done custom. It's doable via hooks and stuff. You can define your own system, but that would, you would have to bait your own business logic into the code. There's no UI for that. Correct. Next question. There's no more questions. Okay. Everyone knows everything? We're good to go? Is there anything anyone would like to see demoed? Ted? My first question. What is the thought about enabling Layup Builder by default, say, on content types? Okay. So the question was when or how do we decide when to enable Layup Builder by default on content types? So the good news is that it's already enabled by default in Umami for recipes. And as far as I know, they're working on making it for most of, for all of the content types. With that change in Umami is very politically straightforward to make. Technically, it's the same work for all of things. But making that decision in Umami is straightforward because that's a demonstration install profile. It won't need, you don't need to push that changes out to new, to new people. Making changes to the standard profile has been difficult and slow going. There are, for example, in Umami, there are lots of complex, or custom block types where you can have a header, a banner, what's the hero image? It's like the new, it's not a new term. Hero image has been a term for a long time, but it's new to Drupal via Umami. Whereas the standard profile only shifts with basic block, which is quite the term. And it doesn't have a level and all installed at all. I think most people just avoid making changes to standard profile because it's too hard to fight to fight. And they just do it in Umami. They do it in contrib via the lightning installation profile. I would like to think that maybe with the changes with Olivero coming in, that Olivero could be built with layout builder at the forefront instead of using the old page templates and stuff. So I think that may be the way to get into that instead of trying to modify Bardek to be layout builder-y. But anyone can pick up that and propose a change to standard profile that's used it. What's the next? We have like five minutes left. Suzanne. So I did some testing of the layout builder, not used in the way that it's mostly been demoed, but used as a landing page builder tool. So it has no, it's used with a content type with no fields. And there were certain things in terms of the UX that were problematic. So I'm wondering in terms of solving for that use case, if you think it would be best to build some kind of contrib module or if there's room to make any configuration changes before? So the question was, I'm going to try to get this right. So no, it was using layout builders mostly been demonstrated as a content operating tool for specific content that has a lot of structured content with fields and whatnot. And when using layout builder for a content type with no fields in terms of basically replicating a layout, a landing page builder, the UX choices that we made don't make as much sense. Everything was catered around fields. And so what do we do about that? And I think the answer is twofold. One, in the short term, just because people already use page manager or panels for landing pages is finishing that work to bring the layout builder UX into that and then make those specific choices in that module. The other option would be to abandon all the baggage of page manager and panels and all the expectations that comes with it and focus specifically on solving that one problem in a dedicated contrib module with the intent of eventually putting it in core. I know Dries has specifically said he wants there to be a very streamlined landing page flow. And that's the thing that we need to build, but no one has taken it on yet. But I would really like that. I think the idea of being able to tailor it to that specific experience and not just reusing the same thing that we're using for the field-based one would be really great. But as far as I know, there's no work specifically focused on that. I'm curious. Is this on? It's on, but you have to get really close. They have to talk really close. I'm curious because I wrote the paragraph box module a while ago. It has very little usage and it's not really the workspace that I work in on a daily basis. But a lot of people raise their hands that they use paragraphs. Is this a useful module still? Paragraphs block, paragraph blocks rather as the most probably, is I think extremely useful. And I think like in the layout slack, I think it's mentioned like once a week at least, especially for people who are already on paragraphs and want it. So just the short version is that it exposes each of your individual paragraph items as two layout builders so that you can rearrange them. Which is great and really cool. And especially solves that use case of people using nested paragraphs to achieve a layout solution. I don't know that, I think as inline blocks improve, people may move away from it if it solves their use case. I think paragraph still has a very, very specific use case around authoring. But I think that inline box blocks and layout builder will sort of decrease paragraphs usage for things it wasn't intended for. As far as I know, the paragraphs authors are thrilled that we're finally doing, because they never wanted anyone to use it for layouts. So they're happy that the module is finally being used for what it was intended for. But no, I thank you for the having paragraph blocks out like over almost a year ago now, right? Time flies. Has really helped adoption of layout builder and really lessened the burden for people using paragraphs. Question in the back. The question was when sort of administrating or auditing a site, how do you identify which nodes have been overridden with layouts? And there is an issue for that in the queues. It's, and I wrote a patch for it. It basically just like lists them and gives you a reverb button or something. Like, it doesn't do anything more because we don't, I don't know what people want it to do. So we can talk, or you can jump in that issue or I can point you to that issue and then you can help us tell, like, tell us what to do or suggest something, you know, Ted. But currently you can make a view that filters on overrides. That's right. So it's not hard to do and it doesn't help you revert them but it'll help you identify them. As Ted pointed out, just for the purpose of listing them to literally just know A, how many you have and which ones they are, you can make a view and filter to only include ones that have layout overrides. So that's a very not great but short-term quick fix for finding out what the scope of your administrative nightmare is. In the front. So this is maybe more of a meta question about the sort of layout and config and triple nine. And as a sort of more DevOps person, one of my big frustrations is people demanding database backups for the purposes of matching up, like their block config to the content UUID and I'm tired of having the argument about, you know, not exporting databases to do that kind of thing but I don't have a great answer. I know it's a broad question but like at some point, I think like the layout ecosystem has got an answer for like that content other than just saying like your block is busted. Yes, so the question was syncing, so syncing the content and config of blocks and layouts between environments is very difficult because if you just push your config, it references UUIDs of content entities that do not exist yet. So you both have to sync over the blocks that you place as well as the fact that you placed them right now with block modeling core. With Layup Builder, it's very similar. It's not as bad. It's not better. You can use Layup Builder in theory to sidestep some of those problems but really you can't because as soon as you start placing those blocks that are created, you have the same exact problem. So it's, the same problem exists with menus, for example. Menus are content and config. The fact, the menu blocks are config but menus themselves have to be created. I don't like the idea of making that our problem but no one else is solving it so maybe it can be. Yeah, it's a very long running problem. It was like the one major unsolved thing when we have CMI. It's like everything's great except for that problem which is a huge burden and you hit every time you build anything remotely complicated. So yeah, I know definitely don't have an answer for you. We, everyone I think, everyone who's been writing configing content entities that work together has been waiting for someone else to solve it and it just hasn't happened. But I'm sorry. And there was one last question in the back. Is there any thought about supporting web components? We have an external design system called OPE which makes the web components any thoughts around that? So the question was about web components and integrating that. So I don't have any thoughts about that but there are thoughts about that. The idea is that anything can be exposed to lay up on it. Everything, anything can be. Like paragraphs, blocks. Paragraph blocks is a great example. They just pull all these paragraph individual items out and you can now put them in a lamp utter. There are about half a thousand different ways you could do that. The problem is just finding which one was the best one or finding the best practice. So I would, I don't know of any models that are already starting to do that. I'm surprised that, I would bet that it's going to come soon. It is extremely doable. And whether it be, I think that's the problem is that there's such a proliferation of component libraries and systems that live outside of Drupal in people's minds and in implementation that it's not as clear to tie them to each other. But it is absolutely possible from within Layup Order to expose anything. And then you could use Layup Order restrictions to turn off everything else. It's not a component. And then, you know, lock them down to that, to your system. So it would be really exciting to see but as far as I know it does not exist yet. I believe that's time. So thank you all so much for coming.