Recap Hallway Hangout: Section styles and other block style variation updates

On July 8th, 2024, contributors attended the Hallway Hangout: Section styles and other block style variation updates.

Attendees chatted about cool new features and handy tips for styling sections in WordPress 6.6. They also swapped stories and ideas on how to handle theme styles with section styles. The group shared their experiences and brainstormed ways to make pattern management and theme building in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ better. They stressed the need for smoother workflows, more user-friendly options, and greater efficiency, touching on challenges like tweaking blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. styles and setting default ones. They also tossed around some possible solutions, like breaking down partial files, registering block style variations, and using a JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file to nail down styles for default block variations.

Default Style selection

There was also a discussion about the need to be able to set a block style as the default for the content creator, so every time a particular block is added to the canvas the block style is applied automatically. This will help with curation efforts, and streamline’s content creation workflows. 

Interface overload for users

One challenge immediately clear to attendees was that the interface becomes heavily overloaded for users. How do you avoid having all the section styles on every group block? 

Currently, the block style variations that power the section styles are limited by the same constraints in theme.json. So they can only be assigned to a block type. Ideas discussed: 

  • Section / Block Style variations need more granular control to identify context. For instance, a headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. or an archive style would still show up in the editor for general group styles, or other container style blocks. They are not needed except in certain situations.  
  • There could be style variations that are hidden from the interface.
  • Use of a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. similar to `blockEditor.useSetting.before` that allows you to conditionally display block supports based on context.

Discovery issue when using style variations to style patterns 

Another feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. was to combine style variations with patterns. Instead of having a blue and a red pattern, create a section style but how would that surface for the user? And instead of editing the original patterns, change the style at a click of a button. 

One solution for this is to have only a few style variations that are aligned with the color palette of the site, so the buttons say blue, black, white, and gray. And then the user knows that they can apply a different color setting to the pattern and it would change predictably. The code example for such a system is on GitHub

This leaves the question of how a user would see the style variations when they add patterns, as there are no style variations preview.  

Watch the video for a more detailed discussion. Below you can also find a transcript of the recording.

Resources to learn more

Props to @greenshady for reviewing the post.

Transcript (via AI)

Computer, you are alright, so I’ll do the introductions again, just briefly. We are here to a hallway hang out on six and section styling and other block style variations. And, yeah, this is going to be, I’m handed over to Justin to kind of kick us off with some remarks and some , ideas, and questions. So in the chat, you can have your , just tell us where you’re from and , if you want to add the questions in the chat. But I think we have a small enough group that you just can unmute and ask your questions, that will be great. We also have here Aaron Robertshaw and Nick Diego and all the phenomenal block theme developers, so take it away. Justin,

All right. So hi everyone. Like usual, let’s try to make this a discussion where everyone can, you know, chime in with your questions, your issues you’ve already ran into. But the first thing I want to know, who has not tried out style, very section styles, or, like some updates to lot style variations in WordPress, 6.6 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Or we’re at the release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)., yeah? Or is there anyone who hasn’t, yeah? So we’re all on the same okay? We have one person saying, I do all right, all right. So I think the best thing to do is maybe just do a really brief walkthrough of what we’re talking about. Just okay, we have a couple people who haven’t now, I think that’s the best thing to do. And all right, we do. I do have a blog post. We also have a developer hours where we covered some of this. If we can link those in the chat, someone and Okay, so section styles. This is what we’re saying. This is the new feature, kind of in WordPress, 6.62 style, like an entire section of content. In reality, it’s not much of a new feature as it is an extension of the existing block style variations system. So if you just look at my screen, you see I have, like, this big green, greenish background, green, blue, teal, whatever color that is. And you’ll notice, like, there’s it’s got white colors. And if I just scroll down my page, there’s a whole different color, you know, with a different green and, you know, different and if I keep scrolling, there’s a whole nother section. That’s kind of why it would like text. And if you also notice, like in some of these sections, like my button, colors change depending on what section you’re looking at, and anything nested within the section styles can be you can customize the style of those things too. So what we’re really talking about and with section styles is we’re just talking about the ability to style things in an entire section and the things that are nested within it, whether that’s elements or blocks, and they appear in the UIUI User interface, just like any other block style variation. So if we quickly look, I can switch to style two, style three, which is not a whole lot different in this thing, but style four is very different. So and if you kind of watch closer, you’ll see like the colors of the buttons and other things may change depending on the style. So we’re we were very much styling nested things and oh, I have zooms in my way on my screen. I’m trying to click. There we go. And these can also be created within your styles folder, your theme. I’ve actually organized these into like style slash block. And this is, for example, section one, and that works just like a theme JSON. There’s a few extra things. You can set multiple block types, and you can set both the title and a slug the slogan. Block types are very new. And then you have your your normal styles property, which you can add css. You can add colors, spacing elements, and you can go down, scrolled a little fast. You can like, specifically target, like a block. How can this case, post title? You cannot add. Settings, which is a question that came up this morning, but you can add styles. So there several other ways that are outlined in the article on how we can, you know, work with the this new system. Like you can still register VHP via php. You can even past, like a themes JSON, like object and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher. So where we, uh, I feel like that’s just like the really quick, uh, overview of what we’re talking about. Like I said, I want to make sure this is very much a discussion now, of like, What problems have you had? Or what it what have you, especially if you’ve been using this so far,

I have a question to just prompt discussion. Okay, as you’ve been building these, it looks like you’ve, you’ve kind of kept to color for the most part. Are there any kind of heuristics that you when you’re building section styles that you’d like to follow? You know, is it, you know, there’s certain types of styles that you like applying and using in Section styles? Yeah.

Um, so I actually have several examples. The ones I show were primarily color. I think that’s the most the best use case, because color I’m trying to that that tends to be the best use case. Let me look at some other examples where I have run into trouble. So this is, like a grid layout. It’s got pricing cards. This actually has, if you don’t know, this is one section style on the outside. This is one section style for each of these cards. And then there’s one section style for this, like background like this, like where the price is on the card here. Like there’s an entire other section style. But one of the things I ran into is some some of these, like, I have this border on this. I don’t like the border in all situations. So then I start thinking, Should I add, you know, so should my section style to automatically output a border, I don’t know, because it works in some situations. It doesn’t in others. In this case, I kind of cheated a little bit and just added I have a custom CSSCSS Cascading Style Sheets. class has global border that I can, you know, remove. I don’t, I haven’t figured that out. But yes, color is the primary thing I’m using them for. I think that works well across depending on how they’re used. But yeah, so there are situations where I don’t want that border. That’s just a problem I’ve run into and trying to solve that means having to go back from using, you know, a section style, to either using a custom class or actually using, you know, the border controls. My goal is to not ever have to touch these design tools at all. I don’t, I don’t think this. I know. I think it’s okay for users to touch that, but as a theme, we’re talking theme development here. I, I would, I would try to avoid using inline styles at all. There are some situations where you need to, like, I think padding, spacing, things like that are mostly okay, because those are not going to change. Like, for example, I have this screen card here, and I want to, I’m actually looking at the wrong I don’t click on the wrong thing. And so if I change this entire card style, like, my spacing is not going to change, right? I don’t need it to change, because this is one layout. So I think it’s okay to like style this card and like, if you wanted to come in and add, you know, whatever spacing on certain sections. And I think your fonts are usually okay. There may be situations where you want to style fonts for specific section styles, and I’ve done that as well. I think I have an example if we look so I use section styles also for things like my, I have a new mouse I’m using, so I’m I can scroll really fast, sorry. Like this is a section style, this little post byline here, or you might call it post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., or Dateline or something in your theme. So. The thing is that I don’t really care so much about colors. I care more about fonts. And there are situations where I will style, you know, nested, nested blocks for that. So this is using my meta style. I’d use that for comment like in the comment as well, for like the Comment author, but not in this particular theme. I don’t have it, but, and one I have where I have styled the like the specific author block. I think the use there’s just so many, there are so many use cases to cover. You can literally do anything you want to. And that’s kind of a double edged sword. What, what should you do and what you should not do? I would start with this new feature, starting with colors, just seeing what you can do, like with a background color and a foreground color or text color, and seeing how that affects, you know, other elements. So if we go back and look at section one for my theme, at least. So I started here. I started with, you know, custom background, custom color text. I also have some spacing that I can probably remove now. But then I thought, Oh, my captions in my main theme JSON are styled differently. Oh, I need to, like, I just use current color. And I’ve done that a lot, but there are situations you need to make sure to test everything, like, test your captions, test your citations, headings, of course, test your links and what their color should be. And then you’ll want to test blocks so it can get complicated very fast, just with colors alone. And so that’s when I say, start there, and then, like, make adjustments based on what your specific project needs. Alright. Would we have anything going on the chat or we have questions? Oh, what Justin said? Let’s see from Brian.

