Gutenberg Changelog #84 – Gutenberg 15.9 and 16.0, Developer Blog Updates, and WordPress 6.3

Gutenberg Changelog 84 Cover w/ Isabel Brison and Birgit Pauli-Haack
Cover Art: Gutenberg Changelog
Gutenberg Changelog
Gutenberg Changelog #84 - Gutenberg 15.9 and 16.0, Developer Blog Updates, and WordPress 6.3
Loading
/

Isabel Brison and Birgit Pauli-Haack discuss Gutenberg 15.9 and 16.0, New Posts on the Developer Blog and the WordPress 6.3 release.

Show Notes / Transcript

Live Q & A: Layout. Layout. Layout

New Posts on the Developer Blog

Gutenberg Releases

WordPress 6.3

Stay in Touch

Transcript

Birgit Pauli-Haack: Hello and welcome to our 84th episode of the Gutenberg Changelog podcast. In today’s show, we will talk about Gutenberg 15.9 and 6.0 releases, new posts from the developer block, the roadmap for 6.3 and a little bit of WordCamp Europe. I’m your host, Birgit Pauli-Haack, curator at the Gutenberg Times and the WordPress developer advocate and a full-time core contributor to the WordPress open source project.

And I have the wonderful pleasure to have Isabel Brison with me on the show. And Isabel has been a designer, developer on the Block Editor for almost four years, I think. And is the editor tech co-lead for WordPress 6.3, and therefore knows quite a bit about the features coming to WordPress 6.3. Isabel, thank you so much for making the time today to be on the show.

Isabel Brison: Oh, it’s a great pleasure. Thanks for inviting me.

Birgit Pauli-Haack: We are both on the 6.3 release squad. So you are the tech colleague for the editor, together with Ramon Dodd. I’m on the team of editor triage with Nick Diego, Anne McCarthy and Firoz Sabaliya. Both of us, Firoz and I, are first-timers on this release squad, team four editor triage. So that’s going to be interesting. And we are less than two weeks before beta one.

Isabel Brison: We are indeed.

Birgit Pauli-Haack: What’s happening in a release cycle before beta one and what after?

Isabel Brison: So right now, from an editor tech lead perspective, what happens before beta one is we need to make sure that all the latest changes from Gutenberg plugin, so more than from the plugin itself, from the Gutenberg repo where all the cutting-edge stuff is being worked on. All those changes have to be transported into the core repo, which is a different repository.

So part of that process is automated. I say all the changes, but in reality, it’s all the changes that are stable enough to make it into core. Because in Gutenberg, there’s a lot of experimental stuff that is not necessarily ready for core yet. And so part of the process is that the editor tech lead, in this case, the leads, because there are two of us, we have to make sure that the right changes are being put into core, that everything is working well.

Part of that process is you can say automated because essentially, in Gutenberg, you have a lot of JavaScript which is published as NPM packages and/or consumes those packages. So that part of the process is you update the packages, you publish the packages, the latest versions. And then we update the packages in the core repo to get those latest versions.

However, there’s also a fair amount of PHP in Gutenberg, and that part needs to be transported across to the other repo manually. And so that’s where we have to go through all the changes that require adding PHP to core and do pull requests for each change set and review them and commit them individually. So depending on how many changes, and we’re talking… So Gutenberg has been growing a fair bit.

We have a lot of contributors now, and so there’s a lot of changes in each release. And so this process can become a bit overwhelming if there’s a lot of stuff. And now we’re counting down to beta and going, “Oh, we need to get all the back ports in, in time before beta and in time, preferably, to be able to test them a bit in core and check everything’s okay before beta’s cut.” So that’s the path of the process that we’re at now.

Birgit Pauli-Haack: So there’s a lot of shifting around and talking to contributors and testing as well maybe beforehand. Is there also a process to audit some of the experimental APIs that are there if they can be made stable?

Isabel Brison: Yes.

Birgit Pauli-Haack: Because that was one of the contentions that sometimes experimental stuff gets into core.

Isabel Brison: So that’s also something that occurs before each release. There’ll be an audit in Gutenberg of all the experimental APIs. So this is interesting. This situation of the experimental APIs has evolved a bit over time. So previously, up until, I want to say maybe a year ago, but I have a very, very hazy sense of time. So it might be more or less.

There were a lot of experimental APIs that would be merged into core because they were part of a Gutenberg feature that was considered stable enough. The feature itself was considered stable enough to move into core, although the API had not been marked stable. And so in practice, there’s a fair few experimental APIs that are public. And because they have made it into core at some point in the past, we now have to support them indefinitely because there are extenders out there using them in the real world.

So we can’t scrap them, we can’t make changes to them. And so essentially, they are stable but there’s a lot of them. And there’s some progress, slow progress in marking things stable for each release but we have to go through a lot of APIs. So every time before the release, I feel like this work should be done maybe a bit more in advance as opposed to being a month earlier or three weeks before beta.

Because by that time, everyone’s just super busy with, “Oh, but we need to get this feature finished and we need to make sure this is working. We need to fix all these bugs to make sure that this feature’s stable enough to make it into core.” And at that point in time, no one is concerned about whether the APIs are marked experimental or not.

So the good improvement that we had a while ago was that a new system was introduced into Gutenberg that allows us to export experimental APIs as private. And so that means from a package, there’s a bunch of private APIs. And they can be used in another package, but they are not made available to the general public. And that makes it safer to have these APIs be experimental for a while longer and be able to make changes to them without having to provide the indefinite back compatibility for something that we, at some point, realized was not the right API.

