 Yeah, so I was just about to kick off by reminding everyone that this session is being recorded and it will be uploaded to WordPress TV and to YouTube and be added to the Developer Hours playlist on YouTube. Do feel free to turn on your video, it would be great to see you all. Please remain muted during the presentations but it would be lovely to see some faces pop up on our screen. It gives a feeling of, you know, we're actually talking to people and not to sort of gray boxes. Awesome, awesome, lovely to see you all. So today's session is all about editor extensibility. We're going to be exploring editor extensibility today and we have two presentations by two very experienced developers. Nick Diego is going to talk about client side and server side filters and he's up first and then up second will be Ryan Welcher who's going to talk about Slot and Fill. They're both sponsored contributors to the WordPress project and a long time contributors. Each presentation is going to be about 20 minutes I guess. Is that right guys? You've awesome and then there's going to be about five to ten minutes after each presentation for Q&A. So either put your questions in the chat or raise your hand using the reactions button on the Zoom toolbar. Okay just going to run through some announcements before I hand over to Nick. First off I'm going to post a couple of links in the chat here. First up WordPress 6.3 is currently in development. I think the Beta 2 came out yesterday was it? So that's available for testing but you can also get involved in development or testing of WordPress 6.3. Hop on that link to check that out. Ryan and I were both at WordCamp Europe a couple of weeks ago which was great and WordCamp US is the next major flagship event. That's coming up August 24th, 26th. There's a link in the chat to that. I don't know if tickets are still available but go and check that out. As the pandemic recedes in our memories local WordCamps are starting to be scheduled so go and check WordCamp.org for what's coming up in your area. And then finally for the announcements next week on the 6th of July which is next Thursday there is the Gutenberg Times live Q&A which is going to be about leveraging Gutenberg's architecture to take plug-in development to next level to new levels. Sorry so follow that link if you want to participate in that. Okay with all that out the way it's time to move on to our talk. So let me first of all introduce Nick and Ryan. So Nick do you just want to tell us a little bit about your background? Sure. I've been building WordPress plugins for a long time. Previously I was a developer advocate at WP Engine and recently joined Automatic. Similar role but focusing full-time on WordPress core.org stuff. Yeah just like building stuff like sending the editor and like contributing to the WordPress project. Awesome and Ryan tell us about yourself where do you come from and how did you get here? Well I'm in my garage so I just walked but I have been a developer for about 20 years now give or take. I have been using WordPress since about 2009. I used to work at an agency called Tenup where we did some really interesting things and now I'm a developer advocate and I get to do all kinds of cool things, build cool demos and talk to cool people like you about Slothill and various random things. So that's it. Amazing thank you. Yeah so we clearly have two highly qualified speakers today. But yeah let me hand over to Nick then who's going to talk about client side and server side filters. Over to you Nick. Great thanks so much Michael. So one of the things that I think is we hear a lot about is how do we modify the editor based on our needs? How do we change things? And that's kind of what we wanted to talk about today in these two different topics. One area that I have been focused on a lot is filters. Filtering the way that theme.json settings and styles can be managed within the editor. For those familiar with theme.json there's a whole section on settings that will turn on and off different things that is provided by your theme. But there's filters to modify that after the fact both in the editor and the client or server side using PHP. So I recently wrote an article about server side filters which is pretty cool. So I'm going to cover that to begin with. Some of you may have already presented it at a hallway hangout. So this might be a rehash for folks. I'm going to kind of speed through it to show what it can do not go through all the code. But all the code that I talk about today is in that article. And then I also have put together a little demo plugin that has all the code that I'm going to talk about today. So the goal today is to show you what's possible as opposed to going line by line through the code. I will show you the code. But it's more to kind of show, demonstrate what you can do with these filters. And hopefully the references provided will show you the nitty gritty details if you want to learn more or apply yourself. So we're going to start with the server side filters. There's actually two that I'm going to talk about and a couple different examples there. And then we'll talk about server side filters which I'm currently writing an article about. So that will hopefully be out next week. But give you a taste of that. So I'm going to start by sharing my screen. Okay. So hopefully everybody can see your adventure awaits. Good there. Perfect. Okay, cool. So the article that I mentioned is called curating the editor experience with client side filters. And the filter that we're going to talk about is it's called block editors use settings before, which is a bit of a mouthful. What we want to do here is your theme provides a theme.json file. And let's take a quick look and we can take a quick look right now. I'm using the 2023 theme, just your stock 2023 theme. We come over here to theme file editor. We can take a look at the theme.json file. This theme.json file is huge, but the main components, you have the settings section, and then you have the style section, so on and so forth. And again, this is going to be provided by your theme. But what if you wanted to say apply specific settings to blocks based on their context? In theme.json, you can, for example, set a color palette, and that's global. You can also set the color palette per block. So if you want to have a specific color palette for button blocks, you can do that in the theme.json file. But what if you wanted to have a specific color palette for button blocks when a button is inside of a cover block? So the context block that you cannot do in theme.json. So there's theme.json is great. You can do a lot, but there's limitations to it. And that's where these filters come in. So this filter called, I always forget, it's, let's see here. Block editor use settings before. Oops. And I'll zoom in so we can see this a little bit better. This is the name of the filter that we're using here. And what this does is that when the editor loads, it looks at each block and it looks at the settings that have been applied to that block, and it allows you to filter them. And so using a very simple example, imagine a situation where we wanted to set the units that are available to the column block to just pixels. Right now, if we come over here to my editor and we come look at page here, we can go to a column block and we can see, it zooms in the way, that the width over here has all these different options for pixels. What if I just wanted to restrict that to, sorry, all these different options for units? What if you just wanted to restrict that to pixels? You don't want to give your clients all these options. You just want to have a specific pixel option. That's something that you can do in theme.json, very straightforwardly. But here, I want to show you how to do it with the filter. You can also do it with a filter. So what we're doing is we are, the filter is saying, okay, what's our block name? In this case, block column. Then we're, it filters by setting. So we're going to say the setting name, setting units. And we're just going to return an array of pixels. Now you might be wondering, where do these setting names come from? Well, if you take a peek here and I'll drop the link, this is the theme.json living reference. Where did my chat go? This here, this will give you all the different settings that are available in their, in their names that are available for theme.json. So that's what we're doing here. We're using the set, the spacing unit. So if we come over here down to spacing, you can see here that under spacing, we have units and it takes an array. So what I'm doing is I'm returning just an array of just pixels, instead of all the different values that are, could potentially be available. Now, when I save this, and I come back over here to my page, remember now that I can select all my options. I'm going to refresh back over here to our column. And we, I can't change it because we only have pixels. So there's no longer that drop down. Again, this is something that you could do in theme.json, but something that's very easily to do with filters. Now I have a bunch of other examples in here, but let's just jump to an interesting one. And then we'll continue talking about more examples. So one of the, I mentioned earlier about the context of a block. So I have an example in here, scroll down a little bit. I think it's the last one here. Yep. So what we want to do here is when a button block is inside of a cover block, pass a specific color palette, instead of the full color palette. So I'm going to come back over here and go to a different page that I have set up. It's called under the sea. And if I scroll down and I have my button here, when I go to color, my text, you can see that I have all the options and the default options, which, with which to choose from. But in this certain use case, when a user adds a button to a cover block, which is what we have here, I don't want them to be, I only want them to be able to choose block or white. I don't want them to have all these options. That's, they're going to mess up their design. There's too many options. This is not something that you can do with the InvetJSON. We need to use the filter for this. So this example, turn, again, these are all in the article. I know I'm going quickly, but these are all in the article, which you can look at in more detail. What we're doing here is we're saying, if the block name is button, what I'm going to do is I'm going to use these selectors to get, figure out what its parents are. What are the parents of this button? We're going to get the block parents. Now, if a parent of that button is a cover block, which we have here, we're going to, we have a, you know, it's in cover. These are the settings that we want to modify if that's the case. We want to disable custom colors. We want to disable gradients. We want to disable the, disable the default palette. And we want to pass a new color palette of just base and contrast with white and black. Again, if it's in cover, we want to go through all of our setting names and update it with these modified settings. So now that I've turned this filter back on, we'll save. Give this a refresh. Now when I go to my button and I go to text, I can only choose black or white. I no longer have all those options. So this is a very, I know I'm going very quickly here, but you can start to imagine where you, maybe you have a, imagine you're managing a ton of sites and you create a plugin that has all these filters and you can, you know, deploy it across all these sites and you really lock down how your users manage content. Maybe you shut down different settings based on, for example, like typography settings. Maybe you want to type, maybe you want to heading or some text inside of a cover or inside of a, I don't know, a custom block that you've created. You only want to have certain settings. You can easily do that with this filter. So you can really get creative depending on your needs. These are some fairly basic examples. The next thing I want to show you here is, and this gets, so this is more about curation, right? We're kind of limiting the functionality that's available to blocks, limiting a theme that's based on settings based on blocks. Talking about extensibility, this is something I kind of stumbled upon somewhat recently. Maybe some of you already know how to do this, but there's another client-side filter called blocks.registerBlockType. And it can do a lot of stuff, but one of the things that you can do is that you can set block settings using this filter. Now, I wrote an article on my own personal blog, but eventually this will probably be an article on the developer blog. But if you want to sneak peek at how this works, you can check and try not to self-promote, but this is where these examples come from. In this case, one of the things that I've struggled with is we have all these different supports on blocks, right? We have the ability to set border radius, for example. Border radius is now available on a ton of blocks, but there are certain blocks that it's not available on. For example, you can't set the border radius on headings. So if you set the background to maybe this green color, you can't change the border because there's no border support applied. But with this filter, you can actually give this block block supports. Now, I will hesitate to say that you're giving a block block supports that WordPress doesn't currently support. But in a closed environment, for example, if you're building something for yourself or for a client and you know exactly what's happening and you're either controlling the whole environment, this is a valid approach because you're not creating anything custom. You're not creating a brand new way to modify border radius. You're using core block supports. You're just providing it block. Of course, there's going to be some caveats along the way. One of the areas that I really wanted to have border support was on columns. But with columns, you're going to run into situations where you have, when you put border support on something, you're going to have the content inside of it might expand out of it. These little things would have stopped core from adopting block supports, but then again in a closed environment, if you're building something for a client, you can take care of that. So what I want to do here with this filter is I want to say it takes a setting and a name. So this is the name of the block and the block settings. If I am editing a column block, a heading block or a paragraph block, I want to provide border support. Now, border support is currently listed as experimental. So we're doing things that are again, we're expanding the editor beyond what it can currently do. And the border radius, for example, is still experimental in core, mainly because some things haven't been fully figured out. Personally, I think it should not be experimental anymore, but that's a personal thing. But anyway, so that's what we're doing here. We're providing the block support to these blocks. I'm going to turn this on. We'll save. So now my update and refresh, come back to my heading. Now I have border support and I can adjust the radius like that. We'll make it a little bit more advanced. Save it. Go to the front end. There we go. So not only can you add border support, you can also remove border support. So while we're adding things, we also can remove things. So you can think about how you could use this technique to either remove supports, add supports, all that kind of stuff. And this filter can do a lot more than just modify supports. But this is just one example, you know, one thing that you can do with this filter. There's another example here, which I think is kind of interesting, is this has to do with typography supports. So one of the cool things in when you register supports for a block is you can assign default controls. So if we look at our heading here, you can look at all these typography controls. These are enabled by default by WordPress. You got letter case. Now if we go to, for example, a paragraph block, you can see that typography just has this one option here, just size. So it's a little bit, I don't know, people have their own opinions about should all the default controls be the same? Should they be different? Well, we no longer have to have that debate because with a filter, you can modify it however you want. So in my case, what I wanted to do is I wanted to standardize the typography panel for every block. And I said that I only wanted to have size and, what else did I want it to have, size and appearance. So now instead of having different blocks have different typography panels or the defaults in the typography panels, I wanted them to be all the same. So again, with this, we're modifying the block supports for typography by updating the experimental default control and undo this. Give this a refresh. And now when I go to heading, you can see that I just have size and appearance. When I go to paragraph, now I have size and appearance. When I go to button, I have size and appearance. So now every typography panel for all blocks that are using the core typography block support will just have size and appearance. And if they want to add more, they can. So really simple example, but it shows you the power of how you can use these filters to start modifying block supports, either to add supports that don't exist or change the ones that do. Really don't want to encroach on Ryan's time. So we're going to speed to the next example because I think that this one's really kind of interesting. So these are service, everything that I showed here is in JavaScript. So this is happening in the client. Now, there's other filters that you can use that are PHP based and our server side filters. And the one thing about those is that they operate in a different way, but they can also do a lot of really interesting things. And they might be more conducive depending on how you want to deploy these curation techniques. So I came up with a very contrived example. And my contrived example was, you have a page, looks like this. And I want to have a different color palette for when somebody logs into my site. I don't know why, but I do. The way that colors work inside the theme.json is when you define a color palette in theme.json, it creates a variable, color variable. Client side filters that I just showed you, if you were to register a new color palette, it doesn't actually create the variable that WordPress uses. Client side filters need to rely on whatever variables are already set in the theme.json file. So that's a limitation. And I go more into that in the article. Server side filters, the PHP based ones, they actually create new variables. So you can see here that I am logged in. Let me go over to this example here. You can find it under server side filters in the plugin. And I'm going to turn this on. This is not turned on. And when we take a look at the colors that are generated, you can see here that I have my base contrast primary secondary tertiary. This is generated in the 2023 theme. If I refresh this page now, you can see now everything's blue. And I come down here and you can see that the presets have been updated. They've been rewritten with my new color palette. And that's the color palette that's being defined by this filter. And this filter, what this is saying, and I'll show you this example is when you log in, you have a different color palette than when you log out. I'm checking here, is the user logged in? And then I'm passing a new set of settings for color. And the way that this filter works is it takes the existing theme.json and then it updates with your new data. And again, I'm going to have an article about this coming up. But it's really handy because you don't need to really worry about, it takes a lot of the, what's the best way to say this? It makes it very easy to handle this and you don't need to worry about the structure too much because if theme.json changes in the future, this will still work because what you're doing here is you're making sure that a version is passed. So if there's a theme.json version 3 and you have your setup using version 2, when you pass this, it will make sure that it updates your theme.json in version 3 once you do this step here, update with new data. So I don't want to get two in the weeds in this, but it's pretty future proof, as I guess is what I'm trying to say. And here's what we're doing is we're just updating the color palette with these new colors and then I also modified the styles to change the button colors because the button colors are set in a different way in 2023. But what you can see here is now when I log out, my colors go back to the original color palette. So again, kind of a contrived example, but an interesting way in which you can use this functionality. The last thing I want to show you here is another option that allows you to modify functionality settings based on the user's role. And I think that this one can be very powerful. And the filter that we're using here, actually, I'm going to drop the, did I give you the dev node example link, Michael, before this? If not, I'll drop a link later that shows you the filters that I'm using. But here I'm using the WP theme underscore JSON underscore data user. And what this is doing is that this is going to modify. So the way that theme.json works is there's a global theme.json. There's one that's provided by blocks, there's one provided by the theme. And then there's one that's provided by the user. And that's in global styles when you're editing global styles. That's what we're referring to here. I will cover this nuance in the article once it's written. But here what we're doing is we're going to modify the theme.json user data. And what I want to do here is I want to disable color control for every single user. And then I want to turn it back on if the user is an administrator. So you could imagine an environment, maybe a multi site environment with tons of sites, different theme.json files in the theme, settings everywhere. And you want to just have like a must use plugin or something like that. It just wipes out control for everybody for color. And then conditionally adds it back depending on roles. So here what you can do is here what we're doing is we're just passing this default settings that just disables color control for everybody. We're updating the theme.json. And then we're getting the current role of the user. And then if they're an administrator, we're going to pass back true. So I'll save this now. And we'll log back in. We'll log in as an admin. And we can see here that I have color control. We'll log out. We'll log back in. We'll log in as an editor. Take, oops. Okay. And now when we come back over here, there's no more color. So I'll leave it there and I'll let Ryan give Ryan the rest of this half. But I know that was very quick, but lots of different ways that you can use these filters to really modify and tweak how the editor works with regards to theme.json settings and styles. So all these examples, again, are in this repo. So you can look at them in more detail. And I know, again, I apologize, I'm very fast. But yeah, really cool functionality that you can explore and use in different environments. Cool. Thank you very much, Nick. That was a quick run through, but super comprehensive. Did you already post a link to that repo in the chat? I did, but I'll do it again. Yeah, do it again so that people have got a more recent. We have a couple of questions. First one's from Lisa. Is there a resource that shows the things that can't be done using theme.json? I'm trying to avoid creating custom CSS in my theme, but sometimes I'm not sure if I'm making the right judgment that it can't be done in theme.json. Gotcha. Yeah, sure. I think that this is a great, the living reference is a great guide. This will show you everything that's available. So there are things that we don't have, we have color, border radius, that sort of thing. We don't have things like drop shadow and text drop shadows. So I think that keeping an eye on the living reference is handy. One thing to note about the living reference, the living reference does not mean that it's in core. The living reference, because this pulls from the Gutenberg repository, this is what is in Gutenberg trunk. So it's not always what you're going to find in core. So that's one of the things that we've talked about a lot with regards to documentation. It's not always clear. If it's listed here, what's available in core. I know that's an area of confusion, but this is probably the best resource guide that I can point people to. Thank you. We've got a couple of minutes for questions. So if you've got a question, put it in the chat or raise your hand. If I see your hand raised, I'll unmute you and get you to ask your question. But in the meantime, Matias says, the selectors ecosystem is something that I need to learn more than we all. And considering this idea of finding the block context in the filter, does anyone know how to find if a block is, for example, inside the block editor versus the site editor? And if it's inside the site editor, how to get the ID of the current editing template? There is a way. I don't know if that's my head. Let's see here. I'll follow up on that. The second question, though, and this has been asked of me before and I haven't been able to find a definitive solution is if you're in the site editor and let's say that you're in the header template part or you're on a specific template, is there a way to know that? So for example, if you wanted to have a specific color palette for, I don't know, the homepage template or something, technically, I would hope that's possible, but I don't know. And I think that this is where some exploration is definitely needed. And if it's not possible, that kind of stuff needs to be possible. And the reason that we're having this conversation today is because we're starting to really focus on extensibility. 6.3 is pretty much out the door, but as we head to 6.4, at least us develop Michael Ryan, we really want to focus on extensibility because now that the editor is more mature, get it to a place where you can add the functionality you need. You can be able to figure out what template you're in, that sort of thing. So I don't have a good answer right now, but hopefully soon. There may be a way to do it. There's a data package available for edit site that depending on if you're trying to do this on the client side, you're trying to do this on the server side, those are two very different things, but you're trying to do it on the client side, you might be able to check for the existence of some of these functions that exist or these selectors. And then based on that, know whether or not you're in the site editor, because the site editor package would only be loaded in a site editor, and then you could probably, you might be able to get current template parts, parts, whatever, that's a horrible name function, but there's some functions in there that might return the information that you need, but you'd have to play around with it. I haven't had a chance to really dive into it. So there is a way, I'm sure, but it might be in the weeds a bit. Okay, thank you. We've got one more question before we hand it over to Ryan from Fernando. Is there a way to filter the block output? An example would be providing a mobile image option to the core cover block. So you could add a possibly, I think, because there's the render block filter, which is like this heavy-handed filter that you can, it's in PHP, you can do like anything with, you can mess with the entire block output. So in theory, I would imagine you could register a, perhaps a slot fill, a transcendent, talk about it in a second, a custom control for the cover block, where you toggle a new person to like upload an image, and they do something complicated with like the render block filter on the front end to do that mobile image. That's probably how I would approach it first. I don't know if you think any differently, Ryan, or? No, I think that's probably how you'd have to do it. And if you're doing, yeah, you'd have to do it that way, I think, because if you're talking about core blocks, they're all going to be static. So you're going to have to filter the output using the render blocks filter, I believe, I believe, depending on the specific circumstance, I think, yeah. Okay, time is now pressing on. So let's pass it over to Ryan now, who's going to talk about slot and fill. There'll be opportunity for questions. Hopefully, once, once Ryan's finished his presentation, if you've got, still got any questions for Nick, you know, put in your question that it's for Nick, and we'll come to that after Ryan's presentation. Over to you, Ryan. Well, thank you. I'm just going to go ahead and share my screen. Let me know if you can see it or when you can see it. It should just say extending slot fill with, extending WordPress with slot fill, my big stupid face on the slide. Cool. All right. Well, so first of all, thanks. So let's talk about what is slot fill? Slot fill is at the high level, it's an extension paradigm for WordPress and allows developers to add elements to existing UIs inside of WordPress. And this is specifically on the admin side, to be clear. Register, what you do is you register a plugin that contains content or what we refer to as fills to be displayed in a specific location or slot inside that whatever UI you're trying to, you're targeting. Sorry. Items are rendered outside of your element tree. So if you're sort of a React developer, you'd be familiar with the idea of like an element tree, like things inside of other things. This allows us to render things that are in completely different locations in a specific spot. And it's very similar. And I think it's even modeled after React portals. Currently there are 12 slots. Now two are experimental. So, you know, with great power comes great responsibility. And while they differ from actions, they are, philosophically, you can compare them to the two actions from the folks API in the sense of like they're both location based. So they appear in a very specific spot and that's where your code or your components going to appear. A slot fill system contains basically three components. The first component is the slot component. And wherever this component is rendered, any fills associated with it will have their content rendered there and accepts three props. I'm kind of flying through this because I want to get to questions. So if, so just please let me know if there's any questions, but I, you know, I will try to go through this quickly so we can talk about it. Here's an example of what a slot component would look like. The fill component, the contents of a fill component will be rendered in a slot with the same name property. So you'll notice that they both have the prop name associated and that's that's how they are connected. This is what that would look like in a very, very simple way. A slot fill provider component, this is the glue that connects fills and slots. So both the fill and the slot need to be wrapped by this component and we'll see how that works in practicality in a minute and it doesn't really accept any props. So a basic slot fill system is an application or component is wrapped in a slot fill provider. A name slot is rendered somewhere inside that app. A fill with the same name is rendered somewhere else inside that app. And then the fill content was rendered in the associated slot location. So we can, so this is sort of a contrived code version. So we're wrapping our my awesome app inside of a slot fill provider and then anything inside that, any fills and slots inside of that slot fill provider are then connected together via the name. In this case, my name, my slot. So this is sort of like a visual representation of what that looks like. So we have our slot fill provider in orange there that wraps our app UI. On the left, we have a slot. On the right, we have two fills. And then when this is sort of rendered, the contents of this fills are actually rendered inside the slot location. So how does WordPress do it? So what we've seen so far is a closed system. We have all of our components. We know all of our components are all inside our app. Our app is rendered, you know, and it's built and we're done. Well, we don't have access to the, as extenders, we don't have access to the Gutenberg source code in the sense of being able to just add more things to it and rebuild Gutenberg every time. So what we need is we need an entry point into the system and that's done using a function called register plugin. This function provides an entry point to this local system and it basically, there's a global array of what's called plugins available. And then there's another component called plugin area and this component accesses those registered plugins and renders them inside a hidden dev deep in the bowels of the source code of Gutenberg. So the register plugin function is part of the at WordPress plus plugins package. Except a number of parameters. We're going to have a name that identifies the plugin and then we have a settings object. The most important thing there is the render and that's going to be the component that we want to have appear in or that we want to have registered with the plugin. There's an icon that that's that you're going to associate and there's also scope. The scope is the scope is the plugin area that this belongs to. So we don't really use it right now. The existing implementations don't actually use that. So if you target something and it doesn't work, it's probably because well that and that's why so you should just just leave it undefined right now. It's mostly for custom stuff. So this is what that looks like. So we were we were going to call register plugin. We give it a name. We have a render the component to render and then we we pass an icon. But that looks like so the plugin area component renders all registered plugins inside a hidden dev. So we can define a scope for this. As I said, the current implementations don't define scope. So if you do you're they want render in the right place. So that's the register plugins must match the scope to be rendered and then it also said accepts not on error. So you're not going to be using this. This is just available. This is how your stuff gets put in there. So I'm just adding this for completeness. You're never going to actually do this unless you're doing something very custom. And this is what that looks like an example. So the slot fills the WordPress slot fill system. The slot fill provider wraps the editor provider component. Various slots are exposed inside the layout component. This is very in the weeds. Fills are registered using the plugins API fills are rendered inside the hidden dev by the plugin area component. Fill content is rendered in the associated slot. And this is sort of what it looks like. It's there's a lot more code in there, but this is kind of the idea. So we have our slot fill provider at which wraps the editor inside the layout. We have slots all over the place and then our plugin area, which is where the fills are going to be actually brought in. And then so this is what that looks like visually. So we have registered plugin that adds a list to the plugins. The plugin area looks at that list and renders all the fills inside that hidden dev. And then at runtime, all the, all the fills get put into the various slot locations. Yeah. So maybe we'll pause there for a quick second. That was a lot of info. If you have any questions, I can answer them now or we can wait to the end. I don't know how we're doing on time. We have about 15 minutes here, I think, right, Michael? About 15 minutes. Yeah. Okay. So if there's no immediate questions, I might just kind of power through because we're going to look at all the individual slots now. And then I have some custom stuff that we can get to you if we have time. But if not, we can, we can skip that part. Okay. So everything that we've seen so far is a very basic slot implementation and that's not how they are built in practicality. They are named components that usually have some sort of other functionality and inner components in them. For example, this is the plugin post status info slot fill. And it contains both a slot and a fill in there. And so the way that that's exposed inside our post status function. So this is actually in your post status at the very bottom, there's a slot fill. So if you want to introduce something there, that's where this would be. So inside our panel body, you can see we have a plugin post status info dot slot. So that's exposing the slot for use. Ryan, excuse me for interrupting. No, I'm good. Yeah. I know you've got a lot of content to cover in a short amount of time, but people are saying that it's a little bit, you're going through this a little bit too quickly. Okay. I just wondered if you could just sure. Yep. I guess I'll have to pace a little bit and no problem. Sorry. Lots of content. So yeah, yeah, yeah. Absolutely. So, okay. So, so we're exposing our slot here using the dot slot property of the plugin post status info. And then when we register our fill, we're going to import the plugin post status info from the edit post package. And then we're going to anything that's wrapped inside of plug in post status info becomes the fill content. So when we register this, and then when it's rendered, it's going to look like this. So the post status info slot fill is anything that you put inside of there goes where that little blue box is shown up. So there are our current, so these are the current available slots for the edit post screen. So we, I'm not going to name them all because I'm going to start saying plug in a million times, but basically, so we can go through each one. So the pre published panel, this adds a custom panel to the pre published side panel. So when you hit publish and then you get the are you sure that you want to publish that shows up the bottom there. And this is sort of an example of what that would look like. And then this is how it how it appears down at the bottom there. I've got my custom panel. And we've got post published panel. So this appears after you've you've published a post or any piece of content really. Again, this is some examples. Now, if you're like, oh, my God, I can't write this down. I have a repo that has all of this in there. And you can you can go and you can build it. And it's got custom examples. So I'm just sort of trying to get through the content so we can get get to questions. That's sort of what this looks like. The plug in more menu item, renders a menu like in the plugins group in more menu drop down. It can be used as a button or link depending on the props per provided. So there's a bunch of props in there. I won't go through them all for the sake of time. But this is how you do how you do that. And then that that appears in sort of the three button drop down there down there at the bottom. A block settings menu item adds new items to the block settings menu of any allowed block. So we're going to say we're going to define what blocks this should appear in by passing the allowed blocks array. And then that would appear there. This is the paragraph block plugin sidebar. I'm sure everyone's probably seen this plugin sidebar that this is the one that appears in the top right corner. So you you can introduce it like this. And then it appears in the top right. And that's what that little icon icon is. I'm sure I think Yoast was like one of the first plugins to introduce this. So this is very, very common. And you can do a lot of stuff inside of this plugin more plugin sidebar more menu item. The naming the naming is a mouthful every time renders a menu in the more drop more menu drop down to use to activate corresponding play sidebar plugin components. So this is basically that button down at the bottom. So if you click it from there, it activates the plugin sidebar plugin documents settings panel. This is my personal favorite. We can insert stuff in the sidebar of our of any post type. You you do it like this, import it and then add whatever content you want in the inside of that. And that ends up looking like like this. So you can add as many custom panels as you want there. Main dashboard button. This one is experimental. It's one of the one of the two experimentals. So we use it with with caution. You can replace the main dashboard button in the post editor and site editor. And it looks like this. So you can do that. Like I said, use it with great power comes great responsibility. So there's currently three slots available in the site editor. They are basically the same location, but they are pulled from a different package. So instead of it being Edward press slash edit post, it is edit site. So I'm not going to show those examples because they show in the exact same spots that you would see them. So a big question is, how do we get more? Where do we get more? Well, we need help. We need your help. So you can go to WordPress.com slash WordPress slash Gutenberg and, you know, open issues for use case. I've got a couple in there that I'm trying to work on. But you can steal all this code. Look at all this code either by hitting that QR or by downloading this link, downloading this link, selling my parents by accessing this link. I'll just, I'll, I'll drop that in the chat somewhere wherever the chat is. Like I've already done that. Oh, you did. Thanks, Michael. Okay. So there's, yeah. And then so we've got nine minutes left. So I can take questions. I can go over anything that I've already talked about, which might be helpful, or we've got some custom stuff in here that I can talk about, but it's going to be, I'm going to have to go through it real fast. So I don't know what you'd, what you'd prefer. Okay. I think we do actually have a couple of questions. Okay. I'll stop sharing. Sure. Matias asks, oh, no, sorry. Wrong. Hold on. Let me find, oh, there we go. Ronald, in fact, asks, yeah, Matias asks, do we have a list of the available slot areas, but Nick posted a link? So thank you for that, Nick. And then Ronald asks, what would be a typical use case for slot fills outside of the admin area? I don't think there would be one outside the admin. I mean, there could be, well, so sorry, let me qualify that question. When you say admin, are you talking about like the block editor or the site editor? Because you can definitely use it in other places inside the WordPress admin. Like for example, in this presentation in the repo that I think has been linked, I have an example of a dashboard widget that uses slot fill. So that's something that you could definitely use. Like a use case where there could be using slot fill to have a sort of a freemium plug-in with a free version, but then for a paid upgrade and then you can use slot fill to introduce those features based on whether or not there's a whatever, like a registration code or something. But on the front end, your chances are there's not much use for it. Ronald has clarified that he meant in the WP dashboard. Oh, yeah. Okay. Yeah. So anywhere. So if you want to look at the slot fill system repo that I have, there is actually an example of a dashboard that registers and we insert stuff with slot fill. So I think it's very powerful. You can extend anything once you get into the custom land of slot fill. Awesome. There is another question from Anton, but it might be useful, Ryan, if you hop onto the chat because he's put a little code sample there, which I think would be rather tedious for me to try and read out. I have a plug-in where I use this kind of approach to add a control to wall blocks. Would a slot fill also be able to accomplish this? And then a little bit of code there. Can you see that? Yeah, I don't think so. So you're adding a control to all blocks. So I would assume you're using the register block type filter that Nick was talking about. So the thing about slot fill is you need to have a slot exposed somewhere. And unless you control the code, the core blocks, for example, won't have slots exposed for you. What they do technically, it's the inspector controls, but that's a different sort of thing. But if you want to add a very specific control... Well, you could use the inspector controls to filter it via register block type, or not that one. Sorry, there's another filter. It's like... Oh, I can't remember off the top of my head, but it's basically... I think you're doing it. Yeah, so you're... Yeah, that's what you're doing. I don't think you're going to be able to do that with a custom slot fill. Well, you won't be able to do it with custom slot fill unless you edited that, introduced your custom slot fill, and then registered plugins to hit that custom slot fill. But at that point, you're going to be sort of running in circles, because that's what inspector controls is for, to be able to add more controls to the sidebar of a block. That makes sense. Yeah. Okay, awesome. Any more questions? So one of my responsibilities as a facilitator of this is to make sure there aren't any awkward silences during this event. So before this session, I did ask Nick and Ryan to give me a couple of questions just to fill in in case there was any... In case there weren't any questions from the floor. And Ryan said that his talk is so comprehensive, there won't be any questions. So prove him wrong. Come up with some questions here. Okay, we've got one from Chris. I'm not a developer, but questions... Sorry, let me just hot-pass this myself. I'm not a developer, but a question somewhat perhaps related to today's topic. Is it possible to code some features directly in a theme block that would also offer settings for those features in the Gutenberg UI? Or is this only possible via plugins plus theme blocks? So when you say theme block, are you talking about a block that is bundled with a theme? So blocks and slot fill are sort of two different things. You could have your theme introduce custom functionality via slot fill. You could also technically have... You could have a plugin do that as well. But blocks don't necessarily... It may not necessarily be the right place to add a slot fill like in a block itself. It is possible to code some features directly in the theme block or would also... Yeah, so you would use slot fill to add features to the Gutenberg UI. I think that's what you're asking, Chris. If not, let me know. I can definitely amend my answer. Yeah, I don't know if this is helpful, but if I'm reading this right, you could have... What Anton was saying, you could build custom functionality and add it to the inspector panel of blocks and then create a setting that interacted with that custom functionality in some way. I mean, yeah, you could definitely do that. Now, I probably wouldn't suggest putting it all into a theme. If you want to, you could. I mean, it's just code. But usually, themes are generally where styling lives and that sort of stuff and all the customization block stuff generally resides in plugins. It doesn't mean you have to do it that way, but that's the general approach. Responsive display for block. Okay, so I imagine conditional, hide things on mobile, show them on tablet, that sort of thing. That you could code all is part of a theme if you wanted to. Yeah, you could probably do something where you had it in the theme where the theme introduces some custom classes that you then access via some sort of admin or some sort of UI for a block that could be added via the theme. Because the theme functionality... So if this is what you're trying to do, what I'm imagining is basically a set of controls that says hide this block on mobile. So it's on off, for example. I know this plugin's out there that do that. I think I know a guy that wrote one. But I think that's what you're talking about. So you would introduce those classes via your theme and then you would introduce that functionality via a filter in the theme as well. That makes sense because those classes and that theme functionality need to exist together. And then you can just access, you can just filter all the blocks to give it that new control that just adds that class that the theme introduces. So I think that's what you're asking. So you don't need a plugin for that. You could do it with a plugin. The thing is any development related question is like, yeah, you can do that. There's a million ways to do it. So best practice would be to probably keep the classes and the UI kind of together. And whether that's in a plugin or in a theme is probably up to your use case. That would be my answer. Nick, do you agree with that, Mike? Thank you, Ryan. We're on the hour now. So let's wrap things up. So if you just head over to the chat and click those little three dots at the bottom, you've got the option to save the chat. So there were lots of links that were shared in the chat. So if you want to save the chat, this is your opportunity to do so and then you can access those links a bit later on. Just a reminder before we end that WordPress is, of course, open source and you can contribute in all kinds of ways. Head over to make.wordpress.org to find out how you contribute. We've run a few of these developer hours now and we've kind of moved things around a bit and tried to settle on a format. And what we decided is that from now on, we're going to hold them regularly on the last Wednesday of the month. So there can be a regular slot for these developer hours on the last Wednesday of every month. So the next one is going to be Wednesday, the 26th of July. So get that in your diaries. So it remains for me to say thanks everyone for joining us for this hour and thanks so much to Nick and Ryan for their excellent and informative presentations. Thank you guys. Thanks everyone. Thanks for having me. Appreciate it. All right. Goodbye everyone.