 Welcome to dominate the theme layer. This is a redo. Yesterday, the sound didn't get recorded, probably. So we're redoing this session with a tiny, but very enthusiastic audience of hardcore themas. And I see a single developer in the corner. So welcome. Let me shortly introduce myself. My name is Jesper Völtke. I work as a themeer and, well, I have a fancier title on that, but I work as a themeer and a front end developer at a company called Bustel. I'm a regular front end developer, Mark of Marine. My background is in journalism. I started developing and doing CSS a couple years back. And I'm one of the front end United organizers. And I have promised myself to sneak in a short advert next year in spring in the UK, front end United UK 2013. And you should definitely be there. Right. This is a bit different presentation that I'm usually giving. Like in the Drupal Design Camp Berlin, I shared a hotel room with a very famous, very loud Danish Drupal and modern DK. And ever since then, I've been using pictures of a sleeping half-naked modern in all my presentations as revenge for his snoring. Since this is DrupalCon, I will be giving a modern DK free presentation. So if I look nervous or a bit like on edge, that's why. You get it's like a comfort thing, like football players are their favorite jockstrap or something. So just like a few words before we get started. This is a theming session. And there will be slides with code. But these slides are not necessary to understand the high level of the session. The session should hopefully be interesting for both designers who want to get themselves better integrated into the workflow, also for site builders and for project managers. There will be more slides here without code. And these are necessary to understand the high level and most important part. So developers, I apologize. It seems that PowerPoint slides are not very well suited to do code. So what I've done instead is I have created a GitHub repository where there's like 500 or 600 lines of documented code that goes through and has examples of the things I will be talking about today. So the session will mainly be about what you should be doing and why you should be doing it. But the how of it you can go through at GitHub at your own time. There's also a link at the end. It's like a toolbox for domination, I call it. So let's take a quick look at what we will be doing in this session. The session is about Drupal's theming layer. Like the Drupal's theming layer is a beautiful beast. With the right touch, everything can be overwritten. It can be controlled. It can be styled. But it's still a beast, and it requires a firm hand. If you try to just be gentle, light touch, gentle strokes of CSS, the beast will get the better of you, and you will not realize your mistake before it's too late. This session is about making your theming more efficient by dominating your mug up early on in the process. Submissive mug up is a efficient mug up. That's an important point. And this session is broken down in four parts. First, I'll take a look at not necessarily the common approach, but a very common approach to styling Drupal sites. And I deliberately call it styling, not theming Drupal sites. And I'll try to show you why that's a bad idea, and we will take a look at some specific pitfall that you might fall into doing that. After that, we'll take a look at another way to do it, like the dominating way, and some of the benefits of that. And I'll try to argue why this makes sense from a theming point of view and also find a financial point of view. Then I'll try to show you how to get this into your workflow, how do you go from having a design delivered by a designer until you have your finished theme and how to make this get into your workflow. And then finally, we will take a quick look at some specific code examples and techniques to do this in a way that's easy and scalable and fast for you for the themers. So the first thing we look at is, like I call it the gentle touch or the gentle way. It seems to me that a lot of themers take this approach. And maybe you guys don't, but I bet you do somebody who does. And especially for new themers, it seems, or people coming into Drupal from other platforms. It seems to me that they try to do as much styling as absolutely possible using only CSS. And only when absolutely necessary, they would go in and they would adjust the markup here and there and maybe create a template file or two. And whoops, I'm not supposed to do that. And one of the reasons this happened is that people often let core and trick them. Out of the box, Drupal has no idea how your site will look like. You have no idea of the business logic or the design system behind your site. So what core developers and contract developers try to do out of the box is to give you as comprehensive set of styling hooks and as a flexible and often very verbose markup to work with. And that makes it possible to more or less style every single element on a website out of the box without having to do anything with the markup. If you're happy with four nested divs, you can style everything as it is. And that's the trap. And this is the trap a lot of people fall into. The result when you do this is often the same. You get like large, bloated CSS, a lot of redundant code. We get styles that are tied to markup. And when you tie a styling to markup, those styles become inflexible, they're harder to reuse, they're harder to port around a site. And when they're harder to port, a site becomes harder to reuse, a site becomes harder to extend. We get low extensibility. We have to put in more effort into our project every time we want to extend it with new features and new layouts and new page types. And this in the end gives us sites with a high maintenance. And in the first round, we did a racing of hands. How many people liked building new Drupal sites? And luckily it seemed like 95% of the room really liked building new Drupal sites. We had three people who really liked maintaining Drupal sites. So we want to reduce maintenance. We don't want to build beautiful stuff. We don't want to spend a lot of time cleaning up CSS files. If we, let's try to look at some of the specifics. There's like four common pitfalls, I see. I don't know if even it's fair to call them pitfalls, but four common ways to style Drupal sites that gives us some issues. The most grievous one is when you start styling your site by Drupal module. This is so easy to do because everything has like a huge ID, very specific, it has 17 classes. You can style everything and you often style it by Drupal module. This like, this leads us back to the issue like this is going to possess low extensibility. If we want to reuse this visual in other places on our site, we need to add, keep adding rows and rows of selectors. Okay, so maybe our campaign monitor block looks the same way as our newsletter block. It looks the same way as our list of, I don't know, Twitter comments. And we keep adding those rows to our selectors and our star sheet keeps growing. Another issue with this is like we're building web systems and that block from this module might appear different in different contexts and in different regions on our site and it might look different. It might look different depending on the user who sees it. It might look different depending on whether it's output in the photo and the site bar and the header or maybe it's output deep in the site node and it will look differently. And if we style by Drupal module, we not only have to like keep repeating these for like for, keep repeating for like every time we repeat like every time we style a new kind of module and we also have to do different versions of it. One when it's at site bar, one in the photo, one in the header and so on. A lot of redundant code. This like, if you only decide to change one thing today, this is what you should be changing. Like you should totally stop styling stuff by Drupal module, it's very important. A related one is when we start styling things by page or maybe by content type. Like it's a very common variation. I see it very often when I inherit sites from others and I've done it too many times myself. Like we style things based on, okay, this is the new space on the new page. We have a header and that header. Maybe that header looks different than the one on the article page. We have some metadata that again looks different on the event page and we start styling things by content type or by region. Again, we get a lot of redundant code. Often there will be a lot of properties shared between like these styles. They will have something in common and we have to style that multiple times. Gives us a lot of lines of CSS. Or maybe it gives us a lot of overrides because we style it once and then we overwrite it and we overwrite it and we overwrite it. This makes it very expensive to maintain. It makes it expensive to maintain because we have more lines of CSS. Like every time we add a line of code, it's one more line to maintain. But it also becomes unpredictable what consequences your changes will have. You go into your style sheet, you change something and you have to go through all the different page types to see what was the other consequences of this. Especially in common, if you inherit sites, you didn't code it yourself. Like, oh, I want to change this because now my designer wants this to be bigger. But not really 100% sure that that styling is not used somewhere else. So, basically to maintain. This is not a Drupal-specific thing but styling by tag, my experience, it's the hardest thing to convince designers or themas to stop doing. Because this is how we started out. Like, we started out styling paragraphs and M and strong and you know. And that's great for web pages. But we're working with web systems. I promise to come back to the difference. But we're styling web systems. And when we tie our styles to markup, it becomes really hard to reuse. Again, often the same visual style is used several times throughout our site. And when we style by markup, we can reuse it. It makes it less portable. Another thing is that in Drupal's steaming layer, controlling the markup takes a lot more work than controlling stuff like classes. And sometimes, maybe for good reason, your, the date you've been styling will be a P tag. Sometimes it will be a span. Sometimes it will be a data element with some attributes on it. If we start styling by tag, we have to, again, we have to keep adding rows and rows of selectors. We have to tell that date, dot date class span is the same as the date class data and so on. There's some exceptions to this. The most notable being stuff like image. Because image have some unique properties. It makes sense to go in and say, all my images should have this, the magical max width 100% that suddenly makes them responsive. But another example could be links, but not even always. Maybe your button sometimes looks like your links. Maybe you have spans with JavaScript elements on them that look like your links. And if we style them by tag, again, we have to keep adding selectors and keep adding selectors. A variation of this, a very common one, is to style headings by tag. Again, this is like a lot of us learned this as best practices. To style your headings once and it will be effective throughout your site. I think one of the reasons that this is a bad idea is because your visual hierarchy, the one, like the hierarchy your designer created, will not always match your document outline. We're creating a web system and blocks and content will be output in different contexts in different places. Sometimes inside the node, sometimes in the site bar, sometimes in the footer. And the visual hierarchy will not match, not always match the document outline. Again, it makes it hard to port things around. Like if we style by heading, well, again, if it's in the site bar, it will look different than when it's your main content on your site and it will look different when it's in your footer. So it gives us low portability. And with the arrival of HTML5 and sectioning elements, well, all your headings might be H1s. All your headings might be H1s wrapped in sectioning elements and H groups. So if you style by heading, not really going away. So this was the, try to give a short overview of what you shouldn't be doing, which is always easy to tell people what you shouldn't be doing. Let's try to take a look at what we want, take a look at what we want to achieve instead. The first and absolutely most important takeaway is that you should create your own front-end architecture that's built on the design and the business logic behind your site. Shouldn't be built on the backend architecture. Shouldn't be built on the group of modules involved. Your front-end architecture should be built on what you wanna achieve with your front-end, the system behind your design and the logic, like your business logic behind it. Another thing we have to look at is that we're styling, most of us are styling or theming web systems, not web pages. If you're styling a web page, doing it with absolute minimal markup and some advanced combination of pseudo-selectors and the specific markup can be beautiful and the right thing to do. But we're building web systems. And web systems have some other success criteria. These systems need to be extensible, they need to be robust, they need to be portable. They need to be extensible in the sense that you can change the markup, we can add new page types, we can add new features, we can add new layouts to our site without having to redo our work all the time. They need to be robust because you never know what will happen after you finish your theme. People will start adding new blocks, they will take blocks away, they will move stuff around, they will change the markup involved. And your styling needs to be able to handle that. Your styling needs to be robust. And in fact, what I want you to do is to be able to build a house that keeps standing when people start moving the foundation around. And we want them to be portable. We want them to be able to take something you style over here, move it to the other site and it should still be styled correctly. Maybe they wanna duplicate it four times in the footer and it should come out styled correctly. So it needs to be portable. And the way we can do this is when we style styling objects, not tags or elements. We wanna style objects. I promise to come back to what I mean by styling objects. And the requirement to do this is that we upfront before we start coding, before we start writing our CSS, we need to invest or you need to invest time to dominate your markup early on. I think maybe that's the second most important takeaway for this, like spend time dominating your markup. And I'm not saying this because it's like some hippie idea of doing it the right way or out of theoretical purity. You should do it because it pays off. It pays off in time, it pays off in dollars and cents, it pays off in happy theme. All three are very important. It gives you lower maintenance. And we already, well, at least I claim that the last group who saw this session didn't wanna maintain their website. It makes it, it gives us a cheaper introduction of new features. Like if we're doing it perfectly, your site builders and content editors can add new features to the site and they will come out styled already. They'll be magically styled without the theme of having to go into the site and doing a thing. As long as they stay within the same, like the same design patterns that we already established. We will get linear CSS. In my experience, when I switched from style doing all the pitfalls and going to an obvious going to approach, I was able to reduce the amount of CSS in my websites to about 30%. I could cut away 70% of the CSS in my website. It gives me a linear CSS, give me a lower footprint, it's faster to download. Also the object oriented approach gives me faster rendering performance. Not normally something you should worry about, but it gives you a faster rendering performance in most browsers. Okay, so this is what we wanna achieve on a high level. This is what we wanna take away. We wanna build web systems that are robust, extensible, portable. We wanna style objects, whatever they are. And we don't wanna fall into these pitfalls. So the way to, like my way of thinking is when I build this mental model for myself and how to get this into my workflow. These days, I rarely design anything myself anymore. So I will receive a design from a UX person or from a graphic designer and I will be expected to either convert that into a theme or expect to take up the site builders and help them architect the site. So I've broken that down into these four steps. We could probably do five steps or three steps. But the idea is that we will analyze our design and the specifications and we will understand the thinking that went into this design. We will try to streamline it and make it faster, easier and cheaper to theme. We will define objects from it and then we will go in and dominate that margo. Let's look at, I'll try to look at each of the four faces and turn. The first one is like the analysis phase. When I, I think it goes for a lot of us but when I get a theme or get the design a lot of the specifications have already been established. And often a lot of the systems architecture behind us have already been established. We wanna know, we know what we wanna build and we probably already know how we want to build it when I receive the design. So what happens is that when I get this design like somebody has been sitting there maybe for weeks putting their, like putting all their blood and tears into it, what I see is this. Like this is what my mind shows me. It's a systems architecture. Oh yeah, like yeah sure that's a field collection and over there we have a view and there's the header. Like there's the ugly part that the team don't really know how to do it. I have to call up a developer and make that magic stuff up there. The first step before we can even start analyzing the design is just to look beyond this and see what the designer actually designed. What is this, like yeah. Like try to understand the design and the system behind it and the logic and the thinking that went into it. And when we get there and we have like we back to scratch a clean slate, we have a design. What we will try to do is look for recurring patterns. We will analyze our design and try to find visual or structural patterns that are recurring, that appear more than once on our site. Here's an example. This is like the sign I received. And I would go through it and look for patterns that reappear more than once. In this case, we seem to have these blocks that share the same width. They have the same background color. They have the same padding. They act the same way inside the flow of the page. This is definitely like a pattern that is recurring. Another example is these headings. Like they share font family, they share size, they share color. And they have repeated not only in the four blocks we saw below, but it seems it's also appearing at another place in the site. And we will do this analysis of recurring patterns not within the page, but across the entire site. Here's an example of the same pattern of the recurring heading. Still same font size, same color, same font family, now recurring within some other patterns. These blocks, it's not easy to see, but these blocks are different than the first ones. And then we'll try to break down these patterns, like to organize them and understand them. Like roughly we have three different kinds of patterns. We will have structural patterns. Structural patterns are things that organize like the control, how the pattern itself reacts to stuff around it and how it organizes what it's within it. So there could be flows, orders, lists, types of content. Another pattern is visual patterns. Could be stuff like borders, colors, fonts, topography, general icons. And try to group them. In this case, I try to like go through the topography on my site and try to group it and order it and look for recurring patterns. And then we have patterns that are variations on other patterns. Patterns that are identical except for some systematic change. In this case, we have these three patterns, these three blocks that are completely identical structurally. At the same content, this content is layouted in the same way, same height, same width, but they are just varying backgrounds and the text colors varies based on the backgrounds. So this is a variation. And you should go in and look at your variations as patterns themselves. And this is like a really great time to bring your designer on board. Or if you are the designer, this is the time like where you wanna bring yourself on board. No, because it makes great sense from both points of view. Like the designer can help you as a themeer to understand what was the logic behind this. They can explain the system, like the patterns. Maybe they can explain all these patterns for you and break it down. And if you're the designer, this is also the way that you can make sure that the person who is gonna take your weeks of work and convert it into a product understands what you designed. This is also important. Like it's a way of making sure that what comes out in the other end follows the thinking that we're entering. And depending on the project, this can be done in as little as half an hour like this whole analysis phase. Sit down, if you're in the same office and it's a smallish project, you can go to the coffee machine with the designer. Print these stuff out and have a talk and write on the printouts. For larger projects, it takes longer time depending on the amount of page types and layouts. But it always pays off. It's a good investment of your time. Next up is the process of streamlining. We've gone in, we've analyzed our design and we have all these different patterns. We maybe regroup them into structural and visual patterns. What we wanna do now is try to streamline it. And by streamline, I mean we want to take variations of patterns and try to consolidate them into fewer patterns. You wanna reduce the like, every time we can reduce two patterns to one pattern, it's one pattern less that you need to spend time styling and maintaining. And we can do this in two ways. The one is simply to unify it. Maybe we have 14 pixel padding. Here we have 15 pixel padding there. And we can just all agree that 14 pixel padding is great. That's no reason to have two different versions. So we'll streamline it. Sometimes like these are just differences that have been, variations that have been introduced through the design process and they're not deliberate. Other times the designer can like make new choices and have you streamline it. If you cannot just unify it, another option is to define rules for these variations. Maybe there's a system to this. Maybe we have two pixel margin below every block. Unless it's the last block, then it has 15 pixel padding. And if it's the only block, then it's also 15 pixel padding. Sorry, margin. And the reason we wanna do this is because rules can often be stylable. You can style these rules, but you can't style variations without a system behind them. Again, bringing the designer on board, the designer can help you do this and like explain the system behind it. Or maybe you can develop a system behind it together. So we analyzed our project. We broke it, we now have all these patterns. We streamlined them into fewer patterns. And what we have left is what we absolutely necessarily need to have on our website. This is what our website is based on. We will also have some unique patterns and just note them down. Yes, that will be a logo and maybe it's the only logo. Doesn't matter, those will be unique patterns. It's fine, they should be there. So we'll try to take these patterns and from the patterns we want to define objects. So we wanna define objects. And we can do this in different ways. There's no, in my opinion, there's no right way to do it. What is important is that you find a system that works for you. This is a, the details are not important, but this is an example of me breaking down these patterns into objects. I'm defining some objects that define some objects that control the size of this, the layout, other objects control the typography, other objects define colors and variations. And use the system that works for you. If you don't have a system, get a system, you can innovate yourself. You can take a look at Jonathan Snook's Smacks. It's a very popular system for structuring your objects as a free version online. There's also a book and an e-book you can buy. Of you, the more academic sort, you could look at Nicole Sullivan's object-oriented CSS. I think Smacks is a nice place to start. I prefer, I have my own system. Again, how you do it is not important. I break it down into these five, six layers. I have grits as a layer of my objects because the grits often are separate from the rest of the structure. So I have grits, I have structure objects that define how things flow and how they order stuff inside them. I have style objects that control the colors, the paddings, borders, stuff like that. I would have topography because the topographic objects are often shared between a lot of other objects. I will define a set of topographic objects I use. Stuff like block titles, page titles, label titles, et cetera. And then I have my variations as a layer. An important part here is to write it down. If you're working with others, definitely write it down. If you're just working with yourself, write it down. It doesn't have to take long. And it doesn't have to be high-five. If you're only working with yourself, this is great. Write it just, print out the design of the wireframes and write on it. Good, as long as you can understand what you wrote down, it's fine. Another way to do it is just to do an outline in a style sheet. After you have defined all your objects, you can go down, you can write a style sheet, and you can define your topography, for instance. Okay, I'll have three different sizes of three different kinds of body text. I have four different headings. I have these like four other different kinds of text. And just like in this case, I've just added, I've given the class name, given the short comments to understand them. And actually, this is, I cheated, I lied, because in this example, I also wrote all the CSS immediately, because I knew how it would look. Like, you already know your font families, you know your font sizes, the weight, the line height. So you can write your CSS immediately. You don't actually have to wait for any manga. You can just write your CSS. And when they finish building your website, you can inject these objects and classes into your website, and it will magically be styled. Third option, if you, is to do an extra layer in your Photoshop comp or in your fireworks, and just write on top of it. I made some simple stencils for myself, and I used this when I worked with my developers in Bulgaria, and allows me to go in and define objects, allows me to define a markup, and I can send it down there to the site builders. And they can build things as I wanted out of the box. So I don't have to all write it afterwards. And it takes the same time for them. So we analyzed it. We streamlined it. We now defined our objects. Maybe if we are really hardcore, we already wrote our CSS. So what's left is to actually go in and dominate the markup. This is, maybe for some, this is the fun part. We want to dominate our markup. And one of the ways we do this is for web systems, I highly recommend going with classes. Because we don't want to style text. We don't want to style pages or elements. Tags are amazing. Our classes are amazing. They're reusable objects, even when in the same page. You can use them as many times as you want. They can be combined with other classes. And they inherit without any problem. You can add 17 classes to the same element if you need to. They're separate from the markup. So we can get this robust styling. People can, we can have our developers and site builders change the markup if you don't have to worry about it. And they are, and that's the good thing. They're very easy to add and inject into your markup to do with Drupal's streaming layer. So I can use what naming scheme works for you. But use classes, also in using classes, use a low specificity. High specificity, again, reduces the reusability. But using low, like often, you can get away with just nesting classes at a maximum two levels deep. Often people wrap stuff in IDs, or they have a lot of classes, because they are afraid that their classes will collide with somebody else's. And the way to solve that is not to nest your classes and add more. The way to solve that is to namespace your classes. Like, if you're afraid that using something, a class like heading, will collide with some module that applies style to heading, then I don't call it heading. Like, if you really want to go extreme, add your theme name to every class. Or just use classes that are different from the Drupal naming. Like, I use stuff like title hyphen blog, title hyphen page. I use classes like blog hyphen element, blog hyphen article, and so on. And I have yet to see them collide with Drupal's standard styling. Like, most of you already know what standard classes are at Drupal. Also, the third option is to go in and just strip out all Drupal's standard classes before we even start dominating it. That's very dominating, actually. Go in and just strip out everybody else's classes. And especially if you use preprocessors like SAS and less, be wary of nesting things too deep. So we have our objects. And we want to layer them. Morton hates this part. When I come to it, I say, you want to layer your objects. Because when I say you want to layer your objects, it's stuff like add three classes to the same element. In this case, I've gone in and I've layered three kinds of objects on this side. I have a block secondary, which is one of three block styles that defines it. It's something that is tangentially relevant to the main content, but not in the main focus itself. It could also have been just block default, or maybe block feature. I've applied a style alternate variation, because in this place, it uses alternate color scheme. And I've applied a grid two, because that's how I control my grid styles. If you don't like non-smanty grid classes, you could go in use your preprocessor and use extend, for instance, in SAS. I prefer these grid classes. The title I've given a title block, styles as a block title. And I've defined that on the content wrapper, that every text output here is text secondary. In this case, it's like a slightly smaller font, slightly lighter color than the main content of this page. And we wrapped everything in an aside, which matches perfectly with this tangentially related content. Yes, it's a little more markup than just giving it one class and adding all your markup to it. But there's two reasons it's still OK. One is that this easily saves in your style sheet what extra characters you use here. And two, if you start out with stripping out Drupal's classes, you'll still be way ahead of the rest of the pack with a lower footprint. So that's the high-level overview of the process. You go in, you analyze a theme, you streamline it, you define it, and you dominate it. So what's left now is to take a look at how we actually go in the theming layer and dominate this. We want classes. We want objects represented by classes. And we want to inject those into Drupal's theming layer. Let's take a look at how we want to achieve this. What are the tools available to us? The first question we have to ask ourselves is, how do we add classes to elements in Drupal in a way that's fast and scalable and easy to maintain? One option we have is we can go in and we can add some template files and add some classes to them. Or we could create some template files for fences and use fences module to use different kinds of template files for this. Both of them are not really good ideas. It's like, who want to maintain five different versions of block, TBL, PHP, if the only difference is the classes applied to it? So what we want to do instead, we want to use our template PHP, and we will use preprocess functions and alterhooks. And we can go in and we can inject our classes very easily through almost any kind of content output in Drupal. And we always only have one template PHP, hopefully. We can have 200 template files, but we only have one template PHP. And when we change something there, that changes affected throughout our site. That's a really great idea. Before we do that, though, we want to go back to views. I talked earlier about you could define your markup, send it to your silentbindles, and have them build stuff out of the box to use the right classes. Well, if they didn't, you should go back to views. And views allows you to override both the markup and the classes for both the wrappers, for fields, for rows, for almost anything labels. You can go in and you can add your own classes. There's no reason to go in and override stuff later on if we can just define it to be correct to begin with. So this usually solves 50% of your theming needs views. Like your mileage may vary depending on the kind of site. But for the rest, we need to go into template PHP, and we need to take a look at these scary render arrays. Render arrays was introduced in Drupal 7. And it's a set of nested arrays and objects, and they can be nested almost infinitely deep. And when your new theme are coming into Drupal, they can be really scary. I think, actually, that the render arrays and the templates of PHP is one of the reasons that so many people try to do everything without having to touch it. We understand CSS, and we just want to apply that CSS, don't have to worry about doing some recursive manipulation of a huge nested array, which structure we don't understand anyway. I'm just curious, like, what today? How many of this very small, intimate crowd I have are comfortable manipulating render arrays in preprocessed functions of hooks? OK, some, but definitely not all. Good. The good thing for us is render arrays are not consistent, I'm afraid. But they are mostly predictable. And for our needs, they are especially predictable. These three nested arrays will get you 90% of the way injecting classes into your theme. So when you go into your preprocessed function, and you look at the array, we have three nested arrays. One is the classes array, and the classes array contains all the classes that are added to the outer wrapper, for instance, around the block. We have a title attribute array, class array. These are the classes that are added to the title. And we have a content attribute array that is added to the content wrapper within the outer wrapper. And by adding or manipulating, by adding or overriding to these arrays, we can control which classes gets output in Drupal by Drupal theming layer. Some modules do even some base themes. If you saw in the Jane session, you would know that especially annex base themes will go in, and they will change your render array. The themes like omega will strip out. No, we won't even strip out. But the classes array certainly no longer adds anything to your wrapper classes. You need to go into the attributes array, class array, and add things. But go in, print it out. You can use functions like KPR or DSM. You can inspect the render array, using tools, and just figure out the structure. And just ignore everything that you don't know what is and you don't need. I still don't know what the difference is between the content inside the element block array and the stuff inside the block object, because it seems to be the same. But it's not important for us. And this is the result we get out. So what do we add to our classes array? It gets output on the outer wrapper. What do we add to our title attribute array, class array? It gets output on the title. And what do we add to a content attribute array? It gets output on the content wrapper. And this is, more or less, what we need to know about render arrays for now. This will allow us to inject classes. And it will actually allow us to keep a separation of content and presentation, just not the same separation of content and presentation you are used to from web pages. With web pages, we had a content that was usually our markup. Then we would have our presentation layer that was usually our CSS, or always our CSS. And maybe sometimes we had a behavioral layer that was some JavaScript. In Drupal, we have a separation between content and logic and presentation. So we have all our nice content inside a database. And we all know we can present that content in 17 different ways, using Drupal and views and panels and this space read. We have our structure and logic, which is handled by all our Drupal modules and our configuration. And then we have our presentation layer, which now not only includes our CSS, but also templates, PHP, and all our files. So we still have separation of presentation and content. Developers can change the structure and logic all they want. The content editors can change their content. And we just go in when rendering our presentation. And we inject our classes and dominate their markup. The way I prefer to do this is with a switch. And switches have several advantages. One is that they are very easy to maintain and easy to understand. In this case, I'm going in and I'm manipulating the field and I'm adding classes to fields based on the field name. And it's just one long list of all my field names. And I can group them. I can say, all these share this same class. I can group them, and I only need to write the class name once. I can even omit the break, and they can inherit from the stuff that comes below them. So I can say that whatever is on my body and my field deadline should also always be on my field location. But what's on my field location should not be inherited to my body. This makes it ideal because it's fast to write up. It's very easy to go in. You don't have to spend a long time doing this. And when you have to add to it, it's easy to go in and just add new rows to this. It's also easy to inherit from others. So if you take over a project, it doesn't take a lot of time to go in, take a template pre-process field, and see the list of field names, and see what's going on. Often you want to combine this with some kind of condition. Maybe when you are rendering your panel panes, if you're using panels, if what you're rendering as a panel pane is a field, you want to manipulate that field and add classes based on the field name. It could be other things. We could switch and anything. You could go in and say, well, if the block has A, I want to do a switch based on B. More or less only your imagination and that of your designer that puts limits to this. We can switch on a lot of different things. These are some of my favorite field name or block name. Field name allows us to maybe have four different styles for our fields, but we have 52 different fields. We could go in and just easily group those fields in these four styles in one pre-processed field function. Defining module could be useful if maybe you want everything that's navigation in a logical sense. You want to output that in a certain way. You could say, if this is defined by menu module, menu block module, or taxonomy module, I want it to look in a certain way. Again, you could theme by region. So if your blocks are output in your footer, they will look different than when they output in your sidebar than when you output them in your header. This allows your content just to move stuff around. Just go in and move the block from the footer to the header, and it will still be styled correctly. Again, you can combine this. You could do it by path. You can add classes to your body tag based on the path, for instance. We can go in and we can combine these switches with different functions. We can do this on the page, on the HTML template, if you want to add to the body element. Blocks, regions, fields, preprocessed panes, views would take up in a complete slide with all the views preprocessed function we have. So when we start combining these switches with all these preprocessed functions, we get a high degree of flexibility in injecting what classes we want into our theme and defining objects. There are three exceptions to this. What's menus? Menus don't have a render array in the same way as a block would have. But we can still go in and we could add classes to the wrapper around the menu. In this case, if we wanted, we could call theme menu tree and we could add the same class to any module, any menu that was output. Or in this case, we could call the theme menu tree and the menu name. And for this specific menu, it would get some other classes added to the wrapper. Another one that usually throws a wrench in the smooth object-oriented theming engine is multi-fields. Because out of the box, what Drupal will do is all these nice classes that you define in the render array that just showed you will get added to the wrapper around your fields and not to the fields themselves. It gives a lot of trouble because we didn't want four fields inside a huge button. We wanted four buttons after each other. And you can solve it in seven different ways. You could overwrite the theme field function. And you could add the classes to the fields themselves, not the wrapper. The easiest thing to do, the quickest thing to do, was go in, take a copy of field to BLPHP, throw in your theme. And then there, you can see that the classes are output on the wrapper and just move them down and output them on the field itself. If you're worried that if you want to control and say, OK, in some situations, I want to put my classes on the field themselves, in certain situations, I want to put my classes on the wrapper, create a field multiple to BLPHP. And just when you need it, go in. Use a switch, exactly like you saw with the classes, and just give it another theme hook suggestion. I won't show how, but in the code examples I linked to, there are comprehensive examples of pointing fields to your own template suggestions. And you can do it in the same way as you do with the classes. You can say, like, for these 17 fields, they should use the multi-field, and for these four fields, they should use the single-field BLPHP. The third one is forms, like forms. I'm lying now, but forms is the only thing that's scarier than the render array. Just believe me, because it'll make everything easier for you. If you realize how many scary things there are in Drupal, you don't want them. But forms are tricky, because they can nest inside themselves. The elements inside your form can be nested inside field sets, and these field sets can actually be nested inside other field sets. And sometimes things are just nested inside something that's not really anything that just the developer would like to group stuff. So what you need to do is go through your array recursively, and look for anything that's maybe an input button and add the class. And what I did was I called up a developer, and I helped him write an example function for us. So I put it into the toolbox, and you can go in there. You only have to define your switch once, and it will recursively go through your form, and it will add these classes where we want them in the form. Again, I won't be going through the code itself, but it's in there, and you're very welcome to just copy-paste code from there. So that was about it. So what we did was we took a look at what was wrong with a very common approach to theming. I tried to show you another way to do it, and what some of the benefits are of that. I outlined a four-step plan of getting this into your workflow that was analyze, streamline, define, dominate. After the session, we shall be chanting this outside. And then I showed you some tools for domination, how you can go in and have your classes injected from the theming layer into the markup when your site is being presented. So that was about it. Online I have the slides. I took the liberty of creating a short link, but you can also go into the DrupalCon website. Or if you're watching this on the DrupalCon website, later further down the side, there's a link to the domination tools, and there's also a link to the fireworks stencils I created. They're very simple, but again, it's just a quick way of writing markup on site fireworks comps. Thank you. Are there any questions from this very intimate group? Yeah? OK. The question was, how can you sleep when Morton is snoring? The answer to that is you actually can't. I have often experienced I had difficulty falling asleep when people were snoring. But this is the only case in my life where I experienced being woken up by somebody who was snoring, because he was snoring so badly, even after I fell asleep drunk. He woke me up. I had a question earlier today. I just repeated, which was about I keep saying that we want to do this in template PHP and inject all our classes. And then I suddenly said, you should go back to views and start adding classes inside views. Isn't that inconsistent? And it is, but for good reason, it's inconsistent. When we go in and we add our classes in views instead of adding them in preprocessed function, we give our site builders the ability to output completely styled new content and new page types on our site. So if you create them a style guide, or if they have seen your handwriting on the printouts, they can go in and they can define new lists with completely new content in it, but just by adding your objects into different fields and wrappers and list items, that content will get output styled completely. And so this is what I was talking about with extensibility. You want to be able to deploy new content. You want to be able to expand your site. This is a living, breathing thing. It's a web system. It's not a page. And you want to do that without having to call up the FEMA every time you add a new list to your website. And that's the reason we want to do it. And we want to do it in views. And the reason we want to do it consistently is to help you find it. So you know that if you go in and you want to change the classes getting added to something. If it's a view, the first place to go is going to view and look in the style overrides. If it's not a view, we're going to template PHP and look there. So it's not consistent. But it makes sense from a business standpoint. It allows you to deploy new features much cheaper. Yes? This is perhaps not only CSS, but overall structure changes. I've often had problems where I'm trying to modify the output in some way. And I've found a hook that should work, and the documentation sneakily says, modules can use this hook. And what I find is that I can't use it in my theme or my template file, because somehow it just doesn't work well. Are there any tricks to solving these problems or handling them better, or is it just a floor and dribble that they also don't work on the theme layout? The question was, you can go in and you want to achieve something, and you find a hook to do it. And it turns out that hook can only be called from modules. I'm not sure it's a floor. And the question was, how do you get around this? I'm not always sure it's a floor. Sometimes there are good reasons that certain hooks are only called at certain times in the rendering process. Other times, maybe we're talking a floor. In Drupal 7, I think almost any alter hook can be called in your theme. If you wanted to, and you really wanted WebCheck to shoot you with that famous gun, you would call a hook query alter in your theme and just write sleep10 or something. And every time an SQL query was like, your site would wait for 10 milliseconds just to piss somebody off. So you can do a lot of things in your template PHP you can't do now. But the only workaround is just write a module. I was very intimidated by writing modules until I found out that modules consist of two things. They have an info file that says what the module name is, and if that module has dependencies, you have to write them on a line. And then it has something that's completely the same as template PHP. It's just called .module. And in there, you write your alter hook. So just create a module. I always have a stack of site-specific modules that I've created. It could be something like maybe I have a bunch of ready-made features on my site that defines everything. But for this site, the image styles are different. Don't fret about it. I'll just write a module. It's literally 10 lines of PHP. And I will have customly overwritten my features with new image styles, for instance. So if you need to invent a new image effect, just do it in a module. I don't know if anybody else has a good solution for it. But it turns out modules are even simpler than themes. Or they can, at the basis, they're even simpler than themes. I'm not saying you should try to figure out how C-tools work, but writing a module that consists of two files doesn't take long. This is my best back. Cool. This is the end of the dominate the theme layer, redo, director's cut. There will be an unrated edition that will include pictures of Morton DK, and they will be uploaded online. And if anybody is able to get their hands on the famous video of Morton stripping at the DrupalCamp, DrupalCon DC, I'm very happy to include that also. Thank you. My name is Gordon. I saw me here.