Changelog #51 – Automattic Becomes a Sponsor, new Gallery Block, Theme.json, and Gutenberg 11.4 Release

Gutenberg Changelog Episode 51 Cover
Gutenberg Changelog
Gutenberg Changelog
Changelog #51 - Automattic Becomes a Sponsor, new Gallery Block, Theme.json, and Gutenberg 11.4 Release
/

Birgit Pauli-Haack and Grzegorz (Greg) Ziolkowski discuss Automattic becoming a sponsor of Gutenberg Times and Gutenberg Changelog, Classic Editor, Frontity, Theme.json, the Gutenberg 11.4 Release and more.

Show Notes / Transcript

Subscribe to the Gutenberg Changelog podcast via your favorite podcast apps!
🎙️ Spotify | Google | iTunes | PocketCasts | Stitcher |
🎙️ Pod Bean | CastBox | Podchaser | RSS Feed 

Show Notes

Announcements

Community Contributions

What’s Released

WordPress 5.8.1 RC, final release September 8th, 2021

Gutenberg 11.4

What’s in active development or discussed?

The theme.json horizon by Matias Ventura

Discussion on Twitter and beyond: Building Blocks with JavaScript and PHP

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 [email protected].

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

Transcript

Birgit Pauli-Haack: Hello, and welcome to our 51st episode of the Gutenberg Changelog podcast. In today’s episode we’ll talk about Automattic becoming a sponsor of Gutenberg Times and the Changelog, theme.json, Gutenberg 11.4 release and a lot more. 

I am Birgit Pauli-Haack, curator of the Gutenberg Times, and I’m here with my co-host, Grzegorz Ziolkowski, JavaScript developer at Automattic and WordPress core contributor. Hi, Grzegorz, how are you today?

Grzegorz Ziolkowski: I still feel energized and extremely excited after all the big news shared this Monday in the context of the Gutenberg project. Maybe you should speak first. How have you been lately? Has anything interesting happened?

Birgit Pauli-Haack: Yeah. That’s funny. Yeah, it’s been a wonderful week, though. 

Announcements

I have fabulous news and some of our Gutenberg Times subscribers already know that. People who follow me on Twitter know this, but I’m thrilled to announce that on Monday, August 30th, I started as a developer advocate at Automattic. Grzegorz and I have been co-workers for five days now.

Grzegorz Ziolkowski: Yay! Congratulations. I can’t think of anyone else who fits better for this role. 

Birgit Pauli-Haack: Oh, thank you. You’re too kind. Like many people who responded and shared on Twitter, many are podcast listeners, as I said, and I was overwhelmed by all the kindness in the WordPress community. Thank you to everyone. Sometimes Twitter really shares its love and I took it all in. Well, it was overwhelming, and a lot of people have reached out. And so thank you. 

So, Automattic is now main sponsor of the Gutenberg Times, the Changelog podcast, and our live Q&As and my work working on it. 

Being part of the WordPress developer relations team feels like coming home to me. And I’m deeply grateful for Automattic for offering me that position. The best is yet to come for Gutenberg and publishing with blocks. I’m elated to be part of an astonishing team that takes the worldwide WordPress community to the next journey.

Grzegorz Ziolkowski: Yes, so I’m really glad that you will be able to dedicate 130% of your work time to help people to get to their next level when hacking with Gutenberg. And I’m highly impressed with what you were able to achieve as a volunteer, in addition to other duties that help you to pay the bills. So I can also imagine how much of an impact it will make on the community now. I said there is more news to share. What else has happened?

Birgit Pauli-Haack: Well, on Monday, Frontity announced they joined Automattic too. So Grzegorz, can you describe what Frontity framework is, and how this fits into the Gutenberg roadmap?

Grzegorz Ziolkowski: So for those who don’t know Frontity, it’s a … how they call it? Server-side dynamic framework for headless WordPress sites and blocks. So in some ways, it’s similar to Gatsby for those who know the space of headless or decoupled WordPress. The biggest difference is that Gatsby, it’s a static site generator, which means it generates HTML files, JavaScript files, and it just runs on your server, so you don’t need Node.js server, whereas Frontity uses Node.js. 

So it allows you to create a sort of front-end theme that is for WordPress, and that’s run in Node.js. And it uses the content you create including the content with blocks, and it adds some additional functionality to it like nice page transitions. It adds some dynamic features like for images and there are plugins that can apply some changes to that so it’s really interesting. And the best thing here is that Frontity as a framework, in their announcement post, they said that they are planning to pivot their efforts to WordPress core.

Birgit Pauli-Haack: Yes, but so Frontity runs in ReactJS too, right? Not only Node.js but ReactJS, okay.

Grzegorz Ziolkowski: Yes.

Birgit Pauli-Haack: Yeah, no, that’s awesome. So Matias Ventura, he’s a member the developer experience team at Automattic and lead architect at the WordPress Gutenberg project. He wrote that, “I’m really impressed with the effort and care the Frontity team has put into the work over the past few years. We are at a cusp of exciting new opportunities for Gutenberg and I cannot wait to start collaborating together on making the experience of developing with it a joy to behold.” So that sounds like a great pivot for Frontity to just be a framework to actually bring everything into Gutenberg, as you said, yeah.

