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.  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.  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?  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 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.  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?  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?  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?  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.  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.  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 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.


I just made a $20,697 mistake. If you haven't already watched my video on emergency funds and why they're important, well then I suggest that you watch it now as I am very clearly more than ever putting it to use. When I was let go from Chromatic, I was offered two months severance. Now, severance is kind of an interesting topic because it is nice to get it and it is nice when you receive it, but they're not really given benevolently. They're basically like an insurance settlement to keep you from being able to sue the company for wrongful termination if you should decide to.  When you join a company, you'll probably fill out some kind of W-4 form that's might be integrated into the software that they're using, but basically this is a form that allows the company to withhold taxes for you. In the US, the IRS has a tax estimator that you can use to estimate how much tax you want withheld. It's always on how you plan to file, what deductions that you think you can take. If you plan on making extra money, you might want to withhold more. I usually set mine high because I make little pockets of extra money throughout the year and it's easier for me to not have to think about it that much. However, a time that you're absolutely supposed to be thinking about changing your tax with holding are for life events. Right here, life events on the form and one of them is for a new career or joblessness. Now, clearly I made the mistake of not adjusting it and if I'm doing my math right, that mistake cost me $20,600 and 97 cents. Now, I'm not in the business of making recommendations but I can tell you what I wish I would have done. I wish that first thing I would have contacted my HR representative and asked for the form that allows me to legally change my withholding. I know that in the past, I had control over that in ADP. In gusto, it looks like there wasn't a form for that inside of the UI. So your mileage is gonna change dramatically on this but is your HR representative's job to make sure that you get the right form and that it is tracked and put in the right place before you get money. So take advantage of that. Now, I don't wanna cross into financial advice by telling you what you should set that to. For me, I tried to set that as low as possible, especially since this happened in the first month or so of the year. I have a whole year to figure out what my tax situation is gonna look like and I'd like to have that money now or it can be the most useful to me. Reasonably, you may assume that the percentage of what's withheld will be similar to your paycheck. However, this is not the case. It seems almost like the assumption from whatever underlying system is used is that now for the rest of the year, I'm going to be making five pay periods in one pay period and so we should withdraw however much that would be for the whole year and that's just not the case. Now, I haven't lost this money per se, like it's not gone, but it is locked away from me. I can't just like go to the IRS and ask for some of it back. Anyway, that's it.  If you wanna watch my video on emergency funds and how I'm able to not stress out about that too much, it's right here. Hopefully you find yourself better prepared for this situation than me. See ya.


