 This is Drupal 8, the panel's ecosystem. If you came to the wrong place, I'd encourage you to stay anyways. We're going to cover a lot of really interesting stuff. Who in here uses panels in Drupal 7 today? Hey. What about page manager? Page manager? Yeah, okay. Who's using any of those things in Drupal 8? Yeah, okay, fewer, fewer. All right, cool. Hi, I'm Chris Vanderwater. I am a technical specialist at Acquia. And I was the Drupal 8 Scotch initiative owner, which is basically the short name for blocks and layouts. You can find me on Twitter at Eclipse GC. And I'm the co-maintainer of Chaos Tools, Panels, Page Manager, and a handful of other things. Hi, I'm Jacob Perry. I'm a technical architect at Acquia. You used to know me at the Drupal Association as one of the lead developers, as well as I'm on Twitter, J.A. Perry. And I work also on C-Tools, mainly in Drupal 7. Panels in Drupal 7 and Drupal 8. Page Manager in Drupal 7 under C-Tools. And the conference organizing distribution. So I want to kind of address first things first. There's an awful lot of stuff going on in this space. And it'd be really, really easy to be super confused. So today we're going to do our best to explain a handful of things that should hopefully limit some of the confusion. And also maybe if you are of the type of person who actually files issues in the issue queue, give you a little direction of when and how to do that, instead of just like, well, I'm using panels, so it must be a panel's problem. So let's just go ahead and acknowledge how many things are actually in this stack right now, because there are a lot of them. First off, we have Chaos Tools, which basically everything depends on. This is true in both Drupal 7 and Drupal 8. Drupal 8 to a lesser degree, because much of that stuff has moved into Drupal 8 Core, but we still have a handful of things in C-Tools that we need, so the dependencies continue. We also then have Layout Plugin, which is a completely new dependency in Drupal 8, something that we didn't break out into a separate thing in Drupal 7. And actually, this is a really great point because DisplaySuite is using Layout Plugins, Panels is using Layout Plugins. There were times in the past where we tried to collaborate in Drupal 7 and it just sort of failed. And a lot of Layout Plugin originally was in Core, so the idea we were gonna put in Core and everyone was gonna use this and then the idea was, well, it's not really baked ready for Core, so we pulled it back out. Fun tool tip, I don't see a Philly hat here, but here rumor has it, we're gonna probably be seeing this getting close as the Blocks and Layouts initiative continues into Core. Yeah, so I think there's a very good likelihood that this might make its way back in in the near-term future. Panels, which is what we're sort of here to talk about amongst all these other things, of course, and then a handful of others. Page Manager, which is a separate module in Drupal 8 these days, as Jacob mentioned. In 7, it's actually just part of CTools. Who in here is using Panelizer? All right, I hope I get all of those hands up in the air by the end of this session today. Mini Panels, and yeah, who's any Mini Panels? Okay, you guys must be in 7. Panels everywhere, okay, few. Anyone in 8 using Panels everywhere? Good, that was a trick question. And then who in here is using Panel's in-place editor? Yeah, okay, we're gonna talk about this too. So let's kinda break down each of these. I wanna talk about Chaos Tools just a little bit. We're gonna give each of these a bit of definition so that you know what's in them. So in Drupal 8 and Drupal 7, Chaos Tools is really, it's just a library or a foundation of things that are really nice to have. This was true way back in Drupal 6 even. In fact, when we did the sprint to move from Drupal 6 to Drupal 7 and get CTools all ready for Drupal 7, I said, oh, I'll look at the form component and I found out that Drupal 7's form component was CTools 6x form component even down to the comments. So a lot of these things have migrated into Core overtime because they are kind of so fundamental. Okay, well, stuff that's incomplete and or missing from Core in a lot of cases. So specifically in 8, this means that we didn't get a form wizard into Core and there is one in CTools. This is redesigned from the ground up if you've ever built form wizards in Drupal 7 or Drupal 6 using CTools or Core. This will be radically simpler if you know anything about building forms in Drupal 8 yet. Field blocks. Field blocks did not land in Core despite my grand ambitions and so if you have a field that appears on an entity, you're gonna need some CTools code if you wanna break out those individual fields for placement via blocks. And that's a big part of the IPE experience. It is. As we start going into panelizer for those who are using panelizer. And you will see that today. Various views improvements and I'm not gonna like over promise here because we're working now like views is no longer Contrib, it's in Core, but some of the improvements we need are still in Contrib. So some of these things are a little helter-skelter. And this is why you're still seeing alpha tags on everything we're doing is because we're trying to push things in the right direction but there's a lot to do still. So we'll be sprinting all tomorrow. Please come join us and help. There's a lot of stuff that could be done, et cetera. Layout plugin. We've kind of already defined layout but to just get really specific about it, layout plugins are just a little bit of YAML. You have a YAML file to say, oh, I have layouts. And then some twig, some CSS and some JS. And this is really all there is to defining a layout that DisplaySuite and panels and all of panel's various sub-modules can just use. Who in here's ever defined a layout plugin in a previous version of panel stuff? Have you guys migrated those to eight yet? Tried? No one? No one? Okay, well, good hint, it's really easy to do. Heck, we could probably get the coder operator to do it. We could probably get it, yes. It's pretty easy to do. Yeah, if you go look at a good example is in panels, you can go look at the layouts we have there and then you can look at the layouts we have in Drupal 7 because the Drupal 7 will make sense to you and then you can see the differences and you'll notice there aren't very many. Yeah, other than the switch to twig and the switch to YAML, this is gonna look really similar to whatever you've done before. I guess there's a switch to libraries technically there as well. Has anybody worked with like the library API in eight? Yeah, a little? Okay, it's actually pretty awesome so if at first it looks sort of weird just like muddle through, it's totally worth it. Yeah, as Jacob mentioned, this is essentially what we built in and then removed from core because we didn't have a real use case for it in core yet. There was a lot of work going on and layout was kind of an easy part to get added but all the stuff that would have made use of it was difficult to get added and then kind of get staged in until much later. So layout plugin was removed mid-cycle just to keep things as clean as possible because we weren't certain we would get to a point where we could use it. But there are efforts to get it back into core and if you all would like to help with those issues we could point you at the issues in the issue queue. So let's talk about panels. It seems like we have a room of people who generally know what panels is but I'm gonna explain it anyways. And this I think is a critical difference in some regard from panels in Drupal 7 because panels in Drupal 7 wasn't just an API for sticking blocks and layouts. It actually had its own menuing system. It had its own weird backend to page manager where it would spend stuff up for you and you didn't realize you were interacting with page manager even though you were and that's all gone. All the scary things that you may have heard about panels in five, six and seven, pretty much gone, yeah, it's all gone. So it's definitely worth taking a different look if you've had that view before. Now we can talk about some scary things later when we get to page manager but panels in general is quite unscary. It is an API for putting blocks into regions. You can configure them and you can place them and that's really nice and straightforward. We do however have a bit of, I swear I changed that to say a bit, of unused code from Drupal 7 that's still in there that we're kind of pruning out. And five. And five. And four point seven. But with the switch to OO, most of that code is kind of just in an un-executed code path and we just need to identify it and remove it at this point. And so what that means is that panels module is actually getting smaller every day which is kind of a nice change of pace. Oh, well I did make it say a bit. Oops. There are a few useful sub-modules though. IPE is the big one that's running in D8. We have not ported mini-panels which has traditionally been a sub-module. We may choose to move it out into its own module though. And mini-panels, and I know someone asked about styles earlier this week. The styles plugin that you may have used for doing the different blocks layouts for what used to be panes, those are now into a new module. If you want more information, you can ask me about that later. And mini-panels, I think we pretty much decided that won't be in panels. So that's gonna be its own module as well. I will take this moment for any of you who are really watching, you may have noticed we didn't mention fieldable panel panes. It's because we're not gonna port it. There's no reason to. Content blocks and core is fieldable panel panes. So like done, that module's dead. All right, scary stuff. Let's talk about page manager, my favorite module in the world. Page manager. We have traditionally said that page manager is a user interface on top of hook menu. That is in fact what it is except we don't have hook menu anymore in Drupal 8. So it is a UI on top of your routing YAML file. So if you are building routes, need a route for my module, you've probably interacted with this YAML file. Well, there's a way to programmatically define new routes. Page manager does that. And page manager actually does that per page variant, which is super cool. And if somebody wants to see that, I'd be happy to show them outside of this. Well, it builds routes. So we've actually toyed with whether we should change the name to route manager, but we didn't. So deal with it. Page manager's less scary. Page manager is less scary. So an important thing here, page manager is not panels. There's been a lot of confusion over the many, many, many years of where to stick an issue. If you are dealing with page manager and you are not actively working on sticking blocks into a layout, you're in page manager, not panels. File the issue against page manager. If you're actively working against layouts inside of page manager, odds are it's a problem with panels. File the issue there. But we put stuff on routes, stuff like panels. You can also put a bunch of other things there. There's a module that I maintain in Drupal 7 called context admin that actually allows you to find completely new administrative elements. So you can go ahead and place, you know, things like a node ad page. If you wanted a node ad page for a particular node type, context admin in Drupal 7 layers on top of page manager to place that wherever you want. So you can do things like attach a create article page to your view of articles. So one click and I'm creating articles. These sorts of things are what page manager really excels at. So it's just a user interface on top of routing. You can plug different things in there to be configured and used. I'm gonna stop right there. I don't want you all to feel like you can't ask questions. Like this should be pretty interactive. So are there any questions at this point with regard to the data we've covered thus far? I should mention. Yeah, go ahead. Yeah, and use the microphones if you could. How stable is it so far because I had some nightmare troubles between moving between different major versions of panels in Drupal 7, which were breaking like all the variants that there were and a lot of trouble with it. Is it safe to use at this time? Depends on what element of it you're using. I think for the most part we've been very diligent about only making schema additions and making sure that our schema was very strict with regard to what we were building thus far. So the module most likely to have any issues on that is probably page manager. The other modules in question aren't going to really have issues there. In general, panels will have an upgrade path now that we're in beta, and so the schema's pretty much fleshed out. So you should feel pretty confident there. There's some UI tweaks that are still in the next beta that are supposed to be going in hopefully this weekend. So yeah, come on in. Find a spot. Yeah, so you should be here. You can't leave. You should be pretty good with that. I shall also mention something about page manager. There is an issue that people have had with routes in the old routing system in Drupal. If you had parameters at the end, people may have seen this where you could take those as arguments and then pass them to page manager in Drupal 8 because of the new symphony routing system. You can't do that necessarily. So it's going to be a little more tricky. It's something to watch out for as you're going through there. I know there's also plans for another rewrite of that, but it's further down the road. So if you're using page manager and you've been expecting to append anything to the route and you're having trouble with that, it is an issue, but it's not necessarily an issue in page manager. It's sort of a symptom of a bigger core slash even bigger than Drupal problem that we have. So getting hyper technical for just like one second, Drupal 7 and 6, their routing system used what they called a fit. And so the fit was used to figure out what route was the best fit to the current route that was requested. And so if you were in a Drupal 7 site, you may have done this at some point, you can just type like arbitrary slash something, slash something, slash something else onto your route and Drupal will find, like it'll ignore all that something, something, something junk and just go to the route that you're currently on when you do that. And Drupal 8 does not tolerate that in the slightest because symphony doesn't tolerate that. So don't try. Okay, so that being said, page manager is actually very close to a beta. We only have a handful of beta blocking things at this point, but we've been very good about only adding to our schema not altering the existing schema. So any sort of upgrade path there should be relatively trivial. So I would say in general, things are pretty stable from a schema perspective. That doesn't mean that we don't have the occasional bug that causes a problem for whatever reason, please report them. Oh, panelizer, okay. So I asked earlier and not too many people are using panelizer. So let's talk about what panelizer really is. Who in here sees display suite anywhere? Wow, okay, I was not expecting that. So panelizer integrates panels with entity displays. Very, very similar to kind of a display suite concept except it's like maybe the next level on above it. So that means that we can provide view mode defaults multiple. So if you want your full content view to have like two columns on it, then you can do that. If you want also an option to have three columns, you can do that as well. And then you can do things like expose those options to your client so that you have a list of controlled layouts that they can select between instead of just giving them willy-nilly control to do whatever they want. And you can do this per view mode. So that means that you can do something like actually construct a panel to be used for the teaser of a particular content type. Then if you go build a view of say articles in teaser mode, you'll get the paneled output for each individual one. It's super nice. It can also do per entity panels output, which means if you want node one and node two to look radically different, you can do that. You can even expose the in-place editor and let an end user or yourself, whoever's permission to do it, actually alter that page to the degree that panels can alter it. And now we get into the fun stuff. So this is true in Drupal 7 to a degree, but we had to really hack things to make it work in D7. In D8, it integrates with entity revisioning right out of the box. And the reason why it does is because panelizer is a field, well, it's a pseudo field on the entity. So since fields are revisionable, panelizer displays are revisionable as well. So if you have something like a workbench moderation, any sort of workflow, oh, did I just lose my mic? I think I just lost my mic. But if you have any sort of workflow, oh, there it's a, if you have any sort of workflow around revisions, you can actually use that with panelizer and have unpublished panelizer changes, things like change it from a one column to a two column, move this block here, change the configuration of that block. All of those things are actually possible in Drupal 8. There are a couple of caveats and we can talk about those when we get to the demo section. And it, I should also add that it's multilingual. You can sense entities are multilingual. It should work as well with that, so. Your mileage might vary though. So, mileage might vary. But it's- Again, file issues. Yeah, yeah. Oh, we should caveat. The panelizer is right now still an alpha. But it is being used in production a few places that I know of. Yes, it is. And it is pretty, it's working pretty well. But yeah, we do have some multilingual sites running. And we also have some workbench moderation sites that are running on it. Yep. So, mini panels. Mini panels are panels in a block. Pretty simple. We don't have anything going on here yet. I'm curious, anyone here using, or interested in using mini panels in Drupal 8? And Paul? It's kind of got a narrower scope. We could talk about like reasons and places to use mini panels. This is a module I think everybody using panels in general should probably adopt. It's really great for like repeatable things like headers or footers or sidebars, that sort of stuff that you don't want to do again. It can also be really good in scenarios like where you want to style a particular type of content in a particular way. Yeah, for example we have, if you're on Drupal.org and you go to the download page to download Drupal Core, that is a mini panel embedded within a page. So you can do cool, customized things on that display because that is the core display versus the rest of the contrib modules which uses just a view. You can pass different arguments because you get all the nice things of panel panes instead of blocks in Drupal 7 and the same in Drupal 8. So the reason we don't have anything moving on this yet is mostly because we've been really focused on the other foundational code that goes into this but I feel like we're actually pretty close. So a lot of the work that has gone into getting page manager and panels and panelizer to all play together nicely because we want more than one implementation of a thing has all largely been done and most of it's just like a foregone conclusion around finishing a couple of patches. So none of which really apply to panels itself because panels is working. So mini panels is probably something that could actually be started if anyone in the audience is interested in helping with that. I know that there are people who want to do that in general and I think we can begin moving soon. Panels everywhere. All right, so we asked earlier, can I see panels everywhere users again? That's I think more than mini panels. Panels everywhere overrides the block layout and the region system. So the normal block system that you use to put blocks in like a header or footer or sidebar of a typical Drupal site. Panels everywhere essentially completely hijacks that and puts a panel in place of that. So now you have a panel for controlling the Chrome of your site and this is super useful. However, we don't have it operational yet but the code path to make it operational was baked into core. So it should be something that can be achieved again once the foundational portions of panels are really ready to go. And I think it'll be interesting to see how panels everywhere evolves because in essence with the blocks layout movement in core there's gonna be a movement to basically some folks are talking about actually doing panels everywhere as like the foundation in core and all this stuff is still TBD but that seems to be the direction we're moving. And so it'll be interesting to see if we actually have a panels everywhere D8 module or a short D8 module and then like 8.4 will have like panels everywhere and then we'll be operating the core or something, who knows. I think that would be like our best case scenario but we need to get there and actually do it first to see whether we can even validate that interest and prove that this shouldn't move forward. So yeah, I already said that. All right, let's talk about the in-place editor. The in-place editor, we have a working temporary solution who's used it in Drupal 8? Okay, that's like four people. It works, that's good. Congratulations. Yeah, Sam Mortensen, he's an engineer at Auddez Law Front End stuff at Acquia and this was sort of like his playing around. He's like, oh, let's do this stuff and he made a really awesome proof of concept and we're like, hey, let's use this. Yeah, so it's way better than not having anything at all and it totally works. So there are, as with anything, a couple of edge cases that we're still hammering out and I think, yeah, so it's based on backbone.js for those of you who know or care about that. We are, however, kinda likely to replace it, yeah. Backbone's in core, which is the reason why we're using backbone. That's true. The idea is to try to have less dependencies, but yeah. So it is likely to be replaced. We have some issues running, which I'll mention here in a minute about we have some issues running on what we want to replace it with and just kind of visually trying to establish what we think that should look like, what a better paradigm is for user interaction there, but there's a lot to be decided yet, so for those of you interested in that, we are certainly still very much in the planning phases. And again, I think it's good to iterate since blocks and layouts are very close to where we're at. Right now there's the whole inside out thing going on and so they're essentially working on their own in-place editor, so there's a lot of conversations happening there. It's exciting stuff, but yeah, definitely join if you're interested in that space. Yeah, so as many beautiful flowers as I think have sprung up in this area over the course of the last couple of years here, we do have a few thorny issues still out there, so I just want to acknowledge that. I made mention of the fact that Ctools is attempting to do some things with views and I have a number of different issues around this because since views landed in core, changing it isn't necessarily something that we can just do mid-cycle. We can't say like, oh, well, Ctools can no longer do X with views, so let's change it. It's not quite that simple anymore, so there are a handful of issues kind of pursuing this. We want the ability to do things like used expose views filters as configuration of a block so that you could say like, mm, you know, if I have a view that can show pages or articles and I want to expose to the user, whether it's pages or articles they're looking at, I could actually show that in config of the block and let you know which you're gonna do at like administration time when you place it. However, the more of these exposed filters you have, the more hairy this issue becomes and views does things like grouped filters and date handles its code completely differently and so it's been a very thorny issue and some of the other issues that I mentioned here are actually things where like maybe that those operations aren't the same way they were in seven, they changed just slightly enough to make things more difficult or were introduced or that sort of stuff. One of the issues that we'll talk about, we talked about panelizer and how layouts and revisioning all play nice together and it's true, they do. The one big caveat to that though is when you place a content block, the content block is only ever referring to its most recent revision, therefore if you were to revision something and change the content of a content block, it will show on your live version even though you haven't published it. We have two issues outstanding, both of which are pretty small and minor that we could commit to panels and C tools respectively that fix this so that you can actually continue to edit content blocks in the revisions of your nodes and they move along with the revisions of your nodes so you don't see anything until you hit the publish this draft button. Panelizer view modes should support multiple defaults. Panelizer out of the box supports one default and we want you to be able to support more than one default so that you can do things like I said earlier, give your end users the ability to select between a couple of different templates while they're creating a node of a particular type. This issue is close to my heart. Well, we use it a lot in Cod and Seven and so we've been working on this in eight and my hope, I don't know if it'll happen tomorrow, I know this is one, I think it's too big for tomorrow. Okay, yeah, because I was thinking, I think this one is in Lightning right now, it's a patch. And so we're using this in some spots and hoping to get this one sooner than later. Has anyone used the different defaults in panelizer in D7? Curious what interest we have here. Yeah, since so few people were using panelizer. Yeah, okay. That's like half the panelizer people, there you go. We already mentioned that IPE is likely to be replaced here are some of the issues regarding that. So I'm not gonna spend any more time on that. And then an issue very close to my heart is that block selection could be way better. Right now when you're placing a block, it's just like a list that goes on forever and you scroll through it and click the one you want. You know, in Drupal 7, we had a block placement utility that actually categorized things and you could click through the categories and later we started adding search to that. This issue actually has a completely searchable, completely categorized version of all of the blocks that lets you dig through that stuff. It is not committed because it doesn't cover all of the use cases yet, which include things like creating new content blocks. It's not doing that yet. I would love for other people to help bolster that and push it forward. So obviously, I seriously doubt any of you are sitting there writing down node IDs. So if you care about these issues, find us afterwards and I'll make sure that these get to you. And there are lots of other bugs and features that we are in the middle of implementing and or stamping out, not necessarily in that order. So with all that said, I wanna talk about one other thing. I have not mentioned Lightning really up to this point. Lightning is an Acquia install profile that we are being very public with and public about. And so Lightning is, well, yeah, I'll point out this isn't a Lightning session. The problem with that, of course, is that it demos all of the stuff we're talking about and has most of the patches we care about actually applied. So when we do a demo here in just a minute, it's gonna be Lightning. So I say like we have production sites using the patches. That's what we mean, like anyone who's using Lightning will be using these patches. And it's worth pointing out the, you're gonna go look at Lightning and you're gonna say this is at a 1.0 release or whatever it is, it's a 0.0 release that's sitting on top of modules that are all marked alpha and beta, mostly alpha. And the reason they've done that is because they're committed to an upgrade path from Lightning to Lightning from this point forward, regardless of what the modules that they're depending upon are doing. So that's very, very brave of them. And I would encourage you to use it because I know that team, I've worked with that team and they're really, really great. So if anyone can do it, they certainly can. It's a great product. Yeah, it's a really good way to like keep, if you are using the panel's ecosystem, you can roll your own and try to manage it or fork Lightning and try to manage it. But really they have a dedicated team of people that are actually following these patches and not only in our ecosystem but in other Drupal 8 modules like Metatag had a patch. I think they're currently working on search to put that stuff together. Some things that are really daunting on their own, Lightning's really solved. So yeah, it's a good one to start even if you don't end up using it in the end. It's a good thing to take a look at to mirror your site as you're building it out and follow along with its path. It's also worth noting, who in here has ever built an install profile anyway? That's a good number of hands. Anyone in here ever wish that they could build a sub install profile? Yeah. There's a patch for it number one and number two. Lightning won't actually let you build sub install profiles but they do have a suggested mechanism for essentially building sub install profiles. So you can look at that and they're actively attempting to support that. So worth noting. But it's not as easy as just like my class extends that class and I wish it were. Yeah, we said that. So anybody want to demo this stuff? Because I assume that's why you're really here. Yeah, I picture me. Sorry. Okay, so what I have here is Lightning and we're just gonna go through and start like demoing a little bit of what we've talked about here. I'll start with like maybe the simplest and then move towards the most complicated for some value of simple and complicated. So we'll start out in page manager. I'm just gonna delete my test page and we'll start over. So who in here has actually used page manager to actually place a page before anyone? That's a pretty good chunk of people in D8. That's like 10, it's still pretty good. So you'll notice here as we write the paths in here, we can use those arguments. They take in those values and so that sort of solves part of the problem we've had before which is a cool part of a page manager. But yeah, you can't take additional arguments than the one you define. Yep, so yeah, we can define new arguments and you do this previously you've done this with percent signs, you'd say like percent test for something like that. In Drupal 8, everything moved to squirrely brackets so you say squirrely bracket test, right? And I'm just gonna put a type of panels here because we wanna see panels on the page and I'm not gonna check any of my optional features, we're just gonna keep running with this. And so when we do this, if we're passing parameters we have to actually define what kind of thing is gonna come across the route to us. So I'm just gonna tell it that we're gonna get content there. And so this will just be nodes of whatever type. I'm gonna roll with the standard builder on this because we'll demo IPE later. And I will do a two column stacked layout and hit next. So you'll see that this isn't quite as pretty as what we've done in Drupal 7 because we're still iterating on a lot of these UIs. But we have kind of the typical table drag sort of thing going on here for the time being. We will get layouts rendering into this that you can drag and drop like you're used to. And when we go look at IPE, you'll see why we haven't really prioritized that yet. This is similar, so if you saw the Fields UI demo in the keynote, it's using some of the similar strategies there. And so our presumption is when we get to a point where that's looking good, we'll probably share a lot of that work on the admin side. So I can just come in here and I can configure these blocks. And when I do this, I'm just picking the regions that I wanna add them to for the time being. And so I think we're pretty much done here. So with that, I've created a new variant. We can add variants. I'm not gonna bother with that for this demo, but it does support adding variants just like you're used to. So if you want multiple variants on this based upon like say the type of node that's coming to you, you can absolutely do that. And so now I'm going to go to test slash one. This is functionally a two column layout for my article foo node, right? We'll go look at node one here in a couple of minutes. But the point is is that I have actually taken over this. I've put the image over in the sidebar. I've put the body in this sidebar. And so if we wanted, is that black for you all? It's black for me. Weird. Pretty sure this isn't a panel spug. Whatever. So if we come in here, if I wanted to add something else to the right sidebar, I could go ahead and do something like add my tags in there. And I'm just gonna go ahead and say like this should be in the right and hit add. And while we're at it, we'll go ahead and do a part by Drupal and stick that in the bottom. One thing to note while we're here, for those who've used the custom C tools block in seven, which are now content blocks, if you're trying to export a page manager page, you won't get those blocks because they're content, not C tools. That's not C tools. So just a little caveat there. So I've got my body, I've got my image, I've got some tags. We just added the tags and we just added the powered by. So I mean, this is a real legitimate layout that we are interacting with and doing whatever we want to. Any questions thus far? No. Okay. Self-explanatory. Oh, you have one? Maybe. Nope. Okay. Great. Let's talk a little bit about a panelizer then. We've been looking at the foo article, but we're looking at it through a page manager page. So I want to actually visit the real article. So if I come in here, this looks kind of similar to what we were already playing with, except we're actually on the node page. And so I have who was published by, when it was published, its image and tags with body over here. And if we go and we actually look at this, which it's under content types now. So we go into content types and if I come into manage display for my article, this page has already been taken over by panelizer. You have this little checkbox here and when you click panelize this view mode, all of the fields UI stuff goes away and panelizer just takes over and does whatever it wants. And so you can see that I have two different defaults here. I have one called default and I have one called inverse. And so if I were to edit the default, you can see that I can change what its layout is. I can change where its content is placed within the layout and then we can do the exact same thing with inverse here. So if I come in here and look at inverse, again I can get up the layout or I can get at the content and these are functionally mirrors of each other, thus default and inverse. We can add new ones if we want to and we may do that here in a moment but what's really, really awesome about this is that you clearly don't see like the panel's user interface here because I haven't turned IPE on for this. But if I come in and I edit this, then I can look at what the full content view mode is and I can say I don't want the current default, I want inverse. And so if I save and keep that published, you'll see now my body is on the right hand side and my image and everything else is over on the left hand side and so I've limited what the user can even do with this but I've still given them options in terms of how the page looks. So we can go through and we can create a series of completely sane defaults that are totally approved, have gone through an approval process and now the actual content author can pick how they want it to look from an approved set of layouts. Cool? Cool. We can also do some really cool things around this. So like if we want to mix this with a panelizing individual nodes, you can go ahead and select the default you want and then like branch from it. So you can say like, yeah, yeah, that looks good but I wanna customize it just for my node and then you can begin customizing it locally. So that being said, let's go look at the landing page. Actually, let's make a new landing page. We'll just start from zero. So if I wanna make a new landing page, we'll make this one about us and I'm just gonna run with the current default display on this and you'll notice that we now have moderated state. So I'm gonna actually demo doing individual node overrides and moderation simultaneously here because either one of those things is fairly simple but mixing the two of them can be quite complicated so it's worth seeing it done. So we don't even have a body on this node type. I'll go ahead and hit edit on that again. I want you to see there's nothing here. If you're putting content on this page, it's exclusively for the use of a landing page. We're not messing with any sort of fields really beyond the panelizer information and the title. So once we're here, I now have this little change layout, manage content and edit down here. So I can go ahead and click like manage content and we have a search bar. So I can say like, let's find the powered by Drupal. Maybe, maybe we'll find that. Okay, apparently my search isn't working today. That's okay. I think that's under system. Yep, there it is. All right, so I'm gonna go ahead and just add this to the middle column and now we have a powered by Drupal block. So if I hit save on this, I'm gonna save as custom. You can actually, if you're using IPE, you can override the default as well if you have the privileges to do that, but we're gonna save this as custom. And so now I have this powered by Drupal thing here. Let's change the layout to something sensible. Sensible purr. And now I can begin dragging and dropping this stuff around. So we're just saving as we go and then maybe we'll go ahead and do some custom content. And so I wanna create a basic block. I don't have internet. Apparently, I'm gonna start typing random Latin. That's pretty good, Latin. That's about as far as I can make it into it. But now that we have some, I can keep writing it. All right, so that seems like the obvious description. And so I can go ahead and create and place this. And now it's gonna say, where do you want this? And I'll tell it that sidebar. And let's go ahead and add this. And so with that, I now have some Lorem Ipsum text placed. And we'll go ahead and do maybe one more of these. We'll do an image. And I actually already have a couple of images uploaded. So we're gonna pick one of these. Yeah, you didn't do anything. This is a stock lightning. Yeah, this is stock lightning. No modules. I've cleared cache once. And so the article content type actually doesn't come with lightning. I built that. And I've cleared cache. Like that's the extent of what I've done to this thing. So you can go try this at home without going what? So save as custom. Now, it's worth pointing out that we haven't changed from draft mode at all. So I'm gonna go ahead and do that. And we're gonna publish this thing. Let's publish it. All right, cool. So node three says that. If we look at it, I'm not even logged in or anything. This is clearly what we see now. So let's have a little fun. Let's create a new draft of this. All right. And I wanna edit this. And let's edit this one. Cause I really think that it should say like, just maybe I was a little overzealous. Maybe we just need one exclamation point. So I'll hit update on that. All right, cool. And there's not enough Ipsum. There's not enough Ipsum, but that's a content block. So I can't really go changing it right now. But you know what I will do? I will take the powered by Drupal block and we'll put it in the top bar. Let's go ahead and save as custom this. All right. So powered by Drupal in the top, here's our body text and we have our lightning image over here. Now, if I come over here and I refresh this, nothing's changed. I still have three exclamation points and I still have powered by Drupal down here. But logged in, I can see the current state of this thing in a forward revision. I can see where we want to go with it. I can even change the layout on this stuff. And I mean, we could start getting really crazy. We could be like, oh, this is going over here. And you know what? This is gonna go here. I'll make my life a little easier here. Edit. I can't get it. No. You guys move it. We have accessibility first on this. So that's what the up, down buttons and the move buttons so that on mobile and with screen readers, you should be able to actually edit layouts. Okay. So I've even flip-flopped the image and the text. Again, nothing changed here. So let's go fix that. We'll edit the draft and we'll make this published and we'll hit save. And so now we've flip-flopped everything. Maybe I unsaved that at some point, but the rest of it looks pretty good. So I refresh over here and you can see we have now staged out this revision, everything's live. And what's really, really cool about this is I have a revision log of pretty much everything we did all throughout the steps. So if I want to look at what this looked like three steps ago, I can. Oh, there's my exclamation point. Somewhere along the way I got rid of it. Right? Yeah. Luckily, IPE as you run through the editor there, it does save things so it can get a little confusing, but luckily if you're using panelizer, it'll save it for you. So if you get Scott, you can revert. So this means we have full revision tracking of all the layout changes made to a panelized node if you're tracking revisions, which is super, super useful. And inside of Lightning, this is auto-integrated with Workbench Moderation, so it just works. It does this out of the box. All you have to do to actually get this is I think probably under Manage Moderation. Oh yeah, I can enable more moderation states, but you have to turn on moderation, which I'm entirely unsure of where you do that right now. But you can dissect Lightning and actually see how this works. And again, you can download all these modules separately, but definitely it would recommend, at least looking at this. So, do you have other things you wanna add? No, I think this is good. I wonder if we should take some questions from folks. We got about seven minutes or so. Yeah. Yeah. So yeah, we have two microphones for questions, and we can run through things on the demo too if there's things people are curious about. That's why I do demos and not videos, because I wanna have a bootstrapped environment to show you the things you might ask about. So really, we'll be super honest. If it doesn't work, it doesn't work, but we'll tell you where we are on a thing. Go ahead. Hey, thanks for the update on the progress in D8. I had one question about when you have a panelized node and you make it overridden. Is it like D7, where now it's totally off on its own in any updates to the default, no longer apply to it unless you revert to default? That is correct. So yeah, in fact, the panelizer field that's in the entity is storing that data. There's some discussions about how we could figure that out, like how you could apply defaults in the future. Yeah, it seems complicated. It is really complicated, because I've seen issues where we definitely wanna do that, and in the same site, we definitely don't wanna do that. So that's a really hard one to solve. So our approach on defaults right now is, and again, buyer beware, this is not 100% yet, but what we're working towards is since the, since the panelizer field knows both the override and the default, what we're attempting to do is get to a stage where we can actually revert from an override to the default it had beforehand. But bleed through of changes to defaults to like forked versions that are in the fields seems like it would be really hard to do with any sort of clarity and probably is more trouble than like, there is one key change that was made, which is in D7, when you override the default, it sort of like destroys some of the existing information about what that default was. In fact, I think we've hacked something together so that I can- Yeah, we're trying to preserve that, right? Yeah, like I have a computed field in Drupal 7 that like sets what default you used to be in. And so in Drupal 8, we fixed that part. So at least if you have multiple defaults and you override it, I'm not sure if this is, well, there's certainly in a patch, because this is all in a patch at the moment, but one of the functions that should be able to do is revert back to, so if you have two defaults, A default and B default, and you have override as custom, you should be able to revert back to B default if B default was the one that you selected in the first place. Unlike Drupal 7, where it was default A, B, you override it and all you can do is go back to the default. You didn't know what it was before because we got rid of that. So in Drupal 8, that's fixed. And once you've overwritten something, like back on my article, you know, I have, there are actually four potential choices here since I have two defaults, but you can't see all four of them. So one of them is the current default display, whatever it may be. And so that means when I'm over here in a managed display, you'll see I actually have the ability to change what the default is. And we're working with Drupal 8's page caching mechanism so that we actually know who has what defaults applied and whether or not they're supposed to be following the default for their bundle. And when we change the default, we can clear that. So the next time anyone hits it, we generate a new cache item and, you know, no problem. So that's really cool because we have global defaults that we can actually change out from under page caching to have page caching recalculate properly. But in addition to this, if you're on a page that supports custom overrides and you're using the custom overrides, this field becomes un-interactable with, add a preposition to the end of the sentence. And so now the user can't do anything until they're back in IPE and actively revert to their default, at which point, like I said, the desired functionality from our end is that it would go back to whatever default it forked from. Got you. Any other questions? Feel free to line up on. Yeah, so you sort of skimmed over this. The big thing we gained in D7 from using panels is that not just page manager, letting you put a bunch of stuff in your main content area, but it also gained context because panels are really smart and understand context and can do all sorts of stuff whereas blocks are very dumb. Is that still the basic lay of the land in D8 that blocks are still pretty dumb and to do anything I need to use panels to get fancy, essentially? Context, yeah. So context was actually one of those things in C-tools that was brought into core. And I think, maybe, Chris, you wanna show actually just the blocks page? Sure. It doesn't really matter, really. But the big thing that we gained from that is the panels page is actually showing layouts of, like, the blocks, yeah. Yeah. It basically, and this is actually the core context system. So short answer is context or the idea of applying context to blocks from, I don't wanna say context module in general, but some of the fundamentals of it are in core. The big thing that panels has moved towards being able to do is apply layouts to those. Yeah. So this list right here is every context that core knows about, because we're just asking core. That's only slightly terrifying, but thank, okay. Yeah, well, that's because we moved to the entity system being basically everywhere, and this includes config entities. So all of those things can be treated as context, and so can every field in your system, and also the raw values that fields might be derived from. So it's a pretty significant bump, which means that a system that was confusing is now terrifying, and that's okay, because it's got the corresponding power. Ultimately, page manager's not responsible for that anymore. This is a core thing. Yeah, it moved into, it's actually kind of split down the middle between the type data API and between the plugin API, because plugins define contexts via type data, and there's like an intermediary there, but yeah, like in just the basic, like this is just core blocks right here, and if I pop open like place block, you'll notice that entity view content and entity view user, which are both provided, they're blocks provided by Ctools. These are blocks which can render a particular entity passed by context. So if you place this, it will render that when you visit a page with a node, which of course is completely useless because you're already rendering that node, but it can do that, and this one will do it for the current user. There are ways to introduce new contexts to the core block UI, but they are difficult and not nearly as robust as what page manager can do out of the box. Okay, so you're adding that UI that we had with a gigantic list is not actually available here anywhere. That is still a panel's. Yes, it's a page manager thing. Page manager thing, right? Okay, thanks. And actually, panelizer has some access to it too, when you're not using in place editor. Right, we have time for one quick question. In fact, we don't, but we're going to anyways. Okay, so first of all, thanks, great work so far. Actually, I have used only page manager in Drupal 8 so far, and actually I have to admit that I needed to uninstall it again because our very first premise was multilingual. So actually, I was like fiddling around a little bit. So first of all, the page title, then the page URL needed to be translated somehow. And then I realized I was able to do it more in a node. So my question, so please don't be offended. What's the need for the page manager? I see the other tools as well, they are quite nice. But what do you think is the need still for the page manager since all those other tools? All right, so page manager has variants in here and we didn't really demo this. Variants have selection criteria, and so on a selection criteria, and I don't have anything linguistic installed right now, but if I did, there's actually also like, basically find the context of language that you're in and then display different pages depending on the language that you're on. Yeah, exactly. You know, and in general, like even non-multilingual page manager's becoming less and less of something from the content side. I think, you know, for me, we use page manager a lot on the admin side, so like showing admin displays, showing some type of static pages, like we were just doing some 403 pages and 404 pages with page manager. But yeah, for like doing landing pages, I think nodes are a much better way of panelizer than say page manager. Yeah, I would go nodes with panelizer right now. That being said, this context right here, this current user one is one that's provided by default to all page manager pages, and we should be doing the same thing with current language, but I don't believe we're quite there yet. That being said, contexts, this stuff right here includes language, it is a viable context, so the second we add that, we'll be able to nuance things based upon the current context, and then you'll be able to build page variants based upon that stuff. Just to push you a little bit further, it's actually two modules like meta tag and for example, sitemap that we at this point really needed for search engine optimization, and so I still need this use case to be applied on this page. Yeah, we're not offended in the slightest, we fully know that language isn't where it needs to be. Yeah, cool. All right, come find us if you have more questions. We are two minutes over, so we're going to give up the room. Thanks. Thank you, everyone.