Category: wptavern.com

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how a block plugin creation can be speeded up with the create-block tool.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast I’m keen to hear from you, and hopefully get you, or your idea, featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today we have Ryan Welcher. Ryan is a developer advocate sponsored by Automattic. He has been developing with WordPress since 2009. And before becoming a developer advocate, worked for agencies large and small, and as a freelancer.

If you’ve been using WordPress for any length of time, you’ll have come across the new paradigm for content creation, blocks. Every part of your website can now be created and amended as a block. Pages, posts, text, images, headers, footers, navigation, and more.

This has widened what’s possible for those who don’t want to mess around with the code of their website. You can add in blocks for almost anything. And change how it looks and behaves from within the block editor interface.

This is an excellent move forward, but there’s still an impediment for non-technical people because creating a block of your own is difficult. If you are able to use the selection of blocks that ship with WordPress Core, or you can find a third party block which does what you need, great. But if you need something specific, you’re going to have to create your own block solution. And that can be hard.

Ryan is on the podcast today to tell us about the create-block tool. And how it can make your pathway towards block creation a little easier.

We start off talking about Ryan’s background and how he became interested in WordPress.

We then move on to how he thinks that the adoption of blocks is becoming more widespread given the maturing of tools and learning materials available.

The conversation then turns to how the create-block tool can help you scaffold your blocks. It’s not a tool which is going to build the blocks for you, but it will help you set up the environment and build process, which you need to get started. Really it’s all about saving you time and effort on things which don’t really you get you building your blocks, but which you need to do that work.

We discuss what you can expect from the create-block tool, and the prior knowledge that you’ll need to have once the tool has you up and running. What level of expertise do you need, and is the tool under continual development?

We spend a few moments talking about the live streaming which Ryan does each week in which he lived code solutions to view as block-based problems.

If you’ve thought about creating your own blocks but have been put off by the technical barrier, this podcast is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast. Where you’ll find all the other episodes.

And so without further delay, I bring you Ryan Welcher.

I am joined on the podcast today by Ryan Welcher. Hello.

[00:04:29] Ryan Welcher: Hello. Thank you for having me. Super excited to be here today.

[00:04:32] Nathan Wrigley: I’m really, really happy to have you on the podcast today, because I really need to learn what it is that you are going to be talking about. We’re going to be talking a great deal about the Create Block Tool, how it works, what it does, how to make it come onto a local computer near you. But before we do that, I wonder Ryan, if you wouldn’t mind spending just a few moments telling us a little bit about yourself, your backstory, your relationship with WordPress, who you work for, all of that’s good stuff.

[00:05:00] Ryan Welcher: Yeah, so I am a developer advocate. I’m sponsored by Automattic. So I’m part of the five for the future, giving back to the open source project that is WordPress. I’ve been a developer since about 2004. I started doing flash development. I don’t know if anyone remembers flash development, but I started doing that. In 2009 I was introduced to WordPress and I haven’t looked back.

Since then I’ve worked at, I was a freelancer. I worked at small agencies, large agencies, shout out to 10up, which an amazing place to work, I love that place. Yeah, and so I’ve just found my way into Dev Rel, which is a very, very fun and exciting and challenging, and way different than what I was doing two years ago. But it’s been great.

[00:05:41] Nathan Wrigley: Can I go a little bit off piste, against the flow of what the conversation will be about? Could you just tell us a little bit about the way that that job works? So you are sponsored by Automattic, is that a full-time thing?

[00:05:52] Ryan Welcher: It is. I work on a team of Dev Rel, of developer advocates, and our job is to appear on podcasts, speak at conferences, create awareness and work on documentation and do all this sort of stuff. But, sorry, yeah, I cut you off.

[00:06:04] Nathan Wrigley: No, no, it was really just, I’m curious as to how that role is advertised. Was it something that you saw in like a WordPress space, and you applied for it? And also who is it that decides what your roster of work is? Do you have autonomy there or is there a panel of people that you have to report to and so on?

[00:06:24] Ryan Welcher: Those are great questions. So it was a role that was advertised. I saw someone mention it, and I think the WordPress Slack, the Make Slack. I applied and went through the process there. As far as the work that we do, it’s kind of a mixed bag. We do have a fair amount of autonomy. This is a newer team. There’s six of us for the entire internet, so. Sorry, for 43% of the internet. So there’s a lot of work to do.

