July 14, 2023

Sometimes in life, you take a look at your situation and realize that to become the person you want to be, you need to make some big changes. This inescapable truth comes with another: Change is really hard. If you’re trying to decide if you should try out WordPress’ new block themes or stick with a Legacy build, we were in your shoes a few months ago. Faced with a new project, a decision had to be made. Here’s why I went with a full-block theme and have no regrets.

A Legacy of Reliability

WordPress has been around for a long time (since 2003!), and despite all of its changes and improvements over the years, by and large, it has stuck to PHP for building both its frontend (presentational theme) and backend (data read/write and site administration). This is one of the reasons for WordPress’ success. Almost every cheap web server on the internet is a LAMP stack (Linux, Apache, MySQL, PHP), making WordPress relatively easy and reliable to run. Using common technologies also makes it easier to find developers for projects, which is another major reason for WordPress’ sustained popularity.

Change: The Only Constant

How we use and build for the Internet has changed a lot since 2003. For example, around 2002, Jeff Bezos sent a memo to his staff called the “API Mandate.” It was accidentally leaked on (the now defunct) Google+ by Steve Yegge and has become legendary in development circles. Among other things, the mandate demanded that “All teams will henceforth expose their data and functionality through service interfaces.” Basically, he was requiring all of their products to have a way to send and receive information to each other: An Application Programming Interface (API). 

Building apps and sites on top of an API is so common now that it’s hard to remember how revolutionary Bezos’ requirement was. Web applications and sites moved from being self-contained worlds to platforms that could “talk to each other.” 

Creating an API for WordPress

WordPress was able to adapt to this change without shifting away from being PHP focused. They added their API that became part of the core version in December 2016 with the release of version 4.7. Suddenly, it became much easier to pull WordPress content into a JavaScript application or leverage JavaScript in a WordPress theme to create rich interactions for visitors or administrators. It brought WordPress into the modern sphere of web platforms and kept it relevant.

This change was also pretty painless because developers could completely ignore it if they wanted to. You left some capabilities on the table, but if you didn’t want to mess with JavaScript, you didn’t have to.

The Rise of JavaScript

JavaScript is a programming language that runs right in your browser and it is everywhere. Its early use was relegated to adding simple interactions to web pages without requiring you to reload the page. For example, it’s how you make a page do things like expand or collapse a row of content. Over time, it has matured and gained adoption to the point that it can do extremely sophisticated things. Every web app like Google Docs or Facebook is powered by JavaScript and in some cases, even the underlying web servers are running it.

This sophistication led to the rise of services like Squarespace and Duda: Places people without programming skills could create sites with complicated media and layouts. Users liked being able to work this way, and increasingly it has become an expectation.

WordPress’ Classic Editor lagged behind, limiting people to a single-column text editor in a designated “content area” of a page. Any further formatting or customization had to be done by a developer with knowledge of PHP and HTML/CSS. To keep up, WordPress began bringing in JavaScript as a core component by creating the Gutenberg editor.

Building Blocks of the Future

Gutenberg was a major shift in how content was authored in WordPress. While still constrained to a page’s content area, it allowed users to place “blocks “ or pieces of content on the page and manage their layout with a drag-and-drop interface right in the browser. In the past, this was only possible through third-party plugins that often led to a disjointed user experience for administrators, as well as potential compatibility issues. To have it as core functionality was wonderful.

Behind the scenes, Gutenberg shifted towards favoring front-end developers with its heavy use of WordPress’ REST API and the increasingly popular ReactJS Javascript library. A block’s conditional logic and creation still involve PHP; but once you’ve made it available to users through a theme or plugin, adding and editing blocks requires no programming skills.

The WordPress team was smart to slowly roll out Gutenberg. Even with its release as an optional plugin, then later as part of WordPress’ core (with the option to disable it), Gutenberg caused problems with older sites that hadn’t updated their code to the new paradigm. More importantly, it was a new thing that people had to learn how to use. Now that it has been the standard for years, I’m starting to see client sentiment reliably shift from being frustrated by the change to demanding the features Gutenberg offers. Gutenberg blocks are now the expectation.

The Next Move

Now that Gutenberg blocks have become a standard way of working that people are comfortable with, WordPress has made the next (and maybe the biggest) move by changing the way themes are built entirely. The site editor is out of beta and if you have a compatible theme installed, you can change every area of a site in the in-browser administration interface. No coding skills required. Unless you need very customized functionality, it’s now feasible for small business owners and bloggers to build a WordPress site and never talk to a developer. It’s all there in the interface and allows WordPress to compete with closed-source cloud services like Squarespace.

