The Layout Initiative

Transcript

Matt Kleve:

For February 8th, 2018, it's the Lullabot podcast. Hey, everybody. It's the Lullabot podcast, episode 223. I'm Matt Kleve, senior developer at Lullabot. With me as always, senior front-end developer, cohost of the show, Mike Herchel. Hey, Mike.

Mike Herchel:

Hey, how are you doing?

Matt Kleve:

I'm great. So we've been talking about all of the great initiatives that have been happening within the development of Drupal core, and the really cool things going in. There's one more on the list that we need to talk about, isn't there?

Mike Herchel:

Yeah, next step is the layout initiative, which we're going to find out about.

Matt Kleve:

So, for a long time, users have been doing great things in Drupal, but there have been some really interesting workarounds that have been thrown into the ecosystem about how to put stuff on a page.

Mike Herchel:

Yeah. Panels, Panels Display Suite, et cetera.

Matt Kleve:

Context.

Mike Herchel:

Yeah. We're just working with their regular block system.

Matt Kleve:

The block system. Yeah.

Mike Herchel:

Yeah.

Matt Kleve:

Lots of different ways to do it differently, and there's some really great work happening right now to do it the new "right" way.

Mike Herchel:

Yes. The one API to rule them all [crosstalk 00:01:16]

Matt Kleve:

One API, and the folks that know the best are on the podcast today to tell us all about it.

Mike Herchel:

First up, we have a senior software engineer at the Office of the CTO at Acquia. He is the second most prolific Drupal core contributor. He has 1,356 core commits, which is pretty phenomenal. You can always find him wearing a red Philadelphia Phillies hat at DrupalCons. He is known as Tim Plunkett on Drupall.org. That's Tim.Plunkett on Drupall.org, and TimPlunkett without the dot on Twitter. Welcome, Tim.

Tim Plunkett:

Great to be here. Go Eagles.

Matt Kleve:

Also with us today, we have a senior front-end developer also at the Office of the CTO at Acquia. She's responsible for the redesign of the Drupall.org front page. She's from Vancouver, not British Columbia. Washington, not D.C. She says it's basically Portland, Oregon. It's Emilie Nouveau. Hey, Emilie.

Emilie Nouveau:

Hi. Great to be here.

Matt Kleve:

I'm glad you're here.

Mike Herchel:

So, layout initiative. What exactly is it, and what modules are included in, and what do they do?

Tim Plunkett:

Well, the layout initiative's been officially an initiative for about a year and a month. We're working on a couple different things. I'm not even sure which ones we're 100% officially responsible for anymore, but the big highlights are there's a field layout experimental module, the new layout builder experimental module, and then the stable layout discovery module, which is for the layout API.

Mike Herchel:

What do each of those modules do? Let's start with field layout. How do I enable that? How do I work with it, and what can I expect?

Tim Plunkett:

Starting in I think Drupal 8.4, it's an experimental module called field layout. The intention was to just take the layout API and apply it to the existing field UI. So it was for laying out the content of your site and the forms that represent that content. It was intended as sort of a middle ground between the core field UI and Display Suite.

Mike Herchel:

So is this on the manage display tab of maybe content type or something like that?

Tim Plunkett:

Exactly. manage display and then form display.

Mike Herchel:

Okay.

Matt Kleve:

So how is this different than what's currently can be done with even Drupal 7? What's new?

Tim Plunkett:

The difference from core in Drupal 7 is that you're able to select from a predefined set of layouts and rearrange your content into it. So before, you were able to arrange your fields in a weighted order, so just like top to bottom, you could say what order they were in, but now you can kind of group them in the different regions, and have two columns or one column or something more complex.

Mike Herchel:

You can do that on, say, like a per view mode basis?

Tim Plunkett:

Correct.

Mike Herchel:

That's pretty interesting. So that'll follow around views or anything like that.

Matt Kleve:

You mentioned the layout API. Where did that come into play and what exactly is that?

Tim Plunkett:

If you're familiar with either Panels or Display Suite in Drupal 7, you had to write your own layout plug-ins, and if you wanted them to work in Display Suite, you had to write them one way, and you had to write them in, for Panels, you had to write them a different way. There are several other modules that also had similar approaches. The solution was to come up with a single API that worked for all of the different modules in the ecosystem. So we gathered everyone together and identified what the needs were, and came up with a single layout plug-in contrib module, and then iterated on that for a bit, and then put it in core, and [inaudible 00:05:03] was reading layout discovery. The basic use of the API is to allow you to provide your own layouts and the module goes and discovers them, and presents them in a way for your other contrib module to use.