Well, I have a question. So when you go back and to one of the other ones, I see kind of six or seven or eight different styles in there. Are there really all different styles? Do you? Did you just kind of put them all in the style variations, and they’ll they’re all for all blocks or, or they’re all three container blocks, or, okay, also for others, yes,

so that’s a good question. In this situation. What you see on the group here? These are almost all what I would consider section styles. They are on container type blocks, like I have a I have them on a few I know some people probably wouldn’t recommend putting them on the query block, but generally on Container blocks, like, you know, group column, you know, columns, maybe media and text for Section styles and so all of these are for those sorts of block, container type blocks. And I’ve been trying to cut back. It would be nice for the theme I’m building. I’ve also been building previous to this feature. So I’m also, you see a lot of these. There’s probably some situations where I can get rid of some of these, and I have gotten rid of some. Like, I have one just for selling, like, the archive page header, like, so if you click on Justin Tadlock, you know, this is a style, but theoretically, I could probably just make that like, you know, this style too, which is very similar, you know, this got the same gray, you know, that’s one thing I could do. But I could also leave them separately. If I wanted to style them separately. That’s a project level decision. But I also think to really take advantage of this for like, from a UXUX User experience user perspective, it would probably help to cut back as much as you can on like these options, I feel like this, like, what is this? 12345, 10 options, that’s quite a bit, that’s a little bit of a choice overload.

Yeah, yeah.

I think Carolina has a similar question. So there’s, how do you avoid having all the section styles on every pro block?

And, yeah,

yeah, that’s my like, I wish I could have, I don’t know how to avoid that be I wish I could, like, remove this archive header, remove the site footer and site header, because they’re not needed, except for in very specific situations. And the reason I have those. Are because there’s no other mechanism and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to style these, these, like these, pretty common sections and themes through theme JSON, other than, you know, maybe like some custom properties or stuff like block style variations are the best way to style those, those sections that are kind of one offs, like archive, header, site footer, site header. There’s a very much one off things. They don’t really need to be style variations, but there’s no I haven’t found a more ideal way of styling them without custom CSS and so on.

I just had an idea, yeah, because you know how with like patterns, you can do like inserter false or inserter hidden, so you can have a pattern that’s like part of the theme, but not represented in the UI. One of the things that I’ve done a ton with block styles is basically create the class. And this is not, this is not with section styles. This is just being CSS. Basically have, like, hidden, quote, unquote block styles that are only handled by the the style by the the class. Maybe it’s a terrible idea, but it’d be interesting if you could do a block or section style, or block style variation that was, like, hidden from the UI. So, like, the class could still be added, you could still register and theme by JSON, not theme of JSON, but in a JSON file, but it was just hidden from the UI. That’d be kind of interesting.

Yeah, I love it. We need a ticketticket Created for both bug reports and feature development on the bug tracker. right now. So, yeah, I mean, I have use cases for that sort of thing. And I mean, we’re seeing those use cases that work, and, you know, in real time here, like the archive header and like my site footer, like, say, site footer on this theme is like, got this grayish, you know? And I want that. I also want users to be able to style that, like, just change it to you if they want. So I don’t know I would like this for that. So let’s, let’s make a note of that for we need a ticket on maybe hidden blocks. Or, you know, it doesn’t necessarily need to be hidden block style variations. At least, needs to be some way to style things custom through theme, like a theme JSON, or, you know, that similar mechanism for whether that’s hidden or or just some other like, you know, property Within theme JSON or something. Yeah, great idea. Nick, I Yes, all right, looking at the chat a little bit, but yeah, use the hidden classes. Works already, and that does, yeah, you can use hidden classes. And I do a little bit of that, trying to think like I will add, one thing I do is, like custom properties, you know, under in theme J sign, you can add, like, I even have things handling, like custom elements, because, you know, core doesn’t, you know, I can’t style inline code, you know, through theme JSON, so I can do that. And that creates a, you know, custom class. And I could show you the custom class really quickly, so base elements, so scroll up and look for my code section. So in that creates, like these custom classes. I mean custom properties, I mean, and you could do that with class custom classes as well, so that, you know, all of these are generating the, you know, custom properties that are used in mycs style sheet. That’s kind of like a one way to get around some of those limitations. And I could very well do that with like, the archive header and site header and so on. And I have, and I’ve done those that way, until I moved them over to like, the like we have the section styles now. So I’ve moved like archive, archive header, site footer and site header over to this newer system, if that makes sense to everyone. All right,

so Aaron also mentioned that there is has been some discussion on defining a scope property in the theme JSON parcels that might allow filtering the context of the section styles, and I think that will be a really good, standardized way. But Erin, would you have by any chance the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ discussion for that?

I would need to go digging for that one. Yeah. I. Can,

I think it was just hoping that you maybe have it just in front of you so

but what I can share there was the the general thinking was that to bring it in line with, like our templates and patterns, etc, that we could just sort of indicate more generally the context that a variation might actually apply. So it’s not a complete, powerful filtering mechanism, but it would be the next step or the next iteration, to build upon this feature,

to dovetail on that briefly, we do have the filter I’m putting in the chat. We do have the filter used for other things that allows you to, like, conditionally display block supports based on context. Like, you could have a button block that only shows specific color palette went inside of a group, or something like that. That’d be kind of cool. Like, if you had, like, if you knew that a group was inside of a cover block, that group would only have a certain set of blue section styles or whatever, using the context of based on where that block was, just as some prior art sharing that of a filter, but that’d be cool.

Yeah? Brian Gardner, what do you have?

Oh, that’s a loaded question,

yeah. Why did you raise your hand

so that I can personally ask Aaron to make sure that slashing thing can get pushed into RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). three. No, my encouragement, based on the way, more hours than I probably should have spent working on this, and several conversations with people who are even present on this call, is that Inception can happen very quickly with this, and that the at least, for me, from a product perspective, I’m trying to, like, narrow the scope at the beginning and just use it for one sort of application. Because you could just open this up and, like, you know, have a section style for this and the color stuff, like, all of a sudden it gets really confusing fast. And so for those who are exploring, I would just say to temper, like, the scope of your initial use of it until two things, one, you understand it better, but also more things get developed, and there’s more sort of support beyond just the 6.6 release, because there’s more coming from what I understand in terms of, you know, creating possible GUIs for like, editing the content of These styles through the dashboard, versus like code. So, yeah,

it’s a good point. Yes, so before Carolina, there’s also Tammy had the suggestion, so just bring them up to parity with patterns. I think Could you elaborate on that a bit

that was relating to when Nick was saying about the ability to hide and stuff. I was way, way ago, so I think Carolina’s probably in this time frame, rather than in the back show. Yeah,

sorry, I didn’t get to all right? Karina, so

