Changelog #41 - New co-host Greg Ziolkowski, Gutenberg 10.3, Updates on Full-Site Editing MVP

Gutenberg Changelog

00:00 /

In this episode I discuss Gutenberg 10.3, updates on Full-site Editing MVP and Block Patterns with my new co-host Greg Ziolkowski.

Music: Homer Gaines
Editor: Sandy Reed
Logo: Mark Uraine
Production: Pauli Systems

Show Notes / Transcript

Show Notes

Grzegorz aka Greg Ziolkowski

How to build a plugin for user to create categories and assignment them to blocks and sort Block Inserters

Talking Full Site Editing with Matías Ventura

Plugins

Conditional Blocks by Morgan Hvidt
Block Visibility by Nick Diego

Gutenberg 10.3

Block Patterns

Full-Site Editing MVP

Did you like this episode? Please write us a reviewhttps://lovethepodcast.com/gutenbergchangelog

If you have questions or suggestions, or news you want us to include, send them to changelog@gutenbergtimes.com.

Please write us a review on iTunes! (Click here to learn how)

Transcript

Listener Question

Birgit Pauli-Haack: I think our listener question for the show is really good for you. So, long-time listener Peter Ingersoll sent in a comment and a question the other day, and he asked about a plugin he’s looking for, and I quote, “If that plugin allowed me to create new block categories, assign blocks to those categories, and then order them, for instance, my selected favorites always to be on top of the inserter, I would be very happy.”

So my first reaction was, no way could such a plugin could exist, but I’m not quite sure. So is there a hook to filter available to tab into the block categories to manage them? Or is there a hook to order the blocks in the inserter? What do you think, Greg? You’re so close to it. Would this even be possible for a developer to produce the plugin?

Greg Ziolkowski: Sure, that’s very interesting that you ask that. Even more, I think last week there was a PR to add a new category to the block editor. And this category will be called Theme, and it’s related, of course, with Full-Site Editing work. And what’s interesting about the way plugin is structured, like Gutenberg plugin, is that it’s built on top of the WordPress core. So, we need to have hooks to be able to do that, even there then it’s added to the core. So of course those hooks exist.

And at the moment, there is PHP hook that is called Block Categories, and it allows you to add your new categories or remove existing categories. So, the interesting part is that I think like two major releases of WordPress before we removed the enforcement to use any category. So, you don’t need to define any strict categories. You can do whatever you want. However, if you don’t provide a name, they are listed as uncategorized. So if you provide those names, then you will have them in the editor.

So in your case, if you care only about two or three categories, you can remove all other categories. I don’t even remember if changing the order will be applied also for core categories. They might be moved further up just to make sure that they are the most prominent. And just to continue, because that’s not the only thing you need to do because if you have existing blocks, and you don’t like the categories applied, you need to use either PHP hook that hooks into block registration, and it’s called register_block_type_args. And on JavaScript site, there is a similar hook called register_block_type. So, you definitely need to check documentation and look for details, but all you want is probably possible.

Birgit Pauli-Haack: OK. So if you’re a plugin developer and up for it, this might be a good test case to help somebody out who has a clear interest in doing this. And I’m sure that other people would follow once they know that will be available.

Announcements

Which brings us now to the announcements section of our show. And I wanted to point everyone of our listeners who are podcast listeners to listen to another podcast, which is the WP Briefing. And for this week, Josepha Haden Chomphosy invited Matias Ventura, who is the lead architect from Gutenberg and has been working there for five years, and they were answering quite a few questions from the audience. And what I wanted to find out was what is the state of MVP of the full-site editing that will come soon? Greg what did Matias say?

Greg Ziolkowski: So first of all, they discussed what’s going to be included in the upcoming WordPress 5.8 major release. They also discussed what could not be included in there. So they are still discussing what’s the best way to approach Full-Site Editing. And as far as I understand, it looks like only, or some fundamental parts of Full-Site Editing would be included in the upcoming release. However, it’s still being discussed, so it might change.