Grzegorz Ziolkowski: Yeah. So I see it more like they bring their experience. And they will try to replicate some of great ideas they had in the Frontity framework, and find ways to achieve the same goals inside WordPress core, which would benefit so much bigger audience. I’m thinking about developers, but also for users on the WordPress. And I’m also beyond excited about the plan they outlined in the post.

So they said that, “Automattic offered to sponsor our team to work directly on the WordPress open-source project, and in particular, to contribute our expertise in developer experience, front-end tooling, performance and user experience to the WordPress core itself.” So this is exactly what I just said. And actually for me, who is focused around experience with building blocks, it’s really great how this expertise can bring the project to the next level, and our efforts to making full-site editing so performant and optimized for bringing only the assets you need, bringing what’s missing the most now is that the block editors is focused on the WP Admin but on the front-end side, we need more interactivity and more better experience of global sites, the first step but Frontity bringing their own experience can fill the gaps in other areas.

Birgit Pauli-Haack: Yeah, yeah. And I have seen that there are also developer relations people with Frontity, so I’m glad we will definitely be able to learn from them. What I missed early on was talking about the developer relations team. It’s actually now a band of five with Anne McCarthy and Daisy Olsen being there for almost over a year just wrangling the whole thing by themselves. And then Tara King was joined, and then Ryan Welcher and myself, so we are band of five. 

And I think there are two people coming away from Frontity, but I’m not quite sure yet. We haven’t even as a team yet have … because we’re all new. So we’re all in support rotation right now at Automattic and at the WordPress forums. So I think next week is going to be the bigger week where we’ll co-organize everything a bit better. Yeah, so but there’s exciting news for the future of Gutenberg and there’s also some good news for some other site owners, agencies and developers. The WordPress core committers officially extended the support for the Classic Editor plugin all through 2022. 

This gives everyone another year to migrate to blocks. Josepha Haden Chomphosy wrote, “Still, if you have been putting off using the Block Editor, this is an excellent time to give it another shot. Since it first appeared in 2018, hundreds of WordPress contributors have made a lot of updates based on user feedback. And you will be pleasantly surprised how far it’s come.” Of course, most of our listeners know that, about all the huge changes because we haven’t been shutting up about them. But it’s definitely an interesting year now for the Gutenberg project and migrating to Gutenberg because all of a sudden, it has a much better picture of the final version or the final vision. Not the version, it will never be done, but yeah, final vision. 

And also, now that quite a few APIs are settled, there is a great creativity amongst developers and we’re going to talk about it a little later in the show. But on the WordPress Tavern, Justin Tadlock also interviewed core committer, Jonathan Desrosiers. And he had some more details on their approach towards maintaining the plugin beyond 2022. So we will share that link in the show notes like we will all the other links in our Announcement section here, that’s now quite big. Yes. Anything to comment there, Grzegorz?

Grzegorz Ziolkowski: Yeah, I mean I wouldn’t be surprised if there were listeners of this podcast that still use the Classic Block plugin. And this is mostly because you might have a site that is no longer developed and it just doesn’t make too much sense take therefore to migrate that to blocks. So there are always use cases like that. So I’m really happy that the support is extended. But eventually, I think that it would be good to say that it’s only a plugin. And if you want to, just keep it installed, and the community should take over the effort, because it’s a lot of work to keep it up to date. And it’s not something that we want to have forever.

Birgit Pauli-Haack: Well, and funny, you mentioned that. I have quite a few sites, and it might surprise everybody to hear that, quite a few sites that are actually on Classic Editor. We have taken them over about two years ago or some of them three years ago. And the theme is that Franken theme, like where all the plugin functionalities within the theme. And then there are plugin that we could build and separate out. But the theme, it does the custom post types, and then relies heavily on advanced custom fields.

Even they have a blocks kind of building thing, there is no migration work done between former advanced custom field sites to migrating to blocks. That’s one thing. I own this one site where there are thousands and thousands of posts on them that there’s no bulk, reliable way to migrate those over. One site is so old, or that was designed in 2012. So it’s not even responsive now, or the responsiveness is kind of really clunky, but the content creator has used a lot of HTML tags within his postings. And it’s an elaborate layout. Making that into Gutenberg blocks is very, very, very hard. But those are the projects I will be handling sooner or later.

But yeah, there is a good reason to stay in Classic Editor for another year or two or three. But yeah, you’re right. Once in a while, it’s probably needs to be taken over by the community. And there are actually a few plugins already in the repository that go a little bit further than the Classic Editor. One of them is by John Starr, and it says Disable Gutenberg. And it also covers the classic widgets section from that. So yeah, just a little side note, yeah.

Grzegorz Ziolkowski: One question. 

Birgit Pauli-Haack: Mm-hmm.

Grzegorz Ziolkowski: So why don’t you stop upgrading WordPress, like keep it on 4.9 and just take the security updates? Isn’t that the best option to feel safe about the future of the site?

Birgit Pauli-Haack: Well, I think sooner or later that most people would actually appreciate Gutenberg as a user interface and getting block patterns rather than a section of, I don’t know, two pages of ACF Meta Boxes and they don’t have a clue how it looks, as long as they don’t hit preview and see how it looks on the front-end. And so, I think the advantages of using Gutenberg for even a big site that has a lot of layouts would be even better. So a migration sooner or later needs to happen. 