We have a focus on improving documentation. That’s kind of our number one focus at the moment. But, there’s a lot of smaller projects as well. I try to maintain the Gutenberg Examples repository, which is a GitHub repository that shows examples of working with blocks and some of the various things that you can do with Gutenberg, like a custom admin page that interacts with the data stores in Gutenberg and things like that.

So, I was just at WordCamp Asia, which was an amazing experience. I wasn’t speaking, but I was meeting with lots of developers and just kind of like schmoozing. I get to schmooze professionally now, which is a lot of fun.

[00:07:16] Nathan Wrigley: That’s amazing. I do wonder since Gutenberg dropped several years ago now. I mean, it really is, it has been going for many, many years. But there really was a fork in the road for WordPress there, and there was a little bit of tension. Some people didn’t see the purpose of Gutenberg and ultimately blocks. And I do wonder if roles like yours became more important after that. Do you feel like a need to message and get the word out and educate more after Gutenberg dropped?

[00:07:49] Ryan Welcher: I think yes. I also think that the tech industry, I mean, there’s always been developer advocates. I remember I went to a flash conference years and years and years ago, and I saw someone speak there who was, what were they called at the time? A platform evangelist for Adobe and was basically doing Dev Rel stuff, like showing what you can do with flash and the new features and cool stuff. So it’s been around.

I think now people are really starting to see the benefits of it. Especially when you have a large community like WordPress. There’s so many people. And having people who can help, you know, the education piece. And there’s a lot of yelling into the void without people like me and our team to hear what you’re saying. Like, you know, the documentation needs work. Okay, well someone needs to work on that. Now that’s my job to work on that.

So I definitely think that there’s, there’s benefits to Dev Rel in any industry for sure. But I think, to an extent, when 5.0 came out, I think that sort of showed the need for someone to come in and say, hey, you know, do you need help there? Or like, have you heard about this tool? Or what’s path of least resistance to move from a short code to a block? All those sort of things. So I think yes and no. I think it’s just overall, having a dev team for the open source project that is WordPress is a great idea to gather feedback and help and just help. Full stop.

[00:09:06] Nathan Wrigley: I think whether it’s as a result of endeavors from people like you, or just the passage of time. I get the feeling that in the year 2023, the message is really getting through. It seems like the inertia against using blocks seems to be dissipating. I really don’t seem to be exposed to too many YouTube videos or people on Twitter moaning too much about that anymore. Moaning is probably the wrong word. I should probably reclassify that, questioning it.

[00:09:38] Ryan Welcher: No, I think it’s a very accurate word.

[00:09:40] Nathan Wrigley: So it feels as though we are at an inflection point. That there’s enough time that’s passed. There’s enough projects out there. There’s enough people that have released resources and commercial products around the block space.

It kind of feels like it’s moment has really arrived.

[00:09:57] Ryan Welcher: I agree, yeah

[00:09:59] Nathan Wrigley: Maybe moving from a position now of teaching people that it exists and it’s an option, into teaching people how to use it and get the most out of it?

[00:10:07] Ryan Welcher: Yeah, I would agree with that. I think since 5.0 the block API has matured, and has stabilized. There was a couple of releases where every release, the function that you called to actually register a block in php, its name changed, and its function parameters changed.

And then there was like one version, and then the next version was a slight variation but the next version was the same name as the first version, but with different parameters. So there’s some confusion there. And you know, with the introduction of block.json, it’s the json file that describes what your block does and what its functionality is. Having those pieces sort of stable and consistent have really helped the adoption of blocks and custom blocks.

I think also, and this is a perfect segue into what we’re talking about today, the tools like to Create Block Package that we’re going to talk about introduced to best practice and showed people, how do I structure my blocks?

So when I was at 10up, I was at 10up when Gutenberg came out. And we spent a lot of time, the company spent a lot of time trying to figure out, trying to navigate how is this going to work for an agency? How do we build these things? What files go where and things like that.

And so that’s a huge amount of cognitive dissonance. When you’re trying to figure out a new api. When you’re trying to figure out a brand new paradigm. And then you’ve got to figure out, well, where do my files go? A tool like the Create Block Package just shows you where the recommended structure is. And then that takes away a lot of the guesswork, and then everything becomes consistent at that point.

And then if I’m working on a project that someone else has worked on, the files at least are in the same place. And, I think the maturity of blocks and the block API has really left a lot of the people who just didn’t like it kind of behind.