Definitely, there are some areas that are in a very good shape like Global Styles that I’m feeling very positive that will be included. And also, I checked with other folks involved like Andre, who is championing the efforts for the Widgets screen, and it’s looking very close as well. So, you definitely need to watch this space. I don’t remember what are the dates to decide what’s going to be included, but Birgit, you can help me here.

Birgit Pauli-Haack: So the decisions to recap the last three or four weeks of posts is the decision to make what comes into 5.8. The go no-go, I found out is not go no-go for Full-Site Editing as a whole. It’s more, which part of that section would go in and which are not. And the decisions will fall on April 17. That coincides with the release of Gutenberg 10.4. Then it’s kind of in that week until April 23, which is the release candidate for 10.5, which should already be out. And that’s the week when the decision falls.

Greg Ziolkowski: Yeah, one thing that is sure that Full-Site Editing is going to be optional for the start. So only themes that would mark them as a Full-Site Editing enabled would trigger all the mechanics behind that. So that’s very important. It’s not like in the Gutenberg editor first release that it was the default experience, it’s not going to happen for sure. So that’s, I think, very important in this context.

Birgit Pauli-Haack: Not all of it is, however, opt in. Yeah. So for the themes to work with the site editor screen, that a user can modify their own headers and put additional templates together, that’s all in the site editor. That is definitely opt in. The theme needs to support it. And when a theme supports it, then you get additional menu items, site editor. But the opt in for the widget screen, that is actually, if it comes into 5.8, it will take over the current widget screen that is in WP Admin and also work in the customizer. So that’s definitely a thing people would need to test, especially theme developers and plugin developers who have widgets in their plugin, to make sure that that works with the new widget screen that is right now experimental in the Gutenberg plugin, but it might come out of experimental in the next one or two releases.

So that’s kind of a short rundown on the state of MVP. Matias also said the MVP should make it possible to build a version of Twenty Twenty-One theme using only blocks without any coding knowledge. So that was the scope that Josepha published and Matias reiterated that that was still the scope of the Full-Site Editing for 5.8 right now, provided the decision to move forward comes in the mid to end of April.

Community Contributions

All right. For community contributions, I found a plugin called Conditional Blocks. It was built by Morgan Hvidt. And it allows to create a block that are displayed when certain conditions apply. And we saw other plugins like that. One of them is called Block Visibility from, I think it’s Nick Diego. There are others that are part of a bigger plugin. But this one is a little bit different because it allows you to change the content, for instance, depending on the HTTP referrer.

And if so someone comes from Twitter, they could see a different message or a different section of the website than someone coming from a Google search or from a link in a newsletter or an affiliate link. So you can granularly very much decide as to when to show a block according to those conditions.

The plugin is also available as a pro version with of course premium features. And you can find them on conditionalblocks.com, or you’ll find the free version, definitely in the WordPress repository. It’s a fun project. So check it out, especially when you want to do more personalized websites or at least content display.

Greg Ziolkowski: It sounds really nice. I mean, it gives you so much power, which by design isn’t exposed at the moment. I guess in the future, we should expect seeing more features like that built into the editor to give more control, especially if you have different roles in the context of Full-Site Editing. You’d expect to have a bit different behavior when you are the designer, and when you are an editor, things like this. But this is on a much higher level of complexity. I like that one.

Birgit Pauli-Haack: I think that part, I hope, will always be kind of plug-in territory. And really, you’re right there, if you can change the header or the block that shows up in the header, depending on this plugin or on the conditions where somebody comes from, it makes a much better encounter than to just have everybody see the same thing.

What’s Released – Gutenberg 10.3

So that brings us to the Gutenberg 10.3 release. And Greg, you were the one who did the release work on it and also organized the release notes. So what stands out for you on the new release of Gutenberg 10.3?