Also, not only for that, but also we have new editors come online, all the knowledge is kind of outdated, or they see it on other sites. And that’s a WordPress skill now, to work with Gutenberg. And now they come to a publication that doesn’t use them, it’s anachronistic. It takes the fun out of it, pretty much. It takes the fun out of me when I need to use the Classic Editor because, “Oh, it would be so much easier to do it in Gutenberg and we can do so many more things.” So sooner or later, we need to think about migrating these large sites.

Grzegorz Ziolkowski: Yeah. So I guess the reason is that you want to stay with the latest WordPress to get all the updates and make sure that the plugins are still compatible, and they also get updates, right?

Birgit Pauli-Haack: Right.

Grzegorz Ziolkowski: Yeah, I mean, it makes a lot of sense. I’m just mostly curious. 

Birgit Pauli-Haack: Yeah, no, I totally get it. Yeah. Especially that-

Grzegorz Ziolkowski: Yeah, I guess we can move on. 

Birgit Pauli-Haack: … I think we have to otherwise we’re getting a little long, yeah.

Community Contributions

Grzegorz Ziolkowski: We can move on to Community Contribution. So I only wanted to highlight two full-site editing themes that I found out about recently. One of them is called Frost and the other one is Aino, I don’t know if I pronounced that right. And they are very interesting. And we’ll leave the links in the show notes as usual. And one of those themes had a very interesting idea because it was like a master theme that had a collection of block patterns. 

So it’s like you have many different target groups in one theme, but you can select that through pattern, which is pretty interesting idea. It’s like a sort of block patterns directory inside the theme, which is something new. I like those explorations in the community that happen right now with all the new possibilities. So Aino is also targeting e-commerce websites. So that’s also quite fine. 

Birgit Pauli-Haack: Yeah. So Aino has been built by Ellen Bauer and Manuel Esposito, I think, the theme developer shop out of New Zealand. And Ellen Bauer was already part of our live Q&As talking about full-site editing early on. And Frost WP is the full name of the site, frostwp.com, started by Brian Gardner. And Brian Gardner has been around the WordPress community for ages. He was the original founder of the Genesis framework, which was then sold to WP Engine. 

And he has started now, with the full-site editing in mind, a new theme base called Frost WP. So both themes are not done by new people. They evolve their own coming from the Classic theme going into full-site editing theme and going in full speed. So it’s really exciting to see them grow and work.

Grzegorz Ziolkowski: Yeah, pretty inspiring to see those full-site editing themes growing. And I also wanted to report that I did my homework, and I caught up with the new Tell Me About Blocks podcast, which is hosted by Michael Schneider. I guess he’s from Germany, right?

Birgit Pauli-Haack: I think Australia, but I haven’t done my homework yet. I haven’t connected with him yet, which will happen. Michael, if you listen to this, expect a ping from me.

Grzegorz Ziolkowski: Yeah, so if you look for inspiration how to build blocks, or extend their capabilities inside the WordPress Block Editor, then I strongly recommend listening to both published episodes. I enjoyed the one with Rich Tabor a bit more because he has outstanding experience in the field and he profoundly understand the project’s visions. So I wouldn’t feel comfortable saying that he’s a representative of the Gutenberg core team and put him on the spot and talk about Gutenberg. He deeply understands how it all should work.

Birgit Pauli-Haack: Yeah, and I followed Rich Tabor from the beginning of his CoBlocks plugin that came out quite early. He built it with Jeffrey Carandang together. Listened to him at the Boston WordCamp in 2019. And he had some great philosophical ideas on how to build blocks in terms of what needs to be in the toolbar, what goes into the sidebar, and how to approach metadata and options data that need to be built into the Block Editor as well and how to handle those. 

So it was quite an interesting way. So he publishes also on richtabor.com, with blog starts about theme.json, about his experience, and what he thinks how everything should work and how it works. 

What’s Released – WordPress 5.8.1 RC

Yeah, this brings us to our What’s Released section, and we have a release candidate for WordPress 5.8.1. And it was released two days ago on September 1st, and it has 41 bug fixes to core and about 20 bug fixes to the Block Editor. Although there are 20 release pull requests as you mentioned before we started recording, Grzegorz, not all of them are part of the bug fix. Some of them are just PRs that need to be added so the other PRs would work.

Grzegorz Ziolkowski: Yeah, so Gutenberg developed so fast that we introduce some technical changes that just are related to, let’s say, code quality, and then it makes it difficult to backport the actual bug fixes. So that’s why it took 20 commits, instead of let’s say, 10 or 15.

Birgit Pauli-Haack: Yeah. So we will share the show notes to the release candidate post on the core Make blog with all the track tickets and PRs that went into it. The release date for it is September 8th, unless, of course, any additional fixes to be made. But that’s expected to be Wednesday, September 8. 

Gutenberg 11.4 Release

And then we had Gutenberg 11.4 release.

Grzegorz Ziolkowski: Finally. 

Birgit Pauli-Haack: Finally?

Grzegorz Ziolkowski: Finally, the Gutenberg plugin.

Birgit Pauli-Haack: Yeah, do you want to start out with what the most important things are?

