Gutenberg Changelog #74 – Gutenberg 14.2, 14.3, WordPress 6.1, Style Variations in Theme Directory, Course on Gutenberg Data Layer

Gutenberg Changelog episode 74 with Dave Smith and Birgit Pauli-Haack
Gutenberg Changelog
Gutenberg Changelog
Gutenberg Changelog #74 – Gutenberg 14.2, 14.3, WordPress 6.1, Style Variations in Theme Directory, Course on Gutenberg Data Layer
/

Birgit Pauli-Haack and Dave Smith discuss Gutenberg 14.2, 14.3, WordPress 6.1, Style Variations in Theme Directory and a Developer Course on Gutenberg Data Layer

Show Notes / Transcript

Show Notes

Special Guest: Dave Smith

WordPress 6.1

Community Contributions

Gutenberg Plugin 14.2

Gutenberg Plugin 14.3

Release lead: Aaron Robertshaw

What’s in the Works?

Stay in Touch

Transcript

Birgit Pauli-Haack: Hello, and welcome to our 74th episode of the Gutenberg Change Log podcast. In today’s episode, we will talk about Gutenberg 14.2 and 14.3 plugin releases, WordPress 6.1 release candidate, style variations in the theme directory as a beta, a developer course on Gutenberg data layer, and so much more. I’m Birgit Pauli-Haack, curator at the Gutenberg Times and WordPress developer advocate. And my guest today is Dave Smith, a JavaScript engineer and full-time core contributor on the Gutenberg project, sponsored by Automattic. Good afternoon, Dave. Thanks for joining me today. How are you?

Dave Smith: Hi, Birgit. Yeah, I’m doing really well, thank you. And it’s great to be able to join you on the show again.

Birgit Pauli-Haack: Well, although you have been a guest on the Change Log before we always get new listeners. And so maybe you could tell us briefly about yourself and what you are working on at the moment.

Dave Smith: Yeah, sure. I’m a developer living from and working in England in the United Kingdom. And as you mentioned before, I’m sponsored by Automattic and I work full-time on the Gutenberg Project. So my primary focus tends to be the navigation project, which I’ve been on for the 6.1 cycle, and that’s now encompassing all aspects of managing navigation in the editor, including the nav block. I also run a YouTube channel, which is Dave on WP, where I post regular videos on all aspects of the block editor. And most recently I’ve been working on an overview video for all the key features coming to WordPress 6.1, so if anyone would like to check that out, then they can have a look at the channel, which is youtube.com/c/daveonwp, and I’m sure we’ll have that link in the show notes.

Birgit Pauli-Haack: Yeah, of course we do put a link in the show notes. Yeah, and I found great videos about the work on the navigation block there. They were very helpful getting into the problem space and why it’s all so difficult to solve. So thanks for putting them together. 

Dave Smith: No problem, yeah. 

Birgit Pauli-Haack: Yeah. Oh, there was also another video, I watched your presentation that you gave to an agency team that is starting out adopting the block editor for their work, and they had some interesting questions for you. So what was your takeaway from the discussions with the group?

Dave Smith: Yeah, so that was the discussion I had with Corner Shop Creative, I believe. Yeah, they were brilliant, they were such a great team. They had loads of questions, I think the Q&A ended up being longer than the actual presentation itself, actually.

Birgit Pauli-Haack: That’s a good thing.

Dave Smith: Yes, it was a good thing. I always think it’s a good sign. But that team had, they really fully embraced the block editor, but they’re butting up against some of the same problems we hear a lot about, styling and curation of content. An example that came up was this possibility of having a synced block pattern, which could be updated with styling changes after the fact. As you know, once you insert a pattern, it’s a one time action. Once it’s done, it’s done. You can’t go back and then update it. So every time the client wants to update their styles, they have to go through all of the instances of the pattern and update them so you that you can see how that’d be a bit of a headache. 

So I don’t see any really good way to deal with that yet apart from inheriting all the styles from global styles instead of applying bespoke ones to the pattern itself. But it’s certainly a tricky problem anyway, it illustrates that we still have some ways to go to solve all these real world use cases that folks are running up against.

Birgit Pauli-Haack: Yeah, updating prior work was actually a pain point that I also heard at WordCamp Europe as well as WordCamp US, where it’s not only the pattern but it’s also when you have a theme that was modified, the template was modified, when the theme is updated through a theme shop, the user doesn’t get the new templates because they override it through their user stuff. That also a good problem to solve because if they update the template and. although it was changed by the user, they’re not getting the new features in there, whatever that’s in there. So it’s kind of a tricky bit there. Yeah. 

Announcements

So yeah, you mentioned it, let’s discuss WordPress 6.1 release cycle for a bit before we head into the Gutenberg plugin releases. Do you want to start out with that?

Dave Smith: Yeah, absolutely. So I think we’ve had the RC1 on the 11th of October, 2022. We’re recording on the 14th, I think, today. So yeah, it’s time to perform those final reviews and get testing on that. As usual, we don’t recommend running this on a production or mission critical website, I think we all know that by now, but just in case. And we’ve got the final release of this 6.1 is going to be out on the 1st of November, 2022, all being well.

Birgit Pauli-Haack: Yeah, there’s some people who say, “Well, I’m not going to update until 6.1.1 is out,” but yeah, I hear there.