Hello everybody, thank you all for coming to see our talk today. I think there was a miscommunication This is where we talk about the mean comments. You're not going to throw them at us Okay No, really thanks so much for joining us today. I hope this week has been as much fun for you as it has for me so far Hi, my nickname is dims. I work with Tim in the communities community. So There was this thing that I started a while ago and that turned it into this talk So let's see what we have in store for you About a year and a half ago dims and I started Sending each other our favorite comments from various forums You know as sort of a wait event to each other We've we've both often spoken about Kubernetes and how awesome our community is And I can hear you all now saying oh, no, it's another big community hugfest.  You're passionate and you are creative emphasis on passionate Every week we hear about somebody who's doing something with Kubernetes that we never would have thought about That we never could have predicted that we don't really understand Which often means that those people find bugs or corner cases or things that we didn't plan for or design for The reality is nobody uses every feature, but every feature is used by somebody in fact Many of the bugs in Kubernetes have come to be relied upon has anybody heard of Hiram's law It's a it's a little saying that says basically Every observable aspect of your system will eventually become part of your API.  Thank you. Thank you. Thank you. How many people here have submitted an issue against Kubernetes? That's a lot more. That's even more And how many of you hit a bug and went? Effing Kubernetes So, you know huge amount of the work that we do day-to-day is not just adding features or fixing bugs So please trust us when we say we hate those bugs as much as you There is nothing There is no feeling like when you do something and it just works right but when it doesn't it can be incredibly Frustrating and hopefully you all file the bug so that we can help to understand the problems But sometimes you file a bug and you don't get the answer you wanted which can result in what my kids would call big feel big feelings Sometimes we get rather strong passionate interactions on our issues and PRs and social media. So I Want to remind everybody here that everybody who's working on Kubernetes to build and maintain the system our volunteers Some of us have been around a long time and have developed a thick skin But some of us have not and they just want to help people to be successful and to participate Behind all those github avatars are people We really really want to help you fix those bugs, but we need your help So when it comes to engaging the project and the volunteers behind it There are let's say more effective and less effective ways to engage So we thought today we would talk about how to engage effectively Illustrated by counter examples So Let's see the usual scenarios usual scenarios for friction, right? so You are running something in production.  Two years ago somebody else had the same problem, right? Then the question is like Why right? So Some of this Somebody do something It might look simple, but it might it's probably not simple We have a large user base You know, we are probably gonna break somebody Hiram's law going back to Hiram's law We can't always Accept like a quick dirty hack to do stuff like we are still recovering from things with it 10 years ago We are trying to unwind those things so Even if it is technically simple Sometimes we are not able to do it because of some other reasons We do try to write things down. There is a lot of discussions in Slack channels and in meetings sig meetings and things like that Sometimes we are not able to reflect that back in the github issue that you're looking at but I promise you We've definitely gone through some of these before Sorry about that that we didn't reflect it back where you're looking and not finding the answer that you need So many years of past It's easy to ask a question, you know, it's definitely harder to come up with a solution now Look at the phrasing itself right like they Right like who is they it's all us right like there is no day here. We are all a community We all have to do this together. We are all in the same boat, you know If production fails for somebody it's gonna fail for somebody else too. So, you know, we do have a really good thing called the Cubinators enhancements process Please search for it and take a look and see how we can, you know, make it easier better for you all The next one is We have bots when you come to cubinators We have a lot of bots and they bought contract with you because we are not able to go talk to everybody For every issue all the time, right? So some of the bots go around like cleaning up old issues and like there's no comments from people for a very long time And like why is a bot closing my issue, right? So sometimes it is more about Hey, it's not in our backlog, but it is there as an issue So there is a difference between a backlog where okay, we are probably gonna work on it at some point But you know There is issues like this there are we also have issues from Vendor issues and things like that too But mostly cubinators cubinators is for Development of cubinators itself. So please be cognizant of that and use other support channels when you can So we get these all the time the easy response here is PRs are welcome But that's a little dismissive the deeper responses. Sometimes it's hard few of us on the project are a hundred percent Doing this project. We all have Carved out as much time as we can but most of us have other commitments professional and family real life We may not be able to get to as many things as we'd like to Dims mentioned the KEP process the enhancement proposal process. This is how we can move an idea forward But it's not as daunting as it might sound if you have an idea a proposal You can write a simple doc Google doc and share it around with your SIG or the SIG that owns that problem area It's a great way to get feedback or use the mailing lists and slack to collect feedback and help Understand why an issue is important and why a solution is appropriate One of the primary reasons why open source is so powerful is because people can scratch their own itch Right, they can do their own solve their own problems do their own work Convert energy into action Don't just harvest but invest We need to keep this project vibrant over time. We're here at the 10-year anniversary Let's all pat ourselves on the back and then what is the next 10 years mean for us? I love this one Reminder every flag we add Approximately doubles the amount of testing we have to do we have hundreds of flags We can't just add a flag and run away Last year we spent about four million dollars on Continuous testing and binary serving four million dollars and that number is only going up every year month over month. It goes up When you get that waiting for tests or Have to run slash retest because something flaked. That's a bad thing right that costs real money So please don't mistake your convenience with our convenience So If you have a workaround Just make sure that as many people know about it right like so go to the issue and say hey I found you know, not just you found the issue, but also I found a solution Here is how you do it. Here is a workaround here is something that will tide you over until there is a better fix that is available We have a lot of extensions in Kubernetes, right? You know document your solutions share them widely and if you Want to go a little bit further than you can say hey do a prototype file a PRC which Issue which tests pass or which tissue the test fail, right? So that is another way you can help us right like we don't know like we started started by saying We don't know all the things awesome things that you all do, right? So we don't so it it will only help us if we know more about the scenarios adding more test cases More in adding more integration tests You know there's a backside bad side to it too because it raises our cost, but we would rather have it than not have it Okay How's this one?  Yes Okay, at least a few people so I mean you can't appeal to shame, right? Saying real world and things like that, right? So not everything is built into Kubernetes itself, right? That's for a reason How much code can we add into the core Kubernetes? That's why we have extensions. That's why The the sick architecture and all the six work together to make sure that there are enough extension mechanisms for For you all to do the things that you do that you want to do, right? And that is the reason why you are all here. We built up a really good big Ecosystem around this But if you really need something which is not there, we'll figure out a way to work with you on it, right? Just please, you know, we don't want to say no to everything all the time either, right? Once we understand your scenarios once you engage with us a little bit more Then we'll get to know more about your scenarios and then we'll work with you on those things Extensibility has to be definitely number one or our agenda, you know for the foreseeable future So I'll let you read this for a second I think the biggest thing here is like Just resetting this one number in one place. Do you think it's really hard? Right That's a question and the number of times that programmatic Complexity has stopped us from doing something, you know is zero We're not afraid of writing more code, but When we are saying that we can't do something there are some really deep technical reasons for not doing something We do want to fix your problem, but not everything can be fixed. We have to make some hard calls We have to figure out like what can't change right now. It doesn't mean that they can't change forever, right? Like we'll find a better way somebody else will come up with a better way to do it sometime later But it's not the right time to make the change, you know, we might break somebody or you know some other scenarios might break and But this is not the way you should engage in a open-source project to try to change the mind of some of the maintainers You know the the worst part about this one is that up the thread several maintainers had responded but But but OP just didn't like the answers Like please don't go shopping for approvals, right? We we kind of talk to each other We know when this is happening and it doesn't work, right? We have an approval process We have a consensus building process within the community and you know, you're part of the community But you're not allowed to yell at us. That's not okay. We do have a code of conduct We do use it more than occasionally And if you're not respectful, you won't be able to engage with us. We want you here, but let's keep it kind, please I Like this one really they had me in the first half, right? I can understand that you're all loaded awesome rate commiseration right empathy That that acknowledgement is nice, but if it's really a big issue I imagine it's affecting a large number of people. Where are those other people? Can we have a conversation that talks about the magnitude of a problem, right? I like this one Tim's pulled this quote out from from me. So I feel weird quoting myself here, but there's always a cost I've had to post this message many times. There's always a cost I know it seems like something should be cheap and easy, but there's always a cost It might not be paid by you But it does exist and remember that you know open source is made of people and people's time is how we feed it Here is another one right like it feels like you're yelling into the void Nobody is listening to you right like you go there and like you go look at your guitar issue Day after day and like nothing is happening. Nobody is acknowledging and like you're screaming to the wind But the thing here is like we can't go watch all the 2000 issues well 2000 plus Until the bot starts closing stuff The reason is we do have a release cadence you you all know how many times we release in a year How many Three three times okay three times a year what that means is we have a calendar So we have a feature fees we have a code freeze and then we have a test freeze and then we make Release candidates and things like that right so we can't be paying attention to the incoming issues Incoming PRs all the time right so there is a cadence in the community. There is a rhythm in the community There is you know, for example, when we are fixing deep flakes And like making sure that all the jobs are green before making the release We might not have time to go look at a big PR that you just logged right or a cap that you just wrote so if you understand the rhythm of the community then it becomes easier for you to participate and then The karma that you get out of like understanding the process and understanding the what the people are doing and when Will help you make friends and you know, it'll make it easier for you in the long run so The other thing here is like you can ask again So if you don't you can escalate right like you if it doesn't work on GitHub issue If you're not hearing anything from people come to slack, right? We have a mailing list All the six have the same pattern. They have a slack. They have mailing lists come to our meetings We have you know meeting notes throw it on our agenda, you know, make the case Right and be vocal about what and when you bring with you data, right? Like in the end, it's the engagement that we are looking for from you, right? So we know what you want so we can do the right things for you and not guess what you want us to do Right, so you are all part of the Kubernetes team So you're part of the solution essentially And it's not just Kubernetes like all our sister projects face these things to right like Look at this one from for the hell maintenance. What are we exactly accusing people of being busy? right Does it help right and literally I write at the beginning it says it's a plea for help right and the person is Escalating essentially So usually we are our own harshest critics, right? We look at what we've built and we see all the problems and and it coming to cube con is wonderful because I hear people say good things for once But when I look at Kubernetes, I just see a pile of two thousand plus bugs plus the two thousand that got closed by the bot and But sometimes we are pretty nice to ourselves by comparison There's not a whole lot of room for interpretation on this one And to be fair Nobody's really in charge right so you can throw the blame at Google if you like but not really our fault and people do and they do And that's okay We have community governance We have a process that ensures that other points of views are considered and that we build consensus around our decisions and our designs Right, so I don't know what value you get out of posting this in a public forum, but okay This is another fun one. I'm not sure that a raspberry pi is the right yardstick to be measuring Kubernetes I mean I Like that raspberry pi runs kubernetes, but it's not part of our test suite Do we have bugs oh maybe you should sure somebody wants to donate a million dollars worth of raspberry pies we'll be happy to We have bugs yes, do we have terrible code? Yes, I probably wrote it. Sorry But I don't know what you expect here like 11 nines And as far as bug reports go here's one Somewhat lacking in detail Does anybody know what this is really about Can anybody guess what this is about? Good bug reports are worth their weight in gold right good bug report is focused It tells us what happened where and when on what version what symptoms do you see what? Platforms where you're running it against don't just open a bug to vent, please All right Kubernetes has escaped the lab. I'm sorry to tell you all If you hate it, that's perfectly fine. Well, there is also I did want to say this other thing Also, we are not actually using tweets which you can see meme and meme net us and other other things on Twitter We're just using the things that you know hurt us more because you are here You're part of the community and you are engaging with us You know, that's why it hurts more you see So as but on a different note as long as people are complaining about it. We know they are using it, right? That's ever Tell me more It's again, it's not given it is that gets beat up It's Your classic send patches But in truth the only code bases that are not a mess is that doesn't have any users back here So not every bug is about the code. Sometimes the bugs are about the way the project operates to Perhaps we should open an issue tracker that lets you file bugs against people I'm pretty sure I need a bot to close mine But again, I Don't know what the expected outcome here was like do people really think that we enjoy that? Or enjoy that we are going out of our way to prioritize flagellating people A little empathy goes a long way, you know, here's a place where The commenters sort of working against their own goals. I'm a good man They acknowledge the reason for the decision good But rather than arguing why those reasons are incorrect. They impugn our intentions, right? We're doing this on purpose because we enjoy hurting you Nobody's trying to make you look crazy. You're doing that on your own This one I liked it's a little bit long is fairly polite in its wording But it clearly comes from a place of frustration The highlighted text caps exist primarily to prevent improvements from being made without sufficiently flagellating the people who dared to be so brazen as to ask for that improvement Like I like it. I would read a book that this person wrote But you know we said earlier it seems simple, but it's really not I know it feels like caps are there to slow you down and to throw roadblocks in your way I get that but kubernetes is not a toy anymore Right look around kubecon and see all the things people are doing with it A lot of companies and people and livelihoods depend on us not screwing up And now even lives depend on it as kubernetes makes its way into really truly mission critical I'm not talking about your web store went down. I'm talking about people died Caps are how we communicate. That's how we share ideas and how we get feedback on them You know, of course, it's a process every process could be improved and and processes are there to serve people not vice versa But let's hear constructive criticism And for what it's worth we all follow the rules I have to write caps dims has to write caps and it's a living document So we continue to iterate over it as as things progress and I look around I see lots of kubernetes community people here You all have to write caps too. I know, you know, it's not like we're beating people up just because they're outside This one is one of my all-time favorites Oh, it's a little tight to read We have a cap which is the vehicle for discussing the policy design blah blah blah You forwarded me to a cap. I posted comments, but nothing happens. You forwarded me to dev null Someone else's kept PR that should cover this You all don't do anything to address the feedback drawbacks on top. You come here and close my issue I want this issue to be open as umbrella blah blah blah. If you close this issue one more time, I will report you So Believe it or not, it's okay to disagree with closing an issue and go ahead and reopen it. Please tell me why This maybe is taking things a bit too far Okay, so having endured all this and you know, thanks for being a sport and you know Listening to us. So let's do the pull out opposite If you don't like a decision ask about it. We talked about this a little bit Earlier too if you're not getting an answer again, ask about it And then lastly People go out of their way to just to say thank you I mean, we're not asking all of you to go around opening issues Saying thanks, but we'll be you know When it happens organically, it does make us feel better Uh The kind folks, you know, you run kind clusters on all your laptops So they were so happy when they saw this right like it was totally unexpected out of the blue and they were The really good people does anyone in the room use kind There you go That was almost everybody. Can can we just have a quick round of applause for the kind maintainers Antonio Get up stand up. Thank you Find him up after the talk and give him a pat on the back um, so To end on the kind note be kind please. Thank you We'll be happy to take questions or more insults if you'd like And thank you to everybody who uses kubernetes and files wonderful bugs for us because that's how We know what we did wrong