 Yeah, so let's go. So again, Boff is in Montreal from 215 to 445, and please fill out the survey. The button is already on our thing on the website, so hook us up if you like it. So I'm Frank Fabrero, I'm the CTO of Phase 2 Technology, the moderator of the panel, but I won't be talking about any particular solution. One of the things that I'm very interested in is how all of these solutions fit the problems that my company has every day, and even though some of the folks talking are from my company, that's not to say that that's always the best solution, so I'm really interested in seeing what else is out there. Hi, my name is Neil Hastings, I'm the software architect for Phase 2 Technology. I'm going to talk about the single-page node approach, basically this is as much core as possible, so my mantra is use more core and use less contrib. So my solution is, relies on several contributory modules also, but use more core with a couple of tricks and tricks. The bean module, which is a way to do block entities, a block references module, and a template field module, the primary modules that I'll be using showing today. All right, so my name is Christof. I'm also known as Swental on Tripolador and on Twitter. I am the elite maintainer of DisplaySuite and also a co-maintainer of the field-drew module, so there's a lot of reasons that why we have written DisplaySuite. I will talk a little bit of that when I'm going to give the demo, because it's obvious when I'm going to give the demo why I've written this, so. I'm Chris Johnson, I'm a director of engineering at Phase 2. I'm going to be speaking about context and how we use it for layouts, even though the origins of context weren't really to solve a layout problem. Primarily just the context module, which comes bundled with three other modules that we'll go through, and then I'll give some pointers as well to other modules that are a little more layout friendly. Hi, my name's Matt Cheney. I'm a Drupal developer and Drupal distribution specialist at Pantheon, based in San Francisco, California. For a long time, I've been really into working on the panels module, and then more recently the panels IP and panelizer module, and I'm going to try to convince you today why those tools are really awesome. And recently I've sort of tried to bundle all of those together into a standalone distribution called Panopoly that sort of takes the best of the panel's worlds and puts it together so that you can download it and have like a pretty awesome solution in one place, and that's what I'll be doubling today. Well, that's way over there. Hi, I'm Chris Vanderwater. I'm actually the Drupal 8 blocks and layout initiative owner, and oh, thank you. And yeah, I'm here mostly just to kind of answer questions that you might have about core in relation to these things. Largely, my objective is to kill all of these modules. Yeah, we're going to roll into the demos now. Each person will get about five minutes, and I'll try and stick to that time. Five minutes to talk about how wonderful this is. So live demos, nothing will ever go wrong, I promise. So I'm going to, in past demonstrations I've talked about the bean module. So today I'm going to focus a little more on the template field and how it controls your layout. Template field module came out of a project we're working on where everything needed to be revisitable and translatable in the UI. So everything really much had to be around nodes. That's the only thing in Drupal 7 that was revisionable out of the box. So the template field module basically turns templates into seed tools, exportables to allow you to export them. You can have them in code and files. So examples of, here's some examples that I have pre-built. So a two column layout, three column layout. You can have a carousel sort of stuff. The actual page itself, we actually use a Mustache template rendering engine. That rendering engine is swappable, but we're using Mustache because that's what the editorial people seem to like a lot better than using the Drupal way. So that allows them to end the UI to build inversion layouts and using Mustache and a lot of JSCSS and any Drupal core libraries to that page. And then we also have the ability to build out the input definition that the editorial team were actually used to fill in this information. So this puts a lot of control in the UI as far as exactly how you want things to display. So this is a quick demonstration, the module's template underfield, which I could have you want to. I think more version alpha 50 or something. Never have the lockdown of the API. Okay, so this is basically what it looks like, the constant editor. This is a reusing template field here. And down here we're using something called formatter field. Formatter field module integrates the template field module. Allows you to use templates as a formatter. So this actually controls a formatter of a field. So you can actually do that on a note edit form instead of in the field UI. So this gives a lot of control over how things are displayed. So the real use case is with the editorial staff, it's extremely highly customized pages. But you don't want to do a whole bunch of one off TPO files or different layouts discussions. And you don't want to use panels. So this is because your panels can do all this. So for example, they have the selection to choose different layouts. There's a lot of configurations here. So you have some basic ones. You can get more complex to do layouts that have images, background images. I'm going to try this and hopefully this works well. I won't use your images. I don't want that picture. No, no, no, no, no, no, no. I'm going to show you what it is. That's for different demonstration later. Okay, so we have the ability to do really, really highly customized templates. And so this is the example of a screen a content administrator would use and not something who's a site administrator. The site administrator are the ones that do the templates. And so this thing, you have all sorts of options. These are all built out in the input definitions that I did before. You can have all sorts of stuff here. I don't know what half this stuff does. I didn't build this one, but white. All right, good enough. And you can add multiple items here. One of the really cool things about Template Field is if I want to add another one, it's just a basic. This is just a basic content. You have the full WYSIWYG, so you can do things like embedding content, embedding nodes, or anything you do in a WYSIWYG you can do in here. And that's really what, in the project we use this on, we're really taking advantage of everything in the WYSIWYG that we can. That's really her piece. This format, what she allows you to do is we have a template called carousel that can be used with the format. So what this does is it takes each of the items in the different layers here and adds them as a slide on a carousel. And we're going to try that and see how awesome it works. So we're just going to use the defaults. No, this didn't work before, so we'll see how it works. Oh, page title. Hi. And this is the page title. And the last thing on the node page I'm going to show you, this is the block reference module. So basically, this came out of the integer.gov project. We use this really heavily with the bean module. It's the U.S. Department of Energy to be able to place blocks in the content wheel in different spots. And there's a lot of presentations on that already. I don't want to spend time on that today. So this is awesome slide, and I'm guessing it's not going to work. It's not going to work. But it works on our project, I promise. I'm almost out of time. That went really fast. Thanks. Have a good day. So this play suite. So there's a lot of reasons why we have written this play suite. I'm not going to name them all, because it's impossible to do that. One of the things is that consistent markup for all your nodes or users or whatever entity that you have in your Drupal 7 website. So that's really reason number one, because in the past what we did is like, OK, here's a node TPL. Let's change it a little bit. But then you have a listing of, say, your articles. Then you probably do that with views, right? And then you get different markup. So it's easy to change that. But by default, the markup is inconsistent with all other solutions in kind of a way. And we are trying to solve that, which is weird, I guess. But to go to the demo, so for instance, if you go to structure content types, you get two things, manage fields and manage display. So manage fields is where you're going to add new fields onto entities. And then you also have manage display, which by default does not do a lot. It only lists all the fields that come from field API. That's basically the only thing that you can do. People, for instance, miss the title field. They can't track the title field around here. That's impossible. And it's by default hardcoded in the node TPL. That's basically where we were like, man, this doesn't work at all. We want to try and make sure that field UI becomes a little bit more smarter. In that sense, we're going to add more fields, more properties that are on the node, for instance, a title, a author, a, there's a lot of other things. And also the ability to just inject any kind of property that you can think of. You can create new fields in code. They come into a field UI, and then you can do whatever you like. So also it's to be like have a central place for your entity thing. So the way that we work basically is we use page manager to work on the page level. And the display of your individual entities is done for us at least in field UI. So basically that's the difference between how, well, other solutions work, I guess. So field display suite at this point, it's not enabled yet. So this is field UI how it looks like. I'm going to go to modules. And then the display suite comes with four modules. So the display suite, this is, you have mis-seedles. But I'll go on. So there's four modules. You have to enable the display suite core module, which will do a lot. And what it does for you is, come on, internet. Everybody stop using the internet. Oh. But I'll go on. So the core module what it does is going to enable you to select layouts for your entities. And also, so you'll be able to select a new layout. So we ship with a couple of predefined layouts, a one column, two column, et cetera, et cetera. And also we'll expose those properties like title, author, onto field UI. The three other modules, there's display suite extras. They contain a lot of nice goodies. But they're not in the main module why you don't really need to use them all the time in different projects, but we do. I mean, it depends on the project and the solutions that you want to have. So I'm not going to talk about the display suite extras because there's too many in them, but you can individually enable or disable things in there. There's also the display suite search module. Who likes theming search results? Who think it's easy? Nobody? Oh, okay. But it's kind of a pain in the pain to like trying to do CSS on search results. So display suite search will take over Apache Solar search pages. Also note sort of the core as well. And you will get pretty search results. You can put an image on the left and your body on the right and well, yeah, you can go nuts basically. So let's enable. Yes, that's good. All right. Okay, I have to go back to field UI, sorry. So I actually have to go to structure. So there's a new entry here called display suite. If you go over, oh, this is the display suite first version I asked for the second branch, but no problem. No problem. No problem, no problem at all. But there's actually two branches right now of the display suite. We're actually also having a sprint after this session to try and get a new release for the first branch and possibly a release candidate for the second branch. But basically they do the same thing, but it's more user experience things that have been fixed in the second branch. But the important thing is here, you go to layout, you get an overview of all your entities that are in a Drupal website. So you see comment, article, text on the term user. Basically, note is more important. We switch that in the second branch because if you have a lot of content types, your screen is going to be filled with common things for which is stupid. We switch that, for instance. But basically click on manage display. Then you go back to field UI and nothing happens. This is the number one issue that I get in the issue queue. I enable display suite and nothing happens. I'm like, okay, what you need to do is go to a vertical tab here and actually select a layout. So we ship with a couple of layouts. You can either create new layouts in your module or in your theme. So you can basically choose whatever you want to do. And so let's go select two columns stacked. And what you basically now get is what you see is the header, the left, the right, the footer and all the field API fields are here. And then you see all the other properties like the read more, use picture, links, title, comments and tags. No, tags is field API, field API, I feel sorry. But you can add more. And now basically what you now have to do is just let's move fields somewhere, right? For instance, this is a title. I can put it on the right. The display suite gives you the ability to add new properties and also to configure them. So this is the field, the title field. Do I want to have a link back to the entity? Say yes, which wrapper do you want? And this is also extendable in, it's extendable, yes. So that's basically what this display suite does from its core. And I've been doing this now for three years and in the beginning I had not so a clear vision on what it really did. This is what it does. It's an extension on field UI for triple core seven. To give you the ability to have simple layouts and more properties on entities. So that's it for my demo. So I'm going to talk a little bit about the history of context and then jump into the demo. So context first started in 2008 with the Drupal 5. And it had a little bit of work in Drupal 5, but then by the fall of that year it was actually moved into the Drupal 6 in terms of the version that it was working on. And I always like to describe context as a graphical interface for Drupal hooks. What it does and what it was designed to do was take a lot of the boilerplate stuff that you would use to do by hard coding some PHP code in a hook. And standardize the action that had to happen and extract the configuration part. So for example, if you wanted to do something where you would say that when a node is tagged with term X, I want you to put this block in the right rail. It would take care of the being able to say what X is and what Y is and you would never have to code all of the code to actually do the placement again. So sort of as a side effect of that, it formalized, quote unquote, the best way to do each of these particular little tasks, right? Because context underneath its core, for each plug-in, the plug-in says, hey, context execute this particular plug-in at this particular hook point. And that's how it actually operates. So once you were able to extract that configuration, then we layer a UI on top of it and basically get all of that out of developers' hands and into site configurators and site administrators' hands. It wasn't designed strictly as a layout tool. It's just as a side effect can get used for that. And I like to talk about it is, it actually has two functions. There's placement of particular items that it does really well, I think. And then there's other reactions that you can use for actual layout, right? So layout might be two column or three column or four column, but then there's placement of items of what do you want to go into each column under which particular conditions. And those are sort of two separate things in the context world. So when you enable it, it comes with three modules and they're already enabled here. But I'll run through them very quickly. The context module itself is just named context and it's the engine. It's what allows you to have plug-ins and that type of thing. So that's this one. You're gonna have to enable that one to get either of the other two modules. Context UI, much like views has an engine and a views UI. If you don't want your administrators to actually be able to change things in your context, if it's more of a mechanism for capturing configuration and moving it between sites and that type of thing, you don't need that enabled. And then context layouts is one of the layout systems that you would get out of the box with it. So once you have context UI, there's actually two places that you'll typically use this. And what I'm gonna show you is the dev branch of 7.x because we've just finished and committed a lot of work to some of the UI there. So this is your basic context administrative UI. You can come in and add new context. Each context is composed of a condition or set of conditions and reactions. And so out of the box, you have a set of conditions where you can say this one should be active. If another context is active, it should be active if this particular menu item, if I own this particular node type, there's all kinds of reactions that you can have, I mean conditions that you can have here. And then once those conditions are true, and you can say they can be true independently or they must all be true, you can say, well, what do you want to have happen? And the reactions, so the one that's placement is the block reaction. And this is the one that I find we must frequently use. And this is the one that you'll most frequently not use from this screen if you want it to be very user friendly for your users. But you can say, okay, I want this set of blocks and I want to go in this particular region. The layout one is also present from the blocks. So if you don't have context layouts enabled, you will not get, I'm looking for it. There's an option here for the theme, oh and this theme doesn't support the layouts, that's what it is. There's an option to say, I want this particular layout and that's based on whether or not your theme supports it. And if I have time, we'll go through that. The interface that most people, you'll want to use for placement is you'll come in, you'll choose configure layout from any block. You'll be able to choose from the layouts that are active. We'll hide that. It'll highlight all of the regions. You can say what you want to put there. And so I'm gonna say I want to put my puppies. So it'll put the block there. You can say you're done and that you want to save your changes. And now you've just manipulated that layout or the placement there. And once you have lots of different layouts, you can drag things across regions and delete the blocks and that type of thing. But that's the basics of what you get. All right, so I'm anchoring this four-person relay. So hopefully do a little bit better than the American team. Sorry. So I'm showing off today a distribution of Drupal called Panopoly. And it's, as I mentioned earlier, it bundles panels, panels IP, panelizer and a number of other sort of custom pieces together. This is an install of Panopoly right out of the box. I turned on the demo content modules so there's some content there. But the goal here is to try to take out some of the Drupal administration into site building and creating pages. Because if I have a Drupal site, one of the things that I want to do is add a page and control its layout. So to do that with Panopoly, you get two options to actually start to create pages. You get a content page, which is just a normal page node that's panelized using the panelizer module. And it gives you some extra options. And you have the ability to create landing pages, which are using Page Manager just to create a general page. So I'll go ahead and add a landing page and I'll just say landing page. And landing can be my thing and I'll add it to the menu. And that's all I need to get going. And now I actually have a page on my site that's in the main navigation, which is very cool. I haven't gone to the Drupal backend yet. Don't think I will. The cool piece then is then at the bottom of this page. And by the way, every page, there's a customize this page and change layout on this page. If I hit customize, I get to bring up what I believe is the crown jewel of Drupal, which is the panel's IPE. And it does you add like information, panel panes actually to a region on the page. So I can go ahead and I'll go ahead and just add a number of things here. These are using the fieldable panel panes module that creates entities. It's very similar to the bean module. But I'll go ahead and add a quick content list. We'll have it be content type, my content page. I'll throw three things and I'll show the teasers. Let's say I'll go ahead and save that. And now while I'm surprised, I have a landing page that has a bunch of content on it. So that's very cool. Now here's the really cool part controlling your layout. So I want to change layout of this page. What do I do? I click this button that says change layout and it brings up, I think we maybe are now up to 30 different layouts that are all like prepackaged with penopoly. They're all cross browser. They're all responsive. And they have a little pictures you can see what they are. So I've got this one, which is just a single column, but I'll go ahead and add a sidebar to the page. And now I have a page that has a sidebar, which is great. So now let's go ahead and add an image to that because I might want an image. So I've got this little widget here that says add image. I've got this demo image that I have, but I can go ahead and remove that and go ahead and upload one and downloads maybe. And I'll go ahead and add a picture of Mr. J. Batson who would approve of this demo. He's very into making pages. And oops, sorry. There's sort of this live update tool. It's pretty cool with it. So I'll try that one again. So what it basically is doing is creating like a fieldable panel pane like on the fly, which is sort of neat. So it'll auto update the image, let's call it J. And it's cool because I can actually upload it and I can sort of see it. I can make it reusable if I want. I can add it a link. I can add a caption if I want, which I don't. And I can go ahead and save it. And now if I save, I've got a picture on the site, which is very cool. Let's go add some more stuff. I'll customize this. I'll go ahead. I'll add a list of links. People build a lot of Drupal sites. You probably have like a quick links box that you do so we can add a link to Drupal. Even though I checked on my phone, it actually is down, which is sort of weird. Drupalcon, let's call this Drupalcon. And we'll call these links. And I can go ahead and add those. And now I have a list of links. And so I'm starting to make a page. Like, this is the kind of thing if you're like building a comp or doing Drupal, you'd be really interested in. So that's cool. Let's go ahead and let's change the layout again. So instead of two column, let's go ahead and add three column. I got a three column right there. Go ahead and save. Okay, three column. And now I can start to play around. And maybe what I wanna do is, I'll take this list of content over here, I'll put it in the sidebar. And it sort of condenses down so that has some cool responsive images. I go ahead and configure. And I got a bunch of options, because this is actually a view. And there's really cool views and panels integration because Earl Miles works on both and makes them talk together. So Panopoli sort of leveraged a lot of this. So instead of having a list of content, I'll maybe just do fields. And maybe I won't, maybe I'll only have two of them, let's say. And I can sort of see, I can save. And now I have that. Then the middle, I can decide maybe I'll make a map. This is the default for the Pantheon HQ. I'll go ahead and make a map. And now I have a cool map on the page, which is sort of nice. There's San Francisco. It's pretty hilly there, but it looks flat. Oh, they all go ahead and customize. Maybe I don't want the map, but I do wanna put the picture of J right there so it sort of like bounces up, which is sort of cool. Maybe I don't, I'll put it down there. I'll go ahead and add some more content at a list of content here. Maybe I wanna store this as a table, which is sort of neat. Maybe make the titles. Don't really want the image. And I'll go save. Now I have a list of table data, which is neat. Go here. Maybe I'll add some text. That's too much text. This is using a veggie lipsum, by the way, if you're a vegetarian and you want demo content. It's a cool one. So I'll go ahead and do that. And then maybe I'll go ahead and make a carousel. Those are sort of fun. So I'll go ahead and remove this. And I have a picture of Dries's bicycle, which is sort of nice. And let's see. If it's a little bit bigger screen, you can see them both at the same time, but you'll see the end result, which is sort of fun. Bike. And then we'll go ahead and hit save there. And hit save. And now I've got a page that I've customized and configured relatively quickly, which is neat. The last little bit is I can actually go ahead and you even can stylize these things. So I added all the Drupal styles, so we can make that thing blue. And now we've got a sort of page. And it looks the way it looks. It's using the Bartik theme, so it has those kinds of styles, but penoply will work in any theme, because all it's doing, saying this panel's does, is it just takes over the content variable, and then everything else is sort of as your theme is. So if you have an existing site, you can put this on, or if you're starting a new site, you can put it on. But the cool bit is that this change layout is true. On this page, it's true on the default homepage that comes with penoply, so I could change the layout here. It's also true on every single node page. These are node pages. There's a default that node pages have, but you can override them per node, which is very neat. And I think this is a really neat solution, because it gives you a central tool to create really powerful landing pages. And not once do I go into the Drupal backend to do it. So it's the kind of thing as a site that is really fast, but it's also the kind of thing for Drupal product, or if you turned it over to someone that you could have, and you can make a lot of really neat things. Thank you. All right, so there won't be a demo of any D8 stuff, because it's still in development, but. If you want to see a demo, come to my core conversation at the end of today. So we're gonna, I guess, transition into a Q&A period, so there's microphones, if anybody has questions, stand up. But in the meantime, as people are getting to that, I wanted to ask each of the people on the panel a question. What are some sites out there that we might know of that are using your solutions? So energy.gov, which is the US Department of Energy's website, is what founded the Bean Module initially. And Robin Hood was the foundation in New York City. They actually, they're using template field and actually displaying SVG files for have dynamic graph LJS driven by content, which is a really, really cool use case. There are several more, but I don't know, I'm sure. I think, I'm sorry. The first version of this place we, that's actually still running from like three years ago, is on a website called Studio Brussels. It's a radio station in Belgium, so if you're from Belgium, Studio Brussels actually runs the first version of this place suite. And it then was basically our test case, because Studio Brussels has, I think like 25 content types, something like that. So it's a really complex site regarding content. And at some point, we were just like doing old style theming, and we had a lot of template files and that got really, really messy when we had to do updates during development. It was just crazy. So I think you're always to brew.be. Have a look. It's the oldest version of this place suite actually running, so great. I would say pretty much any site that phase two develops is probably using context in some form or another. Not all. A lot of the sites that phase two develops uses context in some form or another. Not always for layout. Probably the easiest way to see it is to just download Open Public and take a look at it. It uses context pretty heavily in all but one particular little area where it uses some panels. So that's probably the best way if you wanted to play with the approach that context takes to placement of the stuff to create it. Panels and Panelizer are obviously very popular modules. Have 100,000 some installs across a lot of sites, probably a lot of people in this room. Panopoly is relatively new. It's just in beta five as of this DrupalCon. But one of the things that it's really good for, aside from just building general sites, is it's a good sort of base distribution for other distributions. So there's a higher education distribution called Open Academy that has a lot of like sort of higher education university style features that's based on Panopoly. And the University of California at Berkeley uses that for a lot of their sites as sort of a solution to let individuals sort of customize their sites as higher ed workers. If you're interested in trying Panopoly, of course you can download it from Drupal.org or on Pantheon, we let people spin up free sites to play around with the approach and you can play with the demo content and do the kind of demo I showed today. So, just to see in the audience, how many people are using panels or have used them before? What about context for a block layout? Display suite, template field, beam, that's sweet. Right on. You guys are elite. Very cool. So can you talk a little bit about Drupal 8 and kind of how you plan to kill all of these if possible? Sure. So to some degree here, we're obviously running up against time issues, which is always the case when you're working inside of core development. But the real objective is to kind of take basically what Matt demoed and get as close as we can to that within Drupal Core. It's a very powerful solution. It gives us the ability to essentially change layouts on every single page throughout the system as we have to need. And that's really important from supporting install profiles and really giving people what they want, sort of a perspective. As to how I intend on doing that, at the moment, we've done a lot of foundational work and I'll give a huge update on that in my core conversation today. But we're really what we're doing is we're replicating a lot of the base foundational components that make up panels. So a lot of C tools components are actually migrating into core, things like plugins and stuff like that, that everybody was already using pretty heavily so it made sense for core to support it. And then, as you'll see in the demo that I've got today, there are a lot of specifically modules that phase two is currently developing that even if we didn't go any further than the patch I'm gonna show off today, we could kill off three of the modules that they're having to maintain currently because core would be capable of doing most of that stuff. Which I hope we all agree is actually a good thing. So I think they agree with me so I don't really care. So yeah, I mean, we really aren't at the, even the panel's level of doing things, much less like a panel's everywhere, panelizer solution, but we're working really hard to get there as quickly as we can and obviously we need more helping hands. So if you're interested in that, which I sort of assumed that you might be if you're in a layout session, you should talk to me and we're gonna start really trying to organize what needs to be done there, so. Well, thanks. So one of the problems that a lot of our clients have is that they wanna be able to see what their layout changes are gonna look like before either before their site users see it or they wanna be able to stage these changes and allow it to be previewed by other people in the organization before it actually goes live. So a lot of ways that's handled is through the use of revisions. Do any or all of these solution support revisions? Yeah, a panelizer will do revisions. Panels itself won't do revisions, although there's an entity revision scheduler module that'll help to do some of the sort of like sub revision support. But that like a lot of the way that Panopoli sort of helps to accomplish this is by letting you sort of drag and make changes on your site. But everything I was showing if you, there's like a safe button at the bottom if you decided to hit cancel, for example, it would just revert to the way it was. And that's sort of a way since you get to see it with the CSS and see how it looks that you can just revert out if you don't like it. Yeah, one more point on that is that panels in general kind of supports the ability to build variants of pages. So like you could probably, if you needed to have some sort of mechanism where you actually build it for a specific variant for people so that they can look at it once they approve it, you could clone that out to the main one or something like that. I don't know how that would work with panelizer because I haven't messed with panelizer much but at least for like kind of a traditional panels approach that will work as well. For context, that's really kind of dependent on how you structure the activations of your context. So if you use context that are set up to activate on the particular value of a field, if you're using like context node or context entity field or one of the other modules that offer those types of conditions, then yes, it would support revisions in that mechanism because that value of the field will obviously be different for the page that you're on there. And that of course assumes we're talking about node pages and that type of things. For things where you might wanna stage changes in terms of placement on like a view page or that type of thing, you'd have to go through some a little more customization there since there's no real underlying revision to the view. I think, I mean, this placement doesn't do content. I mean, I think Panopoli does a kind of mixture of it. And this placement only does layouts. And I think every module here is like dependent on C tools and has exportable support by default, which is good. If you don't do that, start doing it now. But basically, if the client wants another layout, then you can just make your changes on your dev environment, then run the exportable thing that C tools does, then put it in your repository, go to staging do, well, and then basically revert it, or update or revert the exportable, which has the display settings in them. So that's basically how we are doing like previewing or making changes to websites, I guess, so. But I think that applies to like every module in a way. I think. Hello. You guys can ask questions too. Frank doesn't have to be the only person. Sure. Yeah, there is a mic. Yeah, there is. Please, ask questions. Yeah, so since everything that my solution proposes around the node, it supports anything that's under revision. So that was actually the reason why we did it in first place. So for instance, workbench, any revision scheduler or state machine, all those modules control workflow around the publishing of particular revision. As far as previewing content before it's live, that's actually interesting because we actually, this question is not staged, I promise. We actually just built and released a module called Site Preview System, SPS, which is built part of the Large-Scale Drupalin project that allows you to take node revisions and stages them to be pushed live on a single site, and also allows you to preview any revision based upon a collection tag. So for example, so for example, we have a, you're doing an election results of Ronnie versus Obama. Obama's gonna win. And you wanna stage all your content on your site and you have the same page. You're using a page node layout. We're all using page node layouts. You want different revisions of that layout. So even using context in the context field module, which is actually now supports revisions. I don't know if you did that or not. You did that, okay. You can actually stage layout changes on the fly. Using this module with any of these solutions. And X works with panels also. We've actually tested it with panelizer and it works great. So you can display entire site like it's gonna be live at a certain point in time. What's not necessarily related, it is related to your layout as far as all these solutions support it because they are based around content, which is how you get revisions. Microphone. I'll repeat it. So the question is, as a non-technical user, how would you go about making a decision between these four solutions? Just use this place. No, I'm just kidding. Yes. I don't ever think there's ever a single solution for any problem. Because I think that's closing off all your options. If you always say one solution always fixes a single problem. All these have wonderful use cases. If you're building a site where it's, there's a short development period. The solutions I have proposed are mainly around higher development teams and larger projects. So we have a lot of customization, there's a lot of code still behind it. If you want something that works great out of the box, Panopoli is probably the best solution for, which just to throw up a quick community site or something, I think they're probably a great solution in my opinion, in context as well with some of the distributions we have out too. But it depends on how much development support you want to do. If you want to do a lot of development support, you want a lot of control, you want, I would say use mine, but I don't know what these guys say. Yeah, it's a tough question. It's true. I mean, yeah, I mean, there's been like in the beginning in this place where it was released, there was like this thing, hey, this is panels. I mean, or this is going to be like a competitor of panels, which is actually not true. I mean, the only two people at that point that understood the exact difference at that point was Earl and me. And everyone in the world was fighting against, I mean, fighting, hey, I used panels. No, you do have to use this play suite. No, they're doing the same thing. Actually, no, in my opinion, panels is a layout builder. And then you have all these kinds of solutions like page manager, and it uses the panels layout builder and to use, to create layouts, I guess. That's basically it. And this play suite is, I think one other key difference, I think, is this play suite doesn't work or act on the global page level, I guess. I mean, if you have an entity, which, I mean, for instance, if you look at Panopoli, you can drag in a node in your right sidebar and then select view mode, like create a new view mode called sidebar, and then the actual display of that node in the sidebar in Panopoli or in panels, that layout you are going to configure and on the entity level thing. So that's the way that we choose, but you can really use them together, I mean, and. I would say to kind of answer the question between all these, it really depends on who's gonna be building your site out. If developers are building your site out, you might wanna use a more developer-centric tool like Template Field and Bean. If you want just regular kind of traditional webmasters to build out the site, I mean, a lot of the tools that come with Panopoli look really, really easy to use for those people, so kind of evaluating who your user base is another step. Yeah, I was just gonna add that Open Academy actually uses both Panopoli and DisplaySuite to accomplish its sort of custom design, because DisplaySuite's great for creating these custom-rich view modes, and then Panopoli lets you, as Central said, pick the view modes, and that that's a great combination to implement a complex layout, but still allow for a lot of end-user customization. But I think the answer to the question, I mean, it's gonna depend on your use case and depend how much end-user interaction you need after the fact, and also what your team knows how to develop against. These solutions all have different, I mean, if you know how to do panels and you're into that, it's a lot easier. If you're starting off new, it's really complicated. Panopoli helps to get you a certain degree there, but if you know context really well, you only have X time, you need to develop the thing, and so if you know the tool you know really well is sometimes the best tool, although hopefully it'll all change for a D8. Hopefully. So having done, like I've used, I haven't used every single one of these tools, but early on in context's lifetime, I used it and panels together a lot. But I think for me, at least, the answer to your question is that you use the one you're comfortable with. What you really need to do is you need to invest in one of them, and the investment is different, right? Like context is very capable. If it serves like 90% of your use cases, maybe that's all you ever need. You write out the template file for the other 10% or something. If you fundamentally need something that's like it's a lot more to learn, but might give you a bigger payoff, maybe go and you learn page manager and panels, or something like that. And each one of these solutions has their up and downs. And it's really just about investing in one of them, I think, and kind of going forward. Obviously in Drupal 8, we want to kind of unify that so that everybody can invest in the same one, but. Yeah, sure. Hi. I'm Sam, I maintain panels. So I would criticize panels for a minute here. There are, there are, one thing that actually hasn't been mentioned in the scope of this discussion at all is one thing that panels provides that others don't, is a framework for caching and scaling that the other systems are not interested in. But God, this is far as I know. But it provides hook points for doing granular caching of selected elements in a way that none of these other systems provide. So if you need to design, like if you have needs for doing some more high performance stuff or saying, we've got a really expensive view over here and you know that views caching itself is problematic. Then you might want to look at doing, you might want to look at using panels simply for that reason, that in addition to being a layout builder, it's also a display framework that allows for the granular caching of different parts of the page. The drawbacks, since I said I was going to criticize, the situation that I tend to see happening on a lot of client sites is people build out, they'll, they'll, you know, they'll add a new custom page here, there, and then they're like 15, 20, 30 variants stuck on that page. That is an unmaintainable situation. So you might want to consider not using panels or a panel's page manager approach if, wow. If you're likely to, if you're likely to have a lot of variations that would result in just, you know, like one or two off tweaks that actually, that type of thing, you're probably going to be able to handle a little bit better with context because you can get yourself into a really untenable, unmanageable situation with giant numbers of panels pretty, pretty easily. So. Thank you. Another question. One more thing real quick. Yeah, just, I'm sorry. We aren't, we aren't discussing it because none of us are necessarily experts at it, but rules module can actually place blocks in regions as well, just FYI. I just quickly wanted to second on the comment before because like you can push in the content very, very nicely with context module, but in panels you just have, you have to create another variant for every like thing that's a little bit different. And I wanted to see what other plans for Drupal 8 for those different approaches. So there are like, that's a very nuanced question and the answer will be nuanced as well. The panelizer actually buys us an awful lot there because like the way it approaches quote, unquote, variants is totally different. It determines it through, you know, there's actually just like, if you actually look in page manager, there'll be a panelizer variant that sits at the top of any of the places that can be panelized and it makes the decisions before it routes off to any other variants. So hopefully that significantly reduces the number of variants you need for nodes or users or anything like that. And then if you've used panels everywhere, panels everywhere also has like a separate page that just is the default one. If there is no page, like no layout specific to a particular URL. And so like it's the combination of all those things together that can significantly reduce the number of variants you actually need on a page by page basis. So like we fully admit that it might be an issue. The other thing to consider is that the router, if whiskey delivers everything it's trying to deliver, the router will be a lot more capable and nuanced as well. And so we might even be able to remove, say if you had node type variants, you know, one for page, one for article, one for image, something like that. That might actually be up a level and not on like a node percent node page. There might actually end up being specific pages dedicated to those because the router can determine that information earlier. I don't know how that will shake out. We kind of have to figure out where all the connecting points are there and leverage it appropriately and that's still all in development, so. Any other audience questions? Yeah, go. Yeah, sorry, can you hang on to that? I just wanted to tag on the response to the last question. I apologize. Fundamentally the problem with panels is that yeah, you create a new variant and because you've got multiple layouts being used all over your site, whereas most of what we do in Drupal right now is we have one layout that we bend a lot. I believe that's Earl's way of describing it. I have not given up on the idea that we're gonna have a system for doing more global injection. That's more like the blocks interface right now, so we'll kind of get to have our cake and eat it too. I don't think it's impossible, it's gonna be tricky, but that will be the thing that makes it much easier for us to not have to just spin off tons of new variants. You globally configure, this block is gonna show up on a bunch of these pages, and then you've got all the full local control over the panel that actually runs, or the panel-y thing that actually runs that page. So the question in the back? This place of the similar for node edit form page. So the question is, the question is do all these solutions have ways to modify the node edit form? So, yeah, actually, the template build does. I showed building out the input definitions. Those actually build out the node edit interface. So those are on a per template basis. So yeah, it does. We know what this place looks like. Yeah, I mean, I'll add an ID. I forgot one module that also ships with this place which if you download it, that is indeed this place with forms that acts on any kind of entity form in your Drupal 7 installation. I would say for context, it depends on whether or not you're triggering layout based on something attached to the node, right? So if there's a value in a field that you're using to say, I want two columns or three columns or four columns, then you just add that field to the node and you have a condition that watches for it and the reaction that takes care of subbing in a template or that type of thing. But there's not sort of out of the box something in context that's going to inject itself into node edit forms. The panels is really good for doing overriding of the node edit forms. And if you get into sort of real custom administrative screens you can have different node edit forms for different node types and actually drag and drop the fields around. Panopoly actually ships with this as the default node edit screen which is actually a two column panel but it can be extended obviously for different use cases. So this will look a lot like what it's gonna look like in Drupal 8 in terms of having stuff on the left which is sort of about your content and stuff on the right that's more sort of data about it. But this is something that I, when I was doing a lot of professional services would customize for every site just cause the Drupal node edit screen like honestly it's not that good. And if you can like actually just drag and drop the fields around in ways that actually make a lot of sense it's really powerful. And that's just to create a variant against node edit. And if you wanna see, Panopoly is an example of how to do one but you can extend that for any node type or any condition you want. Sure. I haven't played a lot with the Panopoly but is it right that since it's using fieldable panes that you store field data in a different way so it would be kind of hard to move back to the more standard way of managing fields and content types? The, I mean in terms of the Panopoly like a lot of the widgets I showed like the map and the spotlight those are actually fieldable panel panes which are just entities that have obviously fields attached to them but those are sort of in addition to the standard node types. Like this is just a standard node type title and body and that actually will work and can be panelized like that. The fieldable panel panes are more sort of additions for sidebars or other pieces of content. I wouldn't say it's sort of more of an extension to what you already have as opposed to replacement for anything. And on that topic we have every intention of putting that into core. Any other questions? We're just have a couple minutes left. And there is, if anybody doesn't wanna ask a question in the big room that we have there is the buffs that are happening. Yeah, so where are we doing the buffs? Off is in the Montreal room, immediately following this. That is, is that in this? Do we know is that in this build? It's in the other building. You didn't put the map on here. It's because we weren't using Panopoly. Drop the map. All right. I just got a quick question. One more question. So what about controlling layers in themes versus controlling layers in modules for those different approaches? Panels can do that. Yeah, panel, like you can define layouts in your themes and panels will pick those up or you can define them in modules. I don't have a strong preference either way. For context, the context layouts module is actually for that. So your theme would say I have these particular layouts and these layouts have these regions and that would be primarily the way that it interacts with themes. If you would like, if you are using two themes on one website and at this point it's not possible for this place we can say the view mode of this article looks like this on that theme and something else on the other theme. So that's not possible. It's also kind of a, it's a field API problem, storage problem, which I probably won't be able to solve anyway for triple seven. Hopefully Chris will solve that. I did also wanna mention if you're using a theme like Omega and like the Delta module where the theme itself has lots of settings for controlling the layout. Delta comes with something for context to control it that way as well. I don't believe in using themes. So. Shh. Somebody else's job, I'm gonna do no. In the core, it's core solutions and mine's around core so it's just your no TPL files. And using view modes a lot is a very big part of the, or my solution in the node is using view modes and TPLs are in the view modes really, so. Cool. So that's it, we're out of time. I wanna thank the panelists for being up here. Thanks everybody.