Greg Ziolkowski: First of all, this release is like so huge that it took me one day to compile those release notes. And I think that’s a lot of work being put, especially in Full-Site Editing efforts. So I counted over 200 PRs merged as probably one of the biggest to releases ever.

Enhancements

And I think that we can start with enhancements because there are a few of them that are worth highlighting. I mentioned a new category called “Theme”. That’s also used now with the template parts block in the inserter.

So there were also three changes to the block editor and I wanted to highlight improved block inserter keyboard navigation. So there’s like a further work going in this direction to make the inserter more accessible.

And we also had a couple of changes in the block library. One thing that I like is that you can now use drag and drop in the media placement for the Cover Block. And maybe I should start with that one because there is an effort to standardize the groups in the block toolbar. So before, you could have like a single buttons with this borders that were like, they were not organized in a coherent way, and it’s now all fixed for most of the blocks. I suppose it’s all of them already. And it groups that was like, there is a block group, there is a rich text editing section, and there is also like another group, I don’t remember the name. But it gives you just a better experience for the user because they can easily find what they’re looking for.

Birgit Pauli-Haack: Yeah, that’s always good. And we appreciate it from the documentation team very much, so we can streamline our processes as well. We did some rewrite or reorganizing of a theme once the more options from the toolbar, the three dot, the more options menu was finally standardized. And now we have one page with those options have to explain everything and every block documentation just links to that. And that is definitely a good outcome here from this one. Yeah. But it takes a lot of work to get through all that. Yes. So what else?

Greg Ziolkowski: Oh, definitely. And also for the Verse block, there was support added for the padding. And it’s like, this is related to full-sided, I mean, to Global Styles project. And there are a lot of changes like that happening recently just to bring also some similar experience for many of the existing blocks. So with Global Styles, we should see a lot of those tools exposed pretty soon.

And there is also one enhancement that by default, we are now using the settings from the servers for the image default size. It was missing. It’s quite surprising, but whatever you set on the server now it’s used also in the block editor.

APIs

And there is also a sections with new APIs. So there are only two items. One of them is quite interesting because that there is a new React hook that you can use whenever you want to copy something, so it simplifies a lot. So you can just use a button and apply this hook and it will take care of everything for you.

Birgit Pauli-Haack: Excellent. Yeah. I do this quite a lot that I copy paste blocks from one section to the other. So yeah, I’m glad that’s now also available for plugins and themes, plugins more.

Bug Fixes

Yeah, big release. Also had 35 bug fixes that are divided in a few sections. I’m not going through all of them.

One of them is that the sibling block inserter is now finally displaying at the end of the block list. I’m just saying finally, because that was the first issue, or one of the first issues that I had with the Gutenberg plugin that at the bottom of the screen, I did not get an inserter. I needed to use the enter key to kind of get a next block. So finally, we have it. Yay! But it’s also good because it needs to be used at the site editor as well as the widget screen. So finally we got everybody involved to do that.

Greg Ziolkowski: I guess we are going a bit back and forth with that one because I remember we had that before, but it was removed.

Birgit Pauli-Haack: Yeah. I think that the more use cases you have and the more you reuse certain components, you get a full picture of what is needed. What they reverted in this release was showing the empty paragraphs on the front end. That was kind of surprising for a few. So that is reverted. And then the bug fixes now that they are showing the active block variation icon in the select mode. So when you have in the sidebar, you see all your block variations who are in the placeholder, so you can see which one you are actually using.

What else? The embed. It just got to get my attention because this line item had the word overzealous in there. And because they fixed the overzealous aspect ratio scaling for embeds and also select fix the focus on it, the imagery size for external URLs works now. So when you have an image that had an external URL, you’re also able to resize them and then the social links received more accessible labels. So accessibility, always a work in progress, but it’s always something very important.

Greg Ziolkowski: It’s a lot of work.