[00:11:39] Nathan Wrigley: Okay, so given that we don’t really have any accurate statistics on who’s using blocks. What proportion of the 43% of the web that’s using WordPress have moved over to blocks, or perhaps are sticking with the page builder that they’ve been using for the last several years and so on. Given that we don’t really know that, what is the elevator pitch for blocks really? What are the small things that you can mention on a podcast in a short space of time, which really nail your colors to the master and say, okay, this is the promise of blocks? This is what blocks can deliver. This is why it’s new, and why it’s worth looking at.

[00:12:14] Ryan Welcher: That’s a great question. I think that blocks offer, well, first of all, there’s no theme or plugin lock-in. So that’s a big concern with, take the example of a freelancer that is hired to build a site and the client is non-technical, but they want to be able to manage their own content.

So, you reach for some of these page builder tools, and now once you’ve reached for them, you’re locked into them. That’s not a criticism, but that is inherently one issue. So with blocks you don’t have that. Your blocks are part of core and you could still suffer a bit of lock-in, if you went with a very bespoke sort of block set or like a block suite or something, but there’s definitely some benefits there. You don’t have a lot of the overhead or any of the overhead that come with some of the larger, page builder plugins, just because they have so many features.

And so there’s some load considerations there. I think it changes the way that you can look at your content. This is a bit more of a philosophical question, but, so historically when we built a site, we had a title for post content. We had the content, which was like the classic editor. And then we had post meta, and you know tags and categories. But if we wanted to store an extra piece of information with a piece of content, there was really only post meta available to us, because the template that was being shown for the front end that would represent that piece of content ,was controlling the layout.

And so we had to store, let’s use an example of an author byline. Say we wanted to have guest authors on a site. So we wanted to store that author name. Well, on the template side you would use get post meta, the function, to get that piece of information and, and display it in your template.

Well, now we can do that all with blocks, because our template is the editor, and the way it looks is basically represented almost one-to-one in the block editor experience and the site editor. So you have this question of, do I need all this post meta now? Now I can just store it as a block attribute, and move it around and do what I need to do with it. So I think there’s lots of good reasons to use blocks. That’s a few of them maybe.

[00:14:09] Nathan Wrigley: Yeah, that’s great. Thank you. I guess the primary issue is that using something like a page builder, whether or not it’s got bloat or whether or not you’ve got the lock in and all of that, is that it’s relatively straightforward. You just click some buttons essentially. Drag things onto the canvas and you’re done. In Gutenberg we’ve got some core blocks, and increasingly you can really start to lay things out with group blocks and cover blocks and things like that. You know, you really can start to finesse the overall design.

But if you want to do anything bespoke, in other words, if you want to create a block which does something that you wish to do, something new, something interesting. Then you’ve got to create that block. And the barrier to doing that I feel is quite high. I wonder if you’ve got any thoughts on that? Whether or not the creation of blocks is still in the domain of, how to describe it? You’ve got to have a certain fairly high level of understanding of all sorts of technologies to make these blocks come into existence. Or do you?

[00:15:12] Ryan Welcher: Well, you do and you don’t. It’s kind of like, it’s the classic developer question, you know. It depends, is always the answer. Whenever you ask a developer something, it’s always, well, it depends. But, I think yes. You do need to have a certain amount of information. But take blocks out of the equation. If you wanted to make a bespoke WordPress theme, with custom templates, you still need to have a certain level of development experience and a certain level of prowess in php, html, css and things like that.

Now, that’s not to say that the barrier to entry hasn’t been raised. Because when I learned WordPress in 2009, I could just copy and paste everything I did into a theme and it worked. Now we’re with blocks. We’re looking at, build processes and learning some JavaScript frameworks in React, some knowledge there. So there is, there’s definitely some things to learn.

Now, there are some tools that can help. Again, this Create Block Package that will kind of get you started and get you a basic scaffold of a block, that you can just then change and add your flourishes to.

I think in general, web development is more complicated than it ever has been. I mean, that’s maybe because I’ve been doing it for a long time and I’m an old man who fears change a little bit, maybe. I don’t know. But I think that knowing JavaScript and Matt said, you know, learn JavaScript deeply, and it’s true. I think I felt that pain when I was, starting to work in Gutenberg. I’m a php first developer. That’s what I learned. I did a little bit of JavaScript, but not a lot. Learning these new concepts was hard. But, I think it’s well worth it.