this is a more of a wish list item. I would like to be able to quickly change my patterns, instead of having one red and one blue pattern, whether they’re synced or not, actually going to have to be synced the very day. And I would just click the button instead of going into having to edit the original pattern, for example, to change the colors in two or three locations. So it’s not only about checking whether this style is on a group, it’s inside a cover block. I want my whole section to be complete in a pattern, bottom part, but patterns first.

Yeah, Brian, you said you could speak to that.

Yeah. So thankfully, the Fourth of July holiday has afforded me some days to play with this. So I have updated my powder theme to essentially powder has always shipped with two different versions of patterns, white on black, black on white. So it’s made it very easy to work within a design system, to just wrap every pattern in a group. And my goal, even though I still may not do this, my goal, was to half the number of patterns and just basically apply section one, two or three to the pattern, and it would control it top to bottom. I don’t love the I love the simplicity of shipping half the code. But what I don’t like is that users don’t see that inside of like the pattern explorer, so there’s no way to show like every pattern I’ve got created, headers, footers, call to actions could essentially be four different flavors, right? White, black, gray and purple. I can insert a pattern and in one button, just as the video I showed, just change the whole pattern into the way I wanted to. But the users don’t see that when they go to add the pattern into the thing. So there’s a little bit of an education that says, add the pattern and then change the color, as opposed to seeing four different colors of each version in the pattern. Explore. Or and the only way to do that is to ship four times the amount of code, which isn’t ideal, but it also, from the marketing perspective, might be more appealing. So you kind of have that, that wrestling. But I’ve, you know, wrap everything in a in a group, and I’ve limited all of my section styles to just the group block. Like, my intent is to just say, this is basically a pattern Color Changer. Like, I don’t you know what I mean. So, yeah,

yeah, I’ve seen some of Brian’s use cases too. So, yeah, yeah, I don’t like the idea of shipping patterns that are basically the same code with just like one little aspect change, and then it does cramp the UI a little bit. I think, yeah, we do need some workflows in core, like with around how like themers are using this feature. And we’ll get more feedback, I’m sure. So definitely open tickets, you know, Gutenberg tickets around, like, your ideas and stuff, so we can, you know, talk them through, and then I have other people come through. I think that’s this an implementation problem, but we can, but the more like Gutenberg itself and core can, like, take care of, help us out there to be with the great Carolina you’re back up.

This is more about the reflection on you source, not being able to see the style the preview. So when you when you’re in the editor, you have your style buttons. You hover over the button, the preview is not good enough. And I believe there’s a suggestion to even remove the preview, which I’m against, because this is also one of my my pet peeves. However, you say that in English, pet peeves text in the button is not enough, right? I can’t fit my description for the style name on my button, and I can’t name them, style one, style two, style three, because it’s not enough context. It doesn’t tell anyone what style one is, unless you really you add it and then you have to go in and do it or whatever, because the preview doesn’t work, and if you add it again, you have to do these extra steps. So I would really like to see that part improve.

Yeah, plus one, yeah. Yeah. So it’s actually my comments basically mirror what Carolina just mentioned. I think that the I’m interested in how users, once things like powder go out in the world, in the world, and other examples, whether like, even in the in the upcoming 2025, theme that might include this functionality, like how users reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to it, because it’s not that many themes use style variations, block style variations, like 2024, is a handful. Like, there’s like the asterisk for headings, and, you know, there’s like a list style. But like this concept of like, changing entire sections, changing the color of them from a user perspective, is very new. And so, like, the default is like, Okay, you go to the color, you change your background color, you change it, you know, you click through all the things and you update it that way. So I think this is a very new thing, not only from a theme development perspective, from a user perspective, and without improvements to the preview or the presentation of block styles. I’m curious how users are going to receive this and actually use it, and maybe things like powder, a great example. I think I like what Brian did with his naming convention, because the names are tied to the names of the colors in the color palette. So at least there’s a little bit of a mental model there where you can kind of tie, oh, oh, this is primary. Maybe that relates to color. Okay, you know. Okay, click primer. But I don’t like UI where it’s like, choose your own adventure. You just kind of are clicking things to figure out what they do. In the little experience that I have, like users are very reticent to click on something that they don’t know what’s going to change and so, and because these are such impactful changes, where you know, changing the visual esthetic of the entire section, new users might without having more context around what the button does, might be reticent to actually end up using the feature. So I think that there’s in future iterations and improvements to how block styles are visually displayed, I think would definitely go a long way in making the feature more user friendly. Yeah. So,

alright, yeah, agreed. Tammy,

yeah. For me, I think it, I don’t know if storybooks the answer or style, but storybook as but for me, it’s about stopping seeing it as a side panel that has things in, and start seeing it as theme design system. And because the problem of scaling of our interface, I go back to this problem is solved outside of WordPress in design systems. So if you want to see a different component and difference, it works in design systems. So it’s not a problem that hasn’t been solved outside our space, and it’s a language that has already been solved. So it’s about, probably, it definitely is about our interface changes, and it’s definitely about having a changing of the each component, and then talking like that, the theme component, and people knowing that they can change that each time. That is also part of that. I think, rather than seeing it at this side, I cheerfully would like both the preview and the block styles. I don’t think either those work for me. User Testing. I’ve seen so many people just I don’t think the previous solves it. I don’t think the buttons solve it. That whole thing be working. I honestly think it is more browse the styles as they are, pick them in a more like book format and design system, because that’s what has worked into time and more it. But I’m open to any hair brain schemes we want to have in between that. So yeah, but I do think it’s that like being able to see the thing and see it changing, and see that it’s got different changes. Could even just be that point one. See that it’s got like, four styles. You know, those little things like, this thing has four style changes. Boom. This thing has three style changes. Little, little things like that. We can start trying and see what people adapt to, I think, is really curious, but we start thinking more in the systems, and start being invested, like, the theme just ships with a couple of things, because that’s what we’re building, which I think is super fun.

Yeah, awesome. Do you want you want to go ahead and share Brian or,

yeah, if you all don’t mind, this is just more a demonstration of this, just in, like, the real world, because I know that, you know, Justin, you shared your kind of interpretation of it. And I think we’re all going to have different interpretations and executions. And I think sometimes seeing this in action actually, like, oh, okay, you know, because we could talk about it, we could read articles that show you how to do it. But I think until you connect those dots and see this in the real world, that’s why I wanted to share. So I’m just gonna that’s cool. So this is my theme, and using, I’m leveraging the tailwind color system inside of my theme. And so there’s 22 different variations, each one like that mirror up with the tailwind color. So I kind of am working within colors and shades, but in terms of the patterns themselves. So this sort of section is all wrapped in one group, and that group, as I click over here, has the base style. You can see it’s just basically the black on white. Now I have let me just do this really quick, but you can see, inside of every single variation. There’s there’s white, black, and then sort of three different shades of purple, and then what’s called a neutral. And so there’s corresponding, as Nick mentioned, I’ve created four different styles, one called base, which is what we see. And if you click contrast, then it just automatically knows how to change everything. And I’m using a lot of current color here. And then if you click on primary, then it becomes purple, and then neutral, and so on. Now to go a little more further, using kind of the button aspect of this, this is kind of similar where, if you click that, then the text changes to whites. But then you go here you can’t leave the button purple. So in this one, I change it to white, so you can start to see, hey, this is, you know, and then neutral is just like the lighter gray, so it’s very much like basin. So all my JSON files are very, very basic. Let me just, I’ll do this just for the sake of demons or not demonstrating, but, so I’ll drop this link after I’m done here. I don’t want to take up too much time, but this is basically the four different JSON files that are inside of powder. This is this has not shipped yet, so I’m waiting on 6.6 but the slugs are named 1234, so that the kind of aim towards a little bit of interoperability. But the UI part of it is for the user, right? Contrast, primary and neutral. So this is kind of just how I’ve chosen to at least explore it as it relates to the work that I’m doing.

