 It seems pretty full, so I'm going to get started. Hi, I'm Tim Plunkett, and I'm here to talk about the Layout Initiative. There are four people officially on the Layout Team. I'm the only one that could attend this triple con, but I wanted to give credit to the others who have been working on this. The team sort of grew out of the people who worked on panelizer and panels and C-tools. So while we worked very closely with other people, like the DisplaySuite team and obviously the UX team, this is where we came from. So you might see things in core feeling similar to panelizer, and that's for a reason. We're a little biased. So just a quick recap of what the Layout Initiative has accomplished so far. We have a Layout API now in Drupal 8. There's a Layout Discovery module that you can enable that gives you some basic layouts and the ability to provide your own new layouts. And all three, DisplaySuite, panelizer, and panels, and also a new core module called FieldLayout, all use the same Layout API. So if you write one layout, it can be used across all those modules. Single unified discovery mechanism. FieldLayout is a new experimental module that was added in 8.3. And it tries to attempts to bring layouts to the Field UI without making any other drastic changes to the Field UI without bringing any of the extra functionality that DisplaySuite and panelizer bring. It just, instead of being able to dump your fields into either content or disabled, it allows you to choose a single layout for that and arrange your content in it from within that UI, as limited as it is. Once we're all done, panelizer will just no longer need to exist. We're targeting all of its functionality to eventually be in core. There's still some things in DisplaySuite that could and should probably still exist and can be used alongside that, specifically the ability to customize the exact output of individual fields, choosing the markup, specifying different prefixes and attributes within the selectors or in the HTML classes themselves. But from the site builder perspective, without worrying about the exact HTML output, eventually all of that functionality will be brought to core. We're targeting Drupal 8.5 for the very first initial version and no real plan on when we're going to finish the whole thing. Which brings us up to today. So 8.4 is coming out. There's nothing really that new in 8.4 other than that the API we introduced is now marked stable. It hasn't really seen any change since 8.3 since the spring. But now we're working on a new thing called layout builder, which all of you that were in the Drees note saw this morning. And that was a real demo that really worked. It grew out of a hackathon project that some of us worked at at an Acquia engineering on site. But now it's like a real patch in the real issue queue with real code that can really be used on a real site, which is very exciting. And you can instead of having to handcraft every individual layout that you would need if you need a I need this two columns and then three columns and then a big footer at the bottom. You'd used to have to write that in your HTML twig file and write custom CSS for it. This has a new idea on how to compose new layouts directly from the UI itself. And the UI you saw this morning, and I'll show again, is pretty rough right now. But we're working very closely with the usability team to come up with something that really presents all the complex concepts in a really easy to use way. Right now, we're targeting landing page functionality. Since there already is panelizer and display suite and even rudimentary functionality and field layout, there's not really anything right now that's really doing landing pages. Page manager sort of exists. It's not really being pushed very hard for Drupal, like the Drupal 8 version. So we saw landing pages as the most important thing to work on first and be able to say this and it uses the layout API itself. So everything that you've built for your existing sites will immediately be usable from within the new layout builder. Live demo time, to get all my windows in place. You can kind of see that. So this is my cool landing page. It doesn't have any content, but there is a layout tab here which allows you to then add new sections. So if I click add section, you're presented with the different layouts that have been defined. These are the ones provided by Core. So I could say I want two columns. I would like to add a block. So I will add the most useful block which is powered by Drupal. And I'd like to add an exclamation mark, there we go. So now we have it powered by Drupal block. If I save, it's on the page. This UI is similar to Views UI in a way in that if I were to go to this in like a incognito mode, well, okay. Didn't, yeah, whatever. Why is it access denied? Whatever, that's fine. Live demos, yay. The idea is that the content, when you make changes here, oh, I can see it from within even. As if I were another user viewing the actual output. If I go and actually edit this title from the front end and update it, it shows here, but viewing the actual node, wow, that's broken. Let's file a bug. I'm gonna write that down. Broken. That's true, but we're supposed to protect you from both and we didn't, so I'm writing it down for later. Thank you all for helping me find a bug in Drupal. Well pointed out though that it is probably only, we're only protecting you from having the regions be different. So if I save this layout, it looks like that. If I edit it in one tab and put them both in the same region, by the way, drag and drop, yay. Really hope this works. Nope, also still a bug. I know. So if it shouldn't take effect until I save, that would be the ideal thing. So that someone could be composing the perfect UI, but not actually taking effect for the end user until save. And this worked a couple weeks ago, so I wonder why our tests aren't failing. Always fine in core. Anyway, so I previously made a more complicated layout, so I decided that there's a new movie coming out soon, it's called Thor Ragnarok, and I'm a big Thor fan. And I really liked all the posters they tweeted out that showed all the different characters, and I thought they'd be really nicely arranged in a certain thing, but if you just try to dump all these images into Drupal, it just lists them sequentially. But using the layout builder, it could look something like this. And if you actually go and edit it, we could then say, well, you know, I mean, Loki is way cooler than Thor. So let's move him over here and have him over here. And now there's only eight people instead of nine. So instead of having this awkward three by three grid, we can know that we need to have three columns here, two column here, and three column here. And if I save, this is also responsive, or it was yesterday. So, you know, you got a little squishing action, and then once you get too small, it jumps to one column, which is really nice. Yay. Okay, so. All right, future. So that's what works today, or works, air quotes. So as I said, the idea is to first introduce it as a layouting tool. So that I just showed you was a single node. So every node that you use this on, you could make, have a different layout. As I mentioned earlier, field layouts module tries to improve the field UI. So the eventual goal would be to present a similar UI to control, say, oh, I want all article nodes to look and have this layout, except for node five, or like all press release nodes to have this other type of layout. And it's not even node specific, it works so you can lay out your comments with this, which gets really wild. You can, any, any type, and it would be very useful for things like media, to say, oh, I want the caption to show over here or like underneath the video at this viewport with. So the idea is to bring this whole idea of the section base where you can add many sections to all of Drupal. And we really think that for the 90% use case that being able to switch between sort of more building block style layouts is very powerful instead of having to write out a very complex layout from scratch by hand. In twig. So the next things we need to do is come up with a good name for this because they're called sections, it's called layout builder, it's called field layout. We need to sort of unify it. They all came out of different spheres, so we need to find a good way to explain this to people. We're gonna write a migration path from panelizer. We have that because the, the maintainers of panelizer are working on this and want to stop maintaining panelizer. The only good way to stop maintaining a module is to migrate everyone away from it and market obsolete. Also in discussion would be a migration path from page manager and from display suite for the portions of the display suite that could be migrated. And that's all I have to say about that. Are there any questions? Do you wanna see more broken demos, anyone? Please use the microphone. The demos we have seen kind of use the block systems. You need to have a block with your content. Yes. On Drupal 7, on some kind of landing page we have used paragraphs. Could you see a future for that in Drupal 8 with paragraphs and using layouts for kind of styling the different bundles? Yes. So I know, I attended a session about paragraphs and they were saying, oh, well, to do layouts you need to create sub paragraphs, paragraphs within paragraphs. And you end up taking what is a really good tool and a great data model and then completely corrupting it just to get layouts onto a page. So yeah, as you mentioned, it is completely block based. There is a plugin within SQLs that allows you to reference individual fields. And it's basically what everyone's used to in Drupal 7 where you can chop up and say, I want the body field over here, the title field over here. So the idea would be to present each of your fields from within this UI and let you move them around. And it would completely replace, let me just go to the admin side. So like this page where you're used to like this where you have just one column. Even if you had different regions here, it's still just presented linearly. The idea would be to replace this with more of a graphical layout builder style thing. And even to in specific overrides target individual field deltas. So, you know, the third value of that field which is where we would really need for paragraphs to be powerful. There's, we're not blocked on the technical side of that. We're blocked on the UX side because presenting that is very complex. So that is a goal. And I mean the work on presenting just saying, oh, I want my body field over here and title field over here, that's already in progress. But getting down to the individual field level, like field delta level, which would be needed for paragraphs is forthcoming. And I hope that if the paragraphs people are here or listening will want to help because I need help. Yeah, any other questions? It's about translation? Yes. It works. Translation, how does it work? So we actually, it works great. It actually works. I don't have a multilingual site set up or I demo it. Again, no. I also only speak one language. So it'd be really hard for me to demo. Yeah, so there are two mechanisms for translation. And they ran by the usability team and they said providing two is bad. Because if you have choice, people get confused and people do weird things. So the idea would be that the initial decision was that you can just use, since there are blocks, you could use block context and the language context to then use that to individually say, oh, this block only shows up for these languages. That's the easy way and that works fine. The other thing is that because of the way we built this, it is using the field system. So the actual definition of the layout and what it contains is a field, which is translatable. So the use case for that was like a newspaper where they don't wanna just change what how the block is shown or how it's laid out based on a single language. They wanna present an entirely new UI for a different language. So you could completely translate the entire layout and present different content in different columns, different regions based on language. Now that wouldn't necessarily be turned on or enabled by default, but it would be completely accessible to someone to do that. And as I said, we just use the field system. So we also will in theory get revisionability and all the content moderation. So you should be able to stage layout changes. And so for example, also with a newspaper where if a story is getting more important over time, you can adjust its prominence on the page and have that go through an editorial workflow, which is very powerful. Yeah, other questions? Yes, please, if you could come up to the mic. So if I were to build a simple side today, should I use core blocks? Should I use penalizer? Should I use field layout? Or should I use layout builder? No, nope, nope, don't listen to them. So that's a great question. So do not use field layout because it is an experimental module. Do not use layout builder because it's an experimental patch and it doesn't really work as you just saw. But I would personally, this is my suggestion, I would say use penalizer, only because we know that there's a plan to write a migration to whatever the future core thing is. Yeah, I mean, I would use penalizer. Page manager is important for other things, but that's the closest analog, I think. Other questions? Yes, please. How is this work going to relate or integrate with CSS grids? So the current layouts that were written in core are using Flex, which is new-ish, not as new as grids. And that's really up to the layout author, I think. I don't really know, I don't know how the tool itself could better integrate with that. The CSS and the templates themselves, I feel like it's up to them, the authors of the templates to make that decision and use grids over Flex. I mean, even the CSS that's in core for this right now is pretty rudimentary. It's basically just using Flex instead of floats and it's still percentage-based. It's not even using the best way of doing things. But yeah, I would say that's up to the template author. And the CSS for these templates is now stable, so, but there could be new, we could ship with newer versions and deprecate old layouts, excuse me. So if someone has knowledge of grids and wants to help improve the layouts we have, that would be great. Others? Yeah, okay, great. To the earlier question about which module you should use or not, in a few, well, in a week or so, shouldn't this be stable? So you should be able to... We're aiming for 8.5, 8.4 comes out in a couple of weeks. Yeah. The API itself is stable. So display, suite, and panelizer and panels all use the stable API that's going to be officially stable in a week. This layout builder stuff isn't even in Core yet. It's still in the issue queue. Just 8, yes. So it's just the API is there. So yeah, I mean, you can define your layouts now using YAML and that's all stable and stock had changed. Hi, thank you for all the work. It's shaping up really great. My question is, like in Drupal 7, we are used to getting a lot of features from panels. Like we have styles, we have views argument, we can pass. I think that is still missing somehow. Yes, there is a lot in D7 panels for D8 page manager that we haven't really tackled. And I think the main reason was that people are now using panelizer to fake landing pages. You just make a landing page content type and you can get very far. You can only get so far. And there's a lot missing. The stuff with views arguments, I mean views blocks now take arguments via context, which is recently committed. And since everything's all blocks, that's the presenting context, D8 context in a reasonable way in the UI is still very challenging. It hasn't really been done yet. I mean the other thing is setting up, this is all using say, for example, nodes or an entity, content entity type. With page manager and panels in D7, it's more of a config thing. And you're defining a path and you define that path and then you can place things on it. And that will probably, that will exist and it should eventually use this layout builder. But the layout builder is like a single concept. It's more the way, once all that is done, how do you actually then implement it? So that wouldn't necessarily be a function of the layout team. Page panels are still gonna need to be around. Yeah, I think access plugins are one more thing which are missing right now from page managers and panels whole thing. We can kind of use context for that but then again, there's a gap between how you can manage access on views. You can't do that with page manager or panel. Yeah, I mean there's still, there's issues in the queues for bringing the power of what C tools and panels put in D7 into core. Even though views moved in, the views content module was a separate module that was in C tools in D7. And it's sort of like the 60% of it or so is in core but like the other 40% has not even been written yet. So that just takes more people to work on C tools. C tools is stable as was announced in the keynote but it's only the functionality that they bothered to write. The rest of it doesn't even exist. So there's a lot of work to be done there still. But as you said, that's a very advanced use case but it worked so great in D7, we need it in Drupal right now because we're used to that power. And that's the problem with writing really awesome code is you have to keep maintaining it forever or people complain. Any other questions? So there's one other thing I wanted to talk about which I didn't have slides for because I didn't think I was gonna talk about it until Dries mentioned it today in his keynote which was the concept of possibly using a modern JavaScript library to sort of decouple this layout builder concept from Drupal itself. And so last week, a coworker of mine at Matt Grill and I worked on a thing to rewrite this layout builder UI in pre-act. This was during when everyone thought react was terrible, no one was ever gonna be used it again and it was dead. And then they fixed react and now everything's fine. So we had to rewrite the demo. But the idea would be to present this layout builder UI using instead of this currently is built using a massive render array and Drupal AJAX commands and it's the most Drupal-y thing ever. And there's no reason for it to be. It's a brand new UI. There's no version of this from D7 that we're building off of. It's completely new. So there's no reason for us to build it in this old way. So we started to work on working on rendering this via react. And it worked really well. Right up until you click the add block button and then you pick a block and then you are presented with a form because there's no way to present and render and validate and submit Drupal forms from the client side. So that's the thing that... So then we decided to turn and ask the form system maintainer to help work on that. And then I remembered that that's me. So now I'm working on decoupling the form API from Drupal and rewriting it in JSON, which has been really exciting. It'll be done in about 10 or 15 years. Yeah. But even then, there's a D7 module called RESTfulPanels some people have may used. And really it just dumps the actual configuration at runtime in just a JSON representation. And we already built that. Like we can do that now. So we're going, ideally we put basically RESTfulPanels or RESTfulLayouts right into core. So even while we're struggling with working on how to submit forms on the admin side, you could still be able to render the actual layouts for the end user from the client side completely, which is really cool. So there might be some talks about that on Friday during the sprints. If you come find me, I will be wearing a red hat as I usually do. And we could talk about doing some client side JS versions of layouts, which would be very cool. Any questions? All right, great. Thank you very much.