And I think you can do things where you don’t need to know, you don’t need to be an expert in React. You don’t need to be an expert in Webpack and build process. You don’t need to be that level. If you choose to be that level, you can, but you can do some pretty complicated blocks, with sort of a base understanding of some of the pieces that you need to put together.

And I think part of my job is to help people navigate that stuff. I’m a big proponent of the Create Block Package. I’ve worked on the package. I’ve helped to add features that developers have asked for to make life easier. One big feature was the ability to have multiple blocks be part of the plugin that is generated when you run the package.

So I think there is a barrier to entry, but I think it’s mitigated by, like, you don’t need to be an expert in all the things. You don’t even need to really understand the build process, for example. It’s provided, and it’s just run a command and just know that this command does this and this command does that. And really, if you don’t want to look under the hood, you don’t have to. It’s going to work for you.

[00:17:30] Nathan Wrigley: We’ll get onto the Create Block Tool in a moment, if that’s all right. But just one last question around this whole education piece and learning about blocks. It feels that there’s a real concerted effort now to create learning materials. There’s obviously learn.wordpress.org, and a whole bunch of other things.

I see a lot of videos being created in amongst the community. People like Jonathan Bossenger and Anne McCarthy and so on. And I’m just wondering if you, well, firstly, if you feel that that’s the case, if the education piece is a lot better now than it was when you were trying to learn at 10up? In other words it’s less of an uphill struggle because you’ve got somewhere to turn to.

[00:18:09] Ryan Welcher: So much less, yeah.

[00:18:11] Nathan Wrigley: So let’s do that one first. Yeah.

[00:18:13] Ryan Welcher: Absolutely. I think, yeah, you’re right. I mean, I think that when Gutenberg came out, there was no real pragmatic, like practical, how to use this information. Because it was a new thing and there was a lot being changed and people didn’t have the resources.

They didn’t have the knowledge to build the resources. Now we’re four years in now, and that’s obviously built up. The folks that learn.wordpress.org doing a fantastic job. Jonathan’s stuff is great. I’m going to shamelessly self-promote here. I stream every Thursday at ten thirty Eastern on Twitch, where we do block development live. and I put that on my YouTube channel. And I’m not the only one. I’m sure there’s, there are people that are putting out content that is up to date and accessible and easier to figure out the things that you need to do.

Now, there’s always going to be gaps in that knowledge because the APIs are still evolving, and every time there’s a new release to the plugin, the Gutenberg plugin, there’s new features and things like that. But yeah, I think now compared to when 5.0 came out, I think there’s a lot more really good information out there.

I’m finding that there’s older information that hasn’t been updated. That’s one of the pitfalls of the writing a tutorial on your blog post or creating a video or doing whatever, is that it’s sort of a snapshot in time of the APIs. And so it’s there, but then there’s, well, hey, did you know that there’s this new way of doing whatever it is that you’re doing that’s a little bit easier, you know, faster, better, smarter, or whatever, right?

[00:19:34] Nathan Wrigley: Yeah. Going back to your shameless plug. Could you tell us a little bit more about that? So you say you go live, every Thursday, and we will get from you the URL and will post it into the show notes. Do you have an agenda for that? Do you know what you’re going to do in advance? Or is it driven by who shows up and what questions they want to be answered?

[00:19:53] Ryan Welcher: it’s a bit of both. I’ve been doing it now for about a year and a half. I’m on Twitch, which is an interesting experience. So I live code. I usually show up with some kind of agenda. Like, for example, right now, last few weeks, every other week I do a stream on the new features that have been released in the Gutenberg plugin.

If you’re not aware, the Gutenberg plugin is on a two week release cycle. So every two weeks we get a new version of that plugin, and then all those versions get rolled up and released into the next version of WordPress Core. I go through the release posts on make.wordpress.org, and we call out some of the more developery refocused things like, a new component is added or a new whatever. So we do that.

The off weeks, I usually build something. Like right now I’m building a block that integrates with OpenAI to generate images. But the images that are being generated are terrifying because I keep doing like people laughing. I don’t know if you’ve ever seen OpenAI generate people’s faces. It’s the scariest thing I’ve ever seen in my life. Have a lot of fun doing that.