Birgit Pauli-Haack: Yeah. Well, but it’s important. Everything is a lot of work.

Greg Ziolkowski: It’s never enough. Yeah. Especially in very complex applications, like the block editor is.

Birgit Pauli-Haack: Yeah. Sometimes I can see that if you haven’t decided yet how you actually approach a new feature, yeah, is it by click, or is it by keyboard. And then if that is not finalized, you cannot make an accessible access to it either. So I can see that some of it is behind and some of it is advanced.

And Greg highlighted the Gutenberg plugin update, which requires at least 5.6. So that formalizes something that was in the last few releases in there that it wouldn’t work if you had WordPress 5.5 installed or 5.4 or 5.0.

Greg Ziolkowski: Yeah. I mean, it’s quite important because you could install it with the older version and it would just break and it was a bad experience. Now it’s fixed. And there is also another fix going in the next few days that will ensure that if you have Gutenberg installed on the older version and it wouldn’t run properly. So I don’t remember the use case, but it’s also erroring there.

Birgit Pauli-Haack: I think when you have a plugin and these two things, it’s kind of tested up until, but the notification of an update available will not come when the accompanying WordPress install isn’t in place. So you will never get the updates. If you’re on 5.5, the updates for Gutenberg announce. So this was definitely a good thing.

Performance

There were three performance changes or add-ons in there. One was inserting the block patterns in the browser’s idle.

Greg Ziolkowski: I can explain what was wrong.

Birgit Pauli-Haack: Yeah, please do.

Greg Ziolkowski: Because those patterns, they contain HTML code that needs to be parsed by the block editor engine, it takes a lot of time when there are multiple patterns that are huge. And that before happened on the moment when the block editor was initialized, causing delays. So you would wait more to see your initial screen. And it’s now fixed. It happens somehow in the background and it resolves this issue.

Birgit Pauli-Haack: Patterns that are on the site need to be parsed when the block editor is loaded or doesn’t have to be parsed. Now they changed that to decide if it’s a block pattern that can be added to that particular screen. And before, they did it on load of the block editor. So it took a long time till you the block editor was ready for you, and now it uses the browser idle state to do some more work. Does that work for you, Greg?

Greg Ziolkowski: Yes. That’s exactly that.

Experiments

Birgit Pauli-Haack: So that brings us to the experiments, Greg. There’s a lot of it there. I think there were 77 line items for experiments.

Greg Ziolkowski: Yeah. I guess there is more because some of them are grouped. Yeah, anyway, it’s like huge change, so you see that Full-Site Editing is the main focus at the moment, and that’s also a lot of contributions happening there.

And first of all, I want to mention the customizer. There is now, you can use the block inspector inside this narrow sidebar, inside the customizer. It’s nicely integrated with some design niceties. And yeah, I hope that this will be brought to the mobile experience like narrow mobile view experience as well.

And we have also twin blocks that are like low level blocks, but are very important when you want to create a theme. So those are login and logout block. There is also a query title block, and which has a special variation for the archive page. I guess there is more of those variations coming like for the taxonomy page or category page. And there is also a term description block. So you can feel it’s like the direction is to add all those helpers that themers use as of today and have them and called it as blocks.

Birgit Pauli-Haack: So especially the last one, a lot of theme developers did not add the categories or the description from categories to the archive pages, and the users didn’t have any, unless you know code, had any way to actually add the description to the archive page, unless it was built into the theme, or it was built as a plugin. And now you just add a block to it, and then you can add the description. And that’s just phenomenal. Easy way to do that. Yeah.

Greg Ziolkowski: Yeah. It will be only better with block patterns because you can imagine that you can have a pattern for a category page and it just like fills everything for you. Also, there is work that’s quite a big feature and a change in the way how block editor works. There’s an experimental layout of it. It’s now used to with the post content block. So the idea is that, before when you had a post content, or you would use full or wide or a regular alignment. However, in the context of Full-Site Editing, it doesn’t scale well, so there’s ongoing work how to improve that and give you more flexibility. Have you build your layout.

