 Alright, so in the interest of leaving as much time as possible for questions and discussion at the end, we're going to get started. Welcome everybody, my name is Ivan Booth and I'm the Drupal Con front-end track chair. I'm a freelance developer at rootwork.org and I'm happy to introduce three of the folks behind Twig and Drupal. Twig, a part of Symphony, is being adopted in Drupal 8 as long as some Twig sprints go well on Friday, so I'm sure they'll talk more about that. I'll leave it to these three to explain why Twig is so great, but I'll say that when these folks presented at bad camp, there were literally gasps of joy from Drupal themers. Not something that happens very often. So to quickly introduce these three, Jen Lampton is leading the charge to overhaul theming in Drupal 8. She's been a contributor to the Drupal community since 2006 and maintains modules like total control admin dashboard. She's also the lead coordinator of Bay Area Drupal camp, despite her lack of an eye patch. Bad camp, that's a pirate theme. She does, however, like horses, which makes sense because Twig is basically a pony that everyone gets to have. Fabian Franz was born on the same day as the new operating system and has pretty much been contributing to free and open source communities ever since. He's been a contributor to the Drupal community since 2009 and is a technical lead at Trellen. Fabian has been helping Jen get Twig in core, which makes sense because Twig is going to make Drupal themers dance. And John Albin Wilkins has browsed the entire worldwide web, literally. So it was 1993 and consisted of two websites, but still, how many other people can make that claim? And he found the web pretty ugly because since then he's been making websites more usable, accessible, and beautiful. He works at Palantir and has made foundational contributions to CSS, SaaS, and Compass, mobile and responsive web design. He also maintains a little base theme called Zen, which happens to be the most installed Drupal theme ever. In his spare time, he enjoys playing with lemurs at his home in Taiwan, which makes sense because when themers look at Twig, they're going to go, ah, so with that, please welcome Jen, Fabian, and John. We had some intro slides. We're going to skip right to the point. So Drupal 8 is going to have a new theme engine. We evaluated a bunch of them very early in the process and decided on Twig. Twig is a PHP templating engine that is already very well documented. So Drupal itself has a little bit of a problem with creating great documentation, so we're really happy to be adopting a framework that already has documentation of its own. Twig is also extendable, which means that we've written extensions for Twig that work specifically for Drupal, but also anyone in the contrib space can come along and further extend Twig to meet whatever needs they have to, so we're not relying on getting it exactly right the first time through, which is good. Twig is also secure. The security team has been complaining about 100% of all Drupal themes with a little rounding error being insecure. And that's just because it's really hard to do it right. With Twig, we can put some protections into place that'll prevent all of the security holes that we're dealing with right now. Yeah, there's still some work going on. So that's also a possibility to sprint on. If you're on the security team and want to make it better. Twig is also really fast. So compared to some similar templating engines like Smarty, it leaves all the other ones in the dust, so we're really happy to be using something that's not going to be slowing us down too much. And it also has really great IDE integration. It turns out, go ahead. Sorry for the fast. For those that have been profiling Twig, there's one number that's standard out 0.3%. So Twig also integrates really great with IDEs. So anyone who wants fancy syntax highlighting is going to get it, which is really great. Can't get that right now with PHP template. And it also looks recognizable. So even if you've never heard of Twig before, if you've used any of these other languages, you'll be able to parse the files and scan them and read them in ways that make sense. Twig was also written by the creator of Symphony, which we're also adopting for Drupal 8. So those two systems play really nicely together. Who wants to see what it looks like? No one. OK, well, you can go then. Thank you. In order to print a variable, you use the syntax with two curly braces on either side and just type the name of the variable. In order to drill into a variable, so if your variable happens to be a more complicated data structure, you get from the top level to the second level by putting in a dot. And that's exactly the same, whether it's an object, an array, or anything else that we can come to invent in the near future. If you want to get something inside, you just type a dot. By the way, there's tons of chairs over on this side. I know it's hard to see from the door, but chairs. If you want to add a comment into a Twig template, it's a curly brace and a pound sign. And if you want to run commands, so if statements, four loops, you use a curly brace and a percent symbol. And we'll show you some actual code a little later too. Wrong way. So we had rolled together a bunch of patches that converted all of the PHP template files in Drupal 8 into Twig files. We got it ready at about 11.30 p.m. two nights ago. And since then, I started trying to actually use it to create a theme. I created one last night. Some of you might have been watching on Twitter. Some of them went really, really well. Some of them went not that well. When I got to the end, I decided that it wasn't really worth me going through the process of creating a theme in front of you. But I do want to walk you through the theme that we created, just so you can see what the code looks like. But I'm going to start off by painting the picture of the site that I was trying to build. So this is usually how I build it. Go ahead. One question before. Who of you have used Drake before? And who of you wants to use it? Whoa. Whoa. More importantly, how many people here like PHP template? Yeah, that's what I thought. Thanks. OK. So here's the premise. We're going to build a website. Home page is very straightforward, just a bunch of text on it. We're going to have a second kind of page that has one of the fields pulled out of the content and shoved into a little side area. And then we want to treat the markup especially so that if there's more than one value in the field, we want to wrap it in a section tag. So we've got some special control we want to do over our HTML. So three very simple things we're trying to achieve here in this theme. So I did happen to put all of this code, please. So I did happen to put all of this code on GitHub if you want to pull it down and rifle it through yourself at your own paster. More than welcome to do that. The Git project is called Twigified, although the theme has been renamed to Twiggy. OK. You will learn a song now. We have actually a Twig jingle. And it's 1-7-5-7-5-5-0. Come review it. Patch be a Drupal 8 hero. So all together. 1-7-5-7-5-5-0. Come review a patch be a Drupal 8 hero. And now you. OK. So we have here this theme that I created. Now that I've got my monitor resized. Where the homepage just has a giant header on it. We've got some content in a straight column. And all that really is is just a new template file for the homepage and a new style sheet. So just really quickly I want to show you the page template. And it should look pretty similar to PHP template right now, if you could see it all. And that's because the first step of making all of these conversions is just getting it working. And the easiest way to get stuff working is not to actually change very much. So right now we just took the PHP template and we're converting it to Twig. Once we get that done, there will be a lot of room for improvements. I know Martin is eagerly waiting to get his hands on the markup so he can change that. There's a whole bunch of people, teams of people who are getting ready to change the CSS. Right now all we're looking at is the syntax of this template file. So just as in PHP template, top of the file starts with a bunch of documentation, points out all of the available variables. This might not be exactly the same at the end when we're done with all of this. But for the most part, it'll tell you everything that's here for you to use. And then when you get to the actual markup, it's going to look a little bit more like markup. We basically have HTML tags. And when a variable needs to be printed, it's just printed in little curly braces. When you need to run some logic on it, it reads a little bit more like English than PHP did. If site name or site slogan, you don't need to worry about dollar signs or is sets or is array and not empty or any of that stuff that you had to do in Drupal 7land. You can just say if site name and print it. So pretty straightforward. We've got a lot of white space in here. It makes it easy to read. A lot of things that should look really similar. There's a couple of differences, variables. Like we said, if you want to render something that's a second level or deeper, you drill into them with a dot. It should be, for most of the stuff you see printed in any template file in Drupal 8, we've got a section at the documentation in the top that tells you what all of those things are. There's also a little method that lets you print out all of the available variables that we're going to clean up and give you a really pretty view into later. So the next thing I want to show you is a node template. And we have Morton. So Morton will make sure it will be usable. Well, you complained so long until it's good. You have been hurt finally. So the node template. What we want to do here is pull out an individual field and display it in a sidebar. I'm not sure how good the color is on these matters I can't see up here. It's just got a little gray background on the side. We pulled out an image and we've just moved it somewhere else on the page. So if we look at the node template, you'll notice that I put in a new little div here called info bar. I've pulled out the individual field content.field underscore image and thrown it in that little sidebar. And let's say we had, I guess I could talk about this now. One thing you'll notice here is a little bit weird. It's got a section of code in here that says block. And what that's doing is identifying a place on the page where you can say, hey, twig, something in this area is gonna be different. And then what we can do, Drupal seven land when you would create a copy of this node template to use for a different node type, you would have to copy the whole thing all over again. Well in twig land, what we can do is create a specific version of it that says here's the article template. It's exactly the same as that node template except for this difference. So in here I've just got a little piece of content that says, hey, this is just the difference of the two templates. So you no longer have duplicate code all over your site. So if I wanted to go and look at what an article looks like that is actually in my blog section, you'll notice that the caption now has some additional text there that says, hey, this is the diff of the original node template and now it's article override. Yeah, the fact that this node dash dash article twig file is literally three lines long. I mean, the significant part of it anyway is like, okay, four lines. But this is a huge win for me. There's so many times I see themes that have like seven or eight node dash dash something.tpl files and they all look almost identical and I can't tell what the heck's going on and when I open up a file. This is gonna make it really, really obvious and just so much better for everybody's workflow. Woo hoo. Okay, so the only thing about that is and we want to ask the Drupal community here, do you find the term block for that confusing? Who finds it confusing? Who would prefer code block instead? Who does not find it confusing and finds it pretty straightforward? So are you all people who've used twig before? A couple. If you used twig before and you called it block and you opened a Drupal file and it was called code block, would you be able to figure out what it was doing? No. So we might need to document that. We might be able to just provide you with both and Drupal coding standards would have code block but block for twig background backwards compatibility would still work. Would that be a good compromise? Who likes that? The question is a twig block the same as a Drupal block and they're not at all. One of the great wins of integrating all these other third party code is that we don't have to write so much and the integration becomes my cleaner. The downside is that everybody has their own sort of terminologies and they seem to conflict with each other. How many people were at this smacks session yesterday and then beat their head against the wall afterwards because of the module and themes and smacks? I, this is a really thorny problem and there is no good solution. I tried to rename block but it didn't go over well. Like Drupal blocks. And I say there is no good solution but really what I really want to happen is I want for you to figure out the really good solution and tell me and me go, oh, obviously. But so just think about it everybody and then come talk to me afterwards, okay? Thanks. Yep. All right, so the next example, what we want to do is treat the field and the sidebar slightly differently if there's more than one of them. So if there's one thing, we just throw it in this little gray area. If there's two of them, we want to wrap it in a section tag. So this is a, you want really fine-grained control over your HTML in particular. This is the code you want to generate. It's a section tag surrounded by a couple of figure tags. Each one should contain only its image and its caption. So I'm going to be overriding the field template specifically for images because these are figure tags. I don't want to roam in every field around my images. And so I've written some code here which checks to see how many items are inside my field. And if there's more than one, it'll print a section tag and then it'll loop through all of the items, print each one out along with a caption which happens to just be caption because that's what I put there. And then at the end again, it checks to see how many items are in there and prints the closing tag if there's more than one. So if we go to a page on the site that has more than one image, it'll wrap it in a section tag which is styled slightly differently in this case. Yay, that's how you do that. Okay, back to presentation mode. So I wanted to go over a little bit of things for trying to solve the problems in Drupal 7 because you're like, yeah, of course it's supposed to work that way but it didn't always go so well. So one of the first pain points that we have in Drupal 7 is the fact that inside template files, there are variables, sometimes they're strings, sometimes they're arrays, sometimes they're objects and it's up to everybody who is using the template files to know which ones are which which can be really frustrating. So here's an example of node template where it uses an arrow to print out the node ID. There's an example of the page template where it uses square brackets and text to get into an array. So in twig, any time you print any one of those variables, you're always gonna use a dot operator to get deeper inside it, so that problem should be solved. The second one is that we actually have two different ways of printing things into our template files as well. Sometimes you just print the variable out like printing classes and sometimes you print render a variable. So now it's up to the person using these template files to know which variables are safe to just print and which ones need to be rendered in order to be printed. So that's also pretty confusing. In twig, we're removing all calls to render from any template, so if you wanna print anything, you just put the name of the variable in there and it'll know whether it needs to be rendered or not and do it correctly. So that problem solved. Right now in Drupal, there are two ways to override the markup that comes out of core. First, you can find a template somewhere in the file system, create a copy into your theme and change the markup there. And second, sometimes the markup you're looking for doesn't actually come from a template, it comes from a PHP function, which is called the theme function. Well, in a perfect world, in twig, we would be able to replace all of the theme functions in all of core with template files. So there would only be a single way of overriding any kind of markup in any part of Drupal. So right now there's two ways. It's really confusing to figure out when to use which one. Sometimes there's one that's provided but it's not actually used and so you've gotta do some magic in order to make your stuff get used appropriately. And what we wanna do in the future is make it so that there's no question. You always go to the same place you copy and change your markup in the same way. We started converting every single theme function in every single template file and all of core to twig turns out there's a lot. And a lot more than even I ever anticipated. And we realized that Drupal 8 should be coming out soon-ish. And so maybe we should just focus on maybe replacing PHP template with twig before we try and rewrite the world. So what we've done is split all of our issues apart into first template conversions and then we'll do theme functions later. So right now if you were to go and play with a giant mega patch it's only gonna convert PHP templates to twig templates. But what we can do is go through all of those other functions later and be like do we need this, throw it out. If we don't need it, okay if we do we need it. Let's see, would it be better served as a theme function or wait, why is this even in the theme system? We have theme functions that don't need to be theme functions. So refactoring the whole thing with a kind of a holistic approach from top down takes time and we wanna do it but there's only so much of us. So come to the sprints on Friday and we can hopefully make this make more sense to people with a single way to override markup. So to do. And the other thing here was that when I mean a theme function is just some PHP code that's pretty fast. It's not even going through the whole templating system. And when we started this process and kind of had this first kind of work in progress mega mega patch which had like all the theme function and everything converted. We did some profiling on it. It was pretty bad because as Jen said there were things like same HTML tag which template was just output and you really don't need a template for that. So where we're going is into a direction where Drupal is still fast by default and talk a little bit more about that later but for everything you can implement template and then the Drupal can ship with some example files and those can be used just copy it into your theme removes the example and you are all set. Yeah and in Drupal 7 the theme system we got a little crazy. We had a bunch of backend developers who. We have pictures. Yeah, yeah, yeah. We, they were like oh this should be a theme function because it has HTML and they just did that like crazy and with twig front end developers are taking control of the theme system and Morton has promised that he will spank any backend developer who, yeah that sounds bad actually. Nevermind. Yeah school, he will school any backend developer. It is true, I will. Yeah on any, the proper method of adding twig file and I want all of us to work together so that we don't have the issues that we've had in the past where the backend developers were just, they didn't have any direction from us and they just did whatever they thought was right and they had no clue what they were doing really so we need everybody to get involved and take control of the theme system. And the front end developers have now taken over the performance department so we are in a good way. So yeah, there's a way too many versions of everything probably because every module developer decided to create their own theme function anytime they had any output to produce. So one of the things we're noticing is that we've got a bunch of different functions that all do the same thing. So what we're trying to do is consolidate and instead of saying you know this doesn't need to be a theme function this does we're saying these two things are almost the same is there a way that we can use the same function for these and in the process of analyzing all of the markup that Drupal normally produces we can put together kind of a set of components that are like these are the standard patterns of HTML that are used all around Drupal and if you need to implement something in the future module developer use one of these things that already exists don't write your own. So we're also going through a holistic kind of what's the most important patterns we see in Drupal and can we create templates that encourage people to follow those patterns instead of slightly breaking them for their own purposes. So these are the lists of all of our template actually this is probably not enough because this is before we had some new modules get into core but this is the code we're looking at cleaning up here. You just need to double that one side to have views added. So yeah just twice as many as you could not pick out in that list. So again this is something that takes a lot of time trying to break down everything we have so we're working on it we could use some help come to the sprint on Friday and we're gonna mark that one as to do as well. So the next problem is insecurity this is something that plagues everyone whether they know about it or not usually more when they don't know about it just because Drupal makes it really easy to do things in a way that's really bad for your site. For example when you need to get at the data of something in Drupal 7 you have a node object there and you can just drill right into it and grab whatever you need and it's PHP so you can just print it right to the page no problem. Well actually that is a problem most people who are doing this don't know it's a problem they don't know that needs to be sanitized they don't know it might need to be translated they don't know what's going on in that data they just know it's there and they can use it so they do. What we wanna do in Twig is make that sanitization happen automatically so that you have a variable there and you can drill into it and you can print it to the page and the instant you say print this thing Twig will go hold on a minute let me get you a safe version to use and gives you what you need. So we wanna make that invisible so front-end developers can focus on what they're good at their HTML, CSS, JavaScript and not have to care about the Drupal and hopefully that'll make things go a little bit better. I was actually creating this set of slides for the first time and I was like well you know what's really horrible is when people put SQL queries in their template files ha ha ha and so I typed one in and then I got distracted by something and accidentally reloaded my page and actually dropped my node table when I was creating the second one. So I was like man our theme system is so dumb it should not let that happen. So another thing we wanna do is make sure that only the functions that we want people to be able to use in template files are allowed so you can't do things like run database queries and get yourself into a lot of trouble when you're working on presentations. So we've got a auto-escape feature in twig that we're learning how to implement for Drupal which will help with the sanitization. We've got three different approaches of how we can turn that on so that'll definitely happen in one way or another and we're limiting the PHP functions that are allowed and there's probably some of you who are like don't take away my PHP, well that's okay. Remember how we said twig was extendable. If you have some crazy use case where you need to add some functions that we haven't thought of, you can do it. You can extend it to do whatever you need. So that's fixed. You can even put that DB drop back. No, no, don't do that, don't do that, mostly fixed. So the next problem is that the language of Drupal, at least in the front end in Drupal 7 in particular was getting too specific to only Drupal. So you're having a hard time onboarding people who are experts in HTML, CSF and JavaScript because they need to know all of the Drupal that stuck into these files. We wanna take the Drupal out and make the files look more like what they're used to working with and also make it more approachable to anyone. So if you know twig, we wanna bring you in. If you know any other similar framework, we wanna be able to bring you in too. And the first place you look when you try and customize something in Drupal is usually in the front end. So we want those files to be legible, readable, approachable and not scary. So the fact that twig is used elsewhere on the web is good. It's syntactically similar to other languages which is also good and it's gonna look a lot more like HTML by the time we're done with it. Less PHP functions, more template files. Hopefully people will find that more appealing. So that's fixed. And the last one, this is really hard to fix, but Drupal right now is running a really, really complicated set of systems in order to generate content on the page. It looks a little bit like this. So if you tried to follow the path of a page request to figure out where some variable is coming from, you'll notice that it doesn't just come from one place and go to some other place. It kind of goes around in circles and triangles and death spirals. Yeah, this was a slide that I presented at DrupalCon San Francisco, trying to explain the new theming system that we just created to backend developers. And it was really, really frightening. And once I laid it out like this, I tried explaining it in 60 seconds or less. It was very, very challenging. But we noticed that once I laid it out like this, that there was some sort of hidden messages about this system. You don't have that slide? Oh, there's a video for a better slide that, anyway. So this is like crazy, crazy complicated. I don't even know how to just. It's okay, you don't have to do it. I don't have to explain it. Yeah, this is. Yeah, you've all lived this. You know how horrible this is. There's just too many different things going on all at the same time. The point is what we wanna try to do is kind of to say to you, use a template and don't care about the rest. So what we're gonna try and do is fix this up a little bit in Drupal 8. The first thing we wanna do is remove theme functions. So we only have template files. And if we can do that, it eliminates two of these subsystems, the original theme function and the theme override you put in your theme. The next thing we wanna do is remove process functions. This was another layer of processing that went between pre-process and rendering and templates that we added basically so that we could flatten arrays into strings. So that in the pre-process layer, you can stick your classes into an array. And in the template, you could print classes and they would come out as a string. Well, we needed some place to make that happen. Well, Twig can do that for us. It can do that when you say, show me the classes. It goes, hold on, let me make that array into a string for you. So we don't need that whole layer of rendering in there to make all of that happen. So, and this is actually not entirely thanks to Twig. There are a whole bunch of advancements in PHP that make this possible. So using a newer version of PHP made this possible, but Twig does it already. So by using Twig, we can get rid of the process layer, which will help a lot too. We'd like to remove the entire Drupal render pipeline as well. Drupal render was something that we created in Drupal 7 so that you could do really complicated things with all of your content at the very last minute. Not we, sorry. Someone created. And it's really, really powerful, as long as you know how to do exactly what you want with it, but there's one person who knows how to do exactly what they want with it, it might be John. And so for him, it's great, but he still hates it. So we're like, well, if it's great, but you hate it, maybe it's not the right tool for the job. So what we wanna do is let Twig actually handle the rendering of all of those things. When you say, hey, give me a node author, Twig will say, hey, I know a node author is supposed to be a link, here's a link, and give it to you without having to run through the render system. So this is something that's been on our list of to-dos for a really, really long time, and we postponed it because we're like, oh, we're not gonna get to it. And then yesterday, when I tried to make a theme without it, I realized that it's not good enough, we have to fix this render problem. So we're gonna go back to the board, we've got some working ideas of how to solve it and see if we can get that done 8-app. So come to the sprint on Friday. The next thing we'd like to do is hook page alter, we need to get rid of that. That's kind of a big question mark, it might be the responsibility of a core initiative called Scotch, it might not happen, it might, who knows, we don't know, we don't like it, we wanna kill it, we're gonna figure out how, but it might not happen in Drupal 8. We'd also like to get rid of template preprocess and the entire preprocess layer. And now you'll notice that the title of the slide changed to Drupal 9 because we probably won't have time to do this in Drupal 8, but it's one of these things where a lot of people who are already theme developers are like, wait, wait, that's my favorite toy, why are you taking that away? Well, we wanna give you another toy that does exactly the same thing, but doesn't require Drupal to stop what it's doing and get a bunch of stuff ready that you're never gonna use and then start what it's doing again. So we wanna give you the same tool, probably have a different name, that does exactly the same thing, that'll work a little more efficiently with the rest of Twig. So there's a lot of preprocess functions in core and we need to do a lot of work on cleaning them up in Drupal 8 and then a lot more work on getting rid of them entirely in Drupal 9. But just that alone gets rid of a lot of those complicated subsystems that are going on in Drupal 7 and I think that'll help make the process of creating themes a lot simpler for everyone as well. The most important part here is it's no longer visible to the schema in that. We are kinda hiding all that complexity. Some of it is still available kind of in the backend and you can still all do crazy stuff. I mean, in Drupal you can do everything with 20 ways. But the usual schema that just wants this seam done and just wants to change this tag and just wants to change this list and just wants to add a class here can do that. And that's kinda the goal, to make it consistent and usable. So we've got a lot of stuff to remove. We like cutting stuff out of core but that's gonna take a lot of work so we're gonna mark that one as to do as well. So I don't know, do you guys think Twig is gonna help us get through all of these problems for having this Drupal 7? Okay. We do too. So as it turns out, we are going through this process of saying hey, okay, well now that we're using Twig, let's kind of look at the way we're doing things in Drupal with a new I and see what else we get out of it. And it turns out that there's a bunch of cool stuff that we get for free that we had never anticipated even being possible. The first one is that people want to be able to edit stuff in the browser, right? Having an IDE or some complicated workflow to change things is great for those of us who already work that way. But there's a bunch of people who are like, I just want to change this template. Well, can you just show it to me and then I can tip, edit and hit save. And guess what? There's a module in Contrib called Content Template or Contemplate which does that and it's been doing that with PHP for a really long time which is a really horrible idea so nobody go install it right now. Don't do this, it's bad. But with using something like twig that's no longer PHP code, it's now safe to save it. You can edit it, you can make changes, you can save it and it's not gonna explode your database or whatever Contemplate was gonna do when you weren't looking. And it will even be fast. And it will be fast. So yeah, we got a huge win by being able to finally edit this stuff. Yeah, the favorite thing to do with Contemplate was to edit your PHP file and accidentally introduce a syntax error and then have your entire site go into widescreen and have no way to edit it because now your website's a widescreen. Yeah, with twig though, basically it would do validation and it would not allow you to save that file or even if it did, it would just skip that template and go onto something else. So. So, saving PHP code in the database is bad. Twig in the database is okay. You can also save it to disk. Modules like Contemplate become useful again, which is great. And people who are used to systems like WordPress or other tools that give you in-browser editing, we can build something in Contrib that would do something similar to make those people happy. Also, twig is a language that's PHP-ish, but it also can be used in conjunction with other languages that aren't PHP-ish, for example, JavaScript. So if you wanted to use the same template file on the back end as the front end, you can do that. So, for example, if you're doing a HX page rebuild where you edit save and you don't want to reload the whole page, you just want to load the piece of the page you changed, you can use the same template file to render that from PHP as you can in JavaScript. So there are already packages out there that do this, in particular there's one called twig.js, that because we're using something like twig, we can just integrate with this other project and build a really cool Contrib module that lets you do that both ways. So I think that's really cool. And then the biggest thing for me, and this is just, this is definitely a pipe dream, but if someone here wants to build it, I'll be your best friend, we finally have the ability to have two-way communication between the code and the user interface. So for a really long time, we've always had this issue of like, well, okay, I went to the theme settings and I changed something, and then my template file, I did something else, and the two things disagree with each other. Like this says don't print the menu, and this says print the menu, which one wins? And for forever, we've said, well, the code always wins. I mean, we'll just break the user interface, it's no big deal. Like that checkbox won't do anything anymore. I'll remove the if check, it'll be fine. But then you have some poor end user who's like, I keep checking the checkbox and saving the page and nothing's happening. Well, finally, we have the ability to like, hey, Twig, has this file been changed? And Twig will be like, yeah, someone removed that if statement or that variable doesn't exist. And then Drupal will go, oh, well, I'm just gonna disable this checkbox. So someone goes to the settings page and it says, sorry, your template's been overwritten and the settings are disabled. There's at least a queue to the user that, oh, they can't change this, they're not gonna keep clicking the button and wondering what's going on. So that's like a low level, like, okay, two-way communication, cool. So if you take that one step further and say if Twig can talk to Drupal and make it do stuff like disable files, maybe we can go one step further and say, well, okay, the normal workflow for creating a theme is writing this beautiful HTML and CSS and then handing it over to a theme or a developer and saying, make Drupal do this. And then developers just spend a lot of time just like cutting up into little pieces and figuring out where to put it and building architecture that matches and then like sticking it on and it doesn't always work right. Well, what if you could just take that template file and throw it into your Twig theme and take, well, with our new zoom, Twig would say, okay, I see that you've put this block in this region and this field over here. So here you go, I built your Drupal site for you. Okay, so it's gotta have the architecture. It's gotta have the architecture to match. You gotta know the name of the block, you gotta know the name of the field. But there is a possibility for something like this to actually happen, which is definitely gonna completely revolutionize the Drupal world, if not the whole world. So I think that's the coolest thing ever. So anyone working on that? Start coding already. And we are working very hard at the moment to get Twig in core so that we can do all those things later in Contrub as well. So that's one very important goal of our initiative, that even if we cannot get to all things now in core, we are enabling Contrub to do and less possibilities. All right, so that's like our basic idea here, but there's a lot of stuff that you can do to make your Twig different from our Twig. Yeah, just real quick. What we did was we showed, we added really nice debugging output. So there's a key called TwigDebug equals true and we just need to get quickly back to our test theme here and take a look at the source. And what you can see is for each of those nodes and other theme cores like our region, et cetera, you see the file name, you see the theme suggestions and everything, so you're easily able to kind of now what templates could I use here? And that's a useful debug output we've built. So activating the bug is one way kind of to always, we build your templates while you are working on them. Currently in Drupal 8, it needs to be fast by default for production side. So if you are adding a template, nothing happens and you're like, what? This is by design because we wanna not have to check every time has this template changed, has this template changed, has this template changed, but you can actually enable this functionality and that's very easy. You just go in your settings PHP and you set this other key, quick auto-related reload equals true and then it will automatically reload and you can just edit your template files normally and it will always be compiled on the fly and always be accurate. The other thing is there's a trick cache key and some people try to change it and they were like, my Drupal is so slow suddenly. So don't do this, this is really kind of more developer only key. You don't need it, forget it just unless you want to see how your site is slow. The other nice thing is it's very easy and that's just one little code example, how you can extend trick. You're just defining a trick extension and then you have two functions like get functions and get filters and you can just define URL and T and then you can, from then on, you can use these functions and filters from your trick templates and those are just kind of, the first key is kind of the PHP that's called and the other part is how it's called and trick. Then we have people might ask kind of, what does change for me? I'm so used to the Drupal 7 way, what are the API changes? So one of the things we made sure of is yes, we created actually more render arrays for now but that's a good thing because this will allow us to, together with the infrastructure, the other people are working on to drill down into everything and to laser render everything. So for example, there were some templates that were like doing a huge stuff of preparation and rendering and doing everything and you're in your template and you don't need all of that because you just want to do some of that output. You can remove it and because we are kind of lazy rendering everything, it's much, much faster in that. So whenever you used to use in a preprocess, you used to use to call a seam, instead what you want to do is you create an array and you use this hash seam equals your function and then your arguments like normally. So that's a simple change here. As Jen said, there will be some more changes with a refactoring of the render API of that. Stay tuned. The other thing is the markup utility functions. I've already talked a little about that. There are some things like an HTML tag or a link where it really does not make so much sense that you need to change all of that link. There might be however, a use case that you want to alter the input of a link like the path or something where you need to change something in the structure of the link but most often you don't need to change the template itself. So what a markup utility function is, it's a seam function which is always fast and a variable kind of preprocessor that can be used for a template in one. And this map initiative kind of allows us to make that possible that for every seam function and for everything that is in Drupal you can implement a template but you don't need to. And that's kind of the idea here. The other thing is, well I've built this really, really big seam in Drupal 7 and it's all two coding standards and now I want to switch to Drupal 8. Do I have to redo this again? We've been given today a very impressive demo of Twiggy Fire. It's a module called by Forrest Maas and at Elephant Ventures on Twitter and they've demoed it today. They've shown a Drupal 7 seam, did some drush command and out came a Twig Drupal 8 seam. So it's not yet completely ready, it's in the sandbox but when Drupal 8 ships it will be ready and it will be your upgrade path to upgrade your seams. We've gone a long road. So yeah, we want to talk a little bit about all of the work that we've been doing for the past 13 months in order to get here. I know you guys are like, wait, why isn't Twig in core right now? It's hard to change all of the markup that comes out of Drupal. It originally started in one sandbox and we tried one approach which made a little bit of progress. We got to play with all of the systems but it didn't actually get it working so then we abandoned the first sandbox, moved to another sandbox, just basically forked core and started playing around with everything. We got it working in the second sandbox and then we started changing every single thing. We changed every theme function, we changed every template file, we changed everything. We had hundreds of people working on it and then when we got it close enough we're like okay, let's take all these conversions that we've been working on, generating all these spreadsheets and lists of who's working on what and move it into the Drupal core queue and group it into ways that make sense. So where would you want to apply a patch? So we went through every single module and every single theme and sometimes we broke them into smaller things like theme.inc or theme.maintenance page and created a bunch of little issues. So this file is getting converted with these theme functions and these template files. So here's the change. And we started working through all of this stuff. We've got this meta issue here at node 175, 7550. You might have heard that before tonight. Where we started going through and making all of these changes. Every single one of these needs to be reviewed, it needs to be tested. We need to compare the markup before and after and so if you guys want to jump in and start working on these, that would be awesome but hold tight, something more important. About halfway through we realized that the scope of what we were trying to do exceeded our ability to do it in the next week which is what we wanted. So we ended up saying, okay, well what's the most important thing? Most important thing is to get rid of PHP template. So what we're gonna do is create this new issue and it's just gonna be all of the conversions of PHP template files into Twig. And so enter node 1987, 510 where we started just doing all of the conversions of the template files. And as we're doing these conversions people are like, wait a minute, we don't wanna make Drupal any slower because Drupal's already really slow and it's really late and if we make it any slower, we're gonna be in trouble. So it came down to all of the front end developers to learn how to benchmark Drupal and benchmark every single template conversion we had. So Fabian wrote this awesome little script and everybody got training on how to install XHPROF, all of these CSS experts were like, oh yeah, let me test that for you. And we got most of it done, which is amazing. So this is node 1987, 510. What we've done is converted all of these things, benchmark gotten, core committers sign off to make sure that they pass approval and we wanna get this committed this week. So if you have five minutes right now or five hours tomorrow or whenever you wanna do it, this is where we need the most attention and this will basically get rid of PHP template and get Twig and core. So this is definitely the most important thing to do right now. And once we have this mega patch in, it is in core, it's not getting out again, it is fixed. So let's get this done. So now we've got all that stuff benchmarked and we're getting in core and we're getting it approved. We also realized yesterday that it's not good enough. Some people might be happy that I don't think it's good enough, not good enough for me. I want Twig to be awesome. I don't want it to just be slightly better than PHP template. In order to do that, we've gotta make sure all of the use cases that theme developers have brought to us and said, I wanna do this in triple eight. I wanna print a node and I wanna drill into its field, image field and write my own IMG tag and print out the source right there. We need to make sure that all of that data is available in that node template in order for them to do that, which requires the refactoring of the render system. Oh, by the way, we gotta start working on that yesterday as well. So that's where we stand right now. We're really close to getting Twig in. We've got a lot more work to do to make Drupal eight as awesome as it possibly could do, but it looks like there's a lot of people in this room. So if we could close the door and just have everyone just get out your laptops, I think we'll be okay. There's also a bunch of people who have already worked on this, so you're all gonna be working now. But everyone who came before, definitely we need to thank, there are a whole bunch of people who contributed to the first two sandboxes at previous sprints. We've got a whole bunch of people who have posted patches from their home or office or car or phone with conversions. We've got a whole bunch of people who are reviewing all of those patches. Maybe they didn't feel comfortable posting a patch, but they know how to look at HTML. We've got a whole bunch of people attending sprints now. There are people here on Monday, there are people here on Friday. There's people in the sprint rooms right now working on it. And we've got a whole bunch of new people added to maintainers.txt just because of their work on this Twig project, which has been really great. We have a list here of all of these names. I'm not sure you can read them all, but there are a lot of people, front-end developers mostly, who are now core developers, which I think is really great for Drupal as a whole. If you've contributed to Twig, can you please stand up right now? Yeah, yeah, we have everyone stand up. Thank you so much. I really appreciate all the work you've done. So like I said, we're not done. Node 175, 7550. We need more help, but there's an IRC channel, Drupal-Twig. If you've got questions about anything, you can go in there if you want mentoring. You can come and talk to us in the Coder Lounge. There's a bunch of stuff we gotta do. Finishing template conversions and benchmark refactoring the render API, removing the process layer, converting all of the theme functions to template files or markup utility functions that'll also be determined by the render API refactor. Cleaning up the pre-process layer, cleaning up the markup generated by core and overall improving Drupal's performance. I know five weeks isn't a lot of time, but I think we can definitely get it done. So come help us, especially come to the sprint on Friday and we will take all of the new contributors. Just go to the session, get set up, come see us, and we'll get you to work. So with that. One last thing before that, I was really, really amazed for this XH Profkit. We had like four days, like 12 people sprinting at every time. It was amazingly awesome here at Drupal-Con. It's, the Drupal community is fantastic and the front end is even more fantastic. All right, so we have a microphone up here in the front. So if anyone has any questions, come up and ask them and I'm sure you have questions. So don't be shy, we're friendly. I will take this to grab another little issue. Jen, she will hate me for this, but as soon as Jen says go, we have the mega patch in, then we as front enders who know about markup but know about CSS have a responsibility. That responsibility is to make Drupal look like a modern system. That means that I used to blame John for all of the bad things in Drupal 7, which I think is pretty fair. The thing is that what John promised me is that apparently I'm leading the markup initiative for something for this. So everything that's gonna be wrong and the markup is gonna be my fault. I'm a very short man. I don't have the shoulders to bear all of Drupal on my shoulders. I need help. I need people with opinions about markup. We used to be really pretty opinionated. So if you don't know even know how to do all of this stuff, just know about markup and CSS. We have an issue called dream markup, which is just a hashtag for on D.O. Go in and search there and you can see us going really into the specifics about markup. But even more important on Friday, I will be willing to sit in the corner and flesh out each little bit and piece and figure out how we're actually gonna do it. So if you don't even know how to install Drupal on your machine, but you actually know how markup should look and be, I need your help. I need it really bad because I'm willing to take the fight with John and we're probably gonna have that. What? Thank you, Morten. We wanted to take one more question. It's Morten DK. Next question, please. Next question. Hi, so now that PHP is outside of the team plate, the battle always is like to know where the variables huge array has inside. How can I check that now without PHP inside? So there's no DPM anymore, I guess. Well, so we're gonna give you a twig inspector that'll basically be a DPM. Right now there's a dump function that you can put anything you wanna look into inside the dump function. It's not pretty. We only used it for the first time a couple of days ago. So we've got to refactor a little bit, but you will have a variable inspector inside that template file and it might even be in the docs at the top, so you just uncomment it and then it'll say these are your available variables and you comment it back out when you're done. Do you need to check the source code or can I just see it like that is DPM right now, basically? Yeah, it's just. There will be a replacement for DPM. Yeah, you won't need a development module, it'll just be in core. Okay, thank you. Sure. So you said that some functions with still, PHP functions were still available in twig? Yes. Which ones are there? So you saw a screenshot where we had added URL and T, right? So inside a template file, you can pipe anything to T and it'll translate it, you can pipe something to URL and it'll turn a path into a link, right? So there's gonna be a whole bunch of those and it's gonna be based on what we find in our existing templates and what's needed. There might be stuff like a format plural that we really handy to have right in a template file. So we're gonna come up with a list of stuff that we think should be added. There's already an issue on Drupal.org that's like add these things as filters or functions or whatever it is we want them to be. But if you have used cases that are different than the ones that we know, add them to that issue and we can get them in. And can we alter this list or the white list? Can we what? Can we alter the list? Can we alter the list? So you can extend twig. So if you had your own like twig pack or something twig super pack, I don't know what you wanna call it, you can add anything you want in the same way that you want. And you can also replace any functions you don't want. You can alter twig completely and 100%. So with your vision of having all the process and pre-process functions gone, where do you see the functionality going from there? We're gonna give you a shiny new toy that'll replace the ugly old toys that are broken. I don't know what that looks like yet and we won't until we get closer to it right now. We're really focused on getting this converted. So for Drupal 8, at least as far as we can see right now, pre-process will still be there and you'll be doing everything in pre-process exactly as you did before. So if you wanna add new variables, you wanna alter variables, you wanna add classes, you can do it all in pre-process, but what we wanna build is a way that you can do it more easily directly from the template file and don't need to go into pre-process. Pre-process will still be there. In Drupal 9, I'd like to get rid of pre-process entirely and give us something that's not quite so non-performant. Something so that rather than saying, wait, wait, before I render this template file, let me get a whole bunch of variables ready. None of those variables are prepared at all until the instant you say, print this variable and that'll make Drupal a lot faster. One of the things that I do a lot with pre-process functions is, you know, there's like 18 different types, excuse me, 18 different types of node types on like really large sites and rather than having 18 TPL files, you just have one pre-process file and do some sort of logic in there to different things. That's the easiest way in Drupal 7, but with Twig, they've got that new code block thing and then it becomes like having an actual like node dash dash article Twig file that just has that little bit of three bits of lines of code actually makes it easier to see what's going on in the system than trying to dive into the template.php file and find the right pre-process and then understand the logic. So it actually, a lot of those things that you have to do it inside of pre-process will be much simpler and better organized and easier to understand using Twig native stuff. Part of the reason why we don't know what it looks like yet is because we're not planning on removing pre-process in Drupal 8. Thank you. I'm one of those developers that got lightheaded when you said something about removing pre-process because I use it quite a bit. One of the best practices as I've always understood it is to keep your templates as clean from logic as possible and do everything in pre-process but yet in the examples I was noticing you were doing stuff like running through loops and doing a lot of logic in the template. So I'm wondering, is that basic premise changing? No, so it's exactly the same code as we had in the PHP template files. So the PHP template files also had loops and stuff in them. It's just the Twig equivalent syntax for doing that. So what we wanna keep out of the template files are stuff like database queries and complicated functions. We wanna move those someplace else and just have you print the variables. But sometimes printing the variable means looping through all of the items in a menu or looping through all of the items in a field. And so there's syntax for that in Twig. So first of all, logic should be in templates. That's why Twig is not just print this variable or something that has kind of like this programming language but that so far everyone could understand that I've spoken to and quite easily in that. The other thing is if you now in Drupal 7 wanted to have an item list and you wanted to have your own item list you would need to copy all of this code from api.drupal.org, copy it in your template PHP, then change it a little thing and it's very, very complicated. It would be much easier if you just copied the template, changed the thing and you're done. And in that it's easier and it's also easier to understand because all of that complicated logic, it's all, there's still some complicated logic in the pre-process but no more complicated logic in the template and that's kind of the goal of that. I just wanna like follow on this idea of this best practice of not having any logic in the template file and I bet you can go back and find videos of me saying that, right? And the truth is that that is a lie. I've been living a lie for these years. And the reason for that is I've come to understand is that really there are two different kinds of logic. There's business logic and then there's display logic. We need some things for like lists, right? This is a display, a design decision about you have to loop through these items, right? And it's perfectly fine for that kind of logic to be in a template file but what you don't want is the sort of business logic stuff and keeping that stuff in the template.php makes a lot of sense or whatever, a module or something like that, right? Okay. Hi, I was just wondering if you could explain how the editing of templates through the Drupal UI is going to affect disk-based templates that are stored in code or in version control? Well, it depends on whoever writes the module. We're not, that's not something we're doing in core. Oh, that's not gonna be in core. So, yeah, and it's definitely the kind of thing where whoever takes that on and wants to make that happen will make their own decisions and it'll be based on that. Those were just things that like, oh, look what we could also get us but that's not something we're working on. Okay, thanks. Sure. I can put on my sort of pregnistication hat. There's a CMI initiative where they're writing like all these different YAML files to YAML configurations that go into files and certainly there's gonna be a lot of sort of existing Drupal 8s of examples of how different things are supposed to work as far as configuration management and then I think that like the person who decides to take Contemplate module which seems a logical place for it to do to be the Drupal 8 version of this module may look at those examples and come up with a system where you, you're editing it on the fly and maybe it's saving it to disk, you know, inside these files that are similar to Contemplate. Wherever it's stored, it's not important because with Twig those files are compiled to PHP so it's still a PHP like template that's generated in the end so it really doesn't matter where that file is coming from. If you wanted to, you could store that file on Amazon S3 or wherever and just get it or get it from FTP server or create it on the fly, you could create a template on the fly, you could create something that would create templates on the fly so possibilities are endless. Yeah, I guess my question was just if you're editing a template through the UI that's stored out on your server and then you're pushing code, updated code from version control, that's got an old version of that template, where are you sourcing from? So it probably wouldn't overwrite the template that's already on disk and we've got patterns for this already with CMI where when you export something to CMI it goes into a directory that's not actually overwriting its original, you just have to grab it and import it some other way. So there might be a similar model like that. You might also, you could still save it to the database, you could save it anywhere, so. Okay, thanks. Sure, any other questions? Okay, so we need you all to come to the sprint on Friday, but please also evaluate the session. If you go to the schedule for DrupalCon you can find our session and evaluate it there. Thank you very much. So we're also doing a bof, if anyone's interested in talking about this more casually that starts right now at five o'clock. So in 12 minutes, do you know what room it's in? A, one, something, go look at the bof schedule or follow someone who knows. But we're gonna do a twig bof. Don't follow John Alvin.