Category: blocks

[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 themes, and in this case, why you should be excited about WordPress blocks.

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 go 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. You can do that by heading over to WPTavern.com forward slash contact forward slash jukebox, and use the contact form there.

So on the podcast today, we have Nick Diego. Nick is a Developer Advocate at WP Engine. He can be found, creating educational content, building plugins and themes, and contributing to WordPress core.

He’s on the podcast today to talk about his passion and optimism for the future of WordPress using blocks. At the recent WordCamp US, Nick gave a presentation entitled, ‘Let’s build a custom block in 15 minutes’. It was his attempt at showing a group of WordPress enthusiasts that the barrier to creating blocks is slowly being eroded, due to the creation of new tools. These tools are creating opportunities for people who might otherwise have stayed away from block development.

It’s becoming easier to create the blocks as the tools take away much of the technical burden of getting you up and running without advanced knowledge of JavaScript and React. Coupled with core components, native blocks supports, and a bit of guidance, Nick thinks that every WordPress developer can add custom blocks to their repertoire.

It’s clear that Nick is all in on blocks. And during the podcast, he makes the case for why you should be too. They offer so many opportunities for what can be displayed on a page, and their capabilities are only getting better.

We talk about how WordPress core blocks are trying to support developers by adding components and blocks supports so you don’t have to repeat the development work already done by others. You can build on top of previous work and thereby save yourself valuable time.

It’s a fascinating chat, especially for those who are, as yet, undecided about whether they want to embrace WordPress blocks.

Typically when we record the podcast, there’s not a lot of background noise, but that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listenable, I hope that you understand that the vagaries of the real world were at play.

If you’re interested in finding out more, you can find all the links in the show notes by heading over to WPTavern.com forward slash podcast. Where you’ll find all of the other episodes as well. And so without further delay, I bring you Nick Diego.

I am joined on the podcast by Nick Diego. How you doing, Nick?

[00:04:03] Nick Deigo: I’m doing great.

[00:04:03] Nathan Wrigley: Would you just introduce yourself? Give us a little bit of your background, who you work for. How come you’re at WordCamp US.

[00:04:08] Nick Deigo: I’m a developer advocate at WP Engine. I also do a lot of contributing both on the WordPress core team and also on the training team for WordPress.

[00:04:16] Nathan Wrigley: He’s doing a talk, presentation. What’s it all about Nick?

[00:04:19] Nick Deigo: It’s all about trying to get people excited about building their own custom blocks, and I attempted to build a custom block completely in fifteen minutes.

[00:04:27] Nathan Wrigley: Did you achieve it?

[00:04:29] Nick Deigo: Just barely. I got the zero minute sign as I was just finishing the presentation, so I just got under the wire.

[00:04:35] Nathan Wrigley: I guess the principle therefore, is that if you can do something in 15 minutes, I mean, let’s be honest, you’re pretty well versed, probably had a few runs through of that. But the bit that you are trying to educate people in, is that it’s easier now than it ever has been. So there’s no excuse to not explore. Is that basically it?

[00:04:50] Nick Deigo: Yeah, and I think building blocks has been a bit scary. I know it was scary for myself. I didn’t come from a JavaScript background, mainly PHP. And so I wanted to show people that there’s so many more tools nowadays that it’s not as scary to get started, and if I can do it in 15 minutes, and I came from a non-technical background. You can do it too.

[00:05:09] Nathan Wrigley: When blocks came around, Gutenberg was launched the first time, how did we build blocks and how has that changed? What things have come over the horizon since then to make it easier?

[00:05:19] Nick Deigo: You wandered in the wilderness and looked for some documentation that maybe didn’t exist, and maybe looked at some core blocks and you kind of tried to figure it out. But today you can scaffold an entire block with one line of code in your terminal and voila, you have a block.

[00:05:34] Nathan Wrigley: Is that because it’s become easier to do, or is that just that there’s more documentation? Are there actual tools? Are there pieces of software that you can download and use and things to make it more straightforward?

[00:05:46] Nick Deigo: I find building with JavaScript is just inherently more challenging than PHP, but we have tools today written by contributors to WordPress that allow you to take all the hard bits and it takes care of that for you. And you can actually get to building the block itself and not worry about compiling JavaScript files and compiling style sheets. It’s all kind of done for you, which really makes it a lot easier.

[00:06:08] Nathan Wrigley: And when you say done for you, is that literally done for you? There’s no caveats. You just do the workflow that you’ve just described and you’re off to the races.

[00:06:15] Nick Deigo: It does it all for you. It scaffolds the whole thing. And now there’s a new version that came out actually like last week that allows you to choose different types of blocks you want to build and it will scaffold that for you and you can get started there, so.

[00:06:29] Nathan Wrigley: I’ll put the link, which you may mention in a moment in the show notes, but where do we find these tools? Where are we going to be going to? Are there websites that you can mention?

[00:06:37] Nick Deigo: So the biggest tool right now is called Create Block, kind of on the nose, but it’s maintained by the WordPress core contributing community. And it’s, well, it’ll be in the show notes, but it’s just Crate Block, WordPress in Google and you’ll find it. The documentation’s being built out. I gotta shout out Ryan Walter, a Developer Advocate at Automattic. He’s done a lot of work on the Create Block tool, and a lot of the documentation around it. So, that’s a place to start if you want to use that tool.

[00:07:00] Nathan Wrigley: Okay, and does it allow us to do all the things? Does the tool allow us to do a subset of things? In other words, if you are really thick in the weeds and you understand how to do React and all of that, are there limitations or constraints that the tool will not allow you to cross over?

[00:07:18] Nick Deigo: So, I’m a fairly novice React builder and so, and I think most people getting started with blocks would be. But if you’re a pro user, there are functionality in the tool. You could define like all your own templates. Basically, you can let it do whatever you want it to do. So if your new, it does a lot for you. And if you’re an expert you can still use it, but then, do all the wizardry that you’re used to and combine it with the tool to make your life easier.

[00:07:47] Nathan Wrigley: So why would we want to use blocks in the first place? I don’t mean that glibly. I literally mean that, there are blocks that come installed in a vanilla version of WordPress. They achieve the majority of what most people want to publish online. What is the use case? What are the kinds of things that are useful? What kind of things can you create, that you have seen, that you have enjoyed looking at?

[00:08:08] Nick Deigo: Assuming that you’ve bought into the block editor and that’s what you’re using and you’re not using a page builder or something like that, core blocks are great, but they’re designed to have all sorts of functionality that maybe you want or don’t want. I was actually talking to an agency earlier at Word Camp US, and they’re all in on blocks, and most of their blocks are custom because they want to provide specific functionality to their clients that maybe is a little bit different than core.

Or maybe completely niche blocks for, I don’t know, food blogging or whatever it might be. All within a block. The block UI that interface where their clients can get in there, see it visually and add the content on their page visually. And then obviously that translates to the front end. So, tons of reasons why you’d want to make the editing experience more visual. Not only that, but allow you to control more the experience than maybe just using native core blocks.

[00:09:04] Nathan Wrigley: So the principle being if you’ve got something, I’m going to guess this is the use case. If you’ve got something which on a particular project is something that’s going to be repeated, and in order to do that you would have to otherwise drag in a load of different blocks and sort of scaffold them together. This is the kind of use case. So something like a menu item on a restaurant menu. Or a real estate house listing item. Something like that.

[00:09:26] Nick Deigo: Yeah, for example, I know a lot of agencies specialize. We do real estate or hospitality or whatever. You could build your own suite of blocks for your agency and then roll them out to your clients and it’s very unique. Now there’s so many third party blocks out there that you can just pull off the shelf that are fantastic, but sometimes you need something custom, and knowing how to build custom blocks I think, whether you need it or not, is a pretty valuable tool to have.

[00:09:50] Nathan Wrigley: Just give us an idea in the 15 minutes that you had. What was the scope and magnitude of what you were able to create? I’m guessing, you know it’s not earth shattering.

[00:09:57] Nick Deigo: It’s not. So, most people are probably familiar with the Hello Dolly plugin, by Matt Mullenweg. And so to me, when I first started developing with WordPress, Hello Dolly was like this example of, it’s one file and it did something sort of novel. Look how easy it is to extend WordPress. And so it actually started, somebody online said, can you make a block that does a random motivational quote?

And I’m like, oh, that kind of reminds me of Hello Dolly, which has a random lyric from the song. And I’m like, what if we blockify Hello Dolly, and show just how easy it is to make a block using the original Hello Dolly plugin. That’s what I did. I made a block that spits out a random lyric from Hello Dolly on the front end of your site. We basically copy and pasted all of Matt’s original functions from Hello Dolly, dumped it into a block, and it just works.

[00:10:46] Nathan Wrigley: So imagine that I’ve got an agency and we have never touched this before. Realistically, how easy is it for you to push your team over to this kind of methodology? Are we talking days, weeks months, possibly years?

[00:10:59] Nick Deigo: Well, I think it depends on what you’re trying to build. So the thing that I built in the presentation was a dynamic block, where the front end’s all rendered in PHP. So if you’re really familiar with PHP and you don’t want to mess with very much JavaScript, you could create a dynamic block where you create some very simple interface in the editor, but then on the front end can do really complicated PHP stuff.

It’s many ways like, I hate to use this term, but it’s kind of like a short code in many ways. You, you have an interface in the editor, which people play with. Not just a short code, but then on the front end, just whatever PHP you want, and that’s what basically what we built. If you’re looking to get started quickly, that’s not very challenging. I mean, using the tool plus your own knowledge of PHP, getting started that way is not too bad.

[00:11:39] Nathan Wrigley: In terms of building these things, the scenario that I just gave you was an agency. We’re using our own employees to build the blocks to service our clients. Do you feel that in the future there’s going to be, in much the same way that there is for plugins at the moment. You can, you know, you can really make a decent living if you have a popular plugin. Do you feel like the same is possible for blocks? And I don’t mean like a suite of blocks, like, for example the real estate one. Could you potentially create a block and then have a marketplace to sell it, and make a decent living? Because I feel that’s where the next shift in revenue streams for WordPress might .Be

[00:12:16] Nick Deigo: I hope so. I think that it kind of speaks to the broader question of the WordPress economy and ecosystem, and we’re starting to see a lot of consolidation and all that kind of stuff. But I do think that there’s a lot of opportunity around blocks.

I know I have my own personal blocks. They’re all free, but they’re starting to get like a lot of usage, in the multiple thousands of active users. And it’s really only started in the last year where it’s like, okay, I guess blocks are a thing, we should adopt them. People are starting to use it more and I think that it’s an opportunity to stake out your niche and you know, if you’re really knowledgeable about real estate or whatever it might be. Yeah, build blocks and I’m sure people want to use them.

[00:12:54] Nathan Wrigley: What are the blocks that you’ve built?

[00:12:55] Nick Deigo: So I’ve built one that adds SVG icons to the editor and you can make them colorful and move them around. And then one’s a social sharing block. Really simple, just allows you to share the current page or post.

[00:13:07] Nathan Wrigley: And they’re getting traction, yeah?

[00:13:09] Nick Deigo: My SVG icon one, which is just. Also, one thing, if you’re building blocks, it’s very much like there’s not many people doing it. So you can really get great block names. So I have a block called The Icon Block, right. It wasn’t taken, so it’s the icon block, and it just allows you to edit SVG icons. And, I looked the other day and it’s got 4,000 people using it. And I’m like, how is this happening?

[00:13:31] Nathan Wrigley: Yeah, I kind of feel that the tide has gone, if you like for getting notoriety in plug-ins. I mean, sure, there are some that come along and for reasons that I can’t quite explain, they rise to the top quickly. They get some notoriety. But it sounds from what you’re saying as if, we’re just sort of landing on the beach really, and the beach head is yet to be taken. And if you get in now and develop now, you could be in that next wave and be what popular plug-ins are now.

[00:13:53] Nick Deigo: Yeah, it could be. We’ll see.

[00:13:56] Nathan Wrigley: Yeah. You used the word accessible. Now forgive me because I’ve completely misquoted you. You used the word accessible in your introduction. You were just talking about accessible in the sense of easy to use. But I am curious because I was interviewing somebody yesterday all about accessibility in WordPress, and we got into the interface and blocks and all of that kind of thing. So just a quick aside, the accessibility piece in blocks. Have you got anything to add in there?

[00:14:19] Nick Deigo: I think that accessibility in the block editor is something that continually needs improvement. And so one of the things, and I think we’ll talk about this in a second, is that when you’re building a custom block, the more that you can take advantage of the way that core does things. So core block supports, and we’ll talk about that, but the more you can take advantage of core components and things like that, the better off you are.

Because there’s a big emphasis on WordPress to improve accessibility. So if your block is using components from core, and core improves accessibility, your block will therefore also be more accessible. So instead of trying to do your own thing and code everything yourself. One, that’s harder. And two, you’re able to keep up with accessibility and all these other improvements by really staying close to core.

[00:15:08] Nathan Wrigley: You’re talking there about an evolution over time and I really haven’t followed the trajectory of what blocks could do in the beginning and what they can do now. Is there a lot of change that’s happened over the last couple of years? The capabilities of a block, am I able to do much more now? Obviously we’re talking about how easy it is, but am I able to do more with blocks than I was, let’s say two years?

[00:15:31] Nick Deigo: I don’t think necessarily that you could do more now, because you could always, if you were really skilled, you could always just write whatever you wanted. But a great example is block support. So block supports are when you create your block, you can define, I want my block to have typography support, or I want my block to have color support. It’s one line. Instead of having to write all the controls in a color palette and all the functionality, you just tell WordPress that this block has typography.

Your block loads in the editor and it has all the typography controls already. And those are coming from core. You’re not having to code any of that. You just tell, my block has typography, and it gives it to you. And so if WordPress ever improves their typography controls, your block already gets those improved controls.

So is it easier now? Can blocks do more? You can do more in blocks without having to code it yourself. You can do color, alignment, border, background colors, typography. All this stuff, you don’t have to code it all. You just tell WordPress that my block has this functionality and you’re good to go.

[00:16:31] Nathan Wrigley: Are there any sort of gaping holes in all of this? In other words, if you Nick were in charge of the roadmap for what blocks would do, is there anything that you feel, do you know what It would be nice to have this.

[00:16:41] Nick Deigo: I think that, I’m actually quite happy where things are, but I do think that we continually need better examples, more resources, because it’s still brand new. And one of the things I was actually talking to folks at the conference today, You may have been working in WordPress for 10 years and you have all this knowledge about how to build with WordPress. Unfortunately, that does not translate to building with blocks. Blocks is brand new. It’s completely different. It’s hard when you’re running a business to dedicate time to learn something new and it’s, that costs money. Time is money. And so the more that we can do to create examples, build tools that help people get quicker, the more adoption that we’ll have and, we’ll be better in the long run.

[00:17:20] Nathan Wrigley: You come to these events and obviously you’ve got your block hat on. You have had for several years or certainly as long as I’ve been acquainted with you Do you find the conversation is more and more turning to blocks? In other words, there’s 600 people here. I don’t know how many of them would class themselves as developers, or capable or wishing to build blocks. But three or four years ago, I’m imagining that the conversation around blocks was basically Nick talking to himself. Is that changing? Are people more and more beginning to use this as the mode to create in WordPress

[00:17:48] Nick Deigo: I fundamentally believe that we’ll get to a point where people either use a page builder like Elementor or whatever, that they’re really comfortable with, or they’ll use blocks. Core blocks or you build with a page builder. I think we’re going to get to that point.

[00:18:01] Nathan Wrigley: And do you see that there’s a sort of conflict there? Do you do you see that there would be a point where. So we’ve got two paths in that scenario. You’ve got like a proprietary page builder. You mentioned Elementor, there’s lots of others. And then you’ve got blocks and obviously they go in completely different directions. Do you think that’s healthy? Is that a good thing? Or would it be, would it be better to sort of try to get them to coalesce in some way?

I have no idea what that would even look like, because they are very different animals. But I don’t know, I don’t know if that’s a good thing to have almost like two, two variants of WordPress, and in 10 years time, you can imagine a crowd over there who are barely able to speak to the crowd over here. I don’t mean an impolite, but you know, they’re just talking complete cross purposes. The block chatter over here is incompatible with the page builder chatter over there. And that feels, in a way, like that would be a shame.

[00:18:45] Nick Deigo: It definitely would be, but I do think that page builders, this is my own interpretation, but page builders were a response to the fact that it was fairly hard to build in the classic editor. So they were going to build a page builder experience that helped people build easier, and it’s multimillion dollar companies now running these page builders. I know people who are Elementor builders and that’s great. I mean, they found their niche and they build everything with Elementor, and it looks very different from core WordPress.

Like that build process is completely different. I think we are going to end up with different camps. But as long as both communities are thriving and like, you know, everything is still compatible. We’re a big community and I think it can support different areas.

[00:19:24] Nathan Wrigley: Yeah, we can definitely have both. Okay, give us some examples, some concrete examples, of things that you’ve seen out in the wild of blocks where you’ve thought that’s ingenious, that’s a really impressive use of it. There may be one, there may be a couple. You can name names and I’ll try to dig out the URL if I can find them.

[00:19:40] Nick Deigo: So one of the things that I saw recently, which I don’t think this is released yet, but I’m forgetting the name of the technology where you can type in a prompt, and AI will generate an image for you.

[00:19:51] Nathan Wrigley: Things like DALL-E.

[00:19:52] Nick Deigo: Exactly. So there’s a gentleman, I’m forgetting his name. He’s working on a block that can do that all within the WordPress editor. So you can just type in whatever and it generates your four images and you pick the one you want. Automatically inserts it into the page. It’s all like super seamless, and that’s just amazing. We’ll save it to your media library. You can insert it, set it as your featured image. So all within the editor as a block.

[00:20:16] Nathan Wrigley: I think that’s the piece which I find most exciting about blocks, is that if you’re just using core WordPress and the small collection of blocks that comes with it, you just sort of see them as an interface to add images, add text, maybe, you know, add some background color or what have you. But I kind of see this future where the block becomes like an application. It can do a whole ton of heavy lifting, but all you need to do on the back end as a user of that block is basically to click it, and then it comes and you can move it around on the page.

The complexity that could drop into there, just in that one tiny little block which you just click, is almost infinite in scale. And so that’s a really great implementation of that. You click a button and suddenly that whole DALL-E thing is dropped into your, your website. Yeah That’s amazing. Any other examples?

[00:21:05] Nick Deigo: Well, I think that there’s another one about like Anthony Burchell, he works at WP Engine as well. He’s building one that does virtual reality and metaverse stuff, really complicated. I build blocks that are super simple. Add icons, social sharing links or whatever. So you can build something really simple, but it’s all JavaScript. So you could also build something really complicated. And I think that that’s the beauty of the block interface.

[00:21:27] Nathan Wrigley: You mentioned in your introduction, this is something I think we’ll explore a little bit more. You use the words, core components, native block support, and honestly at that point I was, I don’t even know what Nick is talking about. Explain all of that.

[00:21:39] Nick Deigo: Block support is a little bit what I was talking about before with defining that your block, I want my block to have typography controls. I want my block to have color controls. There’s a set of defined supports within WordPress. I’m going to not get them all, but it’s like alignment, color, typography, border. There’s probably a few more. And all of those you can just define and WordPress will add all the controls for you all within the interface. So you don’t have to do anything other than say that my block has these supports. It really speeds up development time. You don’t have to build a color picker, build typography, selectors, anything. It’s all in WordPress.

Core components are similar, where if you had a block and it had, you clicked on it, so it had like a toolbar that people could select items from, maybe change italicized font or whatever. There’s a toolbar component within WordPress, so rather than creating your own toolbar architecture, you just say use the toolbar component from WordPress, and then define the tools that you want in the toolbar.

So using core supports really will speed up development, but on top of that, you’re using the same interface that WordPress is using. So from a user, it all feels very native. It’s the same looking toolbar that you get on your standard paragraph block or whatever it might be. And the beauty is, whenever WordPress updates or improves their toolbar control or their block, supports, your block will already get that improvement. You don’t have to worry about updating things yourself. It’s already, because you’re using WordPress core components and supports, when WordPress gets better, your block will automatically get better.

[00:23:12] Nathan Wrigley: You mentioned Hello Dolly earlier, you know, one of the, if not the first plugin and it heralded an era of enormous change in WordPress, and all of a sudden you go 10 years later on and there’s loads of different plugins available. And you get this notion that, okay, enough now. You’ve got 50 plugins on your website, it’s probably time to think about the resources that you’re using and trimming that down a little bit. Do you fear the same may happen with WordPress websites, where we just click happy and install like a million blocks, because we want everything possible in the website. Is there a danger of bloat, just overdoing it with blocks?

[00:23:49] Nick Deigo: A hundred percent. I think that you can have a block for everything and end up with a hundred blocks on your website. A hundred third party blocks in your website. It’s like, wow, there’s a lot of blocks. But at the same time, I think that, I was looking at a website of a user who needed some help and I opened it up and there’s a hundred plugins and notifications all over the place. You know, it’s just an absolute mess.

And so I think with WordPress, you always can kind of mess, not mess it up, but you always can like over install. But I think that with blocks you can run into the same problem, but if you can stick to core as closely as possible. And hopefully core will get better and better, and so that you don’t need third party blocks to do simple things like buttons, let core take care of the simple stuff.

And then you focus on third party blocks that do very niche things, things that core will never do. You’re thoughtful about it. You can probably pare it down to, you know, a handful of third party blocks that you actually need on your site. But yeah, there’s a good chance that we’re going to have sites with hundreds of blocks that maybe people never use.

That’s why like I never wanted to disparage a block library plugin. Cause I think they’re really useful and help people get started. But most of the time you don’t need ’em all. You only need a couple, but you install the block library that has 25, 30. So I like the idea of single block plugins where you can, I actually need this and I’m going to install it. I’m not going to install a hundred.

[00:25:10] Nathan Wrigley: That’s going to be a really interesting thing for agencies because they’re going to be the people working out, which are the, the necessary blocks that they want their agency to use. So you’ve just described block suites, where 50 or a hundred come along for the ride and 99% of them you’re never going to use.

That will become a core skill, is knowing, in the same way that you’ve got your favorite contact form plug in now and you’ve got your favorite whatever. I’m imagining that there’ll be a day where, we’ve all got our little list of, these are the suite of blocks that I’m using and I don’t stray outside of those. And that feels like an area of expertise that we can bring to clients just to make their lives a little bit easier. We know what to install for them because we’ve done it a thousand times before.

[00:25:48] Nick Deigo: And I also think it’s going to be very important for agencies to remove blocks. Core has a ton of blocks, all the embed blocks. You could just have a default little script that strips ’em all out and just has the very basics that people actually need. So we want to be adding blocks, but in many cases you also want to be removing them. The ones that you don’t need.

[00:26:06] Nathan Wrigley: Did you ever come across a proposal by a chap called Joel Spolsky? I believe he was behind Trello possibly. I could be wrong, but anyway, he’s a, he’s got a heritage of doing things well in tech and implementing great applications. You came up with this notion of the block protocol and the idea behind the block protocol was that a block here in Trello would be able to be interoperable with a block over here, WordPress. Equally, you know, if you’ve got gmail working, the blocks in Gmail.

So it’s pie in the sky stuff at the moment. It’s just an idea. But I read the proposal, I just thought it was really compelling. I love, I mean, especially in open source. I can imagine companies, proprietary software companies, they might be a little reluctant to do this because their secret source is the fact that their code is, you know, is obfuscated and we don’t know what they’re doing. But I do love the idea of that, and I was curious what your thoughts were.

[00:27:00] Nick Deigo: I think it’s fascinating and I also think, we talked a little bit about block supports, where instead of every plugin registering a different way to do typography or a different way to do color, by standardizing the way different common controls are used in blocks. You can get towards something like this, where you standardize this. Also, you can take one block from WordPress and drop it in another application and take that one from the other application, drop it into WordPress. That interoperability between applications I think is quite fascinating. We’ll see where it goes. You know, we’ve heard about Tumblr possibly integrating the Gutenberg and it’s like, oh, that’s interesting.

[00:27:36] Nathan Wrigley: So there’s services like Zapier. It’s enormously popular because it enables interoperability. That’s basically all it does. And people use it all the time to just connect the dots with all the disparate services they’ve got, and if we could have that in the future and it was block based, that would be really great. I wouldn’t have to have a giant bill for Zapier every month.

[00:27:56] Nick Deigo: Exactly. Well, one of the things I think, even in a block architecture, I know full site editing is brand new, and we won’t get into that discussion, but the idea behind full site editing is everything is a block. And when you standardize every piece of content on your website as a block, then you can start just doing interesting things with blocks because everything’s a block.

So you can create plugins that target blocks, and all of a sudden you can target the entire website. And so, by already moving to a block based architecture, we’re starting to move in the direction where you can start moving blocks around much simpler because it’s a standardized unit of content. As opposed to random things.

[00:28:31] Nathan Wrigley: I know that the idea of everything is a block is beguiling and it sounds great. Do you think some things shouldn’t be in the domain of blocks? So, sorry to drag you into full site editing, but you know, it’s the best example I can conjure up at this moment. Things like navigation as a block. It’s tricky. It’s difficult to use and it feels almost like it’s throwing the baby out with the bath water a bit, because I know the current interface is a bit old and maybe people don’t like that and they would love it to be in a block, but it kind of feels, don’t break. What’s the phrase? If it isn’t broken, don’t. Yeah. Yeah, that, that phrase.

[00:29:02] Nick Deigo: No, I agree. I think that there are certain components that are really hard to build in block form. And taking the navigation, for example. It’s really tiny. It’s at the top of the screen and manipulating all your links and sub navigation, it’s very challenging. I think that having that be a block under the hood is fine, but the way that users interact with it needs to be greatly improved.

[00:29:23] Nathan Wrigley: So it’s the UI? The principle of it being a block is fine, it’s just the UI that needs potentially addressing?

[00:29:28] Nick Deigo: In many ways you could have taken the old UI, and under the hood made it all blocks, but keep the same UI, and that would be fine. It’s the moving things around and trying to manipulate it. It’s very hard.

[00:29:38] Nathan Wrigley: And because it’s hard, and because these things pop up in our WordPress, we get version 6.1 and we’ve got all these new things, and we’ve gotta figure out what’s going on. Do you find that you are having to fight this fight often? Every time a new version of WordPress comes out, do you need a new line of defense? Okay don’t worry it’s going to be alright?

[00:29:57] Nick Deigo: Yes, and I think that it’s one of those, so we’re doing the walkthrough next week for 6.1, where we’re going to try to show everybody all the cool stuff that’s coming out. You do a disservice to WordPress by not pointing out things that need improving. Navigation block is one of them.

We need to be honest about the fact that it’s not the best it can be. Because new users are going to get in there and they’re going to get frustrated. And one of the biggest, not, again, not to get, toot my own horn here, but the biggest thing for me is consistency. So one of the things that we haven’t had in WordPress is the same typography controls on every block.

You know, I could change font family on my headings, but not my paragraphs. You know, that kind of stuff really starts to confuse people, especially new users. And with 6.1 we’re starting to get some of that consistency. Big, big effort now to improve consistency across blocks. And we won’t get people to get excited about things and use this new stuff, but we need to be, we need to recognize when things aren’t perfect, and what can we do to improve them.

[00:30:52] Nathan Wrigley: Thanks Nick for joining us today. I really appreciate it.

[00:30:54] Nick Deigo: Thanks so much.

[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, making it easier for clients to use the block editor.

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 very keen to hear from you and hopefully get you, or your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today we have Alex Ball. Alex is a lead software engineer at Mindgrub, a digital agency in Baltimore, Maryland. He’s been there for over three years, during which he’s worked on headless implementations, multinational multi-site installations, and much more.

Prior to joining Mindgrub, Alex worked in-house for a company handling a suite of internal intranet type sites, and external marketing lead generation sites. He spent seven years at Baltimore magazine on the editorial staff, before managing their website.

His website leadership experience continues to inform his decision making today. Especially for training clients and making the block editor as easy to use as possible. And that, in essence is the subject of the podcast today.

During WordCamp US 2022, Alex gave a lightning talk in which he laid out some suggestions on how the block editor can be made more straightforward for clients.

Most regular WordPress users have become accustomed to the way that the block editor works. Over time, we’ve understood how things work and where we need to go in the UI to alter things. For many clients, this familiarity simply does not exist. The editor is new and perhaps confusing.

As the block editor is under constant revision, this can create confusion, and lead to mistakes. Add to that the fact that more and more of the website can now be modified inside the editor, and it’s easy to see how mistakes can be made.

Alex talks about solutions to this problem, and he comes at it from different angles. Maybe you lock certain features down so that only certain users can achieve specific tasks. Or it might be that you need to take some time to educate your clients more about the block editor and how it works.

Typically when we record the podcast, there’s not a lot of background noise, but that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listable, I hope that you understand that the vagaries of the real world were at play.

If you’re interested in finding out more, you can find all the links in the show notes by heading over to WP tavern.com. Forward slash podcast. And you’ll find all the other episodes there as well.

And so without further delay, I bring you, Alex Ball.

I am joined on the podcast by Alex Ball. How are you doing, Alex?

[00:04:07] Alex Ball: Very well, thank you for having me.

[00:04:09] Nathan Wrigley: We are at WordCamp US 2022. We’re sitting in the media room, and Alex has joined me today to have a little bit of conversation about block patterns and blocks and locking blocks and all of those kind of things.

We’ll get into that in a moment, but Alex, just give us a little bit of background. Tell us about yourself, your journey with WordPress. How is it that you’re at a WordCamp, talking to a bunch of people in your presentation.

[00:04:31] Alex Ball: Sure. So I started with WordPress probably in 2007 or so. And at that point I was not a developer, I was an English major. I had been on the editorial staff of our city magazine in Baltimore, Baltimore Magazine for seven years, and people knew what the internet was at that time and we didn’t have a very good site and we needed one. And I somehow talked leadership into letting me take over the site without any of that development experience that was probably critical.

But, I dove right in and got used to it and followed some tutorials for building a WordPress theme from scratch, and just took off from there. So I, I was there for another four years. I worked at another company that had quite a few websites, both internal and external.

And they were across a number of different states in the US, and so working with those, using WordPress on quite a few of them. Landing pages, some internal intranet type things. And then I found Mind Grub, and I’ve been with Mind Grub for three and a half years, and we do all sorts of things from really large enterprise scale things hosted on WordPress VIP.

We do headless installations with a React single page app front end. We do more structured data sort of things where Gutenberg is really not a consideration because of all the structured data that’s going on there. And we have a pretty excellent WordPress team, and so it’s been really beneficial for me to try to carve out that path within our team and help us move forward with Gutenberg because we’ve heard from Matt Mullenweg more than once that Gutenberg is the future of WordPress. That you’re going to need to know JavaScript to work with WordPress in depth, and that when people ask him at WordCamp about the sites that they still have with the classic editor plugin running, and what they need to do about that and when they’ll need to switch those over, he says you’re going to need to switch those over at some point,

[00:07:02] Nathan Wrigley: At Mind Grub, is that a decision that you made more recently, or are we going back several years? You’re exclusively using Gutenberg with a variety of different blocks?

[00:07:11] Alex Ball: We are, no, I would not say we’re exclusively using Gutenberg. It still depends on the site, and we still do raise the prospect of it with a client at the beginning of a project. We find that some clients are aware of it, and really don’t want to use it. We’ve had that reaction so we just go with that and we use the classic editor plugin and we move on.

We have found that most of the time they’re not familiar with it, and so they don’t care one way or another. And when we tell them it’s a more enhanced, what you see is what you get editing experience with more ability to move things around and know what you’re doing before you hit save, that they like the sound of that.

We occasionally have people who say that they’ve heard of it and do want to use it. And I guess those are the three real possibilities there. So, in large part it is we’re moving forward with it and doing that because we know it’s the future, it’s going to be better for the client and they do not have a strong preference.

[00:08:20] Nathan Wrigley: So you are here and you are giving a presentation. I say giving, maybe you’ve already given.

[00:08:25] Alex Ball: I have given it, yes. It was about an hour ago.

[00:08:28] Nathan Wrigley: How did it go?

[00:08:29] Alex Ball: I thought it went well. It was a lightning talk and it was about modifying or customizing core blocks for clients. And I used a metaphor about setting guardrails for clients, that I believe was also recently spoken on your podcast with another guest who used the same phrase, and I heard that one after I had made my submission. But I thought it went well.

It was a lightning talk and so it was really focused on the nitty gritty of using a few blocks as examples, core blocks that are probably the most used blocks. Heading, paragraph, image, button, and talking about the specific options that they present for modifying their output and their appearance. And how to go about doing that. And in some cases it was using PHP to do some things. In some cases it’s enqueuing some admin scripts. And in a lot of the cases it’s using the theme dot json file, which not everyone is totally familiar with at this point.

[00:09:41] Nathan Wrigley: Okay, so it was called customizing core blocks for clients. And forgive me, I was not present at your talk, I may be ill prepared with this question, but it felt from the show notes that you shared with me, the things that you thought it would be good to talk about. The principle of the talk was how to lock things down in a website, so that you could build things and then be fairly sure that when you hand it over, there’s not gonna be that moment where they phone you 24 hours later to say, it no longer looks the same. We’ve had a bit of a play. We thought we knew what we were doing, and sadly we need you to fix what we just broke. That’s the principle, right?

[00:10:20] Alex Ball: Right, Exactly. And you find that the nice thing about working with WordPress is that someone on the client team, when you start the project is already familiar with it. Someone has worked with WordPress in the past. Maybe the site that they’re replacing is a WordPress site. So they’re somewhat familiar with it, even if they’re not familiar with the block editor yet.

And before I even get into developing and writing the theme, there’s already been a large process with our design and UX teams designing the site, and those stakeholders, the client, are sitting in these meetings reviewing those designs, exploring design ideas early on to establish things that they like and don’t like.

There’s a lot of time spent on that design, and there’s a lot of thought that goes into it. From a design perspective, the colors that they choose to compliment one another, the fonts that they choose, the UX decisions for what type of menu it might be, how this might look with this. And so all of that work is being done, and the client is obviously paying for that. So it’s important to make sure that that is consistent throughout the development process and after you’ve handed the site off.

Hopefully when we do a project, we are creating a relationship with this client and not just simply handing over a site and waving goodbye to them. So, it’s important to make sure that they feel like they have the control that they need to do what they want to do on the site, but not to feel like anything they touch is going to break something or look bad or go way outside the bounds of this design system that has been carefully crafted for them.

[00:12:14] Nathan Wrigley: I’m pretty sure that 99% of the people listening to this podcast will know exactly what the Gutenberg UI looks like. They can drop paragraph blocks in and they can drop various other bits and pieces in. But in your presentation, the summary of your presentation, you make this point, which is borrowed from somewhere else, I’m sure.

And you said with great power comes great responsibility. And I guess if you were back in the days of the what we’re now calling the classic editor, you really didn’t have any options there. You were just pasting text. There might be some shortcodes being dumped in. And now of course in the era of Gutenberg, there’s a whole load of things that every single person dropping into a default install of WordPress can change.

You know, there’s options to change the color of the text, and there’s options to increase the padding and the margins, and a whole myriad of things in the right hand column. And I guess this is the piece. You’re trying to make it so that there are constraints in what the clients can alter in the Gutenberg UI?

[00:13:15] Alex Ball: Exactly.

[00:13:16] Nathan Wrigley: Okay. You also have called your presentation, well you use the phrase customizing core blocks. Why just core blocks?

[00:13:24] Alex Ball: Well, the reason I went with core blocks is because they’re obviously present in WordPress at this point, and there’s no extra work to be done. Everyone has probably seen them in WordPress, even if you have decided to go a different route and install a plugin that gives you some other blocks that you feel you might want some sort of carousel or gallery or something like that, that you like the look of or does what you needed to do. You’ve still got those core blocks there.

So everyone is working with those, that’s a sort of common denominator. And also because when we talk about being as efficient as possible when building this site and giving the client as much of what they want as we can give them. It makes more sense to start with those core blocks, which are already there. We don’t have to do any extra work.

We don’t have to waste any other time either creating a custom block that’s essentially reinventing the wheel. They are there, and if there are good ways, and not necessarily easy, but ways to customize them, that makes the most sense for getting these things off the ground.

[00:14:41] Nathan Wrigley: If we go back several years, it feels like it’s quite a long time now, when Gutenberg initially launched, there was a real kind of schism in the community. Many people felt that it wasn’t fit for purpose at that time. You know, there were limited options. It was all very confusing and so on. I feel like we’ve crossed that Rubicon now. We’ve come to the other side and, most people here are familiar with it and working with it.

That being said, the reason that these third party plugins come along, which drop in the carousel and drop in the accordion and all the other different things, is because there are some fairly big limitations to what core blocks can do. You know, there aren’t all of the different options and those third party suites are there to fill in that gap. What are your feelings about your ability to create almost any layout with core blocks? Is that now possible?

[00:15:30] Alex Ball: Whew. My gut is telling me no. And I think that this was part of that recent controversy that I’m sort of surface familiar with, where they released a new design on the wordpress.org site for the homepage and the downloads page. And again, referring to something that Matt Mullenweg said, he talked about how it could have been done more quickly than it was.

And he also referred to like Wix and Squarespace and page builders. And it generated obviously a lot of feedback. I think some people were in agreement, and others did not agree. I think that a lot of the sentiment out there was that you could still, with the core blocks available to you, not necessarily go ahead and just do this as easily as people were making it seem.

I think that I had seen something on WP Tavern about a YouTuber who is very, very good with the block editor, and like whipped through in one of his videos, the building that homepage design through the block editor alone, and feeling like he got 95% of the way there pretty quickly.

So, speaking to what I’m most familiar with, which is our projects and the designs that we put together. There has not been a project in the last couple years where we have come up with designs for it and been able to do even more than half of it with just core blocks. I do like to use the core blocks as much as possible for the reasons that we already discussed, but it usually involves quite a bit of custom work.

Now, our designers also know that, and they’re certainly designing for things. There’s always that interplay of design and development, and getting a design and explaining why something is a little difficult or might not work with this or that, and going back and forth and collaborating. The main thing I think is that the core blocks have a lot of these options and it’s sort of like, I think it was the Abraham Lincoln quote, which is, you can please all of the people some of the time, or you can please some of the people all of the time, but you can’t please all of the people all of the time. And so it just can’t be all things to all people.

[00:18:02] Nathan Wrigley: I guess the nice thing about Gutenberg blocks is that they nest. You can put in a block and then inside of that, let’s say, I don’t know, it might be a group block or something like that, and then you can nest things. And one of the nested items could be a core block, and then you are going to unlock the ability to modify that core block. Let’s say it’s a paragraph block or a heading block or something like that.

So it may be that you’re doing custom work with the parent blocks, but the bit that you are trying to open up to the client, if you like, may just be a core block, which is a child of that. Have I kind of got where you were describing there?

[00:18:40] Alex Ball: Yes, that’s exactly right. And that inner blocks element that you can use either if you’re building a custom block in React, or if you decide to go the route, we tend to use ACF on a lot of sites, and ACF has a very easy method for creating blocks as well.

But you’re not constrained to just using ACF fields on those. You can use that inner blocks element in an ACF block to include a core block or core blocks. And we’ve definitely done that because again, sometimes you have a core container block, like a columns block that’s going to give the user a slider that lets them choose the number of columns.

And we don’t necessarily want that. I wanna use the paragraph block within that, but I don’t want the ability to slide that thing all the way to the right and, insert a six column layout, because that’s not gonna look good anywhere.

So I think that you nailed it. I think that there is always that combination of some of that custom work, and some of the core blocks that we’ve already got that make it easier to bootstrap things.

[00:19:55] Nathan Wrigley: I have a feeling that if we were to have this conversation, I’m gonna say 24 months. I think if we had the same conversation in 24 months, I’m imagining that some of the things that you can not achieve at the moment with core blocks, that will have gone, and the layout will be almost entirely possible with core blocks. I certainly know that that’s the intention.

We’re not quite there yet, but some third party things, I’m thinking of things like GenerateBlocks and so on at the moment. They’ve really got the whole, the grid layout and all of that really well defined and sussed out. And I just think it’s a matter of time, so maybe it would be a moot point in 24 months and we might just be able to skip over that.

[00:20:32] Alex Ball: I think that you’re right. I agree with that. I don’t know if there is an equivalent to Moore’s law about, you know, how quickly Gutenberg is going to double or whatever to make itself kind of the next version of it. I know that they, well, I think that they think of it in phases. And this imminent third phase, whether it’s already begun or it’s about to begin, I’m not sure, but that’s sort of the workflow phase, and the emphasis is going to be on collaboration, I believe.

And then after that I think there’s a roadmap for looking at things like multilingual stuff. So, your framing it like that, looking at it in the future, and some of these issues we’re talking about today, being obsolete at that point is correct. And I think is hopefully captured by that phased approach that they are talking about

[00:21:27] Nathan Wrigley: In your presentation notes, you mentioned that you are essentially, you are handing over your work to clients. They’ve paid for their website and you want to mitigate them and you use the word breaking or break. Are the tools for allowing clients to modify this thing, but not this thing. Do they exist in core already? Can you deploy those things or is that custom work?

[00:21:52] Alex Ball: The answer to that is a hearty, confident, it depends. It would be really nice to be able to get very granular with some of these things and let different roles control different things. There is a little bit of that now. We’re starting to scratch the surface with that, as I understand it. Since version six, we’ve got this block locking feature. Now to clarify, before version six, you have the ability to set a template and use that template lock attribute to determine whether the entire template that you’ve defined is locked down and nothing can be added or moved around, or whether things could be moved within it. That existed already.

Now what we’ve got is on the block settings itself, a little lock icon and the ability to do those same things with that block. I wanna lock this block so it can’t be moved. I want to lock this block so it can’t be removed. I wanna do both. You can do both of those things now and, I think it is the can lock attribute. I may be wrong on that.

There’s an attribute that will let you specify whether a user, based on their role, is able to access that lock setting. Now, that lock setting itself is a little bit rudimentary. We’re talking about this and we’re going, Oh man, so only administrators can add the drop cap. We’re not there yet, as far as I know.

[00:23:27] Nathan Wrigley: Yeah. I think at the moment it’s a case of, and I could be wrong about this, maybe things have moved on. I think it’s merely a function to lock it for now. It is locked, but I think almost anybody can go and unlock it. The principle, I think, is to lock it just so you don’t accidentally do something.

But I feel that the things that you’ve described, that’s a real nice roadmap, isn’t it? The ability to be able to lock things in the UI based upon roles. Who knows, even based upon particular users. And so, almost everything comes into play. So as an example, you are an editor, you can do anything more or less, you know, we’ve given you real wide scope to move things up and down, change the colors, change the font, change the text, whatever, depending on which block you’re using.

But you are a different role. Created a new role for some other person in the organization, and all that they can do is move things up and down. Just that, there’s no other capabilities. And I feel that all of that is going to come and we’ll be able to lock people in and out. And at the moment, as you said, it’s all possible if you are a developer, but the day will come, I’m hoping that that’s all possible by non-technical users with the necessary permissions to do that in some kind of UI.

[00:24:39] Alex Ball: Yeah exactly. I feel the same way. And in my talk there’s a bit of a constraint with time. And so I think it comes off a little bit as feeling like I’m referring to this sort of monolithic, the client, as this singular entity and it’s the same everywhere. And obviously it’s not. Every site is different, every client is different, every client team is different.

But even beyond that, you could be talking about situations where you had your stakeholders during the project. They loved the designs. They understand what they’re getting. They understand how to use it. They understand what sort of control they have when they are adding blocks and creating content. And then you have a relationship with them and maybe a maintenance agreement or something, and six months later, they’ve hired someone new, who was not present to hear about why the designers chose this over this. To hear the rationale behind choosing these button styles over these button styles, and getting all of that background on the design and why it works so well.

But they do have some assignment to add a CTA to the website, by tomorrow. And they want it to stand out. And the controls are right there on this button block to choose any color they want for the text and any color they want for the background. And they go ahead and do that. And then you hear from the supervisor, the person that you’ve been working with, who says, we establish this color palette. How were we able to go so far outside that with hot pink. And also, this person didn’t choose an accessible contrast ratio between the button text and the button background colors.

So you can imagine all these different situations where even though you accounted for some of these things, and even though there was a bit of that uncertainty and agreement with the client that you can do this, but you shouldn’t. There are still situations that maybe you didn’t account for that will allow them to go outside the bounds of what was really intended.

And then the counter argument, I suppose, is probably it is their website, and they did pay for all this and it’s theirs. And if they decide they wanna do that, they can. And I guess the only real response to that is that that is fine. It is your site and we’re happy to help you with it. But when you run into these issues that occur because of all that control and your willingness to change these things, then there’s only so much we can do. And if you decide that you want us at that point to put some limitations on there, then we will be happy to.

[00:27:32] Nathan Wrigley: Yeah, there really is no perfect answer to this question is there? There is just what that particular client is willing to negotiate. And it may be that a particular client just wants nothing to do with it and wants to write you email. Every time they want to make a modification, the email comes in and you do it. So they don’t need any permissions of any kind.

There are gonna be the others who are gonna want everything available to them and potentially do a wonderful job, but potentially really be on the phone a lot, asking you to fix things. And I guess there’s a job of figuring out the contracts, and working out, okay, if I give you this permission, that’s fine, but, I don’t know, here’s our hourly rate when things go pear shaped.

[00:28:13] Alex Ball: Yes. and we are not the HOA president who is out here to walk the neighborhood and point out the mortar color in their bricks, that is not an HOA approved mortar color. That’s not us. So I would go back to what I said before where it’s, I hope we are establishing a relationship with the client and that part of that is that collaborative nature and that understanding with them of what they’re getting and what can be done.

And we do tend to have projects regularly where there is training with the client built in, and that is really helpful. Because we’re able to do a walkthrough with them and explain these things, and have them point out things that maybe they’ve already been in there doing content management, and we’re running into something with this or that. And then we’re also able to provide them with documentation that they can continue to refer to. And that is obviously a great opportunity to discuss all of these things.

[00:29:14] Nathan Wrigley: How granular have you gone with this in the past? Have you handed over websites where there’s been literally dozens of users or user roles where they’ve got, this particular user role can do these myriad of things and this other user role can just do far less? Have you really explored this a lot and found it to be fruitful?

[00:29:31] Alex Ball: I wouldn’t say that we have had, or at least that come to my mind right now, too many sites where we have many, many different user roles. You certainly run into sites where there needs to be some sort of editorial workflow and approval process. And I think that that, for the most part, handles those sorts of things.

And I also think that, where we are right now with the block editor, in the future we are more likely to be able to handle some of these things on a role by role basis. Whereas right now it is a little bit more difficult.

[00:30:12] Nathan Wrigley: You mentioned training and that’s a big part. How to describe it? I think it can be quite a tiresome thing to create the training because, on some level you just want the website to be finished and you want to hand it over. But I guess if you are handing over a website based on Gutenberg, and the clients have never seen this before. Creating training materials, being on hand, going to their premises and demonstrating it to them, or creating videos and putting those somewhere. I guess that’s an important part in this puzzle.

[00:30:39] Alex Ball: Yes, yes. We tend to record those training sessions, those, uh, Zoom calls where we’re walking through it and screen sharing. And we did recently go through the documentation, that sort of, starter framework of that documentation, and revise it and go through some of the things that we’ve got in there.

And then obviously every site gets a few different, not even appendices, but main sections. There’s a table of contents and you go through some of the basics of WordPress, but then you delve into some of those custom blocks and sometimes they really need some extra documentation over exactly what each feature does.

You know, you’ve got the different fields labeled and you’ve got descriptions on those labels. But it really helps them to have that documentation to refer to as well, explaining why this happens. Why when I click this, this other conditional field disappears. And it’s because if you do it this way, you’re not going to have access to this or vice versa.

The documentation and the training is not part of every project, but when it is, a lot of the things that we’ve talked about can come up and be worked through, and for the most part solved, or at least established what lines are where.

[00:32:04] Nathan Wrigley: You mentioned at the beginning that you weren’t a developer. You’ve sort of grown into that role. And I imagine there’s several people listening to this who have played with blocks in the UI. They’ve dragged things in and they’ve modified what’s available to them there and, that’s great. But if they want to start tinkering with blocks and they want to alter what the capabilities are with the blocks, the core blocks, whichever block it may be. What are the kind of things that they need to be interested in? Where do they need to be going? What are the documents that they need to read? What are the technologies they need to understand?

[00:32:35] Alex Ball: That’s a very good question. I, a few years ago at WordCamp, did another talk where I talked about coding like a writer, and it was trying to give those non-technical content people more confidence in diving into the code a little bit.

Whether it’s modifying the attributes on a short code. You know, you’ve cut and pasted from documentation from the plugin that provides that short code. But you’re starting to look at that and realize that these different little attributes within those brackets do different things. And what happens if I do this?

Delving into the html behind the scenes a little bit. Getting your feet wet and all that. And I used principles that you would adhere to in writing and also try to adhere to in coding, to get them to feel more comfortable doing what I think you were describing, which is getting into that code a little bit and not simply staying on the surface with just the UI.

And it was things like don’t repeat yourself, which is obviously a massively important axiom in engineering. It was things like, get to the point as quickly as possible. It was things like writing good documentation. Commenting the things that you are adding to the code so that other people know what it means.

That’s the closest thing to that sort of pure editorial writing that I touched on. And, so I think that hopefully people felt a little bit empowered by that to go, Oh, okay, well, right. So this is the way I would approach the lead in my story. And so this is how I’m going to approach the template on this page or the way I structure these blocks.

[00:34:33] Nathan Wrigley: When you began your work on blocks, were there any places that you found to be particularly useful that helped you understand the technologies behind? Because it is a big, it is a big change. If you’ve been working with PHP for the last 20 years, not really wanted to stray away from there, there’s, there’s a lot to be learned.

And I’m imagining that you’ve found better places than others, shall we say. What are some of the resources that you have enjoyed using that you would recommend to others, should they be interested in this?

[00:35:00] Alex Ball: The first one that comes to mind that I think I hit on pretty regularly as I was learning was Bill Erickson’s website. He’s got a lot of good information and it appears pretty high up in most Google results. So it shouldn’t be too difficult to suss out his information on it. But obviously going to his site and looking through things tagged as Gutenberg should do the trick as well.

Well, and I mean obviously Stack Overflow, so much information on there. There is a trainer online named Zach Gordon, who does a lot of JavaScript based training, which is what you’re going to need to deal with, if you are starting to create those custom blocks and you’re not going to use some sort of scaffolding or use that Advanced Custom Fields approach to building them.

I remember using one of his courses to dive into some of that and get a lot of good information from him. And, along the way we started modifying that starter theme that we use for projects to make it easier to build it into a, a block theme.

[00:36:14] Nathan Wrigley: Alex Ball, thank you so much for joining us on the podcast today. It’s been a real pleasure chatting to you about blocks and locking them down and so on and so forth. Thank you.

[00:36:22] Alex Ball: No, thank you. It has been my pleasure.

[00:00:00] Nathan Wrigley: Welcome to the 11th edition of 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 themes, and in this case, the creation of blocks with a plugin. Up until now, we’ve released this podcast each month. But we’re going to move to a weekly schedule from now on. And that leads to a couple of things. Firstly, it goes without saying that there will be lots more podcast episodes, and I would encourage you to subscribe to the podcast so that you can get all of those episodes automatically each and every week. You can do that by searching for WP Tavern in your podcast, player of choice, or by going to wptavern dot com forward slash feed forward slash podcast, and you can copy that URL into most podcast players. Secondly, with so many more episodes, I’d really like to hear from anyone out there who would like to come on the podcast and talk about whatever it is that you do with WordPress. It might be that you’re a developer, a WordCamp organizer, a contributor, a designer, honestly… if it’s about WordPress, I’m keen to hear from you and hopefully get you on the show. Head over to wptavern dot com forward slash contact forward slash jukebox, and use the form there. Once again, wptavern dot com forward slash contact forward slash jukebox. And I look forward to hearing from you.

So on the podcast today, we have Vinny McKee. He’s the creator of the Wicked Block Builder plugin, which is a tool to make the job of creating your own custom blocks, as easy as possible. I’m sure that you know, that the WordPress editor is all about blocks. You can create content and now whole websites with small components, a title here, and a paragraph there.

But the real power of blocks is the way that they can be extended so that they can consume and display any kind of content in any way that you can imagine. The WordPress landscape is moving towards blocks as the way to create and present all the things, and we’re just at the start of this very exciting journey. You can download and try out blocks for almost everything. Some do one thing. Other block packs bring entire suites of interesting blocks to the table. But there’s a problem. Blocks are not all that easy to create. Yes, you might very well be a talented developer who has taken the lead in learning block creation. You burned the midnight oil and got your head around all the complexities. I suspect that it was an uphill struggle. But WordPress’ is mission is to democratize publishing. In an ideal world, not just publishing, but extending WordPress would be something available to the masses. Step in Vinny McKee. His Wicked Block Builder plugin is one of the tools out there that enables you to build your own blocks without the need to understand much of what’s going on behind the scenes. And there’s a lot going on behind the scenes.

Page builders allowed users to create beautiful websites without needing to learn code. Block builders, well they’re doing the same thing for blocks. Today on the podcast we learn about why Vinny built the plugin as well as how it works. What problems does it overcome? And are there any limitations to what you can build? If you’re interested in trying it out, you can find the links in the show notes, head over to wptavern dot com forward slash podcast, and look for episode number 11. And so without further delay, I bring you Vinny McKee.

I am joined on the podcast today by Vinny McKee. Hello Vinny.

[00:04:40] Vinny McKee: Hey, Nathan. Thanks for having me on the podcast.

[00:04:42] Nathan Wrigley: You are most welcome. Now, Vinny is going to be talking to us today around the Gutenberg subject is the best way to describe it and blocks in particular. He has a great deal of expertise in this area and has a plugin which may be of real interest to the people who are listening to this podcast.

This whole episode really was brought to my attention by Justin Tadlock, who on the 14th of January, 2022, wrote a piece called Wicked Plugins Launches UI Based WordPress Block Builder. So be sure to go and check that out. So I asked Vinny if he wanted to come onto the podcast today and here we go.

We’re going to be talking about blocks and building blocks. First question though Vinny, if it’s all right with you, I’m going to ask a more generic question. Would you mind just telling us a little bit about yourself, your history with WordPress and so on.

[00:05:33] Vinny McKee: Yeah. So I’m a freelance web developer and plugin author. I’ve been a freelance developer since around 2006. And I think the first time I really started using WordPress was actually in 2006. At that time, I didn’t really know anything about it really. And to be honest, didn’t even really care that much about it at the time. It was just a way to solve what I needed at the time, which was two blogs for clients so that they could easily create blog posts.

And so then I think it was probably around maybe 2008 or 2009, if I have my timing correct, when I really started using WordPress more and started to build lightweight sites that used it more as a CMS and started to build custom themes for it and everything. And then of course, fast forward to today and I’m using WordPress almost exclusively for all of the clients sites I built or build.

[00:06:27] Nathan Wrigley: Where are you based?

[00:06:28] Vinny McKee: I am based in Seattle, Washington.

[00:06:31] Nathan Wrigley: Okay. So we’re probably going to be talking today around the block builder plugin that you’ve got, and probably it’s going to be the easiest thing to just mention where that URL is right at the start. So the company is called wicked plugins, and you can find wickedplugins dot com easily enough, and from there, you’re going to be searching around for wicked block builder that will enable you to see what we’re talking about today. There’s also a wordpress dot org version. And obviously that’s over at wordpress dot org forward slash plugins forward slash Wicked Block Builder. Each of those words is hyphenated. I will put those links into the show notes and anything else that we discussed today that comes up, I’ll endeavor to put those into the show notes as well.

Tell us why you decided to put all of your bits and pieces into blocks. I know that for many people, this is clearly the future. There’s a lot of interest in this, especially right now. But a lot of people are staying away from it at the same time. What is it that you saw all those months, years ago that made you endeavor to build this solution?

[00:07:35] Vinny McKee: Yeah, I think it’s similar to what WordPress has been great for a long time, which is extensibility. So I think what’s really cool about blocks and what I like about it is that you can extend the block editor by creating your own blocks. And so that gives you a lot of freedom. It gives you the ability to create blocks that are tailored to individual projects. And I think that’s really useful. And I think that’s one area where it stands apart from other ways that you can build a site with maybe a page builder or something.

I know you can extend other page builders as well, but I feel like with blocks and Gutenberg, I like that it’s baked directly into WordPress. And I just think that it’s neat that you can extend it just like you can extend WordPress in other ways.

[00:08:23] Nathan Wrigley: Yeah. I guess the page builder analogy is quite a good one in that if you are a heavy user of a particular page builder, you may well be interested in creating the equivalent of blocks. So app like functionality within that particular page builder. But the issue I suppose there is that it will be confined to that page builder, and so the audience potentially may be limited. Whereas the block based initiative enables everybody with the default install of WordPress to manage to do these bits and pieces.

Yeah. So really nice inspiration. So why did you decide to actually put your elbow to the metal as it were and get stuck into this. It seems that this is a problem of building blocks. It’s tremendously difficult if you’ve never done this before, but equally you could have just sat there and waited for somebody else to build a solution or indeed for that to be no solution at all. What compelled you to create a sort of GUI interface in order to assist people who have the challenge of building their own custom blocks?

[00:09:22] Vinny McKee: Yeah. So what happened is, as I started to use the block editor to build sites for clients, I found myself wanting to create my own blocks. And because I felt that I needed to do that in order to achieve the look and feel and layout and functionality that the designers I was working with wanted for their sites. And so, I felt like I needed to create my own blocks in order to have the control I wanted over the markup and to achieve all those things as far as the look and feel and layout and those types of things. So what I did is I started creating blocks for the sites that I was working on. But what I found is, as I was going through and creating these blocks, I noticed a few things.

One is that, so when you create a block, blocks have two different functions to generate their markup. There’s one called the edit function, which generates the markup that you see for the block when you edit a page and you see your block in the editor. And then, blocks also have what’s called a save function, which is responsible for generating the markup that actually gets saved to the database when you save a page, and then that’s what you see on the front end when you view the page. And so if you want your blocks to look the same in the editor, as they do on the front end and vice versa, which is what I wanted, you have to basically code the block twice. And, you know, even if the markup is almost identical for both views.

And so that was one thing where I noticed it was a duplication of effort and took a little bit of extra time. And even if you want the block to look exactly the same in both of those views, you have to tweak the code slightly. You can’t just copy and paste. And so it ends up being a lot of… it can be a lot of work.

Something else I noticed was that I was spending a lot of time referencing documentation as I was building blocks. So even after I learned how to build blocks, was was still looking at the documentation a lot, because I couldn’t remember things like, okay, what is that control named? If I wanted to add a text field to a block, for example, is that called text control or is that called text field?

And then I would always forget like what attributes those components or controls accepted. So for example, when I would add a drop down to a block, I would forget what the attributes that allowed you to set the options was called options, or was it called choices? And then how did, how did the data needed to be formatted to go into those options?

Things like that. So I still had to spend a lot of time looking at the documentation, even though I had learned how to build blocks. I kept running into design patterns that were hard. So for example, if I wanted to add an arbitrary number of items to a block, something that would be good for a repeater, for example, like adding an arbitrary number of images, or if you wanted to create like a team block that displayed a grid of people where you could sort the people in the block that would take awhile and it was hard to do.

I guess what I’m trying to say is that what I found was there a lot of things that were adding up to take a significant amount of time, and I just felt I needed to create these blocks for these in order to build the sites that I wanted, but that it was too time consuming for it to be economical. And that I just felt like I wouldn’t be able to produce these sites without being able to build these blocks faster.

[00:12:27] Nathan Wrigley: Yeah. This is the problem that we hear about so much is that the move over to blocks really does create a technical debt, really. What I mean by that is, it’s difficult. There’s a new, whole new raft of things that must be learnt, new techniques that need to be acquired, whole systems that you need to put in place in terms of software as well and what have you. And I feel that a lot of people are put off just by this problem. They simply don’t have the time. They’re working. They’re busy. They’re building websites, possibly for clients or what have you. And the time to go out and spend learning is simply not available to them, and obviously in your case, you managed to find that time and create that bridge for yourself and make it happen.

Was that a difficult journey? So going from no blocks, several years ago to the ability to now create not only blocks, but software, which builds blocks. Did you find that journey fraught with difficulty? Was it fairly straightforward? What was your impression?

[00:13:24] Vinny McKee: Yeah, for me, it was actually fairly difficult because prior to Gutenberg, I didn’t really have a lot of experience with React and I didn’t have a lot of experience with a lot of the tooling either that you would use in a React project. So for example, NPM, Webpack, and some of the other tools that we use to maybe set up a React project. I’d worked with it just a little bit before Gutenberg, but not much. And yeah, I didn’t have that much experience with it, and to be honest, I was pretty intimidated by it because that just wasn’t something that I was familiar with.

And so it did take me quite a while to figure out how to learn React of course, but then also I think for me, what was even more challenging was some of the command line stuff and configuration stuff. Setting up Webpack, for example, to be able to compile the project. And I know now there’s ways you can use other tools like WP Scripts.

I also wanted to understand for myself, make it easier, but yeah, at the time, I also wanted to understand for myself, you know, how those things worked, but yeah, it was a challenge. And even today there’ll be weeks where I might spend hours trying to solve a configuration issue with Webpack. Yeah, it was definitely challenging.

[00:14:37] Nathan Wrigley: I think that’s a really valid point. This is not something which is going to be for everybody. If you are of a certain mindset and you have the time available and possibly the skills available, this might be open to you. And then of course, there’s the other people who presumably you’ve built your Wicked Block Builder for, is the crowd of people who perhaps don’t want to go through all of those steps, learning all of those different things. You mentioned React and the build process and all of that. They just simply don’t want to do that. But they would like to dabble in creating blocks, either for themselves, or for their clients. And I guess that’s the tool that you’ve built. Have I got your target audience about right there? Is it people who are keen to build blocks, but don’t really wish to do the learning that might be required if you wanted to do it all by hand, if you know what I mean?

[00:15:28] Vinny McKee: Yeah. I think that’s a big part of it. And that was certainly one issue I was trying to solve was to make the barrier to entry much lower. But I think too, I was also, the main reason I was inspired to build it was actually to save myself time. Even as a developer, I wanted a way to be able to build blocks faster.

And so, yeah, I mean, it’s definitely for people that maybe don’t want to learn React, or set up the tools needed to build blocks from scratch. I also aimed it at developers as well, hopefully make their lives easier and make it much more efficient to create blocks so that when you’re working on a client project, you can spend less time working on some of those other things I mentioned earlier and focusing more on just creating the blocks you need.

[00:16:12] Nathan Wrigley: Okay. Let’s dig into the tool. It is a plugin for WordPress. As we mentioned at the top of the show, it’s available in a free version on the repo and also a commercial version over on the website, which I’ll link in the show notes so that anybody who doesn’t want to hear the URL in the podcast can just find it, but would you just at the outset, just describe the main differences between the free and the pro so that everybody is really clear where that boundary lies.

[00:16:40] Vinny McKee: They’re exactly the same. The only difference is that the pro version has a couple of advanced features. And so the main features that one has, is a repeater component that allows you to add repeating items to a block as well as conditional logic. And then it has a couple of other advanced components as well. But for the most part, the free version has almost everything and you can actually build the exact same blocks.

The only difference would be something maybe like a repeater where if you wanted to have an arbitrary number of links in a block with the free version you had maybe add slots for five links to your block or something. Whereas with the pro version, you could use a repeater so that you can add an arbitrary number of items or links the block.

[00:17:21] Nathan Wrigley: Okay. Got it. Thank you. That’s made it really clear. Okay. So we’re going to try to describe, cause it’s a difficult thing trying to describe what is a graphical user interface on a podcast, but we’ll give it our best go. As with all things plugin, you must install it on your website. And then you’re presented with a range of new menus in the admin area.

Wicked Block Builder is what I’m seeing currently. And you have the option to add new. And the intention is that you go through the tool and at the end of it, when you go to a post or a page, And you click the little inserter, the plus button, you will hopefully have yourself a ready-made block available to be used to put whatever kind of custom data it is that you want to display on your website.

So, with all that in mind, do you want to try, you know the tool far better than I, I’ve really had just the briefest of plays, but did you want to just describe the process that you would go to in order to set up a simple block with some simple attributes and just discuss what kind of things we’re doing.

[00:18:21] Vinny McKee: Sure. Yeah, I’ll do my best. Yeah. Like you said, once you install the plugin, then to create a block, you just go to Wicked Block Builder in your admin menu, and there’s an add new option. So you click add new. And what that does is that opens up the block builder tool, which is just an interface within WordPress that lets you create your block.

And so that tool is organized into six main screens. And so what you see first is the setting screen and the settings screen just lets you enter basic information about your block and configure some things. So for example, you can enter the name of your block. You can give it a description that you can choose, like what alignment options it supports and whether or not you’d like to make it dynamic.

So then the next screen is attributes. And so the attributes screen lets you configure the attributes for your block. And if you haven’t worked with blocks before then, what attributes are a way to store and, or extract data from your blocks. So they kind of hold the data that’s for your block. And so once you configure attributes, which to configure attributes, it’s really just a matter of dragging and dropping an attribute type, a type, meaning like the data type that you want that attribute to store.

So that could be like a string, for example, or, a true false value or a number and array as the other type of attribute. So once you’ve got your attributes added to your block, then the next screen is called the editor view. And like I was talking about before, there’s two views, two blocks, there’s the edit view, which is what you see in the block editor. And then there’s the front end view. In this plugin we start with the editor view and on that screen, what you do, that’s the kind of the meat of it and where you really build the block. And you build your block by dragging and dropping HTML elements and components. So components are things like text fields or drop downs or radio buttons or check boxes or color pickers, anything that you want to add to your block, to allow people to interact with it, to change settings or to input content.

And so what you do is you drag the HTML elements that you want. So like a div tag, for example, if you want your block to be a div and then maybe if you want another div nested inside of it, you would drag another div and nest it inside the first div. And then if you want a rich text control to be able to input some texts, you would drag that inside. You know, one of the divs, but the idea is that you have full control over the markup and, you create the markup however you want by dragging and dropping. And there’s no limits to, you know, what markup you can add that you can put any valid tags in. So what that does is create the editor view and then the next screen is the front end view.

So you have the option of building the output that your block will generate when it gets saved to the database, and what you see when the block is viewed on the front end, when you view a page. However, that screen is actually completely optional. You can skip that step. And if you do then plugin will use the markup and everything that you set up on the edit screen, and will use that as the, for the front end view.

That’s one of the ways that saves you time is you don’t actually have to create those two separate views anymore. You can just create the edit view and then the plugin will use that same view for the front end, if you want your block to look and use the same markup on the backend and the front end.

And then next is the sidebar screen and the sidebar screen works similar to the previous two screens. It lets you drag and drop HTML markup and components, but it puts all those things in the block sidebars when the block is selected in the page editor. Yeah, once the blocks selected, then whatever HTML and components you add to the sidebar appear on the block sidebar on the right hand side.

And finally there’s a style screen. And that’s just basically a CSS editor that lets you put in CSS for your block. It’s completely optional. You don’t have to put any CSS there. You can, you know, enqueue CSS like you normally would through your theme or through a plug-in or however you’re most comfortable with it, but it’s there for people who want a really easy way to include CSS for their block.

And that’s kind of the process of building the block and then you hit save. And from there, you should be able to add it to a page.

[00:22:38] Nathan Wrigley: I’m going to, to sort of run over a few of those bits and pieces. And I’m going to draw an analogy for those of you who have used a tool like Advanced Custom Fields or Metabox or something like that. The similarities here are fairly striking to me in that the attributes that the sort of fields that you might create, so for example, you would like an image when you need an image attribute, you might need like a number attribute or a true / false, like you said, and you can set all of these different things up and then you move on to the next area.

And as Vinny was just saying, this is how it’s going to look when you’re user inserts it, what is it going to look like to them as they’re actually creating the block? And then interestingly, you’ve got the front end view. That’s what it will look like once it’s complete and you’ve published it and it’s visible to the world.

And then, like you said, there’s the sidebar so that you can modify all of the settings that may be associated with that. And then obviously the style. So I think if you’ve used Advanced Custom Fields or Metabox or something like that before, you’ll be very quick to the party. You’ll learn how this works really quickly.

I have to say having had the chance to play with it a little bit today, I went through the three step… building your first block tutorial, which I found to be really straightforward. Probably took me about an hour, I would say. And I was able to follow along with the steps and I had a completely functional block, fairly straightforward example. It has an image, it has a title, some text, and then ultimately there’s a button, depending on what text you put in that button appears. It doesn’t do a lot, but it’s a really nice way to get going. So I would say that if you’re confused by any of this, go and look for the support documents that Wicked Blocker Builder guide, and you want the building your first block section.

I think you’ve done a really great job of explaining how it all works there. Well done.

[00:24:31] Vinny McKee: Thank you.

[00:24:32] Nathan Wrigley: So the backend then handles all of that. I’m just curious. Is there any situation that you can imagine where the editor view, what it is that we’re doing in the backend to actually create the block on our website, where you would like that to be radically different from the front end view. Perhaps the editor view is going to be much more basic and stripped back. And then ultimately the view that people see on the website is going to be a bit richer. I’m just trying to figure out why those two sections are separate.

[00:25:01] Vinny McKee: Yeah. So I think part of it could come down to user preference and then another part of it might just depend on block output, starting with user preference.

It’s possible that some users might just have a preference where in the editor view, maybe they want almost more of a forum based approach to inputting the data for the block. So rather than displaying a rich preview of the block, maybe they just want to way for clients to input data. But then on the front end, of course, you know, it needs to be formatted properly or the way that they want to look. And that might be one example where you would create a separate view for the front end versus the editor view. I think another example is where maybe you needed the market to be different. So for example, say you want to create a grid, a block that displays a grid of, logos for example, and you want each logo to be linkable, and this might be a contrived example because there’s probably other ways that you could do it as well. But just as an example, let’s say you wanted to create a block like that, and you could, in the end of their view, add like an image component that would allow you to select an image for the logo. And then you could add a text field that would allow you to enter the link for the logo. But you may not want to wrap the image component within a link in the editor view because you don’t want it to interfere with being able to select an image, and when you’re editing the blocks. So maybe you want to tweak the markup for the front end. So then on the front end, it would actually wrap the image within a link element, if that makes sense. So that’s another example. And especially with the free version, because there’s no conditional logic, that would be one way you could achieve altering the markup.

[00:26:40] Nathan Wrigley: Actually, the more I think about it, the more that I can imagine situations where the two might be really useful to be separated. So I’m just at the minute been looking recently at real estate agent websites, and it might be quite useful if you had a block to do with a house and you were uploading all of the bits and pieces associated with that house, particularly the images. You might want those images to display in a really full on way on the website, large colorful, and what have you, and you may just want the thumbnail on the backend so that you can see that something has been uploaded, but you don’t as the person maintaining that block, you don’t actually need to see them in all their glory. But the person coming to the website, who’s thinking about buying that house would probably wish to see them in all their glory. So yes, I’m making in roads into what you’re thinking there, I think. Is that the right idea there?

[00:27:26] Vinny McKee: Yeah, exactly. That’s a great example. And I think similar to that, something like maybe a slide show or like a hero section where maybe it displays just one image, but changes on page reload or something. So on the front end, you really only see one image, but on the back end, you need to be able to add multiple images, but you might want to way to show which images are selected. So you might display those images in the block, on the back end, but then on the front end, you would only see one image at a time. But yeah, the example that you gave to you, I think is, perfect.

[00:27:54] Nathan Wrigley: Yes. So the tool itself is a very much a drag and drop tool. You’re dragging in components that you wish your block to have, be those images, text fields, buttons, what have you. Imagine you’re building up these Lego bricks to make your block.

There must be a little bit of understanding of various bits and pieces of web technologies. For example, I would imagine you at the very basic you would need to have some understanding of HTML in order for this to work. Is there a bare minimum set of things that you need to be able to understand, to make basic use of the plugin?

[00:28:29] Vinny McKee: Yeah, like you mentioned, I think you have to have a decent understanding of how HTML works and how tags are nested, because you do create the markup yourself in this plugin, it is drag and drop, but yeah, you do have to kind of understand how markup works and then to understand some of the attributes that certain tags support in that case block attributes, but you know, HTML attributes that are added to a tag in case you need to configure those. For example, if you want to add a simple anchor link to your block, you would add an a tag, and then you might add an href attribute. But if you haven’t worked with HTML before and don’t know that’s what’s required to create a link, then yeah, you might be a little lost or that might be a little challenging.

And then too, I think, to get good results, you do have to know some CSS because just adding, you know, most blocks I would imagine that you want to have some styling. And so, you know, in theory, you could just create a block that’s unstyled that allows you to input some content. And then of course it could output it on the front end, but without any styling, you probably wouldn’t get the best results or the results you want.

So I think it does require a little bit CSS knowledge as well, although I think, you know, you can get pretty far with just very basic CSS. So there, I think it just depends on how far you want to take it.

[00:29:45] Nathan Wrigley: Yeah, if you want something functional, which works, you can probably get away with minimal CSS, but if you want it to look nice, then yes, there’s going to be a little bit of a learning curve there. So I guess caveat emptor, if you are going to be looking into this plugin, there is a little bit going on.

Now, as with all tools that make something as straightforward as this does, I’m curious to know what’s going on in the background that you are relieving us the burden of. So for example, I’m adding in my attributes and that literally is a two second job. I basically click a button and add an attribute and then give it a name, an attribute name, something that I can remember and use later. And I can do that, and I could probably put five or six different attributes into my block in the space of just a couple of seconds really. Again, the same would be true with the editor view. I’m able to create all of those bits and pieces and link them up to the attributes that I made. What complexity are you stripping away? What difficult things are going on in the background? Now it may be that there’s too many to talk about, but I’m curious as to some of the challenges that you’ve stripped away.

[00:30:51] Vinny McKee: Yeah. So, I mean I think one challenge is just the whole build process that’s involved with creating blocks from scratch. So, because you’re using a plugin, it’s going to, based on how you build the block, it’s going to generate that block for you. And so you don’t have to worry about, you know, any command line stuff or knowing JavaScript or knowing React any of those things because you’re creating the block to the plugin.

So I think that’s one big thing that it addresses. Things like the attributes, it’s not hard to add attributes to a block when you’re building from scratch, other than takes a little bit of time to just to code them. But it does make it a little bit easier, I think, to be able to do it through an interface.

Something else it does as well is if you’ve created a block from scratch before, you’ve probably run into this where if your block is, let’s say you create your block and then your block is used on some pages and then say, you need to make some changes to the markup of the block. What happens is if you just make those changes to the block, you’ll actually, the next time you go to edit a page, you’ll see an invalid content warning, which is kind of scary because it looks like the block is broken and it doesn’t display correctly in the editor. And so in order to avoid that, you actually have to create a deprecated version of the block and then behind the scenes, what WordPress does, is it migrates the markup from that block that was previously added to the page, to the current blocks version or markup.

What Wicked Block Builder does is behind the scenes. Anytime you make changes to your block, it automatically creates a deprecated version of it. So that in the next time you go to edit a page that already has that block, it won’t display an error. And then there’s some other things too, like I was talking about before, how you can just create the edit view, and if you want to look the same on the front end, you don’t have to worry about that. It’ll just create the front end view based on the edit view that you created, so.

[00:32:45] Nathan Wrigley: Yes, I was quite pleased in the tutorial that you did that, just simply putting the CSS in and missing out the front-end view step altogether. Still the block looked great because, presumably it was working on what you’d put into the edit view and the CSS that was there, which was about 50 lines or something like that, made it look really nice.

Okay. So I guess the offering that things like page builders brought to the table is that it makes things much easier. Some people are critical of things like page builders. I’m sure there’s many other things that we could point the finger at, but you get the idea, because they say that the code that is output on the front end of the website might not always be the most optimal. And I guess this is one of the features that Gutenberg has, one of the poster features is that it creates lean code. I’m just asking the same question of you. The way that your building blocks, do you have anything to say about, does it create a block that is streamlined and optimally built or have you had to make concessions in order to achieve the sort of GUI aspect of it? In other words, if I knew everything there was to know about building blocks and I did the same block by hand, and then did it through your tool, would there be a noticeable difference in either of them?

[00:34:06] Vinny McKee: Yeah. So I can’t think of a notable difference offhand, other than instead of the block being pre-compiled the block is generated on the fly when it’s used in the editor. It creates a native block, and so yeah, whatever attributes you add, those are all translated to the attributes that you would code by hand. It only outputs markup that you add to the block. The only exception to that is for the components that you add. So if you add like an image component, for example. There’s a little bit of markup that it adds in the editor view to handle being able to select the image and display the image. And then of course, when it’s saved on the front end, if you don’t output or if you don’t specify specifically how you want the output to be for that front end view, then the image component will automatically generate an image tag. But yeah, for the most part, it only puts out whatever markup you define an add to your block, but yeah, as far as how the block functions and works. It’s identical to a native block. It just happens to be generated on the fly when you edit a page as opposed to something that’s compiled ahead of time.

[00:35:17] Nathan Wrigley: Yeah. Thank you. That’s a good answer. In terms of where this is all stored, one thing that’s coming to my mind is if I am an agency owner say, and I have a niche, let’s go for real estate, as we were talking about that a moment ago, and I’m building several websites every month. And I put a lot of work into creating a block with your tool. Is there a way that I can use these on a multitude of websites? Is there an option to export a block and then import it onto a variety of different sites? How does all that side of it work?

[00:35:51] Vinny McKee: Yeah. So that’s actually a really good question. At the moment in the plugin itself, there is no way to export and import blocks. However, those blocks are stored as a custom post type. And then the data for the block itself is saved in a post meta field and a json object. And so you can actually because it’s just another post type you can use WordPress’s default export functionality and export them that way, and then import them using the WordPress importer tool. Of course, important export is something that we have in the roadmap and something that I plan to add to the plugin. But yeah, right now it doesn’t have that functionality built in, but you can achieve it through the WordPress tools.

[00:36:31] Nathan Wrigley: That’s great. We’ll come back to the sort of roadmap, cause there’s a few items which I think are worthy of discussion and we’ll do that in a few minutes time. Staying with the actual plugin and how it works currently. I’m interested, you mentioned about things like conditional logic. I know this is getting into the territory, I think of the pro version, but nevertheless, would you just describe what that enables you to do? What kind of conditions are we able to display our blocks on?

[00:36:57] Vinny McKee: Yeah. So if you’ve ever used a form builder and wanted to, you know, only show a certain field, if another condition is true, that’s essentially what conditional logic allows you to do.

And you can apply these conditions to all sorts of things. So the way it works is when you add, for example, an HTML tag to your block, it’s actually, all of the parts of the tag are broken up. So you can add like classes in line styles, attributes to that tag. And because they’re split up that way, you can actually add conditions to each of those things.

And so what that means is say, for example, you want to add, conditionally add a class to a block, say for example, you have a block where maybe you want to give an option of you have an image on one side and then text on the other side and you want to provide the option to swap them. So by default the images on the left, text on the right, but you have an option to flip them. So that text is on the left and then the image is on the right. Yep. Let’s say you add it. You create a class that changes that layout. So what you can do is you can add that class to the block. It says image on, right, but instead of always outputting it to the block, you can add a condition that says, okay, only add this class if the option display image on right is checked.

And so, so that’s an example, and then you can also use it to conditionally output tags. So what I was talking about before, where maybe you, you don’t want to output an image wrapped in a link tag on the back end, but you do on the front end. You could add some conditional logic to the tag itself and say, okay, only I’ll put this tag, you know, if this is true, or, and then there’s also conditional logic to show or hide things based on whether or not the block is selected in the editor. So things like that.

[00:38:41] Nathan Wrigley: The brain is ticking over all the different possibilities there. That sounds really ingenious. One of the things that I always thought would be nice if I were a plugin developer, which I am not, is it would be nice to see my plugin out in the wild being used by people and the curious and interesting ways that they can implement the plugin. And I’m wondering if you have any little anecdotal tales of people who’ve used your plugin and remarkable things that they may have done with it that perhaps you didn’t anticipate.

[00:39:10] Vinny McKee: Yeah. That’s a good question. I don’t know that I have any yet, because I just released the plugin in November. And so it really, yeah, I don’t know that I’ve had anyone reach out with any particular ways that they’ve used it. I guess I’ve had maybe some questions about how to do some things that I hadn’t thought of before. And so it made me realize that, oh, okay here’s another way that people might want to approach things.

[00:39:35] Nathan Wrigley: To be fair, I didn’t realize it was as new as that. So yeah, that’s absolutely fine. Like I said, right at the top of the show, there is a different pro version. The pro version, we won’t get into the actual pricing because it may be subject to change who knows, but there are three options. You can go for single site license, a 10 site license and the unlimited site license. So three different options. Of course you can. If you’d like stay on the free wordpress dot org repository version. That’s absolutely fine.

The last little bit, just before we tie this off is the roadmap. And obviously you’ve had some feedback. You’ve just described some of the things that have come back to you from your customers. Apart from the import and export which we talked about already, what are you hoping to be adding in the near term?

[00:40:20] Vinny McKee: Yeah. So in the near term, one thing that’s been requested multiple times or quite a bit is the ability to assign an icon to the block. I’m planning to add that in as well as, there’s also been requests to add more options as far as, so blocks what’s called these support features or these support flags where you can say, okay, this block supports something like an anchor so that you can in the block sidebar, you can add like an anchor and that’s something that’s kind of WordPress adds automatically, if the block says that, okay, I support this or things like topography, you can have font size and line height support, or you can add spacing support for things like padding and margins. So just adding some more settings so that you can enable those things for your block. And then of course adding more component types. So right now there’s all the basic ones you would expect, but then adding some more, like for just more component types. So you have more options of how you build your block. And then I would also like to add an ability to save the blocks as a json. So to like a folder within your theme or wherever you decide. The blocks when you create them in the interface, they would get saved to the database like they do now, but they would also get saved to a local json file. And so that way developers could commit their blocks to version control so that they kind of have so that they can version control their blocks. And that’s kind of what I’m hoping to add in the near term.

[00:41:43] Nathan Wrigley: Just something which has occured to me just as you were saying those things, there’s an increasing commercial marketplace for blocks, not as is the case with yours, the block builder, but the blocks themselves. There might be a marketplace for relatively inexpensive blocks, which do a single thing and do it really well.

And I was wondering if there’s any possibility from your plugin to commercialize the blocks that you make? I don’t know if that’s possible, even something you’re giving any thought to, but if I spend a lot of time creating a block that’s incredibly complicated and it has some value, with your tool, would there at any point ever be options to pull that out and make it available commercially.

[00:42:27] Vinny McKee: So I think the challenge right now is it in order for it to work, you do have to have the plugin to generate the blocks. So if you create the block and then export it and import it on another site, it’s only going to work if you have the plugin installed. I do think it would be really cool is if there was a way to actually export the block code. So that you could just import the block without having to have the block builder plugin installed. But I also think that’s a fairly complicated feature to build. So probably not something that I’ll be able to add soon, but I think if that were available, then yeah, there would be a way then that you could create blocks using the tool and then publish them and be able to distribute them without having to have the plugin in order to use the block.

[00:43:13] Nathan Wrigley: Well, thank you very much for joining us today and talking about your fabulous tool, Wicked Block Builder. As I mentioned, there will be links in the show notes down below to the repository version, as well as the Wicked Block Builder website as well. But Vinny really appreciate you coming on today.

Just prior to ending, if people are curious about what you’ve talked about today and wish to reach out to you, what are some of the best ways to do that?

[00:43:40] Vinny McKee: So, you can find me on Twitter @wickedplugins, or you can also contact us through our site at wickedplugins dot com.

[00:43:48] Nathan Wrigley: Thank you very much. I appreciate you joining us today.

[00:43:50] Vinny McKee: Thanks for having me, Nathan.