 So, this is Drupal 8 Blocks Who Knew, or Drupal 8 Blocks Who Needs Panels, or Drupal 7 Blocks Grrrrr. So my name's Ted Bowman. I'm Ted Bow on Drupal.org. I work at Aquia for the Office of the CTO, so Dries is the CTO, so I get to work on cool Drupal 8 core stuff, like some of the stuff that you demo this morning, the settings tray, so the outside-end concept in general, the REST module, the water wheel, the Drupal part of the water wheel module, which is a JavaScript library, so I work on the Drupal integration of that. I've worked on contrib modules in the past, interview forums, scheduled updates as a new one I have. On Twitter, I'm everywhere else, I'm Ted Bow. So who are you? So if it was a smaller presentation, I would just ask everybody to come up and say hi, but generally, how many people are new to Drupal completely? How many people have started to work on Drupal 8 yet? I guess it would be easier. How many people have not started to work on Drupal 8 yet? So most people have. Okay. All right. So Drupal 7 Blocks, why did we need more? So basically, why was core blocks not enough for most of us for Drupal 7? So Drupal 7 Blocks, one, were not features-friendly. So I'm going to go through a quick list of the things that I think are the pain points and we're going to look at them individually and then how Drupal 8 solves those problems. Drupal 8 or Drupal 8 plus Drupal 8 contrib. So just sort of denote on this presentation, I'm going to sort of delve on what you can do with Drupal 8 core blocks in just a little bit more as opposed to the larger ecosystems or modules that might exist, but we'll talk about those too. So they weren't features-friendly. They weren't really easy to export with features. Each block could only be placed once. There were limited visibility conditions. Blocks were not fieldable without a whole bunch of other modules, and not everything was a block, and the Blocks admin screen for me wasn't, I felt like it was hard to manage a really complex site just with the Blocks admin screen. So for most complex sites, a lot of people would use panels or context, and or context, I guess sometimes people use both. So caveat for me, I was really in the panels camp. So this may be an American thing, but that's Mr. Kool-Aid. So I drank the Kool-Aid, which means I was really into panels for Drupal 7. So panels were super powerful, tons of installs, crazy configurable, but it was really complex, and it had a steep learning curve. And it was really complex, even, I think, just with panels itself. And there were a lot of great modules in the panel's ecosystem that added more functionality. But the more you added, the harder it got to understand. Like I said, I drank the Kool-Aid, I liked it. But it was, I also used to be a Drupal trainer. And it was sort of hard to explain what was going on in panels. So this is just the configuration of Drupal 7 panels, I think, which is maybe one or two other panels, modules installed. So Drupal 7 context was powerful, some might say super powerful. I kind of actually came to context later on in the Drupal 7 cycle. I came to really like its simplicity. I think for most people, for placing blocks, it was easier to understand. Because it was closer to the core block system. So this is just the screen for placing blocks via context. So Drupal 7 blocks, so why do we need panels on context? Let's look at the individual problems. So not features-friendly, so really you want to be able to do configuration in Drupal, commit it to get, move it from dev stage to production. In Drupal 7, if you didn't have some of the features extra module or I think there was a blocks features module. If you didn't have one of those modules, at least for most of the Drupal 7 cycle, it may have been improved later on. You couldn't easily export your blocks. So you might have to set them up locally and then actually set them on production. Which is, if you're considering your configuration is not the best practice and not ideal. So Drupal 8 blocks are configuration entities. They're really easy exportable. So this kind of piggybacks on a lot of what I'm going to say that's good about Drupal 8 blocks is how the block system is kind of piggybacking on a whole lot of other changes in Drupal 8. So the configuration management system. In this case, so blocks are configuration entities. They're really too easy to export, very get friendly. And you have one file per block. So let's look what that looks like. This is a screenshot of a directory with configuration. I'm just looking here at the block. So it's probably hard to read, but we have block.block.bartic.search. Block.bartic.bartic.tools. So each one of these is an individual block placement. And so for me right away, I like this better because in features, you would have multiple block configurations. If you had the block features extra module in one file, and it's a lot easier to have get merge conflicts when you're doing it that way. This is an individual block configuration file. So it's a YAML file. It's pretty easy to read. So if we looked at this, it says theme seven, region header. So it's really easy for me to just look and have an idea what this block configuration placement is actually doing. So I'm gonna show a real quick screencast of me basically going and making a change to a block, committing it to git, and then we're actually looking at the differences and then committing it to git. So under this scenario here, I have my configuration directory under my git repo so I can immediately see what changes are there. So first I'm just going out there and I'm saying, what's my git status? So I wanna see, my status is clean. Meaning I don't have any configuration out there that I haven't committed to git yet. And let's just assume in this example, I've exported all the other changes in configuration that I've made now. And I'm coming in, I wanna update something about my site, in this case where block is placed. So the first thing I'm gonna do is I'm gonna go to my site. I'm going to edit this block and I'm gonna go down to the bottom and I'm just going to switch the region to sidebar first from sidebar second. I save it, I confirm, yes, it shows up over there, we're all great. So now I go back to my terminal and I do drush configure export sync. So basically I'm saying export my current site configuration to the sync directory, which is I think the default directory name for Drupal 8 configuration. Once I do that, it's actually gonna ask me, it's like, hey, there's one file that has changed. And if it said something like, I don't know, node content type article, I would say, hey, something went really wrong there. But I see, no, it says block, block, Bartik search. Just the name is gonna tell me like, it's reasonable what just happened. So I'm going to export it. And immediately, I can actually just do a git status here. And I can say what's going on in my file system. And I can say, oh, there's one changed file in my file system, same one that they mentioned above. If I actually want to see what that difference is, I can just do a git diff. And again, since I only have one, it's just gonna show me the one file. It's gonna say eliminated the line region second sidebar. And then it added the line region sidebar first. So it's really easy for me to tell in git to sort of in my mind. Yes, this is what I did. It seems reasonable. I felt like for features, I love features for, well, I loved and hated features for Drupal 7, depending on the day. Yeah, but I mean, it made things possible that wasn't possible without it. But the git differences when you're doing stuff like that were not as clean. It's just like, okay, I can really see just one small line changed. The other important part is because it's not in one big file. If somebody else made a change to another block and then we're merging those things in, we're not gonna have any kind of merge conflict unless they edit the same block and really the same line even. Which is, no, it could happen, but not as likely. And then I would just do a git commit message and say, hey, I, obviously you're probably gonna have more changes than just that. But I'm just gonna say, well, I moved the search block. I'm gonna misspell it here. And then I'm good to go. We're not gonna get into the whole workflow for getting it up there. But basically, I could push those changes up. Other developers can pull them down. And then we could pull them down from production. So we're going to have questions later on. But if anybody had any particular question on the workflow, that type of workflow, so we'll go over more later. All right, okay, so another problem with Drupal 7 blocks where there's really limited visibility settings. So if you ever use panels, you could, for panels variants, you could use a lot of different conditions to say when should this variant tape be used. And then for each individual thing you placed in panels, you could also have visibility settings that were really complex to say. This should only show up for anonymous users. Or this should only show up if the node I'm looking at is an article. So Drupal 7 core though in the block form had very limited visibility settings. I could say on a certain content type, I could say for a certain roles. I could say on certain paths, but not much more than that. But Drupal, and that made us sad. But Drupal 8 has also limited visibility settings. So what is going on here? Why do we have the same limited visibility settings in Drupal core? Actually, Drupal 8 has unlimited visibility settings. So this is also Drupal 8, and you can see over on the left, we have a whole bunch of different conditions that we can apply to that block. So what is happening here? This is both Drupal core, one with very limited visibility settings, and one with sort of unlimited visibility settings. So what's going on? So what we're looking at here with tons of visibility settings is actually Drupal core and C tools. So C tools provides condition plugins. And actually, the reason C tools provides condition plugins is because panels needs condition plugins in Drupal 8. So instead of putting those condition plugins in panels itself, it puts it in C tools, and then panels depends on C tools. So that's a really, and then other modules like rules would also do that too. So in Drupal 8, visibility settings are just condition plugins. And then C tools will make the condition plugins, but then core automatically gets them. Because condition plugins are sort of a generic thing in Drupal 8. So in Drupal 7, context had condition, visibility settings. Panels had visibility settings. And other in the rules had conditions. So all of those in Drupal 7 were totally separate things. In Drupal 8, they all implement a condition plugin. So if you make it for one module, another part will automatically get it. So the fact that C tools provides these, even though they were thinking, well, we're making these for panels, even if you don't install panels, you still get that added bonus. I was going to start the timer, but remind me at 15 till. Yeah, how much time do we have left now? Okay, all right, so and if none of the condition plugins that any contrib module or core provides is good enough for you. Condition plugins are basically in one class, and this is pretty much the logic you would need. I think this is for checking if it's a particular content type. But you basically just have to implement the plugin and overwrite the evaluate method. And you could have any kind of logic you want in here to basically, if you had very special business logic, it's really easy to write your own condition plugins. So another problem in Drupal 7 is Drupal 7 blocks were not fieldable. It was a caveat without beans or boxes or fieldable panel pans or any number of modules I may have forgotten. But anyways, basically there were solutions, but they didn't come with in core. And also it was kind of a divergent solution in Drupal 7 ecosystem. So it wasn't like everybody was using the same thing. It was not like a consolidation of effort around that. So sad. So Drupal 8 blocks are fieldable. We have custom block types, which are similar to content types for nodes. And we have different fields for type. And we can have a custom block library that we can reuse. So this is an example of different types. We have a basic block, which basically is just text and a title and text. And then we have a map block, which is basically just a simple map field on a block and a user promoter block, which is just an entity reference to a user. So they just use all standard fields. Any field that you could put on a node, you can put on a block. So this is our block library in that case, where I have one block that's a map of New Jersey. One is a user of the month block, and then one is a map of Princeton. So example here with the left top block is the user of the month block. Einstein is the user of the month. And then down at the bottom, we have a map block that just has a, you enter a location and it renders a map. So the fact that we're using standard fields basically means you kind of have unlimited block types in Drupal Core, depending on what you have installed for fields for contrib. The other problem is blocks in Drupal 7 could only be placed once. So if I made a view of, also sad. So if I made a view and I wanted to put it in a block but show it sometimes on the right and sometimes on the left, I would actually have to make two versions of that view. If I did not have panels or context installed in Drupal 8, you can have different configuration settings in each placement of the block. And then also different visibility settings. So an example would hear is maybe on articles, the user of the month shows up over on the right in the second sidebar. But in the pages, maybe it shows up on the left. So it's just placing the block twice and using different visibility settings. Another problem with Drupal 7 blocks is they, not everything was a block. So everything in green here in Drupal 7, and I actually had to install Drupal 7 to do this. I hadn't done that in a while. I actually had to install it because I forgot what wasn't a block. So just for this presentation. So everything here is a block that's in green. But all this stuff, the tabs, the branding, the menu up on the right, the page title itself, wasn't actually a block. Whereas in Drupal 8, everything is a block. Pretty much everything, like the toolbar up top is not a block. Good to get a picture. I made one mistake in making this slide. There's a green line around the whole thing. That's not true, that's not a block. But, and actually I missed one block there. But this is a block, this is a block, the tabs are a block, the site branding's a block, that menu's a block. So all the benefits, as far as placing blocks, maybe don't want the menu to show up on certain routes or whatever. Maybe you want the site branding block to show the logo in some pages and not the logo in other places. Stuff you could eat. So I think in Drupal 7, there was panels everywhere so that it could take over the whole page. We kind of get a lot of the same benefit of that in Drupal Core. So basically, the bar tick out of the box is going to just make everything a block. And if you kind of follow that pattern with other themes, you can kind of make everything on your page easily configurable. So we get to the admin screen. So this is the admin screen for Drupal 7. So one of the problems I always had with the admin screen is, if I have a particular block that I'm looking at and I have say 20 blocks on the block screen. If I look at any individual block, I have no idea when it's going to show up. Because it's likely going to have visibility settings. But I can't look at the page and just know where that particular block is going to show up or that. So it gets really confusing. So part of the problem in Drupal 7 and why panels and context was so great, it's not only what you could do, but how you could manage it. You could technically still do a ton with just core blocks in Drupal 7. It just became really hard to manage after you had more than just a real small number of blocks. So you love this screen? This is the great, everybody use this, Drupal 7? I didn't personally. Okay, so that screen made me feel. I want to go to caveat that yeah, there's an expression like the thing you hate somebody put their heart and soul into. So I'll get to why I think one of the biggest problems in Drupal 7. And why this screen was a problem not necessarily because how it was made. So Drupal 8, you do have a bit of differences. You have this place block where you can usually just say, I want to place a block in this region and this actually came from a usability study that they did where people didn't understand. Basically when you place the block at the very bottom was the actual region you put it in and there wasn't a link per region to say I want to place it in this region. So conceptually it was hard for beginners to remember where they were placing it and you had to go into the demo screen to see the regions and then come back and remember the names. So now you can just place a block, then you give a little search screen here, you search for the block you want. But the Drupal admin screen does have this problem of where do any of these individual blocks show up. So that problem wasn't solved yet. So if you look at all of this and you're just like, I have to click each one to configure like where does this, oh this one shows up on pages only. Oh this one shows up on articles if the user is logged in. But as a management that is really kind of, still that part kind of makes me go, er, so we need a hero. So caveat, I wrote this module. So this is block visibility groups. And basically it sticks with the core blocks page but just makes it a little bit better. Let you manage blocks in groups. So an example would be I want to manage all the blocks on articles together, all blocks on pages. Maybe I want to manage all the home page for anonymous users and then the home page for authenticated users. So on the blocks page it just adds some conditions up top and it says, okay you're currently on the blocks page but we're only showing you blocks for, what is the example here? Node bundle is article and the user is a member of authenticated user. So any block that you add in here will automatically only show up for them and then also you can only see those blocks. So it makes it a little bit easier. So basically, we're looking at the group article for authenticated user and then we see our conditions here. We can add new conditions. So instead of when does this block show up, when does this block show up? I know when all these blocks show up just by the fact that I set the conditions and then I place blocks individually based on those conditions. And it also makes it easy to later on say, I want to, maybe it was for anonymous, I made a group for anonymous users and then maybe actually I want to add a role, new users. So anonymous users and new users should see the same blocks. I can easily go and just add the condition in one place and then it works for all the blocks in that group. So these example visibility settings are articles for authenticated, basic pages, home page for anonymous, home page for logged in. But what is Drupal 7's single biggest problem in blocks? Any ideas? So in my mind, the biggest problem is they were made in 2011 and they were frozen. So basically, you couldn't get new features into core blocks. So came out in 2011, we knew we wanted to make it better. So then you make it better in contrib space and everybody starts working on Drupal 8. We no longer have that problem. So Drupal 8, we have semantic versioning. Dries talked a little bit about this today. So basically it means we can put new features as long as they don't break backwards compatibility in 8.2, 8.3, 8.4, 8.5. We have experimental modules, which means we can get those modules in and they don't have to be perfect and we can iterate over them a lot faster. And also we have regular releases. So 8.2 is going to come out next week. 8.1 came out, I think, six months ago. But we have regular six month releases. So we can add the experimental modules in and then we can, I think it's like a year, to get them to stable. So Drupal 8.x, so the best may actually yet to become for the block system in core. Drupal 8.2 was very good for blocks. Or will be very good for blocks. I guess it's out there for you to test right now. But it hopefully gets released next week. So warning, what I'm going to show you is experimental modules in Drupal 8.2. They're experimental in that we don't guarantee backwards compatibility. So that's in the Drupal community between releases between 8.1 and 8.2. You can't break backwards compatibility, except if they're experimental because you get a warning, hey, this is experimental module. This may not act the same way. It may not work perfect. But I think definitely they are ready to test. And that's, we need feedback to see, how does this work? Is this what you would expect? How can we do it better? So let's look at in Drupal 8.1 and 8.0, the current way to place a block. So I go to structure, block layout. And then I go and I pick a region. I hit, actually first I'm going to demo the regions because I don't know what they are because I'm new. I want to put it in the second sidebar. I'm going to go back. And actually I just had to hit the back button because I couldn't figure out how to get back. And I'm going to pick my region. I'm going to place it in there. I get to search for my blocks, which is great. Powered by Drupal, right? I'm going to save it, no conditions. And I'm now to go back to the site. And I look at it, it's like, oh, it's there, cool. So not super hard, but also not super intuitive if you're new to Drupal. If you've been using Drupal for a while, it's probably like no big deal. I know how to do this. So let's look at the way with the place block module. So this lets you place blocks from any page. You don't need to go back to the admin pages. It's great for beginners. And I think it's also like a click saver for any of us who've been around for a while too. So let's look at how you place blocks in 8.2 with the experimental module. And hopefully 8.3 or 8.4, this will just be like the way you place blocks out of the screen for a second. Okay. So we go up to the top to place blocks. All of our regions now have these little plus signs. So we can just say add the block here. You don't need to understand this is the second sidebar. You just need to say this is where I want the block. Again, you search like before, search for the block. You place the block, no conditions, I'll just save it. And boom, it just shows up. So I never had to leave really besides the modal and we can get rid of the modal soon. I never had to leave the front page of my site and I see the change right away. So another experimental module is, okay, is the settings tray. So if you've read any blog posts of Dries's recently, he may have referred to it as the outside end module. I'm sorry, I named it that. It's probably not a very good name for it. So now it's called the settings tray module. So again, experimental module coming in 8.2. Should be a YouTube video there. Oh no, there's not. So enhances the edit mode that you get with quick edit where it kind of piggybacks off that. And it quickly lets you edit existing blocks on the page. And it lets you edit the related configuration. Basically, we're trying to give you easy access to the stuff you actually want to change. So imagine that you are a beginner, or image you are a beginner. And you just installed Drupal. I actually fixed it up top, but forgot to fix it. Yeah, that's all right. Okay, you go to the homepage and you want to change the site name. So let's look at this. So I click configure block, I go back to the back, and can I change the site name back there? No, I cannot change the site name. So for some reason I have to go in and out of presentation mode. So as a new user, I might be thinking, where is the site name? I clicked on the thing that had the site name and I wanted to change it, but it took me back to block configuration. Now, as experienced Drupalers, you may go, yeah, because it's a different thing. But we're sort of thinking of as you're new, you don't know that there's a block placement thing that's different to the site name. You just know that you clicked near the site name because you wanted to change the site name. Okay, so let's look at how you could do it with a settings tray. You click on the title, update the title. Okay, so I go here and I click here and I do a quick edit, and it comes over on the right. Oh, this is a menu one. Same idea though, I'm clicking on a menu and I want to change the menu. I might have reordered my ones. Yeah, and so basically here I want to enable new menu items, maybe I want to change the title. And this actually gives you an example of, gives you an example of wanting to do two things. I want to change the label for a particular block and I want to change something about the menu. Now on the back end, those are two separate things, the placement of the block and the configuration of the menu. But conceptually, you know, that's maybe one thing to a new user. So let's actually look at something. This also could possibly be the experience for adding blocks in 8.3 or 8.4, actually adding or editing multiple blocks. So I say I have the article content type and I want to place the fields of the blocks in different places. So I'm going to click over here. I'm going to look for the author of the node, authored by place. I'm given here, because this is actually C tools, adds blocks per field. I'm going to say I want to show the author as a formatter of an entity and I want to show the article view of the entity and this slider here is. So this is basically the settings trade being used with block place. So this is the idea that we could start to use the setting trade for a lot more stuff, but you see we haven't actually done that. I just have a site that I've converted everything to the settings trade. So we save this and it automatically shows up over here. Now I want to place a block. I want to place the image for the article over on the right. I'm going to click here, search for the image field, click it, choose the formatter for the image, solve the scroll problem. I didn't want to edit out the masking that's from you guys. I figured you could handle it. And then finally I'm going to go and I'm going to add the tags down at the bottom. So you can see here where you get to have a very sort of panels like experience of just grabbing fields and putting in different places. This is only with, the only thing you actually, this would just take the two new experimental modules in Drupal 8.2 and then C tools. They wouldn't open up in the tray, place block would open up in the top, but you start to get that experience and then I'm going to skip putting the tags in. I jumped here. And then if I didn't make all the settings correctly, I could actually go in and say I wanted to change this image to use a different style. I could just do a quick edit, opens up in the right. I want to use the thumbnail and I save it. So all of this without actually, going back to the admin screen. So this is basically place block, setting stray and C tools. But easily, like I said, the worst thing about Drupal 7 blocks is they were frozen in 2011. But now, we've already added two new kind of cool additions to the block actually in the block module, but to deal with blocks and we could start to add more. People think actually a field for every block is great, then we could add that if we want to. But basically the idea is we can add new cool stuff as we go along. So other related blocks, I'm actually going to go through this part kind of quick. Field is blocked, which actually probably I would recommend C tools instead of this module at this point, but it basically adds a block for each field. Let's get through that quickly. But the other thing that's really great about this though, that C tools and this module both benefit from is so many more things are fields in Drupal 8 than they were in Drupal 7. So published status, authored by title, all of that is fields in Drupal 8 where they weren't necessarily in Drupal 7. So modules had to do special logic. Say if they wanted to expose all those things as like a field block. In Drupal 8, basically all they have to do is, I want to expose all fields as blocks. You get so much more than the same module would have got in Drupal 7. C tools adds extra views and blocks configuration or configuration in views blocks. It gets you closer to views content panes. If people have used that in panels, actually it was part of C tools, but usually it was used with panels. It gets you closer to that just with regular views blocks in Drupal 8. Again, it gives you the one field per block. It gives you block UI improvements and it gives you the extra conditions. So if you're trying to stick with core blocks and you're like, I don't want to do a panels yet or other block related modules, I would recommend installing C tools and see what improvements it has. So let's just skip through those. So to the modules that I'm saying you might not need. Panels is still great. I probably would use panels eventually if I was making Drupal 8 sites soon. It's at beta four right now. It's over 3,000 Drupal 8 sites, and but it might not be needed for a lot of sites where you did need it in Drupal 7. So I'm not saying don't use panels. It's just for me, if I was making it, I would consider site by site whether I would actually need it. Context, I think, is a work in progress and or stalled. Last time I checked, the slides will be out there, but if anybody's interested, they could go to this node and see what the latest progress is. There was work on GitHub, but I checked this week and I didn't see any progress. So conclusion, core blocks are better in Drupal 8. Just out of the box, as soon as you install Drupal, you get a lot more benefits. Core blocks plus contribe, really becomes something I'm bordering on awesome, I would think. But also, obviously, more contribe goodness. I think one of the things that really makes this different than in Drupal 7 is the fact that we have so many underlying systems that we thought about in the Drupal 8 development process, and one good example is conditions, is panels, rules, and context all had these conditions. Something should happen in a certain condition. But they all were separate systems. So if somebody made a condition plugin for context, nobody in rules or panels or the block system got the benefit of that. Now, because we have unified that, if you make a contribe module that adds a new condition, core blocks gets it, rules gets it, panels gets it. So you can use it in so many more places. Also, the thing that I think is great about Drupal 8 blocks is we can add more stuff and we can experiment a lot faster so that the block system that I've shown you now for Drupal 8 and why I think it's awesome, there may be reasons I can't even think of that now that might make core Drupal 8 blocks so much better in a year or something like that. All right, so questions? It did, thanks. So if I go and I enable these experimental modules, place my blocks, do a bunch of work, and then for whatever reason, I have to yank out these experimental modules to my setting stick? Yes, so I, okay, I'm glad somebody else brought this up because I did not want to bring this up. I personally think that the two modules that made it into 8.2, they're usable, but they're experimental for sure, but if you're using them locally on a local environment, not on production, but you do local development, they do not save unless, and again, they're experimental, unless we really mess up, they're not saving how blocks are saved. So you can just turn them off and on production, the setting should stick. Caveat, they're experimental, but I think, yeah, you could do that. Caveat, experimental. You know, because we may change these modules, I'm only actually involved in, outside in, I'm not, or the settings tray, I wasn't really involved in place block, but you know, those could be changed, and it would break, so what it would really break is it would break any module that tried to integrate with them, like do not well. If you expect to write a module that integrates with place block or settings tray right now, realize that you will have to update your stuff as we break them, but potentially, you could use them to place blocks and then turn them off and you'd be fine. Caveat, experimental, yeah, so, yeah. Any other questions? Yeah, so that is definitely something that would be awesome and I think should be, so you get into a lot of problems of, like you would wanna like do the change to the menu and see it happening over here, yeah. That, we should figure out a way to do that. That basically is the direction that we wanna go in. There's a lot of technical problems to that because you would have to basically, you know, go to the server, render it, re-render it. The way it is now, you'd have to go to the server, render it, replace that part. I think one thing that could potentially, yeah, I guess also like, not just questions, I wanna have questions and ideas since you know, Drupal 8 is evolving. If people have other ideas they wanna talk about for improvements we can make to Core Box. But one thing that along your lines that could make the experience a little bit better is the refresh list module. How many people have seen that? I think he demoed it. But the idea is you click the page and instead of it reloading, it only reloads the parts that it want. So if refresh list got into Core or if somebody could actually write this as a contrived module against Settings Tray, you could actually save, have the Settings Tray save it and you could use refresh list to only update what needed to be updated. And it's, the tricky part is, if I have a menu block over here and I open it up and I change the menu settings and I save it, there's no guarantee that's the only place on the site, on the current page we're using the menu. But refresh list gets by that by saying, basically Glows to the server and says, with our new cache tag system says, tell me the regions that need to be updated because of cache tag invalidation. And it just magically figures it out and it will send you back, only the regions that need to be updated and they'll be updated in place. So if that was in Core, we could really make a great experience with saving the blocks and it just automatically looks like it updates everywhere. It would update everywhere. So that would be awesome. The refresh list module is like something that's, I think on the line to get into Core but that's not to say somebody couldn't actually experiment it with it you can basically do what I'm talking about in Contrib right now. Yeah, if anybody had time and you could check with me I could show you how to do it. Any other questions, ideas, problems with that we can improve Drupal 8 blocks? That's perfect, like no other future requests. I have a lot of time to work on Drupal 8 blocks if anybody has other ideas. We do that well, especially in Drupal 7. Yeah. Bean allows you to give content managers the ability to manage their blocks more easily without giving them a global access to block management. Yeah. That's a problem we're confronted with regularly on Drupal 7 usually. If they want to be able to manage a single block we have to tell them not to touch any of the other blocks. So potentially you could do that now if you had a module, I don't know what the access modules are in Contrib and Drupal 8, but potentially you could get a Contrib module that allows you to have different access for different entity types and you could show them a list of their blocks and they could actually change. So anything you could do, say for nodes, since nodes, that's not true. But potentially there might be a Contrib module that lets you do fine grain access control on entities. You could use that because custom blocks now are just entities. But that would only work for custom blocks not like the branding block or a menu block and stuff like that. But if you were dealing strictly with custom blocks, a generic entity access module might be able to handle that. Would that integrate with the GUI effects of the ability to reach? I think right now we are actually checking, I'd have to check. We may be actually checking for blocks administration. So one idea would be maybe the permission for the setting straight on a block should not be blocks administration. It could be the access to update that particular entity. We haven't thought about it in that way, but yeah. But usually it would be the same unless you had a Contrib module that changed that. But that might be a reason to actually check the block instead instead of the permission because the Contrib module could change that permission. Any other thoughts, questions, how this works? Yeah. Yeah, yeah. They're looking for already on that page. Oh yeah, sorry I'm supposed to be repeating the questions or go to the mic, yeah. So the question is about the blocks layout page because I think it's much improved especially for those of us who know Drupal but for people who are new, sometimes people come to that page and are confused when they don't see things that are obvious that they expect to be there, like new blocks. Especially when you're enabling a new module, let's say the multilingual modules to enable them and then you don't see the language switcher. Be nice to have like a prompt. So sort of backstory on why this has changed between Drupal 7 and Drupal 8. So the whole idea in Drupal 8 where you can place a single block multiple times kind of relieves the need for that part at the bottom of a Drupal 7 module where you say these are all your disabled blocks because really those were one-off things, you didn't have them twice. Whereas in Drupal 8, a single block would place multiple times so it doesn't make sense to say this one particular one is disabled. But yeah, once you hit the place block whether it's in the new stuff or the existing one you get a list but like you said you don't know that that list is there, right? Unless you click it, you have ideas, Kevin. So yeah, the sort of the North Star designs that we're working towards with these modules is that you'll be able to place blocks from the settings tray as well. So that we want the user to not have to go to that, especially the new user, the person who's unfamiliar with Drupal to be able to click a place blocks link and then to have the blocks show up and then also do things like automatically filter the list of blocks to blocks that have either been recently updated or updated by that particular user so that those things are coming to the surface and that people get, like you say, people have an expectation that they wanna get the block that was just added or that was just updated or that they worked on themselves and immediately add that thing and also be able to see it, be able to see a preview of it and then add it and those are sort of enhancements that we're not seeing yet but like Ted said, we have lots of things that we can add because we have semantic versioning and we have experimental modules so look for more of those things to be coming soon and then also I was gonna mention things like so Ted showed the way that you can create these visibility groups for blocks. We'd like to see visibility groups for blocks on the front end as well so I could say for example, show me this page under this particular context of a user or of something in the URL, et cetera. So one other thing about that idea is one benefit again of other changes in Drupal 8 that are sort of making things easier to do in Drupal, easier than they were in Drupal 7 is since blocks are configuration entities, you could potentially make a view now yourself and make a link in that view to place the blocks so you can make a view of blocks and say I wanna place this block so without too much work, a contrived module could have a link that says available blocks opens up in the settings tray and says here are your available blocks and each one would have a place block link so or you could just have it to where they have a separate page they would go to that they know that these are all the blocks and it would take you to place them so the fact that they're config entities and no, that's not right, sorry, they won't work with views, sorry, take that back, I don't think, anybody else, you can't list config entities in this. Yeah, you can't do that, nevermind, you could do it in code really easily but you can't do it with views so you actually, a contrived module could really easily say list blocks that under a certain condition and give the user a page to list those or maybe open them up on the side if the user is logged in or something like that but yeah, can't do it with views, sorry, sorry about that. Yeah, ultimately the goal is to do that page. Yeah, yeah. Just be able to see them all. Yeah, I think the hope of the place block module is that you, new users wouldn't have to go to the block layout page as much so they would just see the link to place a block and at that point they're immediately given the list so they're not on the block page looking for a list, they're just, all right, I guess you place your block, pick your region and immediately you're given a list, immediately after one step but region or the blocks you want are obviously the most important things in that process. Any other question, ideas? Or what could be better in core blocks? Yes. Okay, yeah, so the question was we looked at the field as block thing, can you get the entity reference? Yeah, so anything that is on, so caveat, you can put something on like an article page that's a field for something else and it won't show up but if you manage it correctly, yeah, you can say this node has an entity reference to another node or to a user, that's just a,