Definitely, and I want to touch on it, because we talked about it a bit here as like naming. There is a ticket. There are two, as I mentioned earlier, there were two different like you seen in my demo. I had style one, style two, style three, and so I would not actually name those that way and like something that’s going to be in front of users. It would be something like what Brian has, base, contrast, primary, secondary, whatever your system is, but under the hood, the slug. So far, we’ve mostly agreed, I think, on like using section one, section two, section three. That way the this user can use, say, 2025 and then switch to your theme in those no matter what the title is, the slug is the same. And you know, they’ll be able to switch themes. Maybe we’ll straighten up some of the issues from the past with slugs and going forward, at least with, you know, these section of styles. But, yeah, don’t. Do not follow my example. Style one, style two, style three. I think that’s a horrible way to name things. That’s just for example. All right, anyone, like any issues folks running into so far, I have some I can share, but I want to hear from everyone else. Aaron,

this wasn’t so much an issue, but more perhaps a way of thinking. When you approach crafting your CSS, you’re not going to throw the kitchen sinkKitchen Sink When using the WYSIWYG (What You See Is What You Get) editor in WordPress, you can expand the capabilities to allow more options. This expanded area is called the "Kitchen Sink." at a single class or start nesting it deeply and then try and reuse that over and over, or nesting those classes within other classes, because you get conflicts naturally. These variations and section styles are just a set of CSS classes and styles. So the same things you would try to avoid when handcrafting CSS, avoid those same pitfalls when you’re thinking about these and when you’re crafting these section styles, if you think of them from the perspective as that they can be nested within each other or themself, then that’ll start to jog or see the thoughts about what styles might conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. and which ones you do need to consider, like links and buttons were mentioned before headings as well as another good example. So I just wanted to throw that out there, because I think that was sort of when I was crafting all of these test cases while implementing it that really helped, sort of just get things happening faster, and it became a lot smoother after that. So

I definitely agree keep those things in mind as you’re building them. Uh, Nick, yeah, I just had

this is kind of an open question. So because section styles are kind of a unique case of just block style variations, because they show up in the same UI, we run into the long standing issue of not being able to combine block style variations because they’re just CSS classes, right? And so I think that it poses an interesting situation where, if you are a theme developer, and you’ve already created style block, style variations for blocks, let’s say a group block. I think Brian, you had one that was shadow or something, and it adds, like, a unique style variation to the group block, and then you start implementing section styles, you start to get section styles feel like a very different thing than block style variations, even though they are kind of the same thing. So, and again, this is just something to I’ve had to think about, how do we handle that? You know, in future, WordPress releases an answer for it, but it is something that is interesting to think about. On that note. Real quick, I can jump in and I my daily pitch to get group blocks to support shadows. The only reason why I have that as a block style, so you have it as a block style, which means in the CSS, there’s a is style, dash, Shadow, or whatever the class is. Now, when it becomes an option, and I’ve already done this as well, when it becomes an actual option, when a block supports that, in other words, when group supports shadow, I will pull the UI part of that so users no longer. Get confused. I really don’t want to have like, a mixture of like, some like styles that do this one thing and then, like my four other ones. I really want to just protect that space just for those four, at least with the group block, and so I can pull that but if you leave the CSS class anybody who’s used it to date, and you could still actually use that class as well through, you know, additional CSS. So my hope is to, like, remove things, but also leave support for them, so anybody using them already to date, don’t all of a sudden, like, have that style gone and so. But I think these conversations where we talk about these things, and we do things like get on calls and pitch for group block shadows and have a bunch of people shake their heads and say, Yes, we should do that. Like, is helpful, because then those who are making those decisions or contributing that code realize that it’s an important thing for us to to ship so that we can, as users and distributors of, you know, products that are built on WordPress can get excited about and then make it a better user experience. So I like these calls, and I just Just one quick thing there. I just think that, like, yeah, we removed the shadow because you it will be in core eventually. But like, if you have, like, a really complicated block style that does stuff that theme dot JSON or JSON files just don’t support, like, you need custom CSS. You have a custom style, but you want to use that in conjunction with style variation. Block, style block, sorry, Section styles, you really can’t. And I think that there’s a good reason why you can’t, but I don’t know it, just it makes it the, at least the UI portion of it feel strange to me. So just something to think about in future iterations.

Yeah, I think to building, I mean, basically what Nick was saying, just said a little bit differently, is that we don’t have a way to create custom utility classes. We have, I mean, lot style variations I don’t really consider as like these smaller utility things that you can mix and match. We do have some utility things like, you know, custom, you know, font presets, spacing presets and so on. But we can’t add custom things, like, before shadow is there that we could not say. We could do something like Brian has done, like, you know, is style shadow, but we had to use the block style variation system to do that. I don’t think that’s to me that’s not always been the best use case, because there’s little one off things. You always end up wanting to mix them with other little one off things. And whereas I see like block style variations is more like you’re styling an entire component, um, instead of like a simple utility. So there’s like, two different use cases that people have used the things for, and they kind of compete. They don’t go well together, um, so, yeah, I’ve been anti like mixing, being able to choose multiple block style, block styles at once, just because it’s it’s going to able to break other use case, it would break some use cases, and it’d be great for for some so we were just kind of missing some system in court there. I feel like I don’t know what that might look like, concerns of UI and so on, but we do need, maybe we need, a new ticket that explores that. All right. Come on, folks of who tested any other things you’ve run into, tips, tricks or issues. All right, I can go back and share like something I think I touched on what Aaron was sharing.

I would want to ask Jessica, you have done a lot of explorations of the section styles and and you also are one of them. You have all your questions in the outreach channel. Did you get all your questions answered there? Or, because that’s very helpful to kind of put them asynchronous in the outreach channel. But I just want to make sure now that we have all the theme developers here. Did you get your questions answered satisfactorily?

Oh, what’s the point that? So yes, I get, got them answered, but like to the point of where I have to make a decision for the product, which is not to include them in a next update, and instead wait, because it will, it would be a bit troublesome for the backwards compatibility. So. So internally, we decided not to really push this forward yet, so probably maybe for in like half a year, or maybe a year, that would make sense. It’s but it has more to do with like this, bumping up the minimum requirement to 6.6 so you cannot ship any more updates to to your customers that are not, not specifically just for the 6.6 updates. So yeah, so that’s where I also like cut off the testing at this point, because, mean, there’s no much, not a good use case right now for an existing product with a user base pushing this forward at the spot.

And the reason is because all the section signs on a theme version, a theme JSON version three, that only comes with WordPress 6.6 and lower versions WordPress 6.5 and so on. They are not having those theme versions three in there, so you can’t use those things. Yeah,

can I just clarify something there? So the section styles themselves, the extensions of block style variations don’t rely on the version three of the theme, dot JSON schema, you can still use them without that. So effectively, you should be able to use the section styles with Gutenberg or 6.6 so will Gutenberg supports two prior versions of WordPress, so that should sort of be the minimum requirement that you’d need to leverage this feature.

Yeah, but then, in IDEA world, you wouldn’t need a Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party at that point, and you cannot force your customers to update to 6.6 ideally they should, but there are lots of use cases where it’s not possible or not wanted for whatever reason, and that’s where we are kind of stuck in, because if you put the theme to require 6.6 as minimum, it’s like you cannot ship any further updates. That’s the major problem at this point. Yep,

I’m reading. Brian cords has a question, and I’m not entirely sure. I’m trying to make sure I understand this. Is there support to add a block style JSON file that would define the styles for default variation of a block. The idea being, I could skip the using theme JSON for individual block styles completely. I mean, you don’t have to have you use theme JSON for block styles. You can just register them via php. I don’t know if that answers like you can just register them and via PHP, and if you need to add custom CSS elsewhere, you can do that. I’m sure you I’m sure Brian already knows that. So I feel like I’m missing something in the question