Matt Kleve:

So a module can use a layout that's been defined in code, or you can define a layout in code for other modules to use.

Tim Plunkett:

Yes, and both modules and themes can provide custom layouts.

Matt Kleve:

Okay. So is the layout builder something that could then can build these layouts within the interface that can be exported? How does that work?

Tim Plunkett:

So that is not what that is.

Matt Kleve:

I tried.

Tim Plunkett:

No, and it's funny because we went back and forth with the naming because we were worried people were going to think that's what it is, but really, Emilie had a really great idea that kind of changed how we were thinking about all this, which came after field layout. I'll let Emilie talk about that.

Emilie Nouveau:

Thanks. When looking at new pages that people are building, I noticed that most of them are kind of components based, so they have different laid out sections of the page, and it's pretty common to want to build a layout like that. People have been using paragraphs recently to build layouts that way, so you have different sections that you can move around. The idea was that we can take the layouts [inaudible 00:06:20] by layout API and make them into essentially rows on the page in their different sections, and you can go in as a content editor and say okay, I want to add a new section to the page. Here I'll select the layout, and then you can put the content into each bit of that layout into regions. Then you have basically different sections that have their own layouts, and you can stack them to build out your page.

Mike Herchel:

That seems kind of interesting. Let me make sure I understand this properly. I define, I can add multiple sections to a page, and within each of those sections, I can, say, make that into a two or three column layout. Is that correct?

Emilie Nouveau:

That's correct.

Mike Herchel:

Wow. When I add content into those sections, is that maybe a field or a block or a view? What type of content can I put into like each region within the section?

Emilie Nouveau:

Yeah. So right now, you can put in blocks into each of those regions, and what we're doing is working on exposing entities as blocks so that you can put different fields into the area. Basically the idea is you can put any bit of content into those spaces, and they function as blocks.

Mike Herchel:

That'd be pretty amazing.

Matt Kleve:

I'm trying to imagine this. To be honest, it's not anything that I've taken a look at yet. I haven't yet downloaded the bleeding edge and started to work on it or play with it at all, so I'm coming from a perspective of knowing nothing, but listening to this explanation, I'm seeing a lot of parallels to how Panels used to work. Did we build Panels in Drupal 8?

Tim Plunkett:

It's closer to Panelizer than Panels.

Matt Kleve:

Yeah. I guess I kind of think of those two things together, since they often get installed together, so okay. Panelizer. Okay.

Tim Plunkett:

Yeah, so it's directly inspired by Panelizer in the sense that the intention is to lay out your content, and that's kind of the focus of this so far has been on content, since that's what drives most of Drupal is a content management system.

Matt Kleve:

You need a system to manage your content, right?

Tim Plunkett:

Yeah. I just wanted to kind of bring it all together. I was trying to explain this to someone recently. If you have an article, you want to lay out an image at the top with a description of that image next to it, and underneath that have like the main article about that image. And then beneath that, you might have three different calls to action, like one right next to each other. Previously you'd have to go in and write a template that says okay, I have a two column, and then one big column, and then three columns at the bottom. Instead of having to do that, you can go and add three sections and make the first section a two column, a one column and then a three column, and just combine those very simple smaller layouts into one larger, complex one for that whole piece of content.

Mike Herchel:

So how is the styling with this? I'm assuming it comes with maybe some default CSS.

Tim Plunkett:

Core ships right now with about five or six different layouts that were exactly the same ones that were in Panels in Drupal 7 and Drupal 8. It uses CSS ... What is it? Sorry, Emilie. How about you talk about this part?

Emilie Nouveau:

Oh, yeah. That one's using Flex right now. Yeah. Eventual goal would be to get them on CSS Grids, but Flex is what was ready when we've been building it out.

Mike Herchel:

I know that Internet Explorer 11 doesn't support CSS Grid unfortunately. So you're probably going to be stuck with Flexbox.

Emilie Nouveau:

The current layouts are using Flexbox. The current discussion is around having some simpler layouts that are going to be more suitable for rows, because some of the current ones have a header and footer area.

