 All right, welcome everybody. Welcome to another hallway hangout. I'm your host, Nick Diego. And with me is Justin Tadlock. We're both developer advocates, WordPress developer advocates sponsored by automatic. So today we're gonna be, we kind of have a lot to talk about. Hopefully we get through all of it, but if we don't, that will just be some good content for the next hallway hangout. What we wanna talk about today is building websites for clients and some of the challenges or things that you need to overcome when you're doing that. So there's a couple of new features in WordPress for curating the editor experience, allowing you to kind of customize how the editor works, which might be needed for clients. And then that's kind of topic one, curation and some demos of some new functionality. And then topic two is gonna be talking about how to build or building block themes for clients. And Justin has put together a new boilerplate or sample theme, block theme that you guys might find useful. But again, starting with curation, if that conversation takes too much of our time, we'll just move the block theming to the next hangout. We really want to engage with everybody's questions and try to answer as much as we can. We have Alec on hand here who is one of the people to help with the curation. So he can answer even some more of the technical questions should those come up. But yeah, that's what we're planning on doing today and we'll both be monitoring chat. Again, please ask all the questions you can. I do have a little poll that I'm gonna run just to kind of gauge the audience and where we're all coming from. And I'm gonna start that now. Feel free to answer or not. It's not that big of a deal. So while that's running, what I wanted to do before we begin is just share a couple of general resource links for everybody. Right now we are just starting the process for WordPress 6.3. So this is the next major WordPress release. It's set to come out in August. And there are just so if that's news to you, there's a couple of links that I wanna share for the roadmap because there's a lot of exciting things coming in 6.3. And it's, you know, in the last year, if you think back a year ago, there's functionality in the editor that we just didn't have, you know, things like margin and padding on most blocks. Like where today we can't take that for granted where a year ago we didn't even have that. So we've made huge progress in the last year and 6.3 is an opportunity to kind of add some more polish to the interface, improve various things and set the stage for phase three of the Gutenberg project which is the collaboration phase. So I'm gonna share another link. So if you're not terribly familiar with what the phases are at Gutenberg or what phase three includes, this is kind of a nice overview of what the next phase for phase three collaboration, which will, you know, it's starting to kick off now. And then 6.4, that'll be a major focus. So, but where I wanted to start today was around curating the editor. So when you're building, we've heard this a lot from the community especially from agencies and people building sites for clients. You have a lot of control in the editor or you have a lot of functionality in the editor to change colors and change styles. All that stuff's been added in the last year. But what if you don't wanna give all that functionality to a client? You know, what if, you know, editors shouldn't have access to border controls? Maybe your designers want access to border controls but the editors shouldn't. This is what we talked about when we're talking about curation, a ways to limit or restrict or modify the functionality of the editor based on the needs of yourself and, you know, clients that you build for. So I'm gonna start by sharing my screen because I'm gonna cover some of the kind of just general concepts around curation and some of the functionality that's been in WordPress for quite some time. And then I wanted to do a short demo around a new functionality that came out in 6.2 that really kind of unlocks the doors to even more of this curation functionality. I'm gonna start by sharing my screen. And this is just a reminder, we should all be here hallway. This is the event that you were attending. So there was a post published a while ago, or not a post, a page in the block editor handbook called curating the editor experience. This is a really long posts and it includes all sorts of different ways that you can restrict the editor, not every way, but most of the most obvious ways of doing this. So if you haven't checked out this page, let me drop the link in chat. This is a great resource for ways of curating the editor. However, up until 6.2, you were limited in terms of the way block settings worked. Let me back up, for example, if you wanted to control how a button block function or how the settings that are available to a button block, just globally, you can do that in theme.json, which I'll show you in a second. But if you wanted to say, when a button block is placed inside of a cover block, I wanted to have a different set of settings. Maybe you have a style guide for how cover blocks are supposed to look, and you want to restrict buttons to only being black and white inside of a cover block. You couldn't do that before, but with 6.2 and some of this new functionality, you can. So for those that run really complex controls, we've heard a lot from the higher ed, folks in the higher ed industry, that you need to be able to lock down different things, you can not do some of that. So part of what we wanted to talk about today is show you how you can do those things, and also solicit from you what other functionality do you need to meet the needs of your clients. And so building off of this curating editor experience article that has all sorts of stuff like locking APIs, the article that I actually just published yesterday, which is the main point of what I wanted to talk about today, is all about a new client-side filter. So I'll again, I'll drop this in the chat. So this is the new client-side filters that allows you to do some advanced stuff. Before we get into that, what I want to do is I want to take a look at a very stock install of WordPress. This is just a local development environment. We're using a 2023 child theme. The only reason I'm using a child theme is that we're not messing with the base 2023 theme. And start to explore some of these curation techniques. Now, we're not going to go into a super full demo. We could probably spend three hours on that. But it's just to kind of give you a taste of what's available. And then hopefully it gets some ideas from you all about what would you like to see in the future? So in 2023, let's assume for a second that we want to restrict the units of measure that are available to the columns block. That seems a little bit abstract. But if we go over to our, let's see, pages. Actually, I'll go to the front end here and we'll go to my sample page. Something happened here. Oh, I had Gutenberg enabled one. It's probably the spacer block. Yeah, there we go. It's in presets. Yeah, exactly. Thank you. So in addition to the base theme, I am using Gutenberg just to take advantage some of this new functionality, all of which will be available in 6.3. So here we are. Just a very simple page that I built out. I do have a big love of the book, 20,000 Leagues Under the Sea. And that's where this is all built off of, but it's just dummy content. Coming over here to our design in our columns, we have a column block. Now, if we go over here to settings, the dimension settings, you can see here that you have the different dimension settings that are available. Right now, I've already applied this, what I'm gonna show you, but right now I can't change this. It's locked at pixels. But in a default theme, or in the default environment, you can change the pixels to anything you want. So if you look over in our cover block here, and we go over to the settings here, you can see that I have me zoom in. I can't really zoom in, but we have pixels, percentage, EM, RAM, VW, VH. But on my column, I only have pixels. I can't change this. How do we do this? Well, this, we don't need our new client-side filter for. We can just do this in straight theme.json. And again, this is covered in the Curating the Editor article here by limiting interface options with theme.json. So we come over here to my child theme. This is the theme.json file for my child theme, 2023 child theme in my theme.json file in settings. And again, if you're new to theme.json, I apologize, there's ton of great articles around theme.json, I spent a lot of learn and a lot of video tutorials in this. But the theme.json file is what is gonna help define the settings that are available to the blocks in your WordPress editor. So in the settings section, down here under spacing, I have units set to be percentage, pixels, EM, RAM, so on and so forth. This is your global spacing setting. So here you can see I have all the options. Down here, I have the options for the column. If I remove the options, the just pixels. And again, what I have here is have blocks. I'm targeting just the column block. And I'm saying I only want the column block to have pixels. That's what I'm doing here. Now in the editor, every other block unless defined here will have all the spacing units. But the column block specifically will only have pixels. So this is a very simple way of applying curation, but it's global. This means every column block can only have pixels, not depending on where it's located or who's editing it everywhere. Really good in many circumstances, especially if you just wanna default. If you don't need functionality, you just wanna turn it off. Great way of doing that, but it's global. What we wanna talk about with these client-side filters that I'll show you in a second is we wanna be able to control this in a contextual way, based on user permissions, based on location, yeah, those two are the main ones. And you can do like on posts or pages. So this, what I'm showing you here is just block level specific theme.json settings, a very simple way of curation. But let's take a deeper look at doing this with the client-side filter. So what we're gonna do is I'm gonna pull, every example that I show you today is gonna come from that article. So if I'm going too fast or you wanna take a look at this and try it yourself, you can come on over here to the WordPress developer blog, take a peek at the curating the editor experience article and everything will be covered here. So we talked about here, this is the example that I just showed you with changing the pixel value for a block. But what we're gonna do now is we're gonna do it using the client-side filter. Again, you can do this in theme.json, but we're gonna do it using the client-side filter. Now to speed this up, what I've done is I've created a plugin. And the plugin is here, it's called block curation examples. This is a plugin that I wrote, it's basically just a little bit of a wrapper plugin to show you how these work. Sorry, not to show you how these work, to implement them, implement the filters. So that's the plugin you can download it, play with it, mess with it, fork it, break it. But that's what I'm using here to apply the filters. And when you apply these client-side filters, well, there are many ways to do it, but I like using a plugin. So you can create your own, like a curation plugin or in some industries, curation is called governance. So it could be a governance plugin that does all this functionality, but in my case, we have a simple curation example. So now with this curation plugin enabled over here, and this is my simple plugin, inside of my plugin, I have a source folder and then I have a file for use settings before. That is the name of the client-side filter that we're going to be using. So here's my example for pixel value. And the way this filter works is it's you need to use add filter. Again, I'm gonna be breezing through this because it's more laid out and more detailed in the article. I just wanna kind of show you what the end result is to kind of generate some discussion around how you could use this in the future, are there functionality that's missing, that sort of thing. But you're gonna use add filter. We're gonna use our filter here, just the block editor use setting before filter. We're gonna use a namespace. So filters in JavaScript require namespaces. We're gonna add a namespace. And then we're gonna have our callback function. And our callback function accepts a bunch of things, a setting value, a name, a client ID and a block name. What's basically happening is when you apply this filter, the editor is basically looking at each setting value for a block and it's going through this filter. And you're basically filtering the setting value. So in this case, what we wanna do, we're gonna replicate what we did in theme.json is whenever we're looking at a block, that's a column. So we are a block name, this is one of the parameters, block name equals column. And the setting name is spacing units. We wanna return this array of just pixels. Now, I would not write a filter for this. I would just use theme.json, but this is like a one-to-one comparison of how you would do both and the same thing in both situations. So what we've done here is we filtered that setting value to just pixels, so now columns just have the pixel for their spacing units. But now that we have this filter and we're in the editor, we can do so much more to determine what the pixel value, when the pixel value should be applied. In here, we could figure out the role or the permissions of the current user and then say, well, only apply pixels when it's like a editor where a designer should have access to everything. Maybe we wanna say it should only be available to when a column is inside of a cover block or on a post or on a page. Because we have this filter now, it gives you so much more flexibility to apply these settings. So now one really important thing before I continue is that blocks generally have a lot more quote unquote settings than is available in theme.json. So if we come over to our example here, when we look at a column, for example, this column block is gonna have attributes. It's gonna have setting widths, right? This is not available in theme.json. This filter that I'm showing you today can only be applied to settings that can be set in theme.json. So that's a limitation currently. So you can't pre-define width, you can't remove width, you can't do any of that. But whatever can be defined in theme.json, you can filter with this filter. So just be aware, the article covers that but be aware that this is a current limitation of this filter, but maybe we'll have additional functionality in the future that gives you more options. Let's look at a more advanced example. I'm gonna come back to my article here just so we can take a peek. The next example that we're gonna look at is restricting by block attributes. And I'm not gonna get through all of our examples today because we still wanna talk about block themes if we can or answer questions. But this one I think is really cool and it kind of starts to hint at the power of this filter. So because we now have, because we're using a filter, we have access to everything in the editor. And we also have access to the block that we've selected. Imagine a scenario where you have a heading and you want H1s and H2s to have certain typography settings but you wanna disable or limit typography settings for H3, four, five and six. I don't, it's a contrived example but perhaps that is needed by a client for some reason. Well, you can do that. So let's take a look at our next example here. In our next example, what we wanna do is we want to remove all typography settings from H3 through H6 and only give it three font sizes. So if we look here, what do we do? We have our filter again, same setup. We're gonna say if the block is a heading then apply our filtering. And what we're gonna do here is we're actually gonna grab the heading level from the block that we've selected. We have a client ID and this is the client ID for the block that we've selected. And we're passing it to get the attributes of that block. Now, we know that the heading level is stored as an attribute on that block. So we can get that. So here what we're doing is all we're doing is we're getting the current heading level of that block. And then we're saying these are the settings that we wanna modify. So if the heading value is H3 through H6 we wanna turn off custom font sizes. We're gonna turn off font style, font weight, everything like that. And we wanna limit the font size to just three. Now this is another important point. When you apply custom font sizes or custom colors using this filter these already have to be set in theme.json. This filter will not create new CSS variables. That's what theme.json does whenever you create a font size it creates a new variable for that same thing with color. So the filter will not create new ones. If you define a new font sizes it won't handle that for you. So basically theme.json is like your master, your source of truth for all the available settings. The filter is just filtering it, turning things on and off or lit restricting what's available. Then down here we're saying if the heading level is greater than three or three or greater, apply these modified settings. And we can see that in action over here. So I have an H2 and we have all the typography settings here. If I change this to an H3 this is a little bit of a, not a bug but it's just, it's something that needs to be worked out. But so if I change it to an H3 you can see that just the three are available. What happened before is my H2 was customized like this. So when this turned everything off I have the size custom but I couldn't see what was there. So that's a bug unfortunately that showed up in this. But what happened was is with H3s I don't have the typography settings that I normally do. I just have font size. So very easy. All we did was we managed this using that filter. And you can do this with any attribute. So your mind can kind of run wild with what's possible once you have access to these attributes in these filters. Now the final one that I wanna talk about today which is really interesting is around context. So here we have a cover block and I have a button and this is what I alluded to earlier where we want this button to only be black or white. Down here outside of cover blocks we don't care what they are. In my colors I can choose anything. But up here inside of a cover block I only want this to be black or white and see how it's only black or white. This is what we talk about with like context. And this allows you to do some really powerful things and really stick to brand guidelines and depending on where blocks are located. So I'm gonna skip my next example just for the sake of time. And now we're gonna jump to this modify block settings based on location example. So here what we're doing is we're checking if the block is a button, then we're using two functions or two selectors to get whether the block has parents. And again, because we're in the editor we can do all this fun stuff. So we're figuring out if the block has parents or we're getting those parents. So parents are, if it's the buttons inside of a cover that's a parent. And then we're determining if one of those parents is a coverable. Again, this might look a little complicated but that's all we're doing here. We're just determining if one of the parents in this array or object is a cover. This is our list of modified settings. We wanna limit the color styling or the colors that are available to just base in contrast, which in this case in 2023 are white and black. And then we're saying if it's in a cover block modify the settings. And as simple as that, that's what you're seeing here. This filter has been applied using that plugin. So we just have these two colors. And then down here, because this is not in a cover block we have all the colors that are available. So that is a very, very quick overview or demo of this new filter, but it shows you how it starts, you start to think about how you can apply this in different cases. So let me stop there and I'll kind of open the floor for questions. Forgive me, I know that was very quick. But yeah, let me know what you think. Yeah, Larry's got a question in the chat there. Is there an easy, quick overall method to give the customer only access to texts or wording for their website? That is all of my customers wants to be able to do. Yeah, yeah. So this is just one, I'll be a minor way of curation. But there are other ways of curating too. When I think this was just introduced in 6.2 the content only editing. I think it may have been before that. I don't know, I've been on a like Tronkin, Gutenberg so long, I forget the versions. Do you have an, I don't know if I have an example of that off hand, but there should be in the, is there one in the curating the editor experience article? Yeah, I'm looking at it right here. So what this, the way this works is with page templates. And so what you can do is you can create a page template where you lock down everything on the page to be content only editing. Now, let me see if I can open this up and see what this does. That's a full on example. Well, let me, let me, let me, all right. I'm going to copy this and see if this works. Copy this code. And we'll see if we can see this in action. So the way that you, what happens is, is when you apply this content on the editing, let's see here. Okay. So let me come up here. So when I click on this cover block, see how it's all these settings on the side, you know, they can change color and do all sorts of stuff. When I click on this group here, notice how this side really starts to simplify. So there's no set. There's no settings. There's no colors. There's no nothing. All I can do is change the text and see how the, the toolbar got really simple. So if we compare this toolbar here. To say this toolbar where it has, you know, all sorts of stuff, movement and links and all sorts of things. Down here, it's much more simplified. You just get both the towel size and length. You just get all sorts of things. Down here, it's much more simplified. You just get both the towel size and length. And you can't move the block around. So this basically, you're combining locking with template only editing, which is content locking in many ways. And this allows the user to maybe change the image. So they can replace the image, but they can't remove the image block. They can't delete the paragraph block. They can't move things around. They're just editing the content. So yeah, this is currently possible. And I would, you can dive into it. Sorry. I'm dive into it in the, in that article. Yeah. I think it's probably worth noting too that there's no UI for locking the content. Or like that. You have to manually enter the attribute to the block. Exactly. And here's. Oops. Here's the. Here's the. I think there's no. My chat is not letting me paste. There we go. So this is the link to the more technical reference for locking and template locking that you can dig into. But this is how you do it. So there is no user interface, but as a builder for websites for clients, you could set it up this way. And you can also do this with patterns, which we just saw that was just a pattern. So you can create patterns for your client. That was available to them. And they, you know, maybe it's a call out or I don't know a piece of content. And when they insert that into the page, they could just only change. You know, the content that's in it. They couldn't really mess with the pattern itself. So in the chat, we also, we have a question for Anton. I think this one looks pretty good. Is there an easy way to check if the context is within a template part. Often want to severely limit options within the header or footer template parts. That's probably going back to like the presentation somewhat. Yeah. Or going back to what you were presenting earlier with the settings filter. I'm guessing that's what he's asking about. I don't know if Alec can answer this. You might be able to. I mean, it's simply part is, I mean, it would be like a parent block, right? I don't know. Yes. I'd have to poke around to figure that out. The message I put in was something that we've been doing. Sometimes like data isn't available in Gutenberg or through JS methods. And so a lot of time we can, if we can figure it out with PHP, like what page you're on or something like that, just inject that into the page with a localizer, and then you can use it in your custom JS. If you don't have access to it through normal methods and JavaScript, you can always just shoot hard it in with PHP. I'm not sure if this would apply to like a specific template part though. So we have to experiment with that. Yeah. I mean, you can do, this is an example I didn't show, but you can do, you know, you can easily like fetch by post type. Again, that's not addressing the template part thing. But there's got to be a way and maybe I'll need to look into that because I could imagine a scenario when you're in the editor here and a person changes the template that they're using. That would be really cool. So if you like change to a different page template, certain functionality was available. I don't know that. That would be an interesting application of that. I'm sure there's a way to figure it out. That's another example. You can add to your examples repo. Exactly. Exactly. Well, yeah, speaking of that, so the repo that I shared this, see here, this plug-in, this is just kind of like the beginning. So over time, I'm going to just as more examples come, we'll just add more examples here. So, and I know that, you know, there's some other work going on in terms of creating curation or governance examples. So, oops. So this will continue being built out with more, with more things on how to do this sort of stuff. Does anybody, you know, we have more questions, but does anybody have issues that they're running into? Like right now, like with a client project or, you know, clients are asking for around kind of curating, like limiting functionality, restricting functionality, that sort of thing. That they just, either they, they just can't do with the editor or it's preventing them from transitioning to blocks. We're really interested to hear that. Because as we move into phase three, we really want to tackle as many of these things as possible. If we can, to make sure this functionality is available. There was one other in the chats asking if we can implement this per role. Yeah. It's an example in the curating the editor experience with clients have filters posts. So I wouldn't, I would prefer to use, I think use capabilities instead of actual role, right? Or did you use a role? No, I'm using capabilities. So it's the one example that I skipped for time. But yeah, you can absolutely do that. You can do can user and then you can pass in permissions that the user, you know, can map to roles like administrator, editor, so on and so forth. So you can, this is really handy too, because if you define your own custom roles with, you know, certain permissions, you can use that here. So you're not, you're filtering by permission as opposed to actual role title, which is arguably the more correct way to do it. But yeah, you can easily pull that. And then in this example, I was limiting who can control borders. So if you're an administrator, you can control border. But if you're an editor, you don't have access to that. So it's a great way, like if you have like a custom role for like a designer, like a web, you know, designer, give them everything, but then other users like your content creators, you would just limit everything or limit a whole bunch of stuff that they just couldn't touch. And you can also do this by post type. So for example, maybe you want to give pages everything, but then in posts, you only want restricted functionality for administrators or something like that. All possible with this filter. I do want to add something just based on the question. When implementing something by role, that's really never the right way to look at it. It's always capability. Because the capabilities that a role has can change. And you may be opening up a security issue if you're checking for a specific role in that role. For some reason on a site doesn't have that capability. Capability is like the source of truth where the roles can be anything. Let's see here. Real client issue. Supposing different template parts. I'm going to read it aloud just for the benefit of people who are watching this later. Real client issue. I want to expose some template parts to clients, but not all. For example, social icons template part, a cyber template part, or footer content template part, but not other template parts like header footer and meta. That was a lot of template parts in that question. Yeah, this is a tough one, right? The template parts for the most part are really only available to the site editor. If you have access to the site editor, you have access to everything. That's going to be an interesting thing though, because as the site editor continues to improve, because we're moving towards kind of a unification of things, so you'll be able to actually edit the pages of your content in the site editor. You'll be able to even foresee a world where there's greater access given to the site. This is not planned or anything. And thinking of, you know, once we have this unification, different types of user roles will have access to that. That's a really interesting thing to think about. Condition of basically template parts by capability. I don't have a good answer on that either. Yeah. There's a question. Did you have a response to that? No, you go for it. I'll follow up after you. I was just going to move on to the next question. So Alisa asks, or Eliza asks, are they considering locking the site editor to user roles? It's already lots to probably edit theme options, or they're different capability I can't remember. It's based on what the capability is. And on a clean install, it's just administrators, like with no custom roles or anything, and super admins if you're multi-site. There are plenty of role management plugins out there. If you want to open it up to, you know, different roles so you can add whatever the capability is for it too. So the next question is an interesting one. You know, with regards to, like, replacing is with digitized sections with temple parts. It's somewhat related to this is a lot of work is being done around the pattern block. So I'm sure most of folks are familiar with reusable blocks, which are kind of like temple parts, right? You can put them anywhere on your site, and the content is synced. So if you edit, you know, reusable block over here and the same reusable blocks over here, the content will update into the same. There's work being done on partially synced pattern blocks. Basically, you can have, let's imagine you have an image and a paragraph, and that's your pattern. You can insert that pattern in different places. Right now when you insert a pattern, it just, it's just blocks. There's no, it just blocks. Once you insert into the editor, that's it. But theoretically in the future, what would happen is when you insert a partially synced pattern, the content will be different in each instance, but the blocks will be the same. So you'd have, you still have a head image in a paragraph in both instances, but the text would be the same. But if you wanted to change that pattern and maybe put the text above the pair, sorry, the paragraph above the image, that would, I don't know if I'll explain it, that would sync between the instances. So the content would be different, but the layout and the function, the layout of the pattern would remain synced. So that provides some interesting, let me see if I can find the PR for that. But that provides an interesting functionality in the future. Because people have been asking that forever. You insert a pattern and then I want to update my pattern. Well, if it's all of the content is already on the pages, no way to do that. But hopefully in the future that will be possible. Yeah, that's the number one question I get is about synced patterns. Yeah, there's no way to do that. Okay, here's the PR for those that are interested, or one of the PRs. I know there's multiple. Yeah, I knew one of the other questions around access to everything versus just pieces of the design. I think navigation comes up in that a bit. Sometimes you have editors who can manage navigation menus, but you don't want them access, giving them access to the rest of the site. I believe that was also hard in classic before blocks. I think at one point it was anyway. Just based on how they done coordinated permissions around that. Let's see. So I'm trying to think if there are solutions with round patterns for that too. Or I don't know. I would probably build maybe a classic menu. I'm just trying to like rambling right now. Trying to think of a ways around that. Well, one of the things I would, I do want to stress is that, especially when it comes to like navigation, because one of the things that comes up so much is like, how do I build a mega menu? You know, like really like more complicated stuff. In those situations, I would, maybe it may sound like I'm dismissing the question, but like, don't be afraid to build your own custom block. You know, we know a lot of people like in different spaces that the core blocks don't work for them, you know, for their implementations. But because, you know, maybe a mega menu or something like that, just there's no way to pitch and pull it into the core navigation block, but there's nothing stopping you from building your own. And so some, I've tried to push people in that direction because sometimes you can do so much with the custom block, especially if it meets the needs of your organization, that a core block just will never be ever be able to do, like a core block will only ever be able to do so much. So yeah, building custom blocks is always an option. Obviously using core as much as you can is great, but sometimes it's not going to work. And also would stress if you do build custom blocks, please share them. If possible, if it's within your, you know, agency, client contracts, how you set that up, just for other people to use and for even inspiration for core. I see so many great implementations of things that people share with me that it's just hidden behind a private repository and not being shared with the community. And even if you can't share the whole thing, it's like, sometimes even just like the guidance on like how you would build the thing or, you know, very simplified, rough, you know, outline of it is usually sometimes enough. So anything you can would be awesome. More examples in the community, the better. So there's a lot of comments around reusable blocks. I personally find reusable blocks and everything around that are very confusing, but part of this whole pattern initiative, because what's going to happen with this, these kind of pattern overhaul is a unification with. It's going to basically be the idea is it is going to be one block. A fully synced pattern block is a reusable block. Then you have a partially synced, which hasn't been developed yet. And then a standard pattern like we have today, but it's all going to run off of one block. So. A lot of the whole, the whole full goal is that a lot of the confusion and, you know, wonkiness of certain things will get. At least get improved with this kind of grand unification. But that's, that's kind of the, the big picture ideal. See. I'm scrolling back through chat to see if we missed anything. So let me see my poll here. I think most people build it out. Okay. So for those that are not have not are not using or building block themes. I'm sure there's many reasons. But what's the number one reason that you're not. Time in the day, you know, is a very valid answer. But we're just, I'm just curious, like what's, what's preventing you from building it? Maybe it's time. Maybe that's the biggest one, but we're just curious. I mean, building a block theme from scratch or using another block theme. Maybe I didn't phrase that poll correctly. Have you built a block theme or using block themes. In your client builds or on your own personal site. Are you, I should have said, are you using block themes? I guess is what I should have said. It could be time for a lot of people are for one thing. I have a lot of extra time. So I don't, I don't have to deal with clients day to day. And like, I've been spending, you know, my evenings and, you know, only into the night here for the last couple of weeks. Just like setting up a, like just kind of a base, you know, boiler play type theme. And, and I realized it's been a while, like probably two years since I built like a full fledged like work, you know, block theme. And a lot of it. And a lot of things have changed in that time. So you're constantly having to relearn I'm assuming for most people. And, you know, time is money, you know, you have to, you have to actually build, you know, your clients. Yeah. See. Well, one of the things that we hear a lot is like, if you're building a lot of sites for clients, like having a really solid like base for starter theme is kind of like key. We are running short on time, but do you want to just share your kind of like the info just behind your starter thing that you built, Justin. Yeah, I'm linking it in the chat. I mean, I'll be, I'll be happy to share my screen. I mean, it's nothing. See where it is. It's nothing special. It's just a boilerplate, right? So I can get. All right. Can everybody see this fine? Yep. All right. All right. So, I mean, it's just a plain, you know, black and white theme. Nothing spectacular. Well, okay, that was the first post I clicked on us. You know, just base elements then just like testing things. But I have in like the theme folder, there are all the base stuff you need like settings and styles within a theme JSON. It looks a bit heavy. I realize as I was doing this, there are still some probably some bugs that need to be reported after I get through this process. And they're also just open tickets that many of them are in WordPress on on slate for WordPress 6.3. Like for example, one of the going back to the first screenshot, like this. These are just like six posts, three columns. And there's no way to remove the gas between posts without custom CSS. And so you have to write a custom block style, things like that. And so like I'm trying to with this starter theme like handle some of those edge cases or not really edge cases, just common cases too that WordPress doesn't quite support yet. Like what is the post. Yeah, so it's kind of complicated. This way too much custom CSS you have to write just to remove a gap. Just to remove a gap. So that needs to be handled in core, ideally, we're not there yet. Hopefully 6.3. But there's a lot of the theme is just like taking care of little problems like that. So you don't have to, you know, if you're building for a client, you don't have to worry about it because it's fixed already. And but I wouldn't love for anybody who wants to, you know, if you want to fork it, build your own thing as like it's pretty minimal in many ways. We'll just stop sharing. And because I know I probably could do a few more minutes on but I know we're short on time. And PRs are welcome. And please, you know, if you want, if you're, I know we had how many people we haven't, who have, who haven't built with my block themes yet? Was it like 21% of our people that hasn't. I haven't. And then we have another 27 of tried. And so about, about 50 people have not fully done it. One thing I want to, I want to spotlight on, on Justin's theme is that it does include some perhaps more advanced techniques like it has per block. Style sheets, which is really cool. So it does some more like kind of basic. Functionality that really sets up for a really sophisticated theme, which is, which is pretty cool. So yeah. Yeah, one of my goals was to at least like show an example of each feature that you can possibly do with the theme. Just so people have like the code there on hand. Even if they need to rip it out later. So more than a starter theme, I would almost, I want to call it a learning theme educational. But yeah, so maybe we'll have time like to kind of walk through that like theme a bit more than like, you know, next month's call will hang out. Yeah, it'll be great. But I know we have more questions that have already popped up in the chat. Well, okay, so Mark's using theme.json and PHP themes, which is awesome. Yeah, I do want to stress like hybrid themes are great. Like, you know, in many situations, especially if you're transitioning like as a great way of going about it. I'd actually say when I first heard about the block editor, like the way it was kind of sold to me and some other theme authors at the time was we're hybrid themes. That's, that's what I had in mind. I felt that was going to be the first thing we started doing with the, we would have PHP templates, but we might have, you know, block template parts that we can insert anywhere. And that's what sold me on the idea early on. And I know we didn't really get the, you know, block template parts within PHP, PHP classic theme until last year. I think it was. So, but yeah, I mean, this is a great way to build client sites to me. Just you kind of control. I feel like you have a lot more control from like, like if you're coming from a PHP development standpoint and you haven't really dove into like full block theming yet. Yeah. I do want to touch on Michael's comment about how basically having more settings and team.js or in global styles that you could then turn off. Or like, so your block editor is super basic, but then you can control more things in global styles. That's one of my personal things too. I mean, if you look at the filters that I showed you today, you could turn off typography, color, border radius, dimensions, but then all the other settings that blocks have that aren't in theme about JSON, you can't do anything with. So having like a unified pay to kind of restrict other functionality of blocks would be pretty interesting. And we'll be really powerful and useful like in a client example, like maybe cover blocks for, you know, should only ever have, you shouldn't be able to change the opacity on the overlay. Maybe there has to be 20% all the time and, you know, you don't want people to mess with that. Like it's really hard to do currently. So things like that are, if there are ways to do it, it's our job, I guess, to show you the community how to do it. So that's, those are the kind of things that I think people are looking for a lot with. Okay, cool. Okay, I'm glad that resonates with you because I think it's an area that would help a lot if that was possible. All right, so another question about to say or comment about disabling blocks. There was another, so there's another issue. Actually, I'm going to share two issues. So if you'd like to share more comments after the hallway hang out, I'm going to share two issues that there are many, but these are two that I think are pretty good. That others have shared and then there's some good conversation in the issues around ways of curating or, you know, modifying editor functionality for the needs of, you know, different situations. So one of them relates to just governing block settings. And this, the second issue is actually the genesis of the client side filter that I shared in the demo. And the first one is about the lack of configuration, potentially endangering editorial workflows for those that build sites, you know, for client city, that sort of thing. So some good comments in there, good discussion around curation and functionality that it will be needed for folks to really adopt block themes for clients. But really any feedback, all the, all the chat today, we're going to be taking back any additional feedback that you have on this will be fantastic. So I also want to add that feel free to ping me or Nick, you know, on Slack at any point, or, you know, even with ideas, you want us to run hallway hangouts around. So because I believe we're going to, we're going to try to keep these pretty consistent, more likely in the, like mid middle of the month, so we're a little light this month. Yeah. And we also have our developer advocacy team also runs what are called developer hours. And so it's kind of a more developer focused event, usually like a workshop or a panel discussion around more like developer heavy conversations, but that's another avenue where we can talk about some of this stuff. So between hallway hangouts and developer hours, hopefully we cover quite a bit, but we're always looking for ideas from you folks in the community around what will be the most useful. All right. Any more, any more last minute questions? If not, we will start wrapping up here for just about a time. All right. Well, thank you everybody for attending again. My name is Nick Diego joined by Justin Talak, we're both developer relations advocate sponsored by automatic and we hope to see you on the next hallway hangout. We will be putting them on meetup moving forward. So again, thank you all for attending and I hope you have a great day. All right. Thanks everyone.