Birgit Pauli-Haack: Yeah, because you definitely need more levels of nesting.

Greg Ziolkowski: Like you can have a column and another column, and inside you can like what’s full in those contexts, or what’s wide. It’s hard to define, because it no longer applies to the full width of the page. So that’s why it has had to change.

There’s also one that I found very interesting and intriguing. It’s a first step towards hybrid themes. And there is a fallback to PHP templates. There were several requests to use PHP extension for templates in Full-Site Editing themes. And it looks like there’s a different proposal here. So rather than use this extension, just let themes to cascade to PHP templates that are defined. I don’t know if that’s going to be in the final release. However, I find it very interesting that those types of explorations are happening. I think last time I talked about that with the theme, that challenge here is that it’s very hard to build hybrid themes in terms of the good user experience, because suddenly you have two concepts mixed and like the questions, how you even like show good indicator, what you are editing at the moment.

Birgit Pauli-Haack: Yeah, I get it. Yeah. But it’s also, a lot of theme developers have this anxiety that they create a great theme, and then with all the tools, the user kind of mocks it all up again. Yeah. There are certainly certain guard rails. But if they can just open up the normal PHP theme that they have built and just add a few sections that are addressable through the site editor, I think that’s quite an intriguing, as you said, idea and Ari, I think, pushed that forward.

And yeah, really, I want to try this out, how that actually works and what pitfalls are there. I understand that that’s completely experimental and it might not work at all, but how would you know? You need to push it over the finish line and kind of see how it works.

Greg Ziolkowski: Yeah, exactly.

So another thing is that now there are block of variations for Template Part blocks. So the idea is that you can search for header or footer and they show up as a block and they are previewed with some settings that optimized for the use case. There is also a lot of changes to Global Styles. And the most important is that you can use now any styles in the theme JSON file, whether or not the block supports it. So before, if a block wouldn’t opt in for support for some setting, it wouldn’t be allowed for the block. However, this changes that the theme editor has this power to put some additional features to the block.

Birgit Pauli-Haack: Oh, yeah. So an example would be if a block wouldn’t do a wide align or a full align, I can now as a theme developer force that block to actually kind of spread out over the full page or the full column. Yes!

Greg Ziolkowski: Yeah. I don’t know if align works this way, but definitely anything that has something with CSS, like colors or padding and stuff like this. Yeah. I think that’s all for Global Styles. Let’s go to navigation editor and block.

Birgit Pauli-Haack: So there are two things with the navigation. One is the navigation screen that will replace the menu screen that you have in your WP Admin, and then the Navigation Block, which you would put into a header and footer or around the … yeah, you could even use it now on an on-page navigation. And there are many, many changes to that. A lot of fixes. And there’s a great team now working on it to push that as far as possible in terms of 5.8.

One of them I like really much, is that it now enables a list view. So you can see what kind of block are in the navigation parent block. Because you can put in links, you can put in images, you could put in, there’s also a page list block. That’s a variation of it. And there has been quite a few fixes. You could even have a paragraph block in a Navigation Block.

Greg Ziolkowski: Yeah. And you can have several levels of nesting, which is the most important factor for introducing this list view.

Birgit Pauli-Haack: Yeah. And so the list you really helps you kind of identify the right level of menu and items, yeah.

The Widget editor also has been, apart from the integration to the customizer, also needed new and additional rest API endpoints. And that’s quite a big PR. And it finally landed. And yeah, what else is there?

There’s a unifying menu for the item styles, menu items styles for the block. And you can now use sans-serif on the widget screen. That’s the default now. So sometimes those changes are little and sometimes the changes are big.

Documentation

Which brings us to the documentation section of this release. And there are 12 changes and the Gutenberg handbook, however, got quite a few.