Mike Herchel:

Okay.

Tim Plunkett:

The markup in CSS for each of those is defined by the layout template itself, by the layout plug-in. So if combining them into multiple sections doesn't add any additional markup or any additional styling, so it's completely up to the individual layouts that you choose to combine together to make the markup for the whole page.

Mike Herchel:

That makes sense. You said earlier those can be either in the theme side or on the module side, correct?

Tim Plunkett:

Correct.

Mike Herchel:

So let's talk a little bit about challenges. How long has this been in discussion, and what were the challenges of getting this into core?

Tim Plunkett:

Well, there was originally a layout initiative in Drupal 8 during the 8.0 cycle that I wasn't involved with. This sort of grew out of that in a way.

Matt Kleve:

You're referring to the SCOTCH initiative, right?

Tim Plunkett:

That was called the SCOTCH initiative.

Matt Kleve:

Yeah.

Tim Plunkett:

Don't make me try to remember the acronym, but it was called the SCOTCH initiative.

Matt Kleve:

Well, I think it was just some people trying to be smart because the other one was called WSCCI, right? The web services core something, something initiative, right?

Tim Plunkett:

Core context initiative.

Matt Kleve:

There you go. Yeah. So SCOTCH has to be the same but different. From what I recall, SCOTCH relied on WSCCI, so it had to be done later, so it just kind of never got done in time.

Tim Plunkett:

Correct. This was a fresh start, as it were. It really grew out of the fact that we banded together to come up with this single unifying layout API that for both Panelizer and Display Suite and Panels to all use. Once we had some momentum on that, we thought of ways we could introduce it to core, which is when I came up with the idea of field layout as just bringing layouts to the field UI.

It was a solid effort, and it required a lot of fixes to other parts of core to make it expect that content could actually be laid out more than one way, and not just the assumption that it's all going to be in a single stack. But since then, we had a conversation at DrupalCon New Orleans, and then most recently, this concept of sections. I remember Emilie talking about it at Baltimore. After Baltimore, we have a sprint, and we came up with a working hackathon level ready demo in May, and then have spent since DrupalCon Vienna kind of working full-time putting it into Drupal core for 8.5.

Mike Herchel:

Yeah. I remember during the Driesnote in DrupalCon Vienna, there was this video that he showed, and they showed the layout builder with the Umami theme, and it looked beautiful. It was just like super easy. They had integration with the settings tray and stuff like that. It was very, very slick. Was that all made up?

Emilie Nouveau:

That was a real demo. We wanted to show what we could do with the Umami theme so you could see what you'd actually do on a real site using the real code that we had at the time.

Tim Plunkett:

Yeah, we didn't cheat. That was real, actual PHP code running. Yeah. Emilie built the whole demo, but it was all using real, actual code.

Mike Herchel:

Okay-

Tim Plunkett:

As you mentioned the settings tray. We did build layout builder, the UI for it. The layout builder UI uses the settings tray to [inaudible 00:13:54] dialog. So every time you go to click to add a new section or configure a block, it slides out this dialog off the side of the screen, and lets you make your changes in real time the layout in front of you.

Mike Herchel:

That's pretty neat.

Matt Kleve:

All this talk with building our new layout system, field layouts, the layout builder, that kind of thing, this is all happening within Drupal core that already has block layouts and the way that that works. How do the two play nice together?

Tim Plunkett:

They play very much the same way that blocks play with the manage display in stock Drupal 8, which is that they don't really care about each other. [inaudible 00:14:35] used to control the main content area of the page. Global the [inaudible 00:14:42] is still controlled by the block UI. Some people think we should bring the section and layout functionality to the full page. That might still be done. It might be done in contrib, but the idea right now is to keep it confined to the main content page. If you want to be able to control to full width of the page, you just don't have any sidebars in your theme. Then you won't have to worry about it.

Mike Herchel:

Can you set custom visibility rules for, say, like fields and stuff like that within the, I don't know, the field layout module? For example, if content exists, then do this, or if that field doesn't exist, do something different?

Tim Plunkett:

No. The field layout module is really just fields UI plus the concept of layouts. Like it had no other extra features there. You will be able to place your fields in that UI [inaudible 00:15:38] for each. The way we do that is we have made fields exposed as, and blocks already have visibility settings, so you place the blocks within your sections, and they represent the fields. So you can still do the same sort of visibility conditions.