real quick. And I think I’m getting the question, Brian, let me just drop this and see if this is what you’re talking about. So in the spirit of having sections that needed to be white inside, like on a pricing table that had a black background, I needed to be able to set something to white, which is effectively the default, right? I actually created a style called base that is basically the white background with the black text, so that I could use that inside of other places. Because if I didn’t, what would happen is it would just inherit the outer one and, like, it would just be like a transparent, like, like group, like, if you think of like a card inside of a pricing table. And so you need, I needed a way to set that white. So I created a style called base, which means, technically, I don’t need the styles that are inside of that to be in theme JSON, because there’s no i No need for that. I don’t That was the question that you were asking. At least, at least, that’s maybe how I interpreted it. But,

yeah, I can clarify the question too, if that’s helpful. Um, I think that’s a perfect example. The cover block is another example where the default of the cover block is a little opinionated. It comes with changing your text color or something like that. So it would be amazing if I could just make if I could just style my cover block, my button, my out these things as those, like kind of partial JSON files, and not even go into theme JSON, because theme JSON is so big and unwieldy. But now I have this nice folder where I can have little separate files for all of my default, you know, basically the default block style variation, like a button, is another example where it’s a little opinionated. It would be great to style that, but not have to do it in theme JSON. I could use it in these partials. So I know that’s a bit outside of the scope of, like, the concept of the block style variations, but I’m just wondering, can you. Override default styles, or set a variation to be default using just the folder structure, not registering it in PHP,

not a current Not at the moment, yeah,

this kind of gets back to like, the question of like, could you have a structure? Again, I think that people have examples of this, like coded examples of this, where you basically take the theme dot json file and you can, like, break the whole thing out so you can have individual files for all the different blocks and, you know, styles and settings or whatever. So basically you take your, like, destructuring theme dome JSON into separate files, and then there’s, like, a compiler that compiles it into a full theme dome JSON file. I’ve seen a few examples of that. I’m not, I don’t have the mount hand, but I do think that would be a really cool way, because I feel like, at least for me, when I was doing like, per block style sheets, back when we couldn’t do as much in thing. But Jason, it’s very handy because you have all your different blocks broken out. Like, from like, a developer perspective, it’s very nice to have everything broken out. You’re not dealing with one massive file. But file. So I don’t know that’d be cool to see in the future.

In the short term, you can filter the theme dot JSON data. And so effectively, we take those partial files and we copy it into the relevant sections of the overall theme dot JSON file. So by the time it gets to the style generation, there are no partials anymore. So you could do the same thing that we’re doing with the other partials, but instead of them being inserted under the variations key, you’re inserting it under the block type, and you’d go from there. So it wouldn’t take much to jump to that?

Would there be a potential? Because if you register a block style variation, there is an is default argument when you registered in PHP? Is there eventually an idea that there would be a parity between the two different methods before I, like, make some janky work around, like Nick’s describing, which we have actually done with the partials and stuff, and you kind of regret, you regret going too far from court with that stuff.

Honestly, this is the first that I’m considering that default variation or style. So I think what we need there is a GitHub issue. We can thrash it out, and we’ll all settle on the best path forward from there. So I can’t answer that one straight away, sorry. Okay,

I’m over here. Just wanting to play around with that idea now, yeah, just break everything down and to partial files and get rid of my 2500 or whatever line, theme, JSON, this at least 2000

All right, coming up, we have five more minutes. So I think we have one last question that we could answer collectively, if anybody wants to raise their hands and we’ll have a comment

about things I

I’ll reflect a little bit on the lengthy theme, Jason. It’s a slight kind of side quest, but one of the things I’ve noticed is each release my theme, Jason is getting shorter, and I love that, because we’re getting more things, either in the UI or we’re getting more things that I don’t have to do lengthy custom things in the theme Jason. So I guess my point here is, if you find yourself creating giant theme Jason’s and maybe think about how the features that you’re using in there could be more compact, or could be a function or something like that. That’s one thing that I’m reflecting about on, like, how much customer stuff Am I putting in there? How could it be made into issues? So I think there’s also something in there of, like, what are we putting in there? But I personally try and not use CSS. I try and only put it in there, which is a whole me problem, I guess so much. Just

a reflection on that. I

guess I have a quick question for Aaron, since you’re here. So what is next? Is there anything on the roadmap for that you can speak to for 6.7 with regards to Section styles and kind of the this area of work.

Um, I probably can’t make specific promises on what will be in 6.7 but I can certainly speak to what the next steps are. So at the moment, in global styles, you’ll see in the UI, you’re only able to configure the variations top level style. So what’s applied to the block that you’ve assigned the section style, block style variation to? We need to find a way to allow configuration of those inner elements and those inner blocks. And it sort of is a nod to the no code. Editing of or creation of themes, or just provides quicker, easier ways to make those tweaks. So the catch there is, we could continue this drill down paradigm that we’ve got in that global styles, but once you start going to block types, to variations, to inner blocks or elements, and it keeps going down further and further. Now you get lost and you don’t know where you are, so we’ve got to solve that UX issue before we can go too far. There other things that were going to be explored were the composability of these section styles. So it’s already come up in this discussion whether we can mix and match, but obviously there’s a big can of worms there, like the order that you would apply these variations would completely change the results if there were overlapping or conflicting styles. So how do you flag that, avoid that, manage that? So there’s a lot to come out of that. So I think the first step is sort of consolidation of what we’ve got learn the lessons from 6.6 and that might inform the highest impact areas that we can enhance. But I would like to see some of those gaps closed in the UI, at least, so that you can get the job done there and we can improve it and move forward from there. I know there were some enhancements that were shelved during the process of getting to the point we’re at now. For the UI, whether we parse out color only variations and move those into the Color panel and typography only section, Styles would be moved under the typography panel, those sorts of things, and we can then provide different previews or cards that might reflect that better. So you’ll know the styles cards in the site editor that have sort of the color palette to it, or the typography these sorts of things. So we might be able to leverage those UI elements to just provide better visual cues as to what you’re actually looking at. So to your point earlier about randomly clicking and trying and that pick your own adventure, I think was the term you used. So to sort of avoid a little bit of that you can see a number of cards or pills on the UI, and you know that you’re looking for the blue one and it looks blue, or you’re looking for a serif font, well it’s reflected. So I think those sorts of improvements would really make a big difference. But there’s always more power, more flexibility that we can add, refine it. Yes, and then there’s a proposal about updating how we handle the global styles post type, and that unlocks a whole new world of possibilities there too. So with so much possibility, it’s a little hard to say what to watch out for next, because there’s a lot that could happen so exciting times there for sure.

Yeah, bigger. Thank you trying to tell with and you’re on mute. I’m

on mute. Yeah. Thank you so much, but you could go and close out the session as well. I just wanted to say thank you so much for being here and contributing to it, and it was a great discussion. And, yeah, what is the next thing that you want to discuss on a hallway hangout? Yeah, some people say, Okay, this is a good thing to do. So what would be your next topic? That’s all my question. You don’t have to answer. Now think about it, and we’ll talk about it in the outreach channel on the Ripper slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Well, thanks everyone, and thank also Brian Gardner for sharing his Justin. Aaron Nick and everybody else Carolina. Have a wonderful evening, afternoon, morning and good night, Aaron, you’ll see you later. Bye, bye, bye.

Transcribed by https://otter.ai

#block-themes, #hallway-hangout, #summary

Hallway Hangout: Theme Building with Playground, Create-block-theme plugin, and GitHub 