Dave Smith: Yeah, well, I mean there’s absolutely loads of changes in this release. I think there’s some stat of 1,700 PRs merged or something like that, so there’s absolutely a load of features coming down the line. But also bug fixes and tooling and testing changes, I think it’s going to be a really strong release. Do you agree?

Birgit Pauli-Haack: Yeah, yeah, I agree. Yeah, there are countless changes for the content creators, and we talked about those in the last six or seven episodes when we discuss the Gutenberg plugin releases. But so almost all features from the plugin releases 13.1 through 14.1 will make it or made it into the WordPress 6.1. It’s already, as you said, in release candidate. So feature freeze was beta one, release candidate one is actually string free. So the army of polyglot contributors that translate all the new things coming to WordPress between now and the final release can be sure that they don’t have to do it again when there are additional string changes there. So that’s string free. So it’s pretty clear. 

So there are two or three things that didn’t make it in there as I discovered, there was a zoom out window, the table of contents block is not in 6.1, and also the theme support for the appearance tool for classic themes that didn’t make it into 6.1. They need some more testing or some more refinement before it goes out to millions of users. And I just realized that 6.0, WordPress 6.0, was already downloaded a hundred million times. 

Dave Smith: Wow. 

Birgit Pauli-Haack: So the counter resets in about a month… No, about two weeks, for 6.1, but then we know the final number. So the field guide for WordPress 6.1 has been published and I counted 19 developer notes about the block editor and block based themes, that’s double the amount of developer notes for 6.0. There’s also a separate field guide for performance update from the performance team. Awesome work there. And also a separate post that lists all the accessibility changes coming to WordPress 6.1 by Anne McCarthy, and I think she lists about 50 different changes that were coming. So Dave, what are the features that you are most excited about this release?

Dave Smith: Oh, there’s so much. I’ve just been going through all these changes for WordPress 6.1 actually, and there’s just so many great things. But I think probably the biggest thing that I think people will notice when they download 6.1 for the first time is just how many more design tools are available across the blocks in 6.1. There’s been a big push throughout the 6.1 cycle to roll out all the standardized tools for blocks for things like color, typography, layout, spacing, and that kind of thing. And I think now that’s really coming to fruition. I think we’re only 50% of the way through all the blocks apparently, I read the last ticket, but it’s surprising what a difference that makes compared to 6.0.

Birgit Pauli-Haack: Absolutely. Absolutely. Yeah. And I actually put, I’m so excited about it, I put a table together with all the core blocks and so you can see all the core blocks and then typography, color controls, dimension controls, border controls, and layer controls, and then you see which block has what. So that’s in the dev nodes as well.

Dave Smith: Oh, that sounds brilliant. Yeah, I’ll have to look that up. Yeah, well the other thing I wanted to have to talk about was the… Something that I think will help increase adoption rates for block editing, and that’s the ability to utilize and edit template parts in classic themes. And first time I heard it I thought, “Oh, what’s the point of that? It sounds a bit strange.” But actually I found that it affords a lot of power, because what it enables you to do is things like make your header or your footer fully editable whilst not requiring our users to have to fully deal with and embrace the full site editor experience. So I was testing this out and I had to go at converting the 2020 theme to allow me to be able to edit the footer. And it was so easy to do, but yet it opened up such an amazing thing because normally if you want to edit just something as simple as the text and the footer, you’d have to create an option and create a new setting in your theme and do all that sort of thing. And now you can just go in and at the footer text, click save, and it’s done. And so actually I think it’s a bigger win than you might expect when you hear that for the first time.

Birgit Pauli-Haack: Yeah, absolutely. Absolutely. And Justin Tadlock actually did a little tutorial when he did the same thing that you did. I think he converted the 20… No, he converted the 2021 with some block parts and had a hero image of the header and all that. So that is actually published several weeks ago at the Gutenberg Times website. So I will add that link also to the show notes. But it goes really through the whole problems that he encountered also with CSS, because sometimes you need to update the things and that’s expected, but also how little there was to update. And he also added a few patterns to it and how you can do that. So that’s a great tutorial if you want to check that out. Yeah.

Dave Smith: Absolutely. Justin’s articles are always really good, isn’t it? So I’ll definitely be looking at that. 

Birgit Pauli-Haack: Yeah.

Dave Smith: There’s one more thing actually you want to call out, if I may.

Birgit Pauli-Haack: Yeah, sure. 

Dave Smith: And this one, I think, has flown slightly under the radar on this release, but it’s actually the syncing of editor preferences across devices. So I mean you’ll be familiar that you can do things like set the persistent list view or you want top toolbar mode within the editor. But in 6.0 these rules just saved locally to the device you were on. So if you went and then switched to a new device, all those changes would be lost, you’d have to reapply those references, which is kind of annoying. So with 6.1, however, they’ve now updated it so the changes are saved to the database. So that means that they’re going to apply across all your devices. So if you’re at work and you set top toolbar mode at work, you come home, log onto your home laptop, and it’s going to be exactly the same there. So it’s a nice quality of life improvement then. And big shout out to Daniel Richards who really spearheaded all the work in that area.

Birgit Pauli-Haack: Yeah, I think there will be a sigh of relief for millions of block editor users that have said, “Yeah, I know the welcome guide. Yeah, go away. Let me go on with my work.” 

Dave Smith: Absolutely. 

