 Welcome everyone. Thank you for coming. This is Continuing Saga of Layouts in Drupal 8. I'm Tim Plunkett. I work for Acrea. I'm based out of Philadelphia. I welcome to the East Coast. It's my first East Coast Drupal Con. And it was really nice to not have to travel at all. I'm now the co-lead of the Layout Initiative for Drupal 8. Emily in the back is the other lead of the Layout Initiative. There's a lot to talk about for the future, but first I want to take a step back into the past, the very distant past of Drupal 7. First, can I get a show of hands? Who is a site builder, or who interacts with the Drupal website? That's everyone. Good. You're in the right place. Any people more on the front-end side of things? And back-end? And who would consider themselves like a content editor or on the business side of things? We'll address all of those today. To begin, Drupal 7 is most of the modules that we're going to discuss for all this talk do more than one thing. Mostly going to focus on their ability to alter the layout of a page. Start with the obvious, which is the block module. It was in Drupal 1.0. It has always been part of Drupal, and it will always be part of Drupal. Drupal wouldn't be what it is without the block module. If you're familiar with the Drupal 7 version, you could place any block once per theme into any region of your choice with conditions that would determine whether or not the block would show up, if it be per content type or for a certain path, for a certain role of user. There was very little flexibility since you could only place it in one region. You couldn't have it in the left sidebar for admins and the right sidebar for anonymous users. That's not possible in Drupal 7. And there's a single UI that lists every block on your entire site at once. So if you have a lot of blocks and very complex configuration with that, it can be hard to understand exactly what's happening by looking at that page. Along came Panels module, the 30th most installed module of all and the most widely used layout module. Panels isn't what you think it is. If you say you know Panels module, you may not know exactly what's happening. Most of the time when you think of Panels, you're really using Page Manager, and Panels is more just the UI on top of Page Manager. It's mostly used to create landing pages. And it operates within the main content region of the single page. So it ignores the head or the foot of the sidebars and gives you very complete control over what's in the middle and main part of your page. Shortly after the Panels module was written, along came a module called Context. Has anyone used the Context module? Does anyone still use the Context module? Many less hands than went up at first. The Context, instead of showing you all the blocks and when you have to go in and look for their conditions, instead it shows you all of the conditions and says for these set of conditions, these are things that will happen. And it was a really interesting way to flip the paradigm of how you interact with your site. And it was more driven towards use cases and user stories saying, you know, as an admin user, when I'm on this page, then these things happen. Which is really great when you have a complete outline of exactly what's supposed to happen with your site and then you build it and then you ship it to the client and they say that's great. If they don't like what they got, it's very hard to go back later and figure out exactly which condition triggered the right thing and to change it later. And coming back to a site months and months later or as a new developer working on a site you didn't build yourself, it's very tricky. There are helper modules that have propped up since to make it easier. But it's very hard to determine exactly what is causing your page to look that way. Then after the sort of renaissance of landing page layouting tools, people started to become more focused around content. With CCK and Drupal 6, the field module being in Drupal 7 in core, there was a module, a set of modules to kind of give more power to that. And that is Displace Suite. Displace Suite is one of my favorite modules. But Displace Suite also does about 30 different things. The main part that I'm talking about is the field placement. So within the field UI, you can set up different sub-regions, for example, article nodes or user profiles and configure exactly what shows up it where for that piece of content as opposed to the entire page. And you can use it alongside panels. Some people say, oh, I use Displace Suite, I never use panels. But you can use both. And it'd be very clear about which part of, which module is controlling which part of the page and make sure everyone in your team is doing the same thing because you don't want to have them blending together and overlapping too much because it can get out of hand very quickly. Then after the Displace Suite kind of revolutionized how you use the field UI in complex situations, and people said, well, I'm really familiar with panels. I like panels. Why can't we have a sort of panels version of that? And while it comes to panelizer module, it's panels integration for content types. You can say all articles have two columns but events have three columns. And you can do with panelizer specific per node customizations. This one node has this different layout than all of the other ones, which can be very, very powerful. And it also operates within only the main content region. So then everyone said, great, we have landing pages and we have content layouts. But what about the rest? I don't really like using the block module for the header and the footer. So they wrote the panels everywhere module. Has anyone successfully installed and configured the panels everywhere module? Two people, three people. That's why you've never heard of it because it's very, very complex to set up. You have to start your site with it. It's almost impossible to then later use the panels everywhere module after building your site because it requires integration at the theme level. It's very powerful but very confusing and tricky. And it is therefore the 424th most installed module, which is enough. So that's sort of an overview of Drupal 7 as it was for a long time. Now, since Drupal 8 has come out, there are new Drupal 7 solutions. For example, paragraphs. But paragraphs didn't even begin as a module even though this is Drupal 7 version until mostly after Drupal 8 came out. So I'm not going to get into any more detail on that. So focusing on Drupal 8, all the maintainers of all these modules came together and said, well, we're overlapping a lot. We all do some really great things. Some things are better than others. But there's a lot of shared concepts here and there could be shared code. So the first foray was a contributed module called Layout Plugin, which is a very exciting name. It actually turns out it's like the 8th most installed module right now in Drupal 8, which is a shame because it's now gone. There's now the Layout API in core as of 8.3.0, which was released like three weeks ago. It provides you the ability to define a layout. There's no UI for it. It's defined there in YAML files. But now this API is used by panelizer, page manager, panels, DisplaySuite. They're all using the same exact API. So if you write one layout for DisplaySuite, it can also be used in panels. You don't have to define them separately, which is awesome. I like not having, you know, four lighting systems on the same site. And as I said, it's in the newest version of Drupal and, you know, bootstraps and foundation are all using Layout API now. So you only have to learn one thing and it'll work for everything. It was... Unfortunately, it has not yet been integrated with the block module. As I said, Drupal wouldn't be anything without the block module. It's not going anywhere. So the block module is still the same as it ever was, except you can now place a block infinite number of times. I can have that power to say, for admin users, I want the block in the left sidebar, anonymous users, I want it in the footer or, you know, different content types. But it's still relatively very little flexibility. You have a single layout for the entire theme. So every page has the same layout and if you want to use the block module to control your layouts, you have to create a theme with, you know, 90 different regions that only some of them are used in certain places to kind of give you that flexibility, but there's no flexibility at all. It's still also one UI. It's a very long list of all of your blocks. And as the regions are defined in your theme, in code, just by machine name, no sort of layout of them. There's no layout API integration as of right now. Panels and friends, all the modules were written separately over the years, but now they're being worked on together as a unit by the same group of people. And most, all of them now have beta releases for Drupal 8.3 or greater with the layout API integration. They were a straight port of the functionality. No real changes were made. It was, if you recognize panels in Drupal 7, you'll recognize it in Drupal 8. The layout, if anyone needs panels, IPE, the in-place editor, a few hands, it's really actually pretty great. You can, you know, customize the page from the front end and drag and drop the blocks around, or panes that they're called in Drupal 7. And it gives you a lot of power, and you can lock that, grant that power to content editors if you are very brave, or you can restrict that power. That is also working right now in Drupal 8 as a backbone.js implementation, which is really cool. That will be iterated on over the next couple months or years. But it's, there's no API changes to worry about. You can just continue using it. And it will continue to do more and more and become more powerful, and eventually possibly move into core. The context module, same as it ever was. No real clear plans to integrate with the layouts at all. Mostly, I believe just because it builds upon block module, so it would need to wait for block module to improve in order to do anything. It's still popular. People that have been using it since Drupal 5 have changed now. So you can keep on keeping on with that if you so choose. The display suite module is the first layouting module to become stable for Drupal 8. And it uses layout API. So you can use it today in production, you know, and there's a 0.0 release. But more exciting, and what I'm really here to talk about is a new core module called Field Layout. It is experimental module in Drupal 8.3. And it is layout API integration for the Field UI. So we're trying to bring sort of the idea behind display suite into core. And the next, the roadmap, which I'll talk about in a bit, is to move towards putting basically panelizer in core. Which is awesome. Now I want to talk about what we could do next or what we should do next or what do we want to do next. There's, you know, after with Field Layout going in, that was the first big step. And that was in New Orleans one year ago, we all sat down and agreed upon that as the first foray into layouts in core. And we did everything we agreed on. And now we have to start discussing what to do and agree again. Which is why we're having a core conversation about it. So one possibility of something we could do is a theme layout. Integrate layouts into the theme which would then help block module. And you could either have one layout per theme or some sort of UI to change them. Similar to the theme key module. There's a huge possibility there. But it's really not as user facing as you would think. As someone laying out your site, it's a content moderation system. And content is key. And defining what the layout is based on at the theme layer doesn't really jive that idea of each piece of content kind of embodying its own space. So this may or may not happen if someone's interested. That could be your pet project. And it could actually happen in core for 8.4 or 8.5. Another possibility would be a landing page builder. Emily, my co-initiative lead has some really interesting designs about how to build landing pages in a new way that's sort of different. Borrowing from some of the paragraphs approach but incorporating it into a panels-like structure. And it would allow you to create each landing page with its own very flexible layout. Which is sort of possible with panelizer. You can cheat, you can make a content type called landing page and create nodes of that type and assign each one their own layout. But landing pages are important for content. They don't necessarily need the same support that content has in sort of a moderation workflow. So it would be nice to have landing pages be a first-class citizen of Tripoli and really bring it to the forefront and surface that in a purposeful way and not just rely on the same old content moderation tools. So we're targeting 8.5 for that, which would be about this time next year. But it's still in the design phase. So if you want to help with that, on Friday we're going to be talking layouts. So you can come discuss that and share your thoughts and hopes and dreams. Other possibilities where getting in more complex is the idea of a full variance system. So with panels, you have the ability to say for a given content type or a given page there are multiple variants and it's similar to the block UI conditions. So, you know, if I'm an admin user, I can see this. If I'm an anonymous user, I can only see this. But that has to be built at each level right now. It has to be hand-coded to be working for content types. It has to be hand-coded to be for layouts for landing pages, excuse me. But what if it was more generic and was something that we could insert at every level of Drupal and be able to have that sort of unified UI and unified API for allowing everything to have like a choose-your-own-adventure as you go down the stack from all the way from the theme level to the page level to the content level to the field level. Which leads me to the idea of unifying everything. I mean, why not, right? It's nice to have options and flexibility and there's still the power to do anything at all and contribe using these APIs. But it's nice when core sets a structure of a pattern to follow and it also helps the tools to be more usable. If you learn one and it looks familiar, if someone implements it in a different way in a different part of Drupal that familiarity helps you be able to use the tool. But, how do we build one system to do everything without making it awful? Because the worst thing would be if we unify everything and spread it everywhere and it's terrible. That's a real danger. There may be a point at which we say, you know what, we tried, but maybe we shouldn't unify everything. Maybe things need to be more bespoke or more custom or they're best left to contribe or even custom solutions. But I really firmly believe there are tools, APIs, design patterns, things we can set forth that will help everyone build their own approach to Drupal with layouts. And this is for anyone whose panel is person from back in the day. When we started talking about unifying things someone pointed out that we were just describing mini-panels. Now, for those who don't know mini-panels, I don't even really want to explain what mini-panels are. But mini-panels was a rather flawed solution to a really hard problem and it caused a lot of pain for anyone who's ever tried to use it. But it's a really good idea. It's really good, I promise. But if we did it right and we allowed Drupal systems to sort of use that, we could use that as the building block to kind of encapsulate, like this thing has a layout which has a layout which has a layout which has a layout in a way that doesn't drive you mad. Maybe. So the question from the audience, there's a mic, by the way, you can start queuing up now if you'd like because I need some opinions and facts and whatever thrown at me. But the question was, wasn't that part of the original whiskey initiative? So there was initiative called the Web Services initiative and it promised to do about 35 things and it got three in on its list. And I think that was, like, 33 on the list, yeah. So the original idea of that initiative was to completely revamp the entire rendering flow of Drupal from, you know, the browser hitting the server all the way through the HTML being rendered. And it didn't many parts of it did happen and many, many, many more did not. And about a year or so into that initiative it was decided there was too much work to be done. So it was split into two. And as you said, the initiative as Web Services and Core Context initiatives, they called it whiskey. So the new initiative was then the single controlling object for templating and content hierarchy or scotch. I don't name them, you know. Mine's just called scotch. I'm easy like that. But yeah, so the scotch initiative was that also trying to solve this same problem. And that's what led to the blocks being able to be placed more than once. And have a unified block plugin system that mirrors the panes from Drupal seven panels. More, you know, singular context driven pieces that can take information from the request and from the global environment and determine their own output. So blocks are really powerful now. And that was about the only thing scotch did. They actually put a layout module into core. A whole complete layout module except the part at the end said act to do and it returned an empty string. So it had all this code and it did nothing. So that was removed from Drupal before 8.0 shipped. So this is sort of risen from the ashes of the original scotch and whiskey initiatives. But it's not really any of their work. We're keeping an eye on all the things they did and make sure we do the things they did well and not repeat the mistakes they made. But we built from instead of the perfect architecture that ended up doing nothing we built the other way which is the worst architecture that did something and then approving upon that iteratively. So that's why the layout API happens to be core now. The field layout module has made it into core. Because instead of rewriting the field UI to do everything we've ever wanted to do, we've made it into core. So we're working on it in that direction from a always keep a working prototype or a working model in place so that it's usable. And that fits with the new six month release cycle if you're at the keynote trees mentioned. Instead of seeing how much can we get done in five years. It's like how much can we get done in six months or less than six months. So we're working on it in that direction. So how much can we get done in six months or less than six months because we also have it all reviewed and write test coverage and get usability testing done, accessibility testing done, security review and then get a core committer and talk them into committing it. So it's quite a process. Which is why I was saying earlier we're targeting 8.5 for some things not trying to get things into 8.4. So yeah, we're queuing up for questions so let's take the first one. So I think there's kind of two things we're dealing with. There's unstructured content and structured content. So structured content being like if it's at a page level it might be like an event. So it has descriptors defined and regions work really well for structured content. Unstructured content is a little bit harder because you come into a content type without knowing what fields you're going to need. Fields are maybe at a component level to be a mix of the two. Fields, layouts and maybe traditional layouts where you're defining strict regions is great for structured content. But I think where that at least in the past is kind of broken down as like the long form unstructured content. And that's one thing paragraphs have solved really well. You win. You're the first person to say paragraphs. Yeah. I know that might be No, yeah. I'm not sure we're still worried in this one, but paragraphs really set this field base, the revision base you can define a field that's maybe two-column and start stacking those. And so I think I'm not sure where it's at in the 8 but the ability to define additional regions as you go per page and maybe that's something I don't not be able to play with many panels or whatever it was trying to solve is how do you take something for an unstructured page. So has there been much movement there in thought? Yes. So paragraphs paragraphs solves the need a very important one. And you're right. It is about structure versus unstructured. I think that the landing page builder that's being discussed is really kind of cribbing off the paragraphs approach. And I think once we're focusing on that because there is no landing page builder right now page manager is the least stable of the panel suite right now and it works but it does its thing. So we're working on a core version of it basically. And I think that those patterns and that approach can be easily moved to address that concern as well. Just to follow up with that would blocks still kind of be the main type of content? I'm glad you asked. I have a slide. So, blocks versus fields they both do the same idea you know you have a piece of content that is its own little self-contained bit. And now we have fieldable blocks which complicates it even more. But why are they different? And should we make all fields into blocks? Or should we make all blocks into fields? Or should we make them into something new? Which would be impossible to name. We've been we had a layout sprint two weeks ago and we spent a good hour discussing possible names for them. And I won't tell you all of them because they were mostly terrible. But yeah, that is a really important question is what is going to be our base smallest atomic part of that? And how do we build from that? So it's ongoing. This is why it's a conversation. Yes. Next. So while it's certainly possible and I've just done to use something like just place a week for a layout to make a page responsive. It also does nothing to help you nor prevent you from doing dumb things. In fact, we even saw an hour ago a video that showed left column, right column as if that was the end of it. And it's not if you're trying to be responsive and roll. So I didn't see anything terrible but have you seen anything maybe I've missed it. So it really is a good paradigm slash interface or whatever to keep people able to remove something to the left column but also explain to them what that means all of that. Yes. Yeah, the Drupal is built by developers and it's built for developers who are too easy to be developers anymore. We want to be site builders. And when developers start making decisions about things like responsive layouts they do it generally wrong and they think that I can top down design this page to do this wonderful thing when you squish it this way. But from what I've been very extremely informed by front-end people is that content should drive where the break points fall. So the more the ability to have a layout for a specific page and define those as the content editor in conjunction with a front-end developer or front-end designer they have to work on the responsive part. This isn't going to solve that for you. We can't. We can't even prevent you from shooting yourself in the foot, really. If we did, we'd make the system inflexible and paternalistic and I don't think that's something we really want. But the beauty of the layouts API is it doesn't produce anything. It is a way to discover layouts and then load them and then build something with them. Right now it's a render array. But there's already someone working on a thing where they can consume the layouts defined by the content editor and pass them through just the definition of the layout to, through JSON and then let everyone else figure it out from there and do it sort of that way and build other tools around the APIs provided. So just because panels does one thing it's not the end of the day. There's going to be other solutions improving upon this and making more specific things for unstructured content and very complex needs on a responsive site. So, Damian. Hey, I just wanted to clear the air given that already came up. Speaking as the panelizer maintainer for D7 I'd like to say a lot of sites should have used paragraphs instead of the panelizer. And at the same time I've seen a lot of sites use paragraphs way more than it should have been. So, please don't consider that, or please don't think there's any animosity between the maintainers or any, or the users of these two modules and ecosystems they're just approaching the problem of how do content staff get their stuff out to the world and everybody has different use cases. So, please don't think there's any animosity between the two maintainers or groups or whatever. Yes? Well said. Thank you, Damian. Alright, so I have a couple more slides but we can continue the conversation. So, please continue to line up if you have something to say. I want to talk, so those are the things we could do and might do and need to think more about. Here's what we have already decided we will do. The main thing, I don't really know how best to explain this but per entity overrides. If all nodes have a two column layout but node five has a three column layout. The ability to say for a single piece of content this can now differ from the rest of the system around it. That needs, that is a killer feature and everyone has always said that to me. I said, Tim, why don't we have that? I said, well, we haven't started yet. Well, now we're starting. The goal is to put that, and we've been calling it analyzer light into core. And that is the main, my main focus going forward for the next killer feature of layout initiative to go into core. Yay. So, if you'd like to, if you'd like, here, there's a mic. No, the question was how do we know how to do it and sort of we have ideas. Honestly, a lot of the original field layout stuff that just went in was copy pasted from DisplaySuite. And a lot of this is going to be copy pasted from panelizer. But we need to make sure we thought through the data model and make right actual behavioral tests for it first up front and make sure it fits the interaction patterns we actually want and not just copy pasting things because we don't want it to get to level 7. Can I ask one more question? Yes, you can. Short enough that I can repeat it. Are you going to identify the entities override with UUIDs or machine names? So the question was are you going to use UUIDs or machine names to identify content? The tricky part is content entities do not have machine names. So the idea is to use UUIDs so that it could be deployable. Anyone storing references to other pieces of content using serial IDs? That's a bug. You should file a bug report because it should all be using UUIDs so that you can actually deploy things properly. Yes. My question is for those of us who jumped in early and were already using panels or displays. Yes. So the first thing was that the since the layout API went into core and all the contributing modules adapted to it, there are already migration paths for panels to panel. Like panels 2 to panels 3 or whatever the panels. 8x, 3x to panels 8x, 4x for example. But there is since there's no solution built yet, there's no way to know what the migration path will be like. It really depends on how one to one things are. The good news is that none of these modules in core are going to be required in any way. And panels, they've already, you know, they're planning to continue working on panels throughout this process. So there's no need to, it's not just like I'm going to finish my work and then panels are going to disappear. Like that's not the plan. Mostly because they're going to be in specific chunks, but there is a vast majority of the functionality is going to remain and contribute for the foreseeable future. And there are already things that we know that panelizer does that we have no real plans to put into core. So honestly it's mostly going to be a decision of is what core provides enough for me and then there can be a migration path. But if there's functionality that doesn't work, you're not going to migrate. And you'll have to continue using the contributor modules. I appreciate it. We'll look at this. I'm envisioning a tab on a node that gives you the field UI for that sort of node. Just because I'm thinking why would I have a UI through this is totally different from how I'm making the default one control nodes. So that exists in Drupal 7 and Drupal 8 maybe right now. So in Drupal 7 that was the only way to do things. You would be dropped into a field UI like interface wherein you could control just for that specific piece of content. And then years later the in-place editor panel's IPE was written so that you could do it in line on the front end, which was great. And then amusingly enough when Drupal 8 they wrote the IPE part first and you couldn't do it on the back end. But that is being worked on. So there would be no plans to... There always needs to be a full 100% functionality admin version of it. And we're not sure if the front end version will just have the 80% use case or a full feature version. It will likely be using the settings tray module, which was new in Drupal 8.2 as sort of the next generation of the IPE. But the UI for setting up the defaults should be very, very familiar and identical to the one controlling the overrides. And then you just made a comment about using UIDs referencing the core end of your reference field uses serial ID. That's a bug. There's an issue for it. But that's not my module, so it's okay. And actually someone mentioned earlier this is a question about responsiveness. There is a breakpoint module in core that does a couple things and it should integrate with more advanced. But I'm going to, as of right now, consider that their problem. And they can talk to me about it as opposed to we're not going to work on full breakpoint integration in core in the first couple versions. Mostly because it really needs to be left to the site-specific theme. Yes? You mentioned the new field layout model that's the concept of subregions. And one thing that I've learned from Google that's been a bit of a real learning curve for me is it's how challenging it can be to have like multiple content blocks. Because we have this main content block and yet the design might call for some form of slices. And it's been a challenge there's, you know, a half a dozen or more possible solutions for that but they all seem like a lot of work for something that could be seems like it could be kind of simple to have all the content blocks. I wasn't sure if some of these ideas are kind of like tacking that or is that kind of something? Yes. I didn't really include slide because you explained it very well. But it's kind of a, it's an afterthought to most people when they're thinking about the functionality but it actually is very important. Yeah, so right now you get a single, from the block UI you can control the single main content block. It's in your main content region and then that loads whatever the field UI has, you've configured. And that's it. You don't get to sort of chop things up at that level. But now we have the ability, because blocks are so powerful, instead of just saying, oh, here's your one UI that shows the content. And then you have to go elsewhere to slice it up and you can't interspers other non-content based components. You've always had the ability of panels in D7. And it's been tricky to do and it is brittle because as you add new fields, you have to, it has to decide to put them somewhere and it might put them not where you expect. The biggest issue there is that panels and all those were working from the contrib side. So they had to kind of patch over and alter the core functionality. We have the privilege of being core. So we can just change how things work internally. And they're no longer spending that extra steps going around the core system to make it do what you want. As a core module, we can just change core. So it'll allow us to do a lot more things to make it more seamless and not seem tacked on. That's my goal. Yes. I wanted to ask about a few areas that weren't really discussed. One is having to use. So there have been attempts to have to use displays. Quick tabs, for example. Quick tabs being its own sort of layout area. And also, maybe ideas about using views attachments and being able to put views attachments in some sort of layout system rather than sort of having to create a block to replace them using something like Panelizer. And then lastly, what are plans about being able to the great thing about Panels or really Panels is being able to add contextual filters and things like that. I'm going to take the last question first. No, no one really thought about that yet. The contextual filters, that's really interesting. I don't think we should, we will make it harder to do. I don't know that we're going to tackle it right away. But that I'm going to make a mental note to look into that. The first part about views, because my introduction to core was working on the views and Drupal core initiative, so views is very near and dear to my heart. I can't hear you, Peter, sorry. Your own mic. Yeah. So the ability to slice up a view, so Panels, sorry, C-Tools, which is the underlying code powering Panels and everything, end views itself, provides the ability to sort of slice and dice up your view and say, oh, this part should be this one thing, this thing should be this other. And you can then use Panels to recombine it in interesting ways. Or you can use views blocks, or you can use views attachments and kind of fake it yourself. And going back to what I just said, those are all different systems that evolved differently over the course of 10 years. Some of which had the same authors, some of which didn't. But they each kind of had to both be aware of like views and C-Tools and Panels had to know about each other, but they also had to assume they didn't all exist at once. And the more we put into core the more we core can collaborate with itself, because it's all it's all one package. So I think there are a lot of improvements specifically around views that need to be done. Once we have a landing page builder instead of going to the views UI and then creating a page view it should be a block or paint or whatever we're going to call it and that it should integrate into the landing page builder UI so that you go to the landing page builder UI, you want a view, you can create a view right there and drop it in. It shouldn't be two steps and have to go do the hard part first and then come back to the part you actually care about. You should be able to start with your intention and work all the way through that flow. I think that's, I'm really excited about that possibility of with menus and views and search and all these things that you would usually use another tool to then lay out later to lay it out initially with purpose from the UI that has been designed for you. So I'm really, yeah, that's that's a huge possibility and but that just you know at this point we just need more people. There are two of us that are funded to work on this and then everyone else you know chips in where they can but most of the other people interested are also maintaining the Drupal contributions of panels and displays and whatnot. So the more people, the better. Yes. Yeah, so with blocks being kind of in a global space and being able to be shared across you know more producer content reviews which is obviously one of the great pieces of blocks but the thing that becomes kind of tough is version control or revision I should say Yes. And potentially I don't know if it could be some of the multi-virgin or you know sharing content how do you kind of control that without having a host? Has there been any headway there? Is that something that's still being worked on? Yes and no. So the idea with if we do it a lot the panel as a model you do have a controlling host which is the piece of content itself and that is revisionable if we do it wrong it will be revisionable. With with configuration like a view a view isn't revisionable in the sense that you're thinking of I mean it's configuration so you can dump it to version control and use git to manage your revisions but it's not the same kind of tracking there's no workflow potential there so the original the problem with page manager right now and it's therefore not revisionable with the layout new layout builder proposal there's still it's got to be stored somewhere so there's going to be a controlling entity like a host of some sort that we can store it in it's just a question of where where you can draw the line say this is this little box I want this to be revisioned by itself and that other thing shouldn't know about it that gets back to the the mini panels everywhere or the how do we propagate it down or back up it's all up in the air because Damien who was up here earlier with the bunny ears cares very very strongly about revisions and keeps us honest and makes sure that we don't forget about it so that's going to be baked in at a very low level especially with the workflow initiative with all the work on constant moderation we can't really ignore it now we are forced to deal with it it's good, yeah other questions? thoughts? considerations? so you're killing me I'll do the thing it's for everyone else it's on YouTube and in 20 minutes it'll be on YouTube or whatever just consideration, I think there's a fundamental difference and it needs to be exposed in the UI when you're visioning a landing page or a complicated panel when you say go back do you mean just the layout? I want to see the content I saw here before and you can't there's no way to do it other than giving that choice because the same person in the same situation can say now I want to go back to the previous configuration and now I want to go back to the previous content and if you don't give them both choices in that in regional UI it's never been always the right agreed even if we solve the data model and make it all really make sense to the person pushing the buttons to actually do the workflows if the UI doesn't make sense it's pointless if you don't know what you're actually doing and that was one of the big failings of the views UI the original or the 2x version of views is that you could easily destroy the underlying data because you didn't know what revert meant and it's really really tricky and it's impossible you can't just put more help text because no one reads it ever ever but you need to there's no way to say you don't want to surprise the user principle of least astonishment you don't want it to be them to be taken aback but what does that mean? how do we know what they expect? user testing and making the best choice that we can 30% of everyone will be still angry because we didn't pick their approach and the rest is just training and tutorials and practice and trial and error and hopefully not doing it on production but yeah there needs to be flexibility there but thankfully because the workflow initiative is happening they're tackling this problem where you referenced entities on content and once they continue to solve that or set the path forward with that we can easily just steal their brilliant ideas and pass them off as our own so I mean you touched on this a little bit earlier but the thing that grabs me the most of all is the difference between the new regions and blocks and then the new field layout and what used to be like in the content regions so how likely it is that those will be integrated and using those to do that yeah so the first thing is that we have to make them all use the same API we can't and then we have to come to the hurdle even if we want to do that and if we do can it be configurable because I know for example my previous employer worked they used the distinction between panelizer and display suite to sort of lock things down so display suite was used only by the site builder or the themeer to control things that were passed down from on high and could never change and things using panelizer because of IPE were the parts that the content editors could then manipulate and it was actually really really nice to have that hard fence around your area and say I'm the control of this part and something else is control the next part but forcing that on someone who doesn't have that complex need is a burden a UX burden like a cognitive burden so being able to tear down those walls and say I have one system to manage everything would be very powerful but very dangerous also so it's an eternal push pull there but you don't have the possibility to do that and make it possible and then decide if you want to tell people about it and I am more focused on the API side so I'm going to make that Emily's problem to decide after I do the thing should we actually release it or should I just delete it and pretend it never happened before we can keep going with discussion this is great and I really appreciate all the input I just want to put up this slide there is an issue tag on Drupal Issue Queues it's a safe in layouts there is a plan issue I'm going to post these slides to the Drupal Con site in the next 20 minutes but that is the issue ID 211.175 I got lucky with the 111 right in the middle it makes it easier to remember there is an IRC channel and there is a Slack channel and that's my Twitter handle Tim Plunkett I would be remiss if I didn't mention the has everyone done taking pictures of it I will be there I will be wearing a red Philly's hat and you will be able to find me do not find my imposter there is someone else here who bought a Philly's hat to confuse people I should have picked a more specific brand than just the Philadelphia Philly's but what can I say I love my city the first time Sprinter Workshop if you have never participated in Sprinter before they will help you get set up with your local environment to give you the skills to be able to actually participate the mentored core Sprint is where if you don't really care about layouts at all you can go to that and they will help you get involved with Drupal and learn the process around contributing the general Sprints are where all the topics, specific ones will be and that's where the layout stuff will be happening and I would love to not code and talk to people instead I can write code anytime sharing ideas and concerns and find out what's actually important to people is really key at the stage of the initiative so I'd really appreciate it if you could come by on Friday and discuss that's it for me we can continue to talk, I think we have about 5 minutes or you can get early to your next session thank you very much I think this has become an area that I'm going to be more involved in I'm working with Pfizer we're doing the way group of concepts and right now I've got a unique I'm trying to figure out how to put those together I've got a new model that puts paragraphs and outlines together that may become I need to know if we decide if that's the solution I want what it does is it adds it turns each paragraph delta into a block that you can place on paragraphs that gives you an admin title so that it's unstructured