Owning your site’s code and content without compromising editability? It’s a huge win for users. But what about developers and agencies? It’s a hard change and a massive learning curve to switch to block themes if you’ve been focused on PHP for over a decade. Is it worth it? Are we benefiting too?

Why We’re All-in On Block Themes

The short answer: We’re all-in on block themes because we’re all-in on WordPress. Some bumps in the road aside, Matt Mullenweg and crew have put out a reliable and open-source platform for years. They’ve continued to innovate without succumbing to the siren song of trendy tech and overly-rapid change. The world is a better place because WordPress exists and their values are commendable. As a result, WordPress has established a high level of trust with us.

If we’re all-in on WordPress, then we need to go where WordPress is going.

The future is now.

Block themes aren’t just the future, they are already the standard. WordPress still supports what it’s now calling Classic Themes and has excellent guidelines on how to convert one to a block theme or build out a hybrid theme that presents features of both.

We considered a hybrid theme in the pre-production planning for our latest project but decided against it as it provides a disjointed and potentially confusing experience for content creators and site administrators. To allow old approaches in development was also just delaying the inevitable: If we were going to have to learn how to create block themes eventually, why not just go for it now?

We want to empower our users.

Besides the obvious benefit of being able to edit more of their site without developer assistance, block themes are great for clients. Here are a few of the things we realized our clients would be gaining:

Flexible Options with “Guardrails” via Block Locking

Ok, let’s be honest: Give a client the ability to edit their site and they are very likely to break something; or if you’re lucky, just make it look unprofessional. And yet, it’s our job to make sure they have the tools to express themselves and communicate with their audience. How do you balance these two very real concerns?

Block themes answer this with configurable block locking, which allows you to set rules for layout (like whether editors are allowed to move a block) and settings (like if they can change a font’s color or size). All of this is configurable in code, and is often an option in the administrative settings for a block. As a theme developer, you can balance user freedom with the need to enforce the professional design standards they paid you for in the first place. Win-win!

A Safe Default to Return To

Let’s say you don’t care about keeping your client from making crazy edits. You’ve opened the door wide and given them the keys to everything in the site editor’s settings. That’s great too! Creative freedom is low-risk because, as we see it,  a block theme’s main role is to define a site’s default appearance. A user can make an infinite number of changes in the site editor, rendering the site completely unrecognizable from the default.

If your theme’s default styles and settings are well-defined in the theme’s code, users can reset back to them easily in the whole site editor, or even on a block by block basis.

So go wild! You can always go back to where you started.

Block themes are easier to create.

Block themes are good for us devs too. At the end of the day, theming is about creating functional and beautiful interfaces: The front end should be the focus. Block themes are far more frontend developer friendly. It’s HTML, CSS, and Javascript; and the more I got into working with block themes, the more I was pleasantly surprised. Yeah, it was a new way to work, but it’s also a smart and rational way to work.

I think in the end, block themes are a little easier to make than classic themes. Onboarding junior devs with zero WordPress experience but who know a little ReactJS is certainly much easier now.

Don’t Repeat Yourself (DRY).

No programmer or designer wants to do the same task more than once, and WordPress has taken DRY (Don’t Repeat Yourself) principles to the next level. Block themes center around the idea of creating reusable, interchangeable pieces. It’s world’s better than what a classic theme can offer in this regard, which is… nothing. We can finally start creating design systems instead of pre-determined designs. Check out Creating Themes from a Pattern-first Mindset for a taste of what I’m talking about, then revel in features like the Style Book and Block Patterns.

ACF Pro bridges the gap.

We’re big fans of the Advanced Custom Fields Pro plugin. If you’ve developed anything for WordPress, chances are you are too. ACF’s features for building custom Gutenberg blocks are excellent and we used them extensively in our first block theme. As a long-time dev with far more PHP under my belt than ReactJS, ACF has provided a great option that doesn’t feel like a compromise. I generally try to avoid relying on third-party plugins, but this one’s so well done that it’s hard to justify taking it off the table.

Be the Change: Learning by Doing

The best way to find out if block themes are for you is to try them out for yourself! If you haven’t already, I think you’ll be pleasantly surprised. Here are some of the resources we found the most helpful as we got started:

• A Deep Introduction to WordPress Block Themes
• Our recommended starter/parent theme: Blockbase
• Block Theme Resource Roundup
• A Developer’s Guide to Block Themes (Part 1, Part 2)

If you’d like to work with us to build an amazing site with WordPress’ latest features, let us know! We’re always looking for the next great project.