Birgit Pauli-Haack: Yeah, it’s really a great. But I also feel that it’s the right time to actually implement that because now the full range of preference tools is actually known. And then also figure out, okay, how all these editor, being the site editor, being the post editor. Yeah, how they handle those preference tools before you’re actually put it persistently in a database. I think that’s a good… The local storage was a good solution for interim, but now that it’s in a database now plugins and others can actually also know about that and help them modify that. So for developers in 6.1, there are great improvements on the controls for theme JSON, of course the typography and border controls and color for links coming also there. 

But the most important thing that I feel is the query loop block extensions that the developer can now create a block variation for the query loop block and define, with the attributes, the customization of the list of posts, custom post types, or pages. And so theme developers working on more complex sites will hopefully make good use of that. I think the ease of style variations for theme developers is also… You can use them for classic themes. No, we talked about that. Yeah, style variations for the block themes are definitely good, coming to 6.1. They were actually for 6.0 already there, the default theme has it. But the default theme now is actually a base theme and now has 10 variations built from the community that come with a default theme. So I’m really excited about that. Yeah.

Dave Smith: Yeah, that’s a pretty amazing thing, that 2023 theme, I think something like 38 contributions and ended up being with 10 different variations. Amazing. A new way of generating default themes for WordPress. I think it really points to the future.

Birgit Pauli-Haack: And I’m not sure if you should just keep that default theme, kind of change the name to default theme and just add variations in every area.

Dave Smith: There’s variations now. Yeah.

Birgit Pauli-Haack: And do a shout out to the community and say, “Okay, now it’s time to show us the best variations,” and then we add it to them theme or something like that. I also saw theme developers that submitted quite a few style variations, build a child theme, and submitted that to the repository with their style variations in it. So you get, even if the design team just selected 10 of them, you get to see even more style variations for it. So it’s definitely quite some creativity going on in the community about that. Which brings us to our community contributions section of the site. Dave, you brought some with us.

Community Contributions

Dave Smith: Yeah, I found quite a few community contributions this week, actually. So the first one I want to chat is about is client side web assembly, WordPress with no server. It’s sort of a click bait-y title if I ever heard one. But this was a post on make blog by Adam Zielinski. And what it is is it is what it says on the tin, WordPress running completely in the browser with no web server whatsoever. And probably most of your listeners will be familiar with WordPress, traditionally you have a web server and your browser sends… When you click on something like posts, it’s going to send a request to that server and the server’s going to respond with the answer. But of course if something happens like you go offline, then you can’t reach the server anymore, and therefore your site doesn’t work. And that’s always how WordPress has worked.

What Adam’s done is been very, very clever and he’s used the technology called web assembly, which is a low level assembly like language similar to C or C++ or whatever. And basically what he’s done is he’s taken the PHP that comprises the WordPress software, compiled it down to web assembly, packaged it up in a bundle, and then run it completely in the browser. Then any requests that go out that would normally go out to WordPress get trapped by a service worker and it get reroutes them to this in browser version of WordPress. Sounds all very, very clever and you think, “Oh well, great experiment,” but it’s actually got some real world opportunities there, I think. Especially around learning WordPress in the browser. I don’t know if you saw that post, Birgit.

Birgit Pauli-Haack: Oh yeah, I actually reviewed it and had some questions for Adam before he published it. And I also tested some of the things. So it’s really amazing and I can imagine the opportunities are probably endless, but definitely when you have tutorial type posts, you can add that to it and people can then, in real time, make some changes to the code that they’re just learning or just reading about and then see how it impacts a website without having to spin up their own local, without any build tools, without any downloading of Gutenberg or something like that to see that all happening. And so it’s a much faster way to learn and see how things working, instead of… And then figure out how you add it to your own code. Yeah, yeah, so really I hope… And I saw Adam in between announcing, I ran into some browser freezes and browser… Because the bundle, of course, is also pretty big. If you have downloaded WordPress before, it’s about four or five megabits. And if you load that in a browser and in your memory of your local system, yeah, you need some heavy lifting there. And if you do some more, it kind of poops out on you, so to speak. Yeah.

Dave Smith: Yeah, exactly. Yeah, I mean that’s definitely why I think this is a first sort of prototype. I know Adam and colleagues are looking for people to start contributing and trying to make this more practical in real word usage. So if anyone is interested in that, then the link to that post will be in the show notes for this episode. I’m also going to be diving into the topic a little bit greater detail with Adam on my YouTube channel, so if you’re interested in that.

Birgit Pauli-Haack: Oh, right, yeah. Excellent, yeah.

Dave Smith: I’m sure you can see that video at some point.

Birgit Pauli-Haack: Yeah, looking forward to that, yeah. So another community contribution is actually that the Meta team just released a beta version of displaying style variation in the theme directory. There’s a track ticket that was opened by Carolina Nemark, a full site editing expert if you need one. And so you can browse examples with a 2022 theme. I put the link in there. So the developer Steve Dufresne commented on the ticket, so to turn on the feature add ?beta-style_variations to the URL. And then the URL gets updated when you browse themes. So you’ll need to re-add that string, however, for each theme page to reload. 

So what I really like is that it’s now an increase of interactivity on the theme directory to help site owners to decide which theme they want to take. And every time you click on the little style variation card underneath the screenshot, the screenshot actually changes into displaying that style variation on the screenshot. So it’s quite fascinating and I’ve spent quite some time browsing themes that already have style variations in there. So if you don’t see a style variation, probably the theme doesn’t have some, but you find the best way… I saw maybe six or seven themes in there, but of course I didn’t browse all 160 block themes anymore. But yeah, try it out. I put the link to the track ticket into the show notes, so you can also see the string that you need to add there and a link to the 2022 theme so you can see all the style variations without downloading it. Yeah, let me know what you think about it. Yeah, I’m totally stoked about that.

