 Hello everybody, how are you? Welcome to the final session of day one. Hope everybody had a good com so far. This is a panel. It's called Different Ways to Control Your Layout. This is going to be I guess part funny intro part demo and then quite a lot of Q&A so hopefully you guys have a lot of questions. I have a hashtag set up, DrupalConLayout. It's on the slides. Hopefully I will be able to collect them here as long as the Wi-Fi stays up. So you know layouts are something that are near and dear to all of our hearts here. We've all, everybody here has been working in Drupal for many, many, many years. You know over the centuries we've come up with a lot of different approaches for how to, you know, for how to control the layout on your Drupal sites. You know, hopefully long gone other days with your layout all hard coded in page.tpl or node.tpl or maybe even something other, some other crazy way. But you know the tools that we're going to be talking about here today I would say you know represent kind of the leading edge of how people have been doing layouts in Drupal over the past probably four or five years. You know some are more recent than others but you know panels I believe started back in the Drupal four days, Context had its beginnings in Drupal five, Display Suite Drupal six, you know Templar Field Drupal seven and then you know we have guys on the panel here to talk about Drupal eight as well. So you know we'll probably cover a little bit of the past and a whole lot of the future but mostly future. You know the choice of layout managers if you've spoken to enough people over time is something of a religious war. You know people get divided into camps and like their layout manager is way better than somebody else's and you know the things that it does that are the quirks that most people hate are the things that other people love. So thankfully I'm not really into any particular religion and you know through the relentless badgering of Matt and Sam and Chris you know myself who is historically in the context camp has come over and played in the panel's world. You know we've even done crazy things like wrote something called Custom Page in Drupal six which I wouldn't recommend anybody use. But you know at least me personally I feel like I've built sites in every different layout manager they all have their pluses and their minuses and you know when Munich was approaching at the last Drupal we thought it would be a really good idea to get everybody together who works on these various tools and get them in one place allow people to ask questions let them you know kind of ask and answer each other's questions and kind of see how it goes. We thought it was a big success and we said let's do it again for Portland so here we are. So let's do a well before we get into you know be sure to go and evaluate the session hopefully you know you've had a really good time. So this is me I'll be the moderator today I won't really be answering many questions but I'll be asking a lot but hopefully not too many if you guys have plenty of stuff. I'm the founder one of the founders in CTO phase two you know do things like open publish and open public. I've been a maintainer on features and context modules like the Akamai module and like I said I've used almost every layout manager there is. I love each of them and I hate each of them and hopefully we'll we'll get into some of the details of that. So next is Kristoff. My name is Kristoff. I'm a Drupal developer at Moondakraft in Belgium and well you probably might know me as Swemple on Drupal and also on Twitter and pretty much everywhere on the internet. I'm a Drupal 8 core maintainable field API and field UI which is sometimes a really hard job but it's really fun especially to be working with watch at the lead maintainer of field API and I'm also the lead maintainer of this this place and is Christopher seen by any chance in this room or apparently not. Christopher is the Drupal 6 branch maintainer of this place and I'm really grateful for that. He's here I need to drink a beer with him because he's from Australia I'm from Belgium that's a really long distance from each other and we only talk on IRC or on Twitter or whatever. So this place week there are a lot of reasons why we start writing this place week. The three main reasons for this place week basically are first of all PHE template. So my front-of-developers at work they speak fluently JavaScript and CSS and all that stuff but when it comes to PHE and especially the way that Drupal built his data it's kind of hard to get into it and one of the things then is I used to be the one that had to master template because I knew how Drupal built his data structure and stuff like that and yeah it gets kind of boring after a while and so that was reason really number one. They I basically also didn't trust them with PHE so there's security issues with PHE template which hopefully don't go away into the latest week so maybe dyslexia won't exist anymore because my front-of-developers really like tweet and they won't do master template files again that's a possibility. Reason number two is maintainability. You can create a lot of templates and especially when the site is live when you have to make some adjustments then you really have to make sure you open up every template far away you have some kind of data that you can change for any project or for a live product. And third, the FCODIY in Drupal 6 it was CCK. It wasn't really that flexible it was crap basically because you only could configure the field and we also wanted to have control over like say the no title or the offer and stuff like that. So those are really the three main reasons why I work this place with together with all my colleagues. I'm still on? Okay. The silence is coming that's all. Okay. I'm still there. Hi. Hello. Hello. No. Okay. The mics are gone. The mics are gone. Yeah. Can people still hear? Okay. Okay. Okay. Where is that? No problem. So those were the three main reasons why we wrote this place week and I'll be giving you a short demo after all the other ones have introduced themselves and hopefully we get some questions. So thank you. So next is Brian McMurray. Hi everybody. I'm Brian McMurray. I'm a software architect at Phase 2. Today I'll be telling you a bit about a strategy we call single page or single node layouts. It's a combination of a few modules that we've created. One's called template field, another's called beam. Can you hear me? Yeah. I'll be talking about single node layouts and some of the strategies for the reasons why we came up with these methods, some of the reasons for why I think it's an interesting and strong solution and I'll give you a quick demo of how we're using it on one site called Robinhood.org that I'm not a professional in New York. I'll show you how flexible that's been for them and you'll actually get a chance to learn a whole lot more about that on Thursday when we'll be on another panel. Hey, I'm Brian Sanchez and I'm from love with panels on 12th November and years ago and I really look back. I'm a big believer in, I mean, all this and I think panelism very much is to be sort of a hard soul, but what Google should be, that when I came into Google I wanted to have tools to make websites, I wanted to have my friends have tools to make websites and I definitely became frustrated with having to out a lot of code to do other basic things like change the layout or maybe add some stuff like this. Panelism to me is always been a solution that like helps to love all of Google and lets you maybe why do a whole lot of things from controlling the way their content works to setting access rules to obviously changing layouts. So the other thing that Google's accepting here is now, my current game is a company called Pantheon, which is all about kind of a really awesome Google platform technology for people and the idea here is that I think in some years in the future that Google will run 10 times the way that they're running and I think they're going to be able to be very posting technology and we all see really great tools like nails and abilities to change the layout and one of the things that I put together that really helped to kind of sell this is a distribution of Drupal through Drupal 7 called Panamali that basically takes all the best practices, handles magic, and gets full magic then that I'm aware of the fun that was sent together in a way that you can download and you can use as a type of threat to a site or to a new distribution and it has a lot of great ways to sort of control how the layouts work, involving them and I think all of that about how Panamali uses the sort of layout plug-ins to the app, they're going to be able to change the structure and not really about how you can customize the layers and change the layouts. I'm Chris Donson, I'm a computer engineer in days two and I'll be talking a little bit about context and how you can use to control the layout. It actually started with Drupal 6 and I'm going to come and talk about it and see how it started to develop it there and it's not solely a layout control tool, it has a lot of flexibility in terms of how you can use it isn't related to the layout but one of the most popular uses of it is supporting places and there's also some conditions and reactions which can be used that address how you can use it so I'll be kind of giving you a bit of that and a slightly modified version of our new public distribution. Next is Chris. Next up is Sam. Next up is Sam Boyer, as they wear on Drupal order and whatever else. As I said, I'm the other company that leads that initiative for Drupal 8. You won't see me on the schedule because they had the foresight to realize that when they did such like this community, I just relayed and put the products away on the stage and the main stage is when I'm there. I'm going to try to not get out of the soapbox but I'm going to do the delay but chances are it's going to happen there. This is a stage full of soapboxes. So you know these guys are now going to go through and give you a little bit of a demo of their solution. You know as you come up with questions if you want just shoot them out to DrupalCon Layout on Twitter and I'll be monitoring that and we could get the questions to the panel later. Somebody brought this to me beforehand. I forgot to mention it. Tonight at 7.30 in the Coders Lounge at the Double Tree Hotel, they're going to do codathon for Oklahoma Tornado Support. So that's 7.30 tonight at the Coders Lounge in the Double Tree Hotel. They're going to be trying to get together and organize teams to help create apps to help those that have been victimized. So thanks. So with that let's get into some of the demos. All right, so did the screen switch? Yeah. Do you see an admin module page right now? Okay, great. All right, so display it as a module and it's a country module. So you have to download it. When you download it you get a set of modules. There's a display sheet core module which does most of the heavy leverage for layouts and stuff like that. There's display sheet experts that contains all of the kind of cool little stuff that you can enable or you can disable. It depends on the use cases. And there's also display sheet search which I'll be showing in a couple of minutes and there's also a display sheet UI. You don't have to enable UI. UI is mainly for creating new view modes, new fields. But I suggest doing that mostly using my code. That's actually what we do. So when you enable display sheet you go to the main overview page. What you get there is an overview of all entities in your Drupal 7 installation. And I guess compared to the other solutions that we have here, display sheet does not actually do something with your page layout. Display sheet works on the entities. And we have something that is called view modes in core. A view mode is something like full, a full version of your node. And you also have teaser. Core comes with search index, search result. And you may have something else. I think something like boom. And you can create your own view modes if you like. So that's what you get. And it works on every entity that you're enabling in your Drupal 7 installation. So what we have here is content with exonomic terms, users and comments. But it also works on the view module. It actually also works on fieldable panel things. And it also works with entity construction, if for instance. So you don't have to actually write anything. Just enable a module that has an entity. And you're pretty much good to go. So when you actually click on manage display here, you go to field UI. Field UI is a core module which you probably all use. You mostly go to manage fields probably to add new fields onto your entities. And what display sheet does is it goes to manage display. And it actually extends. So what you see here right now is just only the field API fields. And what we do with display sheet is we add a new tab at the bottom where you can just select the layout. So at this point, display sheet ships with a couple of default layouts. You can create your own layouts if you like to. If you have panels enabled, you can also select the panel layouts in here. So depending on the way that you build your website, you can actually just enable page manager and panels. And you can also use those templates. So you get consistency with the way that your layouts are built up. So what I'm going to do is just now select a two-column layout. Get a nice preview. That's something that is new in the second branch. Click on Save. What happens is that you now also get a lot of new fields. It's something that's an API in display sheet. It enables you to control the properties on your entities. Properties like the title. And it also adds formatters. You can select whether the title needs an h2 or an h3 or things like that. And you can also, if you're a developer, add new properties or you can just add anything on it and display whatever you like. So also you get regions on this screen. You get now a left and right region. So just start dragging around a little bit and image dial is on medium. Click Save. And this is how a normal dupal core installation works. It doesn't really look that fancy. If I reload the screen, you get this. It's really easy. It swaps template files. That's the core main thing that this lazy does. It swaps template files for your entities. And you can basically do the same for teasers. So I go to the home page. This is actually a view that takes over the node listing page. You get a list of teasers. You just basically go to teaser. And for the sake of them, I also will select a two column layout. Just start dragging around a little bit. And let's put the body here. Now on teasers, no template file contains a title string. And we want to replicate them. So we have a title right here. I can put it on top of the image. The wrapper is H2. It's a reload the screen. And it looks like this. So one important thing, it's not a CSS tool or something like that. You still have to write a little bit of CSS like in every website, I guess. So if you have support questions regarding CSS, I mostly will close them in the issue queue or ask my funded colleagues to answer them. So this is a really easy way to quickly and have a consistent way of theming your or controlling the layout of entity view modes. Now, we also have views integration in that sense. If I go to an edit of the view, we have a display to be road plugin, which has some additional functionalities. And the most use case that we're using for, we have an alternating view mode. And what this does is, for instance, if you have 10 nodes on the list, you can basically say, okay, the first one has to be a full content view mode. The second one needs to be a theater and so on and so on and so on. And it's really easy. I can't even remember how I did that in the past. It probably was a lot of hacking or some if-else statements and template files or things like that and counting and aesthetics and whatever. This is really easy right now. So where's the save button? Okay, it's right here. And, yeah, okay, so I use it to column layout. For both, we have a really easy contextual link right here. So I could, hmm, is that good? I'll go to default, sorry. Live demo. Yes, they always go wrong. Let me switch to, I'll just add another field to it, so different. Right, so here's the author. So you can easily switch between this, between view modes. Now, one of the hardest things in triple core or at least what we find hard is teaming search results. If I would just search for some word, then you get this, well, like formatted stuff and things like that. DisplaySuite contains a module, DisplaySuite search, which allows you to take over this page and it works for search. It also works for Apache Solar. It doesn't work yet for search API because at this point we don't use it. And usually I only commit stuff or at least I work on stuff that we use at work. Of course, if anyone is interested in using search API and giving patches, I will happily commit it. So what you have to do is go to search settings. We have a new search info stuff. It calls DisplaySuite search and that's now default search module. And if I hit, then you get nice search results. And you can actually, what you see here now are two articles. The third one is a page and I can now also go to the manage display of the page and then we have nice search results for pages as well. And it's really easy and you don't, you only have to do some CSS stuff and you're done basically. So that's a really short demo of how DisplaySuite works and we'll go over to the next one. Brian's up next. So this is, I'm going to run through a couple of quick slides that will auto advance every 10 seconds. So maybe I'll keep up and can you see the slides or do you see the... This is single note layout. Okay. So I'm going to talk to you about single note layouts. The place that this came out of is we needed to be able to do a lot of things to our display, our designs. We needed to revision all of the things, translate them all. Man, this is really fast. I'm going to go back. Revision them all, translate everything. And they needed to be really highly custom on a per page basis. And we wanted to be able to do all of that without using a developer every single time a new design came in. New code would need to be added to a theme or pushed into the repository and deployed live. We didn't want to have to do code deploy every single time. So here's a couple of quick little wire frame examples. So maybe these are the same, two different pages on your website. They've got similar types of content but they look very different. What we started asking ourselves is in the past we would create all these different fields and maybe we'd throw together some quick tabs blocks or abuse block or abuse slide show and all these different things. And we'd end up with lots of different content types with various different fields and we'd spend a lot of time theme them. On one site I think we had four different types of blog content so they could have different features. So we started asking ourselves what if we created something that let us control each of those little layouts and we call them templates individually. And so we created a template field and then we asked ourselves well what if we could create flexible layouts that would have extra options in them to be able to share similar things so content and images. So this is a quick example of Robinhood.org. They're a nonprofit foundation in New York. They've got some really highly designed content here. In fact they had large images, they had large text and then they would have interactive content. So this piece here that looks like a city skyline is actually an interactive piece. You can roll over those little bar graph pieces and get new pieces of information. In the past you would have to have a custom content type with hundreds of fields or something to be able to control all that data or it would just be a flash piece that had an XML file somewhere. We wanted to be able to change all that control all the same way. So that's where template field came from. Template field is a model you can get on triple.org. It's an API first and then it comes with a pluggable rendering system and then we actually wrote a module called template field that makes it exist as a field instance. So the API is what controls the ability to create these templates which is a package of HTML, CSS, JavaScript, which Drupal libraries you might want to include that are already existing within the system and a set of inputs which are configurable you know customizable data input areas. The rendering library that we're using is called Mustache. Mustache is a really neat little templating library. They're called logic-less templates. It's super easy. If you can read this example here that's up on screen it's very straightforward. It's nothing like PHP template. This would be something that a content editor or a business writer could look at and understand how to use. As long as they were given what those input names should be they could write these themselves and actually on some client sites their design team knows HTML but doesn't know PHP. So they could write HTML, Mustache templates, input in the input names and then they can do that without meeting a developer to take care of it for them. This is an example of the admin. It's not much to look at. It's basically the Ctools export UI because all of these are Ctools that exportables. When you're creating a new template you've got a number of options here. You can add your machine names and tags which I'll talk a little bit more how that's interesting in a minute. Then you can also go in you can add custom HTML, CSS, JavaScript and pick from a list of all the libraries that are available in Drupal to bundle with this template. Then you can go in you can add template definitions. As I said before this is an example of sort of the quick HTML template that you might use for something. So what this is showing here is that you've got a couple of different inputs. A text input, an image input and an image position input that actually just sets a class on something. This is pretty straightforward and fairly non-complicated to get a handle on. These map directly to these template names, these input names that you can figure. So here we've got text input that's going to be a rich text area, a WYSIWYG text area when it's encountered in the node admin UI, an image area that's going to be a file upload field, an image position which is actually a select box that's going to just give you a few predefined options. So you can put all these things together. You can declare all this in the admin UI or it's also available to do in code. I prefer to do it that way. There's a nice hook built into the module that you can write an admin or a custom module for your site, declare all of your templates and then they're just there. But if you've got content teams that are creating new templates as the site lives on they can do it within your website without needing code to place. So here's a quick screenshot of what it might look like on the most basic level. This is that same input that we just, or that same template that we just defined. You've got an option here to pick from your different templates that are available in the system. This one I called image and text. It's got the text area that's filtered HTML format, formatted text, an image upload, an image position select box so that you can build that really simple thing. What we found with this, particularly in the Robinhood site and I encourage you to come to our talk to hear a whole lot more about this, is that we were putting WYSIWYG into all of these text areas. And so here's a quick look at what the different layouts that we created for Robinhood are. They look probably pretty similar to what panels might look like if you've used panels before. These are pretty standard just stacked layouts. But there are two extra ones here. These are custom interactive ones, bubbles and city stats that are sort of our fun names for them. Those are the exact same system as everything else but they handle very delicate customizable interactive stuff and then all of that's actually rendered out using Raphael, JS and SVG to create those really interactive graphics. Here's a quick screenshot. I'm going to actually show you this in a live demo in a second of one of those fields on the Robinhood site with WYSIWYG in here. You're probably asking, what about reusable components? What if you want to add blocks or what do you do with blocks and beans? What's even a bean? A bean is a funny name for a module that stands for block entities aren't nodes. Basically it turns your blocks into entities that are just like nodes in Drupal. That means that you can define block types and then create multiple instances and those can be revision and put through a workflow system just like any node in your site. Which also means they're translatable very easily. In this case in the Robinhood site we also use the embedables module that allows content editors to create these beans, these reusable widgets and then embed them into their WYSIWYG text to get really complex interesting design layouts. Why use single node layouts? You get custom layouts on a per node basis. You get really easy templating language that people who are unfamiliar with Drupal theming can use. It works with all of your revision workflow and translation systems and it's far fewer fields. You don't need to create lots of different content types to handle all these different really complex data things that you want to collect which all end up actually being called content. Here's one little slide I call double rainbow time and this is because what's really interesting about template API is that templates can actually be used to format template fields. What does it mean? So if you add a tag to those templates that you're creating and you call it formatted then automatically your template shows up as a field formatter option for any template field in the system. So we've used this on sites to create templates that are just simple slideshow or carousel sorts of things where it's got a custom layout, it throws in the JavaScript to do a simple jQuery cycle or those sorts of slideshow libraries and then we have a multi value template field instance on one content type. You just add many different, totally different template field values to that one field and then when it renders out it's a magical slideshow on your note. So that's super complex. I'd love to talk to you more about it. I'm not going to show you that because it's definitely hard to wrap your head around but template API is super powerful and it's more than just existing as a field that can be used to influence how fields themselves are up. Again come see us on Thursday to learn more about Robinhood. Let me show you Robinhood real quick. What do you see now? You see Robinhood.org? All right. Let me show you just super quick what one of these looks like. Here is one of our example things. This is an interactive city stats template. If I just use the contextual links and jump in here. It's running smoothly. I think it goes super fast. You can do it and the demo guides are going to curse me. All right. Well I won't take up all of our time waiting for this computer thing. Oh of course there it goes. All right. Super quick. Here's the layout. We've got city stats here. It's a top content. This is WYSIWYG stuff you can do anything you want here. We use a little JavaScript to change the background color of the WYSIWYG area to match the background color that you pick. And then we've got all of these stat bars. We've got one for each of those little pieces. You can upload an icon, title on the description for each one. So you can do all this stuff. You know this isn't a true infographic. It's a marketing piece of content. You can do all this content. All of this is contained within the template. So here I can actually flip open our template chooser. I'm going to pick something different. All of this is going to go away and we're replaced with just this template's new layout areas. We can add some new stuff and save it. And then we've got an updated funnily displaying but updated template area inside of these pages. And that's what's really cool about this site. It's super flexible and content editors. And that's it. Cool. Next we'll go over to CJ who's going to talk about context and context field. So, context is not simply a layout control mechanism. The parts that I'm going to show you however are the most popular parts for it. But whenever someone asks me to kind of explain context in a sentence I say it's a graphical interface to Drupal. And by that what I mean is context after you install it gives you the option to define all these things called context. And when you take a look at any one of them you can look and it has a set of plugins that are called conditions which are used to activate the context. So the one that we're looking at right here is one called no sidebars. And this context would be active if the particular piece of content we're looking at if the field full width field has a value of yes or if we're at the project's path. And you can tell that it's or because of our all conditions is not checked. And what will happen when this context is active, when this context is active is that the sidebar first and sidebar second regions are going to wind up being disabled. And it's going to add this little no sidebar class to the body tag and that's going to be there so we can do some background swapping. So I'm going to show you that part of it very quickly. Here I'm going to edit the about the ABC agency field and I'm going to tell them and quickly say set it to full width. And now there's no sidebar. The map is swung out whereas before there was sort of a listing of legislators and staff members and that kind of thing. And so that's one sort of quick way that you can set up a context to control your layout. Part of the context that's built in for controlling your layout is if after you install contracts you come in to the settings and you choose use the context, edit the dialogue and you ask it to show you all the regions. You can do really cool things like following. And this is I always call it the context in line editor. It's called context dialogue. But on any page where there's a block you can select from a contextual link that you want to configure the layout. And when you do that it'll show you all the contexts that are currently active at the path that you're at. You can choose which one you want to modify. So I'm going to say I want to modify the home context. I'm going to slide this out of the way and then it gives you the option to come and just start dragging pieces of your page around. So I'm going to put the Portland feats over here. And I'm actually going to come through and I want to add a custom Twitter box here. And so what was the current throughput on layouts? Yep. The layout? Uh, layout single. All right. So we'll say we're going to be 10 there. So this is interacting with the box module. And so I've just created a new box and then placed it here on page. I'm going to come and say that I'm done editing the layout and I'm ready to save my changes. And then I'm done making all of my edits. And you can see I've sort of changed the home page layout and the way things are placed there. And so that's that's part of the system that this comes out of the box of context. If you wanted to use like the full bit example I said earlier, you need to look for a module called context pool field. And that'll just let you set up a reaction based on the value of the pool field. And there's plenty of plugins that people have written depending on how they want to be able to set up their conditions and their reactions. But context is it's kind of most appropriate for your site and controlling layout. If your site is very sort of rules based, it's not everyone wants to just do whatever they want to do on every single page. If it's on pages where a particular tag has a particular value, I don't know sidebars or I want a particular item that's in a sidebar. If you can set up the system for laying out your site using rules like that, that's when context is probably going to be a good option for you to look at. Cool, next we have Matt. Well I will be interviewing the panelist module, which is very much about letting people have whatever they want on every page, which is something psychedelic populist do a lot of work. So that's what it says. But the corner of the panel's layout philosophy is that every sort of page that you're using will have a content region in the middle, and that's the only region you need. And this is sort of really important. Unlike sort of traditional rumor where you're going to have a whole lot of different regions, such as strapable gaseous words, scripted, that this is not necessarily how people think about their sites. This is a very developer kind of thing. I want to put this piece of this thing in scripted middle and that will be the word that shows up. People don't think like that. They want a sort of single region where they're going to have their content and they want to have really full control over that. And that's what the panelist is really good at doing. Instead of just going through the theme of having a bunch of regions, let's just take over the entire content variable, let's use the panel layout system, choose the kind of layout we want, where people do really awesome stuff with that. So to sort of take an approach like this, we need to pull together a few modules. You're going to need the panel's module, obviously, as well as the castable module with the dependency. And then to actually have this kind of thing work on some normal pages, you get that on the page manager, to do it for notes or other kinds of entities. You can do a panelizer and do it on existing pages like the registration form. You can use it on some probably wrote or maintained existing pages, which is a particular way to make everything a panel. And that's a philosophy that I think is really great. Drupal works well for labs. If you want to see a match that you can grab with nobly distribution that bundles all those modules and use a single demo of the basics as, let's take everything a panel, and let's allow them to play with layouts. So you can take that content region, and you can have an area on the page that you can edit using a sort of front-end panel interface called the panel's ID, with the assembly, right or wrong, and I don't know if that's something other people want to improve. Because you can have one column, or you can have two columns, or you can have five columns, and that's all because we've taken over that main area and we've done something with panels to sort of design what we want. So this is great because, you know, each of those layouts that we made is a specific gas-cooled layout plug-in. They're really straight forward to write, and you can sort of Skype a little bit with that. And I'll pull you down with that as distribution shifts of 31 of these things, 5,000 responses already, so that you can actually go in and start building pages. So let's go ahead and show sort of what this would look like. You want to try, as I said, this is the article that works. It's package distribution monopoly, and you can sort of go ahead and download it, or I can't do anything to download it, or install it using the web UI. And once you do that, you'll get to something that looks like this. That's for the sort of monopoly front page. I haven't done anything here but install it, so let's go ahead and just sort of go ahead and name the page. So we'll add the promotional page for the DrupalCon, for the landing page, we'll call it DrupalCon URL, DrupalCon, we'll add it to the menu, and we'll go ahead. And this is on the back-end critic of panels of the page manager page. It's going to look at that URL, and it's going to take you over that content. So if we go ahead and see, we hit Customize, we sort of get this area right here. And so let's go ahead and try to add some stuff. So this is using the people campaign module, you can go ahead and add stuff like images. I've got this Portland skyline thing that I got before, and we'll add that. And now we have the Portland skyline, which is cool, but we can go ahead and change that. So we're going to have this single column, we'll just have two columns, or a general smaller one, which is great. Go ahead and we'll have to this side, we'll go ahead and add a map. The address here, we'll go down here, and we'll go ahead and put a little map on there. You can see where we are, which is cool. And now we saved it, so now we're starting to build this page. And we'll go ahead and this will change this again, and we'll go ahead and add that stack layout, and you go with that. And it's cool because it's sort of just swapping us out on a page basis. We're doing a gesture of this particular callback, but we can also go ahead and do that for, you know, anything that's open type note or type user. Let's go ahead and add a little more text here. For folks, it's not going to be getting demoed, I love vegetarian, so you can tell this is actually awesome. So we've got to fill in the text going. And this is cool because similar to what was done with the comments module, you can also drag these typescidings around, look at the layout, and you can start to actually build pages that look like that, which is really neat. And this is something where from a site end of perspective, I'm not having to go into the back end to do any of this stuff, I'm just sort of like deciding what I want based on, you know, the sort of content decision that I have. So if I want a table, DrupalCon, and I can say it's awesome, and this is the kind of thing that a lot of content editors really like to do is to stick layouts and control them without having to do a lot of necessary sort of back end stuff and not that. So I have to bring the map over, the instance of the site, and really have a lot of fun. And this is the kind of thing that the internet works for the video. That from a layout perspective, I think is a nice way to control your layout as a site developer, to make these things as an end user, to change them, and from a sort of architectural perspective, it's nice because all of your layouts are cast with plugins, and if you use Becfossi, you can just make a bunch of plugins and make your site, and not that becomes really neat. And so yeah, so definitely check it out, and if you're looking to do a site and use channels, you can have a lot of really great technology to control your layout. Well, next we have, Chris is going to show us a little bit of Drupal 8 layout stuff. So while he's getting set up, Matt, someone had a question for you. It was, when you came to Drupal and had the vision of easier layout control, how strong was your technical background? Oh, I mean, to put it, I mean, I'm obviously not writing a lot of this code while I come to the panel, but as a person, I'm not actually a particularly technical person, like I write a lot of code these days, and at Panthen we're obviously doing a lot of pretty natural construction, but my background is in library science, I was very interested in as a librarian how to present online content and how to control it, and I think when people come to Drupal, they're not necessarily looking to just code, they want to like make their idea on the internet, and that's one of the reasons I like these tools, because it gives sort of end users a lot more power to control their layout, and doesn't necessarily know a lot about Drupal because Drupal can be sort of hard. So I'm going to demo some of the things that, this is the Miller Drupal 8, I don't have any patches applied to this at all. You can go and direct this out of the Drupal 8 repository right now and do everything I'm about to do. I won't guarantee that it's about three, it is alpha. In fact, this isn't even alpha, this is alpha. So, and what I'd like to do here is I'm going to address a few of the things that have been shown here and how we're approaching them from the Drupal 8 perspective, and then just kind of talk about what we want the future to be there. Sam and I will basically get from this point forward. So, I'm going to give you a real quick demo and show how that addresses certain topics that we've already covered, and we'll go from there. So, in Drupal 8, we have a whole block section. This seems really familiar to you because it's pretty much super similar to what we've got in Drupal 7 land right now. The presentation is slightly different and we'll probably gain more still, but fundamentally, this is the same thing as what you have today. And so, if we come through here, the big thing that you'll notice is that if you scroll down to the table, there isn't kind of stuff sitting in there that's going to be irrelevant to your life because you aren't using it. And this is really important when you start talking about really big sites like, I don't know, Drupal.org that has over 100 blocks come here, most of which may or may not be being used at any given time. And I don't have an administrative back-end to do the better, but I personally felt some of the soliciting papers on the site. So, you know, in a situation where you actually just want to deal with the blocks that you're dealing with, this is fairly good. And so, what we've really got here is we've got the ability to come in and place new blocks. Now, I'm just going to go back for a second. And I'm going to draw your attention to the fact that we have a search block here. It's generally called a search form. We've got tools. We have user logins. We've got paid company. We have a bunch of stuff, but specifically search here. So, let's see. I've got a little bit of a question here. So, if I just post this, hey, I do have a search block. Great. So, let's just add another one. This kind of shows some of the things that the traditional court hasn't been able to do. A court can not take the same block and put it into two different regions. In fact, it can't have more than one instance of the same block at all. So, if we come in here and we get a place block on search form, I'm going to say this is a search form. And we will display the title. We're going to put it in the sidebar of second. And I'm just going to hit Save on that. And now, if I close this, you're going to see I have two search blocks, right? So, I mean, you've got to support the late problem. We can move that around. We can do all the stuff pretty well. So, this is something that, say, ContextMaple was really good at and did in a very nice way before. All of the solutions you see today can do that. Hey, not for can too. So, that's a pretty big win. One of the other things that we can do here is we can add custom blocks. So, actually, I haven't done this before, particularly during the day. So, we're on for a minute. So, I'm going to save that testing block. And that created a content entity right then and there. We're now placing that content entity on the page somewhere. So, we can come in and say that we want this to be in the sidebar second as well. ViewMode, we can have ViewMode, set this response as Save. And hey, now, if I close this, we're going to have what's in text sitting over here. That is, however, as I said, a content entity. So, we can content entity structure and go into custom block types and do something like, we have a new custom block type called image, say, the fields. And now, if we come into blocks, and I'll do this the other way and hit place blocks. If I add a custom block, which is the same thing, you'll see I can create any of the custom block types that we have. So, if we were going to come in here, the images and say, yeah, that's image. I'm going to go ahead and pass this into, I don't know if this is perfect. Save. All right. Now, if I close this, I'm going to have an image block. I mean, let's switch this straight up block. I couldn't move that into any way that we would ever have on with it. Delete the instance of it. I'll still have the content sitting around. I could have more than one of those on the page. So, again, if we wanted to, we could come into blocks, place blocks. And, hey, since we already created that, we actually have the ability to place multiple instances of the same custom block multiple times. So, I can go ahead and place block on that. I can also edit it here, but I'm not going to bother with that. And we can say, not show up. Well, it's a lot better, whatever. So, it should work. I will check that out later. But, so these are some of the things that the core can actually, actively do now. And so, I think what I would like to do is probably spend this time just kind of talking about, we don't have a lot of time, it's 5.30. This is the last session, though, right? It is. Okay. So, we're just going to keep talking until they pick us up, and see what we're just saying. Okay. So, I think we want to kind of talk about some of the things that we're doing in core right now, in eight, to facilitate these things. There's quite a panel's bias amongst the Drupal eight main fingers of this initiative, but that doesn't specifically mean that we only want panels to be doable. Basically, if panels can be done, then virtually all of these solutions can be done. And so, we've begun working really hard on the APIs to do that. So, there's a war going on. It's kind of amazing. Actually, we can also be on stage. Hi, everyone. Enjoy the drinking tonight. That's what you do at night at Drupal. The fact that we can have this group of people on stage is kind of remarkable. The actual acrimony between the people died down some time ago, but three years ago in San Francisco, there was a very emotional moment when I hugged the maintainer of the context model, and I think it was the first time we had more people come together on the base in like two or three years. But the war still actually goes on in the code. With the way the Drupal works and the way they put together pages, it's remarkable, often, that you can have something like panels coexist in something like contents. What we're trying to do in Drupal 8 is, and trying to do this is not what Chris has shown us far, is we're trying to write a base system that all of these different approaches can share. Common API, common principles, a rigorously designed model that gives us a lot of benefits that performance engineers will care about, but also that front-enders will care about. A more unified rendering system that, again, all of these different systems, all the different interfaces and paradigms for organizing really focus on what's customizing this page and this page for let's set up broader rules and patterns and have things look this way when you're in this context or that context. The system should support all of those. This is what the Scott Initiative is shooting for. Whether to make it or not is, well, it's going to be an interesting few weeks. But yeah, this is, what we're seeing here is the more linear growth that we've accomplished in Drupal 8 so far with the block system, but there are significant refactoring sitting in the branch of the affectionate produced princess. So as we hear talking about princess, we're talking about the Scott Initiative and our last great hope to get these changes in. If we don't, it'll be a shame. It'll be a big shame. But, you know, the Hamilton context will continue, well, maybe as they are, we'll see. We may be able to do much of the Scott Initiative, but hopefully we'll be able to deliver Drupal 8 to all of you where you no longer have to be picking between these kind of options, but no longer need to be such a religious war because the choices are not nearly so mutually exclusive. They are complementary. They are different UIs of the same rich paradigms underneath, and so you pick the UI that matches your use case as opposed to having to pick an entire site organizational paradigm and never be able to move from one to the other with any plot. Cool. So with that, I guess that, you know, we kind of ran a little long, but nobody's kicked this out yet, so if folks have any specific questions, feel free to come up to the mic and ask. There's a mic right here in the middle. Yeah, sorry, mic's up here in the center. So I've noticed that there are significant performance concerns on high traffic sites that I'm rebuilding the Russian Hatch, depending on which approach that I use. The latest, it's been analyzed this place in the context. Going forward, how are you kind of looking at daily release performance and distribution or performance concerns with a fresh hash? And is there any way that each individual's selling preferences, like any kind of selling part, you might find them or might approach a better performance She wants us to fight. I gave a good response to that at the panel side. I think with all of these land rules, the actual land process itself is a necessary step forward, so it's like down for letting people add as many things as they want them to make the site a little bit slower. I think the cool thing about panels though is that because each of the particular things are sort of themselves entities that can be hashed and sort of dealt with this way, panels have a lot of really great stuff on the back end, so you can actually set specific caching rules per individual item on the page. And that can be great if you've got really intensive piece, you can just throw out the five minutes. Simple caching on it, you can set it up to use in the inside modules, or use the inside advantage on it, or you can even make your own sort of caching system. I'll take some point forward. Panels that have a quadruple caching system and set default caching rules and comp for every item in the system and activate your site a little really fast. So I would say in the context world, generally I don't find a lot of performance issues from context because the number of variants that you have when you're using that system is typically a lot smaller. So from my perspective in a panel world, you might have something that you have to define for every page on your site, for example. If you have a lot of pages on your site and you have a lot of things to define, if you go to cache, there's a lot of things to relate and that kind of thing. Whereas in a context world, it's typically more of we have a couple of rules that are defined and there's some total of rules that have to be reloaded when something is when cached is cleared is less than the sum total of things that have to be reloaded than panels of, for example, when cached is cleared. So I would say I think I always kind of think of it as context is kind of a database normalization of your rules, but it's very constrained, right? You can't vary from the normalization, right? So if you use context in the user system like context field, which can create a context for every single content item on the site, then you've basically got all of those rules for every piece of content and you're in the same situation that you would be in, sort of in a panel world and not in from my perspective. So really it's how you use it is really how I find context in a way the page is being cached at the front end, sort of alleviate, it gives you time to sort of rebuild your caching and that kind of thing. So yeah. Was that question to Christoph as well for this place to me? Yeah, kind of everyone. It was okay. If they want to answer it, if you don't, it's cool. No comment. When it comes to Temple Field, because it exists as a field that, caching is done at the node level typically, where you could definitely run into issues, I would say is when you start embedding blocks or things into WYSIWYG, so in the examples I showed before, we lean pretty heavily on WYSIWYG and embedding things in blocks. When you do that you have to clear it, when you make a change to say then a beam or your block, you have to be fairly aggressive in the caches that you clear because it may hit on any number of pages. So there's definitely challenges there, but typically if you're not going for that level of reusability across things, you're not embedding blocks or something into your WYSIWYG, it's a very scalable system, not to brag too much or something, but the Robin Hood site has seen traffic spikes increases of over 100 times in the course of an hour, traffic spikes from actually just the other week we saw a 19,000% increase in concurrent users over a few hours. And we were making content that they've seen at the same time, and it was cruising like a boss. All the displays, regarding the displays, the displays we saw is really fast. It doesn't actually do that much, but it's also template file and then just some stuff around. The biggest problem that you might see is actually the problem core we feel at night, which we are actually heavily working on. We added some performance issues and patches. It's now in the latest Google 7, and also in Google 8, we actually moved some information from field format or settings to a new big entity, which is called the entity display, that object actually knows what it has to render, which makes it popular. And it actually espouses we banked more, we had to bank more everything right now in Google 8. So it's usually a combination of too many fields in your Drupal installation. If you have, I mean basically, if you have like say 100 fields, don't do it. It's Drupal is not built for that, which is sad in a way, but yeah, that won't work. Cool, next question. One use case that I've seen for people that use organic groups and want to delegate the ability to handle layout, and I'm curious in terms of what different recommendations you guys have for your various solutions, which of them work well with that kind of, with that kind of access control approach and which would you recommend basically find somebody else? I can answer that for context. So context is pretty much an all or nothing approach out of the box to layout control. So if you've ever reached an edit point context, you haven't reached an edit all the context. So in a situation where you wanted to give someone layout control and you were using context and you needed sort of segregated ability that I would say it's likely not the best choice for you to start with, you can certainly write some pieces that insulate someone from getting all the way to the background and give them access to the inline editor, for example, that I showed and couple that with some rules to basically say this context is available in this group. This context is active for this group and that's the only one that they can see. The out of the box permission control doesn't naturally lend itself to... I'm sorry? Is the context an entity? No, the context is a... It's not described to the interviewer. It's SQLs. Are they SQL supportables at this point? Yeah, yeah, good on you. In the panel's role, there's a model called rightful OG panels which adds a new access permission for OG's OG group. They give it to the ability to change tasks, which works really well. That's 36, and for 37 you can, using a manager, you can set up a pretty great way to sort of use that IP to a lot of the assembly and only give it to... You can just analyze it and say, here's the OG mail, and you can change it right out if you are at the ability to edit a note that you should be able to do with its own access rules. And the open atrium, the new version of the atrium for 37 uses sort of a code like this. So you should check out that and see how it works together. And it works pretty well. It gives the people there the notice of a change of landscape on the tool section. Okay, I'm going to... That's the right assumption. Temple Field doesn't have any direct integration with OG right now. We just have a run into that. You should take a look. Because it exists in the field, it would be interactable in the same way that it would control field access through OG in other ways. There's also ways to walk down permissions for who has access to create or use particular layouts. So you can restrict that by role, and so adding an OG access there wouldn't be a particular... I'll be answering another question at the same time. People often ask me whether we at work use panels of Paint Manager. We actually do. And what Matt just told, we actually do that as well. So we use Paint Manager and panels to use and control the big components on the page and have variants and stuff like that. And I mean this like we just were like there was little content in it. So, but DisplaySuite itself does not know anything about OG. It shouldn't. It just has to know anything. It's something about entities. That's it. So, next. This is exportable features. This is the way around we need to export our layouts to code. So to me it's important to know. Does DisplaySuite, does SingleNode, and does panels allow you to export all of your layouts completely to code instead of just in the database? Is it just because they're fields or...? Yes, the settings in DisplaySuite are actually also sealed with exportables. So one of the things that people usually forget there are a couple of settings that are also encoded. But you can use strong app, strong app for that for instance. So usually they can get like a little variable called field settings and something with deep modes as well. And then I get a question and I don't export it. But yeah, all the rest is exported. It's a very big little variable. Yes. Template API is built API first. So it was actually designed to be written in code the first time, like from the beginning. So yes, you can put everything into code and then it's also available if you build your layouts in the admin UI. That's the Ctools.export UI. So it's... There's Ctools.exportables, so you can... Yeah, and then the house layouts, like I said earlier, they can be used in a little bit of a way. There are Ctools that allow you to build it in UI. But those are exportable too. And those are exportable too. We all want Ctools.exportables. Yeah. But if you put panels around your work on something like node, there is a magic variable that you have to export for that to some long name thing with a handler in it somewhere. It's a total pain, but you should be able to find it in your editor. My question is very little complicated. I'm not sure about it yet, and I'm just absorbed very intrigued by translations, which came up quickly earlier on and did a really tough job. So I'm going to ask a very stupid question, which is, your thing doesn't actually take information and translate it right? You know, it's like Google Translate, which translations, if you sort of have to hire people to remember to do good, what do you think? Welcome. You get to be magical. Yeah. Yeah. Yes, there's no magic translation. No magic translation. I'm not sure I should be talking about this. I don't know what someone who is. What magic translation stuff? So maybe come talk to Chris afterwards and he can point you to someone to go talk to. Maybe I can. I don't know. I don't know whether I can or not, but I might be able to. Well, we took some of our text, so we dumped it into Google Translate, but that's Korean. And then we took that Korean and we put it back and translated it back to English for- That doesn't work well. It was the most nice thing that- Well, it's really funny. It's entertaining. Very annoying. Yeah. Mad moves. Yes. So the tradition I've been in, to be a fan of Google 7, and I've started getting the feeling I haven't gotten as much love as it might deserve, and I'm wondering if it's a current state. Sure. So the current state is, I commit as many patches as I can, as fast as I can. The beta state of it, there's a D7 stable release tag on a couple of issues, and they generally center around multilingual and internationalization and international translatable blocks and that type of thing. And the reason I haven't moved it out of beta is simply because I'm not confident that some of the API bits of context are going to change. But if the fact that- The version still be alpha. Yes. But I would say if beta is what is stopping you, I will cut a release candidate or a stable and just make any changes to the 2.x. I mean, we use it on production sites all the time. You know, I'm obviously a big fan of context and the beta is kind of a label to me. But I mean, it's stable enough for production so I could make it a one point out if that's a concern to you. And how about the beta? I'm sorry? So usually I wind up with a couple of days on a weekend every couple of months and I'll be able to go and review all the patches and commit- They usually come in slots for me. So there'll be like 15 issues that I get to commit and review and that type of thing at a time. So usually it's when the next bulk window of time comes back to me is when the commit's happened and I try to cut another label. I guess I have some more comments and questions, but I'm not very aware of where the it's going to be pertaining to the effect. I think the presentation is going to be fun. I just want to bring it to the core. Obviously each one is going to be simple in these cases. So one thing that I'm kind of concerned about is from keeping the presentation a bit too close to the content especially if you don't think you can handle the work. My objective would be to set it as far as possible especially when we get into responsive design and we're concerned about how we can lay out the design or where, you know, any of the site that we want and is envisioning any magazine that brings people down to get into responsive. But not that any of these solutions can't handle responsive, but I'm kind of imprisoned by this mindset and I'm using the Historical and it's actually not anybody on this panel. No, it's not anybody on this panel. Yeah. We like DevC, but they squatted a namespace we already had. Yeah. It was hard to remember a person such as Addy, it was really there. They were competing. There's one study we could have worked on if we hadn't been talking to them. As for one going into court versus the other, that would have been going into court. There's a big difference between going into court like I said. The common one in getting out of here is no problem with that. We're just trying to figure out how to decide that that is not fully compatible with the court. Really a lot of the issues between the two systems have been in order to do full-on dates. We're definitely not going to establish age contacts. We'll see contacts understanding. We've already been trying to figure out how to do that formally. Each system has to know what they're all going to be doing. And basically they're going to be treating those foundations. So we're going to be taking the accounts from those foundations by building a shared foundation. We're going to put forward the responses on it down.