I’m actually going to be doing one and I haven’t done this yet, and again, sorry for the shameless self-promotion here, but in a couple of weeks I’m going to be doing a bring me your block development issues stream, where I’m hoping that people will submit these problems that they’re running into and I’m going to try to see if I can kind of like fix ’em live. And we’re going to stream that and see how it goes. It’s going to be wildly successful or it’s going to be crickets the whole time. I don’t know. That’s usually the only two extremes you get on live.

[00:21:19] Nathan Wrigley: I do like the idea of a, like an open surgery in a way. Where people can show up and give you their problems and presumably the further in advance they can give you the problems, the more of a chance you’ve got of actually solving them. But that’s a really interesting idea and an excellent way to help educate people live, watching somebody else do it, not just on a forum or an email chain. Actually seeing it happen and get an explanation for why you’re doing things and possibly even watching you make mistakes along the way and having to fix your own things, yeah.

[00:21:48] Ryan Welcher: If anyone comes to my stream, you will watch me make mistakes Yeah, I can’t type when people are watching. There we go, that kind of sums my stream up. But yeah, it’s a lot of good fun. And we have pretty good community of people who hang out in the chat and discuss things and answer questions and help me. There’s one guy, I always make fun of him because he shows up and saves the day every time if I’m running into an issue, he’s like, here’s your code. And he just pastes it, and I’m like, oh okay, great. So now we can move on because Kevin saved my stream. So shout out to Kevin.

[00:22:14] Nathan Wrigley: That’s a, lovely community feel to it though, isn’t it? There’s something really nice about that. But definitely, before we hang up on this call, I will get the location for that and we’ll post that into the show notes. So if anybody wants to go and hang out with Ryan on a Thursday and watch him live code and possibly take your own troubles and problems and share it with Ryan, yeah, that would be a really amazing enterprise.

Okay, let’s get onto the, what we probably should have started talking about a while ago, but never mind the Create Block Tool or the Create Block Package. So one of the problems that you highlighted right at the beginning when I said, what makes blocks difficult, is you talked about the tooling and the requirements that you need just to get started. So describe the problem that the tool is solving.

[00:22:58] Ryan Welcher: Sure. So if you want to build a block, there’s a number of ways that you can do it. But if you wanted to build a block using React and JSX, which is the HTML extension, the JavaScript that React uses, you need a build process. You need the ability to take your JavaScript code and transpile, it’s a fancy word of saying turn it into something else, into JavaScript that the browser can read.

So to do that you need a build process. And so a build process can be very complicated. Now, build processes have been around forever. If you’ve heard of Grunt, or you’ve heard of Bower. There’s a few, so what we use is Webpack. Now Webpack can be extremely daunting to set up and deal with. The story that I always tell was the first React app I ever built was when I was working for an agency, and they wanted to use Webpack and we went to the Webpack documentation page and all it said was work in progress.

And, it was very funny because the only comment on it was a giant picture of that meme of Picard with his arm stretched out going, why? I wish I had a screenshot of that because that’s best story ever. Anyway, so that’s your first issue.

Your second issue is how do you even structure blocks? There’s a number of files and a number of pieces to a block. And, you know, if you put 10 developers in a room, those 10 developers will have 10 different ways of scaffolding this. So that was always a bit of a problem as well. So what this tool does is it solves those problems first.

So it installs your build process, the one that is actually used by the Gutenberg project as well. It’s maintained, it’s got a million little features and you don’t have to worry about that anymore. And then it also will scaffold the files for your block and put them, give you the names, give you all the files, give you a starting point.

When you run the scaffolding tool, it will prefill a lot of the, sort of, details of your block and give you the starting point. And it bundles it all up inside of a plugin, and so it’s a WordPress plugin that you can just enable and it installs all the dependencies and it even runs the build process. So you literally run it and then you press activate inside your plugin screen, and then you have an active block.

That takes away so much guesswork and so much busy work of having to like, figure out the naming of things and add files. It doesn’t sound like a lot, but if you’re building 20 blocks, and you have to like, copy and paste all your files and go in and rename everything, that can take a lot of work.

[00:25:10] Nathan Wrigley: Yeah, I can well imagine how much time that’s saving. Are there any constraints about where you can install this? So, currently I’m on a Mac. I presume that we’re all good to go there. What about Windows, Linux?

[00:25:22] Ryan Welcher: The only thing that you have to have is Node. So you have to have Node installed, because you can run it using a command called npx. And what it does is it, it won’t download it and add it to your project, but it will just kind of reach out and run it once and then do its thing. So you need to have Node installed.

