Even two years ago, I wasn’t completely confident that I could create everything needed in a block theme for a custom business website. Last year, I reversed my opinion: block themes are now a solid solution for even very complex sites. I don’t grasp all the complexity around Node.js development tools but I no longer feel that they are a prerequisite. With Advanced Custom Fields (Pro), and a good understanding of how the parts of a block theme work, great strides can be made.
I’ve been itching to migrate one particular legacy site over to a block theme to see just how great an impact to site performance there is. I’m also keen to spread the joy of blocks to clients. I anticipate that there will be an improvement to site usability and a confidence boost for content publishers with a block theme.
First question: Can/should I even attempt this?
Built in 2018 using Underscores (_S), this is one of my first fully custom PHP themes as a freelancer. The current website received an interim hybrid update in 2019 to take advantage of some block styles and settings – but not all settings are available so it’s hard to visualize how changes will actually look when published.
Before taking this site apart, I need to make sure critical functionality wouldn’t break. This particular site connects to a third-party chamber of commerce management tool and relies on some scripts and a template file to work. If I do need a PHP template down the road, I can still add that in the new block theme.
But there are some issues I know I have to tackle:
The site has extensive design customizations including animated text, hover effects, custom drop shadows, shapes, and icons. All of this will require custom styles that are beyond what the current site editor can generate. There’s also some content sprawl and complex navigation, but I think I will ignore this until I get past the design work and have a base theme in place (note to self: content work is out of scope, even though it begs for a gentle tidy).
There are several custom post types with overwrought PHP templates and lots of custom fields. I am hopeful these will be easier to manage visually in a block theme – we shall see!
Catalog the current site needs
The current site uses the Custom Post Type UI plugin to create five post types and custom taxonomies for each. These are easy to migrate to Advanced Custom Fields, which I want to do. ACF Pro lets me manage all my post types, taxonomies, and fields in one place. I might also use it to create some custom blocks, like for the text animation currently on the homepage which is already using custom fields.
Choosing a block theme: Start from scratch or use a parent theme?
Since most design and layout work happens with blocks on a page, I first need to decide whether starting with a premade theme is even necessary.
Rolling your own means you only build what you need. You don’t end up with templates and patterns for every possible scenario. But if you code from scratch, you have to manually update your theme.json whenever WordPress makes new block settings or styles available (that you may want access to).
So, in developer-speak: it depends. Understand what you want to accomplish first. There are pros and cons with each approach.
The minimum requirement to enable a block theme is a style.css, theme.json, and templates/index.html file. You don’t need any content here except for theme.json where you want to create a valid JSON object with schema reference and version number. Toss that in a folder, zip it up and upload to your site – start designing with the site editor! But, you can’t do everything in the site editor (yet). Enabling some of the settings and styles available to core blocks through theme.json will require some manual editing of that file.
Using a ready-made theme means you’ll get a head start with some useful presets and you get updates when the theme is updated – so choosing a well supported block theme or parent theme is very important. The downside is you will probably get a lot of templates and patterns you don’t actually need in the theme (I call these “patterns for all occasions”). Patterns may be helpful for non-designers to get a quick start on layout. Since I’m doing a custom design, I don’t find them particularly inspirational – and sometimes patterns in themes have weird structure like an overabundance of divs or vestigial spacer blocks.
I do like Twenty Twenty-Five. Very robust, but equally complex, this is a great choice for a simple site that needs adjustments you can do in the editor alone. With the extensive style customizations I need to do, it feels like I’ll have to fight with it too much.
My fallback theme favorite is Greyd from Greyd Suite. It’s not too opinionated, has excellent accessibility features built in (hello, great focus states), I know it’s getting solid support, and it feels more flexible than most “designed” themes. Ollie and some others are also popular and good options, but the design of these are too controlled for my taste.
Setting up the theme
I’m choosing to create a child theme of Greyd because I feel like it might give me a little speed in development.
To add my own custom fonts and color palettes, the Create Block Theme plugin makes everything easy.
First, I use Create Block Theme to generate my child. Next, I update my color palette and custom fonts in the child. When I write these changes to my child theme, I make sure to uncheck “write patterns” so I don’t end up with a bunch of patterns I don’t need synced within my theme. This save generates a new theme.json file with my customizations.
Next, I wanted to set up in the two main patterns: the header and the footer. In Greyd, there are multiple design patterns available, but to make my life easier, I just want to customize the Header and Footer defaults. That way, I don’t have to go back and update header and footer patterns on every single template. Default patterns are included, well, by default.
Hot Tip: Try to find the simplest solution to a problem before reaching for complexity.
Tackling the home page
The home page is almost entirely driven by custom fields, so I could have easily gotten stuck here. Instead, I decided to just sketch it in and come back to it later. I created the hero section with a featured call to action pattern and moved on.
When things stop working for no obvious reason
In the current design, images have drop shadows. This should be easy with the shadow style for images, right? For some reason it worked on standalone images but not on featured images in post loops. I could see the shadow in the editor but not on the frontend.
This is typical – you start with a fresh new site, the future is bright, and then things start going wrong. These things are universally true:
- Your assumptions will be challenged
- You will have to troubleshoot things that appear “broken”
- You will have to troubleshoot your troubleshooting
- You probably have a syntax error
I opened my theme.json file in my IDE (I use PHPStorm if you care about those things) and manually added the shadow presets to see if they’d get picked up. That worked for the image block but still not for post featured images in a query loop. This was a clue that the setting probably needed to be enabled for that specific core block under styles in theme.json.
Important note about editing theme.json
After saving external edits to a theme.json file, you have to go to the site editor and reload the page. This has to be an editor or template page, not just a regular WordPress page. Reloading updates the database, which updates the version of theme.json stored there, with your manual edits.
If you don’t do this and you keep making changes in the editor, your next “write to theme” command will make the site editor’s version of theme.json the version of record and your manual edits will be overwritten.
Note that this kind of back and forth between your IDE and the editor is really only workable at the beginning of a project. Over time it gets messy. My advice is to get your theme.json set up with the basics it needs, then work on styles in the editor – and use your style.css file if needed.
When the “Advanced CSS” editor doesn’t cut it
We’ll look at this more in future posts but you may need to use your style.css file if you’re doing fancy things like CSS animations, pseudo effects, or … trying to adjust link and focus styles. These can’t (yet) be managed through the editor.
Next time: Archive Views
I could sense I was about to get stuck on some more complex functionality on the home page, so I decided to take a break and move on to some other big pieces, like archive views.
And that’s where I’m leaving things for part 1.
Read the next part in this series where I discover something new about block spacing and more!
Resources to learn more about block themes:
- FullSiteEditing.com from Carolina Nymark
- Theme Academy from Ollie WP (video library of Fränk Klein’s excellent course now open sourced and free!)
- Greyd Suite on YouTube
- Highrise Digital and WP Cafe on YouTube – informative, real life work with block themes and client projects
- Elliot Richmond on YouTube – informative shorts for block developers
- Brian Coords on YouTube – a great teacher and developer, tons of in depth content here
- WordPress Block Themes vs Classic Themes