Grzegorz Ziolkowski: It’s one thing that I marked like we said and big font is the change that converts the Gallery block to use Image block. So it’s a concept of having composed log of several blocks, I mean, two blocks at the moment. So this change is still behind an experimental flag. So you need to go in the WP Admin to the sidebar. And there is Gutenberg, and there is Experiments page, and you need to mark the checkbox and save the settings to enable this new version of the block. 

There are several reasons that were covered with the dev note that we talked about, I guess in the last episode. We will include the link to the dev note. This change is planned for inclusion in WordPress 5.9. So we encourage all the block authors and theme authors to check out this new version, because there will be some incompatibilities. It’s mostly because the markup has changed, and it might break some CSS styles. 

There are also some plugins that do transforms between Gallery blocks to something else or vice versa. So that needs a lot of testing, it was tested extensively already, because it’s a huge change, which brings a lot of opportunities. And the best way to check it out is look at the release post for the Gutenberg plugin, which shows that demo, and it’s really nice. 

It shows how you can move images, you can change every individual image the same way as you modify a single image. So, that’s a great way. You can use drag and drop now inside the Gallery block. It’s just an excellent change. And of course, the plugin authors can do any change they wanted. Usually they can allow you to use other blocks inside the Gallery block, it’s very exciting.

Birgit Pauli-Haack: Yeah, it’s totally … I love to see…. I have experimented with it a bit. And yeah, I like that you can have a different style for each image. So you can have rounded corners for one and circles for a speaker list or something like that. Or each image can have a separate URL now. So when you do a speaker section, that each speaker gets its own link to the profile or the session; just thinking about online conferencing right now, I guess. But it’s really exciting to see how that works. 

I actually tested this PR a couple of months ago. And I was really amazed how it worked quite well with some of the plugins that you mentioned, Grzegorz like CoBlocks Gallery, or others that had a gallery modification. The three ones that I worked with, were quite compatible with it. I know that Glen Davies, who spearheaded the refactor of the Gallery block also did additional testing with that. He tested them with the Jetpack blocks and Lightbox for the Default Gallery & Image Block.

So, I mean, he also made a point in testing the three default themes, as well as Astra and Arbutus. So it’s all in the developer note that he published and which you will find a link in the show notes as Grzegorz said. Yeah, but I’m really excited about this. I think this is such a great way to put a huge photo gallery together and make it work on a website, yeah.

Grzegorz Ziolkowski: Yeah, and just to add more, so now in the Gallery, you can apply image editing, so you can crop the individual image. You can add duotone effects. It’s so powerful because of this change.

Birgit Pauli-Haack: Yeah. And all you learn with the Image block, you can certainly apply to the Gallery block now. And you don’t have to use two different ways on image handling. So that’s definitely an advantage of reducing the cognitive load and expand the horizon a bit. Yeah. So what else is in there? Good. All the next things seem to be like an anticlimax to that. 

Enhancements

But the Cover block now; you can allow an alt text now for your Cover blocks, which is a great accessibility necessity. The Block Lists is now improved, the iframe block, patterns and template previews. So it’s easier to see what you’re getting when you go through the list. What else?

Grzegorz Ziolkowski: There are a couple of changes to Post Featured Image. So it was pretty basic before but now there is support for duotone. They added the scale property, so which allows you to change how this Post Featured Image is displayed inside the block. And as far as this Post Featured Image can fit to the space it has, it can be somehow like constraint and something like that. So there is some contextual help now added to make it clear what it does, really. And there is now, for other blocks, there is font weight support that was added to several blocks, like Post Date, Post Terms, Site Tagline, and the Button. And yeah, basically, it’s a constant effort to add those features to more blocks.

Birgit Pauli-Haack: Yeah, to add more controls to more blocks. Yeah. So I think what I learned with Gutenberg was that well, first, one block gets an extension like the font weight controls, and then once that is finalized, it will be replicated for the other blocks, or other blocks get the support for that, and then it’s tested, how that would work out.

So, I really like that to kind of have additional testing in there before it’s rolled out to all the blocks. Yeah, and that way, the Button block received the spacing support that uses axial padding. So you can have also horizontal and vertical padding for the buttons now within your Buttons block, which is a feature that was requested quite a bit for Gutenberg. And because many, many block suites actually had that built in almost from the beginning, but so now it’s in core. Yay!

Grzegorz Ziolkowski: So this is….

Birgit Pauli-Haack: … Yeah.

Grzegorz Ziolkowski: Yeah, mark, also some changes, because we have those editor feature preferences. And they were reimplemented now on the Widgets page, on the Site Editor page, on the Post Editor page and now they are extracted. And the idea is to have one common interface to use on all screens and share the logic. So that needs to be tested by all the users because there might be some bugs. I would expect that because there is some technical challenges in how to migrate that and store it in the browser. So when whenever you refresh the page, you have still the same settings, they are stored in the local storage.

Birgit Pauli-Haack: When you talk about feature preferences, do you have an example of that?

Grzegorz Ziolkowski: Yeah, sure. So when you open the more menu like the one on the top, on the right side, and then you have fix my toolbar to the top, disable the full screen mode, and things like that, so some of them are present on all screens, some of them are specific to the given screen, but the code that powers that is now in one place.