During and after the Hallway Hangout on using the Site editor for client projects the question on how to handle version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. workflows for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme development surfaced. You are invited to join Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. and theme builders at Automattic, discussing and sharing a workflow that combines open-source WordPress tools: Create Block Theme pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and WordPress Playground. Playground allows them to connect their work to a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository for managing their themes’ version control. 

In this session, theme developers will demonstrate the design, development, and preview approach for Automattic’s process. You will learn how to make all the connections work seamlessly from Playground to GitHub and back again, and how to work with the features of the Create Block Theme plugin.  An extensive time for Q & A allows for plenty of questions answered. 

The event will take place on June 19 at 11:00 UTC. The Zoom link will be posted into the #outreach channel on the day of the meeting. There will be a recording provided for those who can’t make it. 

Props to @greenshady for review.

#block-themes, #hallway-hangout, #outreach

WordPress 6.3 performance improvements

Update (Aug 8, 2023): Benchmarks in this post were updated with results for the 6.3 stable release.

With WordPress 6.3 now available, this post summarizes the performance improvements that are part of this release. While WordPress 6.2 set the bar high with its notable boost to load time performance of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., WordPress 6.3 has been able to exceed these results: Based on the performance benchmarks conducted, WordPress 6.3 loads 27% faster for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes and 18% faster for classic themes, compared to WordPress 6.2, based on the Largest Contentful Paint (LCP) metric. For WordPress 6.2, those improvements amounted to 18% and 5% respectively, so it is fair to summarize that WordPress 6.3 is a major achievement in terms of performance.

Thank you to @clarkeemily for collaborating on this post!

What makes 6.3 so much faster?

To break down the performance improvements in 6.3, it is crucial to understand the different load time performance metrics and how they relate. The most holistic metric is Largest Contentful Paint (LCP) because it captures overall load time performance. As such, the percentages mentioned in the introduction of this post were specifically the LCP improvements measured.

An important part of LCP is the Time to First Byte (TTFB) metric, which captures server-side load time performance and thus directly affects LCP: Effectively, TTFB is the server-side part that contributes to the LCP result. For client-side load time performance, there is no dedicated standalone metric. However, since client-side performance is effectively everything else, it can be concluded that client-side load time performance can be expressed by the difference between LCP and TTFB, i.e. “LCP-TTFB”.

Client-side performance

In WordPress 6.2, the majority of the performance boost came from improvements to server-side performance (TTFB), as highlighted in the aforementioned 6.2 performance improvements post. In WordPress 6.3, that is different: Most of the performance boost stems from client-side performance improvements (LCP-TTFB). In fact, client-side performance in WordPress 6.3 is 40% faster for block themes and 31% faster for classic themes, compared to WordPress 6.2. For reference, in the comparison of WordPress 6.2 with 6.1 LCP-TTFB amounted to only a 1.5% and 2.5% improvement respectively.

The vast majority of the client-side performance improvement comes from optimizing the emoji-loader.js script, by leveraging modern JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. APIs such as Web Workers, OffscreenCanvas, and sessionStorage. Unless your WordPress site has disabled the related emoji functionality, you should notice a performance improvement due to this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. See #58472 and [56074] for additional context on this change.

The other notable portion of the client-side performance improvements stem from adding support for the fetchpriority="high" attribute on images. As such, this improvement is only relevant on content with images above the fold, but given that images are by far the most common media used on web pages, it is very likely that you will notice a performance improvement from this enhancement as well. For a comprehensive overview of how to leverage and modify the new functionality as a developer, please refer to the 6.3 dev note on image performance improvements. For additional context on the change, see #58235 and [56037].

The following list highlights a few additional tickets that can improve client-side performance in certain scenarios, several of them enhancing the heuristics for whether to add the loading="lazy" attribute to images:

Last but not least: A notable developer feature that should be highlighted here is the introduction of script loading strategies, which adds support for loading scripts with defer or async. This is a major milestone for performance in general, however so far only the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. itself has been introduced, which means there is no actual performance impact from it yet, which is why the change was not mentioned earlier in the post. As WordPress core and the ecosystem starts adopting the API (e.g. defer for block view scripts and async for comment-reply), it is anticipated that in the future we will see notable performance improvements from it as well. Please read the 6.3 dev note on registering scripts with async and defer to learn more on how you can leverage the API as a developer and the advantages over approaches that directly manipulate the script tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). See #12009 and [56033] for additional context on this change.

Server-side performance

While server-side performance improvements in 6.3 overall did not account for as much of the performance boost, the release still includes several notable enhancements, particularly for block themes, where server response time is 19% faster. Many of the server-side performance enhancements are the result of optimizing low-level logic in WordPress core internals. While this makes the improvements difficult to describe in isolation, it means that they don’t require any adoption or modifications in the WordPress ecosystem in order to become effective.

One of the most notable performance enhancements for block themes was a low-level change which optimizes how WordPress core block styles are registered. This is relevant since core block styles are handled slightly differently from those of custom blocks. Prior to 6.3 however, all blocks were using the same general logic which included quite a bit of flexibility, and thus also a performance cost, which was unnecessary for the core blocks. The change introduced a dedicated function to register core block styles in a more efficient way. See #58528 and [56044] for more context on this change.

Another major win for block theme performance was an improvement to the get_block_templates() function. The logic in that function was optimized to no longer process all block templates but only those that match the current query. See #57756 and [55687] for more context on this change.

The wp_common_block_scripts_and_styles() function is another optimized function that is certainly worth highlighting. This enhancement is only relevant to hybrid themes, specifically classic themes that call add_theme_support( 'wp-block-styles' ), but for those themes it results in a major server-side performance boost. See #58560 and [56064] for more context on this change.

The biggest change that has a notable performance impact for both block themes and classic themes is a performance optimization in the wp_maybe_inline_styles() function which avoids unnecessary calls to relatively costly functions to get the size and contents of stylesheet files. See #58394 and [55888] for more context on this change.

The following list highlights a few additional tickets that can improve server-side performance in certain scenarios:

Database performance

Several enhancements were made in WordPress 6.3 to lazy-load metadata, which can avoid database queries in certain situations. These changes are outlined in the 6.3 dev note post on metadata API improvements. See the individual tickets #57227, #57645, #57901, and #58185 for more context.

Additionally, the get_pages() function now uses WP_Query internally, which not only means elimination of duplicate code, but more importantly it leads to a performance improvement in the function as it now benefits from the same solid caching behavior, something that was missing in the previous custom implementation of the function. For more context, please see the 6.3 dev note on the get_pages() function and the ticketticket Created for both bug reports and feature development on the bug tracker. #12821.

Last but not least, the WP_User_Query class now supports caching query results, becoming the last of the WordPress core query classes to support it. This can avoid database queries when querying user information. For more context, please see the 6.3 dev note on WP_User_Query caching and the ticket #40613.

A note on the benchmarks used

While the metrics shared in this post are based on benchmarks that were conducted with the same methodology used for WordPress 6.2, any benchmarks need to be interpreted with nuance: Other than how the WordPress site used for benchmarking is configured, benchmarks are heavily dependent on the environment that they are run in. To have additional reference points, a few different contributors conducted and shared their benchmarks as well, based on a slightly earlier version of the release, 6.3 RC1. All of the benchmark results are summarized in this spreadsheet.

It can be noted there that some of the other benchmarks did not see improvements as high as noticed in the benchmarks highlighted (which, for context, were run on the author’s machine), but the main takeaway is that there is a notable performance boost overall. For now it made sense to focus on the performance benchmark with the numbers highlighted in this post in order to be consistent with the numbers from the aforementioned 6.2 performance improvements post, since that was using the same environment for the performance benchmarks as well. For any of the other contributors’ benchmarks where the relative improvements were not as high, it can be assumed that the 6.2 performance benchmarks on their environments would have shown an equivalently lower performance boost as well.

