 Do theme implementations to the science, how to take them open? Unfortunately the microphone was off. No, I think that what we're trying to figure out is, kind of if you look at, I mean this group of people, we have fairly quickly found out that we have different positions in the community. I mean, I am now probably more in the design front of it and just as an end user of Drupal as a theme layer, where we have other people who really didn't want to fuck around with the design layer and just know the technical aspect of it, that's interesting. And the thing is that we're trying to figure out to not end up having a theme layer that the development community will hate to pieces because it's not secure. And the design, you know, the themeers will hate because they cannot figure out how to use it. And we're going to end up having a kind of a monster that none of us can use for anything. So, but to actually get to that, that's why we kind of need to figure out who people are. So how many would define themselves as designers, slash, you know, mark-ups, CSS people? Okay, how many is more in that whole technical, oh, we got arrays here. Good luck, 50-50. We can start a fight. So how many of you are really competent with HTML? Almost everyone. How many of you are really competent with PHP? Most of you. And did you learn that, like I learned PHP through Drupal, not before then? Okay, so you might not a real PHP, you might just know weird Drupal PHP. How many of you have never touched the theme layer but are really curious about what's going on? That's pretty good. Okay. So is there anyone else in the room who is a non-coder at all? Like, I don't touch any files, I just want to push buttons and make my site change colors. Yeah, actually, can we just raise the hands again? Okay, so confident with HTML, confident with CSS. Confident with PHP. Learn PHP for Drupal. Just wants to push buttons. Awesome. I think that probably represents the people who are first coming into Drupal without any sort of background of coding at all, which is also a really important demographic for this. He's got like a four o'clock meeting or something. He may have decided that wasn't viable. I mean, it's not really like him to be late, I don't think. He did show up for our session and where was it done or like half an hour later? Yeah, but we can't wait that long. We'll just do it. Okay, so we're going to go ahead and get started. We're missing one member of our team. Hopefully he'll show up before his slide, but if not, we'll make do. So we want to start by introducing ourselves and maybe we should start on that side with Alex. Alex Bronstein. And I'm Drupal.org. I'm Efulgencia. I'm one of the co-maintainers of the theme system. And I am definitely on the back-end side. I don't know a diff from a span. So, you know, I'm very interested in what the needs of the front-end developer community are to make sure that our theme system reflects that. And in the history of the Drupal project, we haven't always been good at making that happen. So thank you all for showing up. Thank you in advance for, you know, giving us feedback and participating in the process of trying to make the theme system better. And I'll hand it over this way. Okay. So, my name is Charlie Neesche. Better than the CAJACs. Somewhat I started the conversion to Twake. One of the problems is that I won't have that much time to continue this. But I urge everybody who would like to see this happen to help. Thanks. John Elbin. John Elbin Wilkins, actually. It's my full name. And I'm also one of the theme system maintainers. But I call myself sort of a mutant hybrid in that I know both the sort of back-end PHP code and the sort of course system within the theme system. But I'm primarily in my day job doing front-end stuff. So, you know, doing theming. I sort of, I go both ways basically. I don't. Hey, I'm Morten, the king of the north. I tried to get that name in. I'm more of a designer. I actually came in through the designer and the front-end thing. And I've been trying now for six years to get the community to understand that the way of tuples mark up and the way of thinking is not right. It's slowly getting there. At least what we can see this room is an acceptance of this as a problem. So that's kind of, I'm the angry man up here who doesn't want to know about the code and just what I do. I wanted to fight with him all the time. No, so I'm hoping to get more of the designer and that aspect, the end user, the HTML CSS nerds to get them in on it. That's actually what I want to go back to instead of hacking through PHP functions that I don't even understand what they're doing just to get them to do something I want. So, that's me. I'm Jen Lampton. I've been working with Drupal for six years. And my first interaction with Drupal was in the theme layer. I'm now a developer. I've got developers modules on Drupal.org. And I'm trying to work on getting a new theme layer into Drupal 8 and really passionate about making sure that new people have an easier time getting into Drupal so we get more contributors in our community. Hi, I'm David Needham. I've been also working with Drupal for about five years or so. I'm kind of the working man themeer where my day job is theming. So, while we have some developers here and some designers and some people who are more focused on the back end, I do theming day in and day out. And I knew HTML and CSS coming into theming, but then I didn't know really PHP that well. And I basically learned PHP through wanting to do different things in the theme layer. And so, I think I'm here for a little bit of perspective about what I would like to see from the next version of Drupal theming. I'm Chris Vanderwater. I'm the blocks and layouts everywhere initiative owner for Drupal 8. I'm here because this touches very heavily on a lot of the stuff I'd like to be doing for myself. I feel competent in HTML, CSS, PHP, Drupal, whatever. So, I came to Drupal as a themeer and I really care about this stuff even though I primarily developed these days. So, we did this a little bit at the beginning to try and figure out what your knowledge was, but we also want to get a feel for some of your... We have a little bit of room up front. Experience. We stole the chairs, though. Yeah, we took all your chairs, but you can sit on the floor if you want. All your chairs are... So, how many of you have built themes for Drupal 7? Okay, leave your hands up if you've built themes for Drupal 6 and leave your hands up if you've built themes for Drupal 5. Okay. For 7? No, no, that's too old. For 6? No. Sorry. No. Okay. How many of you are really new to Drupal and are really curious about what the future may hold? So, maybe you've never written a theme before. Okay. And then, how many of you are experts, maybe even core developers, and you want to know what the heck we're doing up here? Okay. I feel. That's pretty good. All right. So, we're trying to make an entirely new theme layer in Drupal 8 if we can get it done in the time remaining. And we're going to be using Twig. So, this is a modern template engine, which is really cool. We're using new technology instead of old technology, which will be great. It's really well documented. It's easy to extend. It's secure. It's well tested. It integrates with an IDE. So, for those of you who are developers, you'll be able to, like, troubleshoot, which will be nice. It's got a recognizable syntax, which we'll show you a little later on, similar to Python, JavaScript, and Ruby. And it's written by a symphony's author. So, symphony's also something that's gotten into Drupal 7. Excuse me. We've had some technical difficulties so far with trying to implement Twig in Drupal, and I'm hoping that CHX will be able to talk a little bit about these things. We've tried several different courses of action to get patches in and run into some significant problems. The first of which is that we've had a lot of trouble replacing the render system or running Twig with render at the same time. So, maybe you could talk a little about that. Okay. So, the fundamental problem is that the render function modifies the array you have passed into it, and Twig is simply not created to be able to do that. With Twig, you are passing a context into the template, and there is no way simply to do this. I have hacked Twig itself to get some ways there, but when I have submitted that, then obviously the Twig authors have refused to accept it, and it is indeed not acceptable, because if you are using something like an array access, which is not too far-fetched, because one of the preliminary patches that we got in which have simplified the fairly dreadful classes array syncs in 7, now you can just use classes because we are using an array access object. So, if you are using an array access object, then while you can pass it to Drupal render, it's not going to work there either. It's not going to work with Twig either, and so for this reason, the Twig also simply refused to accept it. We could extend Twig with this hack, because Twig is almost infinitely extensible, but it would be very ugly. There are two ways we have discussed that we can attack this problem. One of them is to use pre-process to run all the Drupal renders that you would have run in your template instead of do it in pre-process, do it in PHP, and then in your Twig template just print those variables. This might be acceptable while we are converting core, but we cannot leave this as a sheave when we release, and the problem is that we will need to have a sheave in place because there are three months left before feature freeze, and it's almost impossible to convert every form to Twig. Renderable is going to be a big enough problem, but to change every form into this, it's just impossible. We are not planning to do that, so we need something that can take the form renderable arrays and make it work with Twig. The way we can do that, we have a class which can hold approximately the same information as the render arrays, but it is an object. It's an object. So what we can do and what we probably should do is to patch up the Drupal render to convert first into this object, because if you are passing around an object, an object you can modify, unlike an array, right? If you know PHP 5, when you are modifying an object, all copies of it get modified because objects are passed around by handle instead of by value. So this is one thing that we probably can fix the render and Twig living together. This is once again something that needs to be done, researched, coded, tested. Once you have that done, you will need to begin to convert everything you see, which is renderable in 7, which is practically everything, to use this class instead of render arrays, not forms, not forms, because the problem with forms is that it's a problem, but we are using automatism to derive data structure and render structure from the same data structure. Unless you are setting pound parents, we are using the same structure to derive both. So logic and display is not separated, and basically we do not have the time to separate those two. We would like to, there are issues for this, even without Twig, no time. So part of those problems are all contributing to our issue of being able to create a first working patch for Drupal 8 because the amount of work that needs to get done to do all of these things at once is almost insurmountable. We're also... I just wanted to say, so there are maybe 10 of you who understood what Chicks was talking about, really fascinating discussion for you 10 people. That was also the most technical slide in the deck. There's going to be a lot more sort of accessible slides for the rest of the talk. Don't be like, oh my God, I'm in the wrong session. We need the non-Tegi people in this session. And to take the people together. We need both duality. Also partly what, in case any of you don't know, partly what happened was there was a schedule change. So there were actually two Twig sessions. There was sort of a beginner level front-end track that was initially scheduled to be here in this room, and then there was also a core conversation. And we actually asked for those to be swapped. So we had the intro level one yesterday, and this is officially the core conversation. So if you got here through the website, you're in the right place. Or if you got here from the signs that are out on the door, you got to the right place. But if you only followed what's on your badge, then you sort of inadvertently ended up in a slightly more technical session than you maybe were planning on. Don't leave. Lock the doors. Gotcha. If you want to leave, that's totally fine. No one will be offended. But at the same time, I actually think in a way, it's a good thing because we need the front-end and the back-end community talking with each other. We need to have, you know, Chicks basically has done a lot of the really back-end work to get us this far and to identify problems. Like John said, if there's 10 of you here who understood what he said and can help us resolve those problems, that'll make things a lot better for all of us who are here. Yes, one more thing I wanted to say about the process. So I have posted this on Drupal Planet that I consider greatly important for Drupal 8's success to have this and other front-end things done. And I am going to give one hour of my time every single day from September 1 until we release Drupal 8 to have these front-end things. So if somebody wants to get into TREG, I am going to help ongoing. I will not be able to do it myself, but I will help. So there's a couple of other things we're planning on doing, like removing some of these crazy layers. We'll talk about a little bit more like process and maybe pre-process also. And that's also presenting an issue with a lot of work we've got to do in order to do that. And we're also running into problems with trying to figure out how the new theme system will interact with the new user interfaces. For example, the blocks everywhere initiative that Chris is running. There's a lot of stuff we haven't figured out yet and trying to figure out how two things we don't understand yet will fit together has also been really slow in getting going. There's also probably a whole bunch of other technical problems we haven't run into yet, because we're not very long and we're long in the process, and that makes me personally really worried because we only have so much time to get the systems. The problem is that we just can't convert core in one step and that we cannot convert forms at all. And because of that, we have some difficulties to reach but we've got really far. It's really the process that is a problem, you know? And there are like hundreds of renderables to be converted. All right, so there's a lot of work and hopefully we've got it all figured out. But we want to go back a little bit and talk about why we decided to change to twig. And I'm going to show you a couple of code samples here. Apologies if you can't see it very well. This is the node template. Current status of Drupal 8 right now. And it's kind of a weird syntax that only exists in Drupal. There's also some inconsistencies. Sometimes when things are printed, they're accessed as objects and sometimes when they're printed, they're accessed as arrays. And that's really confusing to people who don't have any understanding of PHP or programming and they don't know when they should use one or the other. Sometimes things are just printed variables like title just get printed to the page. And sometimes things are print rendered to the page. So if you have a renderable, you call this function render and that's also really confusing to new people. They don't understand what the difference is between a variable that needs to be rendered and one that isn't. We also have PHP and templates is really insecure. When I was creating this slide, I accidentally refreshed the page on my site and dropped my node table. So even people like me sometimes wish that you couldn't do PHP and template files. This isn't necessarily a concern to most of you but it's the kind of thing that makes the whole developer community in Drupal really nervous just because we don't really know what we're exposing people to or what they might do that may be naughty. It's also a mess in Drupal right now. We've got a lot of template files that are provided by every module in core and every module in contrib likes to write all of their own markup too. And people who write modules might not necessarily be the best people for writing markup to start with and that leaves a lot for people who are experts at writing markup to have to clean up after. So we've got too much mess in there to start with and we'd like to get that cleaned up too. I'm going to change over to John so he can show you some complex mix of subsystems that are currently going on in Drupal 7. Why is it... So this is a simplified version. Why is it... Of the theme layer in Drupal 7. I'm not sure why it's cropping the left and right side it's not showing the full screen. Secondly, it wasn't doing that when we were testing. Where is my mouse? There it is. 1024 by 768. That's the right size. Let's try this again. Sorry. It's 1024. Yeah, okay. I really do have an S on my slide here. So this is a slide that I gave at Drupal Con San Francisco at a core conversation because I was one of the few people who had sort of looked at what we ended up with right before Drupal 7 came out and this is literally...it's simplified. There are some things that I left out just because I couldn't fit them into the page. This is really crazy. I want to explain this in 90 seconds, but I had to talk really fast. There's a lot of things going on. Theme registry, theme hooks. Hook theme defines what's in theme hooks. Variables, templates, theme functions, preprocess, process, process, template preprocess, template process, which I left off of this slide and render element is a whole nebulous area here. This is obviously kind of crazy how complicated the theme system got in D7. And people were really shocked by this slide, but it wasn't until later that people started to realize that there's actually some really disturbing imagery embedded in this. Yeah, so it's not a pretty picture. All right, so we know this is a problem when we started working on sprinting towards getting Twig into Drupal 8 earlier this year after Drupal Con Denver. And Martin had a front-end United conference where he did a sprint with all of the front-end people to try and figure out what the top concerns were with the existing theme system, and this is what we've come up with. They want the ability to add, change, and remove markup easily. Consistency in the data that's actually presented to the theme layer and sensible markup defaults. We also had a bunch of developers requesting other stuff like making things more secure and making the theme layer more performant. So that's what we've got right now. If you guys have any other concerns with the current theme system, we want to hear about it just to make sure that our priorities are on track. So does anyone have anything they really want changed or hate about the system? Yeah. Can you just use the mic? Where's the mic? Is it on? Yeah. I can just repeat the question if you don't want to. Yeah, you're welcome. And this is partly because I don't necessarily understand the multi-layers of theme stuff. But one thing that I know is an issue and concern that I would like to sort of have kept in mind is the aspect of semantic markup and accessibility, because especially working for universities, those are kind of like non-negotiable things. We need to be able to do that. And of course, we'd like to do it easier. So just that reinforces the first issue, an easier way to change the markup. So if you don't think the markup from Core is semantic enough or you want to add additional accessibility, it's got to be easier to do that. Yeah, I'd also say that in Drupal 8 we already have HTML5 markup, so we have that semantics. We also have a lot of the aria roles already inside the templates. So part of that is being addressed and as we convert those, you know, TPO-tipple-fips from the PHP template system over to Twig, those will continue to be there. Yeah, one of the things that we talked a lot about at the front-end in United Spain was actually that whole thing that we don't have any idea what tomorrow will bring us of markup change. And the problem we have in Drupal is we're always two years behind. And it's not because we have evil developers. It's because nobody told the developers what we wanted. And I mean, all developers I know, they love to get a challenge of, hey, can we do this? And they'll go, give me 10 minutes. And then Shakespeare will come back with a big thingy I don't understand and he'll say, is this what you want? They'll go, yeah. I mean, and that is what we from the front-end thing need to be better at to actually figure out what is it that we really want. And we want to change everything at any given time. It's not really the end for it. That's the Christmas wish. So we need to be a little bit more concrete and try to figure out actually what is it that we really want to do right now? What is the real problem? Yeah, I would like to see the ability of more template engines to use. As a passionate front-end, I would like to be free of what template engine I prefer. There's also lots of innovation going on in that field. Just to mention client-side templating, which I think is the perfect solution. Also regarding the inclusion of some CSS pre-compilers like Sass and Compass. So I definitely would prefer to be able to work with something like Stylis in Drupal 8. So I think technically spoken that would mean that we would need a Drupal 8 core, which provides us a sort of API style to hook whatever template engine we would like to use. So that would be... I definitely would vote for that. Okay, that's great. We'll readjust that a little later too. I think to... So the multiple theme engine thing has been raised. We have discussed it. There's a trap. There's a trap in it. The problem is that it is not hard to provide multiple theme engine compatibility, but contributed modules are not going to be able to maintain several sets of templates. We cannot expect that to happen. So if you look into seven, what actually happens is I would surprise that this is there, there is an explicit exclusion so that modules are only able to provide TPR.PHP files. Because it is unreasonable to expect from Contribosals to maintain several sets. So we could provide a possibility to have several theme engines, but don't expect that any Contrib module is going to help you with that. So you will be completely alone. Yeah, that's a really awesome point. If we did that, you would have to start looking at modules and see whether they support the theme engine you want. We're talking about how much effort it would be just to convert all of our existing theme functions and TPL files into Twig, much less anything else. So from a pie in the sky perspective, yeah, I totally hear you, but I don't know of a way to go right this second. We probably need to pick one that we can all live with and really try to move forward there. So the point was made that back in the day, you actually could have different theme engines, and the reason for that was because Drupal only used theme functions. It generated the markup within these PHP functions. There weren't template files, and therefore it was really easy to have template files that did certain things, and the rest of it was done by PHP functions. So you still once again, you have the capability right now in the same system with revision for five. Five, six, and seven has a way that you can supply an alternative theme engine, but modules cannot supply anything else but PHP template, and this probably is going to stand for eight as well. So if you have a custom site and you want to write a custom theme engine for that site, go ahead, but there's not going to be anything more than, you know, this is supported, and you are alone. I wanted to address the other half of your point about the SAS. We have a slide for addressing this later. Oh, do we? Yeah. But if we could see if there's anything else that we should come back to and address later too. Right. One comment that I'd like to make coming out of some of the observations we've had is that the architecture of what we're doing is too complicated. You can't reason with it, but part of making it simpler may just be to create high-level concepts that collect together the things we've got. It's not necessarily less functional to simplify the architecture. So we need a simpler form of your diagram that I think works. We'll get to that one slide. That's like one of the next slides. Yeah. All right. So we will return to these later. If you have more things you think of during the rest of the presentation we will have a discussion at the end. So we wanted to talk a little bit about how we think TWIG can address all of the issues we've heard so far. And we're going to start by showing a simplified theme diagram of how Drupal 8 may look. So don't freak out. This is Drupal 7. Okay. Rearranged. It's the same exact diagram, just rearranged all the lines and boxes to map better with the diagram I'm about to show you, which is the DA1. And that's this. I'm going to go back and forth and you can see like there's just huge swathes of stuff that just are gone. The nice thing about this is that we've simplified the architecture because we have there's so many different ways that you can do a particular thing. If you have a particular task, there's like eight ways to do it inside the theme layer. So we want to simplify the decision process of how I'm going to go about doing something by making the architecture simpler. So then there's a way that you're supposed to do it. But we also want to ensure that the same functionality, the same capabilities that we had in D7 we're still able to do those things in D8. One of the the one sort of like just brainstorming idea was like, oh well let's make the D7 theme system easier by going back to the way it was in D6. That was literally a step backward but it would have given us a headache with all this capabilities that even though the system was complicated in D7 it allowed us to do a lot of things. If you figured out how to do them D8 you will still be able to how to do them. It would just be done in a slightly different way in a much more consistent way. And one of the ways that is this audible? Sorry. So one of the ways in which sort of that's achieved is that variables bubble. There's a lot of sort of interesting magic that can happen there. Right now, part of what was on that other slide is we had all these other bubbles like we had pre-process and process and pre-render and so essentially, yeah, a lot of stuff around variables and that's a lot of what goes away and it's specific because that's one of the key issues is how many things can alter the variables that you get and at what point and so by making variables basically smarter we can still provide the same kind of functionality just exposed in a more unified way and that actually gets into some of the technical stuff that Chicks was talking about earlier around how to integrate, how to turn variables into smart variables, expose them to twig as smart variables that can then still be manipulated by modules to the extent that they need to be. For example, the RDF module still needs to be able to insert the attributes that it needs to insert into all of the different pieces. There's other use cases for needing to manipulate the variables by making those variables basically smart variables that can get refined through a consistent and unified process and exposed to the twig templates in a unified and consistent process. I think that's where a lot of that magic happens in going from diagram one to the other one. One of the major reasons why all that pre-process stuff goes away is because they're smart variables when you're inside the template you'll be able to do a lot of really cool stuff right there on the variable as you're adding it to the template file. So the need for this whole other pre-process phase of trying to use PHP and all this stuff just sort of goes away. All right, so to address some of the concerns brought up before how is Twig going to help the ability to easily add, change, or remove markup? We're going to get rid of theme functions entirely. So all theme functions will become template files which means when you need to override markup to it in a template file there won't be a question of where did it come from and how do I override it. And the template files themselves will be using a much cleaner syntax. We won't have print render, we won't have array access versus object access. It'll all be the same consistent markup and twig syntax in your files. Consistency and data presented to the theme layer. Everything will be a smart variable and you can drill into everything in exactly the same way. I'll give you some examples a little later on. I think maybe not. And then sensible markup, defaults, common patterns. Twig doesn't actually solve this problem but in the process of us having to go and replace all template files in core with twig templates we're going to need to review everything. And so it gives us an opportunity to look at it with fresh eyes and say do we really need this div tag here or can we take it out? Do we even really need this template file or can we reuse a different one? That's currently in core and get it up to date, refreshed and more consistent. Yeah, there are several actually way too specific theme files inside Drupal core that could be, we could use a basically reuse some of the template files rather than having specific ones for like book links. There's a lot of clean up we can do. Just remove this and then reuse some other components. So we can make some of the templates more reusable and then therefore get rid of a lot of the ones that aren't needed anymore. And to address some of the developer's concerns, twig also has the ability to auto escape so you won't need to figure out as the emers whether the data presented to you is safe or not. Twig will automatically sanitize all the data when it's being printed so you don't know when you need to run checkpoint or check markup you just print it and twig will take care of that for you. And because twig starts off as templates and it's not going to be the same with the template files, if we can clean up our act with the template files anyway and recycle a bunch of stuff we're hopefully going to get a huge performance gain in the ability to load one wrapper template file and print it 20 times on the page rather than in the PHP template version where you'd actually have to read it from disk 20 times and parse it and print it 20 times. So hopefully we'll get a performance gain and a huge security benefit by using something like twig. And then to address the things that were brought up earlier, we're not really sure this is going to help the pluggable theme engine thing, but we did horribly break the ability to have pluggable theme engines in 777 by putting PHP calls to functions and template files and we'll be removing that. And front end templating will actually be really slick in twig because there's something called twig.js that lets the template files that you're using to produce your PHP pages also to be used in JavaScript. So same template file can render front end, back end, doesn't matter, which would be really cool. So also presents us the ability, twig is safe, we can show it to people on the browser so we can get kind of a WordPress style editor that's like, here's your template, would you like to edit and save this? We're not doing that in core, but it does open up a lot of doors to stuff that's no longer taboo like the contemplate module. You can now actually do stuff in the browser, you don't have to edit files on your file system to get that cool stuff in that direction. We already showed you the picture of a new simplified architecture, which has been really great. And then was there anything else that was brought up earlier that I didn't address with the twig, possibly solving all the problems in the world? Okay. So before we make this huge commitment to twig, which may already be too late because we really like it, we want to make sure that we're not removing tools from our front end developers that you guys really like. So what about getting rid of all theme functions in favor of template files? Do you guys like using template files to override your markup? Is that a medium you're comfortable with and tool that you like using? Can we get a show of hands for I Love Template Files? Okay. How many of you Is there anybody who's honestly a no to that? How many don't like template files? Just like one or two. So developer types probably. So template file syntax is going to be just the concept of That's the question. Okay. What about using theme functions to override your markup? How many really like the PHP theme function override in your template.php file? I have to do it. You do it all the time. If the alternative, in this case the alternative will be a template file that has mostly HTML in it in this case. So how many of you hate the PHP theme functions that you have to put in your template.php file? How many of you would rather have tpl overrides style instead of theme function overrides? Okay, so preprocess functions. How many of you really like the ability to have a preprocess function to add or change variables that get printed out in your template file? Okay. And so is there anyone who hates the preprocess function and would much rather just dump that PHP code right in that template file and skip that step? Okay. So we still have more people would like the preprocess than do it in the template file. Yeah, if there were an easier way to get new variables into your templates, would you be open to it? Yes. Easier. He has a punch in the face and he has a donut. Okay. One thing about these questions, they're kind of weird to me because I am used to doing things the triple way to get what I need to do my job, which is theme. So if we're talking about new files or new way of doing things, maybe we will have the same problems that I use a preprocess for. So I don't necessarily want a preprocess if that's a non-issue with twig or with whatever changes we're making. We also have a slide for in a perfect world if you didn't do things the way Drupal made you do them. So maybe we'll wait for that. I don't know if this is all based on what we have, but that's where we're starting. That's where the question comes from. He really has a question. I guess concretely it's what about loops and conditionals and things like that? How do you do that? Maybe I haven't put any syntax examples of twig in here, but I've got another presentation open. I can show you that. A couple more. How many of you are currently using hooks in your theme? Do you love those hooks? This is new in Drupal 8. We added all these things. Sorry. How many of you hate the alter hooks? That's pretty good. People like them. It's the same sort of question. We like them because it gives us the power to do what we want, but we don't like the way that it works. Would you be completely unopposed to writing a module that did that since it's exactly the same syntax? Yes. Personally, I wouldn't want to write a module that did because I had to write them. You're telling me that I would move my PHP code from my tabletop PHP to a module just because the thing that I'm altering in the template.php file really is a theme issue. How many of you hate the idea of having to write a module to go with your theme? That's Drupal 6. The whole form who also takes care of that. That's the reason I always have this little crap module with me that basically took care of forms grown up enough to take care of forms of my themes, so I had to do a module for that. So the question was kind of a theme that depended on a module. There's actually a patch that there's an issue that was submitted by CHX when he asked me this question in IRC two years ago. We should be able to do that. He wrote an issue and assigned it to me and said, no, write the patch. It's still an open issue. It's still an open issue. It's not actually that hard, but it's got so much other stuff on my plate. It's not an itch that I have. It'd be really easy, but I need somebody else to like, ooh, I want to do that and go and do that. And I can help you out maybe a little bit, but I don't have any desire to go and write that patch. We're going to get you drunk enough to get you to do it. So, yeah, let's keep moving here. I'm just going to kind of like gloss over this particular topic at this point. Treating themes as though their modules has some negative ramifications, but like if it's really a killer feature, then maybe we should just visit different ways of doing it without like making it too different. I don't know. We just wanted an answer and I think we've got one, so. Okay. So, forgetting everything you know about the theme for Drupal. If you were tasked with, you know, make a theme for a website, how would you do it? I write Drupal themes, not a themeer, and my approach is to start with a style sheet and stick it on top of Drupal. And when Drupal doesn't give me a class or whatever, then I go and alter Drupal to do that. And I feel like that is the standard mentality of almost all of the Drupal community is that we don't care what comes out. You just stick it on and it'll look pretty and I feel like that's really offensive to the people who are of like skills in the art of HTML and CSS. And I want to know what you would do if you could start clean in terms of creating a theme for Drupal. So does anyone have a story of like, I wish I could X to do a Drupal site? I can't answer that question. You've got to turn on your mic. Okay. Go ahead. So, my dream scenario, the thing I've been dreaming of for six years was actually the, oh, I just did this beautiful markup and now I take Drupal thing and I now put in the small variables where I need them and I can render all the stuff out and Drupal doesn't touch my markup and I can move it around in some kind of business logical way so I don't have to get special modules to do all this kind of stuff. And I can take my, the way that I figured out, oh, IE 8 is dumb because of this, this and that Firefox 7 doesn't get this Chrome 12 doesn't get this whatever and then I can patch my markup in, patch my CSS and then when I figure out six months later, oh, that was totally bullcrap but I did way back then, then I can change my method yet again and that's kind of the whole thing that we cannot expect to figure out now what it is that the future will bring us. So that will kind of be my dream situation. So you like to do HTML first and then put Drupal into it rather than okay, is that the kind of general consensus from people who are artists at HTML and CSS that you want to write it regardless of the crap that Drupal spits out and then stick the Drupal in? Can we get a shit ton of hands so they understand? Okay. Anyone opposed? Say that too. Okay. Alright, so we needed to figure out how much of that dream experience is realistic in the end of Drupal. There's some weird stuff going on with Drupal's templates within templates within templates within templates that makes it really hard for you to do that all in one place but I don't know, maybe Twig won't help with that problem but we can definitely think about it and then it sounds like our priorities for Drupal 8 remain basically the same. It's what we talked about, the stuff that we figured out at the front and United's front cleaning the markup up making the system easier to use and whatever else. But we also want to make it easier for you to drop Drupal into your markup as opposed to stick your markup onto Drupal which is going to be really hard. So it sounds like we really like Twig. Can I get a consensus from people from what you've just seen right now? Or should I do code samples first? Okay. Code samples first. Code. What does it look like? Okay. So this is how you would write an item list in Twig. If you're going to write logic there's a percent sign in a curly brace that's how you put it around an if statement or a for loop and if you're going to print something it's just two curly braces. If you want to drill into a variable like if you want to get one level, two level, three levels deeper it's always a dot. So here we have an example with attributes where you've got values and attributes. And so you can get all the way down to classes by separating with dots or up just one level by attributes. You don't need to know whether it's a array or an object. And the length of this file is actually nice and concise. We've got, sorry I guess I have all the printing with double curly queues, logic commands with percent symbols and comments in pound signs. So I skip that attribute section. Okay. So this is an example of the theme username function. Again we're not only converting template files from PHP template to twig but we're also converting theme functions. So our current theme username function is super messy. Our theme username twig template would be really simple. It's only five lines of code. Actually it contains an anchor tag. All right. So our theme image function would turn into an image tag. Right. Sounds good. Theme link. An anchor tag. Thank goodness. And this is the theme item list function before compared to what I look like after. So in general we can remove a lot of lines of code from core by switching to something like twig. We do need to do a lot of work to get those variables that are now into smart variables so that twig can figure out do you want to print items which will do all of them or one item which will do just one or one part of an item like an anchor tag or a source tag for an image or whatever it is independently of everything else. So there's a lot of work involved. In the theme system the way it will work is that every theme hook will just have a template file and the list of variables that get printed into it. So it's more of a Drupal 6 style hook system where it's like this is the template, these are the variables and you guys of course would have a way to add or change those variables. We don't know what that's going to be, it's not going to be pre-processed because twig does all of this processing at the time it's requested not beforehand so there's no pre, there's no process it's just rendering won't be called rendering. We need to figure out how that's going to work but hopefully it'll be much simpler. And there's a lot more we don't know. Okay so now can we do a show of hands of just from what you've seen so far how many of you are feeling fairly positive about using twig as opposed to the mess we're in now? That's pretty good. We don't really have no chance to fight. Is there anybody who still has very serious doubts? Okay. So we had an architectural sprint in March that Jen organized and I was a twig skeptic coming into it because I was like okay just bring a new solution at it as necessarily going to fix the problems that we have in this theme system and we started with it specifically said let's start with a list of things that are problems right and then see if twig fixes those problems and where we had a set of criteria to evaluate twig against and it turned out it solved all the problems that we had and added in new cool things that made things even better than I had originally imagined so I in the days of the sprint I was converted I feel like twig does solve our problems but I have answers if you have questions about that. I also started as a skeptic because I know the move from 6 to 7 had its own issues and learning a new system completely like twig I felt at first it would become a huge barrier to entry for people that are moving from 7 to 8 but the benefits in the long run is how easy things are going to be if it happens it seems like such an amazing benefit that sure I'll learn twig. That's a great question. Have any of you ever used twig before? Yes, that's the next question. It's really new but yeah, okay. My question may actually be pretty much exactly the same thing. Twig is new and it's from people who we directly have a great relationship with. On the other hand the examples look exactly the same as smarty to me. A smarty was also really kind of hot stuff in like 2004 or 2005 and there was a Drupal 5 template engine based on smarty and my question is just like we're getting into this and I guess we're really committed to this and the question is twig is better than smarty I guess for reasons that are not visible in the code example. The big power of twig comes in the engine that's behind the scenes. It's taking advantage of a lot of stuff that's really new in PHP that smarty is old enough that it doesn't use just because it didn't exist back then. But syntactically you're right, it's very similar it works the same way. I think part of that is because they're trying to choose a syntax that's familiar to lots of people. It looks like mustache, it looks like Python. I haven't I looked at We'll work on that. I think that's negotiable. I used smarty maybe about six years ago. It's changed a lot since and I haven't seen the most recent version. I know it's headed in the same direction that twig is right now. It might be there already too but the underlying thing that makes twig so much better than PHP template is that one of the performance problems with PHP template is if we have there's a fieldtpl.php in core it's not actually used, it uses theme underscore field it uses that theme function by default unless you override it in your theme as a fieldtpl. And the reason for that is because of performance the way that we're using those files you end up having to basically evaluate that entire file on that file repeatedly and that is really memory intensive and you explain this better than I do actually correct me if I get this wrong it's really not very good for performance and the trick that twig has is that basically the twig syntax it's not just another file that has to reload over and over again there's a version phase so it takes all of the twig files and then compiles them into PHP classes so then Drupal just loads that file with the compiled class in it once and then the class is just in memory so then it just uses that class repeatedly over and over again to create objects and it's really fast so twig is the recent license Drupal is the GPL license that will have the effect of the designs and everything else as well because all of a sudden you'll be licensing which means that I can actually take all of your designs and take all of the stuff with it we forgot to have that license discussion yesterday that we were going to we all went to the big garden and Larry was there and we'll get the licensing issue resolved I'm almost positive but they're aware that there is this difference here right there's a lot of stuff we have to work out and licensing is one thing but I don't think that the licensing is going to be a blocker I think if we went to the twig community and said we want to put this in Drupal we'll be flexible I mean we were able to work with symphony maybe we just get twig on symphony's license I mean there's a lot of different ways we can go with it if at the end of the day they say like it's not going to be compatible with GPL that will be an issue but I don't want to raise too much alarm about that until we're sure that's the problem have you guys considered that the problem of the theme file discoverability because historically there has to be talks about when we created Stark taking all the template files out of us black caves of core module system and so on and put them all actually to the Stark template so you can see them or actually it's better to do it's kind of better api.drupal.org automatically it's kind of theme guide which just pulls the themes that annotates so you don't need to look for the files inside the Drupal file directory but you will rather go to the documentation page so which is better so I think that that's a really relevant like topic I don't actually recall ever discussing it while John and I were doing Stark but like when the question came up earlier about like how do you actually want to work with Drupal oh I want to write my markup and then drop Drupal into it like that's difficult by virtue of the fact that there aren't any themes out there that just have an override for every template available by default and if you made one is that what yours does oh okay let me retract that Morton is the only person who has a theme that provides a template for every TPL file in the system yeah and you know if he says it's a pain then like obviously there are other things to consider here but even at that like that number is only going to go up if we move across every single theme function to be a twig file and all of this so I mean there are a lot of considerations to make I think that if you dumped a theme like that on a themeer they would go away so what they'd sift through the hundreds biggest problem for me in the Drupal world is to figure out where the fuck did that yeah and I think discoverability is a huge problem so yeah one of the biggest problems is the pre-process functions they're adding in new variables and and the theme functions are completely undiscoverable really for an average themeer because it's somewhere inside the dot module file or maybe it's a doting file and then it just becomes really hard when we move that stuff to a template file to go into the core directory in Drupal 8 and see it's dot twig right is the file so there will be inside each of the core modules there will be a series of dot twig files that are related so at least that will make all of Drupal's theme hooks be much more discoverable because they're literally in files that are right there we haven't really talked about this either but in previous versions of Drupal they've lived all in the dimension in a single location and the reason that we split them out into all of the individual module files is because that's how contributed code adds their templates and so it got confusing for people to know if it's a core module it's in the engine if it's a contributed module it's in the module file and there's a chance that we can maybe change that pattern I mean we need to talk about it a lot but if what core ends up doing is providing a default set of template files for like this is how you do lists, tables, links, images, whatever modules can use those instead of having to write their own and put them together like here's a box that contains a table and a list and an image and I didn't need to write any markup and so then it would make sense to re-consolidate those template files into a single location we haven't talked about this yet but there is a potential here for things getting better in this area also I'll repeat your question if you want to ask it what if we wanted you to learn twig let me repeat the question first why do you have to why are you making me learn PHP if I'm just concerned about HTML and CSS and JS see this is why I'm not front-enders I think we have to get Morton to repeat that one can you we have that and the reason why PHP actually is so quite like just where it came from yeah exactly the difference between having when you want to use just HTML to help up the kind of the closure we're using all this stuff you have to have the same thing I think what the point here is is not so much that whole PHP thing the point is that we don't want to end up as front-enders with a system or language that doesn't make sense to us a system or language that we cannot change into whatever else we know about HTML, CSS and SVG generation things that whatever that comes in the future that's the thing what we're having right now is a system that is I mean that pushes people like us who see as front-enders out in a way that we have to do programming that you do very well I do very dumb and that's how all these security issues are coming in so we need to get this hope we need to have a bunch of front-enders who see themselves as front-enders who see who take a great pride in this to actually help you guys out that's kind of the thing that we need to do we're out of time I just wanted to say one thing just tell me how to use the template system right so twig has great documentation I literally I downloaded an EPUB about the twig syntax and the twig system loaded it up on my tablet, learned it on the airplane on the way to San Francisco when we had an architectural discussion it's really easy and it's well documented unlike Render API in Duval 7 so yeah and evaluate us we can continue the discussion out in the hallway for the rest of the day anytime you see any of us drag us and start talking about it and of course Friday we're gonna have yeah Friday we're having a sprints so thank you there's one final challenge if you guys don't mind just wanna throw it out just in a couple words we have to remember too that a lot of the stuff we build gets handed off and right now we're talking about that initial letter so I think we also especially we're talking about multiple templates have to think about how they get handed off we need I mean can I get five fearless front-end warriors I mean we need we stood up yesterday at a session and it used to be only John who stood up as how many Themas are working on Duval Core and John remember to tap me up on the shoulder like oh fuck oh yeah I'm into this thing you know and we were standing two guys and we need some I mean John is more of a program we need more people who really lives down into this HTML, CSS, JavaScript design implementation thing and the issue queue is a hard place to be we need a support group we need to do this in another way so I need some people to back me up to fight yeah thank you again okay all right lock the door no one's leaving okay wait before you all go I also want to just say there's two really important ways in which all of you or any of you who are interested can help and they're very important one for the people who've expressed concerns, doubts you know like especially if you feel like uncomfortable if you're in the minority you know if we're doing a sales pitch and so you know it's like you know everyone's like yay this is great and you're like I have doubts but I don't want to stand out please stand out actually we need the benefit of an open source community is that minority voices you know might actually have like might see things that the rest of us are blind to and it's great to get that feedback so you know we have the issue queue we have groups.truple.org other sources find us if you don't know the sources give us feedback give us negative feedback as much as positive feedback that's one two if you have positive feedback if you're excited about this if you think this is important participate in some of the same you know online channels and actually make those comments because you know even if this is great it's only going to happen if we do it and we're always evaluating priorities right like I when I work on Drupal Core I'm thinking like okay what's going to help the community the most is it working on you know a theming system or is it working on config management or is it working on some other aspect so knowing what's important to people versus like yeah that's cool but it is also very helpful so I encourage both negative feedback and like yes we have to do this and here's why so thank you