Mike Herchel:

So you mentioned the settings tray and, you know, it's this jQuery off canvas dialog, and I'm guessing that the layout builder and all the drag and drop stuff is also jQuery, but there's also a push to integrate React or some type of modern Java script library into Drupal core. Is there plans to upgrade like any type of legacy jQuery code to React or anything like that?

Tim Plunkett:

Yeah. There has been some discussion there. Actually, in a bunch of the React things they were discussing what feature of Drupal would be the best one to start with, and they were thinking about doing the toolbar, for example, but the toolbar is special in a way in that modules want to be able to add things into that UI, into the toolbar. So shifting that from jQuery, or actually it's I believe the tools are in Backbone.

Emilie Nouveau:

Yeah.

Tim Plunkett:

Just something new like React would be basically a API break. The nice thing about layout builder is the API is just at the data model level. The UI itself could be changed at any time. So yeah, right now we're using jQuery UI Sortable, and using the jQuery modals for the configuration tray. [inaudible 00:17:16] we write that entire UI in React without anyone noticing, since no one's going to be hooking into this UI to change it.

Matt Kleve:

This is a lot to throw at a user when we talk about laying out a page or laying out fields within an entity or something like that. Talk a little bit about the design process and how this is something that we're going to roll out to users and it's something that can be usable.

Emilie Nouveau:

Yeah. For end users, the goal is that they won't really have to think about what's behind this at all. When they go to create a landing page, they will be presented with their blank slate page, and they have the option to just add a section, and they'll see there that they can add content. From there, the settings tray pops out, and that's where they select layout, and then they can select their available content all from the settings tray. Then they, once they're done with that, can go to add another section if they need to for the page. The idea is that it's just seamless content editing, where they don't have to really touch any of this configuration, and they can build their pages all from their content area.

Mike Herchel:

Did you or anyone else do any type of usability testing with the new UIs?

Emilie Nouveau:

We've done a little bit of usability testing with some content editors around what they expect from interactions. That's how we've gotten some of the idea of how we should put, add content, how to surround it in a way that draws their eye. But I do think we have some more usability testing that we can keep doing as we're iterating through designs, so I'm excited about that.

Matt Kleve:

We're talking about the layout initiative on the Lullabot podcast. Making Drupal 8 great as far as your layouts go. We're talking with Tim and Emilie, and they know everything about it, and Mike and I are learning a lot about it. We'll talk about the status of things and how this is moving into the future coming up right after this.

Commerical:

Whether you're learning how to build sites with Drupal or diving into the code, there are community power camps, summits, sprints and trainings happening all over the world. Coming up in February and March alone, there are events in Princeton, New Jersey; Portland, Oregon; [Milano 00:19:46], Italy; London, England; Orlando, Florida; Charlotte, North Carolina; Chicago, Illinois; Panjim, India; Essen, Germany; Amherst, Massachusetts; Buenos Aires, Argentina; and San Diego, California. Find all of these and more at Drupical.com, and of course if you want to boost your Drupal chops from the comfort of your own home, point your browser to drupalize.me, and stuff your brain full of carefully crafted videos and tutorials.

Mike Herchel:

Welcome back. We're talking with Tim Plunkett and Emilie Nouveau both from the Office of the CTO at Acquia. We're talking about the layout initiative, which is drag and drop interface to move your content around in core. So that's pretty awesome.

Matt Kleve:

Yeah. It's really great that this is coming to core, Mike, because this type of functionality has been able to be done for a long time for a Drupal user, but it takes three or four different contributed modules and a lot of configuration and holding your tongue right. A lot of knowledge in the background, but bringing it in to core I think brings a lot more power to Drupal, don't you suppose?

Mike Herchel:

Yeah. There's always competing solutions. Say, like going in between context and Panels and stuff like that. You have to make that decision early on in the architecture process, not maybe understanding the full ramifications of what you're doing.

Matt Kleve:

I waved that context flag for a long time.

Mike Herchel:

Yeah? I like context. It was easier to grasp, although the user interface for it was obviously pretty terrible.

Matt Kleve:

Yeah. So, Tim, Emilie, this is something that will be rolled into being an experimental module in Drupal core at some point, or what is the status of things right now?

