The Future of WordPress Themes in 5.8 and Beyond.
Tags: wordpress, php, gutenberg
Published: 2021-09-16 15:47:53

WordPress — the ubiquitious platform that powers some 37% of the world’s website has largely remained unchanged in the way themes are structured since it released.

You’d buy a theme or pay someone to build a theme and it’d be composed of mostly static PHP files. That meant that if you liked certain design elements of a theme, but not all of them, you’d end up using their page templates for some pages, but then have to modify the theme itself (technically involved, often requiring a developer) for the other pages.

Unless you know how to code, you couldn’t edit your theme’s PHP templates to change how your site looks to a visitor.

Want to change the way the layout looks on a certain page? Often not possible without digging into the code.

As a result, theme’s became more complex. Theme developers would build in multiple options, open up content areas, put a thousand if/else statements and break up single template pages into multiple ‘template-parts’ to adjust things as they go. A single theme might not only power the way the site looks when you visit it, but a thousand and one other administrative functions.

Some admin functions/features for ‘all in one’ convenience, some to speed up the loading. Others to give a long list of options of things you could do, while content generation was mostly limited to a WYSIWYG text editor…so it could…do text…and add an inline image…that never quite looked right.

Themes became complex. Often having to load up dozens of admin functions and features to be competitive.

So, then came shortcodes, now you could add a small piece of code like [do_something] and it’d embed another piece of code that, well, did something (usually display stuff in a certain way).

Problem is, all these things required a developer to make and a somewhat-tech savvy person to operate. At the very least someone with enough patience to learn a technical system.

Page builders like Beaver Builder, Divi, Elementor, WP Bakery all evolved so that ultimately, a designer or a user could just lay down some elements, drag and drop things around and make something that looks nice without digging into making the text editor make content or creating custom post types or custom PHP templates or adding more shortcodes.

WordPress developers might turn their nose up at page builders, but the economic reality is — if you have a low budget site, that just needs to look good for a local small business, it’s just easier and faster to throw a ‘page builder’ on top of it and call it done.

Three major problems occur: 1 — your website stacks a page builder ontop of a content management system…leading to 1 second+ increase in load time or 2 — you’re now locked into your theme and changing it means changing your layout. 3 — Even with a page builder, you’re locked into that page builder…change the builder and change the whole site.

As a result, theme’s entered this strange area: they were responsible for design, but more often than not simply being overwritten by “laying on top” of the theme a page builder. Did some small businesses or coding inclined peoplem make their own or hire out custom themes? Sure. But the vast majority of smaller sites all ended up following this pattern of stacking a page builder ontop of a theme to just “get the job done quick” and without a big price tag…the alternative being living with a theme with set templates not easily adjusted or a more “developer” centric theme that didn’t have strict design opinions for templates, but required you to still do some coding to make the layouts you wanted.

There are three problems with these WordPress website building approaches.

1) Page builders basically stack a new system on top of the WordPress system…no matter what and no matter how well built a page builder is, achieving speed optimizations and long term management eventually becomes unbearable. Even the best made page builders add an average of 1 second to your sites load time.

2) You are locked into your theme — changing themes meant completely changing your website, most often, from the ground up.

3) Even when using a page builder, with an open theme, you might be able to change the theme, but now you’re locked into the page builder. Change the page builder and…now you’re changing your whole site again.

Enter Gutenberg and Block Themes — the new WordPress way to building themes.

Gutenberg is WordPress’s ‘block’ based editor and fundamentally powers what’s known as “Block Themes.” This changes the way themes will operate in the future and fundamentally solves the issues of “theme lock” or requiring a page builder to make your site look nice without knowing code.

Plus, Block Themed WordPress websites load incredibly quickly — often at less than a second.

The fundamental concept here is “blocks.” Blocks are small snippets of code that power “components” like, say, a button, a header, an image. When you build them together, it’s like assembling a lego kit — the individual blocks stack together to create something cool at the end.

Blocks can be styled with new variations and default settings for themes and then stacked together to create Block Patterns — like drag and droppable sections of a webpage. These features exist today in WordPress.

Take blocks and block patterns together and you get Block Templates and Block Template Parts— the still currently mostly experimental feature in Gutenberg where you can edit everything on your webpage from the navigation to the footer and everything in between on any page. Reusable anywhere on your website.

While these concepts are not new to modern web development (in fact, Gutenberg is built off of React, which, well, developers build websites largely following this approach).

The end result? Block themes we develop on average have about ~15 files. custom “Classic” themes could easily total 30–40+.
More importantly, now your WordPress theme is mostly just responsible for design — like what font is used, colors and spacing and things of that nature.

The fun thing here with blocks is that you can use them between themes as much as you like- eventually even being able to take whole page templates from one theme and adding them to another.

If you like a certain section of a website? You can add it as a block pattern to your theme. Like a certain block? take it in. Change themes? Your content is all intact and the layouts remain largely intact. You no longer have to completely overhaul an entire site everytime you want to change the way it looks.

While “Full Site Editing” and full “Block Theming” are still experimental and aren’t available just yet without using the Gutenberg Plugin (which isn’t recommended in production), the future is going to be here faster than you think, and soon the era of large, monolithic themes that have to do everything will be over.

I’ll be diving deeper into the more technical aspects of Block Theming, as well as some of the limitations in ongoing articles, while also covering the non-technical usage of the sites — follow along for more as things come out!