Birgit Pauli-Haack: Oh, okay. So for all the three editors, it’s all at one place. And if you change it for one, you know where to change things? Is that answer the past or it’s now getting closer to thinking about taking those preferences out of local storage and put it into user metadata or is that still a ways off?

Grzegorz Ziolkowski: Oh, this one is actually in progress for two years or something like that.

Birgit Pauli-Haack: Right, right. But I can understand.

Grzegorz Ziolkowski: So we are aware about this limitation. So the first exploration was to use cookies. And because there is some API already that uses cookies in WordPress. However, cookies have limitations in the browsers. In some of them it’s four kilobytes and in turns out that it’s not enough for the settings that we want to store. So yeah, there is a REST API-based approach that is close to land, but it never happened. And definitely….

Birgit Pauli-Haack: … No, I can see why. Yeah, I can see why it didn’t happen. Because the editors’ screens were not yet finalized. Because many people knew that there will be a Widget screen, there will be a Navigation screen and then there will be a said editor screen. And the other preference were not yet settled completely over all for different editors. So I can see why it didn’t happen. But it was also not kind of clear to me that that’s the reason. Yeah because-

Grzegorz Ziolkowski: … It’s also complex from the user perspective because now it’s the question. So now, you said that you don’t want to have full screen mode. The question is, “If you don’t want to have it only on one of the screens or it should be applied to all screens?” And now we have it in one place, we could consolidate that and give this option that this option should apply to all screens. But that would now like these user-experience questions. 

And there’s also other questions. So once you pick something; now I am on the mobile that have a small screen. Do I want to have fullscreen there, or it should apply only to the desktop? So there are so many combinations that make it really hard to build a good API.

Birgit Pauli-Haack: … Yeah. I imagine. And there’s also the question, “Okay, if we do it for our editor team, but when I’m an administrator, do I want to change that setting again?” Yeah, that’s another level there. So I can see why that hasn’t been finalized. But then if you really want to have your editor screen, I don’t know what Marias Jensen does, he has this plugin where he stores these kinds of preferences, actually, in the user database, how he manages that. So it’s interesting to see, yeah once that’s explored, where it goes. But for this release, all things are now in one interface package. So that’s a big start in that direction.

Grzegorz Ziolkowski: Yeah, but the changes are applied per screen. So when you change the… what is it, your toolbar displayed, it will only apply to the given screen for now. But in the future, it has to be decided and we are looking for feedback. So new listeners, if you want to chime in, just open an issue and propose how you would like to see.

Bug Fixes

Birgit Pauli-Haack: Yeah, I like that. This brings us to the Bug Fix section, and there were quite a few small bug fixes. We are pointing today to the design tools section, which fixes a bug that now allows zero values for those theme.json styles. So the theme.json style generation. So, a quick side note. I had a conversation with a Jason Crist, who is on the theme team at Automattic and he said we need to make a more a … he didn’t say we need but I learned that it might be helpful to say, JSON, when you mean the JSON file, and Jason when you mean the person named Jason. It’s really hard to do this, or you change your name to JSON, like Jason Bahl did, the WPGraphQL plugin developer. Anyway, so what’s up with zero values in the theme.json styles?

Grzegorz Ziolkowski: So global styles it’s like a new specification of CSS written in JSON. And you know that the issue was that it was possible to write the string 0px, like pixel, but when you were providing a number or the string with zero, it would filter it out because JavaScript or PHP would consider it empty. And so, they fixed that and those values are also allowed.

Birgit Pauli-Haack: So like I could open that I don’t want any gradients by adding the gradient but leave the array empty and it would actually disable gradient?

Grzegorz Ziolkowski: Maybe, I don’t know about that basically. But for the field or property, it was quite important. To have padding equal zero is quite common if you don’t want to provide the unit all the time.

Birgit Pauli-Haack: Mm-hmm. Excellent. 

Performance

And that brings us to the Performance section of the changelog, and there is one that now provides a batch function to the data module to batch actions. I recognize the words, but what does that mean?

Grzegorz Ziolkowski: It’s like there’s a new API in the WordPress data package that allows you to combine several actions, which means changes to the state of the application. So that prevents that on every change, you would have re-render of your UI. So it just waits until other actions get applied and then sends the signal, “Okay, components, you can check out for changes now.” So instead of having several renders that most of them would be wasteful, it just waits for the better time for do it. And it’s pretty common technique that I’m surprised we didn’t have it before. And all agreed about that. 

Birgit Pauli-Haack: Yeah, yeah. Okay, good. And does it add to performance gains?

Grzegorz Ziolkowski: Yeah, on the PR did. However, when I looked at that post and the metrics chart, at the bottom of it, I didn’t see any differences. So it’s really hard to see impact of one PR, because there are other that could downgrade the performance. 

Birgit Pauli-Haack: Good, excellent, thank you.

Grzegorz Ziolkowski: In theory, it should make a difference when applied on a larger scale.

Birgit Pauli-Haack: All right, now you’re going to take us into the Experiments?

Experiments

