Blocks Have Changed How We Approach Building Themes – Here’s How

In-case you haven't heard, WordPress came out with this neat little thing called Gutenberg a few years ago. Even today, sites are still being designed using the classic editor, and over 5 million sites run the classic editor plugin today.

I think what has tripped up a lot of people who are still using the classic editor is fear. Changing something as big as the content editor on a site can have some pretty big implications. The block editor uses a completely different set of tools, most of which is written in JavaScript instead of PHP. For a developer, or agency that has been working with WordPress for a while, this alone makes switching to the modern editor a daunting task.

But more than anything, I think the scariest thing is understanding the workflow that comes from working with a block-based WordPress website. Block-based editing completely changes how you approach themes, and not understanding what that change is like can be one of the scariest things of all. This post is written to help shed some light on those implications, and answers a key question - how do you approach building a site with the block editor?

WordPress Before Blocks

For most of WordPress' existence, sites were built using themes. Themes are put together using a series of PHP files in a theme directory. These files can determine how the layout of any given page, archive, or blog post. Themes have also been responsible for rendering the html in both the header and the footer on the site. You can even change the markup of most plugins directly inside your theme. Basically, if it is display related, a WordPress theme can change it.

The thing is, many of these pages need to use the same markup across multiple pages. WordPress accommodates this with two key concepts - theme hierarchy and template parts.

WordPress automatically checks your theme for a set of different files in a theme hierarchy. This determines which PHP file is actually used to render the output on the page. Which files WordPress looks for depends on what kind of page is being loaded. This allows you to specify things like "all archive pages should use this for the content", or, "this specific blog post needs to be styled in a special way".

Before the block editor, sites were designed, and developed by the page. Designers would design entire web pages, and developers would make these web pages edit-able with something like Advanced Custom Fields. If you go to a site that is still using the classic editor, you'll find most of these sites have custom page templates that contain several hyper-specific Advanced Custom Fields for that template, and the page template itself would use these fields to create a very specific template. Any re-usable code would be placed inside a template part and would then get re-used where-necessary. Most sites would have 5-6 different templates, and all content would work using one of these templates.

What Have Blocks Changed

Blocks have completely flipped this approach on its head. Instead of creating page templates, pages are assembled using blocks, and any layout that needs re-used gets saved as a re-usable block. Designers still design pages, but now must be a little more aware of how those pages are going to be put together. These pages should be able to be broken down into re-usable components, not just pages. Most designers I've worked with have already been doing this for years, but it has become a solidified practice now.

Developers tend to work in the opposite direction as the designers. First, the developer will create each block created by the designer, and then they will assemble each page using the blocks they built. This creates an interesting dynamic between the developer and designer, because now their processes are the inverse of one-another. The designer starts by building the page, and the developer starts by building the blocks. This can really trip up the process if the designer is unaware of the developer's context, and vice-versa.

The best designers I've worked with will take the time to pull each unique component from the page designs and create another screen that features all of the unique components that make up the site. This makes things a lot easier for the developer since it more-or-less dictates what blocks need to be created.

This Change Probably Isn't Groundbreaking

Blocks have forced us to think of themes as a collection of blocks instead of a collection of templates. WordPress calls them blocks, but this design principle is nothing new. Brad Frost has been talking about Atomic Design for years now. React works entirely around re-usable components, and even WordPress itself has had been able to make themes modular using get_template_part for a while. One of my favorite Tailwind features is the ability to make styles modular using @apply, and Underpin has a modular template system, as well.

If you look at design tools like Figma, Balsamiq, or Sketch, you'll notice that they all work well with modular designs, and can usually allow designers to build out pages using the components built.

So, although this does change how we approach building a WordPress site, it doesn't change how we fundamentally approach design. In fact, it validates it. It is now more important than ever to understand how to build a design system instead of how to design a website. If you understand, and have been building in systems, not pages, for a while, the transition to the block editor is going to feel natural.

Conclusion

The big shift in web design with the block editor is in how it's built in WordPress, and potentially in how you approach designing sites altogether. If you're already building sites around a modular design system, you're probably going to have no trouble switching your workflow to be compatible with the block editor. In fact, you'll most-likely find that it is a much better solution than what we were doing in the past. After working with the block editor for a few years now, I groan when I have to make changes to a site that's using the classic editor, because there's a significant disconnect between how the design system works, and how the site is built.

In a way, WordPress is playing catch-up with design principles that have been created, and used over the last decade. It is beginning to align closer than ever to design paradigms that have existed for years - and we finally have a way to translate our components directly into WordPress, and that feels pretty solid.