Tim Plunkett:

Right now, it's an alpha stability experimental module, which means it's still in active development, and everything is breaking every other day, and you shouldn't use it yet. But we're really pushing hard to get to beta stability, which just means you probably still shouldn't use it in production, but you can start sort of specing it out and integrating with it if you so choose, and seeing if it's going to be the solution that you need. The hope is that it'll be a beta experimental module in the Drupal 8.5 release coming out on March 7th.

Matt Kleve:

Right on [inaudible 00:22:09]

Tim Plunkett:

Yeah.

Mike Herchel:

Now, is that for all of the modules that we mentioned? The field layout, layout builder and layout discovery?

Tim Plunkett:

Though layout discovery is a stable module right now, and that's the thing that you use to define and provide your own custom layouts, so that's already in core. Shipped as a stable module. You can safely provide your layouts using that API and nothing needs to change.

Field layout is, field layout's in an interesting spot. As I explained before, it was like an incremental improvement. It was intended that way. Just sort of just bring a little bit of the new stuff to the existing field UI. It's largely going to be supplanted by the layout builder, but only in one key area, which is laying out your content. Laying out your forms and your content forms is still something that only the field layout module can provide. Layout builder has no path forward for that yet. Field layout for content forms has been relatively well received. The ability to just kind of change the order and the presentation of the forms, so that it makes sense to your content authors has been pretty great.

Matt Kleve:

For clarity, you're talking about like an entity form, right? When you're talking about content forms?

Tim Plunkett:

Yeah. So if you're writing a new article, you might want to give them the things that make the most sense and lay them out next to each other, or if there are fields, if you're making a recipe. Like, oh, the directions and the ingredients are two separate things. They don't need to be right on top of each other. They can be kind of shifted around. But the meta stuff and the sidebar [crosstalk 00:23:45]

Matt Kleve:

On the node-add form an image and a caption might be next to each other or something like that.

Tim Plunkett:

Exactly.

Matt Kleve:

Yeah.

Tim Plunkett:

Exactly.

Mike Herchel:

You mentioned the layout API is stable in core. Does that mean contrib is currently taking advantage of it?

Tim Plunkett:

Yes. Display Suite, Panelizer, Panels are all using the layout API and they no longer have to have their own custom solution for layouts.

Mike Herchel:

Okay. So does that mean I can maybe, say, ditch Display Suite, go to Panelizer, and back again, and still be able to keep my layouts?

Tim Plunkett:

Yeah. You'll be able to use the layouts that you've written. So like the template and the markup and the CSS and all that is completely portable across any of them. I mean, obviously between the two architectures, you'll have to get your data in and out in configuration, but the layouts themselves are completely portable.

Mike Herchel:

That's pretty awesome.

Tim Plunkett:

And that will also be true for this new core solution, is that the layouts are all shared between them.

Matt Kleve:

So if I'm building a website today in Drupal 8 and need a way to do layouts, what should I do to make sure that I'm future proofed?

Tim Plunkett:

My recommendation right now would be to use Panelizer. It's the one that maps the most closely to layout builder, and there's also the Panelizer maintainers have, I don't want to say promised, but they plan to write an upgrade path from Panelizer to the core layout builder.

Matt Kleve:

They're volunteering to deprecate themselves?

Tim Plunkett:

Yeah, they are. There's only a couple things that are going to be left that not supported by core once it's finished. Panelizer has this concept of multiple defaults, so that you can swap between like pre-configured different layouts, not just the layout, the visual representation of them, but the fact that they actually have, let's say the body's in the right region, and the tags are in this region, these kind of click together configured layouts. You can define this multiple of those in Panelizer and switch between them. That would be something that we would still left to contrib, but that could be just that single standalone module that does just that.

Similarly, on the Display Suite side, they have expressed interest in deprecating Display Suite in favor of layout builder. There are a lot of other things the Display Suite does in sub-modules. Like there's a module called Display Suite Extras, and it does a lot of extra things. That will very likely continue to live on, but the core functionality of Display Suite should largely go away.

Matt Kleve:

This is kind of exciting and slightly terrifying at the same time in the same way when somebody told me that views was going into core. It was like wait a minute. Hey, that's great. Everybody uses it anyway, but developing something like views or something like layouts, for example, like we've used Panels in the past or anything, I mean that's a ton more code. That's a lot new functionality that will maybe get dragged behind by the core process, but I think that might not be true. I'm talking myselves in circles because it's like oh, this is cool. It's going to be in core, but it's like wait. But it's in core, and that might not be a good thing because of the speed of development and iteration on new features, but it's like, well, no. That's not how core works anymore. So I don't know. It's just kind of cool.

Tim Plunkett:

Yeah. Core's a completely different animal than it used to be. It was like three, four years in between releases before. Now it's every six months.

Mike Herchel:

Yeah, and we're not having the small core versus big core discussion anymore, are we?

Tim Plunkett:

No. It's just fast core.

Matt Kleve:

Giant core?

Tim Plunkett:

It's moving quickly. It's not even giant. Well, I don't want to use ... I don't mean it in the software sense, but it's agile. It is nimble. Core is nimble. It could react quickly now to changes in the market, and the needs, and we can iterate on things, especially with this new experimental modules process. It hasn't been smooth necessarily, but I think core is finally hitting its stride with regard to experimental modules. I really hope that this field layout to layout builder transition will be a good example of how that works.

In layout builder, I've written an upgrade path, so it'll upgrade your regular, if you use manage display, like vanilla field UI, it'll migrate all your stuff over to this new section based layout. But if you're using field layout as an experimental module, it'll also migrate that. So you can make a smooth transition from one to the other.

Mike Herchel:

How has the experimental modules capacity affected this initiative?

Tim Plunkett:

Can you rephrase? What do you mean capacity?

Mike Herchel:

Well, like the fact that Drupal core has the ability to have experimental modules in there, that's a relatively new thing as opposed to like one big monolith, all in one, 100% done patch. How has that affected your ability to develop this to put this in core?

Tim Plunkett:

Yeah. It's certainly let us be a lot more flexible. Like we've able to scope the things out and say this is required for like a beta version. We can't ship without these eight things because this is the bare bones what everyone expects, the minimum viable product. Then we know what really needs to be done to call it stable. Like it doesn't have to just work. It has to look good and be intuitive and be bullet proof, and make sure we've nailed all the edge cases. Then even after we then get to a stable point, we can still iterate and add new features as we go. As we do usability testing both controlled usability tests and also just listening to people complain about it on Twitter, we can respond and make improvements as we go.

Mike Herchel:

So Twitter is a valid place for me to complain about this?

Tim Plunkett:

Absolutely not. No. No. Nevermind. Edit that part out.

Mike Herchel:

Tim's Twitter handle is TimPlunkett without the dot in there. @TimPlunkett.

Emilie Nouveau:

I will totally take feedback on Twitter, if that's where people want to provide it.

Mike Herchel:

Thanks.

Tim Plunkett:

We actually did some user research. Like Angie webchick tweeted out some stuff recently looking for some feedback, and there was some interesting feedback. I read it, and then I closed my browser and went back to not looking at it. Emilie, you know, you did actually have some really good interactions with people on that thread and get something usable out of it.

Emilie Nouveau:

Yeah. I thought that was really helpful. Sometimes people feel more comfortable interacting on Twitter than they do in an issue queue, so I will take feedback wherever I can get it.

Tim Plunkett:

That's D-Y-A-N-[crosstalk 00:30:20] E-N-O-V-A, right?

Emilie Nouveau:

No. Feel free to tweet me.

Mike Herchel:

Yeah. And we'll have underneath the little introduction section within the podcast page, we'll link to your Twitter accounts.

Matt Kleve:

What you're saying though actually kind of makes sense because if I'm on Twitter and I'm just griping, like I'm just griping, and if maybe somebody asked me a question, I can explain my gripe a little bit better and more than just bitching. But if I'm in an issue queue, it's like I'm volunteering to do it. I understand the difference there. So that makes sense.

Mike Herchel:

Is there any features that you were really, really hoping to get in that are not making it into any of these modules?

Tim Plunkett:

For me, there's this thing in Drupal 7 Panels called, I believe it's just pane styles, like for the Panel panes, and it's sort of the ability to write customizable styles around it so that each individual piece of content could have its own sort of wrapper that's defined outside the content. That's definitely not going to be something that we get into the first version, but it's something I really think is powerful and was underutilized before. If we can get it into core and surface it in an interesting way, I think it could be a big help to a lot of people.