So this is all work in progress. So I did that audit recently, and what I noticed is that there are not that many. Now that we have this mechanism that allows us to mark APIs private, we’re not actually putting any new experimental APIs into core. The ones that are already there, though that’s another matter, we progressively stabilized. But it is definitely a work in progress.

Birgit Pauli-Haack: That’s awesome. And I think for the show notes, there was a process and that was proposed at the Make blog a while ago. You’re right, I think it was almost a year ago. And I have the feeling that about three or four months ago, Adam Zelensky, who was one of the drivers of this new feature or new method on how to handle experimental APIs now, he has published a progress report on how that’s working now.

So for the listeners who are interested into getting really into the nitty-gritty of it, that is definitely two posts for you to read. So now just for the people that don’t know you, you have been a guest on Gutenberg Times Live Q&A in January, and you were talking about layouts. How is the work progressing? And how was your talk at WordCamp Asia? So I’m just getting some of our listeners caught up with you and what happened.

Isabel Brison: That seems like an eternity ago, WordCamp Asia.

Birgit Pauli-Haack: Don’t I know it?

Isabel Brison: Back in February. Yeah, it was. And so what happened is, layout is progressing slowly. So there are a few small enhancements that are going to be going into core 6.3. One of the things that I actually just merged this PR earlier, which is to stabilize the layout support. So the layout was one of those experimental APIs that have been in core for a while.

And because they have been there for a while and they’re actually being used in production by a few plugins, they are de facto stable because we do have to provide that compatibility for them. So it becomes absurd at that point to still have the API marked experimental. So layout has just been stabilized. I guess that’s the big news.

It doesn’t mean anything in terms of features. Literally, it’s just the tag. The experimental tag is no longer there. I hope that going forward, this is going to give folks more confidence that they can use layout in third party extensions and it works. It would’ve worked anyway because we did have to provide those assurances already. But it’s good to have it officially stable.

Birgit Pauli-Haack: Yes. Congratulations, so to speak.

Isabel Brison: Thank you.

Birgit Pauli-Haack: You were also talking about working on the grid layouts. I have seen there are still experiments. Well, now that you are part of the release cycle there until the release, you probably are not going to be able to work on that. So do you think that’s going to get into 6.4 or that it’s progressing?

Isabel Brison: So that’s a good question. So grid layout. So what happens is a new layout has been created, it’s available. So through the layout API that is no longer experimental, anyone can now use a layout add. So add layout support to a block. Say you’re building a custom block, you can add layout support to it and you can make that layout be of type grid. So that is already available in the plugin.

And what is marked experimental, and will not be shipped in 6.3, is the group grid variation. So the group block has a few different layout variations, and behind an experimental flag in the plugin, there is a grid variation for the group block. However, that hasn’t been marked stable yet because what we have currently, the grid layout is a very basic version. It’s a very basic type of layout.

There are a lot of features to grid, there are a lot of very interesting and good thoughts out there about how we can build on it and create awesome tools so people can build really cool grid layouts. However, we only really have that basic structure that gives you a grid layout without any real possibility of configuring for the child lock. So if you want them to occupy one space in the grid, two or three, which is what really gives grid all of its flexibility, is that ability to manipulate and decide where the children are going to sit.

So for now, that group grid variation is not going to ship, but grid is actually going to ship in the post template block as a layout variation for post template. So we previously had in the query block the command… The controls are actually in the query block.

So you could choose between a list or a grid layout type of query. But what those controls were doing were actually setting a kind of custom layout in the post template block. And because it was a custom implementation, there was no possibility to add a block space and control to it. And because people really need to have the ability to change block spacing and post template, we did the refactor.

And now post template is using actual layout support, so block spacing can be set on it. And so behind the scenes, it still has the custom toolbar control where you can choose between a list or a grid type layout. So the exposure of actual grid layout controls is kind of limited, but it is using grids. So technically, yes, there is one lot that is shipping with grid layout in 6.3.

Birgit Pauli-Haack: Excellent. Well, that was the catch-up with Isabel Brison on the layout. So thank you so much. So let’s go a little bit further into our show here today. 

Announcements

We have another announcement. Since the last Gutenberg Changelog, there were five new posts on the developer block. And one was just published this week that’s, “What’s New for Developers?” by Justin Tadlock. And that’s the fifth installment of the monthly roundup showcasing features that are specific for theme and plugin developers.

And it focused a little bit on the 6.3 development cycle. It’s more like you can test it now, so your plugin and your theme will be compatible when 6.3 comes out, or just make sure that it doesn’t break kind of list. But it has a lot more other things in there. Ryan Welcher published a tutorial on how to use the block inspector sidebar groups that came in with 6.2.

And now, as a developer, you have more control over the custom controls that should be appearing in the… Inspector controls are what’s showing in the sidebar, just to place that in the canvas where you see all those custom controls. So if you want to, as a plugin developer, add additional controls to, say, the dimensions, you can group the interface for that to show up in the style tab, in the dimension block.

And he has some nice code examples in there. Justin Tadlock also published customizing core block style variations in theme.json. And it’s a walkthrough through the block styles directly in theme.json. Instead of using them in a custom style sheet, you can centralize all the things a little bit more in the theme.json. Curating the editor experience with client-side filters, post by Nick Diego, shows off also the new filters that were introduced in 6.2 and how you can change the editor experience with new client-side JavaScript filters, and has some great examples there for your block development.

And then lastly, the first one is useentityrecords hook as an easier way to fetch WordPress data, by Michael Burridge. And it’s part out of the WordPress data package and core data packages. And the hook has been extremely useful to fetching and working with data in your block development.