This does work, to the best of my knowledge, it works pretty well across all the platforms. I believe there is an issue in Windows with a very specific configuration that doesn’t copy a file to the right place. But that’s less about the scaffolding tool and more about the build process. But there’s a lot of people that work on this stuff. So I’m sure it’s going to be remedied pretty soon, yeah. The only dependency is Node, which is cross platform.

[00:26:02] Nathan Wrigley: Right, okay, perfect. So if I’ve never done this before and I want to get my first block done. Realistically, how long is it between me thinking, hmm, create block tool, I’m going to start using that, to having my first block on the page? Are we talking 10 minutes, an hour, less?

[00:26:20] Ryan Welcher: Two minutes. Assuming you have Node installed. Let’s assume that. You can go to the documentation page and you can run npx at WordPress slash create block and give it a name, and it will prompt you for a bunch of questions. Like, what do you want to call this thing? What name space should it be in? You know, what’s the description?

It’ll ask you a bunch of questions and it’ll just scaffold out the block for you. And the most amount of time is waiting for the dependencies. So that the block needs to be installed and then run. And that, honestly, I did a YouTube video on my channel where I timed it. And I think it took four minutes from start to finish and it was done.

And you have a fully functional plugin with a single block in it. And you enable it, and like I said, the block is available for use immediately. No, the block doesn’t do anything. It’s a very, very simple block. But that’s how quickly you can get up and running with it.

[00:27:09] Nathan Wrigley: Yeah, I think it’s probably very important at this point to describe the limitations, because when I heard about Create Block Tool, I thought to myself, oh great, a tool which is going to help me to create blocks. Not literally create a block, but, you know, add in options and different, custom data and all of that. And that was what I was thinking I was going to get. So just draw a line, make it really clear what you get when this process is complete.

[00:27:34] Ryan Welcher: You get what’s referred to as a static block. So there’s two types of blocks, static and dynamic. And I can get into that if you want, and with no controls. So basically the block will, it shows you a message when you insert, it says hello from the post editor. And then it’ll render that same message on the front end, and there’s some CSS that’s supplied to the front end and the back end.

So it’s a very, very, very basic block. The tool doesn’t have the ability to say, I want to be able to insert post meta. We can’t do any of that level of customization, because there’s just too many options. Like there’s too many ways that you can build a block, and too many things a block can do. So there’s just no, there’s no way for us to build a tool that says, I want to build a block that accesses the REST API to retrieve this custom post type and display all of the information and do all the stuff.

That’s not something that the tool can do. But, what you get is a fully functioning, working block that is scaffolded to best practices, follows best practices. That shows you how to deal with the CSS, and how to enqueue all your different files, and everything is just built and ready to go for you.

And then at that point you have a starting point. So, as a developer, I used to hate having to do the busy work. What this does is this basically gets me a starting point, and now I can add the things that the client is paying me to do, right? I can add the controls. I can add the interface items, whatever you’re building in your block. Iit gives you the starting point to actually build the thing that you want to build, not the, you don’t have to do any ramp up to get there.

[00:29:01] Nathan Wrigley: Yeah, so within two or three minutes you’ll have a block. All of the files in the right place. Everything’s set up. Good to go. And then, really, dear developer, it’s over to you. You got to figure out where to go from there. Do you have any, is there any sort of commenting in the files that’s been added additionally to give you some sort of pointers as to, okay, this is what this is doing, this file is used for this and so on?

[00:29:24] Ryan Welcher: There is. It’s commented fairly decently. There’s kind of a fine line because if you want to use these for production, you know you’re going to be removing a lot of those comments. There’s a couple of files that every time I use it, I hate how well commented it is because I like to structure my files in a specific way. So there’s a lot in there.

And then, at this point too, the sort of, the structure, the file structure’s very well documented and it’s just been adopted. People can change things and people can, it’s very flexible. You can do it whatever you want, but the best practice has been well defined at this point.

It’s like that muscle memory thing. People just know that, oh yeah, okay. So I want to go to the edit.js file, because that’s what I, that’s what I changed to get it to make changes in the block editor experience and so on and so forth.

[00:30:05] Nathan Wrigley: Do you know if, well, WordPress’s mission, I suppose, is to democratize publishing. And it would be, I suppose, an endeavor worth undertaking to have a tool which did carry you on from where the Create Block Tool got you to. In other words, a tool which helped you along the process of creating the block.