Mike Herchel:

Is that like the rounded rectangle thing or the [crosstalk 00:31:36]

Tim Plunkett:

Yeah. And that's really not the ... That's a very web 2.0 usage of it. It was a nice way to demo it, but that really didn't even scratch the surface of what's possible there.

Emilie Nouveau:

One example I think of pane styles and use in modern design is Drupal.org's page uses a different style for banners or for a logo call-out or things like that. That's done with a pane style for the editors.

Mike Herchel:

Yeah. That really does fit into component-ized design and development, which is pretty neat.

Emilie Nouveau:

There's one feature that I'd really like us to be able to get in that's using the toolbar edit modes. Right now, in layout builder we're using the local tasks for doing your saving and canceling, but we have this idea of using the edit modes in the toolbar and having basically a real edit mode that modules can plug into. Then it goes into just that space, but we need to work out how exactly we want do do that for all of core. That will be after [MVP 00:32:48].

Mike Herchel:

That sounds like a nice usable feature.

Emilie Nouveau:

Yeah. I'm really excited about edit modes. I think that they'll make a big difference for people.

Matt Kleve:

What else are you excited about, Emilie, when you think about the initiative as a whole? What parts of the project are really cool?

Emilie Nouveau:

Actually, I'm really excited about seeing the out-of-the-box initiative and seeing how that plugs into all of these things. It's been a lot of fun to see people seeing these initiative tying into each other, and when you can look at how layout builder is used in out-of-the-box and how media will be used in out-of-the-box, I think seeing all of these come together for people really has been fantastic.

Mike Herchel:

Yeah. We did a podcast two podcasts ago with the folks from the out-of-the-box initiative, which was pretty fantastic.

Matt Kleve:

Tim, if you don't mind if we go back a second. We were talking about some of our parallels to Panels and the way things were done before. How within a layout, are we able to pass around contexts and arguments in a similar way that a Panel's layout might have been able to do that?

Tim Plunkett:

Yeah. That's actually one of the things I would say is something I'm really interested in working on is expanding on that. All the things are now using, all the blocks are using context, specifically the field blocks, they require the context of the parent entity. So if you're laying out a node and changing the layout for that node, it knows which fields it has and you can do that. You can even use any references and then pull in other content via those references. But navigating along that path and saying oh, I don't want just the user who authored this. I want their picture, just their picture. Being able to drill down into that level is something that is possible in Panels in Drupal 7 and Drupal 8, but is really, really, really complex. It can get out of hand quickly, and it's not, we haven't figured out a way to intuitively present that.

I both want to work on the functionality, but I also really want to just finally try to get that right and be able to expand the context available from just the piece of content that you're viewing to something larger.

Mike Herchel:

Yeah. That sounds pretty interesting. Performance wise, I'm assuming this integrates in with Drupal 8's caching system?

Tim Plunkett:

Yeah. Caching is kind of a prerequisite, if not for core modules at this point. When you write automated tests, the caching is enabled to the fullest extent while the test runs. The test mocks, it logs in as a user with a set of permissions and then clicks around. Every time I wrote a piece a code that didn't bother with the cache stuff, I wrote the test and it failed immediately. I had to say, oh, you know, well I was checking the paths, so I need to say that this is cached by which path it's on. Or this is related to the user's permissions, so that has to be cached by the user. Then the test would pass.

That's actually one of the best things about doing this as a core module, is that we're held to that standard, so that these things aren't an afterthought. We have to have full unit tests and functional tests for everything, and they catch all sorts of schema issues and caching issues and access issues and everything upfront. So we're really putting out a good product at the end of the day by doing it from within core.

Mike Herchel:

So let's talk about what's next for the layout initiative after everything goes in. You mentioned we're hoping to get this in 8.5. Is that a sure thing yet, and what's blocking it? What do we need to do to make sure that's in 8.5?

Tim Plunkett:

Yeah. The beta deadline for Drupal 8.5 is February 7th, which as I'm told will be the day before this podcast airs. The notes posted along with this podcast can tell you whether or not it happened or not. There's a number of things that we have as beta blockers, as we call them, for what needs to be done in order for it to ship. If we get them all done, it will be available in 8.5, and if we don't, it will be delayed til 8.6, which will be released in the fall.