Dave Smith: Yeah, sounds really good. Well, the more themes that are adding these style variations, the more we’re going to need to have stuff like that in the theme directory. Yeah, great to see that happening. One more thing, community contributions this week is a new course on Learn.WordPress, which is the official sort of tutorial site for WordPress. And this is a new course on WordPress data layer and specifically the Gutenberg data layer. So for those who don’t know, the data layer is used throughout the block editor to read and write data. So for example, if you need a list of posts or you want to create new post, edit a post, you’re going to need to use the data layer at some point. And really that means it’s essential learning if you want to make anything more than the most basic of blocks. 

So this is a full course which covers not only the basics of the data layer but also best practices and some more advanced usages. I know the author, again, it’s Adam Zielinski, who’s been prolific recently. And he’s extremely knowledgeable in this topic so I’m confident there’ll be a great investment for anyone who’s got the time to look at that course. And the link, again, is going to be in the show notes.

Birgit Pauli-Haack: Yeah, it’s great for any developer who has ambition in that. Yeah, definitely requires an advanced JavaScript and req knowledge to get through that course. 

Dave Smith: Yes.

Birgit Pauli-Haack: Well, but not everybody is there yet. So very soon, hopefully in the upcoming weeks, there’s an introduction to block development course coming up. And it gets you from almost zero to block building a real life example, like a multi-column block when you have a text and then it kind of distributes itself over the multiple columns. So yeah, this is the Adam Zielinski fan show because Adam Zielinski also send in, I think, three dev notes on Monday that we were able to put in the field guide. So there’s definitely some great work for developers in the works or in the 6.1. 

Dave Smith: Absolutely.

What’s Released

Birgit Pauli-Haack: All right, so that brings us to the Gutenberg plugin releases 14.2 and 14.3. Let’s start with 14.2, release lead was Michal Czaplinski, who also published a release post on Make Blog, and of course another show note link. It entailed about 80 PRs, 15 enhancements, 24 bug fixes amongst them. And some of them even made it into the release candidate 6.1 that were back ported to the core. It’s a fairly small release now compared to the last two releases. I remember 14.1 had over 383 PRs. 

Dave Smith: Yeah, it’s not quite that big. 

Birgit Pauli-Haack: That was quite epic. But of course there was a rush to get all the features in to make the feature freeze of beta one. And then nevertheless, there are great enhancements, made it into the plugin. And Dave, what are the key features that were merged in the plugin?

Dave Smith: Yeah, so for 14.2 we had smarter pattern suggestions for the query loop block variations, we’ve got improvements to the writing flow, a more polished calendar block, new banners and footers, block pattern categories, and auto completion for links is now in all blocks.

Birgit Pauli-Haack: Well, that sounds terrific. So let’s discuss them one at a time. So there is also letter spacing for the global styles, so you can now, for the heading, and you can now put them in the theme JSON file to have not only letter spacing but also font family selection and the other typography, which is letter like height, case for the headings like sentence case or title case or no case at all. So that’s all for the headings. And I think the letter spacing didn’t make it into 6.1, the others you find in the headings. Yeah.

Dave Smith: We’ve also got another PR, which is switching us to using numbers instead of T-shirt sizing for labels for spacing presets. So if you’re changing something like padding or margin, there’s a little slider and you can slide between small, medium, large, extra large. That was deemed to be too complex, potentially, and had some accessibility concerns, so they’ve reversed just numbers, so zero, one, two, three, four, five. 

Birgit Pauli-Haack: Oh, okay. Yeah.

Dave Smith: It’s simple.

Birgit Pauli-Haack: It’s simpler, yeah.

Dave Smith: Yeah.

Birgit Pauli-Haack: Yeah. And there is another quality of life change that made it into, and that is hiding the floating block UI when typing. It was always going away but it now also hides the insert, so there is no distraction coming up when you type on a paragraph block or in any other blocks for that matter. I think that’s really important because that’s one of the big concerns for writers, that there is so much distraction, especially when they start out, every time they move the mouse something appears and then there’s gone until they see what it was. And it’s kind of disconcerting sometimes for writers when they start out with the block editor. So I like that. 

Dave Smith: Yes.

Birgit Pauli-Haack: The color block also got now color support in 14.2, and polish styles, which is nice because I think the color block… Calendar block, color block. Sorry, let’s do that again. 

Dave Smith: Can you say it again? 

Birgit Pauli-Haack: Calendar block got now color support and polish style. And I’m really happy that the calendar block got some more love now because I think that’s the first change since the beginning of the… Just the last five years since the calendar block actually made it into the block editor. So that’s just really cool.

Dave Smith: Yeah, that’s nice to see. Under patterns we’ve also got new categories, as I mentioned, for banners and footers. The reason we’ve got those is because we’ve already got the headers category for patterns, but that was really intended for more global elements that might be at the top of your site. But unfortunately people were putting in things like what you might call a hero section, sort of a standout call out within the flow of the page, and that wasn’t really the right place to put it. So to disambiguate those, they’ve created a new pattern category called banners and you can put all your hero sections in there as you wish. There’s also another one called footers, I think that does what it says on the tin, it’s just complimentary to headers really.

