Ben
Ben is a lifelong Nintendo fan who likes to build websites, and make video games. He buys way too much Lego.
WP Cafe – Developing Themes with Gutenberg
Last week I took part in the first WP Cafe with Keith and Mark from Highrise Digital. The subject was Gutenberg, the new WordPress editor, and talking about the work we have done with it.
Below is the video from the chat. Before the chat we were given the topics we’d be covering and we didn’t get to answer all the questions. So I’ve included my notes after the video.
What are your thoughts on the block editor? What do your clients think about it?
I don’t have clients, but personally I think it has a lot of potential. There’s a lot of good that could come from it, but it’s not quite there yet.
I’ve been quite vocal in the MasterWP newsletter that I am a fan of the concept but that I think it was released too early. I think it’s changing too much between releases which is confusing for users and hard work for developers, but when it’s finished I think it will open up a lot of opportunities.
What development work have you done with the block editor?
I have built a few simple blocks for my plugin WP Toolbelt. It’s a plugin that is a bit like Jetpack, but is a lot faster, and is built with a focus on privacy.
The blocks include a markdown block, a simple contact forms block, a gist block for embedding github gists, and a portfolio block for displaying posts from the portfolio post type that is one of the theme features.
I’ve also added full Gutenberg support to 20 premium themes. Which was a lot more effort than I’d expected.
What are the biggest challenges of developing themes with the block editor (Gutenberg)?
Recently the biggest challenge for me, as a premium theme developer, is supporting all possible combinations of content. I have no idea how users are going to use my themes, so I have to make sure the content works in every possible scenario. Nesting groups with different content widths is a particularly fun thing to work around.
Also, I feel that keeping up to date with the changes is almost impossible. The code is changing rapidly and trying to keep on top of changes, whilst maintaining backwards compatibility, is a real challenge.
Finally lack of documentation. There’s some docs, but they are often out of date, or only for specific scenarios – and in general they are quite thin. Because it’s changing so quickly we now have the problem that tutorials you find online are often out of date so working out how to do things can be a real challenge.
I follow the WP make blogs. There’s too many different places to follow and they provide weekly updates on the most significant changes.
If you are building custom blocks, how are you building them?
I’m coding them from scratch with JavaScript. My blocks are in plugins, and I don’t like to have other plugins as dependencies, but I can see the appeal of using something like Advanced Custom Fields. If I made client sites I’d definitely use something like that.
For most of my blocks I am using Gulp for the build process. I have used create-guten-block in one plugin but I found it to be quite heavy so I have tried to make my option lighter.
Have you managed to edit the core blocks? If so, how did that go? Are you removing core blocks?
I haven’t edited the behaviour of any core blocks but I’ve styled all of them multiple times.
I’m also not removing anything from core. I know some premium theme sellers do that but I think it’s a bad practice. The customers site is not mine to change. I can see that this would be different for client sites where there’s a defined scope, but for premium themes I don’t think it’s right.
Have you attempted to customise the block editing interface at all? For example styling the editor like the front-end.
Yes. That’s a large part of the work I’ve been doing with adding support to my themes.
It’s not easy. There’s a lot of nested selectors, and opinionated styles that need to be overridden.
There’s also a lot of bugs that I am finding. In the last couple of weeks I’ve reported two issues with Gutenberg and two with Jetpack.
I hope that Global Styles project will improve this.
The styles between the front and back end are not 1:1 but you can get pretty close, and it’s much better than not having any styles at all.
Personally I would quite like the editing interface to be on the front end so that when you hit save the toolbars hide and you’re on your website. But I can’t imagine that happening for quite a while (or ever?).
What opportunities does the block editor provide which you didn’t have before?
I like the fact you can preview things more easily. Shortcodes were never a nice experience. But I think the full site editing is going to be where the really interesting things happen.
I think that full site editing will reduce the need for themes. Each individual theme will be able to do a lot more, so there will be less need for different layouts. When you add in support for the upcoming global styles functionality I think premium themes will find life getting tougher and tougher.
How has Gutenberg changed pricing, timescales and process for delivering projects.
I don’t have clients so not sure I can answer here. For me my pricing hasn’t changed. I think there’s perhaps some changes to be made from a marketing point of view but otherwise it’s business as usual.
What is your one piece of advice you would give to anyone else developing themes with Gutenberg with regards to helping them stay on track in the future – 6 weeks, 6 months and a year down the line?
I’ve written about it on my blog but I think that themes as a commodity will become a lot less important. You need to keep an eye on the new things that are happening. Gutenberg is changing at a rapid pace so you definitely need to see what’s coming up. Full site editing and global styles will change things all over again.
