 So this is the Blocks and Layouts Everywhere Initiative update. If that's not what you came for, too bad. So yeah, very quickly, for those of you who don't know me, I'm Chris Vanderwater. I'm a senior developer over at Commerce Guys. If you want to follow me on Twitter, where I actually talk about this stuff, I'm at Eclipse GC. So let's just get straight down to it. Yeah, oh, no, I just, I got to go back to this. I've been the Blocks and Layouts Initiative owner since March. So just keep that in mind as we go through. So I wanted to talk a bit about some of the goals that we had for this, kind of update you as to where we are, and we can kind of go from there. So really, there are a lot of things that we wanted to accomplish here. Some of us had different goals than others, but we've kind of done our best to merge all of those things. For myself, these goals were really the ability to standardize the entire Blocks system to more closely reflect what was common practice in contrib, right? Oh, yeah. Does anybody else have one of these? Yeah, let me borrow it, and let's see what happens. Oh, awesome. You want VGA? Yeah, VGA. Have you got a media first? No, I don't know. OK, I guess that's going back to the Apple Store. All right, so standardization of the Blocks system. There are a whole bunch of different ways that Blocks get used in case you haven't noticed. And we really need to update Core so that it reflects what's being done in contrib. This is kind of Greek for we'd like to get context into Blocks and a couple other things. We want to drive Block Output through the context that's relevant to it. So if we have a node on the page, we want to be able to pass that to a block. If we have a user on a page, we want to be able to pass that to a block so that we can render individual portions of that node or user in isolation. I want the node title, those sorts of things. We wanted to expose more content through the Block component system. Personally, I would like to expose anything that's output just about anywhere through the Blocks system. There are a couple of caveats to that. But there's a whole lot of work to do if we want every single piece of output in all of Core to be Blocks. I'm going to be doing my best to guilt trip you all this session just FYI. And that's especially true of forms. Drupal Core has a whole bunch of really great things it can do with forms to make them super generic, and then it hardly ever actually does them. So the forms within Core are going to need a lot of upgrading as well. One, to remove the page TPLs in favor of a page-driven layout system, something very similar to panels. I have done my best not to say panels in Core, but I'm just going to say panels in Core. And then ultimately, I would like to maintain my sanity status quo while doing this. So we can debate how sane I am, but initially, we had a number of blockers back in March when I started this. There were various whiskey patches, specifically the symphony kernel and the new router that since that time, the symphony kernel has gone in. I guess I think that's my next slide, actually. Robust and capable plug-in system. We have plug-ins all over the place, both in Core and out of Core, and it became pretty apparent very early on that what we needed was to put something that could handle all of our needs into Core. And then we have to have a user interface agreement on this system so that we can start putting it in place. And that's a really, really non-trivial thing. Boyan, Boyan Summers. I don't even know if he's actually at the con. I assume he is. Oh, OK. So Boyan and I have spent more hours than I've bothered to count on Skype just trying to get through a bunch of this stuff. And we have a lot more to do. Who in here has actually seen his prototypes? Awesome. Awesome. Yeah. OK. I should have put a link to that in here. Apparently, I didn't think about that. But we'll take care of that. So the current status. The whiskey kernel patch has been committed to Core. The plug-in system is in Core, including annotation-based discovery. If you don't know what that is, it's cool. Trust me. Yeah. And much of the user interface, in fact, the most difficult parts largely have an agreement. Like I said, Boyan and I have worked on it a lot. We've included Earl Miles and Angie in that conversation. And the four of us, for the components we've actually mapped out, have an agreement as to what should actually be there. There are more things that need doing. But by and large, they're easier compared to what we've done thus far. So we've tackled the hardest part, and we have pretty good agreements there. Oh, yeah. I think I just said all that. OK. So that brings me to the what's left slides. There's actually a lot of stuff that's left. And I'm just going to kind of start going through this so that you know exactly what is outstanding in order for us to even begin considering that we've succeeded here. I have a blocks patch sitting in the core issue queue right now. It's about 150k, all of which I have hand coded. And it turns blocks into plugins. It also updates the user interface for blocks in such a way that a number of existing contrib modules could probably go away. And I will show you a demo of that today. We need to, and that specifically is actually my focus for this con. I would like to get tests written on Friday for this new user interface and try to get that passing as soon as possible so that we can actually have legitimate tests against this new patch to prove that it's working the way that we want it to. We need to get isolated block renderings. I already have issues that I have filed today for most of the things that we will be talking about in order to give people foundation on what could be done now and likely what we will need to do later. But there are things that we can stage in now and then improve later as we get more abilities into core. Contexts and data sources, there are a lot of different plugin components out there that could actually consume what I've been calling data sources. Blocks are just the big one right this second. There are also conditions, right? Who in the room has used rules? Yeah, so we could very easily put everything but a rules UI in the core almost without trying. Like we could have every single component minus the user interface actually there because actions could be updated to take context conditions which we will need, take context blocks, take context, all of these different things can take what we have termed context or data sources. And yeah, we need to start working on this. Again, I've started outlining this within an issue so that we can start making some agreements on it. Ctools largely does what we are going to want here already and we need to update it and make it object-oriented and really just give it the love that it needs. I've talked about the condition plugins already so I'm not gonna talk about those anymore. Multi-page form wizards. This isn't like a huge blocker for me right now but it will be in the long-term once we start actually building the user interface and that's kind of a big deal for views as well. They've already started putting in components that this depends on and whether we absolutely need it or not is maybe dependent upon how much form code we're willing to write. We could perhaps significantly reduce that and make wizards easier in core though. The UI agreement needs to be complete. As I said, we've agreed on a lot of what is there mostly the really hard stuff but we do need to finish it. And then we need to build the UI which there are a lot of components, very like delicate moving components that we have to kind of understand here before we can just go building this user interface. Who in the room has used panels? Who in the room has used the IPE for panels? Okay, so you people at least know what I'm talking about. Who has used Panopoli? Okay, about the same number of people. So yeah, these are the sort of things that we need core to ship with something that everyone can just use and we need contrib to be able to replace it with their own things so that we can allow for experimentation of additional UIs. We don't wanna just lock them into something forever because that's one of the big complaints against panels as it stands right now. So we don't, and panels doesn't lock you in that way, it's just that nobody has really been willing to code around those various things except for Sam Boyer and Matt Cheney. Layout plugins, we're gonna have to start actually defining what a layout is. I'm calling it a plugin right now because that's most likely what it will end up being and there's a lot of really cool stuff happening there right now. If you all have been going to the Spark Conversations, then you've seen the sort of cool stuff that AQUI has been doing with responsive layouts. There are a whole family of layouts that sit in Panopoli right now that we should probably take a look at with regard to how many of those could be ported to core effectively. And then on top of all of this, we need to have a really long conversation about what is going to happen to themes. If we remove the page TPL, which is really a very important part of what exists in the theme today, does that fundamentally change what a theme is? And if not, why not? And if so, how? I don't really want to get too deep into that topic, but it's one that we should certainly be having in BOFs and in the hallway track. So yeah, I don't have too many slides here, so I'll be done in a second and we can kind of demo and then just start talking about this. So in conclusion, I think there's a lot of stuff to discuss. I have a group of the most important issues that I think we should be discussing here. And in fact, there's one in here that I didn't have in my previous slides and that's the temp store classes, which ask me afterwards, I'll tell you what it is. I'll be happy to put this slide up where everybody can get to it here shortly. But we do have issues for all of this stuff and I've included things outside of my own initiative like Larry's router, which we really need people reviewing and pushing on. So I just wanted to say thanks to Commerce Guys. Like I wouldn't normally try to advertise my company, but they have given me way more than the 20% that they promised for me to be focusing on this stuff. And we wouldn't be anywhere close to where we are right now if I hadn't had probably a lot closer to 40 or 50% time. So yeah, what would you all think of the demo? All right, go away keynote. Cool, okay. So actually, is John Albin in here? John? No? Okay. I think I found a bug, but whatever. No way. Yeah, in fact, there's a bug in head. Oh my God. All right, so yeah, what you're looking at here is probably something that's pretty familiar to most of you. As I said, what I'm gonna demo today could likely kill a number of modules that exist in Contrib. Specifically, we could kill contexts, block layout stuff. We wouldn't even need it. It would be unnecessary. I will outline a few other things that we should likely do here in the very near term that could also kill probably boxes, beams and fieldable panel panes, okay? So, I've got a number of blocks here. I'm actually just gonna go through and remove them. I should have done this before I sat down, but hey, someone else got the benefit of my demo before I did the core conversation and so, awesome. So yeah, we've removed all the blocks except for the main content. I just left it there because we kinda need it. And if we want to add blocks, you can see that there is nothing on this page except for the main page content block. That's the only instance that we actually have up and running right now. You'll notice we are getting help up here though. So if we come over and we look at seven, I have a system help and a main content. And by the way, main content here are actually two separate instances of the exact same block. So we have some additional flexibility there. If we want to add new blocks, we can just pop open the block library and you're gonna see every block that's enabled across every module right here. So if we want to do something like place the who's online block, I can go ahead and do that. I'll select where to show it. So we'll put it in the sidebar. And so I'm just actually, I'm gonna put a title on this that is 15 and 10 so that we'll keep track of exactly what sort of configuration we have on this and can easily see it at a glance from the front end. So we'll call this 15 and 10. I'm gonna hit save. And so just proving that I'm not full of crap, yay, we have a who's online block. Which of course you can easily get into and hit configure and change it over to sidebar second and save and it works the way we expect it to. So for my first trick, I will just add another who's online. And we're gonna put this one in sidebar first because I just moved the other one to sidebar second. We're gonna set it to 10 minutes and five users. So we'll call this one 10 and five and hit save. And you'll notice now that I have a 10 and five and a 15 and 10, right? And so you can already tell from the titles that I have individual configurations but just to drive the point home. 10 and five, 15 and 10. We also kind of built this nifty little plugin UI while I was at it. And so we can do some cool things if you wanted to add a menu. You can just say, hey, what all menus do we have? Oh, we have a user menu. Great, let's just add one of those. And so we can say user menu, user navigation. We will put it in like, I don't know, featured maybe. Haven't done that, feeling dangerous. Boom, right? So I'll admit that looks kind of ugly. Maybe I should move that. While I'm doing that, I will point a couple things out. You all probably can't see that so maybe I should zoom in. So most of you probably haven't been able to see what I'm typing because I'm moving pretty fast here but when I told it I wanted to give it a machine name, the machine name I gave it was user menu. And this is actually the full configuration ID by which it saves it. So it's plugins, core, block, bar tick because we have instances per theme, user menu. So you could actually reuse this exact same naming scheme on a different theme because it's going to switch out the theme component that's sitting there. I haven't decided if these are all good things or bad things, it's just how it is at the moment. But what's cool about this is once CMI starts actually writing to files, you'll know exactly the files to go and get to drop into another module in order to have these things preconfigured. And so I think that that's kind of a cool little point. Let me just add a little bit more. Probably need a powered by. All right, okay. And actually I haven't even taken a second look at this administrative user interface this whole time we've been doing this. So I mean, these things are all showing up here. Again, just to kind of prove the point this stuff is actually working. So now user menu is inside bar first now. Okay, so yeah, I mean, that's my demo. Those are my slides. Why don't we just kind of open this up to conversation and start talking about the future and my priorities and really any topic that has to do with the initiative that you'd really like to kind of cover here because there's a lot of ground to cover. I've done my best to kind of get things this far because I really, really feel like we need to have a bare minimum Drupal has improved in this regard even if we didn't get everything we wanted sort of patch or two. And I feel like this is a really good step in that direction but it's certainly not where we want to be. So yeah, with that, I mean, the mic's open. Please come and talk to the mic so that we get this all recorded. What's your thinking and plan on custom blocks and what's your thinking and plan on page manager type of assign these things to pages that kind of context. Sure, so to discuss custom blocks, in the patch, custom blocks has actually been completely removed for the moment, mostly for the sake of my sanity. I think the best thing to do with it is actually to re-add it in a separate module. I think that makes a lot of sense. Mixing a block with the code that actually runs blocks was always kind of messy. And so I think that makes a lot of sense. I'm debating whether we should do a straight port of that or whether we should go like for what we want, which what we actually want is to turn custom blocks into an entity. So there's an entity that actually sits behind the plugin that we call custom blocks. And in this case, we could actually have like bundleable blocks at this point. So if you wanted to just have an image that you could add once and then reuse all over the site, you could totally just create an image block, upload to it, say that it's reusable and then it would show up in the block library just like any other block. And so you could place as many instances of it as you wanted and it'd be no big deal. If you've ever seen Matt Cheney's demonstration of Panopoli, he does this amongst many other kind of cool things. So we need not be strictly stuck with text and I am CE or something to drop images into it. We could do some really cool stuff there. Son and I were actually discussing this last night while standing in line for food and there's some questions about exactly what sort of things need to live on that entity as actual properties, but I think it's very, very feasible. And so when you come to blocks and you hit the block library, which we should probably change the name of, you'd have like a add custom blocks link here that you could click and then it would show you all of the various bundles of that type and you could just click through one and start adding an image or custom text or whatever to discuss the notion of page manager and the differences between that and blocks as they exist right now. Blocks right now are smarter than we want them to be because they know what region they show up in and they know what caching modes they use and all of this sort of stuff. We want all of that to go away. In fact, the configuration objects associated with them would likely go away and we would have a layout configuration object that says, I have these regions, these blocks appear in these regions in this order and that would likely be where we want to end up at the end of the day. Does that answer all your questions, Gavir? Yeah, that's the UI that Boyan and I have been discussing so in depth and so yeah, there's a lot left to do there. I don't have anything to show. It sounds like the use case described there if a custom block sounds like the bean module. Yeah, that's why I said we could kill it. Yeah, so there could be an effort to port the bean module fairly directly. Yeah, in fact, I've asked Neil to do it. Yeah, okay. Yeah. Hey, Chris, so question about rendering basically individual blocks. Mm-hmm. Couple things I've heard you say make me feel like there's some disconnect. So one was about the sort of page context of the block if I'm supposed to be able to render the block alone, how do I know that it was appearing on a page with a certain node? Right, no, that's a really great question. And so the initial issue that I filed against that really only considers Drupal's existing core blocks. Okay, so it has no notion of that which is why I said we're gonna have to kind of iteratively improve that. At the end of the day, we're going to have to probably generate our own URLs for each individual block based upon their use case. So if a block takes a node and a user context, then we are likely going to have to create a URL that includes the node ID and the user ID passed through appropriately so that it can get those items and load them. Sure, okay, okay. Then I just heard you say you wanted to remove a lot of the configuration from blocks including caching information, but as far as I understood, the part of the goal of the individually renderable blocks was that the block itself knew something like it's cache lifetime. Yeah, actually the layout knows that. And since the layout is the one that wraps the block, it would move up a level. But then how do I, so I still somehow have to load the layout to render the individual block? I think that particular nuance is still up for debate. Okay. Whether, like, the problem is, is that all of the configuration for the block is likely to live in the layout anyways, but like I said, nobody started writing any code there, so it's up for debate. The trig session. Okay. And I was at the one yesterday. So you know why I'm late. Yeah, and you were drinking a ton of water. So yesterday I asked the question, or maybe I posed the complaint that with theming, we're stuck in all these different silos. We have a lot of template files and theming is a bunch of, a series of overrides of specific files. And my worry is that the move towards twig is not getting to the root of the issue. And when I posed that yesterday, they said that you were going to solve all of my problems. So. Nice of them. And listening. Alex. So I mean like the ability to solve all your problems is probably not within my domain, but I might be able to shortcut them to some extent. And so what I've been proposing with regard to that is that when you place a block, you would actually have like an additional dropdown here that would just default to none. And what it would give you the ability to do is actually select a wrapper in which to wrap your output. And this is something that we do in panels currently. Most people hate it because it doesn't default to none. But the point being that having the ability to actually style a block is a really powerful way to say, well, I'm actually okay with the output of this. I just need to decorate it. And really like that's not the be all end all of everything themeers need, but it certainly goes a long ways towards fixing a number of problems. And you know, if themes can actually provide those sorts of things in such a way that you install a theme and you have a bunch of new stuff in the dropdown, like I see that as being a real big win for everyone involved. Well, here's the thing I can't really wrap my mind around. We're talking about removing the render API, but I don't quite know what we're going to replace it with, for example, if I have a block, I have a module I created, and instead of returning markup, I return a renderable array. The reason being that the themeer can have complete control over his markup, right? It's more of an abstract way of describing what you want to output. So we actually have a separation between the data and the markup. All right, so I guess this requires code. So I think fixing the problems of render is probably not within my purview, but I will do my best to comply with whatever obviously is being decided there. By and large, we've generally decided that blocks at the end of the day, currently they're returning renderable arrays, like I'll just tell you that. But at the end of the day, they should probably be returning strings because they're gonna return response objects anyways, which are strings by the time we get a hold of them. And so there needs to be kind of some consistency of exactly how we're gonna deal with that. The other thing to keep in mind here is that, let me see, do I? I don't think I've got one open. Awesome. I didn't actually intend on getting into code, but we will do it all the same. All right, so this is the powered by block, right? Here, probably helpful if I, everybody see that, okay? Yeah. So I mean, I'm just returning a theme function right now. But this is a class, right? And so this is actually a question that I would love to pose to Themers. Are you so afraid of doing something that's a little bit of extra PHP knowledge that you'd be unwilling to learn how to extend a class? Because if you're willing to learn how to extend a class, you have complete control over the output of any block in the system, like 100% control. So if you want to change the system powered by block, you could literally just create a new class that inherits it. It's the same problem of overrides, though. That depends upon whether we're using a theme function in order to output something. If I'm not using a theme function here, like we'll grab a more complicated example. Or just to back up a little bit, I work for a company that's been around for a long time and their flow is they have a mockup that they build with a designer. The designer hands it over to someone who makes HTML and then it's thrown into Drupal. For other content management systems, that workflow is okay, because you can dump the CMS into the theme layer rather than the other way around. The way we're working right now is we override a lot of things that are already provided by Drupal. Yeah, I mean, I don't want to shut you down, but like... Separate. Yeah, I think it's kind of a separate issue. So what issue would it be? Because I think this is the most important thing from my perspective. Yeah, the problem is that it's sitting squarely in the middle of a whole bunch of different people's considerations, so no one of us can directly answer your question. We kind of have to collaborate on it, which obviously we're trying to do, but I'm not sure I can answer for everybody. We could probably sit down and have a real conversation with all of those people, but... Yeah, yeah, this is really good. Okay, great, thanks. Coming back a bit to the problem of custom blocks, it seems like you said that you want basically everything to be a block. So it seems as though the concept of blocks is... Or that a block is really not the content, but the block is something in which you put the content. Like the user online block is a block type and there's like this string of text inside and that's not... So the block is basically different from the content. So what I'm trying to say that because he said the goal was to make custom blocks into entities, so what I would, or my question would be, wouldn't it make more sense to create a block type where you could just put like a node inside and it would render the node because the block... Yeah, that's the notion of context. Right, like we want to be able to pass a node to this and have it render the whole node or the node's title or the body field or something like that. Right. What I'm trying to say is that it seems as though blocks aren't inherently content in that whole scheme of things. No, they're kind of just generic output. Yeah, yeah, so like that's... I'm gonna say a whole bunch of things and some of them may and some of them may not respond directly to your question, but like with regard to what content is actually being shown on the page, there's still likely to be something that says this block is the main content for this page. So by simply putting a main content block up, it would find the other block and then render it inside of itself, right? So we still have a notion of like content on the page and that also means that you could actually remove the primary content for a given page and put something totally different there without necessarily having to deal with the fact that you removed primary content from every page because it would just be that one, right? So like then there are lots of little details to that, but I mean essentially what we would like to do with regard to custom blocks is you have one-off instance use cases of it that are pulling a specific block entity in and then rendering them and then you have others where you've said I want to make this reusable and so you'll be, it would show up in this block library just like everything else right now. And so then you could have multiple instances of the exact same block entity showing in various places on the site, right? So how a block that has a node injected into it, that's sort of a separate consideration and it's one that having the data sources and context layers get us until we get that. It becomes really difficult to pass arbitrary components into a block in any sort of trustworthy way. Does that come anywhere close to answering your question? I guess just like a short follow of what I'm trying to say is that if you have a custom block which is an entity and you fill out the body field or whatever and add an image and then you compare that with a node which you put in a block and render the full node inside of a block, there's really, the only difference is that the node also has its own page somewhere else. So there's really no. Yeah, as was pointed out to me previously if we have blocks rendering and isolation date technically have their own page too. But you're pretty much correct. And that's sort of the delineation we try to make is that the node actually has a page that we intend on users reaching, right? And I mean, I think it's a pretty clear delineation because it's not the only one. I mean, everything you just said about nodes is true of users, right? And comments and files and terms and all of those things. So, I mean, yeah, it's sort of abstract and it's sort of weird, but it works. So this is looking awesome so far. Does this have any of the context data sources stuff in it yet or is this just vanilla ports, still context free everything? This is a completely vanilla port. Okay, does it have? This UI is a paired down version of what Boyan and I have already agreed on and I've shown him this and he was generally okay with it. Okay. So do you have a sense for how that would get put into what you have now? Like a clear path to get that stuff into it or is that still up in the air? Do you and I need to talk about that yet today? Like from a technical implementation perspective? No, I am not sure how I'm going to get context into it. I could talk about how the UI will reflect that but from an actual implementation perspective I do not have answers for you yet. That's why I went and made a whole bunch of issues today so that we could start putting that question answer somewhere. Okay, let's make sure to talk about that specifically while we're here. Okay, great. That's actually one of the goals for this con is to figure out data sources. So, yeah. You talked about panels and stuff like that. I was wondering about the display suit specifically but display suit extra that we can use to put fields in region. We can use the term region and use it in display suit and managing that way. Is there any impact? Is it one? So, display suites focus and I was pretty sure that this was the case but then I saw it actually demoed today because I haven't honestly used it but display suites focus is really about taking care of the various bundles available for entities. So, it allows you to do different layouts for your pages as you do for your articles, as you do for your images and so on. And that's great. And understand that nothing I'm saying is attempting to be little display suite because it's an amazing, amazing product and it does a lot of the things that panels does in a much simpler way but we have all of those same capabilities in the panel style approach. The problem with the panel style approach is that it's a bit more complicated and that's part of the initiative in that we want to try to make those things a bit more accessible. Were you at the layouts thing, the layout session earlier today? Okay, so Matt Cheney demonstrated Panopoli during it which is really kind of the direction that we want to head. Every page has like changed this layout, customize this page button. Like they have two of those buttons and you can change layouts, you can customize the page, you can customize individual pages, you can customize pages that are intended to apply to all nodes of a specific type or all comments of a specific bundle or any of those sorts of things. So I mean, we aren't losing any of the stuff that display suite does today. Its representation might look significantly different though. Any other questions? I guess just maybe as a follow up to that. How does this then correspond to like the difference in view modes between nodes and other entities? You ask a dangerous question. I like to do that. So actually had a bit of this conversation earlier in the week so my answer has changed since the beginning of the week. Really I think the wisest thing to do here is make view modes completely arbitrary. So they're just a string that is related to a layout that consumes a context of that entity. So if we're discussing view modes of nodes then you could arbitrarily name as many of them as you want and what you would do is you would then point that new name at a particular layout that could consume a node. And we could probably introspect it so you'd get a list of all the layouts that consume nodes and you could just select one. And so in this way, like hopefully what we get to do is you can go into views and create a new view and say this is a view of content and I want to use this view mode and suddenly you get laid out nodes in view results. So you start doing those sorts of things. Or really anywhere where we might display the whole node at the same time we would actually say use this view mode and what that does is it goes and it retrieves a layout specific to that view mode and then displays it in that area. I'm not hung up on our verbiage when it comes to a lot of these things. Others I really am hung up on but not that one. I have a same question as I'm made to cradle overlay question mark. I have nothing to do with it one way or the other. It should continue to work just fine in our system. We may need an additional set of modals but I'll cross that bridge when I get there. Can we see an issue to make the implementation simpler and saner? I mean like from the perspective of if you were staring at an administrative page in an overlay you might have the ability to customize it so it's not just like a single column or something like that but I don't think it would fundamentally change what overlays does. Including the crazy acts we're doing around iframe and pulling out the tabs and stuff. Yeah, that's way outside my initiative so. Okay, so I think this goes for another 15 minutes. Is there anything that you all would like to see code wise? I mean, I'd be happy to. Yeah, do you like it? I know it's not like where we're trying to go but I'm really hoping that it's at least a good like hey we've only been working on this since March let's still keep our nose to the grindstone but I really feel like we need to be making a backup plan of some sort at this point unless we get a whole lot of hands to start helping. Yeah. Awesome, so that leads into my question which is given that list of priorities you had in the beginning, which of those could conceivably not be completed and we could still get something that could be checked in and functioning? So I think like bare minimum we need to get like blocks. Like Larry might actually be able to answer this particular question better. Like do you think that the existing blocks that are inside of core would benefit from rendering in isolation? I have a yes from I think Tim Plunkett. Okay, so yeah, all right great. That probably answers the question right there. We should almost certainly have blocks rendering in isolation and I think that would be relatively easy to do. I have a block load function that takes the CMI key and just returns you a block instance. So you could actually do percent block in a URL and if you pass it the CMI key you'll get a block instance back. So that should be like relatively easy to do a first pass on. Actually getting it working with sub requests suddenly falls into Larry's world and we should discuss that with him. Yeah, but so I think there's that that we should definitely do. If we don't do the data sources layer I can't go any further. Like that has to be the next priority after blocks rendering in isolation and the only reason I would prioritize it first is because I'm trying to get a fallback product and I think that we should include that. So but I would really like to start work on the data sources stuff and if we can do that then we can continue forward into all the other things that we want to do and if we can't do that then we're really stuck right where we are. I think even as you talk more about order of operations so we can make sure that the USF stuff to hook into. I would love to do that. Awesome. I'm just gonna use the last few minutes here to kind of throw out a couple of like things you should probably know about the plugin system. If anybody has an objection to that, let me know. But it's my session so screw off. No, what? Yeah, I'll drop all those issues that I have in that keynote into like IRC or something here in a few minutes so we can figure that out. Or I'll put them on my groups page maybe that's a better spot for them. Yeah, okay, great. That's probably the best place for them. So this is the powered by block. I picked it because it's ridiculously simple. We'll look at a more complicated one here in a minute but you can see that I have one method in this class, one. So it doesn't take an awful lot to build a block if the block is simple. We are extending from an abstract class and so we get a whole bunch of stuff for free like say the configuration form, right? And then in addition to that, the only other thing really of relevance here is the annotation which is sitting up there at the top. This block has no registration information anywhere in any module in all of core, none of them do. I've converted every block except for custom block into this format. So what this means outside of my own initiative is that if you have something you want to plug in a fi you could actually completely remove it from ever being part of the loaded code footprint of your site unless it is actively being used which I see is a really huge one. So, and on that topic, like a huge thanks to CHX for helping make the whole annotations thing happen. Alex Bronstein and James Gilliland on plugins. These three guys totally powered through all of this stuff and helped make it happen. So if you like the plugin system, thank them. Let's look at a bit more complicated one. This is the user online block and really like the interesting stuff starts happening in our configure method because what you'll notice is that I have a configuration parameter inside of this class that's an array and we're getting stuff out of that right now. And so this is actually, this is typically data coming from a CMI object except on the first instantiation of the thing in which case you'll notice that I am actually getting the defaults for that right out of the annotation. There's some debate as to whether that's the best practice and I'm open to changing it. It's just what's happening now. So we can just check the configuration of the block and anything that's in the annotations will actually be available to us there. And then when we want to save it, you actually don't have to worry about saving inside of your block because all you have to do is drop it back into this configuration and then I take care of saving for you. So you just put it in by the name that you want it to be and I will magically save it. You don't have to worry about it. I might should stop and see if there are questions about that. Yeah. Basically, any plug-ins? So just like to shortly repeat that for the recording, there are a bunch of things here that are likely to be common across a lot of plugins. Let's abstract them. I'm totally okay with that. This all sits inside of my block base abstract class right now. There are likely a number of things there that could move up a bit. One of the things I do want to mention here and this is probably true for field configuration as well because it's field configuration that makes this especially true for blocks is that we may have config forms that need to be multi-step in which case we're going to have to figure out the whole wizarding thing that I glossed over in my slides. And so like coming up with a consistent way to do that sort of stuff is likely a really good practice. I'm not opposed to doing that. I'm not sure I want to hold up blocks on it necessarily but if blocks got in and we were all happy with a bit of the architectures there and figured out how to move it up a level I don't see a problem with that. There is a plugin base class from which block base is inheriting right now. And so we might just make like a plugin configurable base or I don't know, I don't care. I'm totally open to that idea. Any other questions on this weird CMI usage within plugins? Yeah. Maybe it's not so weird but can you just talk through a little bit about the annotations? I'm a little surprised to see comments driving stuff. You are not alone. So yeah, that's probably a good thing to stop and take a look at for a second. Again, keep in mind that a lot of this stuff is just, it's how it is right now. We should probably change a few things. But when you look at the annotations as they stand right now there are really two classes that you see used over and over again. The first is, yeah, thank you, Komodo. The first is this app plugin which is actually this same use statement right here. And the second is this app translation which is also the use statement under the other one I just highlighted. And so what plugin does is it's a class that just accepts an array of values coming through to it and then it parses that into a PHP array and just hands it off. And so this is basically what, all right, who in here has actually looked at the new plugin system? That's a lot more people than I thought we're gonna erase their hand. Well it doesn't change the fact that I have to explain this. So we have this thing within the plugin system called discovery, okay? And there are a number of different ways that you can discover something. The one that will be most familiar to everyone in the room is what we termed hook discovery in which case you pass it the name of a hook and it goes and invokes every module and returns you an array of definitions just like you're used to doing with just about any info hook on the face of the planet. So this is kind of an abstracted version of the same sort of idea in that we have a centrally, not centrally, we have a predictably located definition of what this plugin is and what it does and because it's predictably located, we can find it even though it's not in a module, okay? So this is the same sort of thing. We scan file directories that have name spaces in them and then we look for a particular directory structure in there and once we've found it, we parse the classes that come back for their annotations at which point that gets returned as discovery and yes, we should throw caching around that. I'm not in the current patch because it's not really ready to go into core just yet but you get the idea. So anyways, this plugin class, all it's really designed to do is take an array in, find any values of those arrays that are themselves, also classes that need to be handled and then it handles them and returns to us the array so that we can do whatever we want with it and it's just like calling an info hook and then specifying a particular key within that info hook, same notion. So the at translations happen at the same sort of level that T would happen at inside of an info hook. There are some desires to actually change that and I think that that's okay but we should change it for all of Drupal, not just annotations right now. So in general, that's kind of how annotations exist, how they work is a lot of voodoo that I'm not necessarily sure I know all. Yeah, it's also, it's not a Drupalism. We pulled this from doctrine commons annotations stuff which by the way, Zend framework is using and a whole bunch of other people. So like this, like obviously not our specific use case because we have our own custom classes here but just the basic approach is not a Drupalism at all. It's out there, it's in the wild and the rest of the PHP world and we are just kind of adopting the standard. The settings portion, I likely will but the reason is is that we don't want to instantiate the class in order to get this information. So it could be a static method but then we have a static method and we're just gonna throw a cache around this stuff anyway, which is why I said I'm okay with moving it to a method. Yeah, yeah, yeah, I'm in exactly the same place. We came to a consensus, I just haven't changed it. Yeah. Just a follow-up, you talked about two different methods of discovery. Is the hook method still gonna be supported or? I would imagine we would support it for at least all of eight. Okay. Well, unless you want to remove every hook and make them plugins, which I'm not sure is viable. Yeah, so yeah, I don't know all the details on that because Chicks has some serious voodoo up his sleeve. Essentially, this is loaded in such a way that it can actually be unloaded after we've got the information out of it. So it's not taking up PHP memory space, which is really cool. So just to clarify, plug-in discovery, the different types, info hook versus annotations and so forth, that is per plug-in type, correct? Yes, it is per plug-in type. So all blocks have to use annotations. All blocks must use annotations. I just wanted to clarify that. Yeah, and so what that means is that there's a particular directory structure that if you replicate and toss classes in, I will find them. So it should be really easy at a glance to open up your plugins directory or plug-in directory inside of your module and see every module whose plugins you implement and then looking within there, see every plug-in type for each module that you implement. So it's kind of self-documenting. Alex, I know you had a question. Isn't that CMI? Yeah, so the point here actually is that we don't wanna separate it from the class so that when you open the class, you have all the information. And for the settings, since we don't need that until we have an instance, it's okay to make it a method there that's not static because we're just gonna fire it as soon as we have an instance. No? Okay, yeah. So you're gonna make me repeat your question. Yeah, I said custom blocks are a hard case, but we've got here that you're setting settings for it and custom blocks are all just text and a filter. Oh, I'm glad you noticed that. Well, so like... You could just have a custom block that you can create multiple instances of it. Right, yeah. Yeah, and so the question is, do we just port it the way it is right now or do we go the full entity route? That's really the debate there. I've been encouraged to do both, which is obviously kind of impossible. Yes, Karen? Well, if we did a straight port, it would be temporary in order to get this patch in faster, not that we don't want entities sitting in that place ultimately. So yeah, it's a little past six. I'm happy to keep answering questions, though. The only other question I would have is, how do you see the contrib space leveraging on top of this or what are you potentially not gonna do here that you'll be expecting contrib to do? Well, if we get the context system in nothing, like I just expect contrib to give us more blocks. Does that answer that question? Okay, cool. All right, that's all I got.