 We've got Morton DK diff killer We've got John Elbin world-class lover. Hey, we've got Piers Warmer symphony foreigner So this is the twig eight session. I'm not gonna say anything else. Oh everybody Does anyone want to do a different introduction? Should I just get this slide? Okay, we're all on Twitter if you want to like ask us questions to be clear that they were joking about HTML classes when they Gave me my title That is a complete lie John is actually a first-class lover All right skipping this slide So we wanted to start off First by talking about why we're changing the theme system in Drupal 8 And so I want to say there are some really positive things about the dreams through the theme system in Drupal 7 Mainly that you can do whatever the heck you want with it as long as you know what you're doing Unfortunately, there were a lot of negative things as well. So we'll talk a little bit about those first starters the Syntax of our template files only exists in the world of Drupal It started from PHP template, which was a templating language that existed elsewhere and in Drupal 7 we completely Changed it into something that didn't exist anywhere else by adding the existence of calls like render right from our template So this is something that people outside of Drupal aren't familiar with There's a really confusing way that we deal with variables or sometimes these variables are objects and sometimes there are rays And we reference them in different ways So if you're taking people who are non developers and trying to get them to use template files They need to understand data structures in a way that isn't really necessary for their normal everyday job So that's really confusing for new people When we print things in template files in Drupal 7 sometimes we just print the variable print classes Sometimes we print render a variable which is also really confusing because it sounds a little redundant But we do it all over the place in different ways And that's also really hard for people to get a handle on when can I just print something or when do I have to render it? So that's confusing for new people as well PHP template is just PHP PHP is not terribly secure So you can do horrible things from any template anywhere if you want to when I was preparing this slide I accidentally dropped my node table by refreshing the page. I was looking at so That didn't go so well Don't do that There's a lot of stuff in our existing theme system We have way too many template files in core alone if you wanted to remove all of your classes from places You've got a lot of work to do just to get to a clean starting point and to make things even worse We don't just have template files in Drupal 7 We also have theme functions and there are hundreds of theme functions So sometimes your HTML was coming from a template file some of it's coming from a theme function Trying to figure out where the source of this code is that you're frustrated with in your theme is sometimes really hard Just can't track it down this is a simplified version of The theme system in Drupal 7 so if you wanted to know what was being passed from one place to another Well, you're not gonna figure it out There's just too much stuff going on and this is this is kind of the nature of open source Where you start with one solution and a couple others later like oh we need this thing and then you add it And you're like oh we need this other thing you add that too And you know and then here you are 10 years later And you're like we have a lot of things going on and it's no wonder that nobody can figure this out John made the diagram. Do you want to talk a little bit about how you did this or why? Yeah, so I gave a core conversation Drupal Con San Francisco before Drupal 7 was released I'm like this is what we're dealing with right now like and I tried to do to do a 60-second overview of this entire thing And I got really close, but it was actually took me about 90 seconds to explain everything I'm interested for core developers and at the time I figured there were maybe two or three people in the entire world who understood this whole thing It's just massively massively evil And and it turned out there was other symbology also sort of embedded in this as well The next slide you don't have the other side. Okay, that's fine. This one's better So all of these things added up to Drupal being way too hard for new people to figure out how to learn And there's a lot of people who come to Drupal from other programming backgrounds are working in other areas of the web And the first place they try and change something is the theme system. They go, okay Well, I'm gonna install Drupal. Let's see if I can work in HTML. I know HTML That's the universal language of the web and they try and start with the theme system. They're like, oh my god I can't do this is really hard. There's stuff going on everywhere. I don't understand what this render thing is What is it? When is it an object? When is an array? How do I print it? Do I need to sanitize it or not? Where is it coming from? And it just it becomes a detriment to the rest of the good stuff The Drupal does that new people just can't get into it very easily. I'm a developer I started in the theme layer a lot of current core developers started in the theme layer That's just how you get into it and this should not be the most frustrating part of working with Drupal So here's this list of stuff that we wanted to fix in Drupal 8. The fact that our template files are Drupal specific We've got mixed data types. We've got different methods of printing stuff. PHP template itself is really insecure We've got two ways of overriding markup templates and theme functions We have too much stuff going on too much of both templates and theme functions We've got a really complicated mix of all of the subsystems that add up in the Drupal theme layer And that just makes everything way too hard to learn. So let's see if we can tackle this list of problems So in Drupal 8 the first thing we've decided to do is change our theme engine So instead of using PHP template, which we've had around for a really long time. We're gonna use something new called twig So twig is a well-documented open-source PHP templating language that most of you may or may not have heard of And it's already in existence in the internet. It's not something we're making up ourselves, which is good It's extensible. So if it doesn't do something that Drupal needs it to do We can write an extension for twig to make it work for Drupal and we have which is good It's secure in PHP templates. You cannot accidentally drop your node table You can't accidentally I will not accept patches that allow you to write SQL queries in your template files You can it will not be accepted. All right, if you if you want to shoot If you want to shoot yourself in the foot you can do it on your own website. We're not gonna let it into core GitHub does not count. Okay. It's also really well tested. There's a bunch of sites out there already using twig and it's unit tested It's also pretty fast compared to other templating languages out there. Obviously PHP is really fast It's it's faster than some other things you might have heard of like smarty Which we used to have in previous versions of Drupal, which is good It works in your ID. So if you're a developer and you want to have debugging There are plugins for all your IDs that can recognize twig. It's really great And it's a recognizable syntax. So those of you are like, oh, no, I've got to learn something new to work with Drupal Don't worry. You can read it. It reads just like logic like English like other things you may have seen on the web So it's not going to be scary and foreign and anyone who's worked in any one of these languages before will just pick it up really easily It's also written by the same guy who wrote symphony, which is also in Drupal 8. So it works really well with that and there's a lot of Philosophies that jive really well with how we're doing everything else in Drupal, which is good So we had a sprint at the end of the Bay Area Drupal camp this year to try and figure out some principles That we should use when refactoring the entire theme layer in Drupal 8 The first one is that we want to start with nothing so Rather than having Overcomplicated assumption of what people might want to try and do we wanted to start with zero and add to it So this is like right now in Drupal you start with everything and try and remove what you don't want We're gonna try and turn that around the other way and start with only what we want if people want to div They can add themselves. We're not gonna put it in there for them You don't know if we're actually gonna get this done. This is what we want. These are the principles. It's what we want We're gonna build from use cases So right now in Drupal 7 we have built a system where anything is possible because we assume that someone will want to do everything at some point But we don't have any use cases to back that up We're like well Maybe someone might want to add this thing in this way and we'll just make it possible We're not gonna do that. We're gonna say look We know what people want 90% of the time and we're gonna build them that and if they have some crazy edge case and That 1% or 10% that comes up they can do it themselves We're not gonna put all of this complication in the core for the edge cases that don't we don't really know exist We're gonna provide tools so rather than Trying to solve everything from the beginning We're gonna solve the 90% use case and give that 10% the tools. They need to do what they want So you want to write an extension for twig you can do that But we're not gonna make it solve all the problem side of the box We're gonna try and consolidate stuff. We've got way too many template files and way too many theme functions Let's recycle. Let's use the same code to write an item list every time you write an item list Whether it's a menu or whether it's a well or a UL or whatever. It's just gonna be the same It's not gonna have different divs depending on where it's called same thing for tables We want to have some components that we can reuse throughout core rather than having every module provide its own markup Uh visibility we want people to know what's going on Twig is pretty good at this already when you look at something you can kind of tell what's going on But we don't want to abstract things We don't want to hide things we want everything to be able to be kind of guessable, right when you're like Oh, I need to override a menu. You're gonna instantly look for a menu template You're not gonna look for an item list template. So we're gonna give you a menu template Just stuff like that that makes Drupal a lot more intuitive rather than One place right have to go through system Kind of begins to make sense with where they are maybe instead of what we have now where we kind of have You have to go through system. You have to go Go trace your hunting. Yeah, so we're gonna try and make it a lot easier to find everything too. So We'll see how perfect that Is that a feature or is that? No, that's a task. Yeah, all right So we're also gonna try and make everything a lot more consistent right now Depending on which piece of content is coming out in which part of the page it can be rendered completely differently You can have its own style sheet. You can look really different. It can have you know extra divs or not If we can start to consolidate and use the same functions everywhere or templates Then the code will start to be the same everywhere, which makes it a lot easier for friend and developers to style like Oh, it's not this table. That's different from every other table. I can style all tables at once So hopefully that'll help a lot too And we're not gonna try and dump it down too much In Drupal 7 there's a lot of this like oh well femurs aren't gonna understand that But it turns out that like if we make something that makes sense they can learn it And if we make something that doesn't make sense, no one can learn it So we're gonna try not to dump it down when we don't have to sometimes They're really complicated problems and they require complicated solutions and we're just gonna do it And when a complicated solution is necessary, we're gonna trust that our friend community can learn it We're gonna make it easier, but I'm gonna do it And the last step is that the way stuff is organized needs to be driven by the semantics and not Like a programmatic deconstruction of what's being written in HTML a really good example is the item lists Right like there are two specific Elements for an unordered and an ordered list in spite of the fact that they both contain less items And there's a reason for those being separate in Drupal We had one function because the developers looked at it and thought oh it's an ally tag That's exactly the same either way. We'll just flip but it's semantically a different thing And so we need our code in the theme layer to produce markup Semantically the way front-end developers think about it and when things start to work the way people naturally think about them Everything will make a lot more sense Moving focus from being a System built by the developers or more system that makes sense to front-end developers. That's kind of the whole idea I know it's crazy talk, but it's that's kind of the whole idea We just figured out over the years that maybe it made more sense Maybe you could actually get more front-end developers into using Drupal because it made sense instead of giving them the content Variable as the only option in a note and they can then use the next four years of pitching and morning So we're hoping to make things work the way they're supposed to work and not the way developers think they should work All right, so who wants to see twig? All right, so I've got some examples of templates that we've already converted Some of these screenshots are a little old and they might have been changed since then but generally speaking Anytime you want to print a variable you use double curly braces to print it Anytime you want to run a command You use a skirly curly brace in a percent sign and you put your little logic inside there And anytime you want to add a comment. It's a curly brace in a pound sign to add a comment People like that comment So The syntax should be really simple and intuitive. It's very straightforward. It just says what it does Generally speaking All of our theme functions are going to be replaced with template files So there will only be one way to override markup from anywhere It is crazy, but it's going to be awesome And there's going to be a heck of a lot less code because as it turns out it takes a lot less code to just write HTML then it does to write a php function to produce HTML HTML and the curly brace twig stuff. Yeah You're out of luck. All right, so the username function just becomes a link tag or a span tag The image function just becomes an image tag The link function just becomes a link tag Right back back to sanity So so when you go to print something in twig It'll sanitize it for you like you can take any like node, right? And in in triple seven you were responsible if you wanted to pull something out of a field You've got to clean it up and make sure it was safe to display Because of this problem like 100% of all themes are insecure. It was a little rounding error in there, right? This is going to prevent that you will never have to sanitize your own data because twig does it for you So twig can handle the translating and sanitizing you just say print and it'll be like I know we need to take care of this for you so Twig will make everything a lot more secure because of that because we don't need to put that Responsibility into the hands of people maybe never seen Drupal before and that's important or any database driven system, right? Or don't care. This just says you can print it and it'll handle all that stuff for you It turns out this is an example of our theme item list function, which in Drupal 7 was really messy When you turn into twig, it's actually kind of elegant So Yes So we don't need to prepare variables in twig because it all happens instead of before you render the template While you're rendering the template so you can say print items and it'll spit them all out Or you can say print items dot item and it'll print out one or you can say print items content It'll print out whatever's inside that so there's everything should be drillable right now if you look at Drupal 8 it doesn't do that we haven't built all of the Flattening compress a complicated object into string functions in yet, but twig can do that and that's what we're shooting for So it's you should if you wanted to print a link inside a menu You should be able to write a template file and just print menu dot item dot link dot content and get only a piece of that out If you want and it'll be secure and it'll be safe to just drop that into your file It's not done yet, but that's what we're shooting for so We we don't know I want to kill them all But we need to make sure that before we Before we remove that tool that we have a comparable tool for front-end developers to be able to do the same thing You want to add a variable to your template file you want to change variable in that template file You've got to have a way to do it So right now what we're doing is taking all the logic out of template files and moving it into preprocess The next step is to take all the preprocess functions and turn them into twig rendering magic But we've got to make sure that there's a twig render magic alter Something right so that so that whoever's using a template file can still change what they need to change And we haven't figured that step out yet So right now I'm gonna say they're still gonna be preprocessed because we're not taking tools away. That's really important No, eventually. Yes before jubilee chips. I hope We'll see Okay, so here's all the problems of triple seven. Let's see if we've adjust some of these So triple specific template can make fun can functions. We've got twig it exists elsewhere in the world fixed Mixed data types. Sometimes we have a arrow. Sometimes we have square brackets all Template variables in twig. It doesn't matter whether it's an object or an array or string already are all printed in exactly the same way fixed Different methods of printing whether you print or print render guess what we've removed all calls to the render function from all templates in twig fixed PHP template being insecure twig will not let you run a sequel query without Alteration And we're not gonna let it do that in core automatically sanitized fixed Two ways to override markup templates and theme functions and way too many of both we're eliminating all theme functions So that'll only be one way and consolidating them at the same time fixed Too many of everything. We've got most of these Consolidated already, but there's some core issues. We can use some help on it. So if you're around this weekend, that'll get fixed shortly And our complicated mix of subsystem. Let's let's see how we're doing with that Here's where we started right where we had way too much stuff. We're removing theme functions That means all theme overrides are also going to be removed Which means in your custom theme you'll just be overriding templates. So that removes two layers already Process functions only existed for the purpose of flattening things like arrays into strings We don't need that twig can do that for us. So that's obviously out Render I'll cost a render been removed from template files. This will still exist as Drupal internal But it's not going to be part of your everyday life. You don't need to worry about render or Drupal render all that so that's gone hook page alter will go away because we're Switching to the blocks and layouts system. So it's going to be a little bit different how we deal with that But we won't have that as part of our theme system anymore either Pre-process functions I talked about we want to kill them We're not really sure whether we can or not at least in this release cycle Eventually we should be able to get rid of them entirely and that's a lot of pieces of our theme system They've been removed. It's a little better, right? Still has the kind of like satanic star there in the middle, but You're gonna rearrange the bubbles or something So that's a lot better Okay, so most things are fixed except for this whole difficult to learn thing We're hoping that'll get taken care of to by doing everything really consistently treating our theme functions the same treating our Styles and classes and div tags and all of that the same all across core if it's consistent people should be able to guess What's going on and that should make that better too So let's talk about some other awesome things that we may or may not be able to do with twig Do you want to talk a little bit about twig template inheritance? Okay So one of the really cool features of twig is the your ability to override Components of the templates. I'm not sure how this is intended to be implemented in a in dribble, but You have a right. Okay, so There's an ability for one template to inherit a super template Usually in a simple context as a layout so you can have a template describing maybe a feed of posts and that inheriting your site layout in turn And it doesn't in a very simple and elegant way I don't know if we've got an example of a template like that, but it is a relatively simple process of doing There's also an override. It's sort of a Hierarchy we can actually override templates have been placed into twig So should you need to override something like something? I'd imagine that twig would be being built into Drupal core like Display page you can write customizations over the top of that so you can really get Your own presentation layer working relatively easily. So, yeah So this idea of twig template inheritance, how many people have like a theme that has like Five or seven or 80 node TPLs in their theme? Yeah, so So my idea of how the the template inheritance could work would be basically you you have your one node TPL And then a lot of those other TPL files are basically this like one line that you want to change So you can mark up in the sort of the the base node TPL to say this section. I want to be able to change in my variants or What are the what are they called in twig? Yeah, yeah, so see yeah You mark this one section and say this is a part that I want to change and you call that a twig block Yay naming conflicts. Oh, anyway And then in your other node TPL file, you don't repeat every single line You just say okay, I'm inheriting from the node twig file And this is the one block that I want to change and when you go and open it it makes it's a lot clearer What's going on you don't have to do like a diff and see what's different between why is there so many node TPLs? It's really clear that I'm just changing this one bit This is all in my head. I don't There's really great code templates of everything on the twig page Which gone out. I open an issue to change the name of blocks in Drupal, but that didn't fly Yeah, we're just gonna call them a block it will bigger. Yeah, I don't know. Well, it's It's a code block It's really straightforward So Well, if you look at template files today, there's actually a lot of logic in there already There's a lot of like if this thing exists print it or if this is a whatever print that so we right now are doing Exactly the same thing in twig as we're doing in PHP template There will be ability to change that around a little when we have more twig stuff, but right now it's kind of the same So I just want to say it's like in Drupal 7 a lot of these times we have we have these things that are in the system already and like oh We have this other completely different idea and we have the system that needs that it's implemented in the same way that we need to like Get into the system So then they just like tack on this extra functionality like theme hook suggestions being done inside Pre-process functions, which is just supposed to be about variables suddenly you're changing the control flow of which Template file you're using inside a mechanism that was meant to be I'm just altering variables, right? That doesn't make a lot of sense that kind of what you're talking about or so Yeah, so so variables In twig files work completely differently than they work in PHP template because in PHP template You like have to go um does somebody want this variable? I know I'll go and like render it and create it or at least create a render array for it So they do all this work to create all these variables just in case The themeer wants to use it in twig. It's like okay I'm gonna tell the twig system that these variables can be made if you ask me to make them Right, and then when you render the template it goes. Oh, I actually do need this variable and then go and grab it There's a huge Potential performance gain because right now what we're doing is a little bit wasteful with all of this preparation of variables That may never get printed to the page or with twig. It's kind of a Inside out as opposed to an outside-in process where you wait until the template file gets rendered and then twig says what's in this template file? Oh, it's this variable Let me go make that for you Whereas PHP template was like let me make all these variables and then when they're called we'll just spit them out So that's part of why we can get rid of pre process is because that whole phase of preparing stuff doesn't need to exist anymore We just need to make sure what was that? Right, it's like a mid-process right like while we're printing stuff we'll make it and in and PHP PHP template was was kind of sloppy and how it did all of this twig is really elegant and that all of your template files get compiled Into classes and they can get saved in memory Which could also be really fast too if you have one node with 300 comments on it in PHP template That file needs to get read from disk 300 times and have those variables inserted or if you're using a PC It gets stat 300 times and that's expensive if you have a class in memory you just execute it 300 times And that's really fast So this is the kind of thing where like it says much TBD because we have actually haven't had enough of it done to do any Legitimate benchmarking, but there's a potential here for a huge gain not only in performance But in like the amount of memory it takes to build a page right when you have a giant render array That's sitting there waiting for parts of it to be rendered or maybe all of it depending on which part of the cycle You're in it. It's messy But here you're just like you know We don't need any of that until the time that we render it and then we can go and get only what we need and print That's a page so it will be really nice We can get all this other stuff out of there So in Drupal 8 we're gonna have this concept of context that'll exist all the time and we haven't actually done a lot of work with the Blocks and layouts people to figure out how twig will have access to that But we know that it will so there will be a bunch of stuff That's available in kind of a global context that you can use to figure out like who's looking at the page How does it need to be displayed? Is this going to like a web services request or is it being printed to a browser? Like is it mobile or not like there's a bunch of factors that go into that like Global context of how this content should be created that twig can then use to print things differently even so It could be really cool. We haven't built it yet And then this last bullet point this is gonna exist in in contrib only so don't get too excited But we were talking about this in Munich where it's possible for the first time in history For your Drupal site to be aware of what's going on in your template files So right now if you're a themeer and you're like why are there all these if statements to see if variables are set before Stuff's getting printed. I don't care whether somebody went to the system page and like changed my whatever I'm just gonna print what I want to print and what that does is it breaks the Drupal's interface, right? Like I said no, I don't want a menu here And it's like well it printed anyway because I removed the if test in my template file to see if it was Supposed to print or not so now your interface is broken and that can be really frustrated Frustrating for for end users not to understand that their theme isn't respecting these Drupal settings Well now we have the ability for the theme to read the template files and say hey This is getting printed whether that setting is set or not So I'm gonna disable the user interface so that whoever's looking at this page doesn't think they can turn off the menu Or doesn't think they can turn off the user pictures or whatever it is And then you're six times on the down the boat the clients come back and want to change something in the on the note page And want to drag it around or you forgot that you kind of custom-built everything in this this note TPL and Instead of using this couple of hours to figure out why is my cash not clearing this data out and so forth and so forth We can actually make this magic land of unicorns where we can have an idea of what actually goes on So if you take this one step further and say okay Well if the user interface can be based on the template files, maybe we can just write the template files first Okay, that's the reaction. I was expecting okay So if you were like I want to write template files for my site you write a bunch of HTML code You drop in the variables you want to drop in we can have something that tells you what the names of those variables are You put them into your Drupal site and then Drupal goes here you go. I've created everything you need to match that Yeah, yeah, that's the that's the possible performance gains thing. Yeah So I mean menus are cached anyways. That's not a big deal, but there are things like that that are going to be Yeah But that actually it's down to when we're talking about how to get new people into this I mean the first reaction you got when you come into looking at these tpl files Well, where does all this crap come from instead of I have this ideal markup I know works in old browsers and every mobile phone and blah blah blah so you can actually now have new people coming in that doesn't know the magic of Drupal and No, just write them markup and make this no Double curly bracket kind of thing put the title in here like every other same template system would do so it's Kind of when we're talking about the Is this going to be hard for new people to learn we kind of expect it to be natural to learn it like hey Write your markup and put your variables in and you're done kind of magic way Well, um Well, I know at some some frontend meetups everyone we will have hard Hard time to find issues to bitch and moan about so we need to like change that way of communicating I know that the sql module that's kind of come out and get help will help us with that but still Yeah I've been developing php for a long time and when I approach Drupal it seems very very foreign to me So I'm trying to tie this into the broader community. I'm just going to have a few wins to drag New people into the Drupal world All right. All right. So one one one last thing on our ball list here's the second one is um We're going to try and build some really awesome variable inspector So if you get a template that says menu, you don't really know what's in that menu You can say hey twig. What's in this menu? And it'll be like here all of the variables that you can print and it'll work a little bit We hope like the token drill system right now or you're like, oh look, there's a node And you click on it and it's like here's all the stuff in the node and you can click through So this is one of these things we were hoping to get done by two weeks from now So if anyone wants to work on that this weekend, we're going to be sprinting and you can help us But um that that can definitely get in I think even maybe We can sell it we can get it in after but um, so we're hoping to make it really easy for people to figure out What they can do in their files So this whole thing like I actually wrote a new theme layer for Drupal called token template that did exactly that Um, but there's a lot of reasons a lot of people didn't like that Um, so what we're going to end up doing is there's a lot of similarities between like tokens flatten and sanitize and produce output And so we can use all of the functions that we're using in tokens to flatten and sanitize output in the render system Um, so there'll be recycling right where we don't have to rewrite a lot of the stuff because it already exists But we're not actually using token. That's also kind of a Drupalism, right? Whereas we'd rather just use twig the way it does it So the the decision of whether we would use twig or like token template or something We had a sprint that Jen helped organize last march Was it so less than a year ago? And we we spent like three days just like going over all the different problems and you know, that's where the slides were What are the problems? What are how can we solve all those problems? And then we started looking at systems that could help us solve those systems when we looked at twig. We're like, okay Yeah, check check check check. It's like, okay Interesting thing is that that normally what the way this has been done in Drupal world is a bunch of developers sit down in the room and decide something great in developer land and then a year and a half later they give that to front-end land and The peasants will rise and again scream at the developers and we did it another way around We had a conference in in Amsterdam at that same way the same weekend front end the first front end united where we basically had no I was expecting three people to show up to the code spend and we had About 80 people showing up all in all and 15 to 20 people actually sitting down and just say, okay Let's identify what our real problem is. We then sent that to San Francisco. We then went to the bar Got pissed drunk and the next morning magic happened That was the day when when chicks had had solved all the solutions Yeah, yeah, so yeah Our strategy was basically instead of it just being developers, which is how we got the render system The the developers got together in like Drupal con Sega'd Which I didn't attend and like decided this is a render system And then Drupal 7 development happened and I was working merely on cleaning up the tpls And then all of a sudden right before code freeze render system lands and I'm like, what the fuck is this? And So I I immediately did not like render system at all But it was just me and all these developers and there wasn't any other Theme people who are sort of in the queue and active and it was like it was way too late by the time it already was in Drupal 7 like So this time we decided okay, let's get developers and front end developers in the same room So we had we had chx. We had effulgencia on skype like 24 hours. Um, we had Chris van der water who's the blocks and layouts initiative lead myself gen And and then we actually opened up Google plus hangout or Oh, yeah, it was way back So when we had all these other front end developers who who joined in remotely And so all of us together came up with the twig solution When we talked about the first day we actually had a demo of a dude who did actually a version of my theme The mothership Renamed it to the mother trick and actually implemented trick into it and shows us the demo of it because people are like No, we don't need anything new. We just need something clean. And then we saw that especially the block things. We're like Holy fuck. When can we get that john john? Can I get that? Um, no, so what actually happened on the last day of this conference We kind of saw what was coming out of san francisco and like Okay, let's just figure out if people actually likes this So we should actually push forward with it or should we just like hide in the hole and it was kind of a room this size of people There was actually interesting sessions going on at this point It was just kind of hey We're gonna brief you about what they did in san francisco and The kind of feeling got already at that point so early on the process that this was exactly what people have been Waiting for and which kind of made me feel happy because I just thought it was me who was being a little bit for six years It wasn't That would have been perfect So this was in munich where we had this session and we're like did people actually want this like is what we want and everyone Wanted it and it was like oh Well, we can do that too So so that's another thing, right? We haven't mentioned that yet But like we can't have like some people use wordpress right and there's like these editors where you can like open up like Here's your style sheet. Here's your template and you can like actually edit them in your browser We can't do that in php template because it's horribly insecure to expose php code in the browser But twig code is safe. We can do that It won't we want to in core but in contrib someone can write a module that gives you a ui that lets you edit all your stuff Does anybody remember the contemplate module? Yeah, don't use that But if it got converted to be twig based it would be perfectly acceptable solution you can install it into blade So contemplate can get this It can come back. Yeah Yeah, so there's a bunch of really stuff you can you can use twig for email templates. There's also like a java script Uh framework like twig js, I guess so that you can use your node template Whether that knows node is rendered like in php on your server or whether it's rendered like client side In some kind of external thing. So there's a lot of really awesome places where twig can be recycled everywhere What do you say? Feel are there is so is there any big change to field for matters? Well, I mean the biggest change is that there's no theme functions anymore, right? So all of your formatters will be using template files I mean we're doing a lot of work on field templates anyway because they're so bad, but So, um, it's a really great question field for matters. Um, I know a little bit about them But why don't you come to the sprint and you and I can talk and We'll figure that out the answer. Okay All right, so speaking of how people can help us um, we've got a lot of uh Stuff that we've completed right like we've got a bunch of template files that need to be converted to twig Which is in our done in our sandbox, but we need to move that to core Um, we've got to convert some more theme functions. I think there's like 20 left or something There's not very many um into template files and there's some pretty good documentation on how to do that Um, we've got to create and test patches against core So we're trying to take all of the work that we've already done and just put it into core Really fast because we've got two weeks to do it Um, and we can use a lot of help with that so if you can write patches We need you in that room um on saturday and then we also have uh, A bunch of people want to clean up the markup that's in core John is going to be sprinting on cleaning up the css So it may be really good to have people want to clean up the markup working with people want to clean up the css We don't break everything at the same time, which is good. Um, and we have uh issues where you can just write html You don't need to write a patch don't need an install dribble. You just want to show me the html You want tell us what you want and then we can fix it We are actually trying to figure out What is it? What kind of markup is it that we as Knowledge of people who knows the front end and how browsers Interact with it. What is it that we need instead of going the other way around? I know it's kind of in Drupal and it's against everything that we have always thought that were And it's kind of a revolution and we can see the red flags and how the people storm towards the castle We kind of need people to do that. I mean, it's I mean We are like four or five people and I got hit by all kinds of stuff the last two months So I didn't have the time to do it and we A lot of this is just sitting down and actually just No walking through the templates and figure out. What is it that I want to have here? How is there how is that my menu should look how should this list thing looks how should that thing look? I mean, it's just defining it so we can actually pass it Further down to people who know how to get this thing into code That's kind of one of the most Important things at this point and and the problem is that Well, I pretty much have hackled John for a couple of years because he was responsible for the evilness in Drupal 7 and John has now passed the torch down to me because apparently I have been the Loudest about everything that's been wrong. So apparently now everything that's going to be wrong in Drupal 8 is going to be my fault, right? So I know I think myself are being brilliant, but I'm pretty sure I'm not that clever So I need some people to help me take the fall down Which means We need more than one face to look at the marker or look at the code and look at the css. I mean John has an excellent post right now Waiting around the hole. How do we name css if he makes any mistakes right now and that stuff gets into core We're gonna be burned down with that crap for years I mean that's I mean that's that's the problem. You make one tiny mistake now And we're gonna have a lot of fun with that each and every day for the next couple of years So is this sprint tomorrow gonna be titled responsibility shared? No Yeah, it's actually it's um actually I am I have a session later today that's kind of tried to wrap up, you know Everything why stuff started out as it did and why we've ended up in this kind of it's not a nightmare Maybe because we have no learned to work around with it, but this kind of Maybe I've just been here so long. So it's not a nightmare for me anymore because I'm from from scandinavia. So it's just always dark Maybe that's the thing and being down here in the sun is kind of like That yellow thing out there. I'm getting a little bit frightened of anyways We the thing is that right now we have for the first time actually an idea of Holy crap developers are listening to funding developers. Oh my god crazy talk with What? Okay, so what we need to do is get all the front-end developers Yeah, he's got sessions after So if any of you are front-end developers and have opinions on what we should be doing in Drupal We need your input. Tell us what you want and we can try to make some changes Um, we've got to configure how to consolidate more of our template files We've got issues against almost everything in core, but we need people to write patches and people to test patches We need people to log on and just say I agree with this whatever Just so the core people know it's important. Um, and then we also need to be able to rethink the template suggestion process There's a really complicated issue So if you're a super developer and want to figure out how to solve some really hard problems There's some issues around that as well And then we want to make it really easy to change your template files in different places There's a patch for that too and then the last thing is trying to figure out how to to redo preprocess Which this is not urgent But we need people to start thinking about it because there's a lot of work to do once we figure out what we're going to do And then we've got to start converting things all into twig format too. So there's a lot of stuff We're going to be doing at the sprint on saturday So everybody put your hand up if you've written html or css or javascript before Keep them up everybody keep them up. Okay, put your hand down if you've Written a patch before Put your hand down if you've you've all written patches before Okay, keep your keep your hand up if you haven't written patches before Keep your hand up if you haven't written tests before keep your hand up if you haven't contributed to core before So tomorrow morning before the sprint there is a how to contribute So come along to that. Okay, everybody with their hand up come along to that one so the the html 5 initiative is basically finished up already and I'm I'm pretty sure aria is in the templophiles already Um, so they just came along for the ride when they got converted to twig So we're doing a subset of the list. We just talked about tomorrow the sprint. So if you want to come out We need you Um, and we've got maybe like five minutes for questions. I think we did that already We're trying to get away from that right, but but yeah, so the the the problem so The thing that the magic that happens in the background is basically it is a new syntax, right? It's this twig syntax, which has been around for a while a lot of other projects are developing or using the same Syntax even though they're not using the twig syntax or they're not using the twig system. They still have the same syntax um But the the magic in the background for the twig system is that it takes that syntax. Um, and it actually Converts it it it compiles it from that into an actual php snippet of code and then caches that Right, so when you're actually loading a page, you're not even looking at the twig files anymore You're just pulling up these php snippets that are So So Yeah, and I would just say that that as a templating language php sucks I don't believe I I don't think that it prevents anything. Um, it has all the control structures that actually So it provides all the regular control structures that you would expect loops If condition statements and all that and you can also go one step further and actually tell twig Which of those control control structures you want it to be able to give the front end developers access to so you can modify that Yeah, a template engine. We can just use php php is a template language and back then I I think it was like seven or eight years ago. There were there were template engines around, you know, there was smarty and others um What do you say to that? How is it different today? Why is twig a better option? um Why did we decide php was the template language for us and now a template language is the template language for us? Yeah Yeah, so I've been doing dribble for eight years now and I remember this is adrian russo who came up with the php template language And if you look at the alternatives at the time smarty Was not the smarty it is today, right? It was really Well, yeah You know that it wasn't until like three or four years later that another template language. It was developed called Oh, what the heck was it? It was the opposite. It had an opposite name of smarty. Does anybody remember this? It wasn't dummy. It was like um Yeah, it was something similar to that It was it was called dummy because it was like i'm trying to not do all the stupid stuff that smarty is doing um They weren't written in a way that was actually particularly fast They were very slow because they were trying to interpret their own syntax on the fly every time you requested them So php template was a really good alternative to those templating languages at the time But A lot of really new stuff in php, right? Where we couldn't have used it in dribble six because dribble six didn't support a new enough version of php To do all the stuff that twig does so now we have cool new toys and someone wrote a template language that uses the cool New toys and makes it perform it twig is object oriented. It's it's really fast There's like a bunch of stuff that we can do with swig that we can't do in php template We can sanitize everything automatically we can run functions like t so developers don't have to we can No one has to understand data structures like there's just a lot of places where We come out on top So it was one of these things where like yeah, we solved this problem years ago But technology advances fast So let's reevaluate this problem and the solutions that are out there and think about it again This is the perfect end solution for everything. It's kind of Chicks kind of came up with twig first and tried to hunt people down and then we're doing the code sprint where Agents theme system pretty much got killed over a table And the reason that chicks wanted to have in because this whole sandboxing thing and No, other of us just want to have an easy way to draw down to variable So it's kind of a match made of as much other technology got. Hey, I get my little thing in I get my little thing and I get my little thing and you have this bastard child But then suddenly we figured the bastard child here is actually Somebody voted for us and we can use it and everybody seems to be happy at this point in three years We will probably be angry as hell So I actually I didn't want twig I thought php was much better and we should just all sanitize our own variables and do whatever in php But it turns out that everybody else wanted twig and I was like well if everyone is happy with this solution Then that's obviously the way we should move forward Yeah And I would just like to add that I was also not a fan of twig when we went into that sprint deciding what we were going to do I was like, okay I don't I don't think we want to go to another scripting language, right? and When we went through the problem space and went through the possible solutions then twig just became an obvious choice Scott Yeah, just a really quick question. Um, I've never used twig before but I have used liquid Are they like is liquid based on twig? Those who are familiar with yeah liquid syntax and things like Shopify and Um, it looks really familiar like very much to say are they in the same family? So you're using jekyll or something like that with liquid layouts or Right, okay, so yeah, I don't know which one came first. I think they were actually um in conjunction because um, so jekyll's off a um ruby Platform and they both have shared from Django. I think the Django heritage. So yeah similar heritage I think one of the things that Is really important about this is actually Really from outside the Drupal world and I think that's something that sometimes we forget but if you look at Happy cog if you look at clear left if you look at some of the the very best thinkers in the wider web world The reasons they've stayed away from something like Drupal is because it doesn't give them the control over What's coming out of it? And this is finally a chance to actually use Something similar to expression engine or some of these other platforms that do do a very good job of it While still keeping what's important about Drupal with the flexibility of the content modeling and everything else so I mean, I don't I'm not enough of a developer to have that great an opinion of the technical merits But just in order to put it on a level playing field and make it the platform that someone like Jeremy Keith would pick up And use I think that's an admirable goal and it's worth it One thing I just want to kind of keep in perspective is that we keep talking about like twig exists elsewhere in the world But there are less front-end developers that know twig than there are front-end developers that know Drupal So we do kind of need to keep that in check and be like, oh, it exists, but it's like, yeah, you know But It's I mean, it's probably the easiest language I've ever written ever ever it's it's like Oh, let me just get this loop right. Okay done Yeah, it's um Yeah, yeah, it's going to be the same crap anyways and then somebody's going to frustrate the hell of a hell of a out of us, but Yeah, exactly. Yeah, so it's you know, it's I mean It's going to be I don't think we're going to have any problem with that That was actually one of the ground rules the thing about not dumbing it down that this whole I mean It might go we might going to have some menu tpl files It's going to be hellish to look at but instead of trying to drag that variable out of thing there and figure out Where does that come from we kind of can see it now or drill down through it or print it out on the page instead of the way Wouldn't it be nice of core? Was your good base theme? You guys can work on dribble nine I already have a dribble nine module out so Where it was the kind of thing where like I was writing something and someone's like, hey, have you heard of this now? I was like, no So it definitely wasn't in the front of our mind But it's the kind of thing where it's like I can totally see that as a contrib thing for someone comes out with a module And it's like ta-da everything works the way you wanted to So it's definitely like this is one of these things where when we first decided on twig we had a very limited Set of requirements and then as we've been working with it. It's like, oh, we also get this we also get this We also get this we also get this and there's just this all the stuff that you can do that We didn't even think about it. Yeah, and I mean this is exactly what's great about open source Of course, right? So because the more people who are contributing to it the more solutions that you end up with so Instead of just Drupal developers working on the twig system We have all these like other people who are also using the twig system and we end up with a better More, you know more robust more flexible system than we could have come up with ourselves The thing that we came up with by ourselves was Drupal 7th's theme system, right? It's probably going to be the same issue I mean, so there's a bunch of like licensing inclusion stuff that we haven't quite figured out where like Drupal has a set of Rules but likely break them when we feel like it Um, I think that what's going to happen is Drupal 7th's going to ship with whatever version of twig ships with and then there's going to be At some point a new version of twig and then there's going to be a contrib module that'll help update it It's a little harder because it's so ingrained in everything that Drupal does Like when you get a new version of jQuery, you have to provide all of the new functions that rewrite It's going to be the same thing only a lot more work Um, so we'll we'll see I mean it could be that you know Drupal 7th's around for two year or Drupal 8th's around for two years And we've got to deal with it for two years, but I don't know if someone gets angry enough. They'll write something I I think that's an excellent question because it makes me think of something that I hadn't thought of before So the problem with jQuery the reason why we couldn't update to jQuery was because we'd written our you know Our libraries built on top of jQuery In a way that wasn't really the best practices and so they were really tied to that specific version of jQuery And when you had the new version of jQuery, then we would have essentially would have to rewrite all of our jQuery stuff So, uh, I think that we need to be really careful with the way we write our filters Because those are the things that we're tying heavily to the way twig works right now and if that you know system changes so, um This would be an excellent question to like ask trees or ask the other initiative leads at the drupal 8 Core conversation later this afternoon Because it's not just twig. It's all these other symphony components that that complies to Sorry, there's a little extension on that. Um, the symphony community is really aware about how these components are being integrated into other projects So backwards compatibility and making sure upgrades don't break. What's what how people are using them is a really High priority for the community Okay, we're we're out of time. It's lunchtime now though So if you want to grab these guys before you leave and force them to not have lunch otherwise thank our team For a great conversation and please do consider coming to the code sprint tomorrow or the how to Contribute session tomorrow