Mike and Matt invite Layout Initiative lead Tim Plunkett on the podcast to talk everything about Drupal's new Layout Builder, its use-cases, issues, and what's new in Drupal 8.7, and what's coming next!
Episode Guests
Tim Plunkett
Principal Software Engineer at Acquia and proud Philadelphian.
Mentioned in this Episode
Transcript
Transcript
- Matt Kleve
- For May 23rd, 2019 it's the Lullabot Podcast.
- Matt Kleve
- Hey everybody it's the Lullabot Podcast episode 237. I'm Matt Kleve, Senior Developer of Lullabot and with the always Co-host of the show, Senior Front End Developer, Mike Herchel.
- Matt Kleve
- Hey Mike.
- Mike Herchel
- Hey, good afternoon Matt.
- Matt Kleve
- Good afternoon. You know we're recording a Podcast and we're not sitting next to each others. How did we ever do this before?
- Mike Herchel
- Through the magic of tubes.
- Matt Kleve
- The series of tubes known as the internet?
- Mike Herchel
- The series of tubes, yes.
- Matt Kleve
- Yeah, so on the Lullabot Podcast we talk all things Lullabot. Generally, in the Drupal's space right? Where a Web Development Strategies Designed Development company that works primarily in Drupal and we're going to learn some more about some of the latest, greatest stuff coming out of Drupal 8.
- Mike Herchel
- Yeah, we're revisiting a topic that we talked about, what, a little bit over a year ago with Layout's and for those of us that have tried out the newest version of Drupal, Drupal 8.7, one of the biggest within that release is that the Layout Builder Module is now stable and that's huge.
- Matt Kleve
- Yeah, we've talked a little bit about this in the past. We had our guest on before.
- Mike Herchel
- Yep.
- Matt Kleve
- And when we talked about the Lullabot website, we heard all about how Layout Builder was super and you know how it really helped us leverage making cool things happen on our website.
- Mike Herchel
- Yep and with us today to talk about that is Tim Plunkett, who is a Principle Software Engineer- Acquia. He's working on the Layouts Initiative, at least until this week. Right Tim?
- Tim Plunkett
- How's it going?
- Mike Herchel
- I'm doing pretty good. And you're from Philadelphia and you're typically in a red Philadelphia, Philly hat. Is that right? Are you wearing it right now?
- Tim Plunkett
- I am wearing a maroon 1980's throw back Philadelphia Philly hat right now.
- Mike Herchel
- Okay, we'll allow that. That's good.
- Tim Plunkett
- Maroon's red.
- Mike Herchel
- Yeah, yeah. Yeah.
- Tim Plunkett
- Thank you for the clarification.
- Matt Kleve
- I think we're kinda with you now in spirit even if we are separated by tubes, so, I don't know, first of all congratulations.
- Tim Plunkett
- Thank you very much.
- Mike Herchel
- Yeah, it was a lot of work. I'm assuming it was a lot of work to get this into Core, correct?
- Tim Plunkett
- It really was. Thankfully we had a big team working on it and over a long period of time now. The plans for it with the Layout Initiative about three years ago, the ideas for [inaudible 00:02:40] came up about two years ago at Triple Con and we've been working on it since then.
- Mike Herchel
- Wow, yeah, and it shows the amount of work. So let's maybe start by talking about the process of getting it into Core. Let's talk about maybe the genesis of the idea and how you proposed it or who proposed it and [inaudible 00:03:04] and things like that and getting it in.
- Tim Plunkett
- Absolutely. The Layout Initiative itself kinda [inaudible 00:03:12] for a bit. The ideal was that there was all these modules and featured panels and panels that are in display suite that needed a singular mechanism for defining Layout's and that was added to Core as the Layout API back in Triple A.3 and so from then it was like, "Okay now we have this generic API that we can do these things with, what should we do next"? The first attempt was just try to improve the Field [inaudible 00:03:42] as it was in place and it was an experimental Core Module called, Field Layout and it was a nice attempt, it was a good experiment but it didn't really go anywhere and it really wasn't worth the sort of pain it caused for existing sites, the upgrade was the way it broke your templates. It really wasn't worth it for the functionality you got but was a really good experiment to see what it would be like to put something like that in Core.
- Tim Plunkett
- So coming out of that failure at Triple Con in Baltimore, Emilie Nouveau, who also is a Engineer at Acquia, proposed a new kind of approach to things. And that grew into now being called Layout Builder.
- Mike Herchel
- That is awesome. So how did she propose on getting this into Core and what was the process on, did you just decide, "I'm going to do this" or did you have to pitch it to someone?
- Tim Plunkett
- Yeah. So there's a process for this with Intregral. There is a separate issue key outside the Core Issue queue and it's called The Idea's queue and there's a define process of how you do ideations and how you step through proposing a product introduction to Core. Anything that isn't [inaudible 00:05:02] facing thing would be we go through this process. So we were actually out at Sprint. We were working on getting panels and Panelizer stable for Drupal 8 and having a migration path from Drupal 7 and at the end of that Sprint we had an extra afternoon and so a bunch of us sat around and discussed it and particularly Emilie and myself and Angie Byron "webchick" who is a Product Manager of Drupal core and sort of went through some of the feedback that she gathers from the community about what people need and ran the proposal by the UX team at the time, the Usability team, which is a group of volunteers that work with Drupal core to kind of validate and give advice and propose UX related functionality.
- Tim Plunkett
- So from there after pitching the idea to them and getting some initial positive feedback, we sat down and came up with some user stories and then went from there to designs and then at a Acquia Hackathon we began to actually code the module, which is very different from how Drupal modules end up starting which is usually someone writes a proven concept and then you just go with that and try to incriminate and prove it from there.
- Mike Herchel
- Scratching the itch, right? Yeah.
- Tim Plunkett
- Starting with user stories and designs is very backwards for how Core usually works but it's how software should work, in my opinion, and it really set the foundation for the success of the initiative.
- Mike Herchel
- Yeah, so it came into Core in what, 8.5 experimental? Is that right?
- Tim Plunkett
- Yeah so a year ago it was added to Core Triple 8.5 and then from there it had the general rules experimental modules supposed to have about a year to finish up whatever they had not finished. A experimental module has to have a stable data module, a stable API and no glaring obvious visibility bugs or performance regressions or any secure code or anything like that. So from that point a year ago we had that time to finish all of the outstanding work and it was a lot. We had a team at Acquia of about five or six, depending on the time of year, different engineers working on it. And at the end about six engineers working full time just [inaudible 00:07:31].
- Mike Herchel
- Wow.
- Matt Kleve
- That's a lot of support.
- Tim Plunkett
- It really is, I mean, I'm really fortunate to have the institutional backing that I have and the whole team has that same sort of support but even on top of that there were I would say a dozen really key volunteers that were working on the Uploader and then several dozen, maybe 50 plus people working to help out incrementally. So it wasn't just Acquia product or anything it's very much the communities project but it was just that instead of working nights and weekends we were fortunate to be compensated and aloud to work on it as our day job.
- Matt Kleve
- When we developed Lullabot.com we developed it within Layout Builder 8.6, what are the big changes between that experimental version of Layout Builder and 8.6 going forward to the stable version 8.7?
- Tim Plunkett
- Honestly from 8.5 to 8.6 there wasn't to much extra. There were some low hanging fruit, bug fixes that we got in the in evenings six months but coming off the big push to get it into Core, there was kind of a breather period and honestly a bunch of us were kind of burnt out.
- Mike Herchel
- Yeah. That's understandable.
- Tim Plunkett
- Yeah so there wasn't really that big of a difference from 8.5 to 8.6. And from 8.6 to 8.7 is basically the entire rest of the work.
- Mike Herchel
- Yeah.
- Tim Plunkett
- So there is actually a huge difference from 8.6 to 8.7 on the API side as well as the UI side and addition a lot, meaning 90 percent of all the explicit work we did around accessibility landed in 8.7 even though we've been working on it through out.
- Mike Herchel
- Yeah, accessibility is a big topic that I wanna talk about. I feel I'm jumping ahead just a little bit though, maybe we should kind of explain to give the 10,000 overview of what exactly Layout Builder is from a user interface point of view for maybe a Drupal developer that has, you know, experience in the Field UI and, you know, maybe display speed and stuff like that.
- Tim Plunkett
- Yeah, sure. Absolutely.
- Tim Plunkett
- For a site builder from their perspective, it completely replaces the Field UI for any place that you turn it on so it can be turned on for any specific bundle [inaudible 00:09:52] per for nodes [inaudible 00:09:55] for comments and for each one of those you can then configure the display of your fields similar to how you might have done things with display suite except for with the ability to re-arrange them into different layouts sort of like Panelizer but without making all comparisons to existing modules, in Triple Core without Layopular you get to control the order the fields display. And it's just this is the order they are in printed in flat. With Layopular you can group them into different sections and within a section with different regions. Previously when you had to write a very complex layout, let's say you wanted a big banner at the top and then two columns were you have a big picture and then a small, you know, call to action and then the body of the text and at the bottom three more things where their recent articles or something.
- Tim Plunkett
- In order to do that you would have to write out a custom layout that said, "Okay, one column, two columns. One column, three columns". The key difference from Layout Builder is that you can click together that using smaller building block simpler layouts to literally say, "Hey I want a one column layout". Done. Then you put in two then in one then three. And instead of having to code any of that and write NCSS or any templates or anything you can just pick from those pre-defined ones and stack the layouts themselves and then re-arrange all your content within them. I think that's the real key differentiator solutions.
- Mike Herchel
- I 100 percent agree with you. I think there's an additional key differentiator though. The fact that it's kind of done on the front end of the site so you can actually see the content there. So for those that haven't used Layout Builder you will go to, for example, like a node, you can turn it on per node or per content type and if you enable it per node you can go to the Layout Tab of the node and you're still loading to front end theme so you see your custom styles and everything like that but it puts some padding in there, some little dotted lines onto where you can drag stuff around and then there's a little button in there that says add block or add section and once you hit one of those buttons the settings tray pops out from the right hand side of your screen and at that point you'll have your various options.
- Mike Herchel
- You might have a list of pre-defined layout sections that you can insert that might be one column, two columns, three column or four column. You might have if you're adding a block you'll have a list of blocks. And the coolest thing I think from an editor's point of view is when their adding a block or when their adding a piece of content in there, they see that content immediately how it would look. And that's really cool because for example, if you're inserting content and you're selecting the view mode and they don't know what the view modes are which I could see being a pretty common thing they can at least go ahead and add it and maybe make an educated guess and see what it looks like and then if it looks great, you know it's going to look great as soon as they hit that save button. I think that's so awesome.
- Matt Kleve
- And the preview is pretty killer Mike. Not everybody reads floats and grids and sees it all in front of them. Seeing is believing. That's awesome.
- Mike Herchel
- Yeah.
- Tim Plunkett
- Yeah, honestly the tool has been built from the ground up with content editors, content authors, marketers, those end users of that part of the site as the focus. And it also is a killer site builders tool but it was aimed towards content authors in a way that the other tools are not. And the previous are a huge part of that.
- Mike Herchel
- Yeah. As we implemented Lullabot [inaudible 00:13:49] and I'm also working on a new project, a new client project and we're doing a very similar thing. We have a content type called Landing Page and it's basically, you know, a Layout Builder enabled page where marketing people or people who might not be as technical savvy as say a Web Developer but they can go in they have their pre-defined blocks that the can add their pre-defined content, they can stick it into their pre-defined layouts, they can move those layouts around and you know, the styling automatically inherits the correct amount of spacing, padding's, gutters and all that type of stuff and makes it very, very difficult for them to make something terribly ugly which I think everybody is loving that.
- Matt Kleve
- Mike as a friend how's the CSS?
- Mike Herchel
- I really like it because it kind of-
- Matt Kleve
- Does it look all right? Your proud of it if Layout Builder is what's on the page and you're the Front End Developer, your like, "This'll work".
- Mike Herchel
- Yeah, I mean, we've been defining our own layouts.
- Matt Kleve
- Fancy.
- Mike Herchel
- Yeah. So we've been defining our own layouts and in that point we've been doing that on the module side of things because of the way that Karen Stevenson has the layouts implemented on Lullubot.com and we're doing the same thing on this new clients site. We have drop down that reaches out to a [inaudible 00:15:21] vocabulary where you can select CSS classes that you have added in there and so I can add a layout section in there and then I can attach CSS classes to that and the CSS classes might say something like, send as a text or it might say, constrain by one grid or it might say apply a negative margin bottom or a margin bottom of four units and that makes it pretty easy for people who are composing the pages to work with it.
- Mike Herchel
- And there's also the ability to add a title into those and when you're adding the title you can select which element you want and it defaults to an H2 and there's CSS classes for that. And then from the styling point of view I typically override the library's just on the theme wire just so I can kind of manage everything within the [inaudible 00:16:24] base and just have a layout directory within my sass directory structure that does all the layout stuff and keeps it very componentized which when you're dealing with CSS you want a kind of componantize everything because CSS is global and you know, you can really shoot yourself in the foot if you don't do it properly and I'm sure everybody has done that, you know and-
- Matt Kleve
- Z makes one thousand.
- Mike Herchel
- Yeah, right. Z makes one thousand and import everything and you know-
- Matt Kleve
- And what it sounds like is that it's good to go out of the box but it can be as complex and as complicated as exciting as you need it to be.
- Mike Herchel
- It's very Drupal, in a good way though.
- Tim Plunkett
- Yeah, that didn't sound like a good way though.
- Mike Herchel
- Yeah, yeah, yeah.
- Tim Plunkett
- No one's ever said very Drupal.
- Mike Herchel
- Well, we should.
- Matt Kleve
- The first time right here on the Lullabot Podcast. 2019 episode 237, yeah.
- Mike Herchel
- We kind of went into the front end a little bit, maybe now is a good way to-
- Matt Kleve
- Well, we were kinda going into the latest version the-
- Mike Herchel
- Okay.
- Matt Kleve
- The dot eight. You had mentioned accessibility.
- Tim Plunkett
- Yeah.
- Matt Kleve
- That sounds like that might be challenging for such an interface. Can we talk a little bit about that Tim?
- Tim Plunkett
- Well it comes in accessibility kind of conveying the information of a spacial layout is extremely challenging and the reason any software that does that right now and there's no real mechanism for it either. Although there are new proposals at the CSS level to kind of have a way to convey spacial layouts, it's in the early draft state. So we were really kind of having to you know, blaze our own trail here and I mean the main thing is that accessibility there's no one answer, there's no way to know oh yeah, you're done now. You did the one thing, check off the checklist accessibility is finished. It's a process, it's a way of thinking and it has to be baked in at the lowest level.
- Tim Plunkett
- The easiest thing to point to is say, oh [inaudible 00:18:35] is it keyboard navigable in a way that even makes sense. Not only can you actually get through a [inaudible 00:18:41] to do the things but does the user understand what they are doing and what the effects of what they're doing has on the rest of the page. And we spent a lot of time on that via either these announce calls in [inaudible 00:18:54] to sort of convey to the user via speech when it's happening or just using Aria roles correctly to give them sort of these landmarks of this is where you are and this is what this means and additionally there's also in the case of navigability we rely on Drupal's table drag UI which is, you know, very prevalent through out Core.
- Mike Herchel
- Yeah.
- Tim Plunkett
- Whether it be menu's or tech savvy terms. If you're going to use a Drupal site as a site builder, you're going to have to figure out table drag whether you're using a pointer device or a keyboard. So we did rely on that sort of assumption of knowledge to allow us to provide that functionality for keyboard navigation, which really did obviously help but there's also still a lot more and the guidelines are very specific in what the intent is of each point but their not specific in terms of how to implement that for all the different possible input devices and output devices and so there's always more work to be done and what we did when scoping anything with Core we use a must have, should have, could have and would like to have system in terms of just to finding out priorities. In order to get anything in the Core there's a series of different topic gates that need to be satisfied. User ability, security, performance, accessibility and I think one about model API. And you have to satisfy all the must haves for that category in order for it to be included in the Core.
- Tim Plunkett
- So we did a 100 percent of all the must haves between the [inaudible 00:20:36] team and the accessibility team came up with. We also tackled a good chunk of the should haves and sort of the nice to haves and could haves. And so that's what remains going forward there's always more we can do but at least at the bare minimum we know we've covered what we have decided as a community are the absolute blockers.
- Mike Herchel
- Did you end up doing any type of user ability testing after or before? Was there any type of accessibility user testing or anything like that or?
- Tim Plunkett
- I haven't had anything holistic. We're looking into that but as far as we had multiple things we did some user abilities test, you know, actual sit downs and test for specific design choices. For example, there was due to technical limitations we had to hobble together a quick and easy way to print out where the save buttons are and describe the changes revert, those sort of actions. And we just kind of shoved them up to the top as Hackathon level, let's get this in. We knew it wasn't good, but we didn't necessarily know what to do from there. So Emilie who's you know, one of the co-initiative leads with me, came up with a couple different proposals and then sat down and did some full visibility studies on those different options and was able to determine what we will end up coming out with.
- Tim Plunkett
- But we haven't had anything at the holistic level yet and that is something I'd be interested in doing but you know, that's next.
- Mike Herchel
- And of course if somebody says there are issues-
- Tim Plunkett
- Oh for sure, I mean, there are-
- Mike Herchel
- File an issue, right?
- Tim Plunkett
- Yeah, please. I mean since it was announced and featured at Triple Con Seattle in the key note, there's been a lot of activity in the layouts Slack channel in the Triple Slack and there's dozens of people in there asking questions and there's even more people answering questions and you can pretty much either get acknowledged that what you're asking is a problem and we don't know the answer yet but here's where to follow a long for it or someone could point you to there's already a solution progress, sorry it's not fixed already but here's where it's happening.
- Tim Plunkett
- so there's a lot of momentum and enthusiasm and really interesting questions so much are resulting in new feature requests, some are resulting in spot off contribute modules to build out the Layout Builder ecosystem.
- Mike Herchel
- Yeah. That's awesome.
- Matt Kleve
- In the vein of what have you done for me lately, what are people chomping at the bit for? What do they want?
- Tim Plunkett
- I mean there's a good couple things. There's some specific things that themers want and with regards to more flexible templates suggestions so that they can really drill down and customize the markup for a specific component to sort of go with what Mike was saying earlier with the component based approaches, where you can either right now you can custom do it yourself but some little bit more flexibility out of the box has been one big request. There's a recent performance fix that we found that should be committed this week and would be back portable to 8.7 so the next version 8.7.2 or something would be in that release. The biggest I think feature request, well, there's two different hands, one is just pure feature request. People want visibility controls like they have in the blocks system where you can say this specific field, this specific block is only visible to people that have this role or viewing page in this language.
- Matt Kleve
- Almost text like.
- Tim Plunkett
- Exactly. That is forth coming, I mean there's people working on that issue. I would say the other one is that we shift without support for multi-lingual sites. Which is not to say that we can only do in English or anything because Drupal 8 can be installed in any language. So it's language eugnostic but it's right now it only works, you can't customize or translate the custom concept content [inaudible 00:24:38] through the Layout Builder and into other languages.
- Matt Kleve
- Okay, so the UI itself is multi-lingual but-
- Tim Plunkett
- Right.
- Matt Kleve
- But content, okay.
- Tim Plunkett
- No if you create regular node content and have all you're different fields displayed and you translate them in old fashion with content translation everything's going to be fine but there are a specific parts of the layopular AUI that allow you to enter texts, specifically labels for your blocks and if you chose to do that those labels are not currently translatable and so that is a known bug and we're working on fixing it. And there's four possible ways to fix it and we're picking to it, we're doing two of them and not the other two and the other two are going to be [inaudible 00:25:25]. I can include some links for those curious about it but you can do three more episodes just on the translation consequences of Layout Builder but this is something that's on the roadmap.
- Matt Kleve
- I'm wanting to ask questions about it but I think I'll just set it aside. It sounds like it's bigger than I'm assuming.
- Tim Plunkett
- There was a good two hour discussion about it at Seattle and was really, really informative and interesting and the notes from that are public so I can make sure there linked for those curious.
- Matt Kleve
- Yeah.
- Tim Plunkett
- But between Core and Contrib within the six months we're planning on supporting pretty much all these cases. It's just depending on which one you want in Core or not.
- Matt Kleve
- We're talking Layout Builder with Drupal 8, the latest greatest in 8.7 with Tim Plunkett from Acquia.
- Mike Herchel
- Yep and when we come back we're going to talk about what's next and any type of gotchas within Layout Builder.
- Matt Kleve
- Lullabot Podcast coming up right after this.
- Speaker 4
- Hey it's [Carl 00:26:20] one of the co-organizers of the first ever Fly over Camp. Tell us about the camp [Carl 00:26:23].
- Speaker 5
- Well it is on May 31st through June 2nd at the University of Missouri, Kansas City Campus. The first two days are going to be normal sessions with key notes and the last day is going to be a contribution session. The cost is $38 dollars and you can register at flyovercamp.org.
- Speaker 4
- Excellent, we'll see you there.
- Mike Herchel
- Welcome back we're talking with Tim Plunkett about Layout Builder and the awesomeness that is Drupal 8.7.
- Matt Kleve
- Yeah, hey Tim, so we talked about the early days of Layout Builder off the top and I was kind of wondering, my mind was wondering during that commercial break. Does Layout Builder as we know it today kind of have it's seed in the old Scotch Initiative?
- Tim Plunkett
- That's a good question. I would say no, I mean, it obviously for context the Scotch Initiative was intended a sort of modern replacement for the block module.
- Matt Kleve
- Yeah, it was kind of an awkward backarim because there was another initiative called Whiskey, so-
- Tim Plunkett
- Yes and if anyone can tell you what Scotch did then they're wrong because they don't remember.
- Matt Kleve
- Whiskey was web services and something and plugins and...but Scotch was kind of the promise of the new generation, right? The let's do panels and Core almost.
- Tim Plunkett
- Yeah, there was a Layout module actually committed to Core at one point and ended up being removed because it didn't do anything. In a way a lot of the foundation but in the end the actual part where we put the output code it just said at to figure this part out. And so-
- Mike Herchel
- That sounds like my code.
- Matt Kleve
- Some of that is timeline I'm sure, right?
- Tim Plunkett
- Absolutely. And it has to do with the Drupal 8.0 dub cycle was very unique in many ways and stretched on for a long period of time so there was no real known end point so there was no deadline to kind of give some scope to the whole initiative. It ended up being not succeeding in that sense but some of the improvements they made the plugin system and some of the context system within Core and some of the improvements of block module ended up being sort of foundational to the Layout Builder although I would say about at least a third of my time or more that I spent coding the Layout Builder was fixing bugs within the context system and the block system and the plugin system because they were improved in such a way in Triple 8.0 with this promise of more functionality but no one actually took advantage of it or exercised it in meaningful ways and so when I actually tried to put it to use it kind of fell over.
- Matt Kleve
- I'm sure building Layout Builder is an exercise for the system itself.
- Tim Plunkett
- Absolutely. [crosstalk 00:29:15].
- Tim Plunkett
- Exactly. And so the Scotch initiative itself had some really next generation of thoughts and approaches to how different customizations were related to their parents and there was this whole inheritance system and so we basically dug and it was all scrap when it was removed from Core. I definitely looked at it every once in awhile to make sure I wasn't repeating any old ground but we didn't really use any of the new ideas from it at all. And really as I said, they started with all these really next generation approaches and proposals and sort of foundational code but nothing actually functional whereas we started at every step of the way Layout Builder did something and it sort of a true iterated approach where you know the image where you start with a scooter and then you go to a bicycle and then you go to a motorcycle and then you get car as opposed to just having some axles and axles in a steering wheel and then you know, from there you build a car and no point till it's completely done is it functional.
- Tim Plunkett
- So we wanted to iterate due to the nature of Core development in order to land anything we had to have something functional. So honestly we did borrow a lot from Panelizer in terms of inspiration but with an eye at display suite, display is a really interesting module because it's really widely used but it does a lot of things and we enture to guess that most people that use it don't use it for the same reasons as the other people that use it and don't use a 100 percent of it's functionality.
- Matt Kleve
- I was trying to remember what it actually did. I've been on projects using display suite but we used a small portion of it's functionality, we used different display modes per content type or something to display suite-
- Tim Plunkett
- That was in Drupal 7. Display suite was the first one that sort of added this concept of different view modes and then you know, in Drupal 8 I helped move that into Core so that was the beginning of kind of chipping away at display suites feature set and moving parts of it in the Core but honestly the biggest thing I've heard is the reason that people installed display suite was because the title field was not manipulable in Field UI.
- Tim Plunkett
- There wasn't any other base field, it was only the configurative fields that you add through the Field UI where the ones available in that display. Some people installed this entire module that does dozens of things really well just for one small set of functionality and so it's sort of in discussion going back three years to Drupal Con New Orleans discussing with the display maintainers about what they saw as sort of the 80 percent users of their module and how to just kind of deprecate the whole module and make it obsolete in which it's basically happened now. And even just this morning there was a blog post published by previous [inaudible 00:32:16] explaining why they pivoted completely from using display suite on all their current site builds to where now everything new they build is going to be using Layout Builder.
- Mike Herchel
- That's awesome. We'll link that in our show notes.
- Tim Plunkett
- And honestly along those lines, I know we mentioned briefly earlier when I was coming the initiative there's a field layout module. The field layout module was very much trying to be display suite in Core and that was the experiment but it ended up as I said, not being ambitious enough, to little for too much pain. And so I declared it as kind of a failed experiment and it's still hanging around in Core and we have to figure out the best way to kind of get rid of it in sustainable way to not ruin the lives of the people who try to adopt it. But switching to something more that supplied Panelizer but in Core it turned out to be the more ambitious and successful approach.
- Matt Kleve
- I do remember when you were last on Tim and you were describing the Field Layout Module, I was like, "Oh, well is it gonna do this, this, that or the other thing"? Essentially, explaining Layout Builder was my assumption based on it's cool name, Field Layout, right? It's going to do that and you're like, "Yeah, sadly no it doesn't do that so-". Well, okay, so any ideas what's going to happen in the future?
- Tim Plunkett
- Yes, so the interesting thing about Field Layout is that while Layout Builder is all about controlling the output of your content. Field Layout both attempted it to improve that work flow but also allowed you to alter the display of the form itself where you enter the content. Which is really powerful and really kind of nice especially for, as an agency like yourself, you're going to try and build out the best work flow for your client as possible.
- Matt Kleve
- Well it's already editable like Dragon Drop wise, right? Now the form and the display-
- Tim Plunkett
- You can re-arrange the order the widgets are displayed but saying the same way that you could do that with Field UI for your output but you couldn't kind of re-arrange or split it into columns or split it into a wider footer or any of those things. And so that sort of functionality is really going to be the casualty, that's what the part we have to focus on because there's a clean update path from migration path from Field Layout to Layout Builder to those using the output capabilities. But for those that have been using it to control the output of their forms, we don't have anything to do with that right now. It's still just an alter of the Field UI code, it's to just kind of roll that foreign part directly into Field UI itself and just make it instead of enhancement of Field UI just make Field UI do that thing.
- Tim Plunkett
- And so then just pretend the Field UI module never existed. Which is good because you know, I have a lot of thoughts about the experimental module process. Yeah, but I think that one of the biggest things that we're allowed to fail. And failing in public is really hard and kind of uncomfortable but I think it's really great and it's a good example of how to do that responsibly.
- Mike Herchel
- Yeah and I don't think there's any shame in failing.
- Tim Plunkett
- No absolutely not. I mean, the only shame is if you try and cover it up or pretend it never happened or you learn nothing from it and you repeat your mistakes but failing in public can be, especially in an open source community, it shows people that look, you can take a chance and go for something and it might be the next big thing or it may not and there's no harm no foul.
- Mike Herchel
- So let's maybe move on to some Layout Builder gadgets and maybe non-use cases. If you're creating site in Layout Builder what are some maybe things to avoid or maybe used cases where not to use Layout Builder. If you don't have any thoughts on this-
- Tim Plunkett
- Yeah, no I can. I would say there are limitations to it's functionality that may or may not be clear at first. Some of them are enhanced by contrib's, some of them are on the roadmap to become something contrib but for example you know, the Layout itself is focused on the output of the editing and the Fields itself and as such if you're a triple site builder you know what the main content region of your page is. Everything that Layout Builder does it lives within that main content region. All of the other things like your headers and your footers and if you have them your side bars are still controlled by the block UI and your page templates and that can be sort of frustrating and you come in and you have this really great tool that's really great for your content and you want to use it for other parts of your page and you can't you're stuck with the old block UI.
- Tim Plunkett
- And that is something that is looking to be addressed by contrib in a couple different forms, some people will want to have a completely brand new solution that our other people working on improving the page manager module which is [inaudible 00:37:23] to sort of use that Layout UI itself to show you how to edit the parts around the main content. Sort of site chrome if you will. So without that module done, or without anyone of those efforts completed it can be kind of jarring like, "Wait, why is this powerful tool limited to this middle part and why can't I use it in other places"?
- Matt Kleve
- Remind me which one page manager is.
- Tim Plunkett
- Page manager is what people might think panels is.
- Matt Kleve
- Oh okay, so page manager is the requirement for panels? And it-
- Matt Kleve
- [crosstalk 00:38:00]
- Matt Kleve
- Panels requires page managers, right?
- Tim Plunkett
- No, that was in 8.7.
- Matt Kleve
- Oh yeah, yeah that's what I'm talking about.
- Tim Plunkett
- So in D8 they switched it so panels is just this shared DUI module on top of panel, it's used by Panelizer and page manager. And yes, all of those words are confusing and make no sense, especially with D8 but-
- Mike Herchel
- I want going to say anything but-
- Matt Kleve
- Just like Drupal.
- Tim Plunkett
- Panelizer has been largely supplied by Uploader but the concept of doing and so that another node is that if you are doing a specific node, let's say you're on node slash five and it's you and your events and you want to customize the [inaudible 00:38:42] events and customize it just the way you want. That is stored as content, that is a field, it is revision able, it will eventually be translatable it can go through work flows like moderation work flows and it's pure content and can be deployed. Page manager is [inaudible 00:39:02] you go in and you say, "I want a slash about to a new route on my site" and when you go to that you see this landing page and it has nothing to do with any particular content it's just you can pull in content from somewhere else but it is a configuration thing and that can be put in version control and ployed [inaudible 00:39:21] what have you.
- Tim Plunkett
- And it's not content, it's not revision able. So that config part is still in [inaudible 00:39:28] and looks like it will be that way for the foreseeable future, there's not enough, if though it's a very powerful tool, there's not enough demand that'll land at in court self anytime soon.
- Mike Herchel
- So I have a question for you. Do you know anything that would help me with this case where, if for example, a field exists then display another field or say ad, I know know, a CSS class or something to something. These cases I'm thinking of is say, I'm deciding my layouts and I'm hard coding them directly in my tweaked input so out of time so you know, I'll have a little twig stem that says, "If this exists then you know, place this one right here and if it doesn't exist I'm going to place this other field down here". Is there anything-
- Matt Kleve
- If there's a picture have a caption or something like that? I'm trying to-
- Tim Plunkett
- Yeah-
- Matt Kleve
- Make it more tangible for you Mike.
- Mike Herchel
- So the exact case I'm thinking about is actually on the episode nodes that this-
- Matt Kleve
- Lullabot.com/podcast, okay yeah-
- Mike Herchel
- Yeah, like that. There's a little rule within the twig templates that says, If we add the links, we do one thing where we move a block around and then if we don't add the links, then we add a CSS class and move another block around, and we do that just so we have this big expanding collapsing transcript thing and then we also have something, we typically don't post a transcripts until a day or so after the node is published. So-
- Matt Kleve
- That's my fault.
- Mike Herchel
- Yeah, it totally is. So it doesn't show the link to the transcript until the transcript content exists. Is there anything in Layout Builder contrib or possibly going into Core that can handle a situation similar to that?
- Tim Plunkett
- Well, so it really depends. Honestly, the short answer's no, not that I know of. But the longer answer is it really depends on what you're talking about because if you're thinking of everything as separate components, in theory those components shouldn't know anything about each other-
- Mike Herchel
- Yeah.
- Tim Plunkett
- But if you're talking about things like sub components and sort of create a larger thing. There are some reference around sort of a multi-field module being worked on by President [inaudible 00:41:57] of previous nets and a [inaudible 00:42:00] of Lullabot are working on sort of a multi-field module and that will allow through the use of custom field formatter's and what not, it will allow you to sort of change and alter the granulite in the printing of one field based on the other. The [inaudible 00:42:19] out here is none of that has nothing to do with Layout Builder.
- Tim Plunkett
- Layout Builder will print out blocks. That may sound limiting to those that are used to blocks before Layout Builder. All the blocks that live in Core and most of the blocks you see their out by your contrib site modules are just there. They print the thing and that's it. Since 8.0 there has been the ability for a block to sort of receive information from outside or request that information and do things based on the examples, field block so, field block knows what field it is but it needs an iminity to print the field out of. So that sort of what we call contextually aware block. It lives in Core now and you have always been able to write context aware blocks but not there's actually a system that uses them and [inaudible 00:43:13] them correctly.
- Tim Plunkett
- So you can write a lot more complex stuff now but at the end of the day you're just writing blocks or field formatter's or what have you, that aren't Layout Builder specific.
- Mike Herchel
- Got you, that makes sense. Did we talk about what's next for Layout Builder? What are you concentrating on right now and what's immediately coming in and is there anything that's planned for Drupal 8.8 or anything like that?
- Tim Plunkett
- So there are, I mean, there's a couple hundred issues in the issue queue of things that can be worked on or are being worked on. There's you know, dozens of bug fixes and future requests and just clean up tasks in progress. And with the way that Drupal Core works is there's no guarantee that any of it's going to land for 8.8 but there's also nothing stopping anything from landing in 8.8. 8.8 was going to go out and the day that it goes out and whatever is in goes with it. That said, within my team at Acquia, we have a list of things we are focused on.
- Mike Herchel
- Yeah.
- Tim Plunkett
- And as I mentioned before, one of the biggest one is translations, allowing sort of you to translate the customizations you've made within Layout Builder and so whatever language you're displaying it in, that is very much targeted for 8.8 by our team but that's not a promise to anything, there's no guarantees that anything is going to happen. Layout Builder is stable now so there's no more strings attached you know, it's just everything else is just improvement from here on out. So yeah, but that means in translations is the main one as I mentioned before also, the visibility controls but everything else is just kind of whatever. Anyone is empowered to work on and there are multiple people that just jump in the issues, saying you know, I need this for my use case and then there are people, myself included, who can help guide them to either making the changes themselves or describing their use case better so that other people can do it for them or they test the changes after we work on them to make sure that they work.
- Tim Plunkett
- So in that sense the web map is actually kind of very open and democratic at this point where anyone can kind of influence what happens.
- Mike Herchel
- So it's the open source way, right?
- Tim Plunkett
- Absolutely. It's definitely how I think it should be done. Honestly how it works maybe let's say last summer after Beta before we had this kind of focused burned out to release where we just stopped working on all new fun things and only worked on the things we knew we had to do. So getting back to that sort of what do people need and what is important to them and how can we make Layout Builder better in Core, is great. And also supporting the contrib modules that have started cropping up, which is something I did want to talk about, there's a link in the nodes but there's a good list already on the documentation of existing contrib modules but there are a couple I want to call out. Specifically, Layout Builder restrictions module.
- Tim Plunkett
- One of the things I was just at the Drupal Delphia, the local Philadelphia Triple Camp a week ago and it's been a couple weeks by now but the one thing that people noted was that Layout Builder was almost to powerful and let people do to many things. And they were realizing their going to spend more time pairing back and locking down and sort of restricting parts of Layout Builder in this case than it would be for them to have to write new code to expand or extend the functionality. And Layout Builder restrictions is a great example of that where it allows you to restrict which blocks and layouts are available within Layout Builder and really can help you clean out the interface if you don't want people to be able to replace all fields for example.
- Tim Plunkett
- And the difference, there's actually another module which I think Lullabot called Block Blacklist, that ones a little bit more absolute in the fact that it prevents anyone from doing it anywhere and just completely removes that block from existence which can help with performance but doesn't let you ever place it and can actually break your site if you start removing things that you've actually placed in other places, where Layout Builder restrictions is only about restricting the list of options available to you.
- Matt Kleve
- Yeah, Lullabot CTO, Karen Stevenson talked about that on the podcast a few episodes ago. And that was more a UX improvement I think. I think there's some performances as well but there's a bunch of stuff you can chose from and we don't want to chose any of this stuff so we're just going to hide that.
- Tim Plunkett
- And that's what Layout Builder restrictions is also, from the UX sort of things, is intended for and they were written at the same time. But I think now sort of the best practices are settling on Layout Builder restrictions for UX and Block Blacklist for performance. And you can use both you know, but you should be very careful about which one you pick and why.
- Mike Herchel
- Gotcha. Are there any other contrib modules that you want to highlight?
- Tim Plunkett
- There is an interesting one called layout Library, which if you used Panelizer and you used the functionality referred to as multiple defaults, that's where that lives now. It's basically the pre-configured sets of layouts with their fields placed within them. So you can come up with let's say five different variations and some have the [inaudible 00:48:39] image and some have where it's just the big headline and no images at all and you build up a couple of those and then on the actual note to edit form it allows the author to pick from that list and have that sort of let them be the limit of their customization. And that's just another example-
- Mike Herchel
- That's nice.
- Tim Plunkett
- Pairing back the functionality instead of letting them just go completely into the blue with moving anywhere they want, you can give them a pre-set west. So that's Layout Builder Library.
- Mike Herchel
- Yeah. Yeah. That sounds awesome. I'm going to need to investigate both of those modules for my project I'm on. That's exciting.
- Tim Plunkett
- Yeah. And there's a good list like I said in the documentation note it kind of kept up to date with what are the best practices and what are the things that are available? Another one on that list, this is kind of a Segway, is there's a module on that page called paragraph blocks.
- Mike Herchel
- [crosstalk 00:49:36]
- Tim Plunkett
- Paragraph blocks is intended to let you place your individual paragraph items anywhere you want on the page. Which kind of to me, fulfills the promise of paragraphs module itself. Paragraphs as sort of editorial tool allows you to just pick any sort from a pre-determined list a bunch of different input types and just have all this different content in a semi-loosely, unstructured way but in the past you had to rely on either abusing paragraphs itself to create nested paragraphs that determined the placement and layout or just some really [inaudible 00:50:13] hard coded templates. So with paragraphs and paragraph blocks in Layout Builder you can keep the flexibility of the editorial control of paragraphs without having to use or shoe on the module into anything more than it is and on Layout Builder to control the output and placement of it.
- Mike Herchel
- Yeah, that's awesome. So I have a question here added to our show notes from one of my coworkers, Matt Oliveira and he talks a little bit about paragraphs and so the question is, there's been some rumblings about paragraphs being the wrong approach for reasons of entity references used in a couple presentations from [inaudible 00:50:54] and [inaudible 00:50:55] Wolf. How can Layout Builder play some of these concerns, in other words, what's the underlining storage mechanisms that Layout Builder uses and does Layout Builder store as entities?
- Tim Plunkett
- Right. So, I have seen at least one or two of those presentations and the paragraphs that the date module issues that largely come into play when you are using revisions and depending on your configuration, yeah, you can really quickly scale yourself into millions of rows. I think that Layout Builder only really maybe decreases it by an order of magnitude but doesn't necessarily solve the problem outright because Layout Builder still allows you to have revisions and just from the mental definition of how revisions need to work and that there's always that story canonical reference or version of that data that you could always get back to it anytime. That can create scaling issues, that said, there are a lot less entity references by the way it uses blocks unless you are creating content on the fly throughout the Layout Builder UI you're just going to be placing other blocks and that's really a small couple lines of config when it's exported the [inaudible 00:52:15] that really doesn't have the same sort of scaling problem.
- Tim Plunkett
- That said, I'm really hesitant to make any sort of promises around that. Every tool can be misused to the point of horrible performance. And it doesn't necessarily, as I said, you can still use them together even but it shouldn't be as sort of exaggerated as a problem. Honestly, there's still just a lot of work that needs to be done around new references and revisions. [inaudible 00:52:51] revisions module but still there's not really sort of a community consensus on that and how to solve those in a general way whereas now you just have to kind of evaluate and know what your scale set you're building is and see what restrictions you have to make based on that.
- Tim Plunkett
- So to address the second half of that question which is what is the underlining storage mechanism? When you're controlling the layout of let's say, all articles or all event types you know, all event notes. That is through the [inaudible 00:53:24] display page right around where you usually find the Field UI. All that stored in config. It can be exported to version control and that's all it is. The same exact data models also reuse when you're doing overrides but that data is stored as a field on the entity itself. So if you go in and you change your node title around and you see you have revisions on it's going to create a revision and it's going to have that new node title. And then you go and change your layouts and you have revisions on it's going to go and change the ordering within that one layout field.
- Tim Plunkett
- And those are to stay in the same revisions table. Stored the same way. So if you want to revert one you can revert the other. You know, it's just using the Field UI or, sorry, Field API and getting all that translation and the support for translation and the moderation and work flows and revisions all for free from Field API.
- Mike Herchel
- So a follow up question to that, so if I'm using the Layout Builder to create content you know, say if I'm adding you know, one time use blocks directly into the settings tray UI, and I have revisions turned on. Is that a potential issue down the road?
- Tim Plunkett
- If you're using inline blocks sort of non-reusable [inaudible 00:54:44] blocks in Layout Builder you're hitting the same exact problem with paragraphs has. That said there is one key difference and that we have a separate usage table that tracks every time each of those inline blocks or any of the blocks are used and if the usage drops to zero they'll eventually deleted. Now that actually doesn't actually work when you have revisions because their still in there forever. So that doesn't really help in the revisions case so but that's sort of not paragraphs fault, really. It's sort of just if you want to build your site that way and use revisions, you're going to have that problem and it's up to you to figure out how to litigate that scaling issues.
- Mike Herchel
- Yeah, that makes sense.
- Matt Kleve
- How did you find yourself at the helm of this initiative?
- Tim Plunkett
- that's a really good question.
- Matt Kleve
- Is this something you were excited about before? Is this something that you know, you saw a place to jump in and really make a splash for Drupal or-
- Tim Plunkett
- So you know, I mean, I found myself working in Drupal Core largely through the original revising Core initiative back in 2012 during the early Drupal 8 cycle and that was sort of my intro and dry run and being thrown head first in the pool of how Core works and from there I ended up doing the Triple 8 death cycle, worked on a bunch of things like Form API and routing system, the age access to the block system and then continue working on these or what not. And then when it came time Triple 8 was actually released you know, I like many other Core [inaudible 00:56:23] were really super burned out. And I kind of did take a breather and worked with the Module Acceleration Program which is a thing that Acquia had set up-
- Tim Plunkett
- [crosstalk 00:56:35]
- Tim Plunkett
- Yeah, to accelerate the porting of Drupal modules to Drupal 8 to sort of make cycling fees able again. So I've worked a bunch on porting different modules and it's sort of forward into the page manager panels sphere on that behalf but there was one specific conversation I had which was with a friend of mine who doesn't do Drupal professionally but he actually sort of sat along, got me into Drupal but he has a Drupal site that he uses to run for his non-profit and he was building Drupal 8 and he was like, "You know, I got all my data models all set up and I even started writing a custom theme and ever things all on the page but there's nothing I can figure out to move fields around and change how I want something on the right, I want something on the left. There's no mechanism in it and I can do all this other powerful stuff but where is that functionality"?
- Tim Plunkett
- And that's my friend Steve and I excited Steve and Steve's needs in this case they helped form a foundation of our original user stories.
- Mike Herchel
- Thanks Steve.
- Tim Plunkett
- Steve and his kickball site, his charity kickball site, need a tool in Drupal Core that anyone can use to sort of re-arrange their content as needed. And so you know, just at dinner one time, three or four years ago we had this conversation and that sort of lit a fire under me and said, yeah, this is something that was attentive with the Scotch initiative but that was sort of developer focused and sort of just a we can approve on the thing we have but I really wanted to build something for the end user or the content author. The person who just really wanted their site to look a certain way and didn't necessarily worry about site building, the upscale for large agencies or anything just something in the hands of a normal content author marketer. And so that's really how I got passionate about it and then as I mentioned, Emilie Nouveau is the lead. She had been working with the DA and also been working on Panelizer and what not. I think also had a similar sort of drive to make it less developer and site builder focused and together this is you know, this is what we came up with.
- Mike Herchel
- Well thanks. Thanks Steve.
- Matt Kleve
- Thanks kickball.
- Mike Herchel
- Yeah, thanks kickball.
- Matt Kleve
- That's a really cool story Tim and Drupal's better because of it. Thank you.
- Tim Plunkett
- Thank you and I mean, there's dozens and dozens of people we can link to my session from DrupalCon Seattle and I do go out of my way to thank a bunch of people cause you know, I mean, other than the other developers within Acquia and the Core committers, especially [inaudible 00:59:24] and [inaudible 00:59:26] you know, there's just dozens and dozens of people that made huge, huge contributions to this. It wouldn't be anything close without them.
- Mike Herchel
- Anything else that you want to talk about or anything that you're super excited about before we wrap up?
- Tim Plunkett
- No not really I honestly just keeping the enthusiasm high in the community and making sure everyone knows that if it doesn't work the way you want it to it might not be your fault, there may be a bug and their are people who will help you either identify that or help fix it or will let you know when it's fixed and for anyone interested to try and get involved at any level of that.
- Mike Herchel
- And that's in the Drupal Slack?
- Tim Plunkett
- In the Drupal Slack in the Layout's Channel-
- Mike Herchel
- In the Layout's Channel, yeah. [inaudible 01:00:15] layouts.
- Tim Plunkett
- Yep.
- Mike Herchel
- Cool. Well, thanks for coming on.
- Tim Plunkett
- Thanks so much for having me.
- Mike Herchel
- Thanks Tim.