Grzegorz Ziolkowski: Yeah, I can talk about some of the experiments because I developed two of them, I guess. And so one change that we are looking into is when you have these blocks, like Gallery is now a good example. When you turn on the experiment, you have Gallery block and an Image blocks. Sometimes, you go to the Image block, and you just want to apply something to all blocks like let’s say, there’s some alignment option in the Gallery block you want to take the space of the full canvas, or the… how it’s called, a full and wide, or like regular. So it’s like going back and forth between parent and child block, it’s pretty annoying. 

The idea is that you could do two things. One is dock the toolbar that it always is anchored to the parent block. The toolbar is always displayed in the place when you have the Gallery block. When you enable this option, then the alignment would be also actually shared with the child block. From the child block, you could change the alignment or alter the Gallery block. And yeah, this is something for the toolbar control that is already in place. It’s still experimental. We are looking also and adding the same functionality to the inspector control, so all the controls that are in the sidebar. 

For now, there were also new refactoring to bring their groups. So that is also interesting from the plugin author’s perspective because if you have more structured way, then first you will be able to target those groups to insert your controls. At the moment, you can either add it to the general sections like next to all other controls or to the advanced one, which is pretty limiting. And in the future, we think that there will be a lot of groups that have more structured way of handling those controls. 

One exploration is to add dimensions control so I can see a follow-up with the typography or colors. It’s a better way to have these controls distributed and the user experience also would be better because you could easily remember where to find something. And that also brings another possibilities like very frequent requests from the site owners to disable some of the controls, and we don’t have controls over third-party changes. So you could at least disable the group now, and that would be a great way. And usually, that’s what you want instead of doing granularly, just tell that this group shouldn’t be there.

Birgit Pauli-Haack: No, it’s really helpful to have the single block also be part of the parent block toolbar to control those properties over all their child blocks, that’s really great. The next part was the blocks spacing. Now the global styles also have a block spacing gap configuration that you can control through the theme.json file. And it also adds support for the layout to control the gap between blocks. Tested out, global styles are still in the experiments as well. So you need to switch them on. But it’s getting really interesting now that global styles is prepared for 5.9. It’s not clear that it will be in 5.9. But we want to definitely test all those things for the user controls, and especially also to switch off user control.

Documentation

That brings us to the Documentation. There were mostly minor changes to the handbook, but one item got me excited that says, “Alphabetize the glossary entries.” Especially from a higher-level point well, there is a glossary. I looked at the PR and it’s actually the glossary on the core contributor’s handbook that has been alphabetized. So if you ever want to know what a committer is or what CRUD means or what a dev note is, the glossary, and I will put the link into the show notes, so you don’t have to dig it out. 

Well, you can look it up there. It’s quite extensive, and I really like it. Now it’s alphabetized, so you might as well find stuff. Of course, for the alphabetization to work, you actually need to know what the name of the thing is that you look up. So it might be worth reading through the glossary from A to Z is probably a good way to expand on that. Yeah, anything else in that part that you want to point out?

Code Quality

Grzegorz Ziolkowski: No, no, in fact, in the Code Quality section, that is next, there are eight items. But those are also some minor changes that I didn’t find anything to highlight.

Tools

Birgit Pauli-Haack: All right, that brings us to the Tools section. And there are quite a few PRs that have the same beginning, and that is, “Automated Changelog” and I’m really happy about that, because we go through the changelog, and if it’s well organized and structured, Grzegorz and I, we can really work through this quite easily. So you have been working with people there as well or was it somebody … Yeah.

Grzegorz Ziolkowski: Yeah, that was quite a nice team like Dave Smith, Hector Pietro, myself, and Dan Richards. So yeah, we teamed up and everyone contributing in some way. So now the changelog you see in the release post, and also in the show notes we share, it’s mostly automated. So that’s very exciting that you can see everything in this form now.

Birgit Pauli-Haack: Excellent. Yeah. And then there were some changes on the GitHub contributor template, that the form to fill out an issue has been simplified for the bug report with a form template, so you can lead along and don’t miss any information. So it short-circuits the communication line. Once you report it, developers don’t have to come back and ask you for additional information. So filling that out is really helpful and speeds up the process. And you don’t forget anything when you fill out the bug report. 

Grzegorz Ziolkowski: Yeah. It’s a nice change from GitHub, that they provided a way to make this process more like filling a form. So it’s much simpler from the user perspective because they know what they have to provide rather than skipping the previous version, and everyone just ignore most of the points.

Birgit Pauli-Haack: … Yeah, yeah. And it’s easier, you don’t have to remove stuff from the issue template to get it all fixed up. Yeah. No, really good work.

Grzegorz Ziolkowski: Yeah, there’s one more change that I personally find very interesting. So whenever you have a block is parsed, then if the contents saved in the database no longer matches how the block should be represented in the post, there are some deprecation logs in the browser’s console. Most of the users they don’t see, but it’s important for developers.

However, it was after we introduced block patterns that they don’t get updated after they’re created, usually. So those logs started to pollute those browser consoles. So now, they are grouped together. Especially, it’s important when everything went well, so you don’t really have to report that however we do that for the information of the developers, maybe they want to update that. That’s a good reminder, but….

