 Carol, who I'll be quoting later in the session, is giving a presentation today at five on recruiting strategies. Larry Garfield, who I'll be quoting a couple times as well, is giving a few presentations over the course of the convention. So first, a caveat. The future is here. It's already here. It's just not evenly distributed. So I'll be talking about a lot of ideas, a lot of mental models used in Drupal theming. I'll be calling some past, some present, some future. The caveat that I want to give is that the ideas themselves are not necessarily old or new ideas. But given circumstances surrounding previous versions of Drupal, surrounding the current version of Drupal, Drupal 7, surrounding Drupal 8, those circumstances make certain mental models easier to use, more advantageous. So I'll be speaking from a perspective informed by my work at Palantir, as well as in the Drupal community. So in Drupal and in web development in general, trying to advance a slide here so far is not working. There we go. What are we doing? Good question. What are we doing? Web programming is the science of increasingly complicated ways of concatenating strings. And by this measure, Drupal developers are really, really good scientists. We have some incredibly complex ways of concatenating strings. So let's talk about our main concatenator in the Drupal world, the theme function. It's been in Drupal for a really long time. And let's look at one of the oldest examples of a theme function, theme item list. It's been in Drupal all the way since 2002. I was glad to hear Drupal history this morning in the Dries keynote, hearing about those ideas that were present in very early versions of Drupal that we still have now. And theme item list is one of those very early concepts. Basically, we have a PHP array. I can make a list of items to get from the grocery store. I can get fruit, bread, cheese, meat. I can make a PHP array. I can then pass it on to the theme function and I get an HTML unordered list of what I'm going to get from the grocery store. So the basic idea with theme item list and the theme system in general, it's been the same for over a decade now. You tell the theme system, I would like an item list, please. You give it the variables that you want to be used in that item list. The theme system will then call the function theme item list. Or if you want, you can override that function with my site theme item list. And that function is going to take those variables passed in, that PHP array, and wrap them in some HTML markup, and you get an unordered list. So a pretty simple idea. Again, we've had it for years and years. But it can get really complicated really quickly. Let's take the case of theming a note, something a lot of us do every single day. On the surface, it might look simple. You can load a node with the node load function. Get the ID, get your node. And then you tell the theme system, I would like to theme a node, please. And what you'll get back is a string of your printed node. But it looks like this. It is a whole lot of dibs, a whole lot of CSS classes. And we get exposed in CSS classes each internal Drupal understanding layer. We get a class for the name of the field. We get a class for the Drupal type of field. All of these internal layers of Drupal are exposed in markup. So the basic idea with theming a node is, again, you say, I would like to theme a node, please. Here's my node object. The preprocess system will then make that node actually printable, because what you're passing in is a raw node object. It is not at all ready for printing yet. If in this markup we saw the username of the author of the node, well, the node object doesn't have that. What the node object has is UID123. So to get that markup ready to be printed, the preprocess system has to do a ton of work before you actually get to node.tpl.php, where the rendering finally happens. And again, if you want, you can override with node hyphen hyphen blog post if your node is a blog post, or node hyphen hyphen blog post hyphen hyphen teaser if it's a blog post teaser. Again, we're using those Drupal internal understandings to inform our theme system. The name of your template is the name of the content type, plus perhaps the name of the view mode. So in the Drupal 6, Drupal 7, and all the way back to Drupal 5 era, internally at Palantir we called this era sustainable theming. And I'll let Colleen Carroll, one of our front-end developers at the time now, our director of operations, describe the goals of sustainable theming. So we wanted an extensible design that could continue to evolve without a developer there all the time. We wanted a designer theme that can stay intact as the site grows and grows. So these are really good goals. There were goals back in 2008, 2009, and there are goals now. We still want these things. We still want to be able to evolve our designs. We want them to be stable. But the way we went about achieving those goals was different in the Drupal 5 and Drupal 6 era because of some different conditions that were present then that have changed now. So in the past it was a given that your designs would be in a JPEG or a PSD or a PDF. Something that is not a website, something that's not HTML or CSS. So you start with a JPEG or a PSD and anything you do in Drupal is going to give you a ton of HTML for free. Whether you want it or not, you're going to get a ton of HTML. And when I was first building Drupal websites in 2007, 2008, I thought this was great because I didn't particularly like writing markup from scratch. I liked that Drupal just gave me all this for free and more CSS classes than I could ever ask for. It was a given in the Drupal 5 era that there were no pre-processes on theme functions. So CSS classes were a lot harder to change. So you get all this markup for free. You get all these CSS classes. But if you want to change them, it's going to be hard, so don't. In the Drupal 5 era, we didn't have the easy addition of multiple view modes that we have now on nodes. That's a core site-building tool in Drupal 7, adding multiple view modes to display a node in different formats. In the Drupal 5 era, you had full, you had teaser, so it became common to just use other CSS hints on a given page, maybe a CSS class on your body tag, maybe a CSS class on your view to do what we now do in view modes. So Colleen summed it up in 2009, saying Drupal is not a build-a-template-first system. It's an install-a-module and theme-it system. You construct your website and then you theme it. You don't start with your ideal markup. George DeMett, one of the owners of Palantir, in 2008 said, do as much as possible in CSS. Don't touch your TPLs, don't touch template.php. The advantage here is it's more portable, more upgradeable, and ultimately more maintainable. These, again, are all the goals that we want. We want our designs to be maintainable. We want to be able to upgrade. We want to move them around. Again, the way we went about achieving that was very different in 2008 and 2009. Colleen, again, don't fiddle with the HTML at all. It's not worth it. Everything can be done with CSS and should be. This was the attitude that we had in 2009. So what does this CSS look like? What kind of CSS do you write if this is your attitude? You get CSS written around field-field headline. And from a certain perspective, this is a great selector. This tells me so much about how this site is built. This tells me that this element is coming from the field module. And the name of this field is field underscore headline. That's really useful and descriptive if you know how Drupal generates these classes. If you know how the views module generates its classes, then the class views-field-field-headline-value is a really great selector because it tells you that this class comes from the views module. The views module is calling the field module. It's calling the field-field-headline specifically the database column value. This is a really, really descriptive CSS class. So in a world where CSS is your API to the browser, the more CSS selectors you have to choose from, the better. And Drupal has more than you could ever ask for. The more divs, the better. Because you don't know necessarily which divs you wanna use. Throw more in there, give you more options. The longer the class names, the better. Long multi-element selectors get very tempting. I use CSS classes on the body tag all the time in 2008, 2009 because they gave me hints as to what was going on. So Drupal Core exposes internal data model layers as wrapping HTML elements. So in this era, oh, I've skipped ahead. In this era, what are we doing? We're making Drupal elements look like our designs. Remember in this era, our designs are in PSDs, they're in JPEGs. Our best hope, our best hope is to look like those PSDs and JPEGs because they're not going to be pixel perfect. We want to make them look as close as possible because they can't be the designs. The designs are in Photoshop. This reminds me of Stephen Colbert. He had a Latin phrase above his fireplace and it translated into to seem to be rather than to be. This is an inversion of the North Carolina state motto which emphasized being something rather than seeming to be or appearing to be. But in the Drupal eight, sorry, the Drupal six, Drupal five era, your best hope is to seem like the design because you don't even have the option to be the design. Now, as we move forward in time, that starts to change a little bit. We're going to talk now about the past-ish present where we started chasing easy and losing the simplicity of our philosophy. So just as sustainable theming as a philosophy was coming into the world in 2008, 2009, another palantir Larry Garfield wrote a blog post called Sustainable Building Blocks where he talked about another strategy to control your markup in Drupal. He talked about writing field formatters and views display plugins rather than overriding those template files. If you do that, if you write field formatters and views display plugins, your work is going to be more encapsulated, portable, flexible. Again, all great goals, all what we still want. We still want these things. So Larry suggested, write more plugins. Don't override those templates, build a views style plugin or a display handler or an argument handler. By show of hands, who wrote a views plugin of some kind for slideshows? Great, so many people, I did too. Larry wrote one called View Cycle Module. And here we have markup classes that tell us this is going to be a jQuery cycle. The classes we see here are views cycle. This isn't a class named after a site-specific field. It's not a class named after the name of the view you configured yourself. This tells you I'm a cycle. That's what I am. Now, there's a trade-off here, as Larry said in that same blog post. It's another API to learn. But if you learn that API, you can make something cleaner, more extensible, and you can reuse it again on your next projects because in 2008, 2009, everybody wants jQuery cycle. So, brings me again to the question, what are we doing? Are we writing CSS to make a view look like a slideshow? Or are we writing a display plugin to make a view be a slideshow? And in Drupal 7, the theme systems complexity clouds this question. It can be easy to work with Drupal 7 and not realize that this question is even there. You just have the task, we need a slideshow. If you, as a developer, know how to write a views plugin, that might be your go-to. But if you're someone who's not comfortable writing an object-oriented plugin, but you're really comfortable with CSS, then you're gonna write CSS and maybe a little bit of JavaScript, and it'll work. But you may not necessarily realize that there's this dichotomy here. And we have so many tools in core, it's hard to even realize what lines up with what. We've got pre-processed functions, we've got process functions, we've got theme hook suggestions, and theme functions that you can override. You can write field formatters. You can modify markup with hook, field, extra fields. You can write new theme functions if you want. You could use render arrays and alter them. You can even just shove things into hook node load. And then in Contrib, which just about every project is going to have some combination of these tools, you might have some of the panels sweet, you might have display sweet, you might have custom views display plugins, as well as some coming from Contrib modules. You can suppress unwanted divs with fences if you don't like all those divs and divs and divs. You can add view modes. You can do all kinds of things, but this is what theming in Drupal feels like to me sometimes. You're dropping your content in at one end. It goes through a maze of pre-process, process functions, suggestions, overrides, and at the end you hope you land where you want, but maybe you don't. It can feel like mousetrap, setting up the perfect ordering of overrides and custom formatters to get what you want. So again, what are we doing? In this era, we're doing whatever feels easier, not necessarily simpler. Is it simpler to write a field formatter or is it simpler to override the styling in CSS of the formatter you already have or to just alter it a little bit in pre-process? Different people will answer easier in different ways, but we can get better at answering simpler more consistently as a community. Now, we thought about this in 2008, 2009. Colleen knew it's not just about whatever feels easier. She knew in 2009 that sustainable theming would be difficult. It takes patience. It takes knowing the inner structure of Drupal to theme based entirely on those internal understanding classes, to theme based on field-headline. You need to know where that's coming from. So the sustainable theming mentality relies on the themeer knowing how the theme system works, but how many people in the world know how this diagram works? John does, John made the diagram. John knows how it works, but not everybody. So in chasing easy, we lost simple. Now that brings us to the future-ish present, the era at Palantir where we're making the markup match and again our givens have changed. So it's become a given in the past few years that all of our clients want a responsive site. So if everybody wants a responsive site, that tells us well then our designers need to do at least a little bit in CSS. You can no longer say that you've designed a website if all you've done is made a picture of a website in Photoshop. Designing a website at this point now requires doing at least some work in CSS to give an indication of how is this site going to respond at different breakpoints. This website for the University of Michigan's Health System was one of our first responsive projects and our designers knew right away that to say that they had designed this site they would need to get their hands dirty in CSS and figure out how are these menus, how are these headlines, how are these images embedded in body fields, how are they going to respond as we move from a desktop size to a tablet size to a mobile size. So if it's then a given that our designers are doing at least some work in HTML and CSS, do we even want Drupal's HTML and CSS? This is a question we've wrestled with for a couple years now at Palantir. If we're getting some level of CSS and HTML from our designers and with each project that CSS and HTML gets better and better and better, what do we need Drupal's for? Those first couple of projects we did responsibly, we would have designers write some HTML and CSS and then we'd say great, thanks, we're gonna copy this into a Drupal theme, we're gonna start modifying it and then we have basically two versions of our CSS. The one the designers wrote in a prototype and then the real version in Drupal. And we quickly realized, well, this is a bad idea. We're writing our CSS twice or we're writing it and then forking it. So if our designers are thinking in design components as they are, we need to be able to implement those design components in Drupal. And if we can, we use exactly the same markup and we use exactly the same CSS. So this language of design components has become our bridge between designers and developers. Our designer can say, I understand this top element as a homepage hero element and a Drupal developer can say, great, I understand this as a large teaser view mode. Okay, great, and we can then use that common language to bridge one design component to one view mode. So it's becoming a given that our clients are wanting living style guides. So it's become our job to take the style guide HTML, take the style guide CSS and make the Drupal match those design components. So for a style guide to be truly living, the CSS and the markup needs to be the same in both places. And for much more detail on this concept, I strongly recommend going to John's talk tomorrow about living style guides. So what are we doing now? We're making the markup match and the CSS just works. And again, we had thought about this in 2008, 2009. But Colleen thought, this doesn't work very well. If you just strip everything out of your template files in Drupal 5 or Drupal 6, it's not going to be maintainable by the client's long term. But I think we have the technology now. So if our static prototype has a design component that looks like this, relatively simple, we've got an image, we've got a headline, we've got a date. How can we make Drupal print that markup? If our designers have written semantic HTML with classes that are written around their design component understanding rather than Drupal specific understanding, do we have a tool in our Drupal tool chest right now that can do that? We've got panels, display suite, views, display plugins, fences. At Palantir, we've gone to panels as our main tool for mapping between design components and Drupal understanding. So we can take that statically coded prototype, throw it into a panel's layout plugin, figure out what our variables are, and then in panels, you set what your data source is. We've got a node coming into this mini panel as it were. You pick your layout plugin, that illustrated list item. So again, we're mapping the design component that our designers are calling illustrated list item to a panel's layout plugin called illustrated list item. And then panels gives you a UI for lining up your Drupal variables to your design component variables. So we're separating raw data from our design components, the panel's layout plugins and the templates therein, and we're separating that as well from the preparation of those variables. How do you get from a raw node object to something you can print in a template? If you're working just with Drupal Core, the answer is you write pre-process functions. And pre-process functions can get unwieldy eventually. We found that panels is a better way to encapsulate that task of how do you go from a raw node object to something that's ready to print in a template. And one of the things we like about panels is that you can use it at multiple layers of Drupal. You can use the panels everywhere module at the page.tpl level. You can use page manager at that hook menu level. What happens when you go to this URL? That's up to hook menu. You can use panelizer at the view mode level. And you don't, if you don't want to, you don't have to use the part of panelizer that lets editors change per node. You can just say, all article teasers are going to use this panel's configuration. And you can use many panels at the block level. So again, in the future-ish present, we're trying to be the design by making the markup match. But to quote Dumbledore, do or do not, there is no try. I'm glad that got a laugh. That's my way of seeing if I've lost everybody and you've tuned out. So the future, clear decoupling. Headless, headless, headless, headless, headless, headless Drupal. In the session description, I promised at least a dozen references to headless Drupal. Everybody's talking about it. It's a given that we can't stop talking about headless Drupal. So Wikipedia says headless software is software capable of working on a device without a graphical user interface. And Drupal's had that for a long time. We've got to rush. That's headless Drupal, if you're asking me. But the headless community is really talking about how can Drupal work with these modern front-end tools? Like Ember, Angular, Backbone, Web Components, front-end tools that have a completely different mental model from the Drupal core mental model of structuring markup and rendering. So the question I always ask is if you want to make a headless horseman, you need to know where the neck is. If we're chopping off Drupal's head, do you chop off the head before theme or after theme? With item list, you've got to prepare all your variables up front. So an Angular developer could recreate that item list function pretty easily. You know from this PHP array basically what's expected. You know even before you call theme what kind of markup you're going to get. In the case of theme node, you have no idea what's going to come out of that theme function. There could be a pre-process function that changes everything. There could be a template function, a template suggestion that changes everything. So this horseman manifesto is calling Drupal out. This is something that I think was written at last DrupalCon in Austin, the last North American one, saying that in Drupal today we've got a tendency to conflate our data with our controllers. We don't have a clean separation of where does our data stop and where does our template begin. I think pre-process functions are a great example of this. Our pre-process functions there so you can manipulate your data or are they there so you can add CSS classes and slightly tweak what it's going to look like. You can use them for both and I think that's our problem or one of our problems anyway. So what do we do about it? The horseman repo suggests that we do need a separation of presentation and content and we're going to need to figure that out in headed Drupal in order to make headless Drupal work well. And I think it's a good thing that we have some financial and market pressure on this. I think clients are starting to see the value of decoupling a CMS and you can go to sessions this week on decoupling your CMS. So to take an idea from Todd Ross Neinkirk presentation called the future of the CMS he describes the pattern that we've been in as in the Drupal community this way. That is very common for a site to build in Drupal 5 and do a total redesign and then you migrate to Drupal 6 and you do a total redesign and seven total redesign on and on and on and each time you are redesigning along with upgrading your CMS. And that's painful. It's also expensive. Todd sees the future as a decoupled approach where you can redesign your CMS or at least redesign your front end without changing the back end CMS and then later upgrade to Drupal 8 but don't touch your front end at all. Yesterday I was talking with someone who said our editors really like the custom tools we've built into the Drupal 7 editorial experience. They think it's great but our site is slower than we want it to be and it's more complex than we want it to be and I said, okay well then rebuild the front end. Keep your Drupal 7 editorial tools, rebuild the front end experience and then in a year or two slide out Drupal 7, slide in Drupal 8 and your end users don't even have to know because the site will look the same. Now that's really easy for me to say over drinks is much harder to do. Actually doing that requires drawing that clear line of this is where our data ends and this is where the design starts. So I think it's great that we do have some market pressure here because the front end is really moving so much faster than things on the server side right now. So it's a given that these front end tools that are evolving faster and faster have different patterns and it's also I think a given that as a Drupal community we can't pick any winners. We're not in a position, we're not moving fast enough to say web components are going to be the winner or Angular is going to be the winner. We're going to tailor everything towards Angular so instead we have to look for what patterns are there encapsulation. I think a common thread in these front end tools is that they have a different way of encapsulating a front end thing. In web components it is the single web component that is the encapsulation. They expect a different kind of data binding and a lot of them expect two way data binding which is a concept that I think we're implementing in a certain fashion in Drupal 8 with in place editing but I imagine we could be doing it even better. Interfaces, this is something that has been extremely successful on the server side in Drupal 8. The idea that we can rely on third party code like the HTTP kernel and all we need to know is the HTTP kernels interface and then our dependency injection container can wire everything up. I think we're going to get to that pattern on the front end. Can we imagine replacing our administrative toolbar with an administrative toolbar web component? That wasn't even written with an awareness of Drupal. It's conceivable but for that to work we would need to know what does our toolbar really rely on? We know it's a list of links but what does it really truly rely on? And I think the interface is the pattern there. They have different ways of doing extension. Twig has its own way of doing extension. Web components have their own way of doing extension and this is a concept that really isn't present in earlier versions of Drupal. There isn't really the concept of extending. There's a concept of overriding but if you override your node.tpl with node-blog, you're redoing everything. On a certain level you're overriding but there's really not much of a connection between the two. So in this future era, what are we doing? We're pulling usable variables into independent design components. Now what will tell us that we're moving towards the future? If you can draw a clear line between your data and your presentation, I think you're moving towards the future. If your design components are defined in one place, if you can have a static prototype that defines your design component and you don't have to completely redo them for Drupal, that's a great sign. If you can name your design components independent of Drupal, if your template file is node.tpl that tells you it's coupled to the node system. I'm hearing more and more anecdotes about multi-disciplinary teams that have front-end developers that know nothing about Drupal and we shouldn't make them name their template files after Drupal's internal data structures. So if your templates and your functions are named for those independent design components, illustrated list item instead of node-article-teaser, that tells you you're moving in the right direction. And if you can make changes to your HTML, your CSS, your JavaScript outside of Drupal and have it just work inside of Drupal, you're moving in the right direction just as we could make a change to the HTTP kernel in Symphony and have it just work when we bring it back into Drupal. We're moving in the right direction. If you can imagine a front-end developer on a Drupal project not knowing PHP. This is a hard one. I found that to be a successful front-end developer on a traditional Drupal project, you need to know what renderer arrays are. You need to know pre-process. You need to know something about writing field formatters. You need to know how to write a style plugin. You need to know how to write a layout plugin. These sound like backend tasks, but to do front-end development in Drupal, well, you need to know a whole lot of PHP. I think we can move away from that. So, how can we do that? At Palantir, we're doing everything we can to get our front-end developers and designers working on the same thing at the same time. Some of our projects historically structure contracts in such a way that we have a design phase and we have a development phase and we're doing more and more to overlap those so that our designers who are working in market and CSS can work with a front-end developer who might know more about browser compatibility, know more about standards. To do that, you often have to pair them. It's not easy to hire a designer expecting them to know everything about HTML5, know everything about JavaScript, know everything about CSS. A way you can start training your designers up for this world is by just pairing them with a front-end developer. At Palantir, I know that our development team is going to need to push for the next, whatever the next thing is. Our design team has been great at emphasizing for us the importance of prototypes, the importance of style guides, but for us to take the next leap to web components or an all-angular site that's going to need more leadership from our development team. If our developers are asking themselves, am I making X look like Y or am I making it BY? Am I making my view look like a slideshow or am I making it be the slideshow? That's a question you should be asking as much as possible. If our designers can state the data required by each design component, as we got started in static prototyping, the HTML would just get written with titles, subtitles, images, hard-coded write-in, and more and more we're asking our designers, okay, so where is this image really coming from? Is this image here because it's part of the content or is this image here because it's a default background image for the design? Is this image here because it's from the content but if the image weren't here then there would be a fallback image? Those are the conversations that need to happen and the sooner the better. So one more time, in the past, we're making our default Drupal markup look like the design. We're accepting the markup that just comes from Drupal and making it look right. In the present, we're matching the markup and the CSS just works. In the future, we're making our real-sites design components be the canonical design components. Now, I've only covered a high level here. If you want even more detail on what's happening in Drupal 8, I strongly recommend going to the Drupal 8 render pipeline session that Wim Lears is doing, I think, in the next time slot. I've been told that this is an advanced topic that will cover basically what happens when you hit a URL. How is that response getting generated? How are those symphony tools getting integrated? What's really happening? Kotzer and Joel will be talking about style, I'm sorry, that's John, that's Tamara, but later today, Kotzer and Joel will be talking about the theme system from hook theme all the way to your twig file. How does that really work? So today, we've got render pipeline and the Drupal 8 theme system. And on Thursday, we've got core conversations from John and myself. I'll be talking about panels and web components and John will be talking about an idea, potentially for Drupal 9, of how can we bring this concept of design components all the way to Drupal core. So thanks, everybody. I think we've got plenty of time for questions here. We've got a mic in the center aisle. If anyone's interested in asking questions, I see David walking up to the mic. Hey, David. I'm claiming my privilege here. Great. All right. In this current system that you're describing where you're letting your designers write some sort of HTML CSS, are there any guardrails that you put around them? Or is it pretty green field? Write whatever, see it. Or how parsimonious is this code? Is it just whatever pops out of their head? Or with some sort of thought to Drupal in mind? So we've certainly found that there are some areas of Drupal where this doesn't work very well, particularly the menu system or forms. The menu system we found, as well as the form system, those portions can be so difficult to modify markup to get exactly what you want that sometimes it's just not worth it. So in those cases, we've often configured a menu or configured our form, take that Drupal markup, put it in the style guide, and then style around that. I'm curious how close you think Drupal 8 has gotten to your future vision. So I think it's put in even more pieces, which is, and it's taken out some pieces, which is a double-edged sword. As I showed that slide, the diagram, the Drupal 7 theme system, each one of those pieces adds to the complexity and makes the system as a whole harder to understand. But each one was added for a specific use case. I think Drupal 8 has done a little bit of the same, added a few concepts, removed a few concepts. So for instance, the process layer is now gone in Drupal 8. I think that's an improvement, because it was never, I think, widely understood the difference between one to use a preprocess and one to use a process. So in short, I think Drupal 8 Core isn't thinking in design components. That's why John's giving a talk about how to introduce a design component system to Drupal Core, possibly as late as Drupal 9. But there are new tools there. And I think as more and more of a start building sites in Drupal 8, we'll find the best way to implement these patterns. And I'm encouraged by CMI and improvements to view modes, because view modes often are our go-to for translating from a design component into Drupal. Improvements to view modes, I think, will be a really big help. Hey, Steve. Sorry, can I take a quick? Micah from phase two, a great talk. I'm really on track with a lot of the stuff you're talking about. One curiosity is as we start splitting, we'll start trying to use the exact same markup for our style guides and externally from Drupal as we're using in Drupal. How do you see that working with where D8's moving with Twig? Is Twig going to be the default markup, or are you going to have some external markup be the default markup? Where is that canonical HTML going to be coming from? So I'm really looking forward to building sites with Twig because of that extends concept. What I plan to do is have prototypes built in Sculpin, a static site building tool that uses Twig, namespace the Twig files, and then in Drupal extend those files, or just include them directly. So if there is a need for any difference between the Twig file and the style guide and the Twig file in Drupal, the tools in Twig make that so much easier than working with a TPL. So that would make the canonical Twig file the one in the style guide, in my opinion. But the goal is that it is just the same Twig file used in both places. Great, thanks. Sure. Yes, over here. Oh, sure. The URL is Palantir.net. It may be easiest to look at my most recent tweet. Steve Vector is my Twitter handle, and I tweeted out a link to the slides. Yeah, I'll also post them to the session description. Any other questions? Great. Well, thanks, everyone, for coming. Yeah, it's like the buzzing stops if I plug this and this in. But I'm not saying anything. So it's curious, like, if I'm missing something true and crucial, come by our tour. Tour, yeah. Let's just have a stick and see what it does. Have you looked at the press and pull module in 7 how many times? No. What I like about it is that it's