Do you know if there are any endeavors, any quiet whisperings in the dark corners of Automattic about this kind of tool? Is there any plan to do anything like that so that blocks can be created by, well, non-technical people?

[00:30:38] Ryan Welcher: There are tools out there in the community. Like I would hesitate to say that Automattic has any sort of secret plans, because that’s not really how it works. It’s more, it’s driven by the community. I mean, I know Automattic does employ a lot of developers who do contribute to the project.

But a lot of these tools come from the community and, for people like me to talk to folks and be like, hey, that’d be a really cool feature to add, to Create Block. There’s been a number of features where we’ve been like, you know what? It’s a really great idea, it’s too specific. So it might be better served as a tool.

But I will say this, the create block package does have the ability to, you can provide what are called templates. So you can create your own custom template. So you can build a block that does X because you’ve built a template. So I could build a template that is like, all right, I want to block that interfaces with custom post meta. And so I could build that template and when I run the package, I can point the package at that specific template and it will scaffold the files out, and I will have all of those starting points in there.

It’s not an interactive tool. I don’t think where you’ll see, what do you want this block to do? Like, unless somebody comes up with this really cool OpenAI integration, which might be a lot actually.

[00:31:43] Nathan Wrigley: Somebody will probably do it.

[00:31:45] Ryan Welcher: I’m sure they will. Blocks can do so many things and they’re so versatile and they’re so, it’s sort of like, how do you even start to define the questions that you ask in the automation process to say, what do you want to do? Like, do you need to access data stores? Sure. Is it a custom data store or is it one of the ones that Gutenberg provides? You know, so there’s a lot, there’s a lot that goes in there.

[00:32:06] Nathan Wrigley: Does the tool itself get regular updates? I’m imagining that the technology behind that is fairly fast moving, and there’s a lot of new updates.

[00:32:15] Ryan Welcher: It is being updated regularly. The package itself gets updated every two weeks when the Gutenberg project, so when the Guttenberg plugin is in release candidate. But there are features being added all the time.

For example, we added the feature not too long ago to be able to copy php files around. And, there’s a lot of sort of under the hood things that, I’m drawing a complete blank of all the features that I’ve added to this thing, but we’ve added a whole bunch. Here’s an example. So when you scaffold out the block, all of your JavaScript files sit inside a SRC or a source folder. And people, they may not necessarily want that because they might already have a source folder.

They might want to call it something like, so if you have an existing project, you might want to call it blocks instead of source. So what we did was we added the ability to be able to target that differently. So you could call it something else. And this works with the scripts package too. So you could define it a certain way and then have scripts look at that. Or one big feature that people were asking for was, we don’t want to scaffold a plugin every single time.

If we have an existing plugin, we just want the block. So we built a no plugin mode where you could run it inside your source directory and it would just give you the block files. And now you’ve got a second block inside that plugin. So those sort of things. And those all came from the community. They all came from people using the package and saying, this is stumbling block for us because we have to copy and paste and move things around.

Why can’t we just add a command that does it? So we were able to add that stuff in and it’s, I mean, I think it drives adoption, but it also. The whole point of this is to make people’s lives easier. If it’s more work to use the tool than it is to do it manually, then it’s, I don’t think it’s worth, you know, the juice isn’t worth the squeeze, so to speak.

[00:33:47] Nathan Wrigley: Yeah, that’s a good point. It just occurs to me that we never said where we find this tool. Do you happen to have a handy URL available?

[00:33:54] Ryan Welcher: Yeah, you can look in the developer.wordpress.org. I’m not going to read the whole url, but just do a search for create block. All the documentation is available there. It’s actually hosted on npm. So, I’m sure we’ll add it to the show notes, but the documentation is all there and it explains how to use it and all the available flags and all the available commands that you can do.

There’s even a more advanced page on creating custom templates. I really love the custom template idea. Well, what do they call it? They call it external templates. External project templates is the official name. And what it allows you to do is like, if you’re an agency and you want to build blocks in a very specific way, you can define that and then everyone in your agency is going to use that same template with this package.

And you can use local packages, or you can host them on npm if you want to share them. It’s very, very, very, very versatile. With that, the sky’s the limit. You can literally do whatever you want.