Birgit Pauli-Haack: Right. Yes. Yeah. And those are the perfect candidate for actually classic themes to use in their themes, is the headers and footers. But the pattern category is something, it’s a little bit different. But there are also template parts that go with that. And isn’t there a semantic recognizing that if there is somebody edits the footer or the header, they get the respective category of patterns for choices in the editor? So I think that was also a reason, definitely for the footer pattern category. So the footer template part can have their own patterns.

Dave Smith: Yes, and to suggest the most appropriate pattern for you. Yeah, that sounds like a good reason for that change.

Birgit Pauli-Haack: Yeah. Another change was a link auto completer that is enabled for the blocks. Is that the… Oh, right, right. We talked about that. That’s the bracket bracket auto completer where it shows you, you just put in bracket bracket in the paragraph and in the list block and now in all blocks and you get a choice of the latest published posts or pages that you have on your site. That’s a very fast way to do inner links on your site, which actually help you with SEO as well, but also keep your reader on the site. So this is a great tool to do that.

Dave Smith: Yeah, it’s good to see that in all blocks now, not just the paragraph block. Especially with the new list and blocks having inner blocks, so that’s quite important there.

Birgit Pauli-Haack: And it was missing from the list block actually. 

Dave Smith: Yes.

Birgit Pauli-Haack: And I used that quite a bit on the Gutenberg Times the list block where I have just a list of links and all of a sudden it didn’t work anymore. So guess what I did?

Dave Smith: Oh, I can guess. So next up, we’re onto the block live section and there’s been quite a number of enhancements to blocks. The main one is the query loop block now suggests patterns based on the active variation. So for this one, imagine if you have a query loop block, you might register a variation for it for something like listing out a list of products from your products custom post type. But that variation itself can also register patterns. So you might have a pattern, which is the list layout, and then another pattern which is list products in the grid. So you’ve got those two patterns. 

So what happens now is when you insert your products list variation, it will suggest to you those two patterns that the variation is registered. So it’s surfacing the most appropriate pattern for your query loop variation. And that’s quite powerful for things like e-commerce sites and things like that. So you’re not getting loads and loads of patterns you have to pick from that are completely irrelevant to the type of query loop you are inserting.

Birgit Pauli-Haack: Yeah, it’s one of the features that quite a few agencies really love because they can narrow down the customization that a user can do and be very strict in certain things, but give a little bit of freedom. That also pairs with the content locking features that come with 6.1. I know I’m jumping back and forth, but it all comes together in one thing, in that it will be the, it’s the site editor thing. Yeah. So yeah, there also it was a great writing flow, a fix for it. Now when you partial select between blocks there and now you can drag it again, which wasn’t possible before.

Dave Smith: Yeah, you had, when you were dragging from one across a number of blocks, it would have this strange effect where it would go back to showing you the first block you’d dragged. So if you had a sidebar open as you would drag in between the blocks, it would flash between the first block and then the multi-select, the first block, the multi-select. And now what happens is just when you start, you click on the first block you drag and the toolbar and everything around it stays based on the first block that you selected. It’s a small change you probably wouldn’t notice, but if you were doing a lot of multi-selection, especially with drag and click and drag, you would definitely notice it flickering back and forth. It was really, really distracting. So that’s just another nice quality of life improvement there.

Birgit Pauli-Haack: Yeah, thank you for pointing that out. Cool.

Dave Smith: Another one was when you’re creating templates in the editor, under the template screen. Previously you could, accidentally, if you were a bit overzealous with your clicking, you might create a number of templates because you could just repeatedly click the create button for any of the templates. So yeah, people were ending up with five versions of the one template and just thinking, “Well, how did that happen? I only clicked once.” So yeah, we’ve fixed that so it’s not possible to do that anymore.

Birgit Pauli-Haack: Yeah, that’s definitely a nice fix there because it’s disconcerting for anybody who has that. And then the last one for 14.2.

Dave Smith: Yes, under testing we have… Under storybook. Now this is quite interesting, they’ve set up a new development aid which adds visual regression testing to the components in storybook. So components are like the low level UI components that we use to build the editor as a whole, not just blocks, but everything as a whole. And storybook showcases those in one place. And what they’ve done is they set up a visual dipping tool. So you run the test, it takes a screenshot of your component at a point in time, and then the next time you run the test it takes another screenshot and says, “Is this different to the previous one?” And if a certain threshold difference is passed, then it flags it up and says, “This test has failed,” and then a human comes along and looks at it. 

And it caught my eye because I thought, “Wow, this could be something that we could extrapolate out to maybe other parts of the editor,” like actual blocks themselves. Because with the best rule in the world, you’re can have all sorts of end-to-end tests and unit tests and all sorts of things like that. But the end of the day a lot of things are visual changes that only a human can notice. So if we’ve got this extra step of automation picking up on these things, it might help. Currently this is only running locally, it’s not running on continuous integration on GitHub, but maybe in the future someone could take that and run with it and maybe it could help.

Birgit Pauli-Haack: That’s a really great idea. I think that is something that developers who learn how to work with a block editor definitely can use that in their local development into figuring out, “Okay, what changed now? Yeah, what did I do wrong?” In the debugging parts, they don’t need to look at the console first when they see something like that. And they build visual regression into their own components that are based on the storybook components. So we are at the end of the Gutenberg plugin version 14.2. What did Gutenberg 14.3 bring to us? 

Dave Smith: Okay.

Birgit Pauli-Haack: Go ahead.

