 Welcome, everyone. Thanks for coming. There was a late switch of sessions in room, so I want to make sure you're in the right place. This is an intro level discussion on a designer-friendly theme system in Drupal 8 for the front end track. If you're here for the core conversation about actually a similar topic just going more in-depth on this, then that's not what this is today, but that is what's happening tomorrow at 3.45 in the Barcelona room. We wanted to get this one happening first so that people who are excited about what they hear here can then go into the more in-depth one tomorrow. We'll see you tomorrow. We will assume that you know all this stuff tomorrow, so. And this makes me look more nasty. Cool. And for those of you who are staying, thank you. I hope this is both interesting and I'm especially one of the things we're really hoping to get out of this is for anyone who hasn't been involved in the core issue queue or other kind of places that has been having discussions on twig to get up to speed about what twig is and why we think using it can solve some really great, some sort of important problems. And most importantly, we need your feedback. We need to know whether we're on the right track, whether this will actually make things better for designers and front-end developers, or whether we need to switch gears and do something completely different. So I'm going to try to spend maybe 20, 30 minutes on the intro and then turn this into a leave lots of time for Q&A and for you to give us feedback. So sometimes it's hard to remember. You go to a session, maybe it's fun, maybe not. But then it's like, what did you get out of it? So if you can only remember one thing from this session, just remember the word consistency. And that's it. If you're ambitious, and you think you might come away remembering two things from this talk, then consistency and simplicity. But first, I guess we'll introduce ourselves. So my name is Alex Bronstein. I work for Acquia. I am FLGentsia on Drupal.org. And I'm one of the theme system co-maintainers. My name is Jen Lampden. I am independent. And I really care about people's ability to learn Drupal and to work with a theme layer. And I'm John Omblin-Wilkins. I work for Palantir.net. And I'm also one of the theme system maintainers. And I'm curious actually for who's in the room. Who in the room considers themselves either a designer or a front-end developer? Looks like a little more than half or two-thirds. Great. And who was building themes in Drupal 6? OK, most of you. Wow. OK. And I guess of the people who have experience in Drupal 6, raise your hand if the switch from Drupal 6 to Drupal 7 was painful, if working with templates and theme functions in Drupal 7 was more painful than in Drupal 6. Wow. Almost no one. OK. All right. Let's check here. I need to make this. This is really low res. And how does that? Is that wide enough? Is that font size big enough for the back? Yep. OK. Let me see if I can go one smaller. And if that still works. Is that still readable? OK. OK, so it was interesting that a lot of you did not find the transition from Drupal 6 to Drupal 7 painful. So for those of you who did, or just to look at why some people might have found it painful, this is what things look like in Drupal 6. This is the node.tpl file, the node.tpl.php file from Drupal 6. And if you look at it, you basically see you don't have that much PHP code. You have a whole bunch of print statements, and mostly what you're printing are variables. So you can print $picture, for example. You can print $title. You can print $content. You can print $links. And even though those are fairly different kinds of objects, they're actually all strings by the time it gets into here. And so a lot of people found this fairly easy. The one thing that sometimes occurs here, however, is you'll notice you'll print something that is the property of an object. And so if you look up to the documentation and see what does that mean, what is the $node object, it says, OK, it's the full node object. Oh, contains data that might not be safe. That's kind of scary, I would think, if you're just starting to think the node.template is NID safe. What else could I be printing out here that's not safe? And if you get it wrong, you might actually introduce a security bug on your website. But at least we're only doing this in one place, and the rest of the variables actually are safe. OK, so in Drupal 7, what changed? So one of the things that changed is we actually introduced an attributes variable. And the attributes variable contains all of the attributes other than ID and class. And we did this primarily for RDFA, but other modules can use it for all sorts of other attributes. We've also introduced this idea of render. So now you don't just print a title, but you also render a title prefix and render a title suffix. And this is done for contextual links and modules like that. You no longer print dollar content, but you hide content comments and content links. And then you can render content. And then after you've done that, you can render the things that you hid. So some variables we have to render. Like content is something that we have to render, but title is something that we can print. And I think this at least has the potential to be confusing for quite a lot of people and makes it harder to bring new designers and new front end developers into Drupal. Or if we do bring them in, then they just spend a lot of time cursing this kind of inconsistency instead of just making their markup look like what they want it to look like. So why did we do this? Why did we create this mess? And the reason is because back in 2009, we were identifying all sorts of limitations of things we couldn't do in Drupal 6. So for example, this ability to one of the things you can do here is here we hid links and rendered the links separately, but you can actually go further. The links include links from other modules. So for example, you can have the comment module enabled, in which case after the node, you get a link, add new comment. If you have the blog module enabled, you get links for view this person's blog. If you have the forum module enabled, you get other links. And maybe you want to take some of those links and render them separately from other links. Couldn't do that in Drupal 6, at least not easily. Whereas in Drupal 7, it's actually very easy. You could actually say, instead of print render content links, you can say something like print render content links blog. And then in a separate line, print render content links, the rest of them. And suddenly your blog links can be in a separate UL from all your other links. And then you can float one to the left and float the other to the right. And that's not just for links, but that same is true for fields. So for example, if you have a whole bunch of fields in your node and you want to print a couple of them separately and then print the rest, same kind of concept. You just say print content, the field you want, and then the rest of the content. So the render system adds a lot of power, even though it does create this difficulty and consistency. So for Drupal 8, one of the major changes that actually went in about a week or two ago is if you look at the Drupal 7 template file, you'll notice that we have a variable called classes and a separate variable called attributes. And that makes sense, because it's very common in a template to want to add more classes. In addition to the classes that Drupal provides you, this particular template maybe wants to add clear fix. Maybe you have a bunch of other ones that you want to add. But then the question comes up, why is class special in that regard? What if I wanted to do the same thing for the data attribute or any number of other HTML attributes? So in Drupal 8, you now just get a single variable attributes. And if you want to treat the class specially, you can print it specially. And then if you do that, then when you print attributes, it prints all the rest. So if you wanted to do the same thing for data, you could do that. You could have another line that says data equals PHP print attributes data, add your own other stuff, and then print the rest of the attributes. Or if you didn't do anything special with class, then you wouldn't even need to need this line at all. You could just say print attributes, and your template file is shorter. And I'd like to point out that you don't have to do show and hide for this. It's just done sort of transparently in the background. Yes? And how does it shoot you in the code? Like if you just want to look into attributes with some abstraction function, and then it's a magic method thing, or whatever. It's only reset when it's printed. Well, yeah. It's reset when it's evaluated as a string. So one of the magic two string method is called. So. Yeah. First you prefer to write it then. Yeah. But still, should you put it in the trial? Potentially. Yes. Yes, there's no hide for this. There's things you can do given that it's PHP. You could sort of create a local variable and stuff. So this is a step in the direction. As these questions point out, it's not complete. Yeah, I have one. Well, that's what this is. And you actually can access this as an object. But one of the things is, I don't know if we want templates having all sorts of functionality around how to deal with objects. That's one of the things that we're thinking maybe at the template level, it would be easier to just be able to print variables. I'm going to show what this might look like in twig, because I think that actually adds some improvements on top of this sort of direction. Obviously, one thing you'll notice, we changed div to, oh, no, that was already done, never mind. So here, twig, instead of opening up PHP tags, basically the two major syntaxes in twig is when you want to print, you put something into a double curly brace. That means print. And when you have a control structure, like an if statement, it's a brace percent. So that actually is nice in that it makes the syntax kind of short. And it sort of means a larger percentage of what's in your template file is markup. And a smaller percentage is sort of code. And I think that has one small benefit. But the other benefit it has is all traversal, whether you're going down into an object or going down into an array, can be done with a dot separator. So you don't have to worry about, OK, is this an array that I have to use brackets for? Or is this an object that I have to use an arrow for? At the template level, you just want to drill down into a variable. So you use the dot. And you'll notice there's no more render function. You can just print a top level variable. This is our goal. This isn't all working yet. This is kind of what we're working towards with twig. But the idea is we would like to move in a direction where templates look more like this. So for example, here, you can print title. And if you didn't need to do anything fancy with content, you could just print content. Or like instead of having to render title prefix and render title suffix, you can just treat it the same way as the bottom most variable. Oh, thank you. Twig is a templating engine that is used by the symphony project. So it's a separate project, but symphony uses it. And one of the reasons we're looking at it is it has a lot of nice features. And one of the features that it has is it compiles to a PHP class. So I think it has a good syntax and it has some good functionality. But in addition to all of the good functionality that it has, anything, a twig file at the first time you run it will get compiled into a PHP class, which means using it is actually potentially really fast. And a lot of the issues around using templating engines that aren't PHP template is performance concerns. And there are definitely some things that need to be looked at performance-wise. But because it's compiled, it actually gives us the opportunity to tweak performance to the extent that we need to. Jen actually organized a summit in March where we got together and discussed the goal was to discuss the problems that we saw inherent in the D7 theme system. Twig was one potential solution. I wasn't really necessarily sold on it at the time. We were really just purpose was to evaluate the problems and try to solve the problems. And we discovered that Twig could solve all the problems that we were having with performance, with security, with complicated syntax of PHP being very noisy and verbose in its PHP template syntax. So that's how we arrived at it. And the fact that it was part of Symphony was another point in its favor. So that's how we ended up picking Twig as a solution for the problems that we're seeing. So what's the license of Twig? It's missing. OK. It's missing by itself. OK. We have taken, and it is missing by itself. You've then got to start stating that it is like real and it's like it's a real copywriter. So we're going to come from it, and it's going to be quantified. OK. On the PHP platform, I actually close the list from the freedom software foundation that we first really talked about, or the user relations we have taken in using the two-by-two systems together. So that's definitely something that, you know, whilst it's not crazy that there's something that we don't want to have to think about. So there may be some flexibility on that. If we went to the Twig project and said, hey, we want to include this interval, but there has been a lot of progress lately about getting licenses changed to get stuck in. Yeah. If we can get him to come to the core conversation tomorrow, that would be really good to bring it up then, too. Yeah. So that would be a great view afterwards to try to get some details of context. Yeah. Thanks for pointing that out, because that's obviously a huge thing that we need to. Yeah. OK. So this is looking at node.tpl.php. So one other thing I would point out then is, you know, as you know, we have templates and we have theme functions. And at one point, we had this, I think, back in Drupal 5 days. We thought, OK, you know, like, we can make, chances, you know, we can try to structure the system such that most themes can do what they need to do just by using templates. And, you know, functions are sort of more, you know, overriding theme functions is sort of more of an advanced feature that, you know, maybe themers can get to when they're ready for that, but, you know, that they don't, that potentially they could do a lot of interesting themes without that. I would submit that that assumption has proven to be false. I don't think I've seen any template. I've seen any theme that doesn't override a theme function. And there's actually some very, very common ones that we have as functions that are very commonly needed to be overridden. So as one example, I'll actually take a look at links. So theme links is a particularly nasty function. It's about, do you see about 80 lines of code. It does a lot of stuff in there. You know, first of all, the markup is totally buried. I mean, you know, like if the reason you want to override theme links is probably, you know, maybe because, you know, you want to change whether you're using a UL, LI, you know, markup or whether you want to output your links in some other way or, you know, you want to get your classes added in. You know, that markup is buried within this function. It's hard to find, even if you do sort of copy and override it. Additionally, there's, you know, you're doing things like checking whether variables are string. You're in some places you have to call Drupal attributes yourself. In some places you have to call CheckPlane yourself, even for like a basic variable, you know, not like, you know, digging into like a node object, but just to get like the text of the heading, you have to call CheckPlane because we don't usually sanitize before calling functions. So, you know, there's a lot of room here to make mistakes. And then there's, you know, logic in here as well. Like we have to determine whether we're, you know, whether our link is active because we want to add the active class to the LI. So we have all this logic to see, you know, whether it's a current path or are we on the front page and, you know, like we check language. So, you know, this is like PHP code. This isn't really like easy to work with as, you know, from a front-end standpoint. And unfortunately we actually, if we were to make links into a template, it would, we would have a noticeable performance regression because we output links a lot on the page. And the nature of PHP template is, you know, if you output a PHP template on the page, you know, a few times, that's fine. But if you start doing it, you know, hundreds of time in a single page request, each one is, has a noticeable performance overhead. And so one of the benefits of Twig is because it gets compiled and then it's a, and then once you use it once in the page request, it's a class that's in memory. You can then call functions on it without this, you know, with much less performance overhead. So we think it's not yet proven, but it's an assumption. We think we'll be able to convert many, maybe even all or very nearly all of our theme functions to Twig templates. And so we won't have that function template dichotomy and we could have, you know, a links template that looks something like this. This is the first time I saw this slide, so. Yes. So does this contain all the logic to those people of the logic somewhere else? So the logic would move into the equivalent of what we do in preprocess as we, you know, when we have something as a temp, we can preprocess something, but we, whether we do or not is not, you know, like sometimes we do, sometimes we don't, but with templates we always preprocess. One of the things we've been looking at with Twig is to change the way we preprocess. You know, right now we sort of, because all of our preprocessing steps are, you know, we're not working with objects. We're kind of like imagining what all the variables that someone might want are. And so we preprocess and kind of prepare all the variables that someone might want to print out. And that's a lot of execution time. And then, you know, the template may or may not print that variable. One of the things we're looking into doing with Twig is make it a little bit more like the token system, you know, where you can just sort of register per template, you can just sort of register the variables that ought to, the top level variables that ought to be available in a template. And then when it's used, then it figures, you know, it then effectively does the things we currently do in preprocess, but only at the point that we know that the template needs to be there. But yes, there is logic that would be happening, you know, at the point that any of these variables are being used. And so that's, you know, that's part of the point, right, is to sort of separate, like, the determination, like, for example, you know, like this idea of link.active, right, we want to separate the concern of, of, of, in the template knowing whether the link is active or not, versus the actual logic of how we determine that. So the big picture is that we want to take all of the logic that theme developers actually care about and make sure that that's available to you in the template file. And we want to take all of the other logic that Drupal actually cares about and remove it. So if you need to know the active state, we're going to give you a link that active, and you can access that and figure out if it's active. But you might not necessarily need to know everything else. Drupal needs to know, like, calling the attributes function yourself for sanitizing stuff. We're going to make that happen automatically. So how does it look in the template that these loading classes amount of files or does performance issue or the whole service should be... Well, it's loading a lot of, it would be, especially on a server without APC, it's, it's loading files that are necessary for that request. I mean, even though there's maybe 200, there's, you know, about, we currently have about 30 templates in Drupal Core and roughly to 180 or so theme functions. So if we imagine where we have 200 templates, they don't all get used on every page request. So, you know, we'd have to look into it, but I think the number that would get used on each page request might be smaller. And we're actually expecting that there might be a performance improvement, because if you have a page that has 30 comments on it, you only have to load that once in twigland, whereas in PHP template land, you would have to load it 30 times. So this is the kind of thing where if we can improve our template files, that we have fewer template files that are recycled, we can get a performance gain instead of getting a performance gain. So once, you know, so basically twig templates get compiled to PHP classes. So, you know, once you, within a request, when you first load the class, then that class is in memory. So that's, I mean, that's just sort of the way PHP, you know, there's actually no way to free it from memory, PHP just, you know, has all of its classes in memory. But if you're using APC, you know, then it's cached just like any other, you know, PHP file gets cached in memory. And the compilation step is going to happen, kind of like in the theme registry build sort of thing where we're like, we're going to compile all the twig templates now, and then it's just done until the next time you decide to do that, which is going to be much later. And we're also going to be comparing this to the giant page array that we have now in Drupal 7, which takes a lot of memory anyway. So. That's a great question. And I don't know. I think maybe. So one of the problems with the render elements is that they, I discovered this back in San Francisco, Drupal on San Francisco three years ago in that, was that three years ago? Yeah. Was that because of the rules that are available inside the render API for creating these elements? It meant that it was basically a sort of wild west of how you actually go about creating a render element. And that meant that it was completely undocumented because it was completely inconsistent, each render element. So there was literally no way for, like, I love writing documentation. And there was no way for me to write documentation on all of the different parts of a render element. And now, with the Twix syntax like this, we're going to be registering sort of variables. So it would be very easy to go in and, like, these are the list of variables for this template. And not only, like, CORE does it right now by, like, hard coding a giant doc block at the top of the template file. We'll be able to, like, actually look at all the contrib modules that have registered variables for this template. And, you know, it'd be like let me show you, these are the variables that are available. And when you register, there should be, I think there should be, when you register a variable, you should be able to, like, register, like, some, a link to documentation or something like that, you know. So a lot of this we don't know yet. But, yeah, it's definitely possible for us to do that. But the discovery is a huge part of what I want to have in it. So I would think that when you register a variable, you would also register some documentation or a link to some documentation or something like that. A resource for documentation. And it's always available. Yes. So, yeah, I just want to kind of quickly sum up and then actually keep, you know, keep this great Q&A discussion kind of going for as long as we have time. But just to sort of, you know, kind of bring us back to the high level of the problems we're trying to solve is essentially these kinds of inconsistencies that we think are causing Themer's difficulty. The not knowing when to use an arrow versus, you know, dereference as an object or an array, you know, arrow shortcuts. Not knowing whether to print a variable or print render it. Having to work with very different rules and syntaxes when you're in a template versus a function. Especially when you're in a function, having to know which variables are safe and which you need to check plain. The one we actually solved, you know, the one that went into head just a week ago, a week or so ago, which is the, but prior to that, ID and class being sort of special and other attributes having different rules. But one that now we have introduced with the attributes patch, which is now that attributes drill down and render drill down sort of have slightly different rules and, you know, these are the kinds of inconsistencies that we think are annoying. And so the dream, if we managed to get, you know, all the kinks worked out with twig and all the assumptions that we have pan out is that we'll be able to always drill down with dot, that whether you print a top level variable or you drill down into a variable, it works. It, you know, if it's a render array, it renders it or whatever else, you know, versus if it's a string, that works too. And that it's safe. That you don't need to checkpoint it. You know, that the next line, this idea of suppression, you know, this is something that we have with render, this idea that when we, you know, when we render a child variable that the, that then when we later render the parent variable, it, the child variable got suppressed from it. I'm not sure what other systems, if any do something like that, but I actually think that's a really cool, you know, if it is a Drupalism, I think it's a very cool Drupalism. And so that is one thing that I think it's an awesome thing that we can keep and maybe even export to other projects if they think it's a cool approach. I think it's worked well in Drupal 7. And we're hoping that to remove theme functions and make all markup live in templates. So, we want to remove theme functions. We also want to remove preprocess functions. We want to remove process functions. And we want to remove render. We want to remove pre-render. So, the idea is that as tools, gamers have a more limited set that's equally powerful. So, we don't need to wonder where to go to do something. It's just, you can do it right there. So, a lot of this we don't know yet, but we were talking about it yesterday and we came up with this idea where if everything in Drupal becomes template first. So, anytime you follow theme function, what happens is Drupal looks up the template file and then tries to insert variables into that template file. That template file is defined in the hook theme of whatever provided it. And what's defined is here's your template file and here's the variables. So, theme developers have access to a hook template registry alter. And so, they can insert new variables at the very root level where here's the template here, the variables available. You can change that. So, if you can change the variables available at the highest level, then you don't need a pre-process because we aren't processing anything before the templates get rendered. We're just running the templates right away. So, you can basically change what's in the registry as the variables are available. And from a module developer standpoint, I think there's going to be like when you register a variable for a template, you get to like when you're asked, okay, give me this variable now. You're given like the twig object. So, it's got all the data that you need to sort of go into it as an object level and then create a variable based on the data and the twig object. Is there additional... I want to get all the edge cases and make sure that we're not missing any. So... I was like, in Drupal 7, we gave the themes access to all the alter hooks. So, those still happen after everything else. So, if you're doing a registry alter in your theme, you should be able to change everything that's already there. Yeah. I think we do need to think about that particular use case because actually Emma Jane brought that up the exact same question right before this and I hadn't thought about that one. So, we should try it. Yeah. The one problem I was that is I tried to keep things modular and make modules with a secure feature. Okay, so they have a feature module somewhere here and I make one module for group something and another module for newsletter or something and the teamers that would just go and put everything in the theme and make a template for everything and so all your modules are kind of modular and you can switch one off but the theme depends on everything and everything is somewhere in the theme module. So, then you have this big theme with a lot of unrelated templates and you have some old templates that you don't know what to remove them because you don't see the old version of the newsletter thing or the newer version of the newsletter thing that's been implemented and so yeah the team and the CSS is reversed because now one week some of that is about the newsletter or something like that maybe there's even the guy who's working on what's that for you and really don't know what to do so all the modules are small enough that you know what to try and switch off but the theme is getting bigger and bigger and that within TWIC I could talk to you for about five minutes about this subject I'm not sure if everybody else here wants to know the answer to that so maybe we could talk about it afterwards I mean there are a couple different things you can do there's a new D8 initiative that not a new D8 there's a D8 initiative that is talking about doing layouts building layouts within core which removes a lot of the hard parts of theming anyway so that makes theming a bit simpler and it doesn't have to worry about creating all the CSS for layouts and stuff like that so then there's a possibility of making themes more modular just based on the fact that they're getting the layouts from here and then if you talk about SMACs Scalable Modular Architecture for CSS that SMAC SMA CSS.com it's a website by Jonathan Snook it's a great resource for trying to make your CSS modular exactly like you want so that's an actual development technique that you just go whack your themers and make sure that they're following that so I usually use this much in the theme and I don't have any themers but I don't already build them so SMAC is a relatively so in its game popularity and I'm trying to promote it as well so I would run it by them because it's a really good concept so the twig this twig dot syntax would help me because I'm always accidentally like I'm going through the develop process the same way you are and like I'm creating it and I always miss the one thing in the long chain that is an object and then I suddenly have like a fatal PHP error right I do that all the time and I help make the d7 theme system so I love the dot syntax because it's completely gets rid of that problem for me that's kind of this item from this thing and be able to print it out because I think there's a lot of theme things that get into it that fast and I want that thing and just want it and I want to think about how to make it secure and I just want to print it out right so that's I think the biggest win too is that we haven't heard the theme developer community a lot about security if we can make it completely invisible to the theme are so all you guys really need to worry about is the markup because that's what you're good at and we shouldn't bother you with calling the obscure functions that we made up just let you use the dot syntax and have twig take care of the security and then you can do what you're good at and we'll get along so you're always going to get contributed module developers giving you HTML that's not very good that's something it's really hard to avoid and one of the things that we do want to do is clean up the templates that come from core so that they're more reusable and in core we want to make the core modules use the good example templates so you'll have a wrapper template rather than having eight things that are wrappers and if we can create a pattern like that that works well in core there's a chance that contribute developers might use them one of the things that we have like 180 different theme hooks in d7 right now but they're very, very, very specific use cases and we would like to have to generalize a lot of those so that they are reusable because right now there's a lot of theme hooks that are not reusable and if we had a bunch of reusable theme hooks then contrib doesn't even have to write its own templates it could just say oh I need that one and that one there's ones that are provided so there's a potential that they they just have to learn how to combine them the right way rather than come up with something that they don't know what the hell they're doing and if you don't like those you can still override them in exactly the way that we're doing now so you'll be able to override them with whatever naming convention maybe I don't know that's gonna change or not but you will be able to change it yeah theme hook suggestions let's see Richard okay anything in twig you're planning on not using for instance will we be able to include just random HTML files stuff like that so we don't know yet there's a couple of things that we think twig does really well and we haven't figured out how to make that work with Drupal we haven't really inherited stuff with its own thing called blocks we already have something in Drupal called blocks that might be kind of confusing we haven't figured out how to make it work right include files seem to be reasonable we tried playing with those a little bit in one of the first prints and it looked fine so we haven't ruled anything out yet but we also don't really know what we're doing yet so maybe it may or may not be using all of the bits that twig provides in core one more thing we were talking about during the whistlewig buff earlier today regarding text formats we'd be able to we'd be able to throw like twig into the mix there to use twig syntax to call things while you're editing a node so I one of the things that that I heard I think it was in the same buff or maybe it was later in the day today replacement for token idea right and somebody said that they thought that you could use something like what contemplate module does but in a sane way because of the changes that are having to architecturally to Drupal 8 which I I've been thinking so poorly of contemplate module for so long it's hard for me to grasp that that might actually be really useful and secure and not like oh my god a horrible performance but there's a possibility that yes you could use twig template with inside you're like your node body I haven't thought about and I probably won't explore that option at all but I guess the answer is yeah probably and you can make it happen too if you want it so there's two different things like one of them is there's this really horrible module that no one here should ever use called contemplate that let you edit PHP templates in your browser PHP is like dangerous and that's not a good idea but if we were using twig that would be not dangerous and actually a really good idea so we have the ability to let people edit their template files directly from their browser which I think could be huge in terms of getting people into creating stuff in Drupal more easily but there's also something else a thing called twig.js that lets you replace things in the DOM using twig templates that are the same as the twig templates you're using in HTML I'm not really sure exactly how it works but I think it's awesome and that would be great I don't know how that would work with WYSIWYG but it seems like there's definitely a potential there for stuff happening yes because they were saying that as a part of the spark project they would want to do that or maybe it already does that they do implement I mean you're able to insert inline tokens like a huge list yeah I mean I think the token thing and the twig thing there's a lot of similarities but they also probably need to remain different things like we're not going to replace one with the other but there's definitely ways they can work together like our drill down syntax was like based on what we liked about how you can drill down something that's similar but I don't know yet so last comment there so would you be able to call things like like the curly brackets and then views.machine name to have a view instead of a node or in a template file you could use an alter hook to provide a variable that would render a view and then stick that in a template file I don't see why not I don't think we're going to do it I think you're asking whether you can do that within WYSIWYG though right is that was that a question or within I kind of changed my mind even more important in a template file like a twig file I think it's possible in a twig file we don't know maybe sounds cool one just before we move on with more questions I also want to just point out that this is the way this the way I think we started thinking about twig was sort of identifying the things that were problematic with Drupal 7 theming and trying to just sort of solve that kind of syntax at once we realize that twig would be cool then all of these interesting possibilities started opening up but at the same time we're like three months from feature freeze and we're still pretty you know there's a lot left to actually do to make this real so one of the things we're hoping for especially online on GDO and in the issue queue and any other you know forums because to know like again is this a good duration by the way DrupalCon is one of the forums so if you want to just come up to me and talk to me that works too yes absolutely you know because one of the things that happened was we thought render arrays were a great idea when we were developing Drupal 7 well John didn't I didn't know anything about it until after it happened and then a lot of people started complaining about render arrays so we'd rather get more feedback broader feedback about things like this earlier so that's one way you can help and then other ways you can help if you want to come to the core conversation the sprint this is on the slide participate in the issue queues and it's not just if you want to help code that's awesome but if you want to just help give the kind of feedback you've already been giving for the last half hour that's or if you have like advanced features and twig that you're excited about like bring them up and if find ways to make them happen or if you have problems with Drupal 7 that we haven't heard of yet right then I'm not sure this is a question if you guys are for the blocks and layouts initiative but how will that impact on the theme system as someone who fears and loads the panels module I am concerned that I will be dealing with bad and unchangeable markup bad and unchangeable CSS so how is that for starters you should not fear the panels module you should love and not load it I'll be working I load and fear the markup generate that we can work on so just how does all play together with the new theme system so for starters the things that we're thinking working on theming right now don't include pages and layouts by these new panels like plug-in things that we don't know yet really but what we're very quickly if it helps Chris is just outside the room yeah go get him I've been talking to him enough so I know the answer to the question okay so what we're talking about are things that are blocks and things that are smaller than blocks so we're talking about all of the theme functions like theme link and theme image and getting those into twig so the plan is that will allow you to create layouts the spark has been demoing some actual code that does it and they were quite clear in that yes we got this demo it works the what did they say the UI is slick and the CSS the HTML is crap but and I told them right in front I said I love the UI I want to use this I think this is awesome but you will not get by the backup and the CSS is really clean and and they're they have an API for like once you laid out the stuff then go generate the CSS and generate the HTML for that and I said I will help you make sure that that's clean so yeah I wanted to be clean too because it's not really that hard as long as you have somebody who knows what they're doing and cares about it's clean right and you'll be able to override everything yeah that probably boils down to in terms of overriding we'll still be able to override the using twig templates yeah yeah it's all going to be twig if we do this and twig there won't be any PHP template anywhere it'll all be twig so there's there's this configuration management initiative too which does it's right now it's the the very sketchy plan that we laid out last night where we were drinking beers is that there will be a YAML it will be a YAML file and a and like a twig file potentially if our part the other twig part gets done a twig file that is the layout of the actual sort of markup so you'll sort of export not yeah it'll be creating that for you and you can override it twig template right in the normal ways right and you could also potentially just like screw the layout generator I'm going to disable it and provide my own have you written your own panels layouts yet yes so you know how there's like a config file that you're like this is all the crap that's available and then you can actually write your own h2ml and CSS and those things are separate so it's going to be the same thing only it'll be YAML instead of weird panels and profiles and it'll be way more confusing and way less helpful maybe I just drank too much when we were talking about it last night and maybe this is not the best time for this question but I was just curious specifically about the compilation of the twig class it sounds like what we're saying is so okay we explicitly say there's some variable that's going to be made available but we're not really doing pre-processing it's like lazy processing or something like that when it's actually so it's an on-demand type situation similar to whatever two string things we do right now in d7 and that's just going to be what happens for all variables yes with the caveat that you know before you call the template you're getting sort of the base data that you need right so like you're still calling node load and providing that and then and then all the other variables right become generated from the data that you passed it's not really a variable talk for a little while longer to understand between base data and all the other variables well like it's very mushy right now because like node load becomes the node variable right so that's what I'm talking about base it also depends on the base data is the node variable right now whether it continues to be I'm not sure okay okay so like if you're on a link file your base data like the link stuff but if you wanted to insert like more attributes or whatever link data but it'll be really different if it's a node or a user sure and like an example of the kind of thing where to draw that line is maybe blurry and maybe we'll draw it on the very far end of the spectrum and say that we don't even load the node and just make a node variable available but not actually loaded until it's output in the template or maybe you know maybe we'll draw the line less aggressively than that but for example the other end of the spectrum the kind of thing we definitely don't want to have all of the comments are loaded you know in like template preprocessed node or actually even before that as part of node view all of the comments are attached to the render array even if node.tpl.php doesn't print it right so if you have a node template where you're like I'm not going to print the comments but all those comments got loaded and that's the thing I'm keying on and I'm just I'm really curious about how I'm just I have like an engineer's variables and lazy attach all the information so I'm curious about how that looks and I'm sure I'll have a look at it at some point too but cool thanks so I guess we keep this magic name you think that that something looks for template of that name and if this exists then it's overridden right now we're planning on keeping the same template override structure so one problem I always have is like if I want to so if I when you're at the top it's horizontal and another one it's on the side and they should have a different markup and some stupid threats is that you make this a theme menu link and then you make an if statement if it's this menu or that menu and somewhere it's even difficult to find out which menu that would be and I don't do it like that I just find this out but so but still but it's for people recommend that you override theme menu link and at this point you cannot know which menu that actually is so it would be smarter that there's another logic to switch between different templates at the moment that you start running the menu and it would be for the entire menu and not just for one specific item and also this but now I have this theme on and so this theme function theme hook should always be rendered like this this seems to be too limited but sometimes you want that in this case you should use this template another case you should use this other template because not every menu is the same and the same could be for other things and there's a thing called theme hook suggestions have you used that in D7 yes yes but also so there are I I think that might be a limitation of Drupal 7's menu system that it doesn't provide enough useful theme hook suggestions out of the blocks because if you look at the menu block module which is a good trip module it actually provides a lot more just with you so like it actually does provide a theme hook suggestion for when you're doing a menu link it's like the menu link dash dash and then the menu name so you can actually do it per menu really easily because it's already available theme hook suggestion for you you could do that in core too but you have to do the pre-processing and add in into the theme hook suggestions variable array you have to add those in manually then the way that I would say you should tackle that problem and then that will continue to be available in DA I think I thought about that and someone didn't like would rather have something that switches at the point where you start running the menu then just go a completely different path and not each time look at which template it should call it but you're not it's just a naming convention of the TPL that you're doing at that time so like you're creating a separate template file that has a naming named a specific way that has the separate rendering so you're not they're completely separate and you're not thinking about both at the same time anymore you're not doing if statements it's just like the system is doing is determining oh I'm in this menu and you want me to do it this way every single time so it just does it that way every single time because it's a specific menu so what's the time five moments five moments okay great so I hate the render API as much as everyone but I thought the theory was the idea behind it was good and that all these contributed things produce markup and we want to instead of just overriding it with separate template files we can have data and we can use that data we being the themeers the themeers can take that data and make a very custom markup but it's terrible because there's no data model there's absolutely no data model so instead we just have this monster array that gets built up and the memory footprint is ridiculous and trying to get to what you want even I've been working with it for two years and I still have no idea what I'm doing I completely agree with you so is gable in here good okay so there's a there's a PHP constant called like language undefined or something like that I have no idea what that does whenever I encountered it I just used it every single time I think there's a multilingual way that I'm supposed to be doing it I don't know what it is so go ahead so I understand this idea of twig and the simplified markup and putting some of the logic into the template files but I don't really see how it solves the problem keeps what we had with the render API but cleans it up and provides some real structure so this lazy loading thing is exactly what we need but I don't see how we get from the template file to lazy loading for example like a particular comment or you know we have a lot of wrappers so we have like the wrapper template and then inside it'll call individual items and these silos kill me and the only thing that sometimes I have to get to break down these silos is the render API it's the only time I'll touch it but I touch it a lot so the idea is that you'll get a template file and you'll get some variable like content and if you want to print out like a field you could do like content.imagefield and if you want like the first value you could go content.imagefield1 and if you want just the source tag you could go content.imagefield1 source and hopefully it'll everything will be like there will be a top level item that you can access like content and maybe there will be some kind of like viewer where you can say like show me what's in content and it'll be it'll show you like these are those and then when you go to print it it'll print the markup version of it so rather than seeing the data which you got from your viewer you can get like it's an actual image tag or it's just the value of the source attribute of the image tag and the idea is that every module that needs to add it's stuff in there will still add it in whatever way it wants but it'll need to define it to the template system in a way that makes sense to you so it's not arbitrary where they shove it in so if I have a module and I define a block and it returns something what does it return or right now you would return an array or right so that's another thing like right now you can either return a renderable or a string of markup we're hoping to get rid of that renderable thing in core and in right and it'll always be a string of markup right so actually a lot of what you asked about is in the blocks and layouts initiative because the thing that it returns is totally they're going to redo that because the way that is done now is just totally janky there's a title and a subject and maybe that's a renderer but that will become much more consistent because we're going to redo that API for returning the block right and another part actually this silo problem that you're talking about we're like oh I actually want to put this field like way the hell over there and separate from the rest of the node so it's actually outside the template file that you normally are doing that problem also becomes much easier to solve with the blocks and layouts initiative because you can suddenly you can basically just say I want a block over here that has the field from this node right and so it's not necessarily a problem that we have to solve in twig because it's a problem that's solved at the block layout space right so the the crazy things that we're able to do with render API we don't have to because it becomes a UI issue of this this silo problem goes away yeah I know exactly what you're talking about remarked John you're referring to the multilingual thing that you should be using and you're not using it I think that's field get item what you mean sorry what field get item that should be not no no this is something in the like seven layer deep array stack where you have to stick in language to get to the field value because field values are segmented based on the language that they were stored with and if no explicit language setting was made it does mean that that code would not be portable to multilingual right because I'm writing all this code that I know is not portable to multilingual but I don't know what the right code is doing is that where you're supposed to grab a language status you're on to get the right value out of the field I do think I remember that works so there's a different just on a Jen is saying there's a different value inside the render array that I need to grab and then stick so there's like a seven there's like a seven stack deep piece of array and then you put like three stacks deep inside of it you got it I think a lot of that has already been improved in Drupal 8 as part of the multilingual initiative and I know that Gabbler would like to improve the rest and would like help doing so are there any final questions? I firmly lay the blame in render API and not in multilingual just for the record okay so we still need your feedback on everything so come to all the stuff that we talked about come to the session tomorrow if you want to figure out how we're actually going to do this because like there were a lot of questions we said I don't know we're going to figure out tomorrow so come help us with that too thank you by the way those peaches were really good I'm glad you grabbed me for a key to here no they're fussy oh well they're really not but I will by tomorrow