And this tutorial shows you how it’s easier to use entity records instead of the getEntityRecords from the data package. This only is for developers of course, it’s to develop a new block. So it won’t help anybody who is a no-coder. But you know that you can curate the editor experience or your developer can curate the editor experience. It’s something that you can, as a project manager, definitely learn more about it.

Isabel Brison: Good stuff. There’s a lot of features here.

Birgit Pauli-Haack: We’re all catching up on quite a few things to make it easier to do block development, and the theme development and also augment the dev notes that certainly talked about the new groups for the inspector controls or through the client-side filters but not as deeply enough. Sometimes it’s really hard to get the exact use case, or if you don’t have examples for various use cases, to get it into an idea and how to use it in your project.

What’s Released – Gutenberg 15.9

So that brings us to what’s released. Then we are tackling first the Gutenberg 15.9 release that’s from May 31st, by about two weeks ago. And it included 171 PRs merged into this release from 58 contributors. Seven of them were first-timers, and Carlos Bravo was a release lead and author of the release post. So let’s dive in. 

Enhancements

There are enhancements that you can now have block variations transformations in the block switcher. So what does that mean? It means that when you have the inserter and you want to do a transform, you can also offer the block variations from it, if I understood this correctly.

Isabel Brison: The block switcher is in the block toolbar, correct? It’s in the block toolbar. When you click on the block icon, you get a list of the possible transforms. So apart from other blocks that you can transform the block to, you would get variations of the same block also as possible transformations, which I feel existed at some point in the past and then was removed. And that has been re-added. I’m not sure. I might be wrong on this. I just have a vague feeling that this is familiar.

Birgit Pauli-Haack: Yeah, it sounds really familiar. I don’t know if it actually includes the styles as well. Because the styles are on the right-hand side and you have to now… But it doesn’t. So it’s the block variations because the blocks’ variation have other names. But they were actually organized in the transformations further down with the prioritization. You probably can get them higher up in the block switcher. So this is definitely something I would support even if it went back and come back.

Isabel Brison: Yeah, makes it easy. And you get style variations too for blocks that have style variations. This is actually pretty neat.

Birgit Pauli-Haack: And you don’t have to open up the site, but to just get the style variations in there. Next thing up would be that the code block now has wide align support. And that is really good because sometimes the line in a code block is creating horizontal navigation bars, horizontal scroll bars. And now, with the wide support, you can make it a little wider and have that one line not remove the horizontal scroll bar, which is a better reading experience.

Isabel Brison: Yeah, that’s a good aesthetic improvement too. It can be nice to have wide code windows so you can read the whole thing in one go without having to scroll.

Birgit Pauli-Haack: Do you want to take the next one?

Isabel Brison: What’s the next one? I wanted to mention that in 5.9 a PR was merged that removed the post content block from the list of blocks that can be inserted in the post editor. And that makes sense because the post editor is basically what we get inside the post content block. So if you tried to add a post content block to the post editor, it was getting an error, which was a really bad user experience.

And so the block was rightfully removed. But in the meantime, someone noticed that there was a possible use case for the post content in the post editor because we can add query blocks in the post editor. So inside your post, you could have a little query with some categories or something like that. And there is a legitimate use case for having the post content block sit inside the query, and so inside the post template that you have inside the query.

Because if you have short posts, if you have a custom post type that’s fairly short, you might want to actually show the whole post in there. And so a PR was quickly done to fix this and allow for that use case. I don’t think it went into… It didn’t. No.

Birgit Pauli-Haack: It did.

Isabel Brison: For sure, it didn’t go into 16.0.

Birgit Pauli-Haack: I think it did.

Isabel Brison: It is going to go out into… It did? I’m pretty sure that it was only merged yesterday.

Birgit Pauli-Haack: Oh, okay. And it didn’t-

Isabel Brison: No.

Birgit Pauli-Haack: … It wasn’t backported. No. So it will come back for 16.1.

Isabel Brison: So in 16.1, we will be able to use post content inside queries inside the post editor, which is pretty cool.

Birgit Pauli-Haack: One other use case is from a different custom post types, you want to show some of the posts in there and in your blog post. And there are many use cases I can think of it when you wanted to query something else and need to post content in there. So the next one is the Wayfinder or Command. I think there’s still a discussion going on on the naming of the feature.

Wayfinder was also not the one that was… It feels right for me, but I’m kind of English Westerners. But in the eastern hemisphere, it was a little bit differently seen. And for translated, it was really hard to find a good way. So the discussion goes on. But in the meantime, the Command’s API has marked in public, so you can use it and test it for your plugin or your WordPress install.

And Riad Benguella’s post Command Center request for feedback also contains some code examples on how to use the API. And you can create static commands, dynamic commands or contextual commands. And so you can try it out and see what it all does for you. It’s like a search bar that you don’t have to go through. You click control K, and then a search bar comes up on the interface and then you can type in some search commands. And it gives you a list of items that you can do, like add page or add post or something like that. Have you played with it?

Isabel Brison: It’s really cool. It kind of reminds me of the Spotlight on the Mac. I don’t know if Spotlight is the best name for it, but in my head, I’m calling it Spotlight. Because basically, it just pops up, this bar in the middle, and you can search for stuff and you can do stuff from it.

It is great. I wanted to add that I think possibly also in 5.9, there was a PR that added the ability to invoke the Command Center by clicking on the template name at the top of the site editor. So that’s just another super practical shortcut.

Birgit Pauli-Haack: Yeah, 15.9. So what else is in there? The interactivity API is still in experiments. And do you want to talk about the lightbox and the directives?

