Grzegorz Ziolkowski subbed for Mary Job as co-host with Birgit Pauli-Haack. They discuss Gutenberg 13.8, Fluid Typography, updates to Block APIs and WordPress 6.1 Planning.
- Music: Homer Gaines
- Editor: Sandy Reed
- Logo: Mark Uraine
- Production: Birgit Pauli-Haack
Show Notes
Announcements
WordPress 6.1 Planning Roundup v2
Proposal: A new kind of default theme
Proposal: Moving Core block styling to JSON
PR in 13.5 Prototype: merge block CSS with theme.json styles
Design Exploration: Encourage editor configuration during on-boarding
Community Contributions
Giving FSE a More User Friendly Name
FSE Program Category Customization Summary
What’s released
What’s new in Gutenberg 13.8? (3 August)
Block supports: Add fluid typography
New examples for Block Types Data (core/blocks package
What’s in active development and discussed
Blocks: Further improve assets handling for blocks
Injecting dynamic data to block HTML markup in PHP
Updated: Tracking: Add a Style Engine to manage rendering block styles
Stay in Touch
- Did you like this episode? Please write us a review
- Ping us on Twitter or send DMs with questions. @gutenbergtimes and @bph.
- 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
Birgit Pauli-Haack: Well, hello and welcome to our 71st episode of the Gutenberg Changelog. In today’s episode, we’ll talk about Gutenberg 13.8 release updates to the block APIs, WordPress 6.1 planning, giving FSE a new name and so much more. I am Birgit Pauli-Haack, curator at the Gutenberg Times and WordPress developer advocate, and today my cohost is Grzegorz Ziolkowski, JavaScript developer and WebPress core contributor. Thank you so much, Grzegorz for subbing for Mary today. Mary sends her regards. She’s really inundated with work, which is good at one point, but we miss her today, and she will be again on the next episode. So how are you, Grzegorz? Thanks for joining us.
Grzegorz Ziolkowski: Hello, Birgit. Hello, dear listeners. I’m great. So happy to join you again and talk about everything related to Gutenberg, which is always fun.
Birgit Pauli-Haack: Yeah, and we are so glad to have you. You will bring… We will talk about some block APIs because there are big changes coming. Can you let us in or should we wait ’til we get through the release?
Grzegorz Ziolkowski: Oh yeah. Like there are a lot of things going on. We are trying to better organize the roadmap for more technical aspects of Gutenberg. So that was one of the talking points during WordCamp Europe. Many core contributors brought that. It’s like the roadmap for user facing features is pretty well defined. You have a lot of references for that, but sometimes, like with so many open issues, it’s really hard to find what’s the most important bits on the technical level and how we can improve building blocks for core and for all extenders, how we can better integrate customizing blocks to work better with blog patterns and with teams in general. So this is what we are trying address with that and we can cover that at the end of the show.
Birgit Pauli-Haack: Yeah. And just wanted to tease it out so people stay on beyond the Gutenberg Changelog for the last Plugin release.
Announcements
But before we head into that, there are a few things that happen on the team. One is the WordPress 6.1 planning is done. We have a preliminary schedule and the post also contains a full slate of release leads. So the Feature-Freeze and Beta I for 6.1 is September 20th, and that brings us with Gutenberg up to the version 14.1 if the team keeps the two-week release cycle. There’s no reason why it wouldn’t. And then a release Candidate I would be October 11. That’s when all the Field Guide is going to be published and now more any string, it’s also hard string freeze so that the translators are able to kind of continue the work. And then the final release is November 1st. That moved from the preliminary schedule that was published four weeks ago or something like that, but with the comments from that planning, it didn’t have a third Beta release, but that is now on the schedule and that pushed the final release date a week into November 1st.
The release squad is release leaders, Matt Mullenweg with the release candidate coordinators again with Hector Prieto and Jonathan Derosia, two veterans leading the release, coordinate the release. And then core-tech co-leads, sorry, is Mike Schroeder, David Bombard and Jeff Paul. And editor tech co-leads, Michael Chaplinsky and Bernie Reider. And then core triage co-leads is Jean-Baptiste Audras and Ahmad Jayon. And editor triage co-leads are Nick Diego and Anne McCarthy. Documentation co-leads is Milana Kapp and Femi Pressid, and yours truly again. So now I’m not a rookie anymore and it’s good to do two releases in a row, because first you learn a lot and the second one you can actually really contribute and not be a pain in the whatnot with all the questions. Marketing and communications lead is Jonathan Pantanni. Test lead is Brian Alexander and Ana Lakisik, and design lead is Rich Tabor. So this is a great squad, again, for the 6.1 release. That’s the third release in 2022.
Grzegorz Ziolkowski: Yeah, I think the squad is excellent. We have a lot of people that were involved in the previous release and also in the release from many months ago, so that’s always a good mix of people. And I guess you did excellent in the 6.0, Birgit, so you are too humble.
Birgit Pauli-Haack: Well, we also have something new on the release lead. Femi Pressid, she’s new to the release cycle, but she has been working on the Gutenberg end user documentation for about a year now and has done an excellent job keeping up with all of it. And now being on the Release co-lead for documentation means the end user documentation gets a lot more weight and she also can start earlier to triage what will be in the Release and what is user facing to update the documentation. If it’s not before the release, then it’s very close after the Release. So we give her all the support that she can get and if you, dear listeners, are inclined to do some writing and want to do some updates on the end user documentation, because you do it for your clients anyway, or you are, you always wanted to start contributing to the documentation team. Don’t hesitate to come and either ping me or ping Femi or Milana that you want to contribute. And believe me, we will put you to work, so you can definitely make a great difference on the documentation team for that.
Grzegorz Ziolkowski: Yes. It’s also the last release of the year, which means that there should be a new default team. I don’t know how it’s going to be handled this year, because with block teams, there are so many options. You can use block team variations or type variations. There’s many options like block patterns. So I have no idea how the design team is go going to sort that out. I know that Rich Tabor as a team lead, that’s an excellent choice. He has a lot of teams in the repository. I mean, in the directory, so you can check them out, look buy out or name and see what he’s capable of. So that’s going to be very interesting. And I also am really excited that the blog editor triage leads, this idea is continued. It was a last minute edition for 6.0 and Nick Diego, he did excellent job helping Core editor Dech Letes with picking the right back fixes and improvements, enhancements, and stuff like that during the holiday. So now having him and Anne McCarty that should be a dream team to work with.
Birgit Pauli-Haack: Yeah. I totally agree with that. He and George Mamadashvili, who also was release lead for this latest Gutenberg Plugin release, they do actually weekly triage meetings now in the Core editor channel and they started that, I think about a month ago. And this has been quite helpful because they sometimes close issues or can push some of the PRs further and see if it gets to a solution quicker. We also have, thank you for pointing out the proposal or mentioning the new default theme. If you missed that, there is a proposal for a new kind of default theme. What was that name? Man, Jenny Ritter. She posted that about two weeks ago and it’s more like it’s going to be a base theme, but then it’s a call for the community to send in style variations as well as for that theme that then totally can change how a site looks, even if it doesn’t change the theme.
So I think it’s an excellent new approach using all the different tools that are available, especially the style variations. I find that very… And Rich Tabor also has, he’s not on the team for the default team, but he’s definitely raised his hand to say, “Well, I will contribute some style variation for the default theme.” And please, we will share the post in the show notes, of course so you can share your feedback. That’s one thing, but also you can be updated on the next version of this, because the next iteration will be that there will be a basic theme and then how to submit style variations that hasn’t been yet finalized. How the process going to work, it’s always with the new things. You need to find the right process to make it work, but Jenny Ritter and the design team and the theme team are working closely together to make this a great new default theme experience.
Grzegorz Ziolkowski: Yeah. So we have one more news to share. So because the date for the WordPress 6.1 is so far ahead, we are also preparing a bug fix release for WordPress major version, which is going to be 6.0.2. And we still didn’t decide on the exact dates, but we are shooting at the end of month and you should expect some official announcements soon, probably after The core chat that happens every Wednesday.
Birgit Pauli-Haack: Yeah, that is good. That’s good. There are a few bug fixes that came out and having them fixed sooner rather than later is really good. Thanks for pointing that out, Grzegorz. We also have a link to the design explorations that James Koster did and he published it on the Design Team post, and that is a new way to offer editor configuration to new people who encounter the blog editor for the first time to select on their, the placement of their toolbar and has some little jiffs in there that actually shows the user, what does it mean? One is the toolbar, the other one, and then the document tool being on top, and then the block toolbar, as well as the accessibility. Like you want to see only the icons or also the text for the buttons in the toolbar and similar things.
So it’s very interesting. It makes the model, the grading model a little larger, but it actually conveys so much more information and it’s so much more helpful I find than the current user experience. So take a look at it. Right now, these are explorations. There’s nothing decided on yet, but that’s the right moment to offer your opinions and offer suggestions and ideas and be part of the process. So we will share that link in the show notes, of course, and it’s called “Design exploration, encourage editor configuration during onboarding.” So Ben Dwyer just merged a prototype to merge blog CSS with the theme JSON Styles. And that definitely is something that theme developers should take a look at to see if that works with how they want to approach it or with their themes. It’s in combination with a new post that says, “Moving core blog styling to JSON.” And that’s certainly something that is ahead of 6.1 to figure out, to make the process of, to give more customization optimizations options through the global styles UI, and that themes can override block JSON styles as well.
So it’s going to be interesting to see how that is received by the design and theme developers, as well as the Plug-in developers. Do you have any thoughts on that?
Grzegorz Ziolkowski: Yeah, so like we are training in the very interesting situation because, so far team could have opinions about styles, like default styles for blogs, and that’s like something that can scale well, but sometimes, because we have this interface that unifies how you deal with so many aspects of how blogs look like. So you can change spacing, padding, fonts, and all the types, all that everything created to typography. You can change background color, foreground color, links, and so many things that we constantly see new things arriving. And that’s like in the past, you would customize that for the individual blogs using CSS. But now the same styles can be replaced by the same construct that exists for themes in the theme JSON file. So like the idea is how to leverage that also on the blog level.
And it brings a lot of power because you can use one language to change everything, but then it creates a lot of questions, like what comes first? Which one should be applied on top of another one? And there’s also a similar exploration for Plugins. So there’s Plugins that change a lot of things. For instance, WooCommerce comes and they can have opinions about styles for blocks as well. So they also trying to find a way using the same representation in the JSON file. So you could combine them together. And it’s definitely very powerful. The benefit of using this common language to express styles is that you can use all type of tools that we see popping up in the community. There is a few tools that allow you to generate those theme JSON files.
So that could be extended for in the future for block JSON. And for maybe, I don’t know, what’s going to be for Plugins, maybe a theme JSON, but maybe Plugin JSON. Time will tell, but it’s about having programmatic control over all those things and having a coherent way to change the same aspects of the front, on the front end how everything looks like. And some people describe that this is how the design system gets introduced to WordPress which is like a good change from the design perspective. But it’s a very complex to come up with a good approach. So that’s why we have this proposal, the call for feedback. So people can share their ideas and their concerns, how that might evolve, how that might impact their projects and products and so on.
Birgit Pauli-Haack: Excellent. Yeah, it’s going to be… It’s some interesting times, especially as you said, kind of the roadmap for, at the beginning for UI and for the no code users is pretty much well spelled out and there’s a vision, but now that it’s almost done with the underlying architecture, there are now the things that need to be happening for extenders, for plugin developers, theme developers. And because everything is now at least understood how it’s in place, there are still a few things like the style engine and this, the common language of how blogs are styled that are coming together. And yeah, these are exciting times. I love it.
Community Contributions
For the community, so Josepha Haden Chomphosy, executive director of the WordPress open source project has posted a post with a headline, “Giving FSE a more user friendly name.” And the TLDR for it is that the terms full site editing or full site editor also abbreviated FSE were actually just a code name internally.
And they were developed to easily refer to all the collection of features under, that are for site editing and global styles and that. And I integrate in the WordPress experience, but how can we best update the wording to be more user friendly? Because it doesn’t tell the user anything. And naming is really hard. We see that all the time. There are few issues that she has with it, or sees with it that it’s already possible to edit every part on WordPress using code. So the term for that editing doesn’t differentiate between the phases of the project and does not show the new capabilities of the CMS per se. And it also implies the use of blocks, but for new users, there’s no reason for them to expect anything else. So the term isn’t descriptive enough for a user that comes to WordPress, what does it do?
And then she goes in a little bit more detail and asked then a few questions for you. We’ve referred to it this way for a long time is one of the reasons how can we tackle renaming it together? And then it’s in the code base. So how will we make sure people who aren’t regular contributors see that there will be a change and repeating in line? What other context do you think we need to be aware to look at when we refer to the collective work in the future? So this is one of the more discussed posts. But your opinion is definitely worth bringing in. There are 88 replies already, but I don’t think that a lot of people have seen that yet. So if you haven’t read it yet, and haven’t thought about that, it’s definitely worth your attention, unless you say, “Okay, well, I don’t know how, what they call it. I don’t care.”
So, but yeah, most of the time, if you are an educator, if you are a theme developer, you have to talk to your users and just explain what it is. This is what we call full set editing now. And there might be a better way and there should be a better way, I think. So that’s one of the pieces I have for you and the other one… So there was a call for testing out from the FSE program, the 15th in a row. And Anne had a deadline of August 1st for comments. I think it ran for four weeks and she now published the summary post for it. And yeah, it was amazing. There were two translations again for the Japanese community, as well as for the Italian community. So there were other voices heard while speaking of translation. Yeah, full site editing doesn’t translate well into a lot of languages.
So there was also a concern. And then she also used for the first time for a test release, a feature or a service called Insta WP, which lets her set up a site and give you a link to it, so you can spin up your own test website without having to do a local install or any of that. So you could use it for seven days to go through the test. That was really interesting. So the high level summary is there’s still a lot of confusion about certain things, especially it was heavy on the Query Loop, but it was also when you create a new template, you get an empty view. Is there a way to make it replicate some of the footers and headers that is on other templates also for a new one. So they know, okay, this is what I have on every website and something like that.
Grzegorz Ziolkowski: So to clarify, what was the text as exactly. I read that you were asked to go to the editor, like full site editor, just to make a pun of the name and then go to the toolbar and probably create a new template and pick a category, like version of the template and then like go and like use Query Loop to display all the posts from that category and provide everything else that you want to see on this type of pages. Right?
Birgit Pauli-Haack: Right. Right. And that was one task. And the other task was to create new posts, to explore patterns that were already available on the site. That’s why the Insta WP was an important, that a pattern for a new event announcement and a pattern for an event recap, meaning there were also additional information that we’re supposed to be in there in the pattern and how it worked.
Grzegorz Ziolkowski: Yeah. But still, this is very exciting that you can go and create a template using your browser without having any access to the server and like, you know it’s just like, it’s a so huge change for site owners.
Birgit Pauli-Haack: Yes. And up until those changes were in the block editor, it was always more like a catch up for what has been around in page builders for maybe a decade or something like, well, no, no six or seven years apart, that was not in core. But now with this new template editor, this is something that you couldn’t do before without code. That you have an author template and the in 13.7. There were a whole range of new templates available now. And in this version we have, yet another one and that is probably the conclusion of, how many different template types can we create. Yeah, I’m really excited about that. That’s a total new thing for site owners that don’t need any developer to not only have a new template, but also can create the pattern creation that is still the missing link.
But you can do a combination of having for every new user on your site that edits, you could as a developer, you can actually have patterns for a certain blog type or post type show up in the create new methods. So that is also something that is highly underused right now. I think those things all come together with time and we need to really have more educational posts around that, like the call for testing. That’s the best way to learn what the new features are when you follow those calls for testing, because they’re very detailed and very distinct and make sure that you can accomplish that, but you learn so much. All right. Yeah, that brings us to what’s released?
What’s Released
Grzegorz Ziolkowski: I mean, finally, there is a lot of cover that’s happening in the community. That’s great.
Birgit Pauli-Haack: Yeah. So Gutenberg 13.8, it was released. George Mamadashvili, was a release lead and he noted that we are almost really 3 releases away from 6.1. I did some calculations and it seems that 14.1 will be the last Plugin release that will make it into 6.1. And that is supposed to come out on September 17, something like that. Yeah. So 13.8 comes with fluid typography, accessibility improvements, revamped quote blog template parts, UX enhancements. And it’s also of course always full of bug fixes and code quality improvements. So let’s take it from the top.
Grzegorz Ziolkowski: Yeah. So the flow typographic is a huge change. It’s something that probably a lot of designers expected to see and, it’s something that still isn’t exposed in the UI. So we need to wait for that. It’s a pretty common approach that we seen in the past. And we talk about the other future that our first available through code and then the UI comes after, after it’s properly tested. So maybe Birgit will tell more about what’s exciting about this feature.
Birgit Pauli-Haack: Well, the fluid topography, what that does is that you can, as a theme developer set a minimum size of your font sizes for the smaller screen and the maximum size for the big, big, big screens. And then what the theme does is, or WordPress does is kind of scales from the small to the screen, seamlessly the typography. So the size of the letters, the spacing of the letters, and also how the paragraphs kind of form. So there is no set viewpoint or view port for the mobile version or the tablet version. It is seamless. And that is kind of the approach that the Gutenberg developers have taken to more implement intrinsic design rather than the certain viewpoints that are along the way, which other page builders have. It’s now available in theme JSON and the fourth theme JSON. So you need to, can set it in the theme JSON file and then how to implement that is in the PR that’s 39529.
And I know there is a certain, a post in the works to flash that out a bit for the theme developers and it’s coming out in the next week or two, but in the PR which we will separately share in the show notes, you are able to set the settings dot typography dot font sizes, and then give it presets for your theme. You set the fluid field to true, and then you have the minimum size and the maximum size, or you can name them. And your theme then is able to, and WordPress will create the variables for it, for the units. It seems that the best use would be to use the REM units for the relative size propagation. Right now the maximum view port is 1600 pixels. And yeah, I don’t know if that’s right, that it says here 768 for the smaller size.
So it will not go all the way down to the mobile, but this is the first version. So it’s not going to be perfect and it’s going to be, it’s really going to be rough. So the developers really need you to test it out and give some feedback on it, how your implementation is either stifled or what are the blockers? What does work, what does not work. How you would kind of proceed with that, because as Grzegorz said, the first version is just to get it out in front of the people to be testing and then iterate on the implementation with the feedback from the community.
Grzegorz Ziolkowski: Yeah. Although I must say that all the demos I’ve seen so far look pretty great. Maybe it isn’t like so rough, as you mentioned, maybe it’s like good enough for some themes to enable that and see how it plays in practice.
Birgit Pauli-Haack: Yeah. Yeah. I certainly have a “it’s good enough kind of approach to many, many things.” But I know that separates me from the professional theme developers and designers. They want it to be pixel perfect. And they want it to be very granular, have flexibility, very granular form. So I think I would not be a good judge of the feature because I also don’t make a living selling themes. So I really would love to see what Anna Sekoda for instance does with it, or what Ellen Bauer who is also, has been a theme developer since the beginning of blocks and FSE. And they have already published quite a few like Rich Tabor, quite a few themes in the theme directory or also on the WooCommerce marketplace. So that is definitely something they will test it out and figure out what’s needs to be done.
Enhancements
So other enhancements that we have in the 13.8 release is that the social icon block has a variation now or an icon for the WhatsApp app, has a WhatsApp icon. So you can also connect your profile, your WhatsApp profile on your website. What I also am quite excited about is actually talking about theme JSON, that quite a few things in this release that are concerning the theme JSON on file. This one is also support for heading and caption elements in the theme JSON schema, meaning that you can target with your CSS directly, the HTML elements without having to create another class name or something with your styling. One is also a little minor. That’s the merge of comments and post comments blocks. That’s a big deal, but it’s also kind of the merging of the old thing with a new thing. So when you use the old comments block and now use the new post comments block, it will update your comments.
Grzegorz Ziolkowski: Yeah. It’s mostly before the themes that use the old block. So right now, if you use that, it’ll migrate to the new one, but it will still retain the old behavior. And you will be able to switch to the version with blocks, which like within the blocks, which is like more powerful in terms of all the types of customization that users can do inside the editor in WordPress. Whereas the old one, it depends on templates that are PHP based. And in like by fault, it uses what every WordPress instance provides that can be written by teams, but every site could also provide their own. But you need to code that so that the new version is what we would prefer, because with the block concept, you can do more.
Birgit Pauli-Haack: Yeah. So another great feature is now added to the image block and that is border support for color, width and style. And I think that’s the last piece missing to make it really flexible what you do with themes. And George wrote that he’s very curious to see what the creative folks at the museum for block art can accomplish with that, because now you can actually change the border width and differently from the right and left on top and bottom, and then change the color of each. And it’s very flexible and you also can change the radius of the border. So you have round a corner on two sides and square corners on the other side. And it’s just really amazing what you can do with it when you have border controls. So yeah, definitely check it out and see what you want to do with it. The block museum for block art is definitely open for submissions. And I will share in the show notes, how you can submit your creations and see what you can come up with.
Grzegorz Ziolkowski: Yeah, there were also a couple of changes to template parts, which makes them even more powerful. The one thing that I like a lot is that right now it was quite difficult to explore existing template parts in the inserter because they were hidden and you had to insert the template part and you’d, once the block was in the editor canvas you had two options. One was, set existing template part, the other one, you could create it from the scratch. So right now all the existing template parts are also exposing the inserter, which is like a shortcut for everyone. It’s easier to find them, which is a good change. It also aligns more with how usable blocks work, which are in their own tab in this inserter here. Like those template parts, as far as I remember, there are inside blocks, which is like, might be a little bit confusing, so maybe that’s something that could be iterated full there. However, if you search, you don’t care so much and you will be able to see them. So I find it like a great step in their right direction.
Birgit Pauli-Haack: Yeah, definitely. Yeah, it’s interesting how people explore interfaces completely differently. So having multiple ways to do the same thing, really exposes more users to the intuition on how to change things and streamlining the process, like these shortcuts is definitely a way to go. Yay. There is a minor change to the color palette. It now displays of checkout preview background and the value is transparent. So you couldn’t see from the color settings, if there is a transparent color or transparent background on a group blog or on a cover block, now you can see it through the checkout preview. That’s definitely a quality of life kind of change that your brain really can absorb that and see that there and give you the signal. There’s a transparent value there. You can now also, and that was missing for a while, you could do the layout content size settings through the theme JSON, but the user didn’t have any way to correct that or change that. Now a site owner has. You can now do it through the interface that you can set the content with as well as the wide width and also the padding for, for those blocks. So that is really for the layout of the template, so that has…
Grzegorz Ziolkowski: There’s one change that I’m pretty excited about. It’s about the placement of the inline toolbar when using feature text tools like bold italic underlying. So at the moment, like in the past, like in most cases you would see that in the block toolbar that could be either dock to the header or on the top of your block, especially when you write a longer paragraph is like is far away when you want to use a mouse to interact with that. So now you can change the setting and that will be like a floating toolbar that’s always next to the text that you have highlighted, which is very similar to what you will see on mobile devices or tablets when you interact with the apps that come with the system, like iOS or Android. So I like that one. And I’m hoping that people find useful as well.
Birgit Pauli-Haack: Yeah. I really like that. I saw that first in medium, when they came out that they had this, you highlight a text and then they offered you a formatting toolbar. And I really loved that. And I was missing that in Gutenberg forever, obviously. But I also tested the distraction free writing tool that Rich Tabor and Jeffrey Carandang created that was the iceberg editor. And they actually implemented that as well. And I’m glad that it now came to core and that we have the first iteration of that. And I’m eager to test it out and use it.
Grzegorz Ziolkowski: Yeah. Also from the experience, I know it’s a bit tricky to use that feature, especially when you are using mobile devices because their system provides their own toolbar. So if in that context, it might be very disruptive, because you don’t know whether that toolbar will come from the system or from the block editor. So, not all features might be available if you see the system one. So, it’s something that needs to still to be tested, but because it’s a setting you can for the mobile, you can disable that. And for the browsers, you can have it enabled. So I’m sure that we all see some improvements on that front.
Birgit Pauli-Haack: Excellent, yes. And a whole new, so the quote has received a total revamp, so to speak the quote block, now you can use it and it’s coming out of experimentation with this 13.8 version. So it gets quite a few more testing in before it actually will come to 6.1. Now you can use nested blocks with your quote block. So you could have a quote from someone and add an image to it, or have multiple paragraphs in there, or have a list in a quote block. Often, you couldn’t do a list and make it a quote. So now you can, and I’m really happy that it made it into this version.
Grzegorz Ziolkowski: Yeah, it’s very powerful, especially for developers who use GitHub and they know what you can do using markdown that you often quote something which includes code examples, images, videos, and so on. So like this is like bringing the same functionality into the block ward. So I’m really excited about that one.
Birgit Pauli-Haack: Yeah, especially when you have code quotes and tutorials also. Yeah, it definitely helps to have that, also have the citation with it.
Grzegorz Ziolkowski: And also there’s ongoing work to bring the same set of features for the list block, which is another level of complexity. So now you would be able to have a quote that has a list that has inside that nester blocks, you can have paragraphs headings and code examples, even in list, which you know.
Birgit Pauli-Haack: Icon, emojis. Emojis in a list block. Yes. Nice.
Grzegorz Ziolkowski: These are much more complex because they’re like, at least are not two dimensional and it’s not only like the nest of blocks can be on one level, but you can have, the list itself can have a nest at least. So it’s like the interactions between those internal, nested blocks are much more complex. I don’t know if that’s going to be ready for 6.1, but it’s definitely in works and might happen.
Birgit Pauli-Haack: And if you are very interested in that list version two, list block version two is still in experiments. So you need to enable it through the experiment settings before you can test it out in your local or test site. I wouldn’t do it in production, but yeah, for testing, it’s definitely, you need to enable it in the experiment settings. Yeah, I’m really looking forward to that, especially because you’re not, so when you change from a bullet list to an ordered list, you change the whole mockup in it. So what happens then? There are quite some complexities there. We have seen that in discussions also with the table of contents block that comes out of the gate with a numbered list. But many people don’t like the numbered list and there is no way to change it over to a bulleted list. Say maybe the experiences that come with the list development with the list block version two can actually be replicated for other great blocks that are out there. So what else is in there? So anything that stood out for you?
Grzegorz Ziolkowski: Yeah, I think we covered the most important aspects, like enhancements and new features. That’s quite a huge list. There are some accessibility improvements as usual. It’s always great to see contributors focus on that area, which is like never good enough because the interactions in the editor are so complex. That is very hard to do it right on field first run.
Birgit Pauli-Haack: Yeah. There have been changes to the border controls, which are trigger quite some creativity. So getting that right for accessibility, with labeling and tool tips and field sets and legends that is now available in the Plugin. And then there were some fixes for descriptions or for some other labeling and semantics in the paragraph block. And then also to, they also replace some diff elements, clickable diff elements with actually buttons because that’s a better experience for all users.
Grzegorz Ziolkowski: There’s also, like in that, related to that, there’s a very interesting change now. When you are focused on the group block, you can use, enter key to create a new empty paragraph just after the group block. So before you would just like, it wouldn’t like, nothing would happen. So you would have to use maybe the drop down menu from the toolbar for the block to find insert a block after the group, or maybe like find some other way, like in between line easier there with mouse. Now it’s much more convenient just to press enter.
Birgit Pauli-Haack: Yeah. Yeah, definitely. I always appreciated that with, for instance, the list block where you can enter, enter, and then you’re out of the list block and can start. But getting that to more than one blocks is really good. There are also some big change, not big, but yeah good changes in the documentation of things, especially, having many more examples in the core blocks, a data API on how you use it. And some of the examples are also with great comments, so you can make more sense out of things. I think that Ryan Welcher does the great work there and he definitely can use some help. He is determined to have for every function call or store call or something like that. He has an example that is ready to copy paste into some other code, or at least with adaptions. The docs for the block JSON are also updated because it was missing the block variations. And that has been added to the JSON schema definition so now.
Now you can point to the block variations as well as to the styles with your block metadata. And then the data module had some missing references and that have been updated. So you can actually find them in the documentation now.
And again, theme JSON got some clarifications on the null true and false values for the block gap setting. That was a little confusing before. So it’s now straight net, as I would say.
Grzegorz Ziolkowski: Yeah, it’s ongoing effort to improve developer documentation. There is a lot of public APIs that are documented, but they miss examples. And I think that the work that Ryan Welcher is shepherding is so important to get it because like having code examples makes it so much easier to actually use the code.
Birgit Pauli-Haack: Right. Yeah, totally agree with that. So I think we are at the end of the Changelog for the 13.8 Plugin release that happened this week on our third.
What’s in Active Development or Discussed
And now we come to the section, what’s an active development and what’s discussed. And before we head into the block API issues, I think there was one thing that I wanted to point out and that is that Ramon published an update also on the style engine tracking issue. So we will definitely point to that in the show notes, but he has, so the style engine is at an experimentation, right or is in experimentation right now. So, but it has a phase one which is block supports and building the foundation. And then the phase two is the global styles consolidation, reducing style tags. And in both, he has some updates on some of the issues. So make sure if you’re theme developer, you’re definitely interested in what’s coming down with the style engine development.
Grzegorz Ziolkowski: Yeah, it’s very related to what we are going to cover now, which is block API. So style engine is in fact, subset of that, it’s related to how class names and style attributes are added to the block HTML output. And the idea we style engine is that eventually we would have everything generated on the server only on the front end, so that means that only styles and class names would be included on the page when the given block is there, which means an excellent reduction of unused CSS, which a lot of websites struggle with today and the progress on that is really promising. And I hope that in a few months we will see all the benefits of the work happening on that front.
Birgit Pauli-Haack: All right. So you revamped some of the… You created a tracking issue for the block API that had quite a few chapters on it and does seem to only have 35 tasks and there are other tracking issues with much longer, but it covers issues that are around block assets, block registration, block attributes, variations, block supports, and then the inserting and moving blocks and block editing, dynamic block manipulation, server side rendering component and of course documentation. So what stands out for you on this? What is the big effort here?
Grzegorz Ziolkowski: So first of all, we have over 4,000 issues open in the Gutenberg repository. You know it’s very hard to triage all of them, go back and see what’s there. So the effort that I made together with Matias just was, can we identify the most common, occurring issue that people rise and they want to see improved and that we wanted to collect items that make the biggest impact in the short term. And it’s not like the list is close. We will be constantly revisiting whether the list makes sense. We will be adding new features based on the feedback from people in general. It’s just a way for us to bring better focus on what we can work on in the upcoming WordPress releases and Gutenberg releases and, like it’s dividing the sections, just like it tries to follow how the milestones for how the WordPress, the block editors and the full site editing should evolve.
It’s always like milestone for template parts, milestone for global styles and so on. We try to mirror the same structure. And for now it’s because issues that we’ve been talking about, some of them for years now, and there were never clear focus to work on them. And we are trying to change that because we see that stuff like block validation and block deportation comes back every now and then, this people often complain about. So we just want to make sure that there is single place that people can go and see, “Okay, is that on the roadmap? Is that being tracked? How can I get involved and help move that forward?” So instead of saying that, find the issue on GitHub throughout all those 4,000 issues. Like there’s a single place. It’s pinned when you go to the Gutenberg repository and you go to issues like on the top of the page, there are three pinned issues.
It’s one of them now. So it’s easy to find for people if they know about that thing. And so it’s easier to discover and this is also a good way to see what’s actually being worked on because if you go to this issue and the tracking number is 41236, you can see because there is an icon is a ranch or how you call it like that like…
Birgit Pauli-Haack: Oh, toolbox tool.
Grzegorz Ziolkowski: Toolbox.
Birgit Pauli-Haack: Tool set.
Grzegorz Ziolkowski: Toolbox, tool set. So you can see this icon. It means that someone is actually working on this feature or there is open PR, so you can leave your feedback there. And once we have some issues done, then we just be marked as finished. So people can see at some point a history of the progress what’s being worked there. It’s also a nice way if someone opens a new issue and you know, like Fabian Kagy, he opened recently some issues related to how we could better control inserting blocks in the editor.
So you could define, for instance, this blog goes only when there is no block inside the template, or maybe I want to have only a single instance of this block when it is inside a given parent block, like very complex use cases and those type of issue, they’re great ideas, but it’s not so easy to define how that could be done. So this tracking issue will try to combine similar issues like that and put that into the tracking issue. So you can have a single reference and find those issues also from the perspective of project management, like when someone opens a new issue and we can easily say, “Okay, please check this tracking issue and see what we already have on this topic and see how that fits to the proposed solutions so far.” Like this type of capabilities are open and I mean, I’m really excited about that because so far it was really hard to identify how people can get involved to improve the API blocks.
So it impacts how you develop blocks and to make it easier, more straightforward for all the developers. But also it impacts the core blocks. Everyone would benefit from the ideas that are in short in decision.
Birgit Pauli-Haack: Yeah. So, let’s see at some of the examples and so in the assets there isn’t one tasks to explore how to tree shake block styles on the front end and has an example issue and that is how, what does it mean? That’s kind of how the CSS cascades through the front end. Another one is combined.
Grzegorz Ziolkowski: Yes it is.
Birgit Pauli-Haack: Go ahead.
Grzegorz Ziolkowski: Yeah. So the idea here is for instance, the idea was whether we can find a way to define, okay, this style is present on the page when the following conditions happen. For instance, in the block has a special class name called, whatever. And then the system that would be built behind that could say, “Okay, and this blog doesn’t have this class. That means that we can skip that and we don’t have to serve it to the user.” So it’s fairly technical, but that gives you idea what exciting things we can do with blocks, having better understanding of how they are structured, what they contain and like these ideas. Also, there’s a lot of requests from Plugin outdoors. So they would like to have a better ways to inject their own styles to blocks or JavaScripts. So, we are discussing different ways how it to make it easier so you could just define okay to all blogs that met certain criteria, let’s add this style that brings some additional visual effects.
Birgit Pauli-Haack: Yeah. Yeah. Okay, I understand that.
Grzegorz Ziolkowski: One of the things that we are actively working on is related to dynamic block manipulation. So we always wanted to have a way to, let’s say, use some data that comes from database or some external service. So for instance, the ideas are the simplest one, you have a block inside the footer that shows a copyright note, like in PHP it’s easy because you are using date function and just like changes every year. So you don’t have to go to your website and update that. And how to define some, some ways. So you could just insert a token that says, “Okay, this is a date.” And it displays a year and it will change automatically inside the block. So it’s shortening the database, something dynamic, on the render of the front end it changes.
So, this is very advanced concept. And however we are now, we should see next week a proposal on make core block for something more simple. Often people want to replace some text or token or something, the credit that like a pattern inside your block. For instance, the cover block has a featured image and it’s really powerful. And we’ll be seeing a proposal for special API that will make that simpler so you can define like, let’s find this stack and change this attribute source with the value that comes from the featured image and this type of thing. So everything is very technical. And I think that is a good common, like good place for people who are very familiar with JavaScript, but also with PHP. So like everyone finds something to think about.
Birgit Pauli-Haack: Yeah, especially the inline token. We actually had Danny Schnell as a guest on our podcast here when he was working and trying to think through that. And he took us quite deeply into what needs to happen. And so make it complex, make it easy, make it simple. And we call it back then, we call it kind of the short codes 2.0, so it’s not nothing new to WordPress, but it’s the innovative version, the better blocks version for it to have these inline tokens for replacing some variable with something else or with some values. And I’m glad that you said that’s kind of in the works for next week to try out or to at least kick it around in theory, so that’s wonderful. There’s also something that’s in the works that’s…
Grzegorz Ziolkowski: And for block registration, there is like a very quite simple proposal. Like right now to define how the dynamic block gets rendered with PHP you need to like define a function. Inside this function you will get some, like content of the block attributes and the block type, and use all those variables to generate the output that’s going to be displayed on the front end. And we are also thinking ahead and trying to combine efforts with how in the future you could like to write simpler blocks in that you would provide a PHP template that generates that output instead. So you don’t have to deal with functions. You just provide a function that just prints everything. And this proposal covers that.
Birgit Pauli-Haack: That sounds really interesting.
Grzegorz Ziolkowski: So in the future, we could have something similar for JavaScript. So also you could provide like, depends would we peak and land on.
And, but there is this in the WordPress like organization on GitHub, there is block hydration, experiments, repository, and like explores exactly what I said for JavaScript, how to make blocks interactive on the front end. So for instance, they can have buttons that change state of the block, and you can have like dynamic data that updates, for instance the simple example, people always use the counter. Like you click the plus sign and the number changes, so this type of features. And at some point we hope that this PHP template and JavaScript template could be somehow unified. So maybe not in a sense that you would be writing a single code, but with some tooling, maybe we could have some format that allows you to generate PHP and JavaScript. So you don’t have to bother and write it twice.
Birgit Pauli-Haack: Yeah, yeah. Yeah, that was a big discussion between Helen Busandy and Mark Jakeworth and Riad Benguela about, I think it was in October last year. And then I know Michael Chaplinsky has done some more exploration. And then there was, did you work with Ellen Cherser on the, there is a new JavaScript.
Grzegorz Ziolkowski: Bento?
Birgit Pauli-Haack: Bento. Yeah, Bento JavaScript. Kind of replace the JavaScript framework with a different framework. It’s not certainly the best approach, but if it works for people who use that. Before that you can use it for blocks with different languages or languages and variations and frameworks.
Grzegorz Ziolkowski: In some ways the Bento components that Google is working on are similar to the ideas because it just exactly does that. So they have some way to define components and they have different representation for web components for PreAct and you can just, it’s the same UI, but you can use different code, depending whatever you want to have on your website. And it sort of falls in the same category. But it’s just like Bento is done by Google. And it’s hard to tell how it evolves. So we are exploring different parts for now.
Birgit Pauli-Haack: Yeah. No, I get it. Well, so is there anything else then, do you want to point out from this tracking issue or discussion?
Grzegorz Ziolkowski: Yeah. I guess I’m good. One of the ideas that Fabian mentioned is very interesting, so because the way to control where you display blocks has always been troublesome for people. So people want to have flexibility. For instance, you have custom post type, you don’t want to see all blocks, so how to do that. And we have some ways on the server you can provide allowed blocks to which is list of types of blocks that are allowed. But sometimes we want to have the positive approach. How do I say that? Which blocks I don’t want, and I want the rest. So that’s also some of the discussions happening that the people like our listeners could chime in and share their ideas. And in general, with WordPress 6.0, we added our sister Field, which allows you to define, “Okay, I want to have this block when one of the parent or grandparent or grand grandparent blocks are this and that block.”
And it’s gives more flexibility, like the comments lock uses that because it allows you have comments and you can have group, then you can have, I don’t know, what else do you want? You can have several groups and then you use a common title, for instance, I mean, in small complex, but make it shorter. And this gives a lot of flexibility and one of the ideas I had originally, how you say like, “I want to have this parent and this ancestor, but I don’t want to have this ancestor.” This type of way of defining, which would satisfy a lot of use cases.
Birgit Pauli-Haack: Yeah, indeed. And I think we need to really write much more use cases for it, and tutorials so people can actually imagine things here because theoretically, what’s an ancestor? What’s a parent, what’s a child, where’s a child? It’s all a little bit more, little bit too abstract when you’re kind of try to figure out how to get it all together. There are so many ways to skin, the cat. So are there answers, so I have a question for you and one is that, is there a way to actually pick up custom fields for custom post types if they were kind of already created or if they are kind of available to use them also in a template or? It’s probably very hard to do it via UI. That’s why our advanced custom fields is still for many developers that go to place instead of creating custom blocks for the custom fields. But I think that. Are there any thoughts on that, in this reiteration of the block API?
Grzegorz Ziolkowski: Yeah. So for now, the proposal, that’s going to be shared next week for replacing parts of HTML with API that allows you to change attributes. That could be a way, you could say that, “Okay, this field is like going to be replaced with custom field.” So you give you the name and something like that, but it’s still not good enough, in my opinion. We need to have a proper way for that in the future. And maybe even more advanced way of defining dynamic in my tokens. The way it works with blocks, ACF Plugin is that they allow linking between an attribute, so it stores the reference to the exact filter in the database. So it stores the number and based on that, it can provide the correct value. So whenever it changes, it updates on the server as well. So it’s not that easy to do that, but for that ACF has created a special way of writing templates, which takes that into account. It’s dynamic.
It is able to link all the correct numbers and so on. So, I mean, it’s like having something like that in a more flexible way that works, not only with what ACF provides, it’s a bigger task and it is definitely something we would like to have, we just need to do it in steps.
Birgit Pauli-Haack: Yeah. Yeah, no, so that will be the block API, third iteration. Now it’s the second iteration and then the next iteration is going to maybe, kind of thinking about through that part. Well, excellent. Thank you so much for walking us all through that. And what’s in the works and what the next iteration of extensibility for blocks actually will look like. That is definitely now that the foundation is in place. Now extensibility has a higher priority, it seems for the Gutenberg project. So I’m really glad that this took a lot of work to find all the right issues and figure out how to structure that. So thank you for going through that and also leading us through that.
Grzegorz Ziolkowski: Although to be fair, most of the issues were opened by our excellent contributors. I just only did the part of finding them and putting them in one place.
Birgit Pauli-Haack: Yeah. And yeah, you helped a lot of people kind of get a good roadmap through that, or at least an idea of what the vision is going to be, so. Because that’s always a question that we get, so what’s the vision? And only these tracking issues and overview issues like Matias did and what you did and was also Andrew does for layouts and for style engine all that. Maybe I should share some of the tracking issues. I think I collected about 10 or 15 tracking issues now. From the Gutenberg project, it’s probably a better way to figure out what’s current on what people are working on. So yeah, that’s a call for me to maybe think about some curation of that.
All right. Well, thank you very much. At the end of the show, we are way over whatever we wanted to do as an hour limit or so, but that’s okay because you brought so much more insights into what the second iteration of block API is going to hold. Is there anything else that you want to leave our listeners with?
Grzegorz Ziolkowski: I don’t have anything.
Birgit Pauli-Haack: You don’t have anything. I don’t have anything. I said everything that I wanted to say at the beginning in the announcement, in the community and no, I’m glad you were on the show. Thank you so much for coming. As always the listeners, the show notes will be published on Gutenberg Times.com/podcast. This is episode 71. And if you have questions, suggestions, especially answer for Grzegorz with all the questions that you might have for the blocks API, send them to changelog@gutenbergtimes.com, that’s changelog@gutenbergtimes.com or ping me or Grzegorz on Twitter or WebPress slack. My handle is BPH. That’s my initials on both of them. What’s yours, Jergus?
Grzegorz Ziolkowski: Mine is G-Z-I-O-L-O
Birgit Pauli-Haack: Giolo? Gizolo?
Grzegorz Ziolkowski: Yes.
Birgit Pauli-Haack: Yeah, cool. Well, this was it. And thank you very much for listening. If you find this helpful, create a review and we read that out loud here. So you would get a little shout out on the next episode. Thank you for listening, and I wish you a great week. And next two weeks until we hear you again.
Grzegorz Ziolkowski: Thank you for the invitation Birgit. It was as your role, a pleasure to catch up what’s happening with Gutenberg.
Birgit Pauli-Haack: Well, thank you so much, and it’s always a pleasure to have you thanks so much, Grzegorz.