 So today, I'll be talking about creating a lean mean Drupal 8 theme. I don't have all the answers to your theming problems, so if you're here expecting a magic solution, this room seems really crowded, but I'm going to do my best to share my approach for Drupal theming. Just as an introduction, my name is Suzanne Dargacheva. I work at Evolving Web in Montreal, and I'm a Drupal themeer, as well as a trainer, and I do some development, and I run a Drupal shop, so I wear a lot of hats. And at Evolving Web, we work for a lot of different types of clients, so we've worked for the Linux Foundation, McGill University, some other Canadian universities, and some enterprise organizations. And we run a Drupal 8 training program, so if you're trying to learn Drupal 8 and weren't able to learn enough at DrupalCon, you can get in touch with us about training. So today, I'm going to be talking about Drupal 8 theming. This applies largely to Drupal 7 theming, as well. And this all comes from my experience doing theming, so I've been working on Drupal sites for probably the last seven years, and I have a lot of experience with Drupal themes, and at some point you think you've seen everything. You've seen lots of different sites with lots of different use cases and requirements and maybe 50 different Drupal themes that you know intimately. But in the last couple years, I've come across some Drupal themes that really surprised me, that did things in a way that I was really shocked by. You know, themes with hundreds of templates and loads of CSS files and just a lot of code in the template.php file. And so you can always learn something new. And a couple of the themes that I was looking at just had so many template files and so much code. And they were using SAS and less and CSS all in the same site. And don't even get me started on the amount of DB calls that I've seen in theme code in the last couple of years. And even though Drupal 7 theming's been around for a while and you know, you kind of think, okay, people kind of know how to do this. I've seen some patterns that were really surprising me. So a couple of the themes that I looked at were themes that we were inheriting from other developers. So these are themes that maybe were written by first-time, first-time themers. And the amount of code was really shocking. But then when I started looking at the configuration, there was also a lot to go through. So it would take maybe days to wade through the views and the panels and the view modes and map it all together with the theme. And so I started to see this as a pattern amongst some sites. And it really made me question, what is our approach to theming? Like what are actually the best practices for Drupal theming? And this is what leads me to this talk today. So now that Drupal 8 is out and we're working on sites using Drupal 8 theming. And maybe some of us are working on upgrades. It's a really good chance for us to reassess how we do theming and to maybe look for a more minimalist approach to how we do things. And this approach is probably going to be different for everyone. So this session today, I'm not going to be giving you a clear solution to how to make Drupal 8 themes. I know Morton did a talk yesterday on what was it called again? How Drupal 8 themes, how do we do this? And so I like him, I don't have an exact approach that I'm going to tell you, but basically I'm just going to be discussing some ideas in the approach that I use and give you some food for thought. And there are some clear do's and don'ts that I have, but basically the approach is pretty flexible. So I'm going to be talking about why Drupal 8 themes are complex to begin with or why Drupal themes in general are complex. Where does this complexity come from? I'm going to be looking through our tool set as themers and going through best practices for using that tool set. And then I'm going to talk about limiting the complexity just by following some basic guidelines. So no matter what approach you're using, these are some things that you can adopt into your theming process. So first off, where does the complexity come from? I think it comes from a lot of places, but three main things. First of all, Drupal theming is really flexible. So that allows us to create something really complex. Secondly, we have a lot of configuration that integrates with the theme. So there's a lot of dependencies back and forth there. And finally, we also are as themers implementing a design. And so sometimes that complexity just we inherit from the design process. So the design process is really messy and then of course the theme is this bohemian thing. I had a client once who asked me to make a theme that looked like an art deco building. It was a few years ago. I didn't have the courage to say no, so I tried to implement that. Another time, also several years ago, I was implementing a site that basically had been designed for flash. So it was a fixed height and it had all these characteristics that were kind of flash like. And again, I didn't really have the courage to say no. I said, yeah, of course Drupal can do that. And I think as themers, we often want to say that. We want to say, of course, Drupal can do this. Like it's Drupal, it's so flexible. And so when we get handed a design, sometimes we see the need to do things with our theme. So you might get given a design that has a lot of different layouts. And we think, oh, can we do this in Drupal? Well, of course, we have templates that we can use to override the markup. And if we don't have enough templates in Drupal Core that we can override, we can start using template suggestions. And then if that's not enough, we can actually add additional template suggestions in our theme so we can add even more templates. And this is how you wind up getting a theme with hundreds of templates. And I think this is a list of all the templates. I know it's really tiny because I had to zoom out really far so you could see them all. But these are all the templates that are used for a theme that I was recently working on. And that's not even all the templates. You have to open up the Views folder there. At the beginning, there's a whole slew of Views templates as well. And Drupal complains when you have modules on your site that are out of date, right? You get a little error message to tell you your modules are out of date. But there's no error message that pops up when you've added 200 templates to your theme. Maybe there should be, I don't know. We also, often as themeers, get asked to implement different display logics, right? So you'll be implementing a website for a university and you have program pages. And you're supposed to embed all the course information on the program page. And you say, yeah, of course we can do this in the theme, we have preprocess functions. And you can also use these to insert icons or embed a node queue or embed a view. Or maybe you want to embed a view inside another view. And you say, yeah, of course we can do this. We're Drupal themeers. We can do anything. We have preprocess functions. So you start adding thousands and thousands of lines of code in your preprocess functions because the Drupal theme system is really flexible. Some sites you might work on have a really clear design process where you start off with a nice style guide and you have all these general style characteristics that you implement. And it's a really organized design process. But sometimes you're working with a design that's put together that's very specific. So you might be implementing basically a brochure as a website. And sometimes this is obvious for a really tiny website. But even for larger websites, sometimes we'll end up with pages and pages of mock-ups that are really specific. And it's hard as a themeer to know kind of at what level we're doing our theming. Are we theming the HTML on the page or are we theming the HTML on this specific page with this specific set of content? And so sometimes when we get designs that are really specific, like over here I have some samples, a corporate website with a lot of really specific marketing material, a tourist brochure for Tourism Quebec, and a comic book website that's designed to be like a comic book. And in these cases we might end up writing tons of CSS and JavaScript. And even if we're using SAS and we think we're all being modern like, oh, SAS, we're still writing loads of more CSS than we really should be. And so here's some samples of SAS from a theme that I was working on. And the reason it's so specific is that it's controlling for the height of some of the elements on the page. It's controlling for really specific blocks that are displaying, you know, quick tabs, and inside the quick tabs you have views. And it's not just trying to control the display of quick tabs and blocks in general, it's really going for these specific cases on these specific pages. So if all we had in our toolkit as themeers was the theme, I think things wouldn't be so bad. You know, there's a lot of complexity in the code, but we can deal with it. It's all in code. But Drupal, of course, doesn't work like that. We have all kinds of modules that we can use. And sometimes we use modules to control the layout and the display of our content. And that's because sometimes we don't want to hard code everything in the theme, right? We want to make things flexible. We want to let site builders come and extend the site. Sometimes we use modules because it's faster than putting everything in the theme, you know? Using panels, it helps you quickly prototype new landing pages. And sometimes we just think of new modules cool, and we want to use it because it's there, and why wouldn't you use it? But using modules to control the display and layout of your pages can add to the complexity. And then you end up with dependencies between your configuration and your theme. So a lot of the times when you're building a site, you have the option to integrate something in the theme or to use configuration. So for example, if you're trying to add a byline to a blog page just below the page title, you could do this just in your theme. You could add a variable to the block template and then print it out in the template, define it in your .theme file or in your template .php file. Or you could create a view. So you could create a view that displays the page title and the byline and print that out at the top of every page. So in a lot of cases you have this option. Do you use a view or do you just do it in the theme? Sometimes you need to group fields together, right? You'll have a site like this where you're displaying an event and you need to list a bunch of dates and maybe some locations. And you could group these together just using a template file. Or you could do it purely in configuration using field collections. So again, you have this choice. You might do it one way. Another themeer might do it another. And even on a single site you might have some cases where you're using field collections and some cases when you're not. One thing we often have to do in the theme is to display content in various ways throughout the site. And so a really good method of doing this is using view modes, right? So you think, OK, great. There's a method for this in Drupal. We have view modes. But you could do it using view modes and you could change the display of the content just using a template. Or you could use views to do this and you could configure the display, the fields, in the view. Or you could just purely use view modes and customize the display of the fields using the manage display tab. So even just for something that seems simple, we have these three options for either using theming or using configuration or using a combination of the two. Often in our themes we want to display different types of layouts. And some themers will do this just in the theme. They'll set up their regions and configure the blocks or allow a site builder to configure the blocks. But sometimes we decide we want to use something like panels or display suite and be able to more quickly configure these types of changes. So on top of our theme we have all this configuration that adds a layer of complexity. And if that wasn't enough, so that's kind of two things we're managing. And then we have designers or the design process. Is anyone here a designer? Yeah, awesome. Designers who know Drupal. This is great. Not all designers know Drupal. Not all designers know content management systems. And not all designers take into account the need for consistency in content architecture. And so sometimes you run into a design process that makes the theme more complex. So how does it do that? So first of all, we have designers who are very good at creating variations of things. If you're using a wire framing tool or Photoshop or Illustrator, it's really easy to copy paste and just create a bunch of landing pages that are all very distinct. So a more concrete example in the slides here. A designer could create many different variations of buttons on your site for no particular reason. And this actually comes from evolvingweb.ca, from our simple corporate website. It's not a very complicated website, and yet for some reason there's this many variations of button styles. So you can just imagine how many button styles you're going to end up with on a larger site. You might end up with a site that has lots of fancy layouts. Every page might have a layout that's slightly different, or you might end up with unique landing pages that have different layouts. Or sometimes sites want to have different layouts for the same content. You're creating a page, and you have three options for how that content's going to be laid out on the page. Or sometimes you'll get specs where the design or styling of a page is attached to the content. So a specific page on the site will need to implement a specific color scheme or branding. Or maybe that is attached to a certain menu item or a menu dropdown. And of course it's possible to do this in Drupal, right? You can create pages where the theme takes into account the page that you're looking at and the design changes. But this can easily get out of hand. And the designer might not realize that they're having this impact on the maintainability of your theme. So here's an example of some landing pages that we implemented. And the initial designs had a lot more variation than this. Here you can see there's a few blocks being displayed in the layouts. And you can have a black background or a light background. They could be left or right aligned. You can add calls to action and videos to these landing page blocks. But the initial designs had way more iteration, way more variation in terms of these blocks. And it was something that would have been impossible to theme in a Drupal way. We would have had to add CSS and HTML specific to each landing page. So by making the design more consistent, we were able to have an implementation that was a lot more flexible. So now when the site authors create new landing page blocks, they just have to select whether they want a light background or dark background, whether they want it to be left aligned or right aligned. So by simplifying the design, we simplified the theme significantly. So we have a really flexible theme system in Drupal, a lot of powerful configuration, and a design process that sometimes dictates the branding of the site. And this isn't even a complete picture. It's kind of a simplified version. I'm probably missing some arrows here, and I'm definitely missing a lot of components. But you can see that, obviously, there's this complex relationship between theming and configuration, and then the design of your site is just adding to this. OK, so I've painted this terrible picture. You're all going to have nightmares about landing page designs and other terrible things. But Drupal H just came out, and this is going to solve all our problems, right? Right, OK, so presentations over use Drupal 8. You're all good. Drupal 8 theming. So I'm sure you've all been going to all of the front end sessions on Drupal 8 theming, all the new tools we have, and you're all excited to get started and build more Drupal 8 themes. So now with Drupal 8, we have libraries for loading CSS and JavaScript. We have twig templating. We have more templates than we did before. We used to have more theme functions, but now everything we can override with templates. We have these new core base themes, classy and stable, and we have breakpoints. And there's lots of improvements just in using the Drupal 8 theme system. So if you're looking to kind of create a more minimalist theme, maybe by default our themes will just be more minimalist. So we have no JavaScript loaded by default on the front end in Drupal 8. We have this max style or categorization of our CSS files, which is really great that we can just start using. We have HTML5 markup by default. We have the stable theme, which is a more minimalistic theme, because it's not adding so many classes. We have better accessibility, so if you look into Drupal 8 accessibility, if this is important to you, you just get a lot more out of the box. And decoupled Drupal is possible, so you can create something truly minimalist. Does that mean that Drupal 8's solving all our theming problems? No, because we still have all of these tools that we can use as themers, and when we're making our custom themes, we can still make things really complex. So I'm going to go through some of these tools that we have. Some of them are new. Some of them we had in Drupal 7. And I'm just going to talk about best practices for some of these things. So first of all, with Drupal 8, we have these two core themes, stable and classy. And you might, if you've heard of these things, you know that the stable theme, it's more simplistic. It doesn't have so many classes that it adds. It's, you know, stable, because the reason it's called stable, right, is because it's not changing, so in Drupal 8, the core markup could change, but the markup in the stable theme is stable. Classy is called classy because it has more classes. So you can see the difference between these two template files. The classy theme adds all this step to the top. So you might be thinking, oh great, this is a way to make my theme more minimalistic. I'll just use the stable theme. It's more simple. But if you're using stable, you might be missing some of these classes that we used to use in Drupal 7, like having a class for whether or not the user is logged in or having a class for the language that your site is in. These things can be really useful. So if you do use stable, you might find that you add a lot of extra templates to get those classes back because you specifically want a certain class. And if you have to copy a template into your theme to customize it, that's adding to the amount of code that you have to maintain. So if you do find yourself doing that, then I would say go for the classy theme. I think it's more appropriate for most theme developers, but choose the one that's going to work best for you and for your design process. Next up, libraries. So we have libraries in Drupal 8. How many of you have used libraries in your themes so far? Couple of you. So for those of you who haven't used libraries, the libraries.yaml file in your theme allows you to define libraries. And when these libraries are attached to a page, the CSS and JavaScript associated with the library will get loaded. So typically, you'll have a global library that's attached in your info.yaml file, and this will get loaded on every page that's themed with your theme. On the other hand, if you have CSS and JavaScript that you only want to load in specific cases, you'll probably attach the library in a template file like this. Like if you only want to attach your search styling library when the search page is loaded, you could attach it to the page search template. You could also attach libraries using pre-process function or using a page attachments alter function in your theme. So you can control when these libraries get loaded and how they're used. So this is a replacement for Drupal add CSS. Now we have libraries which give us more control. So this is an exciting new tool. It's going to help us define our CSS and JavaScript into these more distinct groups and have more control over how it's loaded on the page. But because it's a new tool, we're probably all going to use it way too much. So there are really good use cases for using libraries. It's obvious that you're going to have a global library of some sort. It might be useful to have a library for something like the search section of your site where you have a lot of specific styling for search filters and search results or for a store section of your site where you have all your e-commerce listings and CSS specific to those pages. But it's also tempting to create too many libraries. So the first Drupal site I worked on, the first theme I was working on, I started creating libraries for everything just because they were there. And if you find yourself creating libraries for things like the front page, all your landing pages, your user profile pages, there's probably a lot of overlap between the CSS and JavaScript you're going to use in these pages. And you might just find yourself writing more CSS than you otherwise would need to. So keep that in mind and don't use libraries if you don't have a specific need to. Another thing to keep in mind with libraries if you're adding CSS is that the fact that you're using a library means that you're already in the context of a certain section of your site. If you're adding a search library to your theme, then you know that that library is only going to get loaded on search pages. So there's no reason for you to go and add a selector in your CSS that targets search pages. You don't need to wrap all of your SAS in a selector for the search page because you're already in that context. So this use of contextual libraries allows us to simplify our CSS, so you should take advantage of that. One of the main things we do as Siemens is write CSS or SAS or you might use less to define the look and feel of the site. But it's easy to write CSS that's overly complicated, especially if you're using a preprocessor like SAS. So writing good SAS is important. So even more important than if you're just writing CSS where you're probably aware things are complex, it's easy to write SAS that's overly complicated without realizing it. So a few rules of thumb here, first thing. Don't nest your selectors when you don't have to. So if you're creating a whole bunch of pages on your site and you have a bunch of events views all over the place in blocks and on pages, don't nest all the CSS for your events view inside the CSS for one of your blocks because then that CSS is only going to apply to the events view that shows up in that block. Instead, it's better to create more generic CSS first and then go and override the specific cases where you need to. Don't use IDs if you can at all avoid it. So as soon as you use an ID, you're creating something that can't be reused. So something like adding CSS for a specific block with a certain ID rather than adding a class to that block, it's something to definitely avoid. Same thing with our views or anything else you might want to reuse. With SAS, we have variables. And it's important to name your variables and use your variables consistently. So if you have variables and the names kind of don't make sense, it's going to be really hard for the next themeer to come along and figure out what you meant. And this could be a whole presentation on best practices for SAS. So I'll leave you with the advice that you should review your CSS after SAS creates it, because it'll help you figure out how your SAS could be simplified more. So if you're looking through the CSS that's generated and you find more complexity than you expected and you don't really understand why there's so many complicated selectors, then you can go back and review your SAS to fix that. And there's a link here. The slides will be online with more useful suggestions. So Drupal 8 gives us more templates than ever before to customize. And instead of theme functions in Drupal 8, we have just more template files, right? So for something like theming the breadcrumbs, you don't use a function anymore. You have a template to override the output of the breadcrumbs. So this is great that we have a more consistent way of doing things. We actually have kind of one less tool in the theming toolkit. But the question still remains how to make templates that are maintainable. So my first piece of advice would be just don't create so many templates. If you can avoid it, your theme will be more maintainable if you just have fewer files to maintain. So if you're creating a simple theme that's extending something like classy or if you're using a base theme like Bootstrap, you might not need to create so many template files. If you do start creating template files, you're using twig now, right? Drupal 8 has twig, which is one of the exciting things of Seamers that we get to use. And one of the features that twig comes with is twig blocks. How many of you have used twig blocks before? Couple people? How many of you have heard of twig blocks? So twig blocks are not like Drupal blocks at all. Twig blocks are their own thing. And I don't know if you can tell really well in this example. Hopefully you can at least see this. But in a twig template, you might find a chunk of code that defines a block. And a block is something that you can override in a child template. So say in your node template, you have a twig block. It's going to be a section of the template file. In your node article template, you could decide that instead of overriding the whole template, you just want to override that one block. And so this is great, right? Because usually when we override a template, it's just to override one part of the template. If you're overriding the page template, for example, you probably don't want to change everything around, you just want to go and add one variable to the home page. Or you just want to change around one thing on a landing page. And so by extending templates, so you see in the node article template there, we're extending the parent template, the node.html.twig file. And we're just overriding the node header block. So that's that one chunk of code from the parent template. And so this allows you to create template files that have less code in them, and that are easier to maintain. So this seems like a great thing. And I think this exists in a lot of other frameworks. When I started theming, I was using Ruby on Rails, and it had this similar system of partials, and it made templating a lot more fun. But at the same time, every time you're doing this, creating a child template, it's still a new template. So it's still something that you're adding to the theme. And one downside is that it removes some of the context. So if you open up the node article template, and all you see is this one node header block that's being overridden, you lose the context for what's around that block. So I would say with this twig block tool that we have, it's going to be really great. But it's going to require some more thought and maybe adding comments to describe why we have a node header block in our template, and why we're overriding it. These things will be useful. One other thing to keep in mind when you're overriding templates, especially with node templates, is that you as a themeer, when you're adding a template, you're taking responsibility for all the output that that template prints on the page. So if it's a node template, what's the node template's main job? It's to print out the content of the node. I have seen so many node templates in Drupal 7 themes that don't print out the content. They just print out all the fields that they want to print in whatever order they want. So with Drupal 8, just like with Drupal 7, we have to print things out in our twig templates. So this is the syntax here for printing things in twig, this double curly bracket syntax. And so here we're printing out the links from the content, then we're printing out content without the links, and then we're printing out the links again. And so printing out the content, that second line, that's really important. You shouldn't leave that out of your template files. Even if at the time, all of your contents being displayed, a site builder might come along later and add a field to your content type. And if you don't print out the content, you just print out all the individual fields. You'll be missing that extra thing. So there's no twig police that's going to come along and stop you from adding a template where you're not displaying the content, but just have to take responsibility and make sure you do it. So preprocess functions are still a tool in our Drupal 8 theming toolkit, and they allow us to customize display logic on our site. So we can add variables, we can change almost anything using a preprocess function. And there's lots of good use cases for this. So sometimes you want to combine two fields together or add a variable, change the format of something. And these are all really good reasons to use a preprocess function. But there's also lots of examples of people using preprocess functions in kind of ugly ways. So if you find that you're formatting field types again and again in your preprocess functions, the same fields over and over again, better just to use a module for that, create a formatter. I've also seen in preprocess functions people overriding or people creating logic around a certain node ID, so changing everything about how a node is displayed just for that one node ID. And this is something that we shouldn't do anywhere in our code if we can avoid it because it creates a dependency on our content. So if anyone ever deletes that node, then our whole theme kind of falls apart. Also just obvious things, maybe database calls in our preprocess functions or calculations for currencies. These are things that are too complex for the theme layer. At some point, we need to pass that responsibility onto a custom module. As seamers, we often face this dilemma of whether to put something in a preprocess function or whether to override a template instead. And I think there's no hard and fast rules here. Some people like adding templates, and some people prefer preprocess functions. But in general, if you're adding logic, if you're creating variables, preprocess functions are really good for that. If you're just changing the markup a bit or adding some classes, you can do that in a template file. So ViewModes I talked about a little bit before. They're ways of changing the display of content for different contexts on our site. And adding ViewModes in Drupal 8 is easier than ever before. How many of you use DisplaySuite for Drupal 7? So we still have DisplaySuite for Drupal 8, but for Drupal 8, ViewModes are in core. So you don't have to use DisplaySuite. If all you want are these extra ViewModes for your content types. And they work for content types, but also for other entities. And so ViewModes are a really useful tool that I think people are going to use more, because they are in core, or the ability to create them in the UI is in core, I should say. In Drupal 7, you could create them, but you had to write some code. But I think sometimes they're used too much. So if you are using ViewModes, and in each of your node templates, you have a switch that changes the whole output of the node for each ViewMode, you're probably writing too much code. So if you already have ViewModes, then you have the ability to change the field display for each ViewMode for each type of content, or for each bundle on your site. And so writing all this extra code in your theme is kind of adding a second layer of complexity. If you end up with situations where you have one ViewMode that's just for one content type, and that's only used in one place, that's also probably a sign that you're adding too much complexity using too many ViewModes. OK, theme settings. I think this is something that, kind of a tool that themeers forget about. We have theme settings in contributed modules for changing things like colors and the layout of our theme. But theme settings are something that we can use in our own custom themes as well. So if you have a theme, for example, that's going to be installed in a bunch of different places, maybe you have a university, a set of university websites. And the branding needs to be the same, but you have some slight variations in look and feel. Theme settings would be great for this use case, because it means you can have a single theme, and then you can just use the theme settings to switch between the small branding variations. So for one instance of the website, maybe you want to have a logo or a slightly taller banner or a slightly different color scheme. So you can just use theme settings to change this, and then you only have one theme to maintain. So trust me, if you're trying to create a minimalist theme, the worst thing you can do is say, OK, my theme's really minimalist. Now I'm going to copy and paste it and have two separate themes. This is like the opposite of what you want to do, right? Even creating multiple sub-themes, you're still going to end up with a lot of code to maintain. OK, the last tool that I'm going to talk about here today are regions, and this is going to seem really basic for a lot of you. You think, of course, I've made so many Drupal themes, and you're talking to me about regions. So basic. But I don't think I've ever come across a Drupal theme that I've inherited from another developer, or I don't think I've even ever made a Drupal theme, where the regions in the theme actually match up to the exact regions that I need on the site. So there always seems to be some extra ghost region that nobody knows what it's for. Nobody knows why it's there. There's a sidebar second that has no blocks in it that nobody seems to know why we have this sidebar second. And one day, the site builder decides to put a block in there, and maybe it shows up. Maybe it doesn't. Maybe it kind of shows up randomly in the middle of the page. So with regions, just make sure the regions actually match up with the regions that you have printed out in your template and the ones that you're using. So to sum up, your mission as a themeer is to limit the complexity of the theme. So it's kind of up to you. You have all these forces, the design. You have all the excitement about Drupal 8. You have configuration that you're putting together, and you have your custom theme. And so it's hard to be the themeer and to deal with all these different things. So just some words of advice. First of all, be consistent. So just try and kind of choose a method and stick with it. If you're going to use view modes for everything, go with it. Document them and name them well. If you're using a bootstrap theme, use bootstrap for all your layouts. Don't switch between different techniques for your layouts. Recognize complexity. So if you're working on your theme and you realize you're adding a lot of theme settings, but you're only planning to install this theme in one place, that's probably a sign that your theme is too complex. Or if you have a library that you're creating for every single page on the site, too complex. So take a step back every once in a while and just recognize that complexity. Think about how hard the site is going to be to maintain. So even if it's your site, you're planning on maintaining this for the next five years and you know you're the one who's going to be there, even if it's just for your future self, make sure that you think about the maintenance task that you're adding when you add new components to your theme. So keep in mind that you're not going to remember what you did in that theme file two years from now. You're not going to remember how you structured the SAS variables or why you called the regions what you called them. So that's why documentation is important, even if it's just for your future self. And I know everybody's going to say, write documentation and no one's ever going to really take the time to write it, but at least just document the things that are outliers. So if there's a region that doesn't get displayed on every page, just document that. Don't document the rest of them, just the one that's sort of special. Or if there's the preprocessed functions that are really complicated, just document those. Or just the templates that do something a little different. Or if you have contextual libraries, just note down why you added them. So it's not to say that you have to document every single little obvious thing on your site, but just the things that you think are a little bit special. And finally, if you have the chance and you come across one of these mammoth themes that has 200 templates, maybe rather than taking on that project and all that responsibility, it might be worth considering refactoring the theme. So if you do decide to refactor a theme that you think has become too complex, there's lots of tools out there. And you've probably heard of them at other front end sessions, tools for testing the front end. So one that we've developed at Evolving Web is called SiteDiff. And it'll show you the difference between two sites. It'll show you the difference between the HTML. So if you've done a bunch of work to refactor your theme, but you don't actually want to change any of the markup that's being displayed, you can use that tool to check what has changed. There's also lots of visual diff tools that will create screenshots of your site in different states. So you can test, OK, I refactored all the preprocess functions to simplify them. Now I just want to make sure they still work. So you can see if anything's changed visually on the site. So that's all I have. If you want to learn more about Drupal 8 theming, we have all these trainings that we do. And other than that, I will leave it to questions. Any questions or comments? That's a good question. Should we use panels? We could have a whole debate on that between panels and contacts and other front-end tools. There's definitely, panels definitely adds complexity, because it's not just a tool for changing the layout of the page. It also adds a bunch of functionality. So if you are just using it to create layouts, unless you need to give the administrator control those layouts and you need to be able to change them on the fly, I think it can be overkill. So we've created lots of sites just using context where we have landing pages. Yeah, I mean, I think in general it's a good approach for Drupal 8 as well, yeah. I just have a quick clearing thing up in Drupal 8. The fear of having a lot of files is way less. It's actually how we end up designing the system. So don't be too afraid of it. There is at least 140 files, no matter what you do, because that's how it's built. But you can hide it all the way by going with the base theme. It's just the files are still there, so you can hide them from yourself visually. But they're still there. I just want to make sure that kind of one of the pet things we must in. We have actually been thinking about removing pre-process. There has been a wish in the way we would think Drupal 8. It's not sure if we're probably not going to happen anyways. But again, to reduce the complexity of the session. And besides that, thanks for a good presentation. I get so happy when I see these things happening. Thanks. I was wondering how you take site performance into consideration when you're making some of these decisions. For example, I'm on a D7 site now where I use DisplaySuite as a display mode for search results. But then the way that we configured search made those pages load like 10 seconds plus. It's crazy. So now we're trying to work around that. So what are some things you do to kind of take performance into consideration with your decisions that you make? Oh, good question. So I don't know that much about performance. I work with a team of developers who I sort of hand that over to them a lot of the time. It may be a better question. How do you work with your development team to find those things out? Is that like suggestions that they give you? Yeah. So yeah, that is a great question. So when we recently upgraded our own site to Drupal 8, it's a multilingual site. So it has content in English and French. And we realized after we launched the site that an incredible amount of time was being taken to determine the block visibility for each block on the page. And a lot of that was because there were so many blocks. And we ended up having an English block and a French block for each of our blocks just because of the way we had migrated in the content. So that's something we didn't realize until after we had launched the site. So we have to go back now and kind of reconfigure all of that. So that's kind of not a good case. This is like a worst case scenario we've already launched. We have to redo a bunch of our content. So I'd say just making sure that that's not the last thing, not the last step, but rather like one of the first parts of your QA because it's not that hard to just run some performance tests. Right. This is related kind of, and I almost didn't ask it because he's asking about performance. When you're deciding whether to add a library to a page, I have this old philosophy in my head. And maybe it's, I don't know if it's currently we can have a debate, but that I should put all the same JavaScript and CSS on every page load so that it gets cached by the users browser. But if I'm adding different things for different pages and that's not happening, I can see how it makes the theming easier. But is there a danger in the long run of, I don't know. Having too many components loaded. Of a performance risk of doing that a lot. I don't think it's something you have to be too concerned about. So there's grouping of CSS files for Drupal 8. So that's going to help a lot with the aggregation. So it's not just going to aggregate each of your libraries separately. Yep. Thank you so much for putting this together. You mentioned field collection for grouping fields. Drupal 7 also has multi-fields. So I'm going to get in Drupal 8. What is the optimal way for grouping fields? So Drupal 8, there's already a release for field collections. I don't know that there's any alternative. So I would start with that. Yep. Thank you. And thanks for representing women. Oh, you're welcome. My pleasure. Anyone else? One more thing about the performance. I just realized my colleagues are presenting tomorrow on blackfire.io, which is a performance profiling tool that's really useful for front-end. So if you're interested in front-end performance, that's something to check out. Deletion, we have to manage a lot of sub-themes. So do you have any suggestions like do's and don'ts? We're trying to have parent theme and then bunch of child themes under the same installation. Oh, good question. So for sub-themes, I guess most of my experience with that would be coming, again, from the university context, starting out with a base theme that's shared by all university departments. And then departments that think they're special, like alumni or, I don't know, the admissions office, they think they deserve their own sub-theme. So my suggestion would be to try and figure out this just at least the overall architecture first. So if you have good examples of what generic sites are going to look like, like in that use case, if you have all these generic departments that don't have any special requirements, get a few examples of those first and build that base theme, and then try and work on the sites that are special, like the admissions side or the alumni side, and work on those next. In my experience, if you start off with the special people who think they need a special theme, and then you try and work backwards to create the base theme afterwards, that's a really hard thing to do. So I don't know if it's that useful, but at least try and go in that top down direction. Anything else? So for those of you who've stuck around to the end, you must really like my presentation. So I'm going to ask you to come to Drupal North. We're having a Drupal camp up in Montreal, June 16 to 19. It's going to be really fun. Montreal is amazing in June. We have no snow. There's lots of festivals, kind of like New Orleans. So come on up and join us. And you can go to drupalnorth.org to check it out. It's free. That's for the training. You don't have to come to the training. The sessions are free. Awesome. Thanks, everyone.