Isabel Brison: Yeah. I thought I’d mentioned it because it’s super exciting. It’s still very, very experimental. At this stage, it is unlikely to make it into 6.3, which on one hand, I’m slightly sad because lightboxes for images are really cool. On the other hand, it is still behind an experimental flag in the plugin. It hasn’t actually seen a lot of real-world testing.

So it’s also good to get some testing done before actually merging the feature into core. It’s very new, it’s very promising. So the whole interactivity API is a really interesting piece that’s been worked on for ages. It seems like ages. I don’t know. It can’t be that long. But I’m so excited about it because it provides a really neat way of adding interactive behaviors that’s usually only achievable with JavaScript to playing blocks.

And so it’s going to add a bunch of behaviors out of the box for core blocks, but it’s also going to be possible to use that API in the future to create custom behaviors for custom blocks. So it’s just a really nice way of standardizing a way of adding JavaScript to blocks to create dynamic behaviors. And the first experimental one or the first experiments to be put out there in the plugin is the possibility to add a lightbox to images. So if you enable it, you can click on the image in the front-end and then the image just pops up in full screen kind of thing, which is pretty neat.

Birgit Pauli-Haack: And I know that Luis Herranz did a workshop at WordCamp Europe last week. There was quite some buzz around the interactivity API. Because it mostly is also in the PHP render file where you can just add the directives or add the call for the directives. So it gets a lot of PHP developers also excited about block development and adding the interactivity to them.

And the excitement is also around being able… which is not going to be in the first version, even if it makes it into 6.4, that you can actually create your own directives. So the core will come out with, I don’t know, 15 or 20 directives that have a lot of use cases, cover probably 80% what a developer would need.

And the combination of it, be it data binding, be it button actions, being other interactivity. So this is a really exciting feature to come to block development. And I think it’s one of the missing links to get other people excited about building with blocks and JavaScript. And get the first vendor with PHP and then have the client-side changes through the API is really cool.

Isabel Brison: Yeah. Cool. My cat just popped in. Sorry.

Birgit Pauli-Haack: The cat. So the next thing is that the text formatting tools in a paragraph have now two new attributes added. That’s the long language, so L-A-N-G, and the D-I-R, the dir attributes, which helps with multilingual posts. So you can add a language like French or Italian IT to a paragraph, and then a signal to the assistant technologies and the reader, “Okay, this is a different language.”

And the dir part is that you change left to right, right to left rendering of that. And the code, almost verbatim, is used from Jean-Baptiste Audras, who had a plugin that added those two formatting tools to the paragraph.

And the subsequent PR also now uses the bidirectional text override element from Mozilla. But it’s good to have these additional formatting tools in there to cater to the multilingual content that you find all over Europe. So this is really cool.

Isabel Brison: Not only is this really cool, but I am fairly certain that this is a longstanding issue from the accessibility audit way back when that the last time I checked was still open. So it might be a good idea to go over there and see if that issue can now be closed.

Birgit Pauli-Haack: But now it can be closed.

Isabel Brison: Super exciting.

Birgit Pauli-Haack: That was definitely a missing piece. And that was also the reason why Jean-Baptiste added that to his companies or that his company built the plugin to help their clients with that kind of formatting. So there is a new API to allow prioritization of inserter items.

If you have a block list setting, you now can allow the parent blocks define the priority for the blocks that are allowed in it, and how the inserter displays them for the inner blocks of that parent block. So that is definitely another customization and curation tool for the extenders with their block development.

Isabel Brison: Oh, yeah. For sure. That will be great to provide more custom user experiences for certain block types. Definitely.

Birgit Pauli-Haack: I think we need to somewhere create a list of all the extension possibilities because I don’t think there is an overall list of all the possibilities on how to extend now. Sometimes there’s still missing documentation there of course. Not of course. But I found that some of the extensibilities like the inspector controls, the documentation’s in the README for the source code component but doesn’t bubble up into the developer handbook of the editor.

So I know that Nick Diego and Ryan are working on that together with Michael to figure out this architecture of missing stuff. Next thing is it sounds really benign, renaming template parts to library. So in the side editor on the left-hand side, there was a menu item called template parts. And that will be renamed into library because it will also house reusable blocks and patterns, reusable patterns or sync patterns, I think they’re called.

The template parts, of course, will be also underneath it. I don’t know how far the syncing of pattern or reusable block is going because there’s a lot of confusion since the beginning: what is a pattern? What is a reusable block? And what is the template part? And they sound to be the same, but they all have one thing different of them. And there is an effort to unify it a little bit, and just manage what’s different instead of have three different items for them.

Isabel Brison: I think that that would be great because reusable blocks are essentially patterns or they were already working as patterns, although they have the block itself. When you create a reusable block, it’s frozen, right?

Birgit Pauli-Haack: Yeah.

Isabel Brison: If you make changes to it, you’re making changes to all reusable blocks to the content. Whereas patterns, you drop a pattern in somewhere and you make changes to it and you can continue using that pattern elsewhere.

Birgit Pauli-Haack: But yet there’s this big problem that when you have a pattern and you change the design of the pattern, you cannot go back and have that change as well on all the time all the uses that you had, because there is no record of a post using a pattern. Because once it’s in the canvas, it just is the blocks that are inside the patterns.

Isabel Brison: Yeah. So I think the fundamental piece here is being able to have patterns where the design can be changed globally, even if the content of the pattern is individual to each instance. And it’s a pretty complex piece of work. It’s being actively worked on. There is, I think, an effort to consolidate reusable blocks and patterns.