Birgit Pauli-Haack: Yeah, yeah. I can see that the block patterns of course, changed all the time, even in the content and going back to the block patterns, not the same original. But I think that whole process is also a major pain point for developers to get into block development using JavaScript. The deprecation process per se, I don’t know if it’s unstable or it’s just very verbose and laborious. I know quite a few developers have decided to just use PHP for the rendering, and not go through JavaScript for the render, and create dynamic blocks, quasi-dynamic-static blocks, so to speak. And looking is going to be helpful, yeah.

Grzegorz Ziolkowski: In this context, when you are using Cover blocks, and they get new features, and because of that, it requires new HTML markup to represent that, because you have those deprecations encoded, whenever someone inserts the button that was created two years ago, when you insert that into your post, you would get the most up to date version of that block, which is what we want to achieve and that’s why it’s so important. Of course, when you are working on a site that you have different needs, then dynamic blocks is probably something that you want to have, however, in the context of using patterns, that has some downside when it’s dynamic because you just need to have something that you….

Birgit Pauli-Haack: Yeah, yeah. Totally. Yeah, definitely. So there’s also one, well, pain point with that to just kind of surface it a bit more is when you have a changed block, the deprecations does not kind of go back to the block that was used two months ago and had a different HTML, it just does not recognize as a mistake, but it does not update the block, or the render or the content that was built with the block. 

And I think that’s was also something that it’s hard for a developer to… or it was hard for me to figure out, “Okay, I built this block. And now I make an update and a new version of it. But all the previous usages of the blocks are not getting updated.” And that’s how you do when you have server-side rendering, it always uses the latest codebase for that. So, that was an interesting problem that surfaced with the JavaScript blocks.

Grzegorz Ziolkowski: Yeah, I know we deal with those issues all the time when we update the markup. It’s just the most painful… Also, for a core developer, believe me, it’s not simple, but the benefits which I covered are more important in this context. 

Birgit Pauli-Haack: All right. Okay, so what’s next on our changelog? That’s it?

Grzegorz Ziolkowski: It’s kind of related.

Birgit Pauli-Haack: Oh, no. Yeah. 

What’s in Active Development or Discussed

Grzegorz Ziolkowski: Yeah. So in this section, What’s in Active Development or Discussed, we have a very interesting debate on the internet. It’s still related to building blocks, but from the different angle than we covered in previous episodes. So it all started with the tweet from Mark Jaquith. And so, he poses the idea, as he explained, “What if building custom blocks for the Block Editor was as easy as supplying attributes and a block of HTML? What if this produced React-editing code and PHP-rendering code without a build step?”

Birgit Pauli-Haack: That’s just magic.

Grzegorz Ziolkowski: Magic. There was also a code snippet shared which was like a PHP class that had those attributes and a function that renders the aforementioned HTML. It’s a pretty nice idea. That’s funny because Riad was almost at the same time working on a prototype of something similar. And he shared his explorations on GitHub in the new repository he created there.

And the idea is almost the same. But instead of it using PHP, Riad asked, “Well, what if you use something that’s platform agnostic in a way that it doesn’t bound to a certain programming language, but something that we could use in PHP in JavaScript, but also in React Native or in any other languages you want?” So I really like how this discussion has developed. I also talked to Riad about his idea. 

He walked me through, and it’s really interesting what he does is he just implements what Mark said. So he uses a JSON file. And in this JSON file, he also represents HTML, something sort of like HTML code, that then gets converted with the tool that he created into PHP, JavaScript and CSS that’s just represent your block. Yeah, a bit mind-blowing.

Birgit Pauli-Haack: Yeah, he calls it Blocky, and we’ll share certainly the link in the show notes that’s on GitHub, for youknowriad’s user base kind of forward slash blocky. It’s not an automatic thing or something or a WordPress thing. But yeah. And then there was another discussion. I think there was this discussion was between Mark and Helen Hou-Sandi as well. Yeah. And what does she tried to do? She blogged about it.

Grzegorz Ziolkowski: Yeah, the idea was just to start discussion and set a good tone. I think that she shared also an example using Mustache-style tokens, which is something well known. It’s used in other projects like WP-CLI but also in Gutenberg in create-block tool. Yeah, but she does make the clear that it’s not about this particular templating system or the way it should be done. It’s more general. It’s like an example to better visualize the ideas. 

But yes, I like the discussion, where it’s going, and the ideas that pop up. And there was also a comment from Lars Gersmann. And he said, “What if you would use pure ES6 template strings for rendering the components?” So it’s like just another way of represent. And this one is pretty interesting because people don’t like JSX when building blocks, which is a sort of another templating system to represent a code. 

But in this context, there is something built by Jason Miller from Google. And it’s called HTM, and which basically, is something that some people use instead of JSX, which doesn’t require build step. So having this representation, of course, in PHP it doesn’t look so promising in that context. However, if you would have this templating system and a way to integrate that with PHP, you could do really interesting things. Like in JavaScript, you wouldn’t need a build step, you would just write this string as something that resembles HTML and it magically would convert to React components.

Birgit Pauli-Haack: Yeah, yeah. I’m glad that now those conversations happen. But I think it also needed to have much advanced … you couldn’t have that conversation three years ago because you wouldn’t have the APIs in place to even do a proof of concept or kind of push it a little bit further. And so, it’s clear that that needs to have mature APIs and additional experience to push this a little bit further and make it more open for different variations to build blocks. 