Dave Smith: So 14.3 we had release lead Aaron Robertshaw and he’s posted the what’s new in Gutenberg 14.3 post on Make Blog. And WP Tavern have also covered this in Gutenberg 14.3 improves image drag and drop. And those links will be in the show notes. Let’s take a look at the change log, what have we got first here, Birgit?

Birgit Pauli-Haack: Oh, first up is the post author blog now includes an option to link actually to the author archive, and this is definitely something that was… It’s a small tweak and it was probably a good first issue, but it’s definitely helping a lot of sites that have multiple authors to use it in the templates. Because then you also can, so you have an author archive and then when you template that you can also, there was one change in one of the other plugins that you can actually add the description that comes from the user database about the buyers, put it on top. So you have the author, you have the description, and then the list of all the blocks that now you can do link to that page from each host when you add the post author block to the post template. It’s a lot of templates and blocks.

Dave Smith: Well, I can see that it’s a small change, but I think it’s pretty handy for sites that produce a lot of content. I suppose the Gutenberg Times in fact would be one example of that.

Birgit Pauli-Haack: Yeah, absolutely. Absolutely.

Dave Smith: The next change we’ve got is we’re now using the tools panel in global styles. The typography panel is quite complex, as we mentioned before, it’s got things like letter spacing, case, all sorts of things you can change on typography these days. What it’s doing is now bringing the global styles interface into line with the typography interface that appears in blocks. So if you need to reset all the changes that you’ve made to typography across the entire site, on like a heading block, it’s now really easy to do that through a standard interface, which is a nice win there.

Birgit Pauli-Haack: Excellent. Yeah. And now the feature that was grabbing the attention of Sarah Gooding at the WP Tavern is to allow an image to drop into an empty paragraph block and to create an image block. I think I intuitively thought that was already possible, but maybe I just dragged it between blocks. So now you can, every time you just hit enter on at the end of one block, you can just drag your image into an empty paragraph and it adds it to the site.

Dave Smith: Yeah, I expect there’s probably instances where container blocks have a paragraph block as the default, so now you can just plug an image into that. That’s probably why it helps a lot as well. So yeah, nice little enhancement there.

Birgit Pauli-Haack: That’s great. Especially for the cover block, and group block, I can see that, yeah. Yeah, the next one…

Dave Smith: The next one is improvements to the writing flow, we’re now implementing of standardized controls that feel quite natural when you compare them with other text editors. So you can now hold down the alt key and use the arrow keys to jump around in blocks of text. So an example given is if your cursor is towards the end of a long paragraph, you can press alt and up arrow to move straight back to the beginning of that paragraph. And similarly, alt down arrow will move you to the end of that block of text. And these are all small little tweaks to the writing flow, but it does allow you to move quickly around text and brings Gutenberg into line with many other normal text editors.

Birgit Pauli-Haack: Yeah, I think this was very missed for those who use other text editors too, because it throws you when your shift or control and left arrow doesn’t get you to the beginning of the line and you need to use the mouse to get there. So yeah, I really love that writing flow improvement there. So the next one, it’s the WP HTML tag processor, I think you need to explain to me and our listeners what that actually does, Dave.

Dave Smith: I’ll give it a good go. Yes, this is a technical change, but one that is important for people who are working with dynamic blocks. So often dynamic blocks, the ones that use PHP to output the content to the front of the site, because they’ve got some sort of dynamic requirements and they have to list a post or grab your, I don’t know, post site logo or something like that. In fact, the site logo’s a good example because there’s an attribute to control whether the site logo should be a link or not. And if it isn’t going to be a link, then we need some way to strip out the anchor tag from the resulting html.

And before this processor was added, we had to do this with what’s called regular expressions, which are notoriously unreliable for parsing and modifying html. And this was happening across a number of blocks and the use cases were getting ever more complex, especially around things like using the post featured image in the mark of the cover block for example.

So what we’ve done here is we’ve added this HTML tag processor, which is a very standardized way to walk through the HTML of a given block, and then allow you to make common modifications to it, such as adding or removing class names. Seems like a small thing, but actually unlocks many, many doors and greatly simplifies working with blocks. Not only for core blocks like cover, gallery, and heading, but of course third party blocks can also take advantage of this now and avoid having to write lots of regex, which of course no one likes doing as far as I’m aware.

Birgit Pauli-Haack: Yeah, I’m really excited about that because it improves so much the developer experience for the block editor and it’s such a nice tool to be a little bit more secure about what you’re changing. And if something else is in there, does it screw up your edit or your plugin for instance, or the block? Yeah. So yeah, I’m really looking forward to the dev note for that, it won’t come until 6.2 and we don’t know yet what the planning is for next year, but I know that the leadership is working on all the things that come with 6.2, so we will soon have some information about that. But yes, this is definitely… Try it out, it’s in plugin 14.3, so the team definitely would need some feedback on that to see if it actually lives up to its expectation. 

Dave Smith: Yes.

Birgit Pauli-Haack: And then we have some more changes in the block library and one is also for the image and the team fixed the crop area aspect ratio for when you rotate an image and you crop it, that it keeps the aspect ratio for it. So it’s a nice change and it keeps you a little bit more safe when you do cropping on your images.