So I think the idea is going to be that reusable blocks are going to be absorbed and become patterns of a type. But it’s still fairly early stages considering the complexity of the endeavor. So at this point, it’s not certain what, if anything, of that work will actually make it into 6.3.

Birgit Pauli-Haack: Yeah, I can see that. And because the reusable blocks have actually also an interface to edit them, which the patterns do not. And that’s also something: how can you make those editing interfaces be used for both of them? There are a lot of different things that need to be aligned differently to make it all work, and I think it’s a fairly complex thing. Yes, you’re right.

So the next part for 15.9 is that the global styles get revisions. And that has been on the feedback list and on the wish list of a lot of people who have participated in the Full Site Editing Outreach program and have been very faithful in doing all the testing, the calls for testing and having a revision.

Because you know that when you change colors and font settings and things, you don’t know what you get until you see what you get. You don’t know what you want until you see what you get. And then all of a sudden, “Oh, maybe I liked that previously better.” But then you don’t remember the combination of what it was. And now you have revisions and you can see them side by side. So this is a very exciting new feature that will come in, and it seems to be making to 6.3.

Isabel Brison: Oh, yeah. That one has been merged and it’s definitely going to make it into 6.3.

Birgit Pauli-Haack: There might be UI changes, but it will show up in the styles right-hand side and the sidebar under revisions. And then you get a list of all the revisions in the canvas and you can see them all together.

Isabel Brison: So you can access the dark sidebar on the left-hand side. If you go to the styles and you see if the theme has style variations, they’ll appear there. But also in the right-hand side, global style sidebar, you can also access the revisions on the styles actions. There’s a little button at the top.

Experiments

Birgit Pauli-Haack: Excellent. Yes. Under the experiments of 15.9, there is a list items called the behaviors UI. And that’s part of the interactivity API, I believe.

Isabel Brison: Yes.

Birgit Pauli-Haack: And that is kind of a standardized way to attach behavior to an element or something like that. As I said, it’s in the experiments and I think it’s part of the lightbox behavior. That’s the only behavior that’s available right now. But what else can you think about what this could do?

Isabel Brison: Yes, I believe so. So say that you can define certain types of interactivity for certain blocks as, for example, the image can have a lightbox, but we don’t want all images on the site to suddenly have lightboxes.

And so the behaviors UI is something that it provides website authors, users with a way of enabling those interactive behaviors or disabling them for any given block. So it’s an important piece because certain behaviors might not be applicable to all blocks on the site and you need to have a way of turning them on and off.

Birgit Pauli-Haack: And so that will be part of the advanced interface on a block-based level in the sidebar.

Isabel Brison: Yeah. Currently, it sits under advanced in the block sidebar.

Birgit Pauli-Haack: Well, this concludes our changelog for 15.9. 

Gutenberg 16.0

And now this week, 16.0 was released and Nick Diego was the release lead, and he wrote also the post. And it had 164 pull requests by 54 contributors. So it’s always a good size of contributors adding code to things. And there were four first-timers as well. And this comes with one feature we are all excited about. But do you want to take us into it, Isabel?

Isabel Brison: Yeah. So the feature that we’re all excited about, there’s actually a couple of features that we’re all excited about. One of them is the ability to add new pages from the site editor directly. Now a disclaimer, the ability is to add draft pages, not to publish them directly. But that’s great because the first thing that you do when you add pages, work on it is a draft, and then only afterwards you publish it.

So it’s good. It’s the start of being able to do everything, having the site editor as the center from which you can do anything to your site, including create pages, edit them possibly at some point in the future, publish them. So that’s a pretty great new feature to have. It can be accessed from the left-hand sidebar.

Birgit Pauli-Haack: The new page also helps when you create new navigation menu where you want to access or point to a page that doesn’t exist yet. So this certainly helps as well. And I saw some discussion around it for that to work well and it show up in the list of searches that the page is actually published. So it’s the question, “What is a good way to move forward?”

But what I am really excited about is that I can now edit a page in its context and I see how it works in context of the template. So I see the header, I see the footer, I see if there is a sidebar and how my content behaves that I create for the page. It allows me. And I know from the feedback of the Full Site Editing program, there was quite some feedback that there is a confusion between, “Am I adding the page or am I adding the template?”

And some people edited the template thinking it was a page, and then found that edited piece or that added piece on every single page because they inadvertently changed the template. So the possibility was taking out of the site editor, but it’s coming back now with some guardrails. So you know when you edit a template, all of a sudden, the title changes to page title instead of saying about us.

And it also highlights that you are editing now a template part instead of the page itself. So I think we are getting really closer to have more a unified system of editing and not having to switch out from the site editor to the post editor and back in the admin where you have multiple back steps to get to the old page editing screens. So I’m really excited about to get this all in one interface.

Isabel Brison: So that’s the second feature, what I was saying when I said there were two features. New pages, but also the ability to be able to tell at a glance if what we’re editing is the page’s actual content or the page’s template. So now it’s only possible to either edit one or the other, but not both simultaneous setting. That’s a pretty good one to have in there because otherwise it would be extremely confusing.

Birgit Pauli-Haack: Yeah, absolutely. And then there were a few, I don’t want to say small changes because it definitely takes an effort to get it in. But the list view got two additional, I would say, quality of life changes, the dragging. So you can now drag outside the immediate area and get into a different drop zone element there. And it’s now easier to position a block on top or on the bottom of the list.

Before, it was really hard to get on the bottom of a list when you drag and dropped it. And then the other one is that sometimes in the list view, your container blocks collapsed. And when you dragged a new block into that container, it always put it on the top. Now it makes more sense to put it on the bottom because I added to it.

