[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.