Mark and Keith are joined by expert WordPress developer Bill Erickson to discuss how to work with Gutenberg when building custom, modern WordPress themes.
Watch the video
Transcript
Keith Devon:
Hello, and welcome to episode number eight of WP Café, the show where we chat with WordPress professionals about practical solutions for solo and small WordPress development teams. If that sounds like you, then you can subscribe to the channel so that you don’t miss a show. You don’t have to smash the subscribe button like other YouTubers say. You can just gently press it if you like.
Keith Devon:
If you do enjoy this episode, we’d also really appreciate you pressing that thumbs up button. My name’s Keith Devon and today I’m joined by my co-host, Mark Wilkinson, and our guest, Bill Erickson. Welcome to the show, Bill.
Bill Erickson:
Hi, thanks for having me.
Keith Devon:
If you’re a WordPress developer building custom themes and trying to get your head around the challenges and opportunities that come with the new block editor, then this episode is for you. We’ll be talking to Bill about how Gutenberg has changed his workflow, which default blocks he uses, and when and how he decides to reach for something a bit more bespoke, how he handles styling in the editor, when and how he uses block pattern styles and variations, and a lot more.
Keith Devon:
By the end of the show, we hope that you’ll have more confidence to develop with Gutenberg as your editor of choice. If you’re watching this live, please say hello in the comments and tell us where you’re watching from. Also, please ask questions and we’ll do our very best to answer them live on the show. Okay. Before we get into the questions, I’m sure we’d all like to know a bit more about our guest. Bill, can you please introduce yourself? Tell us a bit about your backstory with WordPress and what you’re up to these days.
Bill Erickson:
Yeah. I’m a WordPress developer. I’ve been a freelance WordPress developer for about 15 years now. So I’ve been building sites on WordPress since before there was a page as a post types, everything was posts. As recently, have started this year, I launched my new agency, Cultivate WP, which focuses on helping web publishers.
Keith Devon:
Very cool. Very cool. We know you, Bill, through your website. We’d never met personally, but Mark and I frequently reference your blog, which is a great resource for Gutenberg development and WordPress development in general. So we really recommend people check it out. The very first episode we did, actually, of WP Café was about developing themes with Gutenberg, trying to get to the bottom of some of the challenges. So this is a bit of a follow-on episode from that. It’s just great to have you on the show, having referenced your material for so long-
Bill Erickson:
That’s great to hear.
Keith Devon:
Be able to get a chance to pick your brain. So thank you very much for joining us, and for joining us so early in the morning. What time is it with you at the moment?
Bill Erickson:
It’s 7:00 AM now, so it’s not too early. But the kids are still heading out the door to get to school right now.
Keith Devon:
Yeah. We had John James Jacoby on one episode. He literally see the sun light rising behind him. He was up at like 6:00 in the morning or something. That was quite funny. All right, let’s-
Mark Wilkinson:
That was with Elliot, wasn’t it with? He was in Australia. So we have spanned across the globe, won’t we?
Keith Devon:
Yeah. That was amazing. All right. We should get into some questions then, get this conversation rolling. Mark, do you want to kick us off?
Mark Wilkinson:
Absolutely. Yeah. I guess one of the first things that you think about with block-based development is the design process. That’s usually the starting point for a web build, and therefore, I just wondered if you have any comments. How does block-based development build in blocks on pages rather than the old way of doing it? How does that affect the design workflow that you take when you’re building a website?
Bill Erickson:
Yeah. When we started using the block editor, I think it was, I don’t know, what, two years or now? We started using it two or three months before it got merged into WordPress core. And so, we were trying to figure out how to make sure that our design and dev process would work well for that. We realized me, and I got together with my designers, we realized this really lends itself well to an atomic design approach, which our designers were using already. So we just had to guide their atomic design approach to start with core blocks and then make more complex elements that then use those core blocks.
Bill Erickson:
And so, it was just a little bit of education on the building blocks in Gutenberg, and then it just naturally flowed. It went really well with their design process and it also led me to no longer take on projects where our team didn’t do the design and dev. Like I said, I’ve been doing this for like 15 years. For the first 10, or 12, or 13 of those years, for the most part, I was just a dev. And so, people would bring me a design and then I’d build it.
Bill Erickson:
But with Gutenberg, it’s really difficult to make a successful website if the design was not built in a way that considered the editing experience. And so, I couldn’t really deliver what I consider a successful project, unless I can have my hands on that design process. And so, once we moved to everything being in the block editor, we also moved to, “We have to do the design process to make sure that those considerations are in place.”
Bill Erickson:
But then, once it’s designed with that thought in mind, it really empowers the client to really manage the site the way they want. So not just single posts and single pages, but they’re really rich pages like their home pages and stuff. They can click edit and see a copy of their homepage that looks exactly like the front end and really interact with it, add new elements where they want, and make it their own.
Bill Erickson:
When it was designed and built to line up with the editor, it gives a really great experience. But then if it was designed slightly differently in that more page template approach where every page is a little bit different, it just makes things way more complicated.
Mark Wilkinson:
Okay, cool. Do you build the backend editor to be as much as you can to be the same as the way it looks on the front end? Are you taking that approach where both have to be the same?
Bill Erickson:
Yeah, yeah. For the most part, we try and get it almost pixel perfect. So we even want like all the content columns to be exactly the same so that as they’re typing, they could see where the word breaks and stuff like that. Which introduces some interesting things because we also use the block editor in lots of different contexts. If the site has sidebars, we’ll use the block editor for the sidebar, because if we’re building all these blocks like call to action and email signup, we want those same blocks to be in the sidebar as well.
Bill Erickson:
So then we have to add some admin body classes to give information on the context, so then we can say, “Okay, on the sidebar posts, make the block editor content area 300 pixels wide.” So that it actually works as expected.
Mark Wilkinson:
No, that’s good. They’ve got that-
Keith Devon:
That’s cool, because we’ve taken that approach too. Do you create a custom post type for sidebars essentially on that-
Bill Erickson:
In more general, we create one call block areas. And so, we’ll use that for like sidebar after posts, after archive, or whatever, any of the places before footer, any of the more global areas where we want them to be able to insert blocks and it’s not just the main page of content.
Keith Devon:
Yeah. And then, on a particular page, would the client choose a template to use that has certain of those block areas available to them? Is that the way it would work?
Bill Erickson:
Kind of, yeah. We usually have a layout selector, so do you want content sidebar or content or whatever. And so depending on that, the block area would appear. For the most part, we’re not letting them say whether they want the before footer areas. Those are built into the themes. This is a global element. The sidebar is a global element if there is a sidebar present on the current page.
Keith Devon:
Yeah. Cool.
Mark Wilkinson:
Cool.
Keith Devon:
Just coming back to design quickly, I’m interested because I definitely agree that taking a Gutenberg first approach to design is beneficial from a timescale and cost point of view. Is that the primary reason or were there data structure reasons why you take that approach, or content management reasons or performance reasons or just technical considerations as well?
Bill Erickson:
Yeah. It’s all of the above. So yes, it makes things simpler when you’re already building from what’s there. But it also makes it simpler for the client to manage. Really, at the end of the day, I’m building on a CMS so that my clients can edit their content. And so, if I’m able to use as much as what’s there, then it’ll just naturally flow, because they already have content that has headings and paragraphs and blockquotes.
Bill Erickson:
And so, we want to make sure we’re making sure our stuff flows into what’s there and they don’t have to rebuild stuff. So the more you can leverage what’s there, the easier the transition will be, and faster development because it’s less custom stuff. Then also just overall performance improvement. It’s funny that you bring that up. The two biggest priorities to most of our clients are performance and accessibility.
Bill Erickson:
As I’m sure you’re aware, there’s huge emphasis on Google’s core web vitals. Pretty much every prospect that comes to us brings that up in the initial call. And so, we’re building towards those targets. So we’re running lighthouse and PageSpeed Insights as we’re building stuff. By being able to build everything in Gutenberg and with our own custom blocks, we’re able to see huge performance improvements versus page builders or the other larger block plugins.
Keith Devon:
Yeah, actually. Okay. Just… Sorry, Mark.
Mark Wilkinson:
Sorry, Keith-
Keith Devon:
I was just going to ask one more design question-
Mark Wilkinson:
I was going to say, has there ever been a time where you’ve designed or you want to design something that you think, “Oh, that will be really difficult to build in the block editor,” because we’ve had that a few times, although granted, we don’t tend to do our own designs as much as you, obviously, because you’ve taken that solely on yourself. We sometimes get designs given to us and like 95% of it, you think, “That’s fine. We can do that.” And then there’s just this little bit that you can’t get your head around as to how you can do it in the block editor.
Mark Wilkinson:
I just wonder if you’ve come across that and how do you broach that with clients? Do you just say, “Well, we just need to scrap that and do it a different way,” or-
Bill Erickson:
Well, that’s one of the reasons why we do the design on our side so that before the client sees the design, our dev team, so me and the other developers involved, we review the design and make sure that we’re guiding it in a direction that works. So yeah, clients will request things that don’t really apply well, or it could be hard to build. We’ll try internally to get them as close to what would make sense for us to build.
Bill Erickson:
But then if it gets really complicated, we’re like, “Hey, this is going to cost extra to build. This is going to slow down the site,” or whatever. We give them the constraints and then let them make that decision. When we’re doing our projects, pricing, we use ranges. And so, it’s a fixed bid for the discovery phase, but then a range for design and development. And so that gives us a little bit of flexibility, so as we’re designing things, it’s like, “Hey, we could go with this approach. It’s going to increase the dev costs by 2,000, or we could go with a simpler one.” It gives us a little bit more flexibility in guiding that process.
Keith Devon:
That’s great.
Mark Wilkinson:
That’s good. Go on, Keith. You were going to ask something.
Keith Devon:
I can’t remember what I was going to ask. The moment’s gone. That’s fine.
Mark Wilkinson:
It was obviously not very important. Lastly on design then, I guess this means that your designers really need to know Gutenberg. They need to understand how it works to be able to design to those constraints, if you like. Would you say that’s true or can anyone design it?
Bill Erickson:
Yeah, for the most part. I mean, I think there’s a basic level of knowledge, like knowing what blocks are available, knowing how things are inserted, that that’s necessary. We also have a lot of institutional knowledge about how we use different blocks. One of the things that we do is we try and make our custom blocks as small and modular as possible. I try to avoid big, full width sections as custom blocks. What I want is all of our full width sections to be full width groups.
Bill Erickson:
So then you can have the core backgrounds and stuff and then just use custom blocks for whatever little thing, like maybe an icon block, so that they can insert an icon here. But then they can still use the heading and paragraph and then a button block. So we try and use as much native stuff as possible. We also use the alignment options. We map that to the design grid. In the editor, when you select… We have two separate grid width. This is a little bit in the weeds. But there’s typically two different grid widths.
Bill Erickson:
There’s the full site grid, which is 1,168 or whatever. And then there’s the content area, which is like 736 or something. And so, when you’re inserting blocks, if you use the wide alignment, it makes it 1,168 regardless of the layout. So if you’re in a narrow content, you can bust out of that with the wide. Or if you’re on a full width content that’s using that full width grid, you can insert something with a center alignment and then not use the narrow or 736 grid.
Bill Erickson:
So by tying these core WordPress alignments back into design, giving the designers the tools to say, “Okay, content needs to be this wide, big elements need to be this wide, full with elements go 100% of the screen,” we give them these few constraints and they’re able to create what they need. I found that the most effective way of helping my designers understand Gutenberg was redesigning their site in Gutenberg.
Bill Erickson:
So they design their site and we built it in Gutenberg, and then they got in there and had to edit their content and realize where their design fell down. They’re like, “Oh wow, this is more difficult than I thought,” or, “Wow, now that I see how this stuff works…” And so, I mean, it does help to get your hands dirty in there. I find your own personal site is the best way to experience that.
Mark Wilkinson:
Good idea. Yeah. And then they’re also using [inaudible 00:14:02] as well to understand how it works and how it… Yeah.
Bill Erickson:
They’re using it and they’re getting to know how all this stuff works. And then they get to see, as WordPress changes, how the editor is improving or changing.
Mark Wilkinson:
Yeah. Interesting. Okay, cool. I think that covers designing a bit. Let’s move on to the types of blocks and things. I guess the first one is, obviously, WordPress provides loads of default blocks.
Bill Erickson:
Yeah.
Mark Wilkinson:
We just wondered how you handle all of those blocks. Do you allow the client to use all those blocks? Do you disable some blocks? Do you make sure that all of those are styled? Just wondered how you go about doing that with the default blocks?
Bill Erickson:
Yeah. We rarely disable blocks unless we’re going to create our own custom block that does it. For instance, I think there’s a search block. We remove that and then add our own one because our custom search block uses the searchform.php file that’s in the theme. So that the search form that we use anywhere looks the same as the one that’s in the block. So that’s the instance where we would remove it.
Bill Erickson:
Or if we’re creating a custom block that matches up with it. There’s the media and text block. And if we’re creating a content image block that’s the same, we’ll remove that so they don’t accidentally use it. But for the most part, we leave all the core blocks in there. We style the basic ones, like headings, paragraph, blockquotes, stuff like that. I just try to avoid using the more complex ones. I very rarely use the columns block just because it gives them a little bit too much design control in the editor.
Bill Erickson:
They can drag the column around and make custom sizes that then overrides everything that’s in the theme. And so, in those instances, usually we’d have a content image block where they specify a content and the image, and then the theme handles the columns and the responsiveness. So for the more advance stuff, those are usually handled through custom stuff. But the core blocks are still there.
Keith Devon:
That’s really interesting what you said like columns, because they’re such a challenge.
Bill Erickson:
And it changes. I feel like for a while, we were using the columns block, and it had some CSS that could override it. And then a new version of Gutenberg comes out and all my CSS doesn’t work anymore.
Keith Devon:
Yeah. Yeah. They’re super fiddly. I think I said this before, I tried a while ago to rewrite the column CSS so that it snapped to grids and things like that. But it’s just, yeah, it’s really fiddly. I find them really actually hard to use as a user as well, like dragging things into the right column and just… Yeah, and styling them on the back end to make them look like the front end. Everything about columns seems to be difficult.
Bill Erickson:
Yeah.
Keith Devon:
But interesting that you felt like you could get rid of them. Because I feel like they’re usually a really essential part of what we do. But I might actually look back at some of the sites we’ve built and some of the designs we’ve worked with to see if maybe there was a different way that we could have handled it, because I just use columns just because they’re there, and you see it as only thing, “Well, yeah, columns will fix that.” But actually, they are a pain.
Bill Erickson:
A few things there. Because most of our clients are publishers and most of them have like 80 to 90% mobile traffic, we have a very mobile first design approach. Like some of our clients don’t even look at the desktop mock-ups to their site, because they know only mobile is what’s going to be seen. And so, columns is less important. That’s why we’ll have narrower content areas, but then everything’s just single column.
Bill Erickson:
Also, the times when we do have multiple columns, it’s usually richer content experiences where it’s like content on one side and then some form of media, like an image or a gallery or something over there. And so, in those cases, we’ll use ACF, let them manage the media through ACF, and then have the inner blocks for the actual content. So there’s only really one column of actual content that needs the block editor. And so we can use the inner blocks for that.
Keith Devon:
That’s great.
Mark Wilkinson:
Cool. Yep. Interesting. Yeah, because columns I know was a big headache for Keith. He had lots of sleepless nights, columns and getting them to work. So maybe that’s something we could revisit as well.
Keith Devon:
I wonder as well, just, Bill, you’re mentioning ACF and inner blocks there. I wonder how difficult it would be to roll our own fairly limited column block where you just choose two columns, three columns-
Bill Erickson:
The problem there is WordPress core only supports one inner blocks in a block. And so, if you have two columns, you can’t have two inner blocks. Yeah.
Keith Devon:
Okay. [crosstalk 00:18:27]. Damn it.
Mark Wilkinson:
We’ve got quite a few questions in the chat, and a lot of them are about this next section, which is looking at third-party blocks and how you actually create your own blocks. We’ll deal with the big one first, I guess, is how do you create your own blocks? You’ve mentioned that design sometimes require custom blocks. You can’t deliver this with what we’ve got with WordPress. So how do you actually build those custom blocks currently?
Bill Erickson:
We use ACF for everything. For a while, I was exploring different tools like carbon fields and whatever the plugin was that now is Genesis Custom Blocks. So there’s a lot of block-building tools on the market. I feel ACF just has a much deeper, richer… I mean, because it’s been around forever. It has a much fuller feature set. It’s also really extensible as a developer. They have tons of hooks and filters. So it really lets us customize it the way we want, because a lot of times it’s not just building the block, it’s also determining how the data… Like what options are available in there.
Bill Erickson:
You have a block where they can select icon and the title. Well, you want that list of icons to be pulling from the SVGs that are in the theme. And so, having ACF where you can filter all that stuff and pre-populate, it works really well. So yeah, all our custom blocks we build with ACF. Recently, like I mentioned, most of our clients are publishers. We find that we build the same set of blocks across many sites. So we’ll have a post listing block, a term listing block, table of contents block.
Bill Erickson:
Now we’ve packaged all of that into our own premium plugin, which isn’t for sale anywhere. It’s just a way for us to deliver that to clients. And then, so as we make improvements to it, we can push those out to everyone rather than having to go update all the sites. So we used ACF in there, but a lot of our core blocks, we build into a plugin and then site-specific ones, we build into the theme.
Mark Wilkinson:
That’s interesting. So that means you can push updates to everyone, doesn’t it, if you make changes and improvements to things. Everyone can get them, which is good. You’ve never built blocks using React and the native [crosstalk 00:20:40]-
Bill Erickson:
I mean, I tried. Early on, like when I was first getting started with Gutenberg, before Gutenberg was merged into core, I took Zac Gordon’s course and then I built a few custom blocks, and then everything changed. Then I started taking the course again and it was just… I’m not a JavaScript developer, I’m not a React developer. I think a good analogy is meta boxes here. If you’re building a plugin that’s for public consumption, that’s going to be distributed, it makes sense to build things natively with React and remove any dependencies.
Bill Erickson:
But when you’re building one-off things for a client, something that takes five minutes with ACF could take five or 10 hours if you’re building natively with React. And so, we don’t build our custom site options or meta boxes or stuff like that for a client site hard-coded. We also don’t build our own blocks from scratch.
Mark Wilkinson:
Yeah. I think we’re the same and I think many people are the same. I will come to you in a minute, Keith. I just wanted to mention the people in the chat who have asked that question. I think that was Ben, and is it Joe I think I mentioned that as well, asking about ACF. So it looks like ACF is where to go. We use ACF as well. It’s nice and simple, just for the reasons you’ve suggested. Keith, you want to come in.
Keith Devon:
Yeah. I was just going to ask, on the ACF point, you mentioned earlier about trying to make the backend experience as close to the front end as possible, like pixel perfect if possible. How do you get that to work with ACF? I mean, is it using like a preview mode or something, switching between a preview, or do you have the meta boxes in the sidebar? How do you set up your ACF custom blocks?
Bill Erickson:
It depends on what type of interaction the client needs. I started default to preview mode both so that the editor looks correct, but also because we use inner blocks a lot for our custom blocks and that requires preview mode. And so, then like let’s say the content image block, so it’s in preview mode, they click it. They can type the content here. And then in the sidebar they can add the image and then it updates the image that’s in the preview area.
Bill Erickson:
If we’re doing something more complex like using the repeater field or something like that, maybe a tabbed content area or something, then we’ll use the auto mode so that when they select it, it switches to the ACF meta box view. But then the way unselected, it renders as it should be.
Keith Devon:
That’s really cool. Have we used that yet, Mark? I don’t think we have.
Mark Wilkinson:
Possibly. I can’t remember. Yeah, I can’t remember. I can’t remember.
Keith Devon:
That sounds [crosstalk 00:23:15].
Mark Wilkinson:
I think I like the fact that you can do stuff on the right hand side for the simple blocks. And then, but like you said, when you’re doing a repeater or something more complex, it’s just not big enough of an area, is it, to actually get all the stuff in and you need to put it in the main bit. And then, like you said, the previous was good or the auto mode that works really well, which is cool.
Mark Wilkinson:
Quickly then, my questions, we’ve covered in the blocks. That’s good. So next thing is about styling those blocks then. Obviously, Gutenberg provides styles for its core blocks. So I just wondered, do you use that, do you build on top of that, or do you just wipe that from scratch and style them all yourself per project? Or do you have some core styles that you use yourself? Just wondered how you approached that problem.
Bill Erickson:
Yeah. I try and minimize the amount of undoing of Gutenberg stuff as possible, just because I don’t want to fight that uphill battle. But there are times when Gutenberg is weird where it applies something to the back end but not the front end. I think Blockquotes sometimes has a border on the left to the editor, but not on the front end. And so, what we do is we start… SaaS makes this very easy.
Bill Erickson:
We have our styles broken down into different files. And so all of our block styles go into like both the front end, but then also an editor style sheet. And so, that takes care of like 99% of things, just making sure that whatever styles you’ve got on the front end also apply in the backend. I have a Gutenberg partial for any Gutenberg-specific overrides. So like I said, the Blockquote, when that gets messed up or…
Bill Erickson:
Another thing that I find really useful is for the more advanced ACF style blocks, let’s say my post listing where it’s going to output a list of four posts or whatever, I don’t want the client accidentally clicking on one of the posts and then going to that post from the editor. So for any of the blocks that have links like that, inside the Gutenberg editor, I set it position relative and then set of pseudo element that’s like Z index 99 that covers the whole thing, so that they can’t accidentally click. They can click to select it and then manage the options, but they don’t go to that post.
Mark Wilkinson:
That is a good. I’ve had that problem where you’ve got like a video of something and to select the block, they have to play the video. “No, we don’t want them to do that.” That’s a really good idea. That’s a really good idea.
Keith Devon:
Yeah. That is a good idea. That’s really clever. Yeah.
Mark Wilkinson:
Yeah, clever one. And then-
Keith Devon:
So you do just-
Mark Wilkinson:
Go ahead, Keith.
Keith Devon:
You do enqueue the Gutenberg style sheet as it is.
Bill Erickson:
Yeah.
Keith Devon:
And then, yeah, you make any changes that you need to.
Bill Erickson:
Yeah. Yeah. We leave the block styles enqueued as is and make our changes to it. It doesn’t matter so much for the simpler blocks, but for the more complex ones, if they do insert columns, they want that to work. And so, I found it, for a while, I was dequeueing all the block styles and trying to handle it all myself. But Gutenberg changes too much, both with its core styles, but then also adding new blocks that I didn’t consider when I designed the site.
Bill Erickson:
And so, to future-proof it, to make sure whatever they answered in the editor works, you really just have to include the block styles and then add some overrides where it makes sense.
Keith Devon:
Yeah, that’s cool, I think. I tried dequeueing the Gutenberg styles and ruined my own, but I’ve regretted that decision. So I think we’re going to go back to an approach very similar to yours where we, yeah, accept as much of it as possible and then just make the overrides. I think that’s a less painful approach going forward for sure.
Mark Wilkinson:
Yeah. On the front end then, using SaaS, do you just compile those into one CSS file and then load that, or do you go an approach whereby I’m only going to load the Blockquote CSS if there’s a Blockquote block on the page?
Bill Erickson:
For the most part, we just use it as a single a style sheet. In some contexts where there’s a really complex style thing, or if it relates to JavaScript… So let’s say we have a slider block, it’s only used one place in the site, but it has a ton of CSS and JavaScript associated. Then we’ll only enqueue that when that block exists on the page. But for the most part, all of our styles are enqueued into the main CSS file.
Bill Erickson:
There’s also some tools that you can use for CSS tree shaking. Like if you’re building an AMP site, it’ll automatically reduce the CSS. It’ll make a per-page CSS file that only includes the styles on that page. And so, you’ll see like 75% reduction in your styles. But then you have all the other negatives of AMP. There are some plug-ins on the market coming out, that I’ve beta tested, that do a similar thing, but for non AMP sites.
Bill Erickson:
I played with that a bit, but I’ve found that because of our very atomic design approach, there is few styles that make sense to be totally pulled out because everything is built from the same little building blocks, and they aren’t applied to all the major pages.
Mark Wilkinson:
Yep. That was interesting. We’ve dabbled with the idea of just loading the CSS for specific box as and when that’s used. We’ve never tried it, but in theory it seems to be a good idea. But like you said, you’ve just mentioned some problems with it, which is interesting.
Bill Erickson:
Yeah. I’ve found that in actual real-world testing with PageSpeed Insights and Lightspeed, even though having lots of little style sheets are supposed to be better, it actually makes things slower. And so, having it all in one style sheet… Also, I found that the critical CSS that WP Rocket generates, if you already have very lean CSS, that actually doesn’t have any performance benefit and introduces CLS issues because some things might not load that they weren’t aware of.
Bill Erickson:
And so, for the sites that we build that are really lean, and the style sheets are only a few kilobytes anyway, we just load that in the header and then we have zero CLS issues and we’re only loading one file rather than lots of smaller assets.
Mark Wilkinson:
Interesting. Good advice to try that. Where are we up to? Let’s have a look. Oh yeah. Block patterns, and styles, and variations, and things like that. This is something we’ve played with a little bit. I just wondered if you’ve used them, if you found a use for them, and how’s that gone, really.
Bill Erickson:
Yeah. block styles, we use quite a bit. That’s one of the areas where we remove a lot of stuff that Gutenberg adds. So we’ll remove all of the button block styles. There’s a few other ones where we remove all the salesmen, add our own. So we use that a lot to give the client the ability to change things up.
Mark Wilkinson:
Is that done in JavaScript or is that done in PHP?
Bill Erickson:
Yeah, that’s done in JavaScript.
Mark Wilkinson:
In JavaScript. Right.
Bill Erickson:
I have an editor.js file where it’s just unregistered block style, “Here’s all this stuff,” or unregistered block type, “Here’s the stuff for that.” So that is a JavaScript-based thing. But it’s pretty simple once you have the code. You can just copy paste. And then when it comes to block patterns, I haven’t used it too much with clients. I find that the UI for finding block patterns isn’t as easy as they would hope. Most of our clients can’t find it.
Bill Erickson:
But when we recently built my agency website, because everything is just a page, like even our case studies are just normal pages, I created a block pattern for how our case studies should be. So my designer could click that, it would pre-populate it with all the blocks and then they could fill it in. So we’ve used it internally a bit. We might use it a bit more on some clients, if they have repeatable landing page style things where they need all of these blocks in a certain order.
Mark Wilkinson:
Yeah. We were thinking landing page for specific layouts might be good just to drop the layout in the page enough, you go and create the bits and bubbles you need.
Bill Erickson:
Yeah, no. It [crosstalk 00:31:06] a lot of value. I found that a lot of our clients, they will just duplicate a page that they like when they want that kind of layout. That UI seems simpler to them than the block patterns. So we might start pushing block patterns a little more. Also, the fact that everything has to be code-based makes it a little difficult.
Bill Erickson:
But there’s a plugin that I used recently where it exposes the UI where you can take a reusable block and then save it as a pattern and then it becomes accessible. And so, that’s something that I’ve installed at a client site where they said, “How can I reuse this sort of section?”
Mark Wilkinson:
Interesting. [inaudible 00:31:43]. Yeah, that sounds good.
Keith Devon:
Obviously, there’s block styles, which we’ve used quite a lot. But there’s block variations as well, which we’ve used less. Do you use variations? And if so, how do you decide if something is a style or a variation?
Mark Wilkinson:
Can someone remind me of what the difference is?
Bill Erickson:
Yeah. I haven’t used variations. I’m not sure what the difference is.
Keith Devon:
Okay, cool. Wow. It’s all on me to try to explain something I know very little about. I think whenever you build a columns block, whenever you add a columns block to a page, for example, I know we’re saying maybe we won’t ever use columns again, but if we did, we add a columns block to a page and it says, “Do you want it to be three columns or two columns or a third, two-thirds?” Those are variations, and there is a variations API.
Keith Devon:
For me, it’s very similar to styles, but I just don’t know the difference. The variations, they’re exposed in different ways. They’re exposed like that whenever you first create a block or there’s another UI. I can’t remember exactly what it is. We did use this, Mark. I can’t remember what for, when I discovered it. I remember I tweeted it, started a bit of an argument on Twitter because I unintentionally, but I basically said, “Where’s the documentation for this, because it looks awesome.” And everyone’s like, “There isn’t a documentation. Write it yourself.” I was like, “I don’t know how to use it. I can’t write it myself.”
Bill Erickson:
Yeah, no, I haven’t used it. I mean, I just googled it real quick. It does look very similar to block styles, but it’s just a different way, and it exposes it differently. Yeah, I haven’t played with it. I mean, my one complaint about block styles is the inability to use two block styles at the same time.
Keith Devon:
Exactly.
Bill Erickson:
And so, maybe this might help with that.
Keith Devon:
That this-
Bill Erickson:
And so, you can have like a style and a variation and then they can combine. But yeah, I haven’t had a chance to play with that.
Keith Devon:
Yeah. That’s what I was going to get up because… Actually, it came up yesterday, I think. I was building a list, so I was using a list block, and I’ve created a list block style for stars for the bullet points. But the client wanted to make the list a larger font size. And because it’s not a paragraph and lists don’t have font size control, you couldn’t do it. So I was wondering, maybe I could use a variation as well as the style and work with it with… I don’t know.
Keith Devon:
But yeah, it’s interesting because I don’t know what is supposed to be a variation and what’s supposed to be a style. Style’s intuitive, but then what’s a variation? So yeah, something to look at, I guess. There’s your next blog post, Bill.
Bill Erickson:
Yeah. I need to add that to my Gutenberg stuff. But yeah, oftentimes when I need… Because it’s like block styles are literally just a CSS class. If I need two block styles, I just add the extra CSS class in advanced. It’s not very client-friendly, but it’s like if you want it large and stars, just type is style large down in the class and it’ll also be large in stars.
Keith Devon:
Yeah. Yeah. And you could just create more and more styles with combinations, couldn’t you, be like if we got [crosstalk 00:34:54]-
Bill Erickson:
Yeah, like large stars. Yeah.
Keith Devon:
Yeah. Yeah, yeah.
Mark Wilkinson:
It sounds to me as though variations might be good if you’ve got… But you need to make a decision before we show the next lot of options almost. I don’t know, like a layout and then you get a different set of fields if you’ve chosen this variation rather than… That sort of thing. I don’t know. Maybe that was not… But that’s not what columns is, I guess, because you’ve still got the same UI, don’t you? But-
Keith Devon:
I can’t think where else it’s used except for columns, but yeah. That’s an interesting [crosstalk 00:35:23]-
Mark Wilkinson:
Is it in the embed one where you choose which one to use maybe? I don’t know. I don’t know. I know you can just paste the URL. So I’d rather use the embed block as in at the block and then page. I don’t know.
Keith Devon:
Yeah. I’m not sure.
Mark Wilkinson:
You could [inaudible 00:35:34]. I’m not sure. I’m not sure.
Keith Devon:
Cool. Something to [crosstalk 00:35:37]-
Mark Wilkinson:
Research to do though, I think. Yeah, definitely.
Keith Devon:
All right. Where are we up to with the questions.
Mark Wilkinson:
We’ve covered the next one, which is custom style in the editor. Obviously we match in the editor as much as we can on the front end. We tried to do that with some good success, but some things just don’t quite work. I think some things you mentioned, like covering up those clickable areas that you don’t want people to click is really good little tip, actually. So, that’d be good. Have a look at that. And so, what opportunities do you think Gutenberg has given theme developers that they didn’t have perhaps before the block editor was out and about?
Bill Erickson:
I mean, by making the default editor more powerful, it lets us move away from the page template paradigm where it’s like we have a pricing page and a team page and all of these pages that have their own unique design with all that functionality. Now we can separate that and just create them as individual blocks, which then makes those elements reusable elsewhere. We’ve found by moving beyond the page design model to the more atomic approach. It really just empowers our clients to build richer content later on because like, “I want the pricing table, but I want it on my landing page.”
Bill Erickson:
And so, it’s like, “Well, you can’t do that because it’s tied to that page.” Well, now the block can be used anywhere. And so, any block we used on the homepage, they can then use inside of posts and stuff.
Mark Wilkinson:
Yeah. Makes sense, doesn’t it, that way? I guess that brings us on to some of the challenges then that the block editor gives, because, obviously, like you say, it’s allowed the developers to really branch out and put everything everywhere. Does that bring any challenges in terms of styling and things like that, that everything’s got to work with everything? I just wondered if you’d come across any of that.
Mark Wilkinson:
I know we’ve had some issues with like space in issues when you’ve got backgrounds on things and not on other things. And I just wondered if you’ve come up across any and any solutions you might have.
Bill Erickson:
Yeah. I mean, it definitely introduces a lot of challenges beyond what a normal WordPress editor… Because you have all the baggage of this richer editing experience that you need to make sure keeps working. And so, I think that’s just one of the areas where as you build stuff, this is where maintaining your own starter theme makes a lot of sense. So as you figure out problems, you can then bring it there and then it’s solved, specifically around like backgrounds and stuff.
Bill Erickson:
We used to group block heavily and then anytime the group block has the has-background class, we add top and bottom padding to that section. And then anytime you have two full width blocks, like group blocks that have has-background, the second one has negative margin so that they’re touching. So it’s like global styles that we use across all our projects.
Bill Erickson:
Let’s say you have an alternating white and gray section, we don’t need a white background. But you want the padding in that section to match the one that has that. So then we add it to a group, set the background color to white, and then that gets the padding they need while the visual structure. So it’s little tricks like that, that you learn. When I’m registering the theme, the Gutenberg color palette, make sure you include white so that they can duplicate the padding when they’re doing alternating sections.
Keith Devon:
That’s clever. Yeah. That’s really good idea.
Mark Wilkinson:
It’s not quite intuitive, obviously, for a client to say, “I want a white background,” because obviously they think they’ve got a white background, presuming that the background of the site obviously is white. Let’s just say it’s a little different to that, but anyway. Is there anything-
Bill Erickson:
Yeah. No. [crosstalk 00:39:03] a bit of a learning curve. I mean, before Gutenberg, when I delivered sites, I’d send it to him for review. I have a bullet list of like, “Here’s the different things you should check out.” Gutenberg is such a visual editor and a lot of the interface is fairly hidden unless you know where to look at it, that we shifted to 100% video-based training. Like when we deliver a site to a client, there’s usually a dozen or 20 videos walking them through different aspects.
Bill Erickson:
Both of all are our custom blocks, but then also the way we use the Gutenberg block header. We have a whole video on groups and how to use them for backgrounds and for paddings and stuff and alignments and page layouts. Gutenberg is a blank canvas where you can take it in the direction you want. And so, we want to educate them on how our design decisions were affected by the editor.
Bill Erickson:
And so, we use the alignment options different than another developer might. So we want to make sure you’re aware of how we use that.
Mark Wilkinson:
Is that a suite of videos that is essentially the same for all your clients, but with custom ones for the custom blocks, or do you just do those fresh for every client?
Bill Erickson:
I do them fresh for every client. I have a list of the common videos that I do. And so, I just run through that list. But yeah, I do a custom one because it’s all in the editor and the editor looks like their site. And so, it wouldn’t make much sense to have a video that was for someone else’s site. Yeah, I have to record fresh videos every time.
Mark Wilkinson:
Cool. Keith?
Keith Devon:
Yeah, just tell me if you’ve already covered this. But you mentioned about obviously having standard styles that you used for group blocks and things to cover these common spacing issues and things like that.
Mark Wilkinson:
Yeah.
Keith Devon:
Do you have a starter theme? I think you mentioned a starter theme. Do you have your own custom starter theme?
Bill Erickson:
Yeah. I have a few starter themes online. None of them are really up to date. I have a private starter theme that I use on our projects. We might be making that public. The starter theme’s called Cultivate. I was keeping it private until we launched the agency. It also has a lot of very specific stuff for us built in. So it might not make as much sense for someone who’s not building a bunch of food blogs, because it has a bunch of stuff for like WP Recipe Maker and things like that.
Keith Devon:
Sure.
Bill Erickson:
So it’s very specific to our needs. But yeah, I might be able to, at some point, make that available. But the starter themes, I have EA starter and EA Genesis Child are the two public starter themes. For the most part, they have all of the same core Gutenberg’s stuff in it, so like the editor styles and things like that.
Keith Devon:
Do you use that as a parent theme or a starter theme? As in, do just build on top of that or do you create a child theme for your-
Bill Erickson:
Yeah, I use it as a starter theme. First thing is we rename it to the client name and start modifying it from there.
Keith Devon:
Yeah. The challenge, I think, we’ve tried to do that in the past and the challenge has always been just to make sure that you keep updating that starter theme, because obviously you start with something and it’s great because you’ve built in, it’s all nice, and lean, and useful, and modern. And then you build a client site on it and then you make a bunch of changes. Those are things that you think-
Bill Erickson:
It’s that step to [crosstalk 00:42:28] that. Yeah.
Keith Devon:
Yeah. Are you good at that or is that something you struggle with as well? I’d find that really interesting, like how do you keep it up to date? Because we’ve struggled with that.
Bill Erickson:
Yeah. I lean towards keeping stuff out of the starter theme because I want to keep it lean and I don’t want to have to remove a bunch of stuff as I’m building it for clients. But then all of our projects are version controlled and in GitHub and stuff. And so, when I find myself going back and referencing things from older projects, so I’m like, “What was that unregistered block type thing that I was using?” I search GitHub, it shows me the projects.
Bill Erickson:
And then if I find myself pulling something from previous projects multiple times, then I move it to the starter theme. So yeah, I don’t have… Or as I’m building something, I notice like, “Oh, Gutenberg update. Now our group [inaudible 00:43:14] are broken. I better fix that.” So if I’m recognizing the moment that it’s going to affect everything, I’ll make the update there. But usually it’s after the fact I find myself copying and pasting this all the time, “I might as well put it in there now.”
Keith Devon:
Do you find that like because you’ve specialized a bit now with your new agency… I don’t know how long you’ve been on that niching route, but do you find that it helps to have a niche whenever it comes to having a collection of tools that are useful and easier to keep up to date because you’re using them more often? Is that a benefit?
Bill Erickson:
Yeah, definitely. It’s funny. I’ve been in this niche for about two-ish years now. Basically, it’s a really small community. We built one really large food blog and then five of her friends hired us. And so, we did six back to back. Then we became known in this space as the people that build really fast websites for those high-traffic sites. And so, I don’t market myself necessarily for that, and I’ve even stripped all the publisher related stuff from my site because I want Cultivate to be lead gen for publishers and then my site to be lead gen for everything else. But it’s still 80% of our work.
Bill Erickson:
But yeah. Being in a niche definitely helps because it allows us to… By solving the same problem over and over, we can dive deep and get a little bit more detailed into that. Again, like I said, I’ve been packaging the stuff that’s applicable to all these projects into a plugin, so that then I can loop back around and update everyone else. But even for the stuff that’s not like that, by working on the same niche over and over, our core theme has really become refined as opposed to completely different clients with completely different tool sets and trying to learn them in the moment.
Bill Erickson:
And then just that knowledge just goes away because it’s never going to be relevant again. Like some random MLS system for some realtor over there. And it’s like, “I’ll never need to know that again.”
Keith Devon:
Yep. Makes a lot of sense.
Mark Wilkinson:
Couple of questions from YouTube. Chris says, “Any chance you can share a sample of one of these client tutorial videos?” I’ll leave that with you. I think that’d be super useful actually to see what you do.
Bill Erickson:
Yeah. I could draw up some of those in… I’m not sure where’s the best place for me to add notes to this after the fact. Maybe a YouTube comment or something.
Mark Wilkinson:
Question. Yeah.
Keith Devon:
That’d be good, I think.
Mark Wilkinson:
Question. Yeah. Probably, a comment on YouTube would be the best place. That’d be great if you could obviously put… So there you go, Chris. He’ll put one of those in. X Sam says, “How would you create a Gutenberg block on a headless WP site? I wouldn’t know because I don’t use headless. But I don’t know-
Bill Erickson:
Yeah. I mean, I don’t do headless but, I mean, I don’t think it would be any different than it is now.
Mark Wilkinson:
[crosstalk 00:46:08].
Bill Erickson:
You would just register the block as usual and then you’d be using ACF to create the block in the editor. Then your headless thing is going to have to interpret that data and render it. I’ve never done that part of it. One thing that I would be wary about is all of the fields in ACF are just stored as comments. So that’s one of the reasons why we really lean towards using inner blocks as much as possible because then that’s actual content in there.
Bill Erickson:
So like if ACF gets disabled or the theme changes and they don’t have that block type registered anymore, all that content goes away if it was just you had a title, subtitle description field. But if it’s actual text, it’ll still appear in the markup there. For things like table of contents, that parse the markup. But if all that stuff is just custom fields in the block, that won’t be seen.
Bill Erickson:
So yeah, I haven’t done any headless stuff, so I’m not sure what the process is of converting the ACF markup into the actual rendered HTML. But it’s probably the same as it is for all the other blocks.
Mark Wilkinson:
Yeah. I guess, this function’s the parse and things. So yeah, but-
Bill Erickson:
Yeah, parse blocks or whatever, and rendered block.
Mark Wilkinson:
Yeah. We’ve not really had any experience with that, so hopefully that helps anyway, but there we go. Keith.
Keith Devon:
Yeah. There’s another question. Couple of questions, actually, from Mike Ellis. I’m going to add one to the screen now. First one he says, “What to do about richer data? We do a lot of quite detailed stuff with post meta right now.” This is actually something that Mark and I talk about a lot, is when do you create a custom post type and then reference that from within a block, rather than just adding that data directly to a block. Do you have a thought process that you go through, Bill, whenever you come up against things like that.
Keith Devon:
Just an example for people could be, there’s a Meet The Team page on a website, so you could create a post type called People and add everybody as a separate post in there. And then pull in that data using a block maybe, or you could just build that page up with blocks, either custom blocks or native blocks. Throughout a project, we find that there’s lots of those decisions to be made and I just wonder, Bill, how you go about making that kind of decision.
Bill Erickson:
Yeah. I’m actually looking, because I did that exact example, [inaudible 00:48:49] people to Meet The Team page. And so, rather than trying to build a custom post type and then using metadata for everything, we just used the normal block editor. And so, we have a block pattern for, what should a team member page look like? Use a page header block for the header area and then stuff like that.
Bill Erickson:
And so, this is where parse blocks and rendered blocks comes in really handy. I’m not sure if there’s anywhere I can paste code in here. But for our team listing, I’m literally querying all the sub pages of the team page. And then for each one of them, to get… The name is going to be the post title. But then the subtitle, what I’m doing is parsing the blocks, finding the page header block, and then pulling out the HTML of that, because I know that’s where I’m putting the title.
Bill Erickson:
And so, rather than having to store it all as metadata, as long as the block structure on the page is predictable, you can pull that out. We’ve done similar things on case studies or whatever. Like if you want to pull out the testimonials, you can just go through parse the blocks, find the blockquote. And if that exists, then you can render that blockquote. If that’s your only need, is to be able to pull out bits of data, I would lean towards using the block editor for everything and then parsing the blocks as needed.
Bill Erickson:
Now, if you need to actually query that data or display it differently like an events calendar or something, that makes sense to store it as a post type, so then you can sort it by event date and things. When they pass, they can move off of the list. So if actual queries are involved, then I would probably lean towards having them as metadata. That is one area that I wish… And I’ve requested it a few times and I’m hoping Elliot adds it, but one area that I wish ACF would improve, would be the ability to, as you’re creating a custom block, select certain fields and say, “Save this also as post meta.”
Bill Erickson:
So when I’m doing my team member and I have the team member subtitle or whatever, save this as post meta so then I can access that later and then I can query for everyone who’s developer or something. It would be really useful. It’s capable, like core blocks can do that. If you take Zac Gordon’s course, he shows you, how do you save block data as post meta? But it’s just not a capability in ACF at the moment that I’m aware of.
Mark Wilkinson:
Sounds good. Yeah. I think the example we use with people is with the recruitment sites. So often they want the Meet The Team page, but they also then want to have the different person attached to the certain job, so that you’ve got a query with the right person and then share all the information with the job. So I’ve tend to come for the post type approach for that.
Mark Wilkinson:
But it’s an interesting suggestion you made that about parsing the block content. That would probably work as well. But like I said, querying’s probably best to have a post type.
Bill Erickson:
Another thing that we’ve done is, I’ll create a site options page where we can select key types of data. So like select the Our Team page and you select that in the site options. Then when I need to query for people, I can go to the site option to get the ID of that page and then get the children. So that way you’re not dealing with hard-coded stuff, but you also don’t necessarily need a custom post type if it’s just all the sub pages of this section.
Mark Wilkinson:
Yep. Yep. Interesting. Any other questions, Keith, that you found? I think I’ve covered [crosstalk 00:52:12]-
Keith Devon:
There was another one from Mike, but we had covered it pretty much. It was about-
Mark Wilkinson:
Okay.
Keith Devon:
Yeah. That was just about using ACF flexible fields and things for landing pages. Haven’t pulled any other questions out yet.
Mark Wilkinson:
I think was all right.
Keith Devon:
I think we should wrap up soon, probably.
Mark Wilkinson:
Yeah. Yeah. Just the last point for me was, obviously on this debate of custom post types and pages, and I know you mentioned you just built a site where you’d use all pages. Was that own site, sorry, where you said you’d done that without using any custom post types?
Bill Erickson:
Yeah. Actually, I think our case study is as a custom post site, but the editor is still just the Gutenberg block editor, so there’s nothing unique to it. It’s just so that we have the archive.
Mark Wilkinson:
Okay. Right. Because I’ve often thought of that now with the block editor. Like you say, you’ve got where you can build pages of different blocks. Do we actually need custom post types anywhere? Can everything just be pages? Maybe the blog can be posts and we can do it that way. I’m not sure whether we’ve got these [crosstalk 00:53:07].
Bill Erickson:
I think post types still serve a role. Basically, anytime you need to have dynamic archives or query by certain things, it’s useful to have it that way. But yeah, definitely, I’d say five or six years ago, I was using custom post types a lot more heavily. We used pages for simple content. Any richer content like team members or whatever, we would use as a custom post type. But now with the block editor, since the core editor’s so much richer, we’ve gone the other way and rarely use post types, unless it really makes sense like events or case studies or something where you want that dynamic archive.
Mark Wilkinson:
Yeah. Yeah. Makes sense. Cool, good. Right. I think we’ll wrap it up there. I think that’s been really good discussion. We had lots, actually lots to go away with and have a practice at. So that was good.
Keith Devon:
Yeah. It’s been great, Bill. Thank you so much.
Mark Wilkinson:
Hopefully, everyone can [inaudible 00:53:56]. Thanks for that.
Bill Erickson:
Yeah, thanks for having me.
Mark Wilkinson:
Where can people find you on the web, and if they want to go and find out more about you, your services and stuff?
Bill Erickson:
Yeah. My personal site is billerickson.net. As you mentioned, I have a blog where I’ve written a lot of articles about Gutenberg and other stuff. Then my agency site is cultivatewp.com.
Mark Wilkinson:
Excellent. Cool. So definitely going to look at those. Certainly, the blog on billerickson.net is a superb resource for Gutenberg development. If you are doing that, you’ve probably already found it when you Google things. But I can’t recommend it enough. It’s certainly helped me out a lot when I’ve been doing some development. So yeah. Thanks again.
Mark Wilkinson:
Again, please do subscribe to the YouTube channel if you want to listen to more episodes of WP Café. We’ll have another one coming up next month. We’re not quite sure what the topic’s going to be yet. If you have any suggestions, then please do let us know of the things you’d like us to cover, because I’m sure we can try and get some experts in the area and we’ll see what we can do.
Mark Wilkinson:
Thanks once again to Bill, and those of you tuned on YouTube, thanks for your questions. That’s all for now. Thanks for joining us. We will see you next month.