So when you open up the collapsed block again, you have all the new containers or blocks that you dragged into it on the bottom of the group block, for instance. So I really like those features. They make it much easier to be a little bit more predictable in what you’re doing and behave like that as you think it would. Intuition is an interesting thing. Sometimes you get it right, but sometimes you get it wrong, and 50/50 is a pretty good ratio for that.

Isabel Brison: Yeah, true. And it often takes a few iterations to figure out what the best behavior is and what’s most intuitive because it’s not always obvious. When you’re conceptualizing something, you’re thinking, “Oh, let’s build this new feature. It’s going to work like this.” But then in practice, it’s like, “Oh, actually that doesn’t work very well at all.”

Birgit Pauli-Haack: So what else is in there? So I stopped at the details block. The experimental flag for the details block was removed and the blocks itself was stabilized. Now you have the two elements: the summary and the details. You can certainly style them accordingly. And now you can also add them to your canvas and it works out of the box. So this is more, it’s a block.

And we talked about it before, I think, in last episode as well as the one before. Because it was experimental and we were kind of going back and forth on it. It’s the block where you can use it as a spoiler alert. You can hide the details of your movie review that would spoil for those who haven’t seen the movie, spoil the movie ending or that part. Or if it’s just minutiae detail that only two or three readers would need, you can hide them in the details block, and then you get an error to expand it into the details from the summary.

Isabel Brison: That’s pretty cool block.

Birgit Pauli-Haack: And it was long in the making. It will make it into 6.3. I think there are two other blocks that are on the verge in core, but I don’t think they’re going to make it. The one is the table of contents block, and the other one is the footnotes block or blocks.

Isabel Brison: That’s sad. Those were really useful blocks.

Birgit Pauli-Haack: It doesn’t seem… There wasn’t any movement on the table of contents block for about a month. So I’m not sure that anybody takes it on because there are two things that still need to be done there. And the footnotes block, I think Ella is working on that. And she is having two different variations where that needs to be a decision, which one will be pursued or not. And with two weeks to go, it might be a little bit tight.

Isabel Brison: And it’s not two weeks, it’s closer to one week actually because for the packages… So for all the JavaScript pieces, what happens is we’re going to grab the release candidate for the next Gutenberg plugin release, which is going to be 16.1. And publish the packages from the release candidates with any bug fixes that are necessary after RC is cut. And those updated packages are what’s going to make it into core before beta one. And because the RC is going to be created towards….

Birgit Pauli-Haack: Next week.

Isabel Brison: … the end of next week. It would usually be on a Wednesday. It is likely at this point that it’s going to be Thursday or Friday. Given that both editor tech leads for this release are in Australia, we can conceivably do it on our Friday morning.

And that gives a little bit of extra time. It’s still Thursday night, everywhere else in the world. So at this point, that is likely to be the plan. And so what’s going to make it into beta one is anything that can be merged until that date, which is essentially one week away.

Birgit Pauli-Haack: Yeah, it’s one week away. We are recording this on June 15th, and beta one is the 27th. But the next release candidate, that’s going to be the 23rd or the 24th. So continuing with 16.0, thank you for this explanation on how tight it actually is with the timeframe.

Isabel Brison: No worries. We’re glad to throw everyone into panic.

Birgit Pauli-Haack: High alert. So the query pagination block, another feature is that you can hide the label text for the next and previous. You have three choices: you can have an error, you can have carets or you can have text and now you can have both. But you can hide the previous text for it and just have the errors. So that’s a feature that is on par with the query pagination form classic themes, which is really cool.

And I highlighted one other thing, and it’s only really relevant for developers that want to get into how to use the HTML tag processor, Jeff Ong refactored the search block to actually use the HTML tag processor. And I think it’s a good case study on how this actually makes it easier or more readable to use the HTML tag processor instead of rejects in PHP. So I think it’s the PR51273, if you just want to get up and listen to this, get up and look at it. Of course, it’s in the Changelog 16.0. Have you worked with the HTML tag processor?

Isabel Brison: Yeah, I used it a while ago to do some layout-related stuff. So I think I actually was the first person to use that API in Gutenberg. It was still in Gutenberg, hadn’t been in motion to call yet and it was just being worked on by a few folks. And I was doing a layout-related task where it was trying to add the layout, the class.

So in a block when you have layout support, you get class names that will say what kind of layout it is, and then you can hook styles to them and stuff. And most blocks just have one wrapper. Blocks that have inner blocks have wrapper, inner blocks. But there are some blocks that have a bit more of a complex markup structure.

And so the idea was that the layout classes should be added to the inner wrapper so that they can have an effect over the inner blocks of the block. And that was a piece where I found using the HTML tag process, it was super handy because I had to locate the inner wrapper of a given block. So that was a great API. It is really, really helpful for that kind of work with PHP when you have to go digging around for some HTML and you don’t want to use rejects.

Birgit Pauli-Haack: I think it’s not tied to WordPress. You actually can use it in any PHP code, so reaching out to the bigger universe outside of WordPress. It’s definitely an enhancement of the language as well. So another line item from the Changelog is that the post template now has block spacing and layout.

Isabel Brison: Yeah, I did that one actually.

Birgit Pauli-Haack: Congratulations.

Isabel Brison: Well, it went through a few iterations. It was one of those PRs that end up taking a month and have 80 comments on them. Well, maybe not 80 comments, but there was a fair amount of reviews and re-reviews and, “Should we do it this way? Should we do it that way?”

