A Long-Time WordPress Developer’s First Move Into Block Themes

@bkmacdaddy • 3,000

Tip the AuthorCopy linkTweet this

Jun 02.2022

I’ve been building custom sites in WordPress for more than a decade. I had grown accustomed to the process I had refined over the the years, using a boilerplate theme framework that I had customized, tweaked, and somewhat mastered as the foundation of my process. In the past couple years, as the Gutenberg editor was introduced and continued evolving, I chose to bypass this “new” way of WordPress and promptly installed the Classic Editor plugin on every site I built, clinging desperately to my tried and true way of doing things. But as WordPress 6.0 and full site editing was looming on the horizon, I figured it might just be time for this old dog to cave and learn some new tricks.

This article is an attempt to document some things I went through as I worked on a new, relatively simple project building a child theme for Twenty Twenty-Two. This is not a tutorial, since I am still figuring out what I’m doing (and more importantly, the correct way to do it.) Instead, I just want to share my thoughts along the way of my journey into the unknown (to me) that is block themes.

Getting Started

I started with doing some research. This great article gave me a solid understanding of what I would be working with and how to set up a child theme for Twenty Twenty-Two, which I had determined would be the best place to start. There are definitely other starter themes you could use, but I figured this would be a good choice to dip my toes in the block theme water.

As I began setting up my local dev environment (I currently use Local to quickly spin up a new WP site to work on) it quickly became obvious how much of a whole new world this was going to be. What happened to page templates? What is this JSON file that is the heartbeat of block theming? HTML files are in here too?!? I was a bit overwhelmed, to say the least.

I consider myself a pretty quick learner, so although it was daunting, I was determined to figure this out. I’m also pretty stubborn and competitive (just ask my wife) so I was not going to be defeated. That said, I knew it was going to take some time to wrap my mind around all of the new and different.

theme.json WHAT?!?

Thanks to recently exploring Tailwind CSS, along with a few past projects, I was not unfamiliar with JSON files and functionality, but the thought of setting up theme defaults such as colors, fonts, typography, and the like in such a file was so completely foreign to me. This was probably the largest learning curve for me, and where I spent the bulk of my time trying new things as I figured out the various concepts.

I copied the parent theme’s theme.json file into my child theme and started playing around, changing simple items I wanted to change, like colors and font sizes, then tried to change the default fonts to use my Google Fonts of choice. This took some figuring out! Instead of simply enqueuing the font script like I used to, I had to download the actual variable font files from Google, add them to my /assets/fonts/ folder, replace them using @font-face within a function in functions.php, and then see them load as an inline style. I also had to change the CSS variables throughout the theme.json file that called the original font family. Could this really be the way things work now?

Still, as I continued to dabble and discover, I started thinking that this theme.json thing is pretty interesting and exciting. So much you can do with it! Adding blocks and style variations can give your end user all kinds of editing power while still keeping them within the reigns that you set as the developer. I was beginning to see the many benefits and possibilities.

Templates, Parts, and Styles, Oh My!

I didn’t get too far into these three subfolders, but I did poke around enough to grasp the concepts. Rather than PHP files for page templates, we now have the /templates/ directory, where templates are actual HTML files 🤯 consisting of blocks. This, to me, is a whole new language to learn, and although I’ve dabbled in creating my own custom blocks, I have yet to create a page template like this. I am really looking forward to getting there!

The /parts/ directory is the same, but just portions of pages (like header and footer options) that are then called into a page template like so:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

The /styles/ directory, on the other hand, holds your different style variations in JSON files. Again, I have not messed around with styles yet, but the endless possibilities of what you could create for your end users is exciting. With just a click of a button they could change the style (colors, typography, etc.) of the whole site!

In the past, these are the types of things I would code using Advanced Custom Fields, custom post types, page and post templates, and more, mostly in PHP. Now, it’s a combination of JSON, HTML, and CSS to make all these things happen – a radical shift for this old school WordPress guy.

In the end, it took me about a week to build a custom blog theme without many “fancy” bells and whistles, but each day it got easier and more interesting as I figured things out. It was definitely an eye-opening experience!

So What Now?

Moving forward, I am planning to work my way toward building block themes for every WordPress project I take on. It will take some time, and I figure I will still rely on my old faithful process for more complex builds for a while until I get myself feeling confident and well-versed in this new-to-me way of doing things. But I know that this is the direction in which my beloved CMS of choice is heading full steam ahead, so I don’t believe there is any choice but to buckle up for the ride if I want to stay relevant and up to date with current best practices. I’m curious to hear what other WP devs have to say about their own experiences with block themes, if you care to comment.