While this means we cannot get a definite answer to how much faster WordPress 6.3 is, it is safe to say that it is a lot faster than 6.2, and relatively speaking the performance improvement is even higher than it was between 6.2 and 6.1.

Automated benchmarking workflow

Some of the benchmarks referenced were conducted using a new reusable automated benchmarking workflow that @swissspidy recently implemented, using the same approach as the manual benchmarks, but using GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions. Those results show that using this workflow leads to more consistent results overall due to using the same environment, and it furthermore reduces the effort needed to conduct performance benchmarks. In the future it may be a good idea to rely on the numbers from that workflow rather than those from an arbitrary environment of a specific contributor. For reference, the automated workflow numbers roughly indicate the following performance improvements in WordPress 6.3 compared to 6.2:

  • LCP is 10.6% faster for block themes and 8.8% faster for classic themes.
  • TTFB is 4.7% faster for block themes and 5.6% faster for classic themes.
  • LCP-TTFB is 13.4% faster for block themes and 9.3% faster for classic themes.

Get involved

If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both.

Props to @adamsilverstein, @annezazu, @joemcgill, @oandregal, @spacedmonkey, @westonruter for review and proofreading.

#6-3, #block-themes, #core-editor-improvement, #core-performance, #performance

WordPress 6.2 Performance improvements for all themes

With the latest WordPress release out in the world, this post seeks to recap the performance improvements available for all sites. According to this analysis done by @flixos90 that you’re encouraged to dig into, WordPress 6.2 loads 14-18% faster for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes and 2-5% faster for classic themes. Server-side performance is seeing a major boost of 17-23% for block themes and 3-5% for classic themes. These changes demonstrate WordPress’s continued commitment to ensuring that websites built on the platform are optimized for performance.

This builds on efforts done in the past that you can read about in the following posts: Need for Page/Post Speed and Performance Matters.

Thank you to @oandregal and @flixos90 for collaborating on this post!

What’s changed

theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. APIs

Leading up to WordPress 6.2, theme.json related code received more performance related attention partially thanks to an understanding that this newer configuration file has an important role to play in the future of themes. This work aimed to improve Time To First Byte (TTFB), a metric related to server-side performance. It focused on three aspects:

According to this analysis, caching wp_get_global_settings had the most impact in the release, improving classic themes by 9% and block themes by 24%. For context, while wp_get_global_settings was introduced in WordPress 5.9, it’s usage expanded to cover many more use cases, including querying data for rendering front-end blocks. As a result, it benefitted immensely from caching the response.

Lazy-loading images for block themes

While Time To First Byte (TTFB) was a big focus of the 6.2 release, there was also a major change to Largest Contentful Paint, the main user-perceived performance metric: the first image or iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. of the post will no longer be lazy loaded for block themes.

As a reminder, lazy-loading images landed in WordPress 5.5. After an analysis reported that lazy loading images above the fold negatively impacted user-perceived performance, a fix landed in WordPress 5.9 with WordPress 6.2 following up to ensure block themes won’t lazy load the first image or iframe.

Front-end metrics

Outside of the work done to directly improve performance, there was also a focus on making front-end metrics readily available to all. The aim being to ensure developers have the necessary information to make new features performant and catch regressions earlier, all aiding in creating performant future major releases. All Pull Requests in the Gutenberg and wordpress-develop repositories now include front-end performance information. This information is also reported in the following places for a more comprehensive look:

  • The Gutenberg dashboard now collects a number of front-end metrics:
    • Largest Contentful Paint (LCP): tracks the overall user-perceived performance.
    • Time To First Byte (TTFB): tracks server-side performance.
    • LCP-TTFB: tracks client-side performance.
  • There is a new WordPress core dashboard that reports the following server-side metrics:
    • Total: tracks server-side performance. Equivalent to TTFB in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ dashboard.
    • Before template: tracks the time it takes to dispatch the template_redirect hook.
    • Template: the difference between total time and the time it took to dispatch the tempate_redirect hook.

Get involved

If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both. 

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

#block-themes, #core-editor-improvement, #performance, #themes

Navigation Block Fallback Behavior in WP 6.1

In WordPress 6.1 the navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. will have a new fallback behavior.

What is the fallback behavior?

When a theme uses a navigation block in a template part, it’s to control where the navigation should visually be located, for the theme’s UIUI User interface to be consistent, usable, and visually attractive. However, themes developers don’t know beforehand what menus the site has, how many pages, what they’re called and so on.

The fallback behavior is the small heuristics in the navigation block which tries to determine what the block should display by default, when a user activates a theme.

What is the new fall back behavior?

Starting with WordPress 6.1, theme developers and authors can lean on the following fallback behavior of the block:

If the navigation block has inner blocks, it will honor them and display them. If the navigation block is empty, however, then it will initialize the fallback behavior.

The fallback behavior (in both the editor and the front of the site) is:

  • If there are no block menus or classic menus, the block will display a list of available pages using the Page List block.
  • If there are multiple block menus, the navigation block will display the most recently created block menu.

The key changes can be summarized as follows:

  1. Improved consistency.
  2. Page List as default fallback.
  3. Selecting the most recent block menu.

Consistency: previously the fallback behavior was inconsistent between the fronted of the site and the editor. If a theme used an empty navigation block it would display a list of pages on the front, and an empty block in the editor. Now the behavior is consistent between both; the editor mirrors what visitors see on the frontend.

Defaulting to page list: previously, themes which wanted to default to a page list in the editor usually included a page list inner block within the Navigation block. With this update, this is no longer necessary. The navigation block, if empty, will automatically have consistent front and editor behavior, defaulting to a page list.

Selecting the most recent block menu: This part of the fallback behavior is new. In the event a site has multiple block menus, an empty navigation block will display the most recent one.

Theme developers should keep in mind.

Display only

The fallback behavior only affects what the empty navigation block will display. Unless the user edits the navigation block’s default fallback, adding a link, changing a label, converting a page list block to a list of links or selecting another menu, the markup of the template part is not changed.

Default content is still honored.

There is no change to how navigation blocks with inner blocks from theme markup behave. Themes  still include inner blocks in the markup in the event they want to showcase a specific situation, for instance a small three links menu, pointing to #, with some restriction on length of link labels – this will continue to work, just like before, rendering the uncontrolled inner blocks both on the front and in the editor.

Props: @get_dave for editing and technical review, @bph for review

#6-1, #block-themes, #dev-notes, #dev-notes-6-1, #navigation-block

Core Styles and Theme Customization: the next steps

Since WordPress 5.9 ushered in the era of blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes, there have been questions and concerns about the relationship between theme and CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles in the context of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. Much of the feedback centers around the notion of how themes can, or should be able to, override CSSCSS Cascading Style Sheets. generated by Core.

This post provides an update about what is happening and, rather imprecisely, when things will happen.

A summary of the challenge

Gutenberg comes with a mix of bundled CSS: global, preset CSS vars, individual block styles or style attributes and block supports.  

As a result of these different layers, theme authors are running into battles of specificity where they wish to override Core styles. Given the frequency of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releases, CSS rules are seen as moving targets.

Part of the challenge is to combine the need for greater transparency and predictability with the customization and control of theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.. Thrown into the mix is how the Block Editor approaches and honors styles added by users.

Folks working closely with Gutenberg are thinking about how to address these concerns both in the short and long term. Everyone’s feedback and contributions have been immensely helpful so far. 

As you can imagine, the ambitions are lofty, the parts are many and moving. There remains a lot of work and discussion to undertake, and the answers aren’t all there.

Theme.json and theme CSS

Block themes have introduced a new paradigm into theme development, with Core attempting to absorb many of the common CSS customization burdens that classic themes have had to carry.