You can scaffold the block to do anything, and then just target that particular sort of style of block. Like I built one that would do dynamic blocks because at the time the tool didn’t support dynamic blocks, and now it does, by the way. My template is obsolete now, but that was a thing that we needed. So if you wanted to build a dynamic block, you would just target my template instead of the built-in one, and you would get that sort of flavor of block.

[00:35:06] Nathan Wrigley: You, mentioned a little while ago, maybe 20 minutes or so ago, that there was this dynamic block, and you said you might digress into that, but we never did. So let’s go down that little path just for a moment, yeah.

[00:35:16] Ryan Welcher: Sure thing. So like I said before, there’s two types of blocks. We have a static block and we have dynamic blocks. So a static block, the difference is basically where stuff is saved or if it’s saved. So, in a static block. So all, I’d say the majority of core blocks are static, meaning that when you hit save, it actually saves the markup into the post content.

So it’s saved to the database. A dynamic block doesn’t do that. A dynamic block uses php to render the front end, the way we would always sort of, add run until the pages loaded and that file is run, and then it displays its information. And that’s basically the difference.

Now there’s some trade offs for both. With static blocks, when there’s markup changes, you have to do this thing called deprecation. So you tell Gutenberg, if there’s any developers listening, I’m sure there are. If you’ve ever seen that, like, you know, the block, we couldn’t render the block. There was an error. Everyone’s seen that error. That’s because some markup has changed.

You need to deprecate that. So that’s an extra step. Where with dynamic blocks, you don’t need to do that because it’s always run live, so to speak, right? So there’s some benefits to using a dynamic block for that regard. But the trade out there is you have markup in two places. So that’s, at a high level, the difference.

[00:36:26] Nathan Wrigley: And the create block tool will point you in the right direction of creating one or the other, depending on which your.

[00:36:33] Ryan Welcher: Yeah, it lets you choose. So there is a flag called a variant, and you can choose between static or dynamic. I believe the default is static. It’ll give you a static block if you don’t run that flag. But if you say variant dynamic, it’ll do a dynamic one. And then there’s actually, within your templates, this is getting really the weeds, but if you define a template, you can actually have multiple variants. So you could have your own variant. You could have a TypeScript variant for your particular template. Or like a, I don’t know, Tailwind CSS one. So there’s a lot of flexibility there is where I’m going with that.

[00:37:03] Nathan Wrigley: Amazing. So much going on in the WordPress space at the moment. On every level. From straightforward to incredibly complicated. And feel this is on the incredibly complicated side, but really interesting work. You mentioned that you are obviously into this, but there were a couple of other names which came off your tongue earlier. I’m wondering if in the round, you could just drop some of those names, people that we might like to go and find, as well as yourself, who are working with you, pushing the Create Block Tool.

[00:37:36] Ryan Welcher: There’s the folks that I work with on my team. I’m sure you’ll know all these names. Birgit Pauli Haack is on the team. She’s the Brains behind Gutenberg Times and all that stuff. Justin Tadlock is on the team as well. I’m sure everyone knows Justin. There is Michael Burge who is on our team, and think that’s it.

[00:37:54] Nathan Wrigley: Yeah. Well if there’s any that you’ve missed out, you can always fire them over in my direction and we’ll make sure, that they get into the show notes. If anybody has been listening to this episode and they’ve thought, you know what, this is curious. This is something that I need to begin to play with, but I would like to find out a little bit more first. We know you’ve got the Twitch channel, and we’ll push people towards that. But what other places can people get in touch with you Ryan?

[00:38:19] Ryan Welcher: Sure. I have a YouTube channel as well, so I’m Ryan Welcher Codes in both places, Twitch and YouTube. I try to answer the comments on YouTube as often as possible, but sometimes I don’t get to them right away, but I’m at Ryan Welcher on Twitter and my DMs are open, so feel free.

I’m Welcher or Ryan Welcher or Welcher Ryan in a million different Slack channels. So, I think I’m Welcher in Make Slack. I’m on Post Status. I’m on Discord in a few places. So just search my name or variations of my name and I’m sure you’ll run into me and, I’d be happy to speak with anyone one-on-one in a public forum, whatever, whatever works.

[00:38:54] Nathan Wrigley: Thank you for making yourself available, and thank you for talking to us today about the Create Block Package stroke Tool. That’s been really, really interesting. Ryan, thanks so much.

[00:39:04] Ryan Welcher: Thanks so much for having me and I hope I can come back sometime.