 G'day everyone. How's it going? It's 10.45, so I think it's a good time to start. Thanks a lot for coming along to seeing building banging websites with bricks, paragraphs and modifiers. Before I get into the presentation, I'd like to ask you all two questions and the first one is of all the time you spend on building a website, how much of that time is actually spent on solving customer needs? How much time are you spending on thinking about what your customer requires and actually implementing that versus the time you're spending rummaging around in the plumbing of Drupal? And this is a question we'll come back to to look at later in the presentation. The second one is once you've developed your website, how responsive is that going to be for future needs? When you've built that site, are you just crystallizing a design that's been developed at the start? Or have you built something, a toolkit that is going to serve the needs of the editors and the end users of your website? Hello and welcome. My name is Murray Woodman, and I'm a director at Morft, we're a Drupal agency based in Sydney, Australia. I work with this team of Murray developers and we've been working on a module called the Modifiers module over the last year or so. And we'll be going along and having a look at that in detail later in the presentation. But we'll also be looking at the paragraphs module and the bricks module and we'll be able to see how these three modules are able to come together to form a nice little ecosystem for site building. As we've been developing the Modifiers module, we really have been thinking of those two questions. How can we build sites more quickly? How can we build them more effectively, consistently and basically be delivering them on time and giving editors the flexibility they need to build the sites that will serve their customers' needs? I'm going to be considering three different kinds of personas in this talk. The first one, of course, is the visitors to your website, the end users. They want to be consuming attractive, information-rich pages, which communicate clearly. And of course, on the other side of that equation, you have the editors and the marketers, the people who want to be able to author attractive, persuasive pages for the visitors. And in this particular case, we're really focusing on component-driven design and how those components can be used to build those sites. And finally, we're going to concentrate on site builders. And I count myself as a site builder, as I'm sure many of you do. And what we really want to do here is leverage the best that Drupal has to offer. And by that, I mean combining entities, view modes, layouts and modifiers, and bringing them together in a coherent system so that we can serve the needs of editors. Before we go in and have a look at these three modules working in Unison, I'd like to sort of take a little sort of walk through Drupal history and the different ways that we sort of build websites and different paradigms we have when it comes to layouts and placement of items on the page. The first one is your typical theme, where we have theme regions, and these regions are baked into the theme. And basically, you know, the design is done by placing blocks on the page with visibility rules. This is probably the way we all started building Drupal websites. It's probably the simplest and the most effective way of doing things. The one downside of it, though, is that these layouts are baked in at the start, and it's very difficult to change those if the needs of the site changes. There is a particular theme that I've got a soft spot for, and it's the Omega 3 theme back in Drupal 7 days. I'm sure, you know, quite a many of us, you know, feel similarly about it. This thing came about when responsive design was first becoming popular, and it was able to sort of combine grids and responsive in quite an effective way. But one of the very interesting things about this theme was that it had the concept of zones, and these zones were able to build out different sort of layers of grids effectively. And this sort of brought a lot of flexibility to the site builder. No longer were you just constrained to having these fixed regions, Omega 3 was really trying to help you chunk the page out. And this approach, we can see that appearing now with the layout builder, and we can also see in the BRICS module as well. So it's interesting to see that concept, you know, was sort of formulated a while back, and now it's becoming more popular. Of course, we had, you know, the paneliser and layout plug-ins, you know, around this time as well. And, you know, paneliser, well, the layout plug-ins were amazing, you know, they allowed us to have a wide variety of layouts that we can swap in and out. And it really gave the site builder and theme, you know, a lot of options at their fingertips. We had all kinds of, you know, different designs with all these amazing sort of BRICS layouts, and, you know, there was really a lot of options there. But once again, these layouts were fixed at design time. You could swap them in and out, but, you know, you were not able to change them as the site required. A few years ago, the Paragraphs module really started to come to the fore, you know, it's been a massive influence on site builders, I'm sure, it's, you know, part of your tool kit, and, you know, it's an incredibly popular module these days. Paragraphs, of course, are not concerned with layouts, it was concerned with, you know, defining components and encapsulating those components so that they could be served the needs of editors. There was a whole bunch of, there was a massive sort of, sort of community that grew up around paragraphs and, you know, lots of different techniques were experimented with. One of them, I call edgy paragraphs, but these are basically these edge-to-edge designs that you could get with paragraphs. Basically, you could remove the container from the paragraph and pop it out to the edge, and that way, you know, the paragraph is taking the full width of the page. And, of course, this opened up a whole lot of, you know, design possibilities because themas could now target and get those really sort of nice, sort of rich pages that we expect. The classing paragraphs module also came out a few years ago, and this really augmented that, sort of, edgy design, you know, you're able to, editors were able to put a class onto an individual paragraph and change the way it looked. You could change the colors, the typography, the padding, the look and feel, really anything you liked, and it was that one single class being wired into the paragraph that made that possible. So in this little present, you know, example here, oh, my goodness, that is just terrible contrast. Oh, my goodness, I'm going to, I'm sorry about that. But yeah, in the, with these, with the classing paragraph, you put a class on the div and basically affect the way it looked. The, and this is really bumming me out about the, my contrast there, it's a little bit bright. With the, with the Bricks module, what you have now is the, and we will see this in more detail and better contrast later, you have the ability to combine layouts and entities onto one page and basically bring these designs to the fore, these layer cake designs going down. So we're able to combine the components that we love with paragraphs with the layouts and the Bricks module is able to bring all of those together and we'll be seeing how that works later in the presentation. And finally, we have the modifiers module, which basically allows presentation look and feel to be mapped down into an individual entity. So we're able to use the paragraphs module to provide the components and the modifiers module can come in and basically change different presentational aspects of that. So for example, you could have background images, background videos, different JavaScript effects, different CSS effects. So it's basically a way of injecting the richness of the Drupal theming layer onto an entity in a way that's easy for editors to access. Okay, so let's, let's go through and have a look at each of these components in order. Firstly, the paragraphs module. You know, the success of the paragraphs module really comes down to its flexibility and just taking this quote from the project page, it says, so what's it going to be? Think big. And the paragraphs module has opened up a whole new world for site builders being able to design components to, you know, for editors to be able to use and really that is the success of it. But the other important thing about paragraphs is that they're scoped to the node that they're on. When an editor is going in and editing a particular node, they have the paragraphs there and they're operating within the context of that piece of content. On the other hand, other systems such as the layout builder and panels IPE, they're really sort of looking using blocks, custom blocks, you know, which have a global scope. So if you imagine a whole stack of custom blocks, they are living in your sort of blocks library there and you may have hundreds of these on a website. It's actually quite difficult for an editor to understand what all the blocks are, have to retrieve them and find them and place them on the page. You know, about a year ago we went down the path of switching over to IPE and trying to get that to work in Drupal 8, but, you know, frankly, the editor experience was not so good because it's just hard to manage that many blocks. And so we've switched back to paragraphs now as a way for, you know, editing and maintaining the content on a page. So that's why I think, you know, paragraphs are a natural fit, definitely for managing your components. This is an example, and thankfully you can almost see that. This is an example of a page with some paragraphs on it, okay? So we've got some tabs there. We've got some, you know, circle progress sort of indicators. We've got a little gallery and we've also got a high charts graph, okay? So this is demonstrating the componentized nature of paragraphs. We are using kind of like a traditional sort of layout paradigm here. In this case, this is paneliser with a sidebar. And we've had to do a little bit of a hack by just saying, hey, here are some sidebar paragraphs, please put them in. So we can see that we're kind of getting some layouts and some components working together here, but it's still in this fixed approach. And basically we're going to take this example and then go on and see how we can extend this with bricks and modifiers. So let's have a look at the bricks module and see how that can work with paragraphs. Now, the bricks module sounds like a scary thing. It sounds like a whole new concept. It even may sound like a competitor to other entities such as paragraphs. But really that is the wrong way to think about it. The bricks module is a perfect accompaniment to paragraphs. It works in unison with it and basically brings layouts and view modes in with the power of paragraphs and brings them all together. So at the heart of the bricks module, we're really just talking about a field, the bricks field. And that bricks field is just a list of entity references. It's just a very simple relationship in an ordered list heading off to other entities. But in this case, there is a couple of bits of magic. One of the bits of magic is the layout. So you can see there in the horizontal box there that we're able to select a layout from a list of layout plugins. So this layout is actually a paragraph with a bundle called layout. And that bit of magic says to bricks, hey, go into the layout plugins, load them up and let the user select one of them. So here we have the layout plugins being loaded up as a piece of content as a paragraph. Secondly, on the left-hand side, you can see this drag and drop interface where you're able to move different paragraphs around in a nice sort of compact UI. You can also see that it's nested. So in the case of that layout, that's sort of a position one. And then we've got two items underneath it, the images and another layout there. So that's how this is being put together. And finally, down the bottom, we have, I've just circled the defaults. That's basically showing a view mode. So in this case, we're showing the default view mode of that particular paragraph. So what we have here is basically what I call bringing the best of Drupal together. We have the components, we have the layouts and we have the view modes and we've brought them all together in a compact interface. Now you can do this kind of thing with paragraphs and nested paragraphs today, but the UI is not so great. It's quite expansive and it's hard for editors to get their head around it. So what we can see here is the UI being much more compact and basically making it easier for people to manage these relationships. So here we are back at our example. We've just sort of changed the layouts a little bit. It's nothing too fancy, but hopefully you'll get the idea. Down the bottom here, you can see we've got a 50-50 layout that we've used and we've dragged those two components in underneath it. We have our circle progress indicators in a sort of like a four column thing and up here at the top we've got the high charts and the content in an 8-4. So we've built this page out using three different layouts, one, two, three, and we've dropped the different paragraphs in. Now if you were going to do this with pure paragraphs, it would actually be quite difficult. One of the approaches I've seen people do is they make these kind of Frankenstein paragraphs where you might say let's have a high charts content sort of arrangement where you're actually building the layout in. But the problem there is you've got one paragraph doing two things and it's not really sort of factored out in a very nice way. Here when we've got the layouts that are sort of outside, we're able to have much more control about how we place those paragraphs into the layout. And finally here we've just expanded out those circle paragraph ones out to the edge by sort of busting them out of their container. So you can see we've got quite a lot of flexibility here in how we lay the page out. Let's go in and have a look at the editing interface. I'll talk quickly, but here we have the bricks field and you can see we've got the layouts here. So in this case it's a two column 8-4 layout up the top. And we're also just going to have a quick look at the view modes. Here's a bunch of standard view modes that we support on our site. I'm now moving items up for the top and bottom there and we're clicking save. And so when we come back we can see that the high charts has flicked over to the right-hand side and we've also reversed the order of those two down the bottom. So that's really the guts of the bricks interface there. It allows it sort of easy dragging and dropping of components inside the different layouts and also selecting the view mode as well. You can also see there in the interface it's got a little spot for CSS classes too. That can be quite handy for just dropping classes onto those individual components. So in a sense that's like a poor man's version of classy paragraphs if you will. The interface is not as polished but it still sort of achieves the same thing. The Bricks module is currently under quite a lot of development and new features have been added regularly. You've seen the support we have there for paragraphs now natively, but Bricks is also supporting dynamic entity references. And this is really cool. When I first heard about the Dynamic Entity Reference module I thought awesome. This is a module that solves a problem in Drupal. And for me one of the problems in Drupal is there's a very strong concept of entity types and entity IDs going around as a pair. So if you look at the API you often see those sort of going around as a pair. And it makes it quite difficult to combine different entities from different entity types. And the Dynamic Entity Reference module overcomes that problem by extending it and allowing lists of entities from various types. So for example you could have a list with nodes and users and taxonomy terms all in one list. Now this has been a slow burner of a module and I think it's awesome to see that this is now being adopted in Bricks. So if you come through and have a look at this page it's pretty hard to see. But on this one here we have paragraph being shown and we've also got the admin user being shown here. So this is quite experimental. It's new in the Dev branch and it's only been there a couple of weeks. But we can see here that we're actually mixing in users and paragraphs in the same layout. And the thing that brings it all together is the view modes as well. So now that you've seen this you can start conceiving systems of having view modes that are consistent not just within the node but also across your other content types. So you could have a teaser view mode for a user and a teaser view mode for a node. And you could put them, arrange them in this way and you're going to have a consistent interface. So I think that's a really exciting thing that we're breaking down some of the barriers there and making this system more flexible. Okay moving on to modifiers. So as I said modifiers project is one I've been working on with the team for the last year. We've really been driven by a desire to encapsulate the cool stuff in the Drupal theme layer and make that available to editors in an easy way. So we're not trying to put sort of themers out of a job but we really don't think you should be spending time in the theming layer constantly reinventing the wheel. What we want to do is wrap that up into a little component and allow you to apply that in to entities as you like. So let's just jump straight into it. Here we have the demo. We can see that we've now got a blue background and white writing on that div and we've just got a parallax image down the bottom there. So a fairly sort of simple example but we're just showing that we can take that page, this little demo page and then sort of trick it out with some presentational aspects. So this one up there, no change. Here we've got the background color and foreground colors being changed and here we have parallax image being applied. So you can see that we're basically building things up, components, bricks and modifiers and they're all building up to work together. Jumping into the editing interface now, we're going to scroll down, so we've got the bricks that we know and love. We're going to edit a section here and we're going to come down and we can see on this section this is the one with the parallax image. So we're just going to remove that old image, come along and select a new picture of clouds. So we didn't like those old clouds. Let's put some new ones in and we've basically changed that modifier and now we're going to click save. And we can see we'll come back and the display has been updated with the new picture of clouds, which of course you can't see but I'm sorry about that guys. The monitor is too bright. So anyway, at least it's accessible, right? We've got nice sort of contrast going on there. Yeah, so basically the modifiers are being applied as a field onto those different entities and then altering it. So how do modifiers work? So now's as good a time as any to explain it, right? And oftentimes people do ask me just what is the magic behind them. When we were designing modifiers, initially we did design them so that they were very closely coupled in with entities. But then we took a step back and said no, that's sort of tying it in too tightly. Let's tie it into a selector. So with a selector, you can theoretically target any div on a page or anywhere where you can select that particular HTML element. And this at its heart means that modifiers theoretically could be applied to the header or the footer or the teaser items or whatever. But in this particular demo today, I'm showing you how it applies to entities specifically. So a little bit of code. The magic happens in Hawk entity view, Walter. And this hook is fired when an entity is being displayed with a view mode, which is the dollar display there. And what happens is this build array gets updated with CSS and JavaScript and different attributes. So the name of the game here is for us to update that build array with data that is present in the modifiers. So this is some cut down code and I'll just quickly go through so you understand what's happening. First off, we get the entity ID and that is basically the ID of the paragraph. And then we'll just make up a little class for that modifiers ID and then the ID name. So this is the handle that we have now for this particular element. And we will place this ID on the element so that we can then address it via the JavaScript and CSS. We load up a modifiers service and that service will take the modifiers field and basically make a whole stack of little configs. So for each modifier we've applied, we'll get a little nice beautiful little associative array of configuration. We give other modules a chance to alter that, like an altar hook there. So other modules can come in and change that array if they like. And then finally we come down and we actually apply those modifications. So what happens is the modifiers object here is processing those modifications and coming up with a whole stack of modifier objects. And then those modifier objects are applied through to the particular build array. So breaking that down, it basically means what we're doing is we're assembling all the CSS and the JavaScript and the JavaScript settings and putting it down into that build array. So we're really trying to take everything that that build array has and abstracting it out so that the modifiers can come in and change that. So let's just have a look at a concrete example here. We have our parallax background modifier. So it's implementing modifier plug-in base. So the modifiers are plug-ins. So you can go out and define your own if you like. And in this case we're really saying, hey, we want these two libraries. Please include those in one too. Thank you. We want this JavaScript settings array. Let's build that out. Great. And we've also got some CSS in here for a full background color. Can you please put that in? So we build all those things up and then we just go off and make a new modification. So we're just sort of gathering together all those different properties and making a modification. And at the end of the day, that modification goes through to the hook-end view alter and does its magic on the build array. So yeah, basically that's the way we've abstracted out modifiers and how they're able to plug in. I'm just going to have a quick sip of water. Sorry, guys. Okay. So that all sounds a bit complicated, I know. We've done a lot of the hard work for you and we've also released a modifiers pack to help you out. And this Contrib module supports a number of modifiers to help you get up and running very quickly. So you can come in, download this and there will be a whole lot of submodules in there and you can enable that. And once you enable it, the config will spring up, the modifier will be there and you can then start using that on your own entities. You know, we support like a lot of sort of eye candy kinds of backgrounds here. You've just seen colors, images, different gradients, parallax and video, right? So this is a really nice grab bag of tools that marketers and editors are going to really like to use to sort of spice up their pages. And it really brings a lot of sort of creative capacity to editors to quickly add this kind of stuff to the page. We've also got another sort of bunch of utils in here for achieving different effects and you can mix and match those as required. So that's a modifiers pack. If you try modifiers, please download the modifiers pack because that's the thing that's going to help you get up and running. All right, let's return back to those first two questions we had at the start of the presentation. You know, the first one was, you know, how much time do you actually spend solving customer problems versus, you know, doing repetitious tasks in the Drupal back end? And, you know, one of the things about the Drupal community is we spend so much time trying to automate and make things more, you know, make things faster and more reproducible. And, you know, this is what we've tried to do, you know, with the modifiers module. If you are able to get a nice set of layouts, a nice set of components, a nice set of view modes and a nice set of modifiers, you can bring them all together and have a system that is insanely flexible and allows you to build sites out very quickly. When we first started building Drupal 8 sites, you know, they were mammoth things, right? You know, we would be there for six months trying to build something custom. Nowadays, now that we've got this sort of toolkit, we're able to build sites out in, you know, four or five weeks. And, you know, we've really sort of done away with a lot of the head scratching and hair pulling that can go on when you're doing things from scratch each time. And, you know, this has really allowed us to spend more time, you know, with the customer and trying to work out what they need and how that site is going to be put together to, you know, to answer the questions and their demands. Secondly, you know, once a site is delivered, how responsive is it to future needs? I think once you have these set of components, you're also not just delivering something that's more flexible, but it is going to be much more, you know, predictable and extensible in the future. So, I mean, having that toolkit there for editors means that they're able to mix and match as required, you know, and the combinations that they're able to do with, you know, the different view modes and layouts gives them a lot of expressivity, if that's a word, going forward. And if they have a new feature that they need, you can then evaluate that and say, okay, this is worthwhile. Let's put it into the platform. Let's encapsulate that into a component, a layout or a modifier, and you're improving the system as a whole. So, what you're doing as a developer is, you know, giving people a scalable system and you're getting reuse out of your code, and that can only be a good thing. We've seen where we've come from. Now it's time to have a quick look at where we could, you know, possibly be going. You know, when you look at Drupal, you know, these days, I see there's a rapid change going on in Drupal 8, you know, lots of amazing things are being added to Drupal 8 all the time. We have, you know, layouts and we have the settings tray, and we've, you know, we've had a lot of, and sort of developments going on in this area in Drupal Core. But I also see, you know, ideas coalescing, you know, from different parts of the ecosystem. We've seen the layout builder using these ideas of sort of stackable layouts, and we're also seeing the BRICS module taking this approach as well. So I think that's an idea that's really going to, you know, continue to expand, and I can see, you know, lots of little sort of layouts, you know, supporting these kind of new ways of building pages out. I haven't really spoken too much about layout builder in this presentation. That's because at the moment, in my opinion, the layout builder is really sort of targeted at site builders putting together the blocks for content types, right? It's dealing with the sort of the big picture stuff of what a page can look at. What I've been trying to look at here today is the content side of things and focusing on BRICS paragraphs and modifiers. Now, each one of these three things, they're all implemented as entities. They're treated as content, not config, and they're really living in the world of the editor. And so I'm really sort of drawing a distinction there on persona, site builders versus editors, but also content versus config. And I think it's a conceptual differentiator here that the paragraphs, BRICS, and modifiers are all basically content that's living in a, you know, a living breathing site that's controlled by the editors rather than the site builders. It's been great to see, you know, the BRICS module bringing together all of these things, breaking down the boundaries that have existed previously. You know, we've now got dynamic entity references being brought to the fore and layouts sort of working in nicely with the components that you've built. There's a really cool project that I've just recently found out about, and this is by Stephen Fondenhout, and he's released a proof-of-concept module called paragraphs front-end UI. Now this little animated GIF, it's pretty low res, but I think it will give you enough of an idea. The settings tray is available via a contextual link here, so you can see the settings tray opening up, and the different properties of the paragraph are being edited in the settings tray. So what we have is we're not editing the content per se, but we're sort of pulling the levers and, you know, turning the dials here and actually sort of configuring how that thing works, but it's still content stored in the paragraph. When it comes time to actually editing the text on the page, that's sort of done over, you know, on the left-hand side there. So here we can see this outside-in approach that Dries has spoken about being applied not just to configuration, but also content. Now Stephen says this project is just a proof-of-concept, and it's designed to encourage, you know, thought and discussion in the Drupal community about what can be possible, you know, with interfaces of the future. And I think if you, you know, take the ideas here, it would be quite easy to extend them into the way Bricks applies things, and as well as the modifiers. We've seen that the Bricks and modifiers are kind of stuck away a little bit on the edit page, but if we're able to use this paradigm, it's really bringing them up and putting them into their hands of editors even more. So let's have a look at a possible recipe for the future, and really, I mean, this stuff here is right here today. And we've got the settings tray newly arrived in Drupal that's providing the outside-in experience, and this can be used for config and for content. We've got the layout builder for site builders, you know, building their big sort of global picture things for handling the content types and the various view modes. And then we've got the paragraphs Bricks and modifiers sort of combo that's sort of working together on the content side of things. You know, I spoke positively about the way the Bricks module handles the editing interface on the node. It provides a really nice sort of compact view of the world, but it is also quite technical. I think it probably suits, you know, the technical-minded Drupal folks who may be using that, but really for editors, having that outside-in experience is also going to be, you know, a massive sort of positive for them as well. And I think, you know, this is the kind of space where there's a lot of stuff happening. I don't know if this is going to be a winning recipe or not, but I think it's certainly something that's interesting and it'll be sort of very interesting to see how the Contrib space works. That develops here in the future. Tony Starr, Anton, he is the author of the Bricks module, and he will be, you know, presenting on Thursday living design systems for teams. He will be, you know, speaking about a lot of the ideas I've gone into here and applying them to component systems and how they can work. And finally, I'll just do a quick plug for the sprints on Friday. If you guys are around on Friday, please head along to the sprints and get involved there. So that's basically it. You know, what I've tried to present to you today is something that's relatively new. The Bricks module really only has about 400 installs. The Modifiers module has probably got about 70 or something. There's very sort of early days for these modules, but I think that they, you know, can combine together to form a really sort of good ecosystem combining it in with paragraphs and other entities. So, yeah, thank you very much and thanks for coming along. And I really would be interested in your questions. So I don't really know the drill, but there's a microphone up there. So, you know, I really want to hear some discussion. We do have probably about, well, a good 20 minutes if you would like to talk. So, yeah, please head on up and ask away. Hi. So I'm curious about the example you showed with Modifiers. The way that I would normally achieve that would be to add a field on those entities to say, oh, make this a blue background or a white background or change the parallax image. Can you say more about why you would choose to use a modifier versus just creating a field for those options? Yeah, well, the main thing is a modifier is a plugable, it's plugable, right? So you can just add one modifier's field and then add multiple modifiers in. So you can add a parallax one, you can add colors in and you can basically build out the presentation combining multiple modifiers at once. If you're just going to do it as fields, just say you had 10 different modifiers, you'd have to have like 10 different sets of fields, right? So, you know, your paragraphs are going to get very complex because you're just adding in all this stuff, basically. So this is just a way to abstract at one level and allows you to apply it that way. Gotcha. And so also with fields, you would need to do some custom theming to say what, you know, when you add that field, you'd be saying, you'd be providing a class and then creating something in the theme. That says what that class does. And it sounds like with modifiers, you don't do any custom theming. Is that correct? Yes or no? 99% yes. Like all those modifiers you saw there did something quite explicit. Like I'm going to put this image, you know, on that div and that's just the way it is, right? There's no further modification needed. But you know, of course, you may still want to theme some things. It's not completely doing away with theming, but certainly we try to encapsulate it as best we can. It's a new unit that does what it says on the tin. I think the concept of classing paragraphs, and we've also got another module called entity class formatter, which can apply to any entity in Drupal 8. But applying a class through a dropdown on an entity is an incredibly powerful thing, right? It's much, much simpler for an editor to say, hey, I want the blue background or the red background, for example, rather than having to add a modifier in. I didn't talk about this, but we've got another module called the look modules. Basically it's like applying a look and feel to a page and it's possible to define a set of modifiers in a look and you can then wire that into a class. So you could have the, I want my fancy trigons background with white writing sort of look and that you can just then select that with a dropdown. That's like another step of abstraction I didn't want to go into today, but that's the power of being able to define different selectors rather than entities. So you can actually use that approach to start styling up the header and the footer and things like that as well. It just depends how crazy you want to go, but just keeping it simple, we're just applying the modifiers direct to the entity. So I think all those background ones, the eye candy ones, they're going to be nice, easy ones to put on, but maybe you might have a dropdown that handled the padding or something like that, you know, how your theme actually wanted to deal with that. So it's just a matter of mixing and matching. And I think having a class selector is still very helpful, which is different to what modifiers provides. And sorry for hugging the mic. One last thing. So do you see the techniques that you've shown as more appropriate for site builders or for content contributors? Because I think a little bit of this might get a little overwhelming for the typical non-technical content contributor. I would probably say skilled editor, right? Yeah, like more of an administrator level. Someone who wants to get involved, like an old-fashioned producer, I guess, someone who really wants to kind of understand the system. I'm not saying, yeah, all editors are going to naturally feel at home of going, oh, I'm going to add this modifier in, but that's the way we've tried to build it, right? You know, it's like, yeah, add that one in and put it on. So I mean, that's what we're shooting for. But the whole idea is that the site builder and the developer develop the tools that the editors can use. And I think with that outside-in approach, it's going to be, you know, you can imagine, yeah, edit this paragraph and you see the modifiers just popping up there and you just tweak it and click save and it updates. I mean, that is a much more editor-friendly approach and that could be something for the future. Yeah, cool. Thank you. Thank you. Great talk. Thanks for talking about BRICS. We actually use it very majorly on our site and we have like the skilled content editors like successfully managing BRICS pages and everything. I'm kind of curious about your thoughts on using ECK as like entity construction kit as opposed to using paragraphs, mostly because the paragraphs like are kind of inaccessible to the rest of the site. Because we found that you could actually go into an ECK entity and edit something where you're not even on the page. Yeah, great question. So I mean, when the BRICS module first came out, that was the paradigm you'd go into ECK, define an entity type maybe called BRIC or whatever you wanted to call it, and then you define your own bundles. And effectively that was kind of replicating maybe what you had in the custom blocks world or the paragraphs world. So we already had a set of custom blocks that did that. We had a set of paragraphs that did that. It was like, oh no, I don't want to have to go and make another entity. So for me it was quite nice to see paragraphs being supported. But I think with this dynamic entity reference that you have now, that does mean that you can mix and match. So if you want a global block, go make a custom block and then you can just mix and match and put that one in as well. But I guess it's the both sides of the divide. Is it scoped into the content or is it a global thing? And of course having reusable blocks can be very helpful as well. Yeah, we actually are using ECK and paragraphs with BRICS. It works seamlessly, so it's really nice. And why wouldn't you have gone with like a custom block rather than ECK? We actually are using blocks to show different views. So we create a view that has a block and then the BRICS page can show that view as well. It's really flexible. Yeah, we've got dodgy one like that, the old view paragraph or whatever to allow you to pull that stuff in. But you're going to have little edge cases, views on entities that you can put in. So sometimes you need a little bit of glue to get those working. Thanks. You pointed to this a little bit at the end. So if you want your answer to be good at the session later in the week and find out there, that's okay. But I was just wondering your thoughts on how this fits into like component-based design through pattern lab or KSS or those sorts of like mapping specific components or specific designs. Yeah, I mean Tony Starr may be talking about that later in the week. I'm not really sure, but I guess that was really coming down to how you want to model that in your paragraph. And when that paragraph has been rendered out, what template you're going to use and what libraries you're going to pull in there, I guess, right? So, you know, I think the paragraphs will give you that flexibility to define the HTML and CSS. So on the back end it doesn't add any complexity to the paragraph completely? No, we're just trying to avoid that at all. I didn't really touch on it there, but there's one field called field modifiers that you put onto the paragraph and that basically pulls it all in. Okay, cool. Thanks. Hi. In your example with bricks, you were kind of going through this quickly. So I didn't really pick up where the paragraphs were in there and were you actually editing a node and the bricks is the interface to add paragraphs? Yeah. Or are the paragraphs edited separately and then referenced in the bricks interface? So, I mean, what are we on here? This is the full blown one. Yeah. So, I mean, yeah, this is a node and this is a bricks field we call content components, but essentially you're looking at paragraphs here. Each one of these things is a paragraph. So this layout one, this is a special paragraph type of the bundle called layout. And so in the bricks logic, it goes, oh, if I see a bundle called layout, I'm going to go in and provide that little dropdown with all the layouts that are provided by the layout sort of plug-in system. So that's a little bit of magic there where it's pulling that thing in. But what this field is doing is it's got the entity, it's an entity reference list of entities, but it's adding the indent. It's handling a layout if that's being selected. It's got some CS, sorry, a class in there as well. And it's basically bringing those things together into the field. So there's more data wrapped up in the field. That's really where this configuration is being stored. So it's still the paragraphs that are, they're still themselves, you know, we're not changing those. It's just basically adding a bit more data in on the field level as to how they're arranged. Okay, so you could get this similar effect with the paragraph field. It's just each paragraph holds that. That's right, that's right. That's in a paragraph rather than in a brick field. We've been down that path before and it's exactly the same. I mean, it's not terribly different. You could easily have a layout paragraph yourself and have a drop down and then that class with class in paragraphs or whatever gets dropped on. And then in your theme layer, you say, oh, every item gets, you know, you extend in some grid or something and target that class, right? So that pattern, we've done that with paragraphs before, but the problem is there, it's just like the UI, it's just a bit too spaced out. And like the nesting of paragraphs can get a little bit crazy sometimes. Okay. And then one other question with bricks, the layout options that are being presented here, are those definable per node type? That's a good question. So that editors can be limited to the appropriate set. Yeah, this is everything. So I just think we've got the four-inch ladder in here. We've actually defined our own little module called Bricks Layouts. And so we've basically defined our own set and that's what we use here. But yeah, you can see in this list we support few-mode layouts and page layouts. So we've got all these. We use these ones for the pages and we use these ones for the bricks. But these are sort of like layer cake design ones and they're not these monolithic ones with many steps. It's just like one column, two column, three column, equal columns. That's the kind of paradigm you're talking about here with these. So we've done all these with Bootstrap and then the equal column is just like a flexbox thing too. Okay, so that's potentially when setting up a site, that is potentially scopeable to a constrained set. Yeah, I mean, I'm not really fully on top of that. But I do believe there are attempts to have libraries of layouts and define them in different cases. But yeah, my knowledge is a bit lacking on that. At the moment, it's just all the layouts that are there. Thanks. Hello, and thank you for your talk. I was hoping you can help me by zooming out just a little bit. No, not on the screen. Just zooming out in general, I'm thinking about page assembly in Drupal. Yeah. It's a basic question, I apologize. But in Drupal 7, I think there was a lot of competing page assembly strategies. Like you were there like blocks in context person or panelizer IP or display suite. And some people use beans. It seems like there's a lot of different options for traveling down that road. And so I'm trying to get an idea of how this fits in the overall scheme of how people are doing Drupal 8. What does this compete with? And if I say hello to this, what am I saying goodbye to? Well, you know, we're quite open to a lot of things. I'm quite promiscuous when it comes to the techniques, right? So we use display suite for our little view modes and we use panelizer for the content types. That's just how we like to work with it. And that's the paradigm that we've used all the way back from Drupal 7. We're still doing it in Drupal 8. We love paragraphs. We're still using paragraphs, right? So we haven't really said goodbye to any of those things. You know, we use beans as well. You know, a previous question before was about how can you reuse blocks? Well, of course, beans were the equivalent of custom blocks now and they're very, very handy in some cases. So, yeah, we're still using those as well. You know, so I'll just say one of the crazier things we're doing now is that just say you've got a complex footer, right? And it's got all these weird layouts. Now, usually in a theme layer you're going to maybe have like four postscript areas and a little footer and you kind of cobble it together and hope that that works. But then what happens if you come up with a design that's got, you know, like four layers of stuff and it's got to be two grid instead of four? What we do now is we define one region in the theme. We call it Nadia. It's just at the right at the very bottom and it's just an edge to edge div region. And then we've got this block and we just call it the Nadia block. It's a custom block and that basically has bricks in it. And then we can just build out the whole footer with bricks and then we just take that block and put it into the theme region. And so suddenly now with this tool kit we've got a way to build out insane blocks and we can put all the modifiers on it. And, you know, so we're just basically building out that whole footer region in a really flexible way. And so we're using this on distros, like just say we have a distro and we're trying to support 20 marketing sites. Like each marketing site is different, awesome. And they've all got their own weird footer way. But, you know, we're able to kind of use this system to, you know, basically put it together in config without having to break out into the theme and define new layouts. I was just going off a bit of a tangent there. But I was just going to try to say, yeah, you can kind of put this stuff together in interesting ways to overcome, you know, some of the problems. I mean, one of the design goals we've had is really to try to not touch the theme layer. And that is to have basically a style guide driven, you know, development that's providing, you know, the basic typography and stuff. But we're really trying to let the content and the modifiers tell the story. And that's the way we're trying to build sites now. And so with that in mind, we're able to really, we have, you know, been building sites with this approach where we're not really touching the theme or if we do it's only to solve something really specific. What are you giving up? Well, I mean, there's, I mean, the context paradigm in Drupal 7, you know, that's, you know, that's this different why we're like, we're at the moment living in the world of paneliser and still defining the placement, you know, according to content type in that way. But yeah, you know, you're just finding your way. I mean, Bricks is a new thing for us. But, you know, I just really loved it as soon as I saw it because it was all still working with entities. And it was just fitting nicely, you know, together. So I just think you got to experiment. I don't really know how it's all going to wind up, you know, but Bricks for me has a lot of promise, but you know, there's a lot of change sort of going on in the ecosystem as well. So it'd be interesting to see what happens. So it's just briefly, you had mentioned earlier about a winning recipe. And so if you adopt kind of a strategy and you're like, this is a community isn't really picking up steam on this. Have you had problems in the past, like going back to your 20 sites and saying, oh, this one did some other kind of strategy. And this one used this page. Man, I'm doing that every week. We're pretty adept at writing scripts and moving paragraphs around between all these different systems. No, but if you invest a lot of time in your paragraphs, they're still going to stay as components, right? So if these layout systems, you know, change, I mean, all that investment you've kind of put into those paragraphs is not going away. They haven't been deleted or anything. You know, they're still existing on that node. So, you know, you know, obviously this is a, you're buying into the paradigm when you get into it, but it's not the end of the world. If things have to change, I think, because you've still got your content there and that's the main thing. Excellent. Thank you. Thanks. I really enjoyed the talk. You talked at the end a little bit about the layout builders. And I was wondering how you see this integrating with that and the example that you kind of showed several times, that could easily have been built with layout builders instead. How do you pick which one? Is it just whichever one you think the content editors will be more taken with or what's the strategy there? Yeah, now, like I don't want to be someone doing pronouncements on layout builder. You know, the settings tray is awesome and the visual aspect of it is really cool. But I think the distinction I was trying to draw there is the node specific nature of paragraphs and that's really been treated as content. Whereas layout builder is like panels, you know, panels in core, it's IP, it's all these big block things. You're adding, you know, views, fields and blocks. You know, that's the kind of thing you're dealing with. And you know, our experiences with IP in the past means you have this massive library of blocks. So if you want to do a landing page with 20 sections, where you go into your custom blocks and you make your 20 custom blocks, you give them a specific name like front page, top, front page. You know, and then you're trying to go in and go, oh, where's front page, top, there it is. Okay, I'm going to drag it there. That's just, you're trying to get that content from a global namespace into the page and that's why I'm sort of a proponent of paragraphs that it's existing in there. So I mean, I don't really know what's going to go on with layout builder and paragraphs. I'm a core developer that, you know, they're looking at trying to integrate paragraphs in and that's on the roadmap. I mean, that's just hearsay. But as we've seen from that, that paragraphs front end proof of concept that Stephen Fondenhouse did, that, you know, we've got that interface with the settings tray that's there to manipulate the paragraphs in the same way. So, you know, I'd say concentrate on the UI and the editor experience, maybe not the layout builder side of it, you know, but that's just my opinion at the moment. But, you know, when we're building pages we're still really sticking with panelizer for now, I'm waiting for that to become a bit more mature. But, you know, I'm not dissing out on it at all. It's still, you know, amazing initiative. But that's the system we're using at the moment. Is it too simplistic to say that that is more for like one-off pages whereas the layout builder will be more for this class of things? Yeah, that's it exactly. You know, so going back to panelizer, you know, like you could define your layout for a particular content type and capture that in config. But as soon as you came down to the node level thing and did an override, that was kind of, you know, content. So you can do node overrides with this and you can do that, but it's, you know, it's not operating on that global level anymore. So you can do it, but I just haven't had good experiences with it. So, yeah, that's why I'm going that way. All right. Thank you. Thank you. Wow, questions. I love the questions. Now, three minutes. Any final ones, guys? All right. Don't forget Anton's talk coming up on Thursday. Thank you very much. Yeah, sure. Just, I can now relax, Kayla. Months of stress. It's all good. I'm going to start with how we would fit into here. So we have basically three different books for what is hopefully the same content type of each. So we have this, what they're calling a level one page. And this is kind of like what the top level page for each thing would be. And it's basically like this full page and then the only thing that they'd really be editing here is this and then whatever comes here. And then the rest is this. This would just be blocks, you know. Sorry, I'm just... That's right. Is it okay if I watch? Yeah. Oh, you want to watch this? Sure.