Dave Smith: Yeah, absolutely. The next one is another fix and it is for link colors in some theme contexts, specifically 2022. There was an issue whereby if an ancestor of the navigation block set a link color, then it would override any text color set on the navigation block, which is really, really confusing because say you had a, I don’t know, a green link color set on an a parent root block and you had red text color set in your navigation, you’d be seeing the green color in the editor thinking, “Well, what’s happened?” You wouldn’t know where this color’s coming from. It ended up being a temporary patch has being put in to basically increase the specificity of the CSS. But in the longer term we’re looking to migrate the nav block to use standardized color controls, but it’s a lot more complex than you’d imagine. But yeah, if you’d been experiencing that problem in your theme, then you hopefully shouldn’t have that problem anymore as of 14.3.

Birgit Pauli-Haack: And that problem was on both ends, editor and front end?

Dave Smith: Yes.

Birgit Pauli-Haack: Yeah, good to fix, yeah.

Dave Smith: Yeah. And there’s a next one, which is to re-add styles that were removed from classic themes. Why would we remove styles from classic themes, you ask? Well, obviously it was an accident. Basically a lot of the core styles have been moved to theme JSONs so that we can pass them programmatically, but in doing so some of the styles for buttons were lost and no longer output, which meant that classic themes had blank buttons for a little bit. So now those are in a separate style sheet and buttons are back looking nice again for classic themes by default.

Birgit Pauli-Haack: And I’m just going through that, and yes, that had been ported back, I think to… I’m not sure, is that ported back to WordPress 6.1? It looks like it but I’m not sure.

Dave Smith: I assumed that it had, if not, I think it has… Yes, it has been back ported to 6.1.

Birgit Pauli-Haack: Yeah, that’s a good thing, yes. So 6.1 is not having some backwards compatibility issues with classic themes, so that’s definitely a good thing. And then there were quite a few code quality changes that updates some of the tooling and linking code. Linting is when… Oh, maybe you would explain it better than I do, Dave.

Dave Smith: It’s just programmatically checking your code for common formatting changes. So WordPress requires you to have a space around parentheses, for example, so it will automatically check those and fix them for you. That’s linting.

Birgit Pauli-Haack: And the reason behind removing lodash dependencies from some of the JavaScript, I think was performance reasons, right? That it increased performance when you don’t need to load lodash.

Dave Smith: Yeah, lodash is a fairly sizable library, so there’s an effort underway to completely remove that dependency, which should reduce the bundle size going to the editor, which is always a good thing.

Birgit Pauli-Haack: Yeah, yeah. Speaking of tools, there’s another… It’s not a tool thing. There was quite a few discussions around the experimental APIs that made it into the WordPress code base, but now there is… Adam Zielinski actually put a proposal together on how to limit that access and the first version of it is now available in the Gutenberg plugin. Do you have some more information behind that?

Dave Smith: Yeah, so experimental APIs were quite controversial because Gutenberg does need to iterate and move quite quickly compared to core, for example. And so they often introduce experimental APIs and they’re not guaranteed to be stable and might break at any time. But of course some of these APIs were ending up going into a core WordPress release because they hadn’t been stabilized at the point that WordPress was released. And that was understandably something that we didn’t want to happen because WordPress has a commitment to backwards compatibility, so you can’t really have experimental APIs going into a core release. 

So a middle ground had to be found between those two positions, one, that Gutenberg needs to iterate quickly, and number two, that core needs to not have breaking changes in it, which is entirely legitimate. So the way that this has been done now is from now on, if Gutenberg wants to expose experimental APIs views within its code base, it has to do so quite explicitly. You have to go through a number of quite laborious steps to do so, which is important. And number two, if you are a plugin developer and you choose to consume and experimental APIs, you also have to jump through a number of code hoops in order to do that. 

One of which actually requires you to type in, manually, a string of text which says something to the effect of, “I know that using this experimental API will break my plugin on the next release,” or something along those lines. I mean, we laugh, but the point is that it is to educate people that if you do use this, it’s it is at your own risk. And I like to think this is quite a nice middle ground between the two positions and hopefully we’ll see it come to a fruition in the next couple of releases as the current experimental APIs are stabilized and all future ones have to go through this complex setup state in order to be exposed anyway.

Birgit Pauli-Haack: Yeah. And it wouldn’t so much be hard if only the Gutenberg plugin, that it would use the experimental APIs. But I think because most plugin developers that adopted block development also looked at the source code of the plugin and learned how, “Oh, let’s see how the core developer do that.” And they used that experimental API in their own plugins for many, many years now. And now that’s really hard to deprecate. If just WordPress using it, it would be easier to deprecate that because nobody else uses it and everybody would know how to change that. But because they are not only the plug-ins that are in the repository, they are plugins that are done by freelancers and agencies for their sites that are third-party plugins that are not in the repo might be using it. So that backwards compatibility promise is really something that needs to… Though the experimental APIs cannot be deprecated without breaking those and it also cannot be it need, they actually should need to be documented if third-party use them. But the nature of experimental API is actually not documented and can disappear at any time. But that is not possible when they’re in WordPress core. 

So yeah, so there is a solution coming out and I think there is a lot of… We talked about it before maybe with… I’m not quite sure. On the Change Log before when for 6.0 when there were, I don’t know, 280 experimental APIs that are merged at the core. Some of them are really only used for the Gutenberg plugin or the block editor, but some of them were actually used in the wider ecosystem. So speaking of JavaScript library, there’s the next feature is remove enzyme completely, and enzyme is a react testing library.

Dave Smith: Yes, that’s right.

