 All right, welcome everybody. Again, my name is Nick Diego. I'm a developer advocate at WP Engine and also a member of the training team. Today we are going to be doing an online workshop all around how to curate the editing experience within WordPress. I'm gonna begin by sharing my screen and we will get started. Okay, so you should all be able to see my screen right now. It is, you may recognize this as 2023, a brand new theme with WordPress 6.1. Just to make sure we're all in the right place, we are doing builder basics, how to curate the editing experience with WordPress. And we're gonna talk about today is kind of this idea that the editor, the WordPress editor can be a bit confusing or overwhelming, should I say for some users, especially if you're delivering content to clients or you're delivering designs to users. So the idea about around curating the editing experience is how do we pare down that editing experience, restrict it so that maybe to meet the needs of your clients or users to really simplify that experience. Now there's a million ways, not a million, but there's a lot of ways that you can do this. And I'm gonna start by, I just wanna share this link, I'll share this in chat. This is a great resource. This is pretty much all the ways that you can cure at the editing experience with WordPress. We're only gonna talk about really three of them today. I could probably talk for three or four sessions on this topic if we wanted to go through every single one. But I'm gonna talk about kind of the three that I use the most often or I find them most useful. And also one of them is brand new in WordPress 6.1. So I wanted to make sure we highlighted that because I actually think it's also one of the coolest new features when it comes to creating a really constrained editing environment for users. So this is my first Builder Basics in a while. I think we have done one in September, but we will be doing more of these. We have three more planned until the end of the year. And then of course there's tons of great other presentations on the online learn WordPress online workshops meetup group. So I encourage you to check those out. But Builder Basics, this kind of series is all around kind of teaching you the basics of how to build with modern WordPress techniques. Generally we don't touch code. Today we will touch just a little bit of code, but it should be fairly accessible. And there are things that I really want people to know how to use. So bear with me when we get to the code portion. So I always like to go over kind of the tools that I'm using in these demos. So again, we're on the 2023 theme that just came out of WordPress 6.1. I'm also using the Gutenberg plugin. Now normally most of what you see here today well almost everything you see here today you do not need the Gutenberg plugin for. I am using the Gutenberg plugin because the last content curation method that I'm going to show you, there's a very small edge case bug that has been since patched and will be included in WordPress 6.1.1 which will be coming out soon. But I didn't want to introduce that bug into our presentation. So that's why I'm using the latest shares in Gutenberg. So I'll point out where the bug is in case you're trying to go check this out on WordPress 6.1 but note that it will be fixed very soon. All right, so again, just Gutenberg, just the 2023 theme, let's get started. So I'm going to go over to a page that I've already pre-created and when you talk about restricting the editing interface often we like to think about a design that you've prepared for a client or a user that you don't want them to inadvertently break or wreck. I think about delivering a design to a client based on a specific brand guide or a specific specification. So we're going to kind of demo these methods of curating the editor by going through an example. So what I have here is just a very simple call to action. So if we look at our list view, we can see I have a couple other blocks on the page. I have some texts down here, but basically our call to action is just a cover block and inside there's a couple of groups and then we have a heading, some texts for a description and then a couple of buttons. So imagine that you're delivering this pattern to a user and maybe it's a new user, maybe they're not as comfortable with the editor or perhaps you were delivering something and has very specific guidelines. The client loves the way this looks and they don't want it to change. All they want the user to be able to do is make some subtle content changes. If you look at these two groups here inside of our cover block, these two groups are really for layout. I'm giving another talk on alignment dimensions and stuff which will be next week, but there's a lot of fairly sophisticated layout settings that are applied here that make the content sit properly inside of this cover block. When a user comes to insert this pattern and I'll show you how to do the pattern in a second, when a user comes to edit this content because this is just a dummy header, we don't want them to inadvertently remove this group or move this thing around so that it breaks the layout. And that's kind of what we're talking about here. How do we restrict the editing experience within WordPress so that a user who maybe didn't build this pattern can use it without inadvertently breaking the design? And this is a very common request from people that are building things for others, especially like agencies. But it's also really useful if you're delivering or distributing patterns or themes to other users out in the WordPress ecosystem. So I mentioned that this is a pattern, but I haven't actually shown you that yet. So before we dive into the three methods that I'm gonna talk about today, let's turn this into a pattern. Now again, we're not talking about patterns today specifically, but I think that this is a good refresher and if folks have never created a pattern before, it will provide a good framework for what we talk about later in the presentation. So a block pattern is just a collection of blocks. So we can think of this cover as a pattern. So what I'm gonna do is I'm going to hop on over to the theme folder for the 2023 theme. And you'll notice that there's a folder called patterns. And inside of that folder are all the patterns that come with 2023. So those patterns, if I go over to the inserter here and I go to patterns, these are the patterns that come with 2023. What I wanna do is I wanna create my own custom pattern with this called the action. So I'm gonna come on over to the 2023 folder. I'm just gonna create a new file. I'm gonna call it custom CTA. So I'm just creating a new file inside of that patterns folder. Then to be quick and easy, I'm going to copy the header from one of the other patterns that are in 2023. This header, again, in the learn WordPress workshops, we've done sessions on patterns. They're available on WordPress.tv. So if you like a thorough overview of patterns, check those out. We're just gonna do a quick primer here. So every pattern needs to have some information about the pattern. So you can see here we have title, slug. Let me zoom in a little bit. We have title, slug categories, keywords, so on and so forth. I'm gonna remove some of this stuff. We just care about categories. Every pattern needs to have a slug. This is like a unique identifier that every pattern has to have its own slug. And we're gonna call this custom called action. So basically set up my pattern, but I haven't actually added the block content. So I'm gonna come over here. I'm gonna copy the cover. Basically this copies all the blocks that are inside of the cover and all of the styling that's applied. Come over here and I'm gonna paste it. So now we have a pattern. I'm just gonna save now. And when I come back over here and I refresh the page, now when I go to my plus sign, go to patterns and I go to featured, you can see now that we have our right of call to action here, custom pattern. Just to prove that it works. I'm going to delete the one that's there. We'll start a new line. We'll go to patterns, featured, and we will insert our pattern. So if you've never created a pattern report, it's just that simple. You design what you want inside of the editor, when you're happy with it. In this example in 2023, I created a new file, added the appropriate header at the top with the necessary information, copied over the block markup, there we go. Okay, pattern complete. Now let's move on to how we can restrict the functionality around this pattern. So when I first mentioned, I showed you how there's all these groups inside of this. I don't want a user when they insert that pattern to be able to move the groups around or remove them. So back in WordPress 5.9, there was introduced the block locking API. Block locking has since the feature has since been iterated on and improved the version after version. And you'll now see, when you click on this three little dots, you'll now see the lock icon. Now, content locking or block locking is a, there's a lot to it. There's a lot of advanced functionality you can apply to locking. There's some interesting things where you can restrict who can lock and unlock things based on user roles. This is a bit more technical and you need to write code for that. But I just want to point out that this is a very powerful API in WordPress. But because there's a nice user interface for it, it's very useful even for folks who don't want to dive into code. So you can see here that I can lock this down. I can lock this whole cover block down. And when I click on this, it says, do I want to disable movement, prevent removal, and then I come and apply these settings to every block inside of my cover. Now, let's think about this for a second. I want the user to be able to move the cover around because I want them to be able to move, you know, the call to action up and down the page. They should also be able to remove it. If they add it, if they insert the pattern maybe by accident, you want them to be able to remove it. But what I don't want them to be able to move or remove are these group blocks. So what I'm going to do is I'm going to go to group. Now you can see right now, I can remove it. I can also drag it and move it around and really mess with this design. So what I'm going to do is I'm going to click on lock. We'll apply this here and click apply. Now that move handle and the ability to remove the block is no longer there. We're going to do so the same thing for this group and we're going to apply. So at this point, the two groups that handle the layout are restricted. The user can't move them or remove them. Now, of course, any user with edit access can come in here and unlock the block. Again, there are ways to restrict this based on user role, but just note that without those additional advanced features, you know, you will need to note that users can unlock and lock things. Again, back to this article on curating the editor experience, there's links there to the more advanced features that you could apply. But we're already in pretty good shape because unless the user actually unlocks it and then deletes the block, there's no way for them to inadvertently break this layout design. But you may wonder, okay, well, you just spent all this time creating this pattern. Why do we care about block locking in a pattern? The reason is because just like I copy and pasted before, I can copy this whole block, come back over to my pattern and I can insert it. And if you look closely, it's gonna take me a minute to find here, there's now an attribute applied to the group block. This says lock move true. It's a little misleading because it says move true, remove true, but that means that movement is locked true, removal is locked true. So it's a little bit hard to, you're gonna get mixed up when you read it. But now these lock attributes are applied to our group. So when I save my pattern now, and we'll delete this old one, and we'll refresh the page. Now, oops, we can go to pattern, featured, insert. And now you can see that my pattern was inserted with those locked groups. So now you can see how you can take, if you're comfortable creating patterns, you can now combine that with this locking feature to restrict maybe more complicated elements of the pattern that you don't want a user to interact with, maybe inadvertently ruin the design. I could probably take this a step further. Perhaps I wanted to ensure that every call to action block had a heading, had a description, had buttons. And so what I could do now is I could even go further. So I could also lock down the heading. I could lock down the description here. And now for buttons, you could kind of get a little fancy with this. You could lock down the buttons block. This is the block that contains each button. I could lock this down. But maybe inside of this, I only want, maybe I want the people to be able to move the buttons around. So you could lock just removal on both buttons. So this means that a user still needs to create both buttons, but they can move them around because maybe for example, they create one call to action that they really should be on the right or the left. They can still move them around. So you've prevented removal. So every call to action still has two buttons, but you have allowed the user some flexibility to move them around. Again, to apply this to our pattern, you could of course come over here, copy that, that attributes and paste them into all the blocks inside of your pattern. That's way too hard and error prone. So I tend to just design everything in the editor. I'm gonna happy with it when it functions the way I want it to. I literally copy and then paste. I, until someone can convince me otherwise, this is the most effective way to design patterns in WordPress. Until there's a way like in WordPress to like auto-save your patterns when it comes to designing and applying them to files themselves, always design inside of the editor when you're happy with it, copy and paste over to the file and then you can make some tweaks as needed. But it's always easier to design inside of the editor, especially when you have this interface for locking on the locking. So this is a great start. So we've kind of prevented users from moving and removing and we've kind of locked down layout. But the problem here is that the user still has complete flexibility over all of the design tools that come with WordPress. Now, in themes, block themes specifically, you can use a file called theme.json. And theme.json is what defines the settings and the styles for that block theme. So in a theme like 2023, all of the design tools that WordPress provides have been enabled and that's pretty common in most publicly available block themes. However, that might not suit your needs. You might have a user or a client that you've designed a very specific layout for and you don't want them, for example, like let's if I come to these buttons, I don't want them to start adding all sorts of padding. Maybe they don't even understand what padding is. Maybe it's easy to kind of see what padding does but maybe they're not familiar with padding and they're just changing things around. Maybe they're changing border. Maybe you don't want your button to look like this. You've carefully defined your button and you don't want users to have this power. Personally, I love this power because it allows you to design some really cool things but it's not right for every scenario. So even though we've locked everything, they can't remove the block. They can still do a lot when it comes to design. So the next tool that we're gonna talk about when it comes to restricting or curating the editing experience is limiting the design tools that are available to users and the way to do this is using theme.json. So what I'm gonna do is let me just reset this and we're gonna use our button as an example. So let's assume that in this design or this site that we're delivering to a client or this theme that we're delivering to the world, we always want there to be square corners. We don't want rounded corners on our buttons. However, border is available to the user for buttons. So let's head on over to theme.json. And again, this is getting back into the code but theme.json is something that as we move forward in WordPress and if you're not familiar with theme.json, I strongly encourage you to start learning and getting it activated with theme.json. It's kind of the heart of block themes and it's incredibly powerful. And once you kind of understand how it works, it's a pretty intuitive. I mean, it's a lot of code but it's fairly intuitive and then you can really use it to do some really powerful things. So let's head on over to theme.json in 2023. And you can find that file at the bottom here and I'm gonna collapse many of these containers so we can kind of get a overall look of what theme.json is. So it's really broken into four pieces. We have custom templates, settings, styles and template parts. Again, I can give two, three, four presentations just on theme.json. We're gonna ignore custom templates, we're gonna ignore template parts and we're gonna ignore styles. What we wanna talk about today is settings. Settings and styles, honestly, are the two biggest important pieces of theme.json. Settings in particular are where you define things like the color palette. So in 2023, we have this color palette. I am using a style variation of 2023. I don't really wanna get into that but in the styles, you can see that there's other JSON files that have settings and styles as well. We're gonna kind of ignore that for a second but theme.json is where you define your color palette for your theme. It's where you define layout, so you define spacing, all sorts of things. Now, there's a special setting that 2023 is using and that's this appearance tools. It's kind of a shorthand that basically enables all design tools inside of WordPress, all the ones that are available. It makes it easier to do if you're somebody like if you're a theme developer and you're building something like 2023 instead of having to say true, true, true, true for every design tool, you can just say appearance tools, true and you just turn them all on. And the tools that we're talking about here are border, color, spacing, that sort of thing which includes border radius, style, margin, padding, all that sort of thing. Now, if I was to define, I close these up so it's a little bit easier to see. If I was to define a border here, I can say border, inside of border, I can say radius, false. Now, let me, at the end, I will find the handbook article for Theme.js and Global Styles that have all the different parameters that it accepts. I kind of know this offhand, but I don't expect everyone else to. So I'll find that article towards the end and I'll post that in the chat. But one of the things you can define is border, in this case, radius. And what I've done is I've set it to false. Now, if I set border radius false at the kind of root level right inside of the settings section and I save this, when I come back over here, I'm gonna save and we'll refresh. When I go back to my button here, oops, did it not save? Oh, perfect, thank you, Brian. Border radius false. I think I'm backing myself into a problem here. Let me save. I alluded to the style variation issue and I think it's gonna bite me. Okay, so let me see here real quick. Let's go to style, I think this is the electric one. Okay, let's try refresh now. I swear this works, interesting. Okay, so normally what should happen is that when you just find border radius false, then the border inside of this panel right here should not appear. Let me try one more thing and so the next, so assuming that worked, what I was gonna show you next is you can define a section for blocks. And inside of blocks, we are going to choose button and this allows you to configure the same sort of settings at a block specific level. So let me just try this and see if this works and then we will diagnose. Yeah, at least this stuff always happens. So if you run into problems like this, that you are not alone for sure. There is a small cache when it comes to theme.json. So we might be getting impacted by the cache but let's try this. So this is where, so let me back up. If we were to define this where it's border at the top, border radius false, this is gonna impact the border control on every block on your site. This will turn it off. If you define it at the block level, it will only remove it for that block type. So assuming they both work, this type of functionality is really handy because for example, let's pretend that back to our square borders around buttons. Maybe your theme always wants square borders. You don't wanna give users border radius on buttons. But if you want a border radius on a group or a cover block or something like that, turning it off everywhere might actually be problematic because maybe you want it to use it on other blocks. This is why defining it at the block level, I kind of generally recommend. Unless there's a real reason to disable it at the global level, I tend to always apply it at the block level based on what I want to do or what my theme is trying to do. One of the other things that's really cool is you can also do color. So you could define specific color palettes for say buttons or for fonts or sorry, for paragraphs and headings. So you can really kind of mix up the configuration not only restrict functionality, but you could change up the functionality, depending on the block that you're editing. Let's save this and let's see if this works. Give it a refresh. Okay, that worked. So now we don't have the border radius here. Let me back this out and we'll save this. Because what this should do is this should remove border from every block and then this kind of doubles down and removes it from buttons. But if this, I think we were hit by the cache a second ago, but let's double check. Yep, okay, so now the cover block no longer has border. Let's turn everything back on and just double check that everything works. Watch, it's not gonna work now. Okay, border is back. I was wrong, cover does not have border and button borders back. Okay, we're in good shape. I think so often there's actually a ticket on GitHub about this caching issue. So sometimes when you edit theme.json, it takes a second for it to be reflected in the editor and on the front end. I believe the cache is like 30 seconds to a minute. So occasionally you can get hit by this. If you do, just laugh and move on or wait until that GitHub issue is effectively fixed. Okay, yeah, so Eve's asking a great question. Can you manually set the radius to be four picks rather than true or false? So that is where you would actually use the settings. So let me hop on over here. So this, sorry, I said settings, I meant styles. The settings are where you turn things on or off or you configure an array of options. So for example, typography or color palette. When you wanted to find a specific style, you can do that in the style section. So let's pretend that you wanted to disable border for users, but you wanted the, on buttons, but you wanted the border of buttons to be four pixels. What I would do is I would set border radius false in the settings so users can't change the border. But then down in the settings, or sorry, the styles, I would do, I would do something like this. I would do blocks, button, radius, four pixels. And if we are not hit by the cache, we will have four pixels on our buttons and no border functionality. So you can see it's hard to see, but there is, let me make it more clear. Let's do 20 pixels so you can see a little easier. So now we have 20 pixels on our buttons, but the border functionality is no longer there. So we've used theme.json in two ways. One, we've set the style in the style section and we've restricted the design control, the actual functionality that allows the user to change the radius, we turn that off to false. So you can definitely combine the two to do that. So is there any benefit of that over CSS for a theme developer? Brian, my colleague's in the chat here, so he can back me up on this. I strongly encourage everybody to use theme.json when it comes to styling as much as possible. Now, it doesn't can't do everything. So you'll still need CSS for some really kind of advanced things. It only can go so far, but the benefit of using theme.json is two-fold. First off, you never have to worry about what is the class name that's applied to buttons because it always applies it correctly. You never have to worry about WordPress updating or changing. If you were to set, write a custom CSS class that defines order of 20 pixels and the way the markup of the buttons block changes, which it can, unfortunately, you might get hit with having to update things, but using theme.json, it's always there. And the benefit is, is that when you apply the theme.json setting, it doesn't over, it has a very low specificity. So a user, if you enable the control, the user can always override it in the settings. So it provides a nice defaults for your theme. And then the user, assuming you enable that functionality, they can always override it in the user settings. So sometimes when you apply it a custom CSS variable, you might make the controls inside of the editor no longer function because your CSS is overriding whatever the controls are trying to apply. So I always try and encourage folks to use theme.json, the styling as much as you can. It's getting better and better. It's like now it supports things like hover styles and elements and all sorts of things. Again, I could talk about theme.json for days. One of the cool things, for example, about theme.json when it comes to buttons, is there's now like a button element. So you can define a button style for elements, the button element, and then that will affect buttons in search bars, in normal button blocks, in forms and all sorts of different things. Again, a whole much bigger topic. But especially if you're building block themes, I would strongly encourage the theme.json approach. Okay, but that doesn't mean you can't write custom CSS. I do it myself, especially for more advanced things. I don't wanna say CSS is dead or anything like that. It's still very valuable and very important, but whatever's in theme.json is a good place to start. Okay, so now we're gonna talk about my, the new functionality that's coming out with 6.1. And this is something that I think is, in many ways, game changing. That's a big statement. I'm gonna copy and paste the developer note for it right here. So what we're talking about is content-only editing. So we've shown how to remove functionality. We remove the border, we've changed the border, that sort of thing. We could take it a step further, we could remove color and we could remove typography. But that's a lot of manual configuration. And if I disable, if I set my buttons, if I disable radius on buttons, that happens everywhere on my site. Maybe there are certain scenarios where I wanna have border radius, but this call to action, I don't. I want my call to action to be exactly the way I designed it. I don't want any sort of other changes made to it. You can't do that in theme.json. Theme.json is really powerful. You can do it at the global level. You can do it at the block level, but there's no context for where that block exists. I can't say I want button blocks to not have border when they're inside of my call to action. There's no functionality for that. So it kind of makes you, it forces you to make hard choices. It forces you to either remove border from every button or move it globally. And that might not be exactly what you're looking for when it comes to curating this editing experience. It goes a long way, but it may not be exactly what you're looking for. So what I'm striving for here is I want this call to action when the user inserts it. I want it to not be able to be changed at all. All I want them to be able to do, change the text, change the description, maybe add some links, maybe add the links for the call to action buttons, maybe change this background image to whatever they like, but I don't want anything else to change. Now, the other reason that you might wanna follow this approach is not like we're gonna not be mean, not that we're trying to like, tell users, oh, you can't change anything. Sometimes this is just very overwhelming. I mean, if you look at all the settings here, I mean, this is a lot of different settings. Once we start opening all this up, all the different margins and paddings, it can get very complicated very quickly. And so especially when it comes to newer users, this might not be the editing experience that you wanna provide people. Content-only editing goes a long way in solving this. So the way to apply content-only editing is incredibly simple. And it's almost, it's so simple, I'm just gonna do it and then we're gonna look at it and then we're gonna talk about it. So what I'm gonna do first is I'm going to remove all of this locking functionality, take me a second, because I wanna go back to what our original pattern was with nothing applied. And yes, unlocking does take a little bit. Okay, so we're back to our original, I'm gonna copy this, I come back over here, edit our pattern, back to the original save. I'm going to revert out, oops. I'm gonna revert out all the things that JSON changes we made. We're gonna go back to just stock 2023, give this a refresh, remove our pattern, add it back. We have our pattern, it's got too many controls, we wanna take care of this. The way that we're gonna do it, there is no user interface for this, so you have to add it manually or add it to the pattern, which we'll do in a second. We're gonna apply the template lock attribute to the cover block, the container block, and we're gonna give it the property of content only. To do that, you can do it in the editor using the code editor. We're gonna come over here. We're gonna zoom in a little bit. We're gonna type template lock content only. Copy it into the chat so we all know what the attribute is. We're gonna exit the code editor. We're gonna go back to our pattern, click on the sidebar, there's no settings. I click on my heading, no settings. I click on the list view, I see my cover here, but you know how before I could look and see all the blocks inside of it? There's now nothing there. What content only editing does is it removes, for one, it removes the ability to click on those cover, I'm sorry, those group blocks. Remember those group blocks in there? I can no longer click on them. It basically removes them from the interface. I only can click on content blocks, so things like text, things like buttons. I also can change media. So for example, on my cover block, I can still replace the image behind it, but I can't change anything else. I can change things around the image. I can change alignment and that sort of thing, but I can't change, remember before there's this whole sidebar about focal point and size of the image and overlay color and padding and margin and all that kind of stuff. It's all gone. So this pattern that I've delivered, aside from the content part of it, changing out the heading, changing out the description, changing the buttons, adding links for the buttons, you can do things like open a new tab. The user just focuses on the content and not about the design. And I think that this is a really powerful tool that can be used in various scenarios, especially when working with users and clients. So you could imagine if you had an entire library of patterns, call the actions headers, so on and so forth. Using this technique, the user can go through their pattern library, insert it, edit the content as they like, change out images and so on and so forth, but they never interact with all those design tools that they may not need because the idea is you're presenting a pattern that, for example, imagine if you're building something for a client, you've designed an entire library of patterns, the client approves those patterns, these are the patterns they wanna be using on their website. When an employee or user is inserting those patterns, all they really need to do is be able to edit the content. They need to change out the call to action, change the description, change links and so on and so forth. They don't need to actually change the design. You've been hired to create the design. So this is a tool that you can use to really lock things down. So let me take a quick peek at the questions here because I think there are gonna be some. Content equals simple text content, things like links, button text are not editable. So no, so you can't, you can edit them. So I can edit these, so I can say, I can edit the text, I can edit the content. I can edit the links. So I can edit the links, I can change the links. So the things that I can't do are things like change the color of the button, change the typography of the button, change the size of the button, change the size of the text. All those, let me turn it off real quick. So if you go to code editor and we just remove this. Now, for example, when I go to text, I have all these settings over here. When you enable content only, all these settings go away. So margin, typography, color, all that kind of stuff goes away and the user can only edit the content. Now, if you had an image in here, so we put an image here, they could change the image, they could replace the image. So anything that's media or text, they can change, but everything else is locked down. Now, it's important to note, this is the very first iteration of content only editing. Let me put it back on, because there was one more thing that I wanted to show you before. Okay, so we're back to content only, there's no settings over here. It's a bit hidden, but purposefully so. If you click on these three little dots, you can click on this button that says modify. When you click on modify, now you get all the controls back. For example, I have, you know, focal point, everything I would have, change the overlay, we could change it to red or whatever. Oops, and then when I click off of that, it goes back. The modify button is very similar to like the lock functionality by default. Anybody can modify a content only locked block. But again, this is the very first iteration of this functionality in 6.1. So in future versions of this functionality, I fully expect there to be ways that you can filter out certain users. So you could imagine a scenario where you deliver to a whole bunch of patterns that are content only, content only editable and they are restricted to administrators. So only administrators could modify them. That might be useful, right? If you really need to make a change, having a way to hop in here and make that change would be very helpful. But for, you know, maybe authors or, you know, lower tier user roles, they couldn't do that. So I fully expect that to happen in the future. And if you were to check out some of these other curating editor experience techniques, which I won't cover today, you can even go further. So for imagine like, I can go to this code editor, right? And remove the attribute. Well, you can also disable the code editor for certain users. So imagine a scenario where you've, you're combining the functionality of these content only editing patterns. You've disabled the code editor for specific users. Maybe only administrators can access the code editor. Now you have an interface where an author or maybe even editor can insert these content, change the content, but they really can't do anything else. They can't remove it. Sorry, they can't remove the content inside of it. They can't change the color. They can't go into the code editor and mess with the code. So it's a really, there's some really powerful ways in WordPress now to really restrict that editing experience. And this is something that people have been claiming for, for a long time. So when the block editor first came out, it's like, oh, look at all these cool design tools, which are great, but in some circumstances, they're not so great because they give users perhaps too much flexibility. So again, I entirely encourage you to check out this full article if you really want to do a deep dive into all the different ways you can turn things on and off and restrict content. But these are my three favorite because I find myself, I'm often locking things. I lock things myself just so I don't inadvertently delete them. So for example, the spacer block, sometimes I'll just lock it. So I don't, when I'm doing design, I don't inadvertently just delete it by accident because I can no longer delete it. So I think the locking is like kind of this, the simplest method of content curation or editing, curating the editor, but one that I find that I use all the time. Theme.json is something that I also use a lot, especially when it comes to designing themes. You know, if you have a very specific theme design, going back to our border example, where all borders need to be square or in the example in the chat, all borders need to be four pixels or 20 pixels. And you really want to lock that in doing something where you set it in the settings and then restrict border radius in the settings for buttons and then in the styles, set it to a specific parameter. That's a great way of doing it. And then I think when it comes, this is very new, right? It just came out last week. Yeah. Wow. Six point one was last week. This is very new, but there's a lot of different ways that you can use this. And I think that it's going to be interesting to see how people use it and then thinking about ways that it can be improved. Maybe there's more functionality that this needs to make it more usable. One of the things I was talking to a colleague about was, wouldn't it be neat if you could have patterns, you know, that were locked and controlled, but also specific to user roles. So if you're an editor, you come into the patterns and you only see patterns for editors or you kind of, you know, you're an administrator, you see everything, things like that. So we're really on the, I don't know, we've made a lot of strides and all of this, you know, restriction functionality. There's still a lot of, you know, a lot of room to grow and a lot of more things to add. So I think we only have about 10 more minutes. So I want to give ample time for people's questions or people want to see me go through something else, do more edits and team.json that may or may not work due to cash. I'm happy to do anything. I'm going to start by looking at some of the comments here. Oh, Elise is asking, where did you edit that? Again, I was taught not to edit code in the admin area. Okay. So when I'm editing my code here, this example, what you're seeing here, I'm actually using BS code. And so I'm on a local WordPress installation. So I have, you know, the access to the theme folders, and I'm making those changes directly using BS code to open the folder and edit the code. I agree, you probably should not be editing code directly in the WordPress admin. I will speak only for myself here. I do it quite frequently, honestly, because now when you're inside of this editor, it's pretty good at detecting when you make a change. It's going to cause a fatal error, and it will stop you from creating that fatal error. So for example, if I was to make changes to my theme.json file, and I, for example, remove this comma, which will break things. It gives me this little X and it tells me that's not correct. So again, I would never encourage anybody to live edit their site, especially theme.json, but I must admit that I do it on occasion. And this editor has gotten better and better over time where it's pretty resilient at protecting you from making too harmful of mistakes. Okay, a code editor in the end. Okay. So the code editor here is, did you mean this one here? So if you go to the three little dots and you go to the code editor, you can go like this. So this is the code editor. And this is where you can see all the block markup on the page. And this is where I made some of those changes directly to the block markup. Now this is. Yes. And so this is by page only. So this is the block markup on the page that we're seeing here. So for example, we have the cover. So if I go back over here, I can see cover. So this is the cover. I have a spacer block above that. This is basically everything that's on the page. Now editing this markup is a little tricky because it's, it's a mess, right? It's just a big glob of code. However, once you get more comfortable with it, for example, all I was doing, I was, I was adding the attribute right at the beginning. So it's a little bit easier. I find that this is very handy, especially when you're copying and pasting code. So for example, sometimes I'll either click copy and then copy the code over to the pattern file, or I'll just hop into the code editor and just copy the code exactly. And then paste it over into the pattern file. It's really up to you. But those are the two ways. All right. Sam's asking. Probably found us at the block locking so far. Similar. Many plugins such as WooCommerce require emerald. We'll give them actually disable. Yeah. So that, that is a huge problem. So there are certain plugins. That in order to function properly. Need to have administrator rights. I've seen a lot with the custom plugins as well. I'll admit I have. Some custom plugins myself that just do the nature of the way they work. They need to, they need admin rights. In order to, to function properly. So that's definitely a problem with third party blocks. I'm not aware of any current solution around that. But I do think that. If. You're looking at. There's a couple of ways you can look at. Restricting content. You can either completely restrict a user. So we're talking about, you know, getting rid of the code editor. Really not making it possible for them to edit things. Or you can do a bit of more of a lighter approach. And that's kind of why I like this content on the editing. Because it's so. Attractive to present a user with this design where they don't have to think about anything. They can come in here. They can edit the content. But if they really needed to. They could go click that modify button. And that's the kind of approach that I think by default that we're presses approaching. Implementing these restriction functionality. But then. There's a way to get rid of that. If you wanted to. And I kind of like that approach. It requires more education on the, on the, you know, part of clients and whatnot. But I do think that there needs to be a more. In addition to that, there needs to be more filters and whatnot to handle the restrictions that. You know. May not be possible today. And I think that will commerce. Blocks themselves are. They are still in work in progress. And I think that as they develop further, they're going to incorporate more of the core features that are available in WordPress. And continue to get better and better. And hopefully overcome some of the limitations that they have. All right. Does anybody have any other questions, anything else they want to see. Around content. Curating the editing experience within WordPress. All right. Well, if not, feel free to add them in the chat. If not, I want to call out a few more workshops that are coming up. So this one should be great. This one is on Monday. About navigation block. The navigation block has been a bit of a pain point. I think for, for many folks. And I, it's, it's slowly making progress. And there's a lot of, progress plan for 6.2 has been kicked, kicked off recently to continue to improve that. This one's going to be a great one too. About a 6.1 exploration, just kind of an overview of everything that's happening in 6.1. It's actually going to be two of these. And I believe my next one is next Thursday. I did want to shamelessly promote this one as well. It's right here. This is going to be fun. We've done a lot of things. I think it was like around May time period. This was right before 6.0. Obviously a lot has changed since. Six. Even prior to 6.0 to now. And a lot of that has to do with block layout alignment and dimensions. So much has changed when it comes to this. One of the things that we see now are things like block spacing. Sorry. Spacing steps, these steps that allow you to pre-define different spacing steps. So we're going to cover all of this. We're also going to talk about fluid spacing next week. So I encourage you to check that one out. If you really wanted to get really deep into how to position and lay out blocks and WordPress. But again, if nobody has any other questions, we can answer them in the chat. Again, my name is Nick Diego. Develop relations at WP engine. Thank you everybody so much for attending. And hopefully I'll see you next week or another one of these learn WordPress workshops. Have a great day.