Pascal Bichler also chimed in. And he had this additional approach to saying, “Okay, using React components in the editor, but use web components that use the same API to render the front-end.” So it sounds like duplication, but on the other hand, web components are maintained by a large standard body and are not dependent on the implementation of the framework, like the React framework, or you can use web component with other frameworks as well. So if you would change the … God forbid, the editor to a different component system, you still could use the same front-end. That’s kind of interesting way to … that’s a larger look at things, way larger than I’m capable of, but yeah, it’s just another way to organize things there.

Grzegorz Ziolkowski: Yeah, it aligns with what Mark proposed, to have one our presentation don’t get like, it behaves differently in the editor, differently on the front-end. But maybe it could be different if you are in a native app, on your phone, it would could have a different representation. It’s very interesting times to be in and engaged in those type of conversations.

Birgit Pauli-Haack: Yeah, for some who do day-to-day development, it seems to be more an academic discussion. But I think it would be really helpful to read Helen Hou-Sandi’s blog post, and of course, we’re going to share it. And she made a big point of saying this discussion is not between two WordPress core committers, like Mark Jaquith is and she is. She has been a lead developer for quite a while on the open-source project. This is just a discussion on programmers who do agency work to organize how they do custom blocks within the team. 

And that certainly, should be interested to some of the agencies that also work with us and have been on the fence of using Gutenberg or have tried to solve some of the problems and to get additional input from those that Helen Hou-Sandi works for 10up and Mark Jaquith is, I think, a freelance developer. So from their point of view, it’s definitely worth a read. 

All right. If I look through our notes here, I have just one thing that I wanted to point out that is Matias Ventura, who is called the spark of Gutenberg in one of the publications, posted a short blog post, but it’s giving the theme.json file its horizon, pretty much. And he covers there when themes are going full-site editing, or using the theme.json file for controlling all the different places of the theme, it has some consequences on interactivity because you now can build an interface on top of it. 

On consolidation, you can remove the overhead of repetitive declarations about block features, and then compatibility, that language of blocks is by default compatible with third-party blocks, which I find is a quite compelling argument to switch over to theme.json because the plugins then also can connect with the theme and be more…. We talked about it, Grzegorz before here, that if you have an additional custom post type or a different content that you want to put on the front-end, you can tap into the theme.json to style i, or keep it in style with the local theme without having to do a lot of your own CSS put to it. 

It definitely has a performance gain on rendering those block themes and starting to roll out them. And it has a flexibility component to it, a visual parity. Talking about patterns, he talks about portability, accessibility, and also the admin section. So it’s quite an interesting post to look at from a bird’s eye view on the theme.json and what it will mean for WordPress and WordPress development. So that’s my before you go, end of the show thing. Do you have anything that you want to point out, Grzegorz? 

Grzegorz Ziolkowski: No, I just wanted to emphasize the portability that we also discussed in the context of blocks, it’s just the same. How much this would change the landscape that you could have this meta language that allows you to write blocks that can be run in so many different places, not only inside the WordPress web app, but also on mobile devices, and in so many other places like in Drupal or whatever the future will bring.

Birgit Pauli-Haack: Yeah, so I was wrong. I have two more things that are I wanted to just point out before we end the show. First… Oh, it’s actually three, no five… I never stop. Okay, so let’s wiggle that down. It’s Anne McCarthy has published the summary of the testing call for the header and the navigation block. It’s very interesting, the summary will be shared, but it also points out some of the pain points that still need to be resolved with navigation block and the screen. 

Then speaking of theme.json and portability, she is preparing with a team, also the next call for testing, which is not so much a testing of features, but a testing of a broader picture. And that is how themes switching will work or was supposed to work or what’s expectations about it? Because that’s certainly something would be relevant when we go into 5.9, or when it’s released, could be 6.0. But how does theme switching change now with theme.json and full-site editing? Meaning which of the templates that I as a user build, I want to keep when I switch the theme? Or is there a header that I want to keep when I switch the same kind of thing?

So how that’s supposed to work and that will be really great if you’ll have a lookout, we probably will talk about it at the next show. And then this third one, what I wanted to do is… And I totally forgot about it. So this is the end of the show. Yeah, no, it doesn’t come to me. 

So thank you so much, Grzegorz. It was a great show again, and we got some very interesting technical insights in how to approach some of the harder work at developing Gutenberg. So I think that was really helpful for me, especially, I learned a lot today. And then as always… Sorry, go ahead.

Grzegorz Ziolkowski: It’s always good to discuss those difficult topics, but it’s very inspiring, also to see how the community explores all those ideas, so I’m glad to follow all those discussions.

Birgit Pauli-Haack: Yeah. So as always, the show notes, and they will be quite long, will be published on the gutenbergtimes.com/podcast. This is episode 51 and if you have questions and suggestions on any of it, please send them to [email protected]. That’s [email protected]. Well, thank you so much, Greg. It was good talking to you. And thank you to our listeners for being with us. If you like the show, please share a review on iTunes or on Stitcher or Google, so more people will get to be learning more about Gutenberg.

Grzegorz Ziolkowski: Yeah, thank you everyone for listening. And see you in two weeks.

Birgit Pauli-Haack: See you in two weeks. Bye.

Leave a Reply

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