 Just so you know, the slides are already uploaded on the session, so if you want to download them to follow along, that would be great. So you know, there's a lot of code snippets and examples throughout this session. And we're going to be comparing twig templates and PHP template from Drupal 7, the PHP template, and Drupal 8 using twig, so I'm really excited and let's get started. So real quick, my name is Larry Wallangatan, here's my Twitter handle. I work for Chromatic. We have team members all across the United States and in Europe. Check us out on Twitter or online. Let's just dive right into it. So PHP template, this is a theme engine. If you're not familiar, I'm sure many of us are. That powers Drupal 7 themes. It allows us to create reusable templates to render dynamic markup. And it's a mix between HTML and PHP, which is good and bad at the same time. But when we move on to twig with Drupal 8, we have a major shift. We're using twig as our theme engine, and what is twig? It's a compound macro language, and it's all about abstraction. Now, this is a big shift from Drupal 7 to Drupal 8 using twig. But you might ask, why are we using twig? What was the impetus? What was the reason that we changed? And there are two major reasons. The first reason is jobs. If you know HTML, you can quickly pick up on twig without having to program any sort of PHP. That wasn't truly the case with Drupal 7. Also, with the abstraction, it masks the complexity so that front-end developers from a different paradigm are able to come into Drupal 8 and start building templates. So twig walls off PHP completely so that we can just focus on learning twig and its conventions, which is what we're going to do throughout this talk today. So twig is not PHP, just to be clear. A few pros for twig, it's easier, in my opinion, for non-developers to pick up than PHP template in Drupal 7 is. All you need to know is HTML and twig conventions, and you can get started. So we're just going to be taking a closer look. Now, if you're familiar with Drupal 7 and the theming system, we're going to be doing a lot of comparison between Drupal 7 and Drupal 8. So you have a frame of reference. If you're brand new to Drupal, which is perfect and great, we'll be introducing you to twig here. And you'll also be able to backport some of that knowledge to Drupal 7. So let's just get started by taking a look at some code. Now, these are both lifted from a core theme, Bartik. One is from Drupal 7, the node.tpl.php. One is from Drupal 8, the twig file at the bottom. Now, they're both doing the exact same thing. And as you can see, the syntax is definitely different. On the top, we have PHP declarations later throughout. And in the bottom, we have a bunch of curly braces. Now, if anyone is familiar with Jekyll, twig looks a lot like Jekyll. So if you have any sort of experience with that, it'll be useful to keep that in mind. So we're going to be going through each and every one of these topics systematically and comparing the difference between Drupal 7 and Drupal 8. I'm going to be using Drupal 7 in place of PHP template and Drupal 8 in terms of in place of twig. So this is all that we're going to be covering. We're going to go through each and every one of them. And hopefully by the end, you'll be familiar enough with Drupal 8 and twig that you can get started with creating templates with twig right away. So let's look at creating templates. In Drupal 7, we have all of these core templates that are available to us. Now, there's a ton of these. But they're super useful because if we want to create a template, all we need to do is go and find our template file within modules slash the star is a placeholder for the name of module, like node. And we can copy and paste the template file into our theme file. And that template file in our theme file will then override what's being output by default. So that's a super helpful way of creating our own templates and creating custom templates. Now, if we create custom templates, we have to deal with template.php. Now, in this example, we are taking the node.tpl.php file and creating a promoted node.tpl.php file. So that if we have a node that has the promote flag on it from our configuration, we can tell it that we want to use the node promoted template file. So we're using theme hook suggestions we're going to cover in great detail very soon. But this is just a quick example of how we would create a custom template. We'll revisit this soon enough. But first, let's take a look at how we create templates in Drupal 8 and Twig. So in Drupal 8, we don't have to explicitly define where a template lives. We just have to place it in its expected home, which is the templates directory of the theme. This is all based on routing. And it's also based on naming conventions. These are two things that we're going to cover routing in detail in this session. But we are going to talk about naming conventions so that we know how to create templates and how to override templates within Twig and Drupal 8. Also, if you want to create subdirectories within your template directory in your theme, that is possible. You're able to do that by altering the hook theme function or the hook theme registry alter function. If you, for example, wanted to have your custom theme templates and then within templates, something like custom templates for anything that is purely custom that's not based on any of the templates found in Core. When we talk about overriding default templates, we're going to revisit what we just saw. Here we're overriding the page template in Drupal 7 and giving it a page template for every single node type using template.php and then the hook preprocess page function. So we're checking to see if a variable for a node type is set. We're going to set a theme hook suggestion of the node type. Now, there's a hierarchy of where templates are rendered and how they're rendered. And we're going to cover that in naming conventions. So keep naming conventions in the back of your mind. It's something that we're going to talk about, because it's really important. Personally, it took a while for me to wrap my mind around how certain templates got printed. So in Drupal 8, it's much simpler. We just have four steps. These are directly from the documentation of how we would override a default template. First, you would locate the template you wish to override, which is usually in Core. You copy that template file into the location of your theme folder, which is theme slash, or the name of your custom theme slash templates. According to naming conventions, which we'll be looking at soon. And then you modify that template to your liking. Now, this is a really big overview of what we're actually going to be doing. Everything else is going to be a top-down approach. So we're looking at the very top, and we're going to get into the specific details within our templates. So now we have creating templates. We have overriding default templates. Now let's look at the theme hook suggestions. Now, if you didn't know, a theme hook suggestion is an alternate template file to use for a particular instance. Now, let's take a look at how these are done in Drupal 7. There are a lot of theme hooks that are available to us. Pre-process hooks are ones that are super popular. People are usually very familiar with this is one that we've seen already when we were creating our own custom template. And if you take a look, though, we're using hook theme suggestion right here instead of hook theme suggestions. Now, that's a very key difference. And it can lead to a lot of headaches if you're not familiar between the difference between theme hook suggestion and theme hook suggestion. So let's take a look and just dissect that really quick. So they're not equal. In template.php, these things are not the same. Theme hook suggestion only accepts a single suggestion, and that takes precedence. So if you want to override something and you don't want there to be a fallback, theme hook suggestion is the way to go. Now, theme hook suggestions, it takes an array of suggestions that you pass in, and it prioritizes them with the first and last out order. And it cascades based on specificity. And that all goes back to naming functions. And that we'll discover in debugging will make this a lot easier. So let's take a look at Drupal 8 really quick and the theme hook suggestions that are available to us. Now, we have several more theme hook suggestions that are available within Drupal 8. And this is all in the custom.theme file. I might have glazed over this earlier. So in Drupal 7, you have template.php, where a lot of your preprocess functions and hooks live for your theme. In Drupal 8, we have a theme.theme file. Since that's really confusing when you're looking at it on a presentation, for all of our examples in Drupal 8, we're going to be using custom.theme. So custom is the name of our theme.theme is the name of the file. And we have each of these suggestions and what they do. The first one, it alters name suggestions for theme hooks. Second, you can see for a specific hook. And then finally, alters suggestions for a specific theme hook. Now, also different in Drupal 8, you can see that we have passed in by reference is this suggestions parameter on both of them. And this is really important because it's really different from Drupal 7. That's something just to keep in mind. Now, we have a dedicated hook here. This is just a quick example of how we are, our goal is to create a custom theme template using our hook theme suggestions hook alter so that we in the end call the right template for our file. So what we're trying to do is we're gonna modify the user template, say, hey, we want our user to have specific templates for specific view modes, which we said in our configuration. So when we do this, this is what template, this is what Drupal is gonna be looking for in terms of a template. We'll have our user dash dash custom view mode, whatever that name is, whatever the names you set in your configuration are, that's how you would use a theme suggestion in Drupal 8. This is just a standard overview. We're not gonna go super deep into all of the rest of the theme hook suggestions. This is a great example. For example, if you wanna modify node, you can follow it in a similar fashion using custom suggestions underscore node alter, so on and so forth. Now naming conventions is something I keep talking about and it's worth spending our time dissecting what naming conventions mean in Drupal 7 and Drupal 8 because they're very similar for our example.com slash node dash one. So this is the front page of our example website. Naming conventions will determine the theme's hierarchy of what template gets called in what situation. So it starts from the most specific and it goes down to the least specific. So it looks to see, hey, do you have a page dash dash front if your node slash one is the front page? If not, it'll go to page dash dash node dash one. If not, page dash dash node and so on. It'll continue on down until it finds the right template to render. Now we set these things in template.php using our theme hook suggestions but understanding the hierarchy is important especially when we come into Drupal 8. As you can see it follows a very similar hierarchy and this is just an example for page templates. Note that there are similar naming conventions for regions, for blocks, taxonomy terms, comments, fields, search results. There's a lot of patterns on Drupal.org that are well documented. I haven't included them all in this talk just because there are so many of them but they all follow the similar sort of hierarchy from the most specific to the least specific and you can set the specificity yourself so that you can determine which twig file gets called. Now let's talk about some of these, the actual code within a twig file so we can understand and see the differences that are displayed. First we're gonna talk about variables. Now in template.php we're revisiting this again. We have our preprocess function and we're setting it our variable of foo, we're setting it to a simple string of bar and in our node template we are printing it out so we can access that by going to PHP print our variable foo and that will render bar, a fairly straightforward example. Now let's look at what this looks like in Drupal 8 with twig. The only difference at the top is that instead of template.php we're using custom.theme. We're still calling a preprocess function, we're setting the exact same way but within our twig file we don't have any of those PHP declarations anymore, we just have opening curly braces, the name of our variable, closing curly braces. Now let's take a look at a comparison between the two, as you can see at the very top, exactly the same whether in Drupal 7 or Drupal 8. Within our node template file and within our node twig file the difference is clear based on the curly braces and the PHP declarations. Now this is a template of what we're gonna be going through for the rest of this talk with the slides, we're gonna see Drupal 7, we're gonna see Drupal 8 and then we'll do a direct comparison between the two so we can see how one translates to the other and vice versa, so with conditionals. It's important to remember that we don't wanna have any real business logic within our template, that's a really big no-no but we do wanna have control over if things are displayed. So for example, a conditional here, we are checking to see if the URL variable exists. If it does, we're gonna print our URL and as an anchor tag and then an image, so you can click on the image, go to the URL. Now if it doesn't exist, you're gonna print just the image so your image is just there. There's some notation that you should just be aware of, there's semicolons after the conditional statements. If you don't have those there, you'll get some errors on your page. Conditionals in Drupal 8, it's very similar but we have opening curly braces and the percentage sign and this in twig is something that's really special is that it's much more readable in my opinion. So you have if URL variable, you can print it out, print out your image, otherwise just have your image. As you can see, they're very similar. There are more conditionals though besides just if we wanna take a look to see of other conditionals like if set or empty. So on the left we have PHP template, this looks a lot like just straight PHP. You're checking if something's empty, if not and you're also checking if something is set on the left. Now what's interesting is on the right with twig, we're using keywords that are sort of like natural language. So if URL is not empty, you'll print your link with your link and if URL is defined, that's how you would define an is set within twig. So following down this whole, we're gonna continue with control structures which is the logical next step after we've looked at conditionals. So very common control structure is a loop. Now in PHP on the left we can see how a loop is defined, we use a foreach, we iterate through them and we print rows. For PHP template we have to make all those PHP declarations throughout. Now let's take a look at this in twig. It's not quite PHP, it's not quite PHP template, it's something in and of itself but it's also similar to natural language. So for row in rows, show row dot content. Now this is our first exposure to dot notation which allows us to access an attribute on a variable and in this case each row has a content attribute and that's what we're gonna be printing here. PHP template versus twig, we can see in this example just how they compare. Filters are important because they allow us to manipulate strings and arrays. There are some that are available in both Drupal 7 and 8 and we're just gonna cover those in brief here. So we're gonna look at check plane, translating with substitutions, imploding and escaping. Each one of these has its own use so I'm sure many of us might be familiar with what each of these do. The T function for example will allow us to translate a string. We can also have substitutions that need to be translated. We can implode an array so that things are concatenated and then we can also check plane which encodes special characters in a plain text string to display HTML. Now the echo and the print at the top and bottom, those things are, they're not relevant for this talk, I just wanted to add a variety here. Now in twig we are doing the exact same thing but we have a different kind of notation. We have our variable or string followed by pipe and the filter that we mean to call. Notice that in the translation filters we are not passing in a variable directly. That's a no-no for a variety of reasons. The translation documentation online has a lot of best practices about how you translate links, dos and don'ts, et cetera but this is just an example of what translating looks like in twig. Note also that there are many more filters available to us in twig and Drupal 8. This is just an example of a few of the common ones just so that we can compare them with Drupal 7. If you compare it left and right, it's another example that you can see how each is translated to the other. Now in twig we have something special that we can chain different filters together. So in this we're getting an array of user names, we're gonna concatenate them with a safe join so we're printing out user names and then we're gonna use another filter that's available to us called lower which is just going to output all of that text in lower case. So we are able to call multiple filters in a call. Now there's specific documentation on how to do this. Using this with translation gets really tricky and with links so if that's something you wanna do be aware that there's some security implication in that and that it's worthwhile to check out the docs online about examples that are good and bad. It's well documented but it's outside the scope of this talk. Okay, links. We're gonna do a quick overview of links. Drupal 7, we have a few utility functions that are available to us. Drupal get path, it returns the path of a system item. Path to theme returns a path to the current themed element. We see that in template.php we can define a custom URL variable and get the path to the node. This is an example of how you translate the node's path into a variable so you can print it out on the template. And you do that in custom URL.php below. Now in Drupal 8, we have two functions that help us generate links based on the route. So the example I've used for the URL function could be used with a path. This is just an example of how to get an absolute route and that's essentially the difference between URL and path. One is relative and one gives you an absolute URL. Render arrays are key value pair that we can pass to the render function within Drupal. This already exists in Drupal 7. So let's take a look at how that's done in Drupal 7 before we take a look at what that means for Drupal 8. So on the left we have template.php and we have two different variables that are defining the exact same thing. So in Drupal 7 we also have the theme function so we can call our theme function and pass it in parameters such as image and then an array with a path and an alt. And then on the right we can print out that variable in our template with just a simple print and the variable name. In using a render array, we essentially set up the variable as an array. So we're using all of the same parameters for our image but on the right in our page.tpl.php we're calling the render function and we're printing out the logo. Now if you just did a simple PHP print logo on a render array, you're just gonna see the words array on your page where you expect to see the image in this example. So if that's something you run into, remember that you have to call the render function on a render array for Drupal to render it. Now in Drupal 8 the theme function does not exist anymore. We only use render arrays when we're generating our custom markup here. So we print it out just like you print out a simple variable and this will be rendered by Twig and the Drupal in Drupal. So let's take a look at how each is done comparatively render arrays in Drupal 7 and 8. We see that the way that we create the render array is exactly the same in Drupal 7 and Drupal 8. So if you start making a habit of using render arrays in Drupal 7, if that's something that you're doing, the transition in Drupal 8 will be a lot easier. The only thing you really need to be aware of is just the Twig notation of calling in the variable because you don't have to call in the render function anymore, which is great. Now there's a few deep dives into render arrays if you really want to understand all of the different parameters that can be passed and all the different things you want to do with render arrays. One of my colleagues, Gus Childs, he has a blog post and then also Drupal session from Drupal Kanyu Orleans about understanding render arrays in Drupal 7 and in Drupal 8. Now this is probably my favorite part. Debugging is incredible in terms of helping us develop well and efficiently. So in Drupal 7, we have the develop module and develop themer. So in our template.php, we can call our variables, pass that into DPM and then we'll see our output on the right, which is a collapsible array that allows us to go through and check each and every variable that's available to us so that we can then modify it within our template.php file. Now in our settings.php file, we can set theme debug to true. Now this is something that's new and I don't know if everyone's using it yet, but if you have Drupal 7.33 or above, it's something that was back ported from Drupal 8 into Drupal 7. And we'll see an example of what this looks like in Drupal 8 in a moment, but it's the exact same output that's generated and it's very helpful in terms of understanding how naming conventions work in our theme and seeing what's being called in. So the big block of text on the right, this is an example of the debug being true. So if you were to inspect in Chrome Inspector or in Firebug, you would see all of these comments within your HTML to show what the theme hook is called, what the file name suggestions are available to us. And then also the output where it begins and where it ends. So this would be really helpful when you are new to Drupal 8 and Twig theming to be sure to turn on in your services.iaml file in the Twig config that debug to true and then auto-reload to true as well. Because if you don't have debug to true, then even using the develop module, you won't be able to do that and you also won't be able to do some of these functions. So at the top we have within any of our HTML.twig files, you can call dump, which would just generate the list of all the variables that are available to us in the current context for our template. So if you're in a node, it'll generate all of the node variables. If you wanna look at a very specific variable, you can actually pass that in and investigate it there. And then the develop module, it's also still available to us, but instead of calling DPM, we are calling kint at the bottom. It generates output that's very similar to what we saw in the last slide, which is just a collapsible array of key value pairs that we can iterate through. Now coding standards are something that a lot of people take very seriously within every community. So let's take a look at the coding standards within Drupal 7 and then with Drupal 8. We don't have to mention every single one of these, but this is just something for a frame of reference of coding standards that are adopted in Drupal 7. In Drupal 8, we're adopting the coding standards, and these are ones from the Drupal documentation about what you should follow when you're using twig templates and denting the code inside of tags, as we see in all these examples, and then using lowercase and underscore variables. Now this isn't all that we're having to abide by because twig itself has some of its own coding standards. So you place only one space before, after, or before and after each of these elements here. Now remember that you can just go back and reference these. Twig also determines that there are no spaces before, after, before, or after this. So on twig's documentation it has all of this. It's not as easily organized because it's just a list of things. This just shows if you need help because the coding standards are out of whack, you can just reference this. So this brings us to the end of our talk on twig. So we have some time for questions. Just a reminder to join us on Friday for our contribution sprints. So we have some time for question and answers real quick. If you wanna evaluate the session, please do. It's here. If you wanna leave to head out early, that's perfectly great too, but questions and answers. Yes, and also could you come and use the mic please? Yeah, hi. From my experience when I used the kind function into twig with four gigabytes dedicated to PHP, I got the memory exhausted error. So do you have to suggest any other ways to actually debug into twig? Yeah, so a real quick follow-up question to you is where you're calling the kint. Were you calling it in your theme or were you calling it in a template in the twig file? Okay, yeah, so kint, if you just call in kint without passing in anything, it's gonna try to get all of the variables. So are you passing the variable inside? That is an interesting problem to have. I know that it is common that if you call like the dump variable within twig, or you call in kint, which is just doing a nicer version of that by rendering it into collapsible arrays. Depending on how your site's set up, if there's just a lot of custom variables or anything, it can cause a lot of issues. Now, in your example specifically, I would try to go to the most specific twig file that you can find that you need to look at. And if that doesn't work, we can exchange our details after this and then we can go back and forth about how best to resolve that. Yes? It's twig-like in terms of erroring, like is it quite hard to call it PHP or give you white screens of death if you get the syntax wrong? Or is it quite forgiving? And also, where does it log? Does it log like PHP to error logs and stuff? Yeah, so twig is a part of symphony and there's something that I kind of glazed over with this and with debugging. If you install the Drupal console, you can have a lot more information. Now, you can find that on Drupal.org about how to download and install your Drupal console so that you could take a look at those errors that are returned. So symphony itself has its own specific error logging that we can take a look at which twig is an extension from. Drupal also kind of hooks into that. So white screens of death. In my experience, I have experienced them so that is frustrating still but we do have a few more tools to help us. So the biggest thing in my experience that has been helpful is just turning on the theme debug. If you have that on, then you can slowly go through your code to make sure where things are happening and if they're happening correctly. Also, just to note that I forgive me that I didn't mention, when you turn on theme debug, when you deploy to production be sure to turn it off because it'll just ruin everything. So just keep that in mind. So twig gives you a lot of power with filters and all kinds of stuff. Have you seen any changes in the way you build template files with regards to business logic or is it possible to do more of that in twig files since you can do a lot more with a lot less code or would you recommend still keeping all of it in a pre-processed function? So it depends on your use case but my preference is just to keep those either in pre-processed functions or it's something that we didn't cover in this talk about theming is to have custom modules that then have their own custom template files within them which can also abide by similar naming conventions to override certain things so that we keep, even though filters are super powerful, there has been a lot of discussion online about the use of those and a lot of great examples of what not to do when you're using different filters specifically when it comes to translation links or anything that a user might be entering into your system that is displayed in the twig file is something to be very cognizant of how we would handle that. So keeping those in like that business logic in its own separate place is the current preference. Well, if there are no other questions, since this is the last session I wanted to make sure it was short and sweet so that we can all start our nights a little early. Be sure to evaluate the session, Drupal.org, download the slides if you want some reference. All of my information is also on the slide, I mean is also on the session online so if you wanna contact me directly about anything you've seen here today, feel free to do so. One other thing in the plug, there's a twig channel on Slack with a lot of very, very friendly and helpful people if you have any more questions. Just go to that twig channel, I'll post that, I'll edit my session so that that link is there as well so that you could continue learning Drupal 8 and twig with some support. So thank you very much.