Backwards compatibility was a concern because the blocks in production, there are lots of websites using it, so you can’t break stuff for real-world users. But it’s done and pretty happy with it. We talked about it a bit earlier. I don’t think it’s probably necessary to go through what it does again. But I think there’s a lot of folks who are going to be happy with this one.

Birgit Pauli-Haack: And I think that answer shows it’s kind of one answer that I had conversations with people at WordCamp Europe, and it’s one question I also gathered at WordCamp Asia. And it’s really hard to answer it because the question is, “When are design decisions made and who makes them?” And it’s very hard to explain that iterative process of developing these new features that haven’t been in WordPress before.

So there is an initial design that comes from the design team, but then all subsequent is iteration on how the flow is going to be. And as you said, there are 80 comments there, so that it’s definitely a community approach to it, or at least a subset of developers trying to figure that out in a team.

And testing comes about, and then there’s going back to the drawing board and then start again. So there is not really that one decision-maker and that one design that is zeroed in on. It’s more really what the idea was, and then we do the implementation. And then it’s how it works in context with the other things and it needs to be adopted.

Isabel Brison: It’s very much a process. And depending on the complexity for any big piece, you’ll have a bunch of discussion even before the thing is built. And then, while it’s being built, there might even be more than one PR, there might be, “PR one, this approach.” And then, “Ah, but there’s another approach that we could try. Let’s do another PR and try it.”

And then people will test and compare the PRs. And we are a very opinionated community, I’ll tell you that. People will jump on and review and critique and give opinions and go, “Ah, this is not going to work for this case. And what about this plugin that break things for them?” And then after all that discussion, something will be agreed. It’s slowly chipping away and finding a way forward when it’s, “Okay, can’t do this because blah, can’t do that. I’ll maybe try that. Okay, that works. That works in testing. Let’s try it.”

And the good thing about Gutenberg, about the plugin and this process of working experimentally is that you can merge something into the plugin and try it out, review cycles. And then get feedback from the extremely vocal and passionate community that we have, which I’m super thankful for. It’s great to be working on a project and have people just go and, “Oh, that’s amazing,” or “Oh, sorry, that doesn’t work for me. We really need to do that instead.” And you always know where you are. You know, “Okay, I’ve done this thing. That worked. Well, maybe that didn’t work so well, we’ll need to iterate on it and do something else.”

Birgit Pauli-Haack: But sometimes it can be a little tedious, I give you that. But I think the product gets better for it when everybody starts, opens the listening ears and kind of see, “Okay. Yeah, that’s certainly valid and I see that use case. And let’s see if we can include it into the design and into the feature.”

Isabel Brison: Oh, yeah. For sure. And because no one person knows everything, you build a feature, you have your own view of how that feature’s going to work. And then someone else has a completely different view. And it’s by getting a lot of different views that we manage to do things that lots of people can use in different ways.

Birgit Pauli-Haack: So that answers some of the questions, but maybe not in that way those who ask those questions actually like it. Maybe they just want somebody to blame or something like that. I don’t know what motivates that kind of question.

Isabel Brison: I don’t know. And sometimes things are subjective. And working on layout-related features, I can tell you that everyone has their opinion on how it should work. And sometimes opinions are clashing because one person thinks it should work this way and another thinks it should work that way.

Nobody’s right, nobody’s wrong. We just have to try and figure out which approach is going to satisfy the majority of use cases. It’s impossible to build a tool that will do every single thing. So it’s kind of what works best for the most people.

Birgit Pauli-Haack: Alone the decision to have the toolbar on top or on the block. I don’t know if the community is 50/50 split, but some people like the toolbar directly on top of the canvas, and some people like it to be close to the block that they are just editing on. But it could also be situational. And these design decisions, it’s hard. It’s then kind of, “Okay. What’s the design of the feature to change the setting?” It gets you into to the next conversation with other people about a feature.

And so it’s an iterative process and it gets better and better while listening and trying to get it in. So on 6.0, I think we are almost through. We already talked about the Command Center, making the command selectors and actions as well for the public API. And then there is one bug fix that I like to point out, is the fix, the multi-entity, multi-property undo and redo.

I think that is something that really we are waiting for quite a bit that when you highlight something and you delete it and you do undo, you only get one back or two back, but not all of it, for instance. And you cannot redo it because it didn’t have a memory of what the other properties were. And that has been fixed. And it really happened, and it happened to me, and I think it happened to anybody who experimented with multi-selection at one point.

Isabel Brison: Yeah, for sure.

Birgit Pauli-Haack: So this is fixed and I just wanted to point out, “Yay.”

Isabel Brison: Yeah, that’s a great fix. Really needed.

Birgit Pauli-Haack: Say again?

Isabel Brison: Really needed, as in a necessary fix.

Birgit Pauli-Haack: And I think that was it from the 6.0 release. 

What’s in Active Development or Discussed

So that brings us to the active development or What’s Discussed section. And I had the idea to actually go to the roadmap of 6.3 and look at things that will make it into 6.3 and two and what’s not done yet. But there are a lot of links there. And we definitely know that the new blocks’ table of content footnotes are probably not going to make it.

There is also the introducing UI to safe patterns or all the things around patterns. I’m a little bit doubtful that we see some of the additional equation flows for patterns in that, what’s on the roadmap and what already happened but it’s not part of WordPress 6.3, is the curation filter in the pattern directory. So some core contributors went through the public pattern directory and created a few patterns as well under the WordPress moniker or user account, and then added that.

So when you go to the pattern directory, you now have not only the categories there, like header or buttons or text or images. You also have a dropdown to select between curated and community. And the curated are the best of the best. Some of the community contributors or WordPress contributors think that those should be highlighted a little bit better or higher or are created by WordPress core contributors.