And one of them is that the block design principles have a new section. That’s the Group controls, how to group the controls in the sidebar, in any of the tools. And then one is also an update of the quick view image on the documentation homepage. So when you go to wordpress.org/gutenberg, you see all the screen items that are not just the post editing, but also the inserter and the sidebar are now in the image, yes.

Code Quality

Greg Ziolkowski: And I think that brings us to the code quality section, which has 18 items. So first of all, I wanted to mention that there is an active proposal to start using TypeScript natively in the Gutenberg code base. And as part of that effort, there is ongoing work to add those types using only JavaScript. And we have two more packages now that ship their own types, which helps developers to use those packages if they opt in for using TypeScript because they add a very nice code completion hints inside the editor.

And there is also several block editor changes as usual. So those changes are to make sure that the DOM of the block editor, like DOM representation, isn’t growing. So also it ensures that the performance will be optimized in the future, or we use less CSS classes so we can remove some styles and stuff like this.

Tools

There are also changes to the tool and there are nine of them. One of them is quite important for the releases. So I was seeing the release these this week, and it was a really nice experience that you have UI on the GitHub and you just need to type some keywords, and then the process starts, then everything’s generated for you, all the comments like, “It’s like it’s magic happening. They did amazing job there. I loved the process.” It’s hard to learn that, but once you get, you never want to go back to what was before.

Birgit Pauli-Haack: Yeah. Yeah, I understand. So just to get back to the adding the TypeScript proposal, it does not indicate that Gutenberg is now going totally TypeScript. You can use normal JavaScript. It’s just that some of it is created in TypeScript and especially the package, are you rewriting all the packages in TypeScript, or you’re not rewriting it there?

Greg Ziolkowski: Oh, no, it’s not happening. The codebase is too big. Also, it doesn’t make sense to start refactoring. So the idea is that it helps a lot to have those typings in low-level packages. So not like block editor package or block library or the edit post page, not this higher level that you have them very often. Most of those release notes are related to those higher level features. So this is only about framework-ey staff, as you would call it. And it just helps to keep the code quality on a higher level. It allows you to catch issues early. And it’s more about long term maintenance improvements rather than changing the language. Like JavaScript is staying there. The language TypeScript is just to solve a certain type of issues.

Birgit Pauli-Haack: All right. OK, thank you. And we will have a link to the proposal on ‘Make core Blog’ in the show notes, so you can read up about it and dive into it right there.

Greg Ziolkowski: There’s also one more thing I wanted to mention. So there is this create-block scaffolding tool that it’s now requiring by default WordPress 5.7. The update was necessary to enforce the best practices like using a new PHP function called register_block_type_from_metadata, which is using block.json representation. So if you follow that part, it’s quite simple to go from there to sending your block to the Block Directory because it requires this block.json on file.

Birgit Pauli-Haack: Yeah. I started out using the create-block quite a bit, and then I had to troubleshoot something and then of course it fell off the wayside. So, I’m really anxious to get back to it. But to make it work, I need WordPress 5.7? Or I need 5.7, so the plugin would work?

Greg Ziolkowski: Yes, you need 5.7 for the plugin to work with all the latest features.

Birgit Pauli-Haack: That concludes our Changelog for 10.3.

What’s in Active Development or Discussed

We also used to talk about what’s in active development, and we have two things for you. Oh, well, a few things. More than two. But yeah, let’s start with Pattern Directory that meta team is full-steam working on the pattern directory. And it’s a newly built service. And we talked about it here and also on the Gutenberg Times. There was some section here about the pattern directory. But it seems that the team is getting close for the final pieces. And that is the WordPress.org Pattern Directory. Shaun Andrews posted on them on the design team blog the state of affairs, so to speak. And you see that the patterns will be arranged in a masonry gallery. And then when you click on it, you will see more details about it. So check out that particular blog post. We’ll have it in the show notes.