Birgit Pauli-Haack: Right. Yeah. But now react has created their own testing library, so that’s why it doesn’t have to be bundled anymore, right?

Dave Smith: Yeah. I mean, we would be using these two testing libraries on our components, one was enzyme and the other one is react testing library. And react testing library, which is built on top of react’s own library, has its own nicer encourages you to test things in a… More experiencing them how the user would interact with the component, so it encourages better accessibility practices, et cetera. So it made sense to standardize towards one. So finally, after lots of work by lots of contributors, enzyme has been removed. And now if you want to test your components, you should use react testing library.

Birgit Pauli-Haack: All right. Yeah. And in the PR, there are also some code examples on how to do this for your own code, what you need to do in terms of taking out enzyme and using react library, so check out the PR 44494. And of course it’s on the change log for 14.3. So this concludes 14.3 and our Gutenberg plugin releases and we’ve come to the things that we discuss what’s still an active development, but what might come or will come to the Gutenberg plugin in the near future. Dave, you are part of the navigation project, almost exclusively, what is in store for the navigation project?

What’s in Active Development or Discussed

Dave Smith: Yeah, absolutely. Well, we’ve just rounded off the 6.1 cycle, we’re moving into thinking about 6.2. And there’s been a number of priorities suggested on the navigation tracking issue, which we’ll put a link to in the show notes, about what we should focus on for the 6.2 cycle for navigation in the block editor, including the navigation block. The proposal is at the moment to put a specific focus on editing and managing menus within the editor itself. It sounds obvious, but previous 6.1 is focused more on importing menus and automatic fallback behavior. Whereas this one is we’re going to try and actually the editing and managing of menus themselves. So there’s that. 

We’re also going to be working on foundational issues and improving tests for better reliability and some more under the hood technical changes such as moving from in IDs to slugs when you’re relating a navigation menu to a block. So we’re looking for feedback on those proposals, so if anyone wants to input, please go along to that tracking issue and comment and we’d be only too glad to hear from you.

Birgit Pauli-Haack: All right. So there was, at the beginning of I think 5.8 or something like that, there was the idea to actually have a navigation screen also for organizing menus. Is it an idea to go back to that? Or is it all kind of happening in the sidebar? Do you know what the approach is going to be?

Dave Smith: Yes. Yeah. I mean, the current thinking is that having a separate navigation editor screen, there was an experiment for that for a while in the plugin, that’s now been disabled, there’s no plan to continue to work on that. But instead the idea is to bring that ability to manage multiple menus into the editor canvas itself. If you think about things like templates and template parts, you can do that all within the editor, there’s focus modes for template parts. 

And the same thing will hopefully apply to navigation, so you’ll be able to manage an individual navigation block and it’s associated menu within the editor within the block itself. But also if you have lots of other menus and you want to edit one that isn’t on the canvas, for example, there will be a global navigation sidebar that you can pop open from that W WordPress menu on the top left and there you’ll be able to choose the different menus and move things around, edit them, things like that. And so the foundational work for that should be going into 6.2, the actual screen may not appear in 6.2 but at least the foundational work will be going in to make that possible. So yeah, that’s the state of play on that particular aspect.

Birgit Pauli-Haack: Well, thank you to elaborate on that. And then, so Andrew Sorong has also created a new tracking issue for the layout options that are going to come after 6.1. And layouts are the ones that, for all the layout options, design tools and other refinements. And 6.1 comes with three layouts now, the flow layout, the flex layout, and the constraint layout, making it possible so the inner blocks are following their parents, so to speak, in that. 

But there are also additional improvements in the works. One was the fixed positions for head and footer template parts, meaning it’s stuck to the top or to the bottom. Also have some more layout consistencies, like an ad layout support to the cover block. Also some minor things like allow the change block cap in the editor and all that. So we’ll have that link also in the show notes, so the tracking issue, so you see what the team is working on and what they have on their priority list so you can follow along and also give input. It’s really important that people test along the way so it gets a more stable version of it.

Dave Smith: Ooh, I’m excited about fixed position head and footer template parts. 

Birgit Pauli-Haack: Yeah.

Dave Smith: A lot of people ask me about that for navigation, so I can imagine.

Birgit Pauli-Haack: I can imagine, yeah. So yeah, it seems that we are at the end of our show today. And I’m so happy, Dave, that you joined me today on going through the two change logs and talk about WordPress 6.1 and all these great tools that you brought in from the community.

Dave Smith: It was an absolute pleasure, thank you.

Birgit Pauli-Haack: Is there anything else that you wanted to alert our listeners to that we didn’t talk about before, before we close the show?

Dave Smith: No. Actually, I think we’ve covered quite a lot in this show. So no, thank you.

Birgit Pauli-Haack: Yes, we did. So when people want to reach you, how would they connect with you apart from the YouTube channel that we are going to put in the show notes?

Dave Smith: Sure. I think probably the best way is through WordPress Slack, I’m Get Dave on WordPress Slack. Feel free to send me a DM if you’d like to discuss anything.

Birgit Pauli-Haack: Excellent. And as always, the show notes will be published on GutenbergTimes.com/podcast, this is number 74. And if you have questions and suggestions and news you want to include, send them… Or you want us to include, send them to ChangeLog@GutenbergTimes.com, ChangeLog@GutenbergTimes.com. Thanks again for listening and being part of our show. Thank you, Dave. And this is goodbye for me, bye-bye.

Dave Smith: Bye.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.