In this episode, Birgit Pauli-Haacj and Mary Job introduce Ryan Welcher and discuss Gutenberg release 13.7, more template creation enhancements, first full-site editing themes in the Woo Commerce marketplace and more.
First Block Themes on WooCommerce Marketplace
- Bonum by ThemesKingdom
- Basti by Ana Segota of Anariel Design
- The most beautiful WordPress Gutenberg Block Theme
What’s in the discussed or worked on
Stay in Touch
Birgit Pauli-Haack: Hello, and welcome to our 17th episode of the Gutenberg Changelog Podcast. Today’s episode, we will talk about the latest Gutenberg plugin release 13.7, more template creation enhancements, full side editing themes in WooCommerce, and a lot more.
I’m Birgit Pauli-Haack, Curator at the Gutenberg Times and WordPress Developer Advocate. And I’m here with my co-host, Mary Job, WordPress Community Organizer at wpafrica.org and Support Engineer at Paid Membership Pro.
So glad you’re here again with me, Mary. How are you today?
Mary Job: Oh, I’m doing very okay. Thank you, Birgit. I’m also looking forward to my first WordCamp post-COVID. I believe this is also a good time to mention that a call for speakers for WordCamp Ginger is out, so if you’re interested, I look forward to meeting you there. Please apply to speak. WordCamp, again, Ginger will take place on the 2nd and 3rd of September 2022.
Birgit Pauli-Haack: All right. Well, thank you. And I’m also so happy to welcome from Canada core team contributor and Twitch streamer, Ryan Welcher. He’s on the second time on the show.
So, how are you today, Ryan? Thanks for joining us.
Ryan Welcher: I’m good, Birgit. Thanks for having me again. It’s always a pleasure. It was a great time last time, and I’m looking forward to diving into all the new features.
Birgit Pauli-Haack: All right. Excellent. You just finished this week’s live stream on Twitch. How did it go? And what did you talk about?
Ryan Welcher: It went well. It was a smattering of topics. I have been working on a lot of documentation around some data store stuff, and I learned something new about useSelect, which is a hook that we use to retrieve data from Gutenberg and from the data stores. And I kind of poked around it into Gutenberg 13.7 a little bit. But we kind of ad hoc jumped into this really, this concept of one block being able to refer to another block to get its attributes and talking together and having them update and everything. And that was a lot of fun, but it was pretty in the weeds, as far as working with blocks go. But, yeah.
Birgit Pauli-Haack: Well, that sounds really interesting.
Ryan Welcher: Yeah, it was fun.
Birgit Pauli-Haack: Yeah, excellent. Excellent. So. Go ahead.
Mary Job: Oh, yeah. I was going to say that sounds like a lot of fun.
Welcome again, Ryan, and thank you for joining us on the second time here.
Ryan Welcher: Glad to be here. Very, very much so. Thanks for having me.
Mary Job: All right. So, let’s get this show on the road. We have a couple of announcements.
First off, I’m glad to announce that Pattern Previews are now available in the Team Directory. Now, the Meta Team has released a better version of this new future in a team directory.
What this does is, it allows you to see the patterns that are available within a team. The patterns at the space are thumbnails on the team stage. And when you click on them, you can see a larger version, which is what you would also see when you click on a page on your website.
This is a first iteration, and in the release post on the Meta Team blog, Steven Dufresne different as asks for feedback. So, if you’re testing this and you see something that is not working right, please, please do give them a feedback so that they can improve more on this future.
Do you have any thoughts on this, Ryan or Birgit?
Birgit Pauli-Haack: Well, I find it’s really fantastic that it’s out there. And yeah, because I suspect that patterns will become so much more important on WordPress than they are now. And this is another example of how patterns will get a much bigger exposure.
Mary Job: Awesome. Okay. All right. Still on announcements, next up, there is a call for comments on a feature plugin for notifications.
I’m actually excited about this one. I don’t know if I have OCD or something, but it freaks me out when I enter into a WordPress site and I’m seeing all this notifications there and there I’m just clicking X and X, and then I come back and I see them. It’s really upsetting. So, actually, this is not block- or editor-related, but the group of contributors working on this review for the API, for the BP admins just published this in their current approach.
So, the problem this seeks to address is actually simple. Imagine you log into your WebPress site. You haven’t been there for weeks. And the moment you do, you’re bombarded with update notifications, premium plugin advertisements. I think the one that gets me is the premium plugin advertisements that come on the main dashboard instead of on the plugin itself dashboard. I mean, when I see them, like, “What are you doing here?” So this is what the team around the WP notification project tries to change.
Cutting from the post by Brian Coords, it says, “This project is focused on building a new framework for notifications from the ground up, and potentially providing a tool that encourages consistency in presentation, follows best practices in standards and accessibility, and discourages disruptive interactions in the WordPress admin screen.”
Do you have thoughts on this, Ryan?
Ryan Welcher: I love it. I love the idea of it. I know it’s the bane of most site owners’ existence to deal with the… Every plugin handles notifications differently. I mean, when people are left to sort of roll their own solution to a problem, then we get 100,000 different solutions, so having something that’s standard, and it’s thoughtful, and built from the ground up, it’s going to be great. Because I just think we can… Well, even the most obtrusive notifications with a system like that will still not be that obtrusive, and not be that glaring. It won’t be bright orange or whatever it is, all those sort of horrible UX decisions that get made.
Yeah, I don’t think there’s anything really bad that can come out of a proposal like this, in my opinion.
Mary Job: Yeah.
Birgit Pauli-Haack: Oh, yeah.
Mary Job: Sorry. Go on-
Birgit Pauli-Haack: … totally. I agree totally. After 19 years, I think it would be really… It’s good to have a team looking at it, and the team has been working on this for a few years now, on and off, because… Yeah, some of us have life outside of WordPress. But, yeah. I’m glad they got to the next step in showing the world what they’re up to. And that is always good because now feedback comes in.
Especially also, for the planning developers, because admin notices are important. Yeah, but what are the importance of this, and how would you work it if you’re a plug-in developer as well? So, yeah.
Mary Job: Awesome. I look forward to testing it and giving you my own feedback on how it works. So, yeah. Okay.
So, moving forward to our section on community contributions. First up, I’m happy to let you know that the first block teams are now available in the WooCommerce marketplace. This is exciting.
So, if you’re building Woocom masters, Bonum by Themes Kingdom was the first. This particular one favors a great set of patterns for all kinds of sellers.
The second one also just landed, and it’s called Basti by Ana Segota of Honorary Design. As always, this one shows off a beautiful design, and it has great attention to detail. It also provides wonderful patterns, and also some great style variations for your buttons, columns, and other books. It also has some great overall style variations that would let you change the character of the theme. On installation, you would find a set of four design variations, depending on the nature of your business.
Jamie Marsland is a review of this particular team. So if you’re building newcomer sites often, you should also take a look and explore this block teams.
Birgit Pauli-Haack: Yeah. Yeah, Jamie Marsland did a review, an eight-minute review of it, and really did a deep dive into it. And I was always wondering, yeah, with the block themes, what would make a theme, the value that of cost? Yeah, what would I pay for when I buy a theme that is full-site editing, and it’s definitely the style variations for my buttons, or for every block, or/and it’s also the style variations for the global styles.
And, of course, the nature of the patterns, and how they fit into the versatility of the theme. So, I think this is very well, both themes, the Basti theme, as well as the Bonum theme in the Bonum marketplace. It pretty much says it all in the marketplace announced there are free themes in there, but those two are not free themes. There are both premium things, just to do a little caveat there.
Mary Job: All right.
What’s Released – Gutenberg 13.7
Birgit Pauli-Haack: So, that brings us to our what’s releases section, and we released yesterday or the Gutenberg team released yesterday, on Wednesday 20th, the Gutenberg 13.7. Yeah, Gutenberg 13.7 brings an updated model design. And we’ll talk about the features later.
So, this release comes 167 PRs with 58 contributors, including four first-time contributors. So, excellent. Kudos to all the contributors who helped with the release.
Ryan Welcher: Sorry. I just want to say that it’s been fairly recently, I think, in the release post that we’ve been specifically calling out first-time contributors. I think it’s probably not that recent, but I think that’s phenomenal. I know when I was first trying to get my first core props, it’s just such a win. It’s such a huge win, and you feel so good. And it’s great that people are calling, that they’re getting mentioned every two weeks, as opposed to every six months, or three months, I guess, when the next version of WordPress comes out. I just think it’s great. It’s such a good way of thanking people that are putting in their time to get this done.
Anyways, sorry. Continue.
Birgit Pauli-Haack: If you want to know who the new contributors are, check out the release post because, on the low end, after the Changelog, you’ll see who they are and what did they contribute? So, you can see also, is it something that you would want to do? Or just thank them personally when you know them, or when you see them in Slack.
So, there are a few enhancements in that release. One is the update of the model design and it’s subtle, but it’s very, very helpful because it provides you focus on what you might want to accomplish because it blurs the background. It kind of comes up on top of the page, and then blurs the background a little bit. It also reduces visual noise in the corners. So, it’s definitely a quality-of-life enhancements, as we call it. But it’s definitely something that will replicate through all the models. So, it’s the preferences, it’s the keyboard shortcut, it’s the… Or any other model that’s kind of in use.
For the theme developers, the next one is… You will really find that helpful, but now there’s text decoration support for the post title block, which was still missing, especially when you do for query blocks or something like that.
And then, there’s also now a change in the featured image. No, in the media placeholder. Now, if you use an image block or a cover block in a post, you can actually say you want to use the featured image, so you don’t have to reload it up again into the post, if it’s a featured image, and if your theme doesn’t show it already with your single post. And in the query blocks, you now can use them in your templates and you just have one click where you can select the featured image. You could do it before, but you had to click twice in the toolbar to actually attach the featured image to that block.
Yeah, Mary, Ryan, if you have anything, yeah? Feel free to comment.
Ryan Welcher: Yeah, I think that kind of changed just to make it easier to do something, like two clicks doesn’t seem like a lot, but if you’re building out hundreds of pages, two clicks ends up being a lot of time, right? So, being able to reduce even down one click, it’s nice. I think it’s great.
Birgit Pauli-Haack: Yeah. Yeah, it’s half the time, right? And it’s not always two clicks. It’s also that you have to move them out to find the click, yeah. So now, that is all much nicer.
A similar redesign was made also for the document settings. That’s on the sidebar, not the block settings, but the post settings for post or page settings for the page. So, in the previous releases, the post settings panel in the side bar was already redesigned. And in this release, it all becomes a little bit more refined. So, the fields for post format, slug, template, and authors are now aligned, and they all have the same width.
And then, the template displays the default template string instead of none, so it opens up the dropdown box to select the new one, or edit the existing one.
Also, the perma link opens now. If you want to change it into a pop-over to edit it, and it’s a much nicer experience than trying to fit it into the small screen there when you want to re-edit the slug. So, the result is cleaner. It’s more organized, and should help to readily access the important information about the post and page at a glance.
Ryan Welcher: I’m just going to say, again, these kind of changes just make… They’re all quality-of-life changes, right? It doesn’t really matter to your website if all those things align, but it’s some visual dissonance, and stuff like that. So, yeah. It’s nice to be able to….
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … to refine these things as we move forward, as the project move forward.
Birgit Pauli-Haack: Totally agree. And when you look at the release post, and there is… The design team put two images together, and the web episode org side has a compare block where you can have before-and-after pictures. And then you have a slider in the middle of it, and you can slide along. That’s in there, but for this one, you just see the two sidebars next to each other. And it’s so weird, yeah? I’ve never noticed how disjointed it actually was before than it is. And now that it’s in order, yeah, it’s so much nicer to look at. Yeah.
Yeah, and now we come to the bigger feature. The biggest feature that’s actually in the release is that you now can create templates for all kinds of different post types, different taxonomies, specific terms, specific categories on tags for authors. You can even create a custom general template.
So, when you add or edit a template for custom post types and taxonomies, you can do it for a single post. So, you get a list, for the single custom post-type pages that you can select and then edit or create a new one, if your theme hasn’t provided them, because you just created your own custom post type with a plugin or something like that. You see it in the Add New Template for it. So, that’s pretty cool.
So, you can, for instance, have a different template on your blog. You can have it for personal blogs. Blog post, you have a different template than for a developer-related blog post, or a third one for travel posts. So, you can do a lot more creativity here. And if you have custom post types, as I said, it’s already automatically in there.
I already got a question on Twitter after I tweeted out the new features about the new plugin. And there was a question, “So, how do I get an archive post type? So, is there an archive for my books? If my post type is books, can I have an archive?” You can, but not with the template engine yet. You can certainly do a new page and pull in the query block, which already covers the custom post types. But that is the only template that has not been yet created. It’s in the works. I saw the tracking issue for all the different templates that developers want to create, and that one is the only one that doesn’t have a checkbox. It was pretty interesting.
So I think that’s pretty big because without….
Ryan Welcher: It’s huge.
Birgit Pauli-Haack: … access… Yeah.
Ryan Welcher: Yeah. Oh, sorry. Yeah, sorry. I didn’t mean to… For theme developers or anyone, really, who’s building block themes, this is massive. Because one of the things that I’ve heard is the… When it first came out, we couldn’t do… We can’t create the theme templating system that WordPress has had since, I don’t know, Version 1 on the PHP side, in the full-site editing experience, until now, basically. Right? So it’s huge because there are so many times where just having that specific template that you want to have for a very specific thing meant that you had to go and create a new file in your theme, upload that to your server, or whatever. And then, you could work with it. But now, I mean, it’s going to put a bunch of developers out of work. I mean, it’s not. I’m kidding. But a lot of that, it’s not completely in the hands of the admin, which is great.
Birgit Pauli-Haack: Right, right. And yeah, for those who design themes, it’s definitely, you don’t need to have access to the final theme file system anymore. Yeah?
Ryan Welcher: Yeah.
Birgit Pauli-Haack: And you don’t need to know about the template hierarchy that WordPress has because it kind of gives you a clear jumping point for the next block template that you want to create. So, it definitely expands the reach of the creativity or template editing beyond just the developer. Yeah, I really love that.
So, the next step for that would be custom fields, right? How to-
Ryan Welcher: Yeah.
Birgit Pauli-Haack: … surface custom fields and custom post templates. Yeah. So, it’s going to be interesting to see what will be next for WordPress and the block editor.
Ryan Welcher: I don’t know if this is in the works, but I just recently built a site for a friend of mine. And there was a lot of… It would be great if you could create a template that was inherited from an existing template. Maybe there’s a way of doing it. I haven’t really dived into it that far, but I can see that being something that people want to do. Like I create a new template for a very specific tag. I don’t want to have to go and set my header in my footer again. I just want to inherit that from whatever, from a template. So, if anyone’s listening.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: That’s what you should do.
Birgit Pauli-Haack: And it’s geniuses all kind of think alike. So, there is actually an issue in the GitHub repo, or at least it’s talked about that those templates shouldn’t start from scratch on a blank page. They should have some default, be it the header and footer in there so it kind of starts out like a page on my site and not so much, “Okay. What is missing here?” Yeah, kind of thing. Because the surprise would be that if it’s a white blank page, and you just put the things in that you want, it won’t have a header and footer right now, but that is definitely in the works. Yeah, you’re absolutely…
Ryan Welcher: Yeah.
Birgit Pauli-Haack: … right.
Ryan Welcher: Which I think would be great, yeah. Because I think the path of least resistance is where 90% of the people are… That’s 90% of the use cases. I just want a new tag template, so I don’t want to have to go and reset up my whole page. If I want all that, then I probably wouldn’t have any problem saying, “Copy this template,” and then changing the things that I need, as opposed to brand new template. And I got to rebuild all things, and maybe I have to match settings and stuff. Anyways. It sounds like it’s definitely on the radar, which is awesome.
Birgit Pauli-Haack: It is, yeah. I don’t know how the implementation will look, but there’s definitely, yeah , the GitHub space. You listeners, if you want to do some input, there’s always great discussions on GitHub on how to approach a feature like that, that hasn’t been done before. And that’s actually the beauty of community, yeah, that more people have better ideas, and it comes out of better product.
All right. Another quality-of-life, so to speak, or a start of a new feature is in the Information Panel on the Editor. That’s the little eye circle. Now has received a new number, and that’s the estimated time to read in the Table of Contents in the Editor. So, next to the numbers of words and characters and numbers of blocks, numbers of headings, numbers of paragraphs, the sixth one is now estimated time to read for whatever this asset is.
And I really like that because then you can kind of gauge, “Am I too long now?” Or, “Do I need to put a TLDR on top of it because it’s now longer than two minutes?” Or something like that. Yeah, you can kind of build your own rules around this. Not rules, but kind of think about your own rules, yeah. Yeah?
Mary Job: Yeah. You can also copy that instead of using a plugin, add a plugin to your site to do that. You can just copy and put Estimated reading time at the top of all your posts.
Birgit Pauli-Haack: Yeah. Yeah, of course, it would also be better. So, it’s only displayed in the Editor right now, and it cannot be used on the front end without additional feature. But I put in a feature request for a new post, Time to Read block in GitHub. So chime in, if you want to, and kind of have a bubble up. It would be one of the new blocks for a post, and that you can use in a query block or even on a single a post template, yeah.
So, that’s kind of for the enhancements. We’re quite a few… Not the big swings, but they are apart from the huge amount of templates that you can create now.
Ryan Welcher: There’s one that we skipped over from full-site editing, Birgit, that I just wanted to call out.
Birgit Pauli-Haack: Yeah, please.
Ryan Welcher: … Apply to the block locking that applies to air blocks.
Birgit Pauli-Haack: Oh. Yes, yes.
Ryan Welcher: I think that’s fantastic. Was it 5.9 that released that block locking came out? Or was it 6.0. I can’t remember. But the ability to go in and lock a block, and now you can apply that to any of its children blocks, which I think it’s a huge quality-of-life thing, which is so nice.
Birgit Pauli-Haack: Yeah, yeah.
Ryan Welcher: Because that’s a lot of work, especially if you have nested blocks and nested blocks and nested blocks, you have to go in to every single one and mark them and lock them, which is great.
Birgit Pauli-Haack: Yeah. Now you have just a little toggle switch on the bottom of-
Ryan Welcher: Yeah?
Birgit Pauli-Haack: … the module, and where you say, “Apply to all blocks in this container.”
Ryan Welcher: Which is great.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: So, that could extend the patterns, which would be great, because you could probably have your patterns start out as locked. And there’s a lot of options here. Block locking’s a really powerful tool, especially when you get into user-based block locking where, as a administrator, I have access to all the blocks, but as, say an editor, I can’t move two or three of those blocks. When you get into that level of editorial control, especially across a team, it gets super, super powerful.
Birgit Pauli-Haack: Yeah. And we will later on also talk a little bit about the new handbook page about that. Yeah.
Do you know anything more about that? Or any comments?
Ryan Welcher: Yeah, I think it’s super powerful. I think one thing that, as a block developer, errors are problematic because they’re hard to track. They’re hard to track down. So, if you’ve ever seen this sort of Cannot Display Block and An Error Occurred, that’s the error boundary. So basically, the way the react works is it’s wrapping every error, and it catches it all and says An Error Happened.
So what this API allows you to do is, when that error happens, you can actually do something with the error message. One of the examples in the pull request is, if you were going to Century, Century I/O, I think it is. It’s an error logging tool, right? So if you had a block that was, say, hitting an API that you wrote or whatever, and you wanted to log errors back to Century to be able to see what happened, this enables that. This allows you to do really complicated things.
Or even if you just wanted to, say, fire a notice, and say, “Hey, you didn’t input your API key. That’s why this failed,” that helps to give your user a better indication of why their block failed. Now, hopefully, you shouldn’t be having a block fail in the wild, sort of thing. But sometimes we need certain things to be in place before these blocks will work. But I… Yeah.
So I think it’s the beginning of a lot more developer experience, style of quality-of-life changes, things that allow the developers building these blocks to be able to handle things more gracefully, specifically errors. Especially… Yeah.
So, I don’t know. I think it’s really, really good. It’s super interesting to me, but I’m a big developer nerd, so I think it’s… I don’t know a lot of use cases for it right now, but I can definitely see it growing. As it matures, it’ll be more and more useful.
Birgit Pauli-Haack: Well, there were quite a few bug fixes coming out of it, but I think that there was none that actually jumped out at me and said, “Oh, thank God that it’s fixed now,” kind of thing. But, of course it’s also… Yeah. It’s in the… Yeah, it’s every personal experience is a little bit different.
But we come to the documentation settings. And Ryan, you have done quite some work there to enhance or make the documentation better through the Generation Tool.
Ryan Welcher: Yeah. It’s always been a bit of a pet peeve of mine that the Block Editor Handbook has got a lot of information, and it’s great. And it’s all generated dynamically directly from the Gutenberg repository. But there’s not a lot of code examples. And, specifically in the data store realm, there’s a lot of… You can see what is available to you, but using it is sometimes a lot more complicated than just, say, making a call to a function.
Part of what I’ve been working on is the ability to… Well, adding all examples for as many packages as I can. We have examples now for the Get Notices package, so you can use those. The other part that I’m working on is removing things from the documentation that probably shouldn’t be there for an end user.
For example, this is a bit in the weeds, but when you’re dealing with data stores specifically Redux-based data stores, which is what Gutenberg is basing its data stores on, you have these functions called Actions, and some are only dispatched or run internally to the store. So the store says, “Get me a thing,” and then that thing gets returned. And then the store internally says, “Oh, I’ve got that thing. Now I could do something else with it.” So those actions aren’t ever going to be used by a developer using a public API.
So, one of the things that I’ve been working on is adding a support for a doc block tag that will basically exclude things from the documentation. And so, that’s a big win, I think for us, because it’s already complicated and the functions don’t really explain what they do, and they shouldn’t be used at all because you would never call them. It wouldn’t make any sense. And if you did call them, it’d probably just break the data store. So that’s one thing.
And so, another thing that I’ve been working on is… Actually, I guess that’s it. They ignore stuff. Getting examples in, I just literally merged half an hour ago a PR that gets rid of all of the internal actions for the data package, which is great. So it’s going to reduce the amount of documentation, but make it more concise. But, yeah. It’s a long process. There’s like 10 packages and there’s a lot of selectors and actions that I have to document.
So, if anyone wants to help, there’s a tracking ticket in Gutenberg.
Birgit Pauli-Haack: Oh, awesome.
Ryan Welcher: … all of our sections, yeah.
Birgit Pauli-Haack: Yeah, I’ll find that for you. And we’ll share the tracking issue link in the show notes, so you can jump on board. It could also be quite interesting too, because that gets you a little bit into the weeds, but not deep enough.
Ryan Welcher: I will tell you this; you will know the package inside out and backwards, because you have to write documents. You have to write examples that work. You have to figure out how they work, and then you have to figure out a real reason to use it. I know lots about this now, way more than I ever thought I would, but…
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … Yeah.
Birgit Pauli-Haack: Excellent.
Ryan Welcher: So, it was a great way to get right into the API.
Birgit Pauli-Haack: I wanted to also… So, thank you for doing that, picking up on that.
Ryan Welcher: No problem.
Birgit Pauli-Haack: And going through with it. What I also found on the documentation, how it’s also part of the documentation revamp, or more people looking at documentation from a point of developer experience, or is that we might reorganize things. Yeah, so having a different header or a different pass to a certain document, or even the document URLs changes. But we need to have a redirect directly attached to it, so we can say, “Okay, this old page now needs to redirect to the new page,” so we don’t lose people that have been in that documentation for a long time.
And yeah, I connected with the Mater Team and figure out how can this be done on the Gutenberg manifest, the JSON repo. Yeah, to also add the redirect later on, so when they import it to, when the importer, into the webpress.org pages, then also can take care of those redirects directly, and not have a second step to it.
Ryan Welcher: I think that’s great. I think that’s going to allow us… Us, the Royal us. Is that a thing to-
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … to be more fluid with the docs because I know that’s been… Our docs… If you look at some of these pages, they’re massive. They’re just super long, and there’s that there’s that zero to expert problem that we sort of have in the documentation realm where, “Here’s a basic example, and now here’s all the information you’ll ever need to know about it ever.” And it’s all kind of on the same page. And so, if by being able to be more dynamic with how often we change pages, and we can set redirects and things, it’ll allow us to kind of play with the documentation format, and maybe we can be a bit more. We can play a bit more fast and loose with it and try things. And it’s not a huge undertaking, and people don’t lose all their bookmarks, and it’s bad times. So I think it’s great, being able to do that.
Birgit Pauli-Haack: Yeah. And I wanted to bring it back to what you talked about before, the locking experience for… There is a new page in the Block Editor Developer Handbook, and that is called Curating the Editor Experience. And you’ll find it under the How To Guides. And it talks about the locking API, what the user can do, and how you can suppress that, and how you lock patterns or templates, how you can set the permissions, change the permissions to the control-locking ability with code examples. Very well done. And providing default controls and options in the theme JSON file, and how to find how to work that.
And then also, to limit the interface options to the Theme JSON. That’s the global styles kind of on the right-hand side. Yeah, you don’t… not necessarily want somebody to use the custom color or to use the custom doer tone links because you want to stay on design color, on brand color, all that.
There was a make blog post about it, but now it’s in the handbook and it’s… If I look through it, I find it really comprehensive. And it has some nice section adders, and additional resources that are also on the Learn. So there is one video on the WP space from the Learn Worker space. It’s working with templates and full-set editing. And, yeah.
So that’s a great page, and that is new. And yeah, I love that it’s now all in one place and not distributed over the whole web universe, because somebody found something and shared it. But then, yeah, I can do that, but I also want to lock down this, so now you have it all on one page.
Ryan Welcher: That’s great.
Birgit Pauli-Haack: Yeah. There are a few experiments that are called, globally, the style engine, and there were some updates there. I will share the style engine tracking issue. And there’s also a block layout tracking issue for that. So you can stay up to date in what it’s all about. It’s pretty much how styles are treated from theme to block, to elements, and back again, in terms of how you can change things, yeah. Because, for some of the things you have UI, and for some of them, it’s only in Theme Jason. Some of them, you need to still do with CSS. So, there’s quite a big work to be done to standardize that.
I think that’s it. Do have anything else that you… Oh, yeah! That was the first idea that I had when I thought about getting Ryan on the show. There’s a section in the grade block about the grade block script. And that is that you get a prompt for minimum system requirements, if they are not met. And also, careful prompts to, yeah, how to continue with that. And it also fixes a regression from the size, underscore size refactoring.
So, great block. Ryan, you have done quite a few demos, and quite some work on it. What does it do for those who haven’t heard about it?
Ryan Welcher: Well, it’s my favorite package in all WordPress, first of all. What it does is…
Birgit Pauli-Haack: And now, we get into the second hour of our podcast.
Ryan Welcher: Yeah, yeah.
Birgit Pauli-Haack: … easier a bit.
Ryan Welcher: Do you have a minute?
Birgit Pauli-Haack: Yeah.
Ryan Welcher: Do you have an hour and a half?
Birgit Pauli-Haack: Yeah, I have a minute.
Ryan Welcher: Okay. Sit down. Let me tell you about Create Block.
It is, basically, the TLDR is that it is the tool that allows you to quickly scaffold blocks. So it will create a plugin, and it will create for you a block, a scaffolded, simple block that you can then do whatever you want with. So it’s very, very powerful.
It can accept custom templates. You can write your own templates and publish them. The NPM, you can use local templates. So if you have a very specific way that you like to build your blocks, or work for an agency, and your agency’s got a very specific way, you can create a template and have the Create Block package just refer to that template, and it’ll build blocks out for you however you like. It’s super powerful.
So, the two pull requests that are in there around a prompting, there are some edge cases when it comes to, I think it’s Linux, and maybe a bit of Windows, that for where we were getting some false positives. When you run Create Block, what it does behind the scenes is it checks to make sure you have the right version of, know the right version of all these things installed.
And sometimes, depending on the platform, it would say, “That’s not right. You’re missing,” and whatever, and it would just stop, so you couldn’t use it. So, what this is allowing you to do is it’ll say, “Hey, I don’t think you’ve got the right things. Do you want to still go?” And if you know that you do indeed have everything you need, you can continue the process. It makes it a lot easier, because it’s a huge blocker for someone that’s not maybe working on the most sort of standard system set-up, that they can’t use this tool, even though they know they’ve got it set up the way they want it, and that it’s set up correctly and it will work, that the tool fails.
So, that’s what this is all about. Just allowing us… Well, it just drives adoption. It just allows more people to use the tool. The last one, the fixing the regression from size, there was a internal effort to move away from Lodash, I believe.
Yeah. _.size is a Lodash function. So this, it was moved away from using Lodash, but then they found that there was a regression, so they fixed it, and that’s all that was. But-
Birgit Pauli-Haack: Yeah.
Ryan Welcher: Yeah.
Birgit Pauli-Haack: Yeah, it is, actually…
Ryan Welcher: … dependencies.
Birgit Pauli-Haack: … a huge effort to move away from Lodash for performance reasons. And if you count in the change lock all the PRs together that are listed, you will not get to 167. You will only get to 120 or 30 because there were about 40 different PRs that touched quite a few files to move away from Lodash.
Birgit Pauli-Haack: Yeah. And I wanted to… Create Block is also my favorite tool, and I just wanted…
Ryan Welcher: Yeah, me too.
Birgit Pauli-Haack: … to add many people tried it out before, and they were only kind of fixated on single blocks. But now you can have… I don’t know if that’s already implemented. I know you were working on it to allow for multi blocks?
Ryan Welcher: Multi blocks? Yeah.
That is actually built into the Scripts package, so you don’t need to have a special template. And so, originally, you needed to have a special template and a special Webpack file that would allow you to build a multiple blocks using a single-build process.
So, myself and Greg, who’s an alumni of Gutenberg changelog. We worked really hard on working on scripts and Create Block to allow scripts by default to handle multiple blocks. It wasn’t just us. There was a lot of people, and Greg did all the heavy lifting. I’m just taking credit for it.
So now, if you, if you structure your setup in a certain way, basically putting a block that JSON file inside of a directory inside of your source files, your source directory, the Scripts Package will see it and it will create a block for each one of those that it finds. So we don’t need anything custom to do that.
What we are doing with Create Block, and this is hopefully going to get in soon, is we are trying to make it so you can just scaffold the block, so when you run Create Block now it will scaffold an entire plugin, and then put a block inside that plugin.
What we want to be able to do is have it scaffold the plugin, and then if you run it a second time with a flag, it’ll only just add another plugin to your existing one. And that’s-
That’s something that’s going to add a lot of power to it.
Birgit Pauli-Haack: All right.
Ryan Welcher: And we’re sort of working on that now. And we’re also working on the ability to of, within this, we could do a whole nother podcast on this, so I’ll stop.
Birgit Pauli-Haack: Maybe we should.
Ryan Welcher: … a lot of cool… Yeah, there’s a lot of really cool things coming for both scripts and Create Block.
Birgit Pauli-Haack: And I also know there is a flag that you can set when you create it that it’s going to be a dynamic block.
Ryan Welcher: Yeah, sure. That’s not merged yet, but that is-
Birgit Pauli-Haack: Okay.
Ryan Welcher: … the other one. Because we are working on making that as simple as possible, there has been talk of, instead of it being dynamic block, it would be like dash dash variation. And then you can tell it’s static or dynamic, or if there’s another type that gets introduced along the way. We can do that as well. So, we’re still working on that. It’s definitely something that I don’t think anyone’s could going to say no to. It’s just a matter of making sure that we get it right before it launches, because it’s really hard to change something after it’s out in the world. So, yeah. So, there’s a few things that Greg and I have been working on, that I think is going to hopefully make Create Block the defacto package for building blocks.
Birgit Pauli-Haack: That’s awesome, yeah. Yeah.
Ryan Welcher: That’s my pitch. That’s my elevator pitch.
Birgit Pauli-Haack: Very good. And this was a great segue into our What’s an Active Development were discussed. And one is that I mentioned about documentation be restructuring. And we mentioned Greg. So Greg has gone in and has looked at the hooks references for the Block Editor and found that the documentation is using the term hook filters differently than the rest of the WordPress documentation. Because there are hooks with actions and filters, not just filters. So, he wanted to restructure the reference for that. And he has. The only thing, he hasn’t changed the name on the titles yet. He has changed the page title, but not the slugs because we discovered we needed a redirect thing. So this was merged. It’s in the handbook now, but the slug does not match the title of the page, which sometimes a little unfortunate. But that’s definitely updated. It will come, and it’s already in the handbook because the handbook updates are not tied to the release. Yeah, they are listed in the release notes just to have them, give them a place, but they are, pretty much as soon as the PR is merged into Gutenberg, within 15 minutes, the documentation page is updated. So, that’s actually a great process here.
Ryan Welcher: It’s great. But it can also be a little bit… And this is probably something that we can talk about. But because it’s built from Trunk. Trunk is the bleeding edge of everything that’s in Gutenberg. And since, sometimes, things end up in documentation that aren’t released in Core and aren’t released in any plugin versions. And there’s no sort of simple way right now of indicating that.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … But it is awesome that when documentation gets up… Like I merged my poll request just before we started, and it’s already live.
Birgit Pauli-Haack: That’s awesome.
Ryan Welcher: The doc changes are already there, and that’s great. But, yeah. So that’s something to keep in mind.
Birgit Pauli-Haack: Yeah. Keep in mind that it’s not a version control. It’s just a bleeding edge and it also doesn’t disseminate between what’s in WordPress and what’s just available in plugin and future WordPress. So, yeah. It’s sometimes we need to kind of read it a little bit carefully, especially when you are an early adopter of things and love that life on the bleeding edge. Yeah, sometimes it gets you there bloody, yeah. Oh, leading edge. Not that, yeah.
Another thing that’s in the works is, and a lot of people definitely have been waiting for it. It’s the fluid typography. So, the first iteration is already merged, and will come to 13.8. It’s still experimental, but for theme developers only in theme JSON to have the settings for the fluid typography. So, they set minimum and maximum sizes for the font, and then it automatically expands and… Or is it expands and…
Ryan Welcher: Contracts.
Birgit Pauli-Haack: What’s the other one, word?
Ryan Welcher: Contracts.
Birgit Pauli-Haack: Contracts. Yeah, not a D. It was of long wrong. Yeah.
And if all is good, you can test it with Gutenberg Nightly already. Or you wait for the Gutenberg 13.8 coming out on August 3rd.
Dave Smith, who was, I guess, here on the Episode 68, he is experimenting with a feature to actually attach custom labeling to blocks in the list view. And that has come up quite repeatedly in the call for on the FSE program, and also in the user testing that when you have more group blocks in your page, that it’s hard to kind of find the one that you actually want to work on. And because they’re all called group blocks, and you have six or seven of them, or three of them, you hit them no say, “No, that’s not it. That’s not it,” yeah. But if you can give them a name, then you can identify them.
The same is with headings or even with paragraphs, yeah. You can kind of, each of them. It’s not merged yet. It’s a PR that you can… And I’ll link it in the show notes that you can maybe even test out there. And it just gives you… You click into the block row where the block is mentioned, and then it opens up an editing field that you can write in, yeah.
Ryan Welcher: I think this feature… I think it’s very cool. First of all, it’s something that’s needed to be able to… If you’re in the list view and you’ve got 20 blocks, and it’s hard to know what’s what. But a side effect of this, which is something that actually just came up in my livestream today, when we were trying… I think I said this earlier… But we were trying to have one block refer to another block, and get its attributes, and then do something with those attributes in the first block. And the issue that we were running into was, there’s no unique identifier for blocks that are persistent. So, they’re in the bowels of the code. There is a Client ID that you can get access to, but that Client ID is refreshed every page load.
So having something like this, a really cool side effect is that now we’ve got a unique identifier for a block. So you can give the block a name, and then that… Because in the implementation, I believe they’re saving it as a block attribute, so it gets saved with the block. So now, other blocks can get that block by getting the list of blocks and filtering by that attribute for the thing that they want.
So I think that that… I mean, this is a perfect case of we built for one thing, but now there’s a whole nother use case that people can really use it for. And I’m super excited about that.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: I will-
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … I will help Dave with it.
Birgit Pauli-Haack: … And it probably would be helpful to keep that in mind when the first iteration comes out. Yeah, how that can be used in plugins or in… Yeah.
Ryan Welcher: Yeah. Yeah, I’ve already-
Birgit Pauli-Haack: Or because it’s…
Ryan Welcher: … left a comment on the PRs. Yeah, it’s so powerful.
Birgit Pauli-Haack: But it’s-
Ryan Welcher: The user…
Birgit Pauli-Haack: Yeah, but it’s user controlled, so the plugin doesn’t know what the user going to do. Yeah.
Ryan Welcher: That’s true. Yeah.
Birgit Pauli-Haack: Yeah. So, it’s-
Ryan Welcher: I mean, in the use case that I’m talking about, it’s sort of you would need to have that user level to connect those two things anyways. But it solves the development problem of, “How do I make a connection between two blocks when I have no unique identifier anywhere to save as a reference?” There’s no Block ID that’s persistent. It’s always new every page load. But this could potentially solve a problem like that.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: … cases around the same name. What do you do with the same name? But that sort of stuff.
Birgit Pauli-Haack: Yeah, yeah. All of that. Yeah, yeah.
Ryan Welcher: And it’s very cool, though.
Birgit Pauli-Haack: So, it’s not because it’s experimental and it’s relatively new. We don’t know when it’s going to be merged or when it’s coming through the Gutenberg Nightly, but that’s kind of that a little PR bleeding edge or leading edge, sorry. I need to kind of get the bleeding out of it.
And that is pretty much the end of our Changelog today. So, Mary and Ryan, is there anything that you want the community to know or remind them of, before we end the show so they can kind of look out for it, or see you, or…
Ryan Welcher: Well, I’m going to shamelessly self-promote. You can watch me every Thursday at 10:30 Eastern at on Twitch. My handle’s Ryan Welcher Codes. I’ve also got the YouTube channel with the same name, Ryan Welcher Codes. So, anything on my stream, that’s anything that’s decent, I usually put on YouTube. And, yeah.
But yeah, we do all kinds of coding stuff, usually block-related. So, that’s my shameless.
Birgit Pauli-Haack: Excellent.
Ryan Welcher: … self-promotion.
Birgit Pauli-Haack: Yeah, super. And we’ll put, of course, the links in the show notes.
Mary Job: Well, on my end, I’m good. I’m good. And I like what Ryan did. You know what they say. They say, “If you don’t promote yourself, nobody’s going to do it for you.”
Ryan Welcher: Awesome.
Birgit Pauli-Haack: Yeah.
Ryan Welcher: Thank you.
Birgit Pauli-Haack: Yeah. Yeah. So… And before we end the show, I just wanted to remind you, dear listener, that if you like the change of podcast and of… Write us a review, either on Stitcher or on Apple or on Google. It helps us promote it and kind of get more people interested in it, and they know that it’s around.
And then, as always, the show notes will be published on gutenbergtimes.com/podcast.
This is episode 70. And if you have questions, suggestions or news you want us to talk about, send them to firstname.lastname@example.org. That’s the email address at email@example.com. Or you can always ping me on Twitter, BPH, or Gutenberg Times. All the DMs are open, so I’ll also look at them.
Well, a huge thank you to Ryan to join us today for this hour, and bring so much new interesting stuff there.
Thank you so much, Mary. It was great to see you again, and talk to you.
And I’ll see you next time in two weeks.
Mary Job: Thank you, sir.
Ryan Welcher: Thank you for having me. It’s always fun.