And speaking of block pattern, if you didn’t get a chance yet to work with that, there is a new tutorial out on the wordpress.org news section by Beatriz Fialho from the themes team. And it really shows you how to create those block patterns. And I appreciate that tip that she also said that you can use any block for your pattern, including the blocks that came from a plugin. So if you have a testimonial plugin, a block from a plugin, or a better gallery block from a plugin, you can add that to your block patterns. She also writes that if the block is in the block directory, you will be prompted to install it on one click if it’s missing from your self-hosted WordPress.

Now I found that a bit confusing, but I clarified it with Kelly Dwan, she’s working on that team. And the Pattern directory will only be allowing, for now, core blocks to start, but will eventually also allow blocks from the block directory. However, the pattern that you make for your theme or your site that are not hosted in the directory, you can have any block in there. It will just not have that one installed click when the plugin is missing on a site that uses that the pattern, or wants to use it that Beatriz mentioned.

So, yeah, I’m really excited about that block pattern, all kind of … it’s easy to do, and the users really appreciate that they can certainly replicate something that you built from core blocks or from a plugin blocks with the background and the topography and the image with it, and the size of the image, and left or right as line in an image or something like that. But if you can give them a one-click, this is how it looks and over and over again, it’s certainly a much better design experience. And as a theme developer, this is actually a great opportunity to make blocks, kind of design them in combination, combination of blocks, and adopt the design for it. I think that’s what users really will appreciate when they… And what a lot of theme developer developers already do with their layout. But now you can do it in blocks much better or easier.

Greg Ziolkowski: Yeah. I love the idea of block patterns directory. I like that it builds up on a block directories like those in the future would be like a unified experience. So you install a pattern, install all the missing blocks, like the future is really appealing.

And what I want to mention here is also that we are looking into integrating block patterns into blocks. Let me explain that. The query block is in active development. So it has this integration with block patterns. So that would be like the next step in this direction, that you could register block patterns that are only targeting a given block. So it’s like it’s building an app inside an app. And the nice thing is that the UI that the it’s explore at the moment, is like browsing the gallery on your phone. So it’s almost like you can swipe left, right, and pick the pattern that fits the most your use case. So that’s very interesting how all the concepts interact with each other.

Birgit Pauli-Haack: Yeah. I think those block patterns integrate them into the placeholder kind of section, I think we have that from the beginning for the columns where you decide, to a one to two column or three column. And if I have a two column, is it a 50/50 split or a 70/30 split? But that was a very early … it wasn’t even called block pattern yet. But now with the, especially the query block, the query block is not something that a normal content creator is actually going to assemble. It’s the theme developer and the plugin that gives those query blocks a design for it. And then that’s what the content creator is adding to a page or post. So yeah. But thank you for that. It’s going to be quite a bit complicated now. It’s not the classic editor anymore.

Greg Ziolkowski: Yeah. It needs to be simple for users not for the developers.

Birgit Pauli-Haack: Simple means it’s complex to make it simple.

Greg Ziolkowski: That’s the goal.

Birgit Pauli-Haack: Yeah, that’s the goal, right. Yeah. That you hide the complexity and it’s intuitive, but sometimes that takes a few runs at it. The next thing is there is some WordPress 5.8 release planning going on?

Greg Ziolkowski: Yeah. I think Francesca Morano posted a timeline for the WordPress 5.0 release. We briefly mentioned that before. So there is a date now, July 20. It’s a bit to change in the schedule, because initially for this year, we planned four releases, and anyway, there were discussions that it doesn’t work well for the community. So they decided they will do only three releases this year. And so the one happening 5.0 would happen in July. That may still change. Because it depends on the decision, what goes from the Full-Site Editing project.

Birgit Pauli-Haack: So the future freeze will be planned for May 21, given the July 20? And then it has two weeks. It’s also changes how feature freeze embedded beta is coming together. Up until now, beta one was feature freeze, but now feature freeze is about two weeks earlier than beta one. So those who test things are testing also the bug fixes. So a beta is not the start of testing the bug fixes, it’s kind of really only testing the release that is in there. And yeah, it’s kind of interesting.