So in terms of helping with that, it'll be a moot point by then, but even after ... Once we get through the beta, if it lands in 8.5, that's when the real fun starts because we've really pared down the list of things that we're working on right now to only include things that are absolutely required. And once we get all those check boxes checked, then we can start opening it up to work on the things that need to be done in order for it to be stable, but also any other additional features and things people want to include in actually making it real and not just the minimum version of itself.

Mike Herchel:

Are you going to be talking about this at DrupalCon Nashville, hopefully?

Tim Plunkett:

Yeah. Session submissions for DrupalCon closed yesterday, so I know that we, multiple people from the layout initiative submitted multiple sessions, so we will see. But all the initiatives will be speaking in some capacity, whether it be a full session or just a series of BOFs. So there will definitely be someone there talking about the layout initiative in an official capacity at DrupalCon Nashville.

Mike Herchel:

Okay. Are you going to be sprinting on the Friday afterwards, and if so is there anything that maybe newcomers can help out with or is there any particular need that you can identify that people might be able to look at?

Tim Plunkett:

Yeah. I'll have the link along with the podcast, but we have an issue tag that we tag all of our issues with. It's blocks-layouts, and there are a lot of issues in there. We need pretty much every discipline that's relevant to Drupal. We need end users. We need site builders. We need themers. We need back-end developers. We need people to write documentation. We need people to test translation. Like everything you can think of, we need. We want to show off the people, so if you're an evaluator, come by and make sure it actually has that wow factor.

Mike Herchel:

So bike shedders?

Tim Plunkett:

Yeah. Bike shedders have a special table in the back. Everyone else can come sit at our table.

Mike Herchel:

Okay. That sounds wonderful. Yeah. People can identify you. Are you going to be wearing your red Philadelphia hat?

Tim Plunkett:

I will either be wearing red Philadelphia hat or I'll be wearing all green, all the time for the Philadelphia Eagles. That remains to be seen.

Mike Herchel:

Yeah, yeah. So like by the time this podcast comes out, we should know if your city is still standing.

Tim Plunkett:

One way or the other, Philadelphia will make it through.

Mike Herchel:

Any final thoughts, starting with Emilie?

Emilie Nouveau:

Yeah. It would be great to have people who are interested in front-end work and in design to come by and both look at the usability of it and work on improving the design because right now we have our MVP design, but we'd love to add even more polish to it. I'm excited to see this go in. I'm excited to see content editors getting to use it.

Mike Herchel:

I'm excited too. Tim, what's your prediction for the Super Bowl? I want an actual score here.

Tim Plunkett:

I'm going to say 31-21, Eagles over Patriots.

Mike Herchel:

All right. All right.

Matt Kleve:

We have to keep in mind that this podcast was recorded on January 25th, where the Super Bowl is February 4th, so ...

Tim Plunkett:

Alexa predicted the Eagles would win, so, you know.

Matt Kleve:

Alexa must be right.

Mike Herchel:

Yeah. There's no going against Alexa. You know if the Eagles lose, then the Eagles were wrong and not Alexa. That's how it works.

Tim Plunkett:

Right. Absolutely.

Emilie Nouveau:

I'm just going to avoid the whole Super Bowl by attending the Drupal Summit in Portland.

Matt Kleve:

Good plan.

Tim Plunkett:

I'll be skipping out on the end of Drupal Camp New Jersey to go watch the Super Bowl unfortunately.

Mike Herchel:

Drupal Camp New Jersey and Drupal Camp ... Was it Drupal Summit, Portland, right?

Emilie Nouveau:

Pacific Northwest Drupal Summit in Portland. Yeah.

Mike Herchel:

Those will be in the past, but I'm sure they will have been awesome events. Tim, do you have any final thoughts about the layout initiative?

Tim Plunkett:

No. I'm just really excited for the progress we've made so far, and I'm really looking forward to working on some of the new stuff now that the plumbing is mostly out of the way. I really mostly just want to get it in the hands of real people and see how it improves their Drupal experience.

Mike Herchel:

Exciting. Well, thanks for coming on.

Tim Plunkett:

Thank you.

Emilie Nouveau:

Thank you.

Mike Herchel:

If anyone has any feedback, feel free to tweet at Emilie but not Tim. Thanks.