 Okay. Thanks, everyone, for coming today. Let's get started. So in today's session, I'm going to be talking about approaches to Drupal front end and how to decide between more theming and more site building kind of approaches. I'm not going to be talking about decoupled Drupal or that kind of thing, so if that's your only shtick, you can go to another session. I'm going to be talking about more traditional Drupal theming. Just as an introduction, my name is Suzanne Degacheva, and I work at Evolving Web in Montreal. So I co-founded the company back in 2007, and I do a lot of Drupal training. I also do a bunch of theming, some site building, and a bit of module development from time to time. And I manage Drupal projects and get to work on interesting things. And if you're interested in following me, my Twitter handle is Suzanne underscore Kennedy. And just as a heads up, I do run a Drupal training program, so if that's at all interesting to you or you have colleagues who you desperately want to learn to have no Drupal better, feel free to get in touch with me. You can come up afterwards and I can give you more information or you can look at that on our website. So who here considers themselves a Drupal themeer, Drupal front end person? Probably most of you. Some of you do Drupal site building more. Some of you figure, I'm more on the site building side. Should have set this up as like site builders over here, themers over here, I've kind of a standoff. But of course, if you're implementing the front end of a Drupal site, you have to do both these things, right? So typically any Drupal project, you're gonna be doing lots of theming techniques. So over on the left here we have different things you're gonna be doing that involve theming, working with templates, creating libraries, writing CSS, all kinds of fun things. And then on the configuration side, a lot of your work is gonna be actually creating elements in Drupal, configuring views and whatnot, adding classes, working with image styles. So you have a lot of these types of techniques you can also use. And typically when you're implementing a site, you have to do these kind of in conjunction and you're doing both of them together. But often you run into situations where there's a couple approaches you could take and sometimes you're looking at a more theming approach and sometimes you're looking at something that involves more configuration. So I'm gonna go through some of these in the session today. So there's a philosophical paradox that you might have heard of. It's about a donkey who's faced with two piles of hay and the piles are exactly identical. So the donkey's just standing there looking at the two piles of hay and the donkey's super hungry. And the piles are exactly the same so he can't decide which one to eat. And so he ends up starving because he just can't pick which one would be better. And I feel a lot of the time as a Drupal front end person or just as a Drupal site builder, we end up in this situation where we can't decide between two equally good options. And part of the problem is that it's hard to assess. Like the piles of hay look the same. And so when I'm working on building out a site, whatever it is, I like to think through the criteria that I need to use to figure out which approach to use. So it's not possible that the two approaches are exactly the same. There's always gonna be differences. It's just a matter of us knowing what those differences are and how to assess them. So when you're looking at a certain approach, you wanna first of all make sure that the approach is gonna work for you. Like if I'm implementing this header, is it actually gonna show up on the right pages? And not only does it have to work, a lot of times with Drupal, we need to make sure that things work at the right level of specificity, right? So you want the header to show up on all these pages but you don't want it to show up on your product pages. You only want it to show up on your blog posts. So making sure that your approach is gonna work for the right level of specificity is important. You also wanna think through, as you're deciding what approach to take, how easy it's gonna be to keep something up to date. So if you're trying to implement background images on all of your headers, what's gonna happen if someone has to change those background images? Is that gonna be easy to do? Or is it gonna be easy to reuse that for other content types? Is it gonna be easy for other people to come along and understand what you've done? So what approach you're taking? It depends on the whole context of the project. So it's not enough to just say, well, this is the approach that I like. You wanna be thinking about where the project is going. So if you're implementing something, are there gonna be other things exactly the same that you can come across that you wanna implement in the same way? Is it gonna be possible to reuse what you've done? Is it gonna be possible for your colleague next year who inherits your project to understand what you've done? And so these are the considerations you need to take into account when figuring out what the approach should be. So I'm just gonna run through a whole set of examples and then I'm gonna talk about kind of two basic approaches to each one and I'm gonna talk about why you would pick one over the other and if you have in mind any other examples you can think of, you can feel free to share them at the end. So hopefully there'll be time for that kind of interaction as well. Let's say I'm a front-end developer on this project and I've just gotten the designs for this new website. I'm looking through the designs. The first thing that I look for is sort of the most exciting thing. I like to do the interesting parts first. So the first thing that I see that's interesting are these tabs. So within the content there's, within this content type there's gonna be these five tabs that the user can click on to see different parts of the content, different sections. And so thinking about how to implement these tabs, I consider two approaches. So one more configuration-based approach is gonna involve downloading a module. So who can think of a module for setting up tabs on the website? Oh my goodness, it's only like one person who knows if a module for tabs. So there's all this research we're gonna do to figure out maybe a potential module to use for this. On the more theming side of the approach, maybe we want to create our own, set up our own JavaScript library to implement tabs. And then we're able to configure that and add classes via the template. So actually in a template file, we can set up the HTML for the tabs, we could put in the classes, and then we can make it all work with our custom library. So why would you pick the configuration approach? You might really know in advance that there's gonna be all of these tabs on the site. It's not just one content type. Maybe there's many content types that are gonna have this feature. And you know that you're gonna wanna be able to apply this to other parts of the site without stepping in and setting up additional templates. So if you really need to be able to extend this, a module approach might be the best way to do it. Whereas with the JavaScript approach, with a more theming style approach, we would be able to have a lot more control over the JavaScript we're adding. We might be able to limit the amount. We might have options of other libraries to use. So for example, if I've, did anyone here go to the animations session yesterday? Probably a bunch of you did, front end to people. So maybe you found out about some new animation technique and you want to use that to implement the tabs. So if you actually write this yourself as part of your theme, you'd be able to do that. So whether you're inserting this functionality into the theme of your site or building it mostly as part of configuration really depends what you expect and what you want, how you want this to be maintained. So you've got the tabs part all figured out and then you move on and you start building, you start kind of going down through the mock-ups and you start at the top. So you notice that there's these nice headers on the site. So these headers that are displayed on certain content types and this is gonna be the title of the page. So here this is the title of these school board content types and for each one there's this nice background image and then you have some fields that show up as well. So you're thinking through how you could possibly implement this and you come up with two ideas. First thing that pops into your head is that you could create a template for this. So in Drupal 8, as you probably know there's a page title block, right? So the page title is something you can move around and there's a template file for that page title that you can modify. So you could actually customize that template and start adding content to it. So you could print out some fields. You could add an inline style in your template file to create a background image for that section of the page and you could pull in data in twig from the image for the page, the header image and you could print that out as the background image. So you could do this purely with theming. Or on the other side you could do it with configuration. So you could create a view and add contextual filter and display the fields that way. So you could do it with just configuration and maybe of course a little bit of CSS. So you're trying to decide between these two options and on the one hand if you implement it in your theme it's kinda nice cause it's fun to do twig templating. Like who here likes twig? I think it's awesome. Every time I get to do it I'm just like oh this is so fantastic. And you have in that case fewer views and fewer blocks and fewer moving pieces and maybe someone else who comes along is gonna be familiar with your templating approach and they're really gonna understand that. But on the other hand, the configuration approach makes it way easier to go in and the client decides oh I actually have another piece of information to put here. So maybe with a view it would be easier to adjust those fields later on. You could also in the configuration approach maybe instead of having a background image that you put into the template file maybe you just wanna print out the image and then have it displayed behind the other fields. And with that approach you could use the responsive image module, you could resize the banner on mobile and make it more performant and maybe that approach is gonna work better. So you kind of have these pros and cons. So in large part in this case it's gonna depend on what you and your colleagues have kind of decided is the better approach. Like do we expect to do all these things in templates or are we gonna make 50 views on the site to show fields exactly where we want them? So a lot of the time these banner images have some kind of overlay on top to make the text more legible. So we see this pattern all the time right in hero banner sections of the page. So these banner images that we're working with all have this kind of dark overlay is kind of transparent and we have to apply this throughout the site in different ways. And so there's a couple of ways we could do this. We could use HTML and CSS to create an overlay. Eventually it'll be wonderful when we can do this with just CSS. Or we could use the image effects module who here has used this module. Image effects, anyone? Image cache actions maybe if you're more like old school. Yeah. So you can create an image style that actually adds that. So that way you're just creating that thing once in configuration and you can apply it wherever you need to on the site. So you have these two options with pretty much the same result. The HTML, CSS approach is nice because you don't have so many modules. And you can also adjust the effect. So in this page you have this darker overlay but maybe in another context you wanna change the color of that overlay depending on the type of content. So maybe in your design you need more flexibility. Maybe you actually need to be able to configure that based on the content of the page. So with an HTML, CSS approach you're gonna have a bit more flexibility there. On the other hand with an image style with an image effects approach you're going to have less HTML which is for some people like the ultimate goal like how can I have as little HTML as possible. And it's also gonna be easier to reuse. So if someone wants to set up another content type and basically implement the exact same thing they can simply apply the same image style to the content wherever it's displayed. So you can reuse that throughout the site. So you can always ask questions as a front end developer sometimes we get a design we're just like oh I can implement this, watch me and you just do it as fast as you can. So I think in old cases like this it pays to kinda step back and say oh well are we gonna be doing other things like this on the site in the future or how could this apply to other content types? So stepping back and doing that analysis at this point is important. So you finish the headers of the site you've got the nice headers with all the fields you want and the background images and it all looks great and then you keep scrolling down and there's this grid of content. So this is like every website you build right? There's always gonna be some grid of three columns, four columns, maybe all kinds of different grids throughout the site. So this is a content grid and it's attached to a page. So maybe you see this as part of a landing page or a basic page where you wanna have some little tidbits of information like calls to action or in this case we have statistics. And your first thought is that you can implement this with paragraphs or blocks, right? If they're gonna be reusable if you want these statistics to show up somewhere else on the site you're probably gonna end up using blocks cause you want to be able to print those a couple of times. Paragraphs are gonna work better if you have that content kind of inherent to that piece of content you want it to be searchable you want it to be really part of that content type. So either way you set up a reference field and you use paragraphs or blocks. And then if you're gonna take more of a configuration approach you might be really creative and think oh I can actually display this with a view. Cause that way I can set it up as a views grid that can be the format and then I can apply classes within the views grid and then voila I have my layout. I don't have to do any additional theming I don't have to write any templates. On the other hand you could avoid using a view all together because a view of fields for that piece of content on that contents page seems a little redundant so maybe to you a template approach makes more sense. So you override the field template and you put the classes in there so that you get the three column grid so you can override your markup and then style the thing. And in either case if you're using something like Bootstrap and you have existing classes you can use those classes or you can set them up from scratch in your theme. So the configuration approach is nice because it allows you to change the style of the grid through the configuration. So you can just go into your view and add it a class and you're in the config and you're gonna change your view maybe from a three column to a four column layout or you could apply that same pattern to other grids of content that come along. So it's a little bit easier to reuse that. On the theming side it's nice because you avoid this confusion of having a view on a page to just show something that's part of the page. I always find this a bit confusing when I see that someone else has done this. When I do it it makes sense to me but when it's my colleague who's done it I always get confused like where? Where is this content actually being printed out? Like how can I customize it? I don't see it as being printed out as part of the node. Another nice thing about doing this through theming is you could actually come up with some logic in your theme that if there's three items of content then you print out three columns whereas if there's four items of content you print out four columns. So you could actually adjust the classes that are applied. I know if you're using Flexbox you're thinking oh who cares I'll just use Flexbox for this but if you're still using something like Bootstrap and adding classes for each column depending on the number of columns then doing it through a template allows for actually you to write code and have that flexibility to change the behavior. So you've implemented your grids of content and that's working out well and then you come across some other attached pieces of content. So you have another style of landing page where you have some block or paragraph type content being printed out like this and you can kind of see here that there's a background image used for each of these slices of content and a different color being applied to the text and also different alignment. So there's some styling changes and so you think okay how am I gonna implement these two different styles of displaying content on the page. So a configuration approach you might decide to add a field to each entity so each paragraph or each block might have fields to let you customize the styling of each component and you could have separate fields for alignment for color for typography or with a straight theming approach you might say forget the fields I'm just gonna say this is a striped thing and the first ones white the second ones black the third ones white and just have it all kind of hard coded in your theme. And so with the configuration approach you're adding more configuration but you're giving more flexibility to your admins and with the theming approach you're creating something that's just simpler and you avoid adding anything extra. So you've sort of finished with these landing pages and you're moving on to more of the content types and some of the content types that we come across as Drupal site builders are gonna end up having a layout within the actual content. So here we have an image at the top we've got some most of the fields over on the left side and then on the right side there's some selected links that are displayed and maybe a logo for the product. So our theming brain is telling us oh you can just make a node template for this this is great again we love templates so this is gonna be fun and we even get to use the without filter because ideally our node template is gonna print out all the fields on the left and then it's gonna break out these special fields on the right so that way if someone comes along later and adds some more product attributes they'll get printed out as well. So that's maybe our first instinct. But then we went to DrupalCon this year and we heard about the layout discovery and field layout modules and these allow us to place the fields in a layout just through configuration. So how many of you have tried these modules? So few of you, you all have homework to do. None of you is on a laptop right now I'm very impressed so you can go home afterwards and install these modules try this out. So this is a way to these modules provide an interface through Drupal for kind of like a display suite does but it's core, these are core modules and these provide the functionality to configure the fields in your content type or in other entity types into a nice layout. And there's some layouts that come with so you can use like a two column, three column layout or you can provide your own layout in your theme. So I'm kind of cheating, I'm calling this a configuration approach because you get to configure the fields but if you really wanna create your own layout because you have your own layout for the site that you've already come up with with classes you're using for the layout, you can provide that layout in your theme. So that's what layout discovery is all about, it allows Drupal to discover your custom layouts. So the theming approach, obviously there's gonna be less configuration, fewer modules and up until now, these modules are experimental so you might have that reason not to use them quite yet, it's also probably easier to manipulate and combine fields in the template file so these modules don't give you so much flexibility for really customizing the markup of individual fields. On the configuration side, it's going to allow you to reuse the same layout across different content types and it's gonna be easy to add new fields to the layout. So if you're working with this product and somebody decides we should have some more of these links on the right-hand side of the page, you can set up those fields and then just fix the layout. And that whole layout interface, that's part of the managed fields display interface that's already in Drupal so it's just an extra feature that's added there for picking the layout and setting that up. So you go through the site and you discover some more content types with interesting fields and you see this content type where, this is a book content type and there's a lot of fields on this book content type an astounding amount, you had no idea that there could be so much information about a book. And in the design, the designers decided to kind of condense the information of it by combining a lot of the fields together. So there's some fields that have links on them where the link and the text is our separate fields actually and there's a lot of fields that are combined together in kind of an inline style with these pipes between them. And so you have to figure out a way to implement all of this and as you scroll down the book page there's even more elements like this. And so you want to customize the field HTML and you might jump right to the conclusion that you're gonna make a node template. So you're gonna customize the HTML of each item in your node template. On the other hand, you could take this approach of having a view with a contextual filter to display the fields for the current node that's being displayed on the page. And that way you can configure the HTML through views. So if you've all used Drupal 8, you know that you can add twig right through views to handle your fields. So if you're displaying fields as part of your view you can just go in and you basically have a twig template for each field right within the views configuration. So you could use that to actually create this whole interface. So you could have two equivalent outputs but just completely different ways of configuring them. So the theming approach is nice because I've just shown you one snippet of this page. As you scroll down the page there's gonna be more sections like this with extra fields that are formatted in a similar way. So by doing it in views you're really kind of creating all these mini templates and maybe there's multiple views blocks that you're actually displaying on the page. And so the configuration itself although it's nice that it's just configuration it's actually hard because it's not really organized that well or it's not necessarily easy to know that those views are printed out on that page and that that's the approach that was taken. Whereas a theming approach is kind of more maybe more obvious. You just have one template file that's printing out all these book fields and all the HTML is in one place. So it might be a little bit easier for someone else to come along and discover what you've done and actually understand it without having to click on every single views field configuration. So again, it depends on your team. It's if you're working how many of you are working with other themeers other site builders? Yeah, a lot of you are and even if you're not I find that if I come back to a project after a year it's sort of like I'm a new person and I'm my own colleague a year later that I have no idea how I did something. So you want to be consistent with yourself as well. So you finish implementing all these books and there's a few more views that you have to implement on the site. So here's a list of pages that you're printing out and it's gonna be probably a view. In the future you might need to build something else like this as an entity reference field. So you might have a page that references for other pages, like related pages. And so you might have a couple ways that you're displaying the same kind of interface. And so you think about two ways to do this. So you have kind of a teaser version here of each page and you think maybe I could do this as a view mode. Like you could create a teaser view mode and have the four fields there, the title, the image, the text, the link and have those being displayed as fields as part of the view mode. And so you could display the nodes in the view using the view mode and then that's gonna control exactly what's printed out. On the other side you could configure the view to display fields and then you can just print out each field one at a time. So on the view mode side it's kind of nice to use view modes because view modes, if you haven't used view modes in Drupal 8, view modes are now something that you can create yourself so you can have all kinds of different view modes that you've configured. And one of the big benefits of view modes is that you can use them in different contexts. So we can print out nodes using a view mode in views. That's usually how I think people think of them. But you can also use that same interface in the manage fields display interface. So if you're referencing a page and you wanna display the page as a teaser, you can use that teaser view mode when you're displaying that reference field. So it's definitely a more consistent approach than using specific fields within the view. You can also use the tools like the field layout tools for configuring the layout of a teaser. So this teaser that I showed doesn't really have a layout but if it did, you could use that tool. And then you can also customize a template file for that view mode. So you have more kind of theming tools at your disposal and also more configuration tools. So it's a bit of a more flexible approach. On the other hand with fields, you get fine grained control in your view of each field. So each field is gonna have this little, basically a little twig template that you can modify in configuration. So you might feel like immediately you have more control using the fields approach. Okay, so we feel like we're almost done. We're scrolling down to the bottom of the page now and in the design, we see that there's this footer, kind of this big footer with all these places that blocks can go. So at first we think of this as being like one region, one part of the site, but then we think well, there's different columns in the footer and then there's this part at the top and this part at the bottom where there's blocks being printed out. So we're wondering how we should implement this. So there's kind of two ways we can think of this. We could do this using configuration. We could create a region for every part of the layout. So for every part of the footer, we could have like a footer left and right and top and bottom and have all kinds of footer regions, just like Bartik has, right? So we could do that and then we can assign the blocks to the region to get the layout we want and maybe we'll end up with just one block per region, which might seem like we did a little bit too much work adding all those regions if there's just one block in each one. On the other hand, we could use CSS so that the blocks in the region appear in the separate columns and in the layout that we want. So we could just select each block and make it appear exactly where we want and we figure the blocks in the footer aren't gonna change that often anyway. So with the configuration approach, it's gonna be way easier for site admins to understand and update the block placement. So this means if somebody wants to add something else to that footer, maybe at the very bottom or maybe on the right side, they'll be able to do that. They don't have to call you, they don't have to bother you, you don't have to change anything on the theme. On the other hand, with a theming approach, it might be easier to kind of adjust the layout without having to create any new regions. So if you do expect the layout to change, maybe it's not really confirmed yet, maybe it's gonna be easier to update that if you don't have to go around adding all kinds of new regions for every update. So either of those approaches is going to work. Okay, so you're almost done with the site, you feel like you've gone through everything but there's a couple other special components that you forgot. So you've implemented this web form but there's some special fields in the web form. So you've probably come across this before with the styling of forms where there's some components in the form that are displayed in a layout. Has anyone had to do this? It's like, oh yeah, there's gonna be these options and they're just gonna sit nicely next to each other. Until of course someone else comes along and adds some extra fields to the web form or adds some extra options to the subject of this email and then the whole layout's gonna break. So with web form styling, how many of you have used web form in Drupal 8? Oh yeah, it's super cool, eh? Yeah, everyone's excited? You're a very quiet group. I mean, for me web form was one of the most exciting things when the module, when I first used it for Drupal 8. So one of the things that it has is the ability to add a lot of configuration. So you can actually put a lot of your styling right into the web form. You can also add classes. And so it's super flexible in terms of what you can do just through the UI. And so on one side you might say, oh, I'm just gonna put all the styling for this web form, everything for that layout into the web form config. On the other hand, you might decide that you wanna apply a class in the web form config and then put all that CSS into your theme. So with the first option, it's gonna be easier to adjust the styling if somebody comes along and wants to add another option. And so that CSS little tweak has to change. It's gonna be easier to do that through config, especially if you're trading web forms kind of as content. And this is something that we come across in Drupal 8 where we have to come to terms with the fact that some things on our site are content and some of them are configuration. And some of them are sort of like they're technically configuration but we treat them as content. So something like placing a block, that's configuration. But maybe that's something that we're doing all the time on the live site. So it kind of has to be managed more like content. And web forms kind of fall into this gray zone as well where you're adding them on the site. Maybe people are adding them all the time, so you're kind of treating them like content but they're part of configuration. So on the theming side, the nice way to do this would be to apply some kind of class or a set of classes to your web form and then in your theme in the CSS, you can implement the styling and that way all your CSS is in one place. And for some people that's like obligatory. Like there's no putting CSS into configuration here. We're always going to put CSS into our theme. It's gonna be SAS, we're gonna compile it, it's gonna be great. So you kind of have these two approaches that have different advantages there. Okay, so you're almost ready like you were about to deliver your site with a theme and the site building all done. And then you notice that you missed a layer in the mock-up, like in the mock-up file, you forgot to turn on this layer and you discover that this website has a mega menu. Oh my goodness. Who here loves the mega menu? I think this is beautiful. This is the Art Gallery of Ontario website, it's really nice looking I think. And so you come across this mega menu and you think how am I gonna do this? So the first thing you think of is just Google like okay, Drupal 8 mega menu, right? Not your head, I mean come on, that's the first thing you're gonna do, you're gonna Google it. How am I gonna implement this mega menu? So you find a couple modules you can use or you think well if I'm really being creative maybe I can create a template file for the different sub-menus in this menu and maybe I can use that to insert extra components. So these links on the right, book ticket search, maybe you can just put those into the actual template file for the sub-menu. So you can figure out with Drupal 8 theming, I mean the templates for the menus are so much easier to use in Drupal 8 so you've got your twig debug out and you're gonna be able to figure out in no time how to do this with templates. And so the module approach is for sure gonna be more flexible because any mega menu module is gonna allow you to configure what extra components are displayed under each menu item. And actually in Drupal 8 because menu items are their own entities, a module should easily be able to extend that and add new fields, new data into the menu system. On the other hand, if you implement it yourself and you do everything yourself with templates and everything, you're gonna have more control probably over the CSS and you don't have to worry about JavaScript being added or markup being added that you don't like. So you get more control on the theming side. And kind of as a middle ground, there's also a module just pointed out called simple mega menu that sets up the data for the menu as part of the module so you can configure what is displayed where but then it gives you tools in your template files to display things how you want. So it doesn't just assume where you wanna print out the extra stuff you have under your menu. So it kind of seems like the best of both worlds. I have not tried this module yet but it seems like a good middle ground. So you finish the site, you feel happy about all the decisions you made and then you're reflecting back and you're thinking, oh, this is really interesting, this whole notion of having my theme and having my configuration and you're feeling very philosophical. And one thing that is interesting about Drupal 8 is that we have configuration management. So everyone here is using configuration management or like you went to a session this week and you're all set to try it, right? So configuration management means that you have your theme, which we have always thought of as code where you have template files and you have your preprocess functions and your CSS. So that's really traditional code. And then on the other hand, you have all this configuration you do when you're doing site building. So you're configuring views and content types all over the place, you're setting up modules. And so traditionally we thought of this as being maybe a more fragile thing where, oh, I added this view but what's gonna happen if that twig configuration in my view gets messed up? It's gonna ruin the site. But now that we have configuration management, all that configuration we're doing is also being managed as code. So every time you're going through one of these components and implementing it, you're maybe doing some theming, you're maybe doing some site building and then you're exporting your configuration and you're committing it all. So you don't have to feel quite as anxious about your configuration being wiped away. So they're both kind of managed in the same way and we can almost think of our configuration as being code. So I see less of a downside in putting things into configuration in Drupal 8 because of this. And also most front end tasks involve doing both. So you're never gonna say, oh, I'm just gonna have a theme that does everything. Like have you ever had someone come to you and say, oh, I'm building this site and I just need help with the theming? Could you just build me a theme? Has anyone had this happen to them? Yeah, just build me a theme and I can do the rest. So it doesn't really work that way, right? Like even though we kind of try and separate out like content and styling and everything, it's still, there's a lot of interplay between theming and configuration and so you're always gonna have to do both. So I really encourage you as you do your projects to reflect on your priorities, to reflect on who's gonna be managing the project, where the front end look and feel is going and how flexible it needs to be. Thinking about your colleagues and how they're going to see what you've done if they're gonna understand it. And then just making sure that things, to keep things simple, but to make sure that things work at the right level of specificity. So just, you can keep these elements in mind. And the thing is that these are gonna change for every project. So you do have to think about this kind of a fresh every time you start a new site. So that's all I had in terms of presentation. A few notes. So there are code sprints tomorrow and how many of you have never been to a code sprint before? Oh wow, so you're gonna have a lot of fun because the DrupalCon code sprints, they have a lot of help for people who have never contributed before and it's very welcoming environment. So I really encourage you to go if you can. And also there's feedback you can give on all these sessions. So like your homework after DrupalCon, just like take 10 minutes and fill out some of these things on the DrupalCon website. You can review all these sessions. And there's also training that I do. So if you're all interested in that, you can stick around and talk to me or just send me an email. So I hope some people have questions or opinions or people are gonna like say, ah, you shouldn't do that with adding CSS to configuration. So I hope you have questions. So please, please line up and give me your thoughts. It's not lunchtime yet. It's only 11.30. We have 15 whole minutes. You're all like the donkey in front of the piles of hay, like what are we gonna choose? Curious about when you choose to let the client or the end user add classes or change colors with a field? For instance, where you say there are different stylings, do you upfront decide which permissions you give to the client? Oh, yeah. Because sometimes the client calls from the same company from that block changed. And it's really hard to track down who changed it or something. Yeah, yeah. So I mean, if something's a field, right? If you had, I mean, I wouldn't say have a color picker as a field. I don't think I would ever wanna do that. But if you wanted to just have a couple options, it's a little bit less scary. But yeah, I would say you could add permissions to those fields just like you would for any other fields. So you could use field permissions or you could do that with, just with a form alter, you can change who can edit what permissions pretty easily. So it depends on how flexible that needs to be. And is that something that you would discuss upfront a project? Do you have any experience with that? Yeah, I mean, on most projects, people think that there's going to be more people editing landing pages. So I would, if somebody started saying, oh, there's gonna be some people who can edit this component and other people who don't have permission, like I would kind of question that and try and maybe simplify it because usually it's just a couple people on a site actually editing this type of marketing material. But it's definitely something I would ask upfront would be like, how flexible does this interface need to be and who's gonna be doing the editing? Because that would determine how easy it needs to be to use and what the interface is gonna look like. Thanks. So one of the issues that we come up against when using sort of the configuration method for setting things up would be if we have multiple environments. So if we've got a dev staging and live environment having to repeat ourselves in doing the configuration, do you have any tips on how to handle that? Are there any useful tools that you use? Oh yeah, absolutely. So like I mentioned with configuration management that does become easier, but you have to be fairly disciplined about doing like exporting your configuration as you're building each component. So if somebody's working on a view and a content type and a view mode then they're gonna be exporting all of that once they've done the work and maybe the theming as well. So all of that gets committed. And then of course people have to be doing config imports on a regular basis so they don't get out of date. And typically that process works pretty well, especially if people are assigned different parts of the configuration if they're not all trying to edit the same view. So that might determine how you're, like if you have a lot of people collaborating on the project, it might determine how you break down the configuration a bit. And then the other thing is you do occasionally have configuration dependency issues. So if somebody goes and adds a field to, like adds the body field that's defined as part of the article content type, like the base field is defined there and then it's applied to other content types. And then some other colleague goes and says, oh we don't actually need the article content type, we're going to delete it. Like that's where you get kind of conflicts. But I'd say as long as there's good communication, like if everyone on the team knows you're deleting the article content type then they should be able to figure that out and avoid the problem. So just good communication. And sometimes like in the past, if things have become kind of hairy, I set up like issues in our issue queue for configuration components and for something maybe that you're more concerned about and then you don't work on that part of configuration unless that issue is assigned to you. But that's kind of a more... Okay, thank you. Yeah. Hi Suzanne, thanks for a great session. I have a quick question. On a D8 site I was working on recently, we were using both view modes and a lot of twig templates. So we had field twig templates and blocks and nodes and because we had view modes, we had view mode templates and our .theme file ended up getting very long with a lot of pre-process functions for all of these specific templates. So I was wondering if you had any insight or suggestions into managing that because that .theme file was kind of... Yeah, really unmanageable. There's a great page on Drupal.org that talks a bit about best practices for pre-process functions and templates, like kind of what should go where. Because in Drupal 8 you can do a lot in template files and so there's a lot of things that in Drupal 7 we would have done in probably a pre-process function that now because we have all these filters in twig we can do easily in template files. So you could read through that and maybe see if there's some places that would be better suited to doing something in a template file. And otherwise it's hard to know without looking at the .theme file. I guess you can look for just places where you're repeating the same pattern. If there's pre-process functions where you're doing the same thing multiple times. And on the template side, if you find you have a lot of templates and you're doing the same thing in multiple templates, remember that you can always create template suggestions. So you could have multiple content types that use the same node template, for example. So if you really have, like if you keep copying and pasting the same template file, just because you're trying to do the same thing by multiple parts of Drupal, those template suggestions might help manage that complexity. Thank you. Hi, I've just a short follow-up for one of the previous questions. So if you use configuration and export and import it, make sure you do this on one system and don't create the field on multiple systems because they get different UUIDs and then you use the field values. It really gets messy. Thank you, yeah. And a small question. Have you used the field group module? Yes. Because we found it quite useful. Is it allows to create wrappers if you just need to put a few fields together without needing to write a template or... Yeah, absolutely. So on that section where I was talking about theme or how to manage the field output of specific elements, I should edit this slide to talk about field groups. That's a great suggestion. Anything else? So feel free to come talk to me. I'll be around over lunch and everything and I'd love to talk more about this. Thank you so much for coming and enjoy the rest of your DrupalCon.