So the Full-Site Editing will have between April 23 and May 25 to get all the bugs out when it’s a no-go or for the features that are a go for 5.8 or the sections. First beta will be June 8, and then first release candidate will be June 29. That’s the plan, right?

Greg Ziolkowski: Yeah. So, the process from beta is almost the same as before, but we have this additional two weeks for polishing everything before we merge everything to core.

Birgit Pauli-Haack: Yeah. So, and there’s Global Styles. I think we mentioned some of it already has been discussed quite a bit. The few things like the layout configuration that we mentioned with the theme.json. Andres also mentioned that there is now support for child themes in the Global Styles. So the editor fetches the theme.json of the Global styles, and if there is a child theme, it also looks into that directory to catch the theme.json for that and match it. And it would give the child theme a priority if things are declared differently. If there are mixed signals, so to speak.

Andres also created a proof of concept with having the alignments controlled by the site editor. And there is a testing PR too. So you can use a current theme, both block-based or traditional provide the styles for different alignments. So there will be conflict between those two and then you can use an empty theme that he attached to the PR to test it all out, how that site editor is actually working with that.

Greg Ziolkowski: It sounds like a very complex issue. Like the testing construction is so long.

Birgit Pauli-Haack: But Greg you also told me when we were preparing here that there is now finally the final structure of the theme.json. What was so hard about it?

Greg Ziolkowski: Yeah. So there was a lot of discussion based on the testing done so far. In particular, we have a few experimental Full-Site Editing themes and the structure of the config file was a bit hard to work with. So, there is now an agreement that there is a new structure proposed that is much more flexible. Also, I think it’s easier to scan at the moment. So, I’m positive about the future of that. However, it requires some breaking changes for those existing testing themes, and this should happen in the next few days because that’s the most important part before we can start merging Global Styles code into the WordPress core.

Birgit Pauli-Haack: Excellent. Yeah. If you want to provide the theme.json file for theme developers and 5.8, you’d definitely have to settle on a final structure, definitely.

In the show notes of the show, you will find the PR that discussed the final structure of the theme.json file for Full-Site Editing.

Greg Ziolkowski: Yeah, it’s easier to see the next plan because it’s very complex. And there are also discussions during the last core Dev Chat, and Marius Jensen started the discussion on more frequently merging updates from the Gutenberg plugin into the WordPress core. And I definitely agree with that. We tried doing that in the past. However, it’s so many experiments going on, it might be a bit hard because some of those features that are already in the JavaScript codebase depend on PHP changes. So I think we should try. And next week I promise I will start discussions on how we can improve that.

Birgit Pauli-Haack: Before we end the show, and we are definitely on the end of it, I wanted to point out that there is now the fourth call for Full-Site Editing published, and your task would pay if you so decide to start testing again, is create a header for a restaurant. It’s a quite tangible thing for a use case. And Anne McCarthy has again, made quite some test instructions for you. And this definitely prepares the site editor furthermore, for a future release full WordPress core.

Greg Ziolkowski: And bonus points for using block patterns that you can then publish to the directory.

Birgit Pauli-Haack: All right. Good point. So as always, the show notes will be published on the Gutenberg times.com/podcast. This is episode 41. And if you have questions or suggestions that we should talk about here, changelog@Gutenbergtimes.com is the email address, changelog@Gutenbergtimes.com.

So, thank you, Greg. It was a great show, and it was great fun talking to you about that and having you here. Are you going to do it again?

Greg Ziolkowski: Thank you, Brigit. That was really fun. Surely, I will see you all in two weeks.

Birgit Pauli-Haack: Excellent. And thank you all for listening. And this is goodbye for me, until the next time.

Greg Ziolkowski: Goodbye.