So that filter is available now on the pattern directory. It does not yet seem to make it into the pattern inserter that you can do that. But that is definitely on the roadmap, but it’s not yet done. So I think that the stabilization and usability of the toolbar, the list view and the link control UI, custom list views and library management, those things are almost done going into 6.3. But there is the box shadow component. I think that has already been merged from the design tools. No, that hasn’t yet.

Isabel Brison: Yeah, I think so.

Birgit Pauli-Haack: That hasn’t yet.

Isabel Brison: It hasn’t? Oh.

Birgit Pauli-Haack: Well, the box shadow that you can attach it to all the blocks I think is the one. There are box shadows enabled for certain blocks.

Isabel Brison: Yeah, got it. I’m not 100% sure of the status of that.

Birgit Pauli-Haack: And the style block is exposed in the style preview, I think, and details.

Isabel Brison: Yeah. There seems to still be an active tracking issue here.

Birgit Pauli-Haack: So it takes a little longer. I think we make this for once we know when beta comes in, what is actually in the release of the features that made it. So in two weeks, when 16.1 stable comes out that’s passed the beta one release, I think our Changelog, the show will go through the roadmap and check off all the things that come and didn’t make it into 6.3.

And then we have a better conversation than doing it now in just projecting or estimating. And I’m very bad at predicting. My crystal ball is really in the shop, so I didn’t know where to go with that.

Isabel Brison: Predictions are always hard. And I think you kind of have to be in-depth knowledgeable about the work that’s being done. But if you’re just looking from outside and trying to have a bird’s eye view here of seeing what’s going into the release, it’s impossible.

I just have to go and ping people what I’ve been doing these past few weeks going, “Oh, hi. What do you think about this feature? Will it make it in? Are you happy to continue working on it? Is it mergeable within the next week or so?” That kind of thing. And so essentially, it’s a whole process of just talking to everyone and trying to figure out what stage they are at with the work and what I can help with, that sort of thing.

Birgit Pauli-Haack: And I think an indicator is… And I will share the link to the project board for editor task on 6.3, so we all can follow up on that and see how that is. Because that’s updated quite a bit between the editor triage team and the core leads tech teams. So core leads.

Isabel Brison: Mainly what I’ve been doing on the board is adding in PRs for back ports to core. I see that there is a bunch of stuff in progress and needs to review columns in this board. I’m not 100% sure of the status of some of these. Some of these PRs definitely, I think, at this point it’s unlikely that they’ll make it in.

So the fact that it’s on the board doesn’t mean… And even if it’s marked in progress, it doesn’t mean that it’s actually going to make it because it can just be a PR that’s been sitting there for a while and it’s on our wishlist. We would love to do it. But if no one’s actually actively working on it at this point, then it’s unlikely to make it.

Birgit Pauli-Haack: And I know that at the editor triage team, we are going through that as well and kind of figure out what comes in as issues from the testing parts of those. So to be sure the features that are in the Gutenberg releases 15.2 to 6.1, if they are not labeled as experimental, will make it into 6.3. So going back to the previous releases of Gutenberg, you can pretty much predict, “Okay, this is going to be in there.”

What will be hard is to find out, “Well, you will be at 6.1, the release candidate will be next week.” And that kind of closes the feature freeze pretty much for 6.3, unless there’s something that is pushed through as a placed task by several core committers to say, “Yeah, that can make it and that will go in there.”

All right. Well, this was a long show today. Thank you so much for staying with me, Isabel, and providing so much great insights in the development and the design process as well as the release process. Is there anything that you want people to know about 6.3 or Gutenberg project that you are excited about?

Isabel Brison: I think we’ve pretty much covered most of the things about the general processes. I’m pretty excited about the changes to the site editor and new improvements with browse mode. I hope everyone else is equally excited. I think this is going to be a pretty good release. Thanks for having me. It was a lot of fun chatting about this.

Birgit Pauli-Haack: So if people want to get in touch with you, how can they find you? What would be a good place?

Isabel Brison: I am on GitHub as tellthemachines. I am on WordPress Slack as tellthemachines also. So ping me on Slack. I’m usually online during the week, Australia time.

Birgit Pauli-Haack: All right. Well, thank you so much for being on the show. And I want to point out, we have a Gutenberg Times Live Q&A coming up on July 6th at 17:00 UTC. And that’s about using Gutenberg scripts and components to revamp a plugin. It’s a case study and we are talking with the lead developer and the tech lead from GiveWP that have worked on their 3.0 revamp.

And they have used most of the Gutenberg components or based it on WordPress components and scripts. And it opened quite new perspectives for them. So I am really excited to have Jason Adams, the director of development and Jon Waldstein, the lead developer of GiveWP on the show on July 6th, 17:00 UTC. I will share the link in the show notes.

Reserve your spot. And it’s a usual live Q&A where we have some demos, and then we talk a little bit about the project and then we answer all the attendance questions.

As always, the show notes will be published on gutenbergtimes.com/podcast. This is episode 84. And if you have questions, suggestions or news you want us to include, send them to changelog@gutenbergtimes.com. That’s changelog@gutenbergtimes.com.

Thank you all for listening. I’m looking forward to talk to you again in two weeks. Thank you, Isabel Brison. And I am so happy to have another show for you. That’s it.

Isabel Brison: Yay.

Birgit Pauli-Haack: Bye-bye. You take care.

Isabel Brison: Bye.

Birgit Pauli-Haack: Bye.

Leave a Reply

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