This arrangement is apparent at the basic level of pattern and site composition: blocks.

One of the functions of blocks is to express site elements in a consistent manner, and promote consistent customization experience regardless of the theme. This means that site owners can switch between themes and be confident that their theme.json and global style preferences will migrate with little or no friction. 

Overriding CSS, whether layout, preset, or block styles, presents an obstacle to integration and interoperability: visual parity between the frontend and editor becomes more difficult to maintain, upgrades to block internals may conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with overrides. Custom CSS is, furthermore, less portable across other block themes.

By encouraging theme authors to use theme.json APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. where possible, the hierarchy of “base > theme > user” defined styles can be resolved correctly.

The general response to calls for greater control over themes is to extend the theme.json API. If there is a feature in demand, and it’s not currently available in the API, contributors band together to build it in. For example, to control the ways in which editors can interact with their designs, theme authors can define which style UIUI User interface components are accessible in the editor right down to the block level through the block support API.

When working on styles in Gutenberg, these guiding principles have remained predominant.

The reality however, is that theme authors will do what they can to achieve specific objectives, that is, “to get stuff done” and realize their (or others’) designs. There have been reports of overly-specific generated layout styles, and CSS rules using !important frustrating theme CSS overrides.

Alternative ways of thinking about how styles are expressed have been proposed, and the ensuing discussion has been supremely valuable.

While more communication and documentation around the what, why and how of styles is part of the puzzle, making the theory and intentions behind blocks and block themes compatible with the practical reality is an ongoing preoccupation of many who are working on Gutenberg.

Current initiatives

Folks on the Core team, including me, are monitoring discussions, and are actively working on shorter-term code changes, and longer-term mitigation strategies to make working with CSS more predictable.

At the same time, the goal is to preserve the primacy of theme.json, and look for opportunities to extend its API and reduce the need for manual overriding of block or layout CSS. When considering proposals such as extending theme.json to define settings and styles for block “sections”, the goal becomes even more pertinent.

Shorter term changes relate to bugs or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. features. These potentially include removing !important from preset style rules, and addressing block-specific style issues such as Global Styles: Setting font size for Paragraph impacts Quote Block.

Longer term, there are new discussions around outputting semantic classnames for generated styles and the notion of, for better or worse, holding block or layout classnames to the standards of a public API. The motivation here is for greater consistency in what Core exposes. @isabel_brison expresses eloquently that, regardless of whether something can or should be done via theme.json “sometimes there isn’t a better way to accomplish the goal, and the best we can do in that case is provide a good safety net of consistent and meaningful classnames”.

A vehicle that could unify the management and generation of style and classnames is the nascent Style Engine. The stated goal is to have a “consistent API for rendering styling for blocks, across both client-side and server-side applications”. The barest of bones are in the Gutenberg plugin right now, and there are more iterations on the way. 

Finally, and intertwined with all these efforts, are the plans around increasing layout options. Implicit in this project is a refactor of how we generate and apply layout styles across blocks. Many of the concerns in relation to style and classname generation – predictable and consistent classname hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and customization via theme.json – are guiding this work.

Iterations of the longer term projects will be priorities in upcoming versions of WordPress.

Improving documentation

Official documentation on block editor styles is out there. 

There is, nevertheless, huge scope to improve documentation around the role of in-built block CSS and theme.json styles, for example, answering specific questions on best ways to control layouts or individual blocks and providing how-to guides.

It’s a critical one to get right as we all move forward on this issue, and one that I hope will form part of the projects mentioned above.

How to get involved

While there’s no single solution, or maybe even a right solution, now is a great time to get involved while everyone is still experimenting and planning, and there exists the chance for us to strike a balance between the common styles produced by Core and highly specific requirements of theme authors. 

Compromise will arise from wide input and consultation, so I encourage folks to share their thoughts on the features they’d like to see in theme.json and block themes in general. You can join the discussions surrounding semantic classnames, layout options or the Style Engine, or create a new GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue or discussion if you have an idea about a new approach.

If you have knowledge to share that would help other contributors, there’s always scope to expand and improve the documentation

Thanks for reading this post, and for everyone’s input so far. I look forward to diving into the problem-solving pool with you all.


Thanks to @annezazu, @isabel_brison, @andrewserong, @glendaviesnz and @apeatling for their help with this post.

#block-themes, #core-css, #gutenberg

Core Editor Improvement: Choose your Style

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

With Gutenberg 12.5 and the soon to be released GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 12.8, a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme author can now bundle multiple sets of Styles with their theme, allowing anyone using the theme to quickly switch between them as shortcuts for customization. These different Style presets can change both settings available, like turning on/off font weight, and style options, like the default color palette. For a practical example of what this looks like, check out the quick demo below showing off how a theme could offer both light and dark Style presets:

You can experience this for yourself locally by using the Twenty Twenty Two theme, creating a new styles folder in the root of the twentytwentytwo theme folder, and dropping this gist in there. 

This Styles feature gets even more exciting when it’s paired with new enhancements like the fonts API in theme.json coming to Gutenberg 12.8. That opens the door for a wide range of styles per theme — look for more and more themes to leverage this in the coming months. The following video shows off some new creative possibilities that are opened up by these new features in combination: 

If you’re a block theme author looking to take advantage of this new feature, dig into the documentation now to learn how to create different style presets and align with the necessary theme structure

Thank you to @kjellr for the demos and help writing this post. 

#block-themes, #core-editor, #full-site-editing

State of the Customizer with block themes in WordPress 5.9

With WordPress 5.9 bringing support for block themes, this results in a few changes to how the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. works and how one can preview themes.

At a high level, this post covers how blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes cannot be previewed due to the introduction of the Site Editor and how the Customizer itself will only appear if a non-block theme is activated or a site has a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that interacts with the Customizer.

Previewing block themes

If you activate a non-block theme like Twenty Twenty-One, open the Customizer, and click on the Change button in the Active theme section, you will see a warning message displayed for each block theme. Please see the example below:

A warning message is displayed for each block theme in the Customizer

It is displayed because the Customizer doesn’t support block themes. They can be customized in the Site Editor instead.

As a result, to customize a block-based theme, you need to activate it first. If you’re concerned about doing so, it’s recommended that you set up a test site first to explore the theme.

Also, it is not possible to preview inactive block themes because the Site Editor only works with the currently activated block theme. This means that the Live Preview button is not displayed for inactive block themes.

Once the ability to preview any block theme in the Site Editor is implemented, it will be possible to enable the Live Preview button for block themes as well.

Previewing non-block themes

Previewing non-block themes works the same way as in WordPress 5.8. Nothing has changed here.

Customizer and block themes

WordPress removes the Customizer from the Appearance menu if a block theme is enabled. Why? Block themes are customizable within the Site Editor rather than the Customizer.

However, if any callback function is registered for the customize_register action, the Customize menu item will be added. This is necessary to ensure compatibility with plugins that still require the Customizer to be present in the Appearance menu.

Because the Customizer shows up conditionally, various links have been adjusted depending on the type of active theme to ensure a smooth user experience.

For example, if a block theme is activated, the link in the Welcome banner leads to the Site editor. However, if a non-block theme is active, it leads to the Customizer.

Summary

If you need to preview or edit a block theme, activate it first. Previewing non-block themes will continue to work the same way.

WordPress will only add the Customize menu item if a non-block theme is activated or a plugin interacts with the Customizer (please see the customize_register action).

TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets: #54549 (warning messages for block themes in the Customizer), #54460 (change links depending on the type of active theme), #54337 (conditionally show the Customizer in the Appearance menu).


Props to @annezazu and @hellofromtonya for technical review and proofreading; props to @audrasjb for proofreading; props to @desrosj for providing general feedback on this post.

#5-9, #block-themes, #customize, #customizer, #full-site-editing