The Death of Themes as We Know Them

I Come to Bury Themes Not to Praise Them.

Themes and Plugins have been an integral part of the WordPress community pretty much from its inception. But, with the advent of the Gutenberg editor and the associated blocks, themes, as we previously understood them, are changing in dramatic ways.

Selecting a WordPress theme will become a UX (user experience) choice and largely irrelevant to the aesthetic (user interface or UI) choices. We developers will customize the visual aspects of our web properties with pre-built Gutenberg blocks, JavaScript code snippets, and custom CSS frameworks instead of what we think of today as themes. These visual artifacts are currently available as plugins – thereby making plugins as relevant to your site’s look-n-feel as any theme used to.

Blocks as Plugins

Here is a sampling of available Gutenberg blocks available as plugins:

• Atomic Blocks – Gutenberg Blocks Collection
• Ghost Kit
• Stackable – Gutenberg Blocks
• Ultimate Addons for Gutenberg

As plugins, these UI elements transcend a specific theme choice. As the popularity of these plugins grow, next generation themes will have to take such third-party influences into account. This frees the custom developer to make a theme choice based on the structural elements it provides (page layout, wayfinding, etc.) and less on the aesthetic affordances which dominate theme choices today.

Structural Reorganization

Historically, when organizing custom code, we’ve thought of themes as the place we store logic specific to the site’s aesthetics (UI) and wayfinding (UX). And, plugins as the place where we put site-independent, functional logic. It’s becoming more important to think in terms of WHEN we want to execute our custom code.

If we look at the WordPress file, wp-settings.php in your WordPress root folder, you’ll find the primary hooks for plugins and themes:

• Plugin Hooks –
  • 329 do_action( 'muplugins_loaded' );
  • 371 do_action( 'plugin_loaded', $plugin );
  • 394 do_action( 'plugins_loaded' );
• Theme Hooks –
  • 463 do_action( 'setup_theme' );
  • 509 do_action( 'after_setup_theme' );

As we move forward, the decision as to whether your logic belongs with the plugin or theme hooks will depend more on where WordPress Core is in its loading sequence than our traditional thinking of look-n-feel versus functionality driving that decision.

Example Theme

Imagine, if you will, using the very basic “Underscore S” theme structure as your actual parent theme. This could become the parent theme for EVERY website you develop, regardless of differences in the actual UI.

I believe the Underscore S website statement, “I’m a theme meant for hacking so don’t use me as a Parent Theme.” is pre-Gutenberg thinking. And, as such, is no longer accurate.

In fact, Underscore S is the archetypal example of future themes. It is focused exclusively on providing a specific UX, and, was developed explicitly to NOT provide UI.

Framework Themes

Theme frameworks, like Genesis, will need to increase their focus on performance and structural flexibility as well as easily incorporating third party blocks, plugins and JavaScript snippets. Historically, these frameworks required third-party developers to adopt “their way” of doing things. That will change with this decentralized theme structure.

Not Quite Dead…

The non-coding website development community will continue to demand traditional “finished” themes. And so, there will continue to be demand for such themes. But, there will be less interest in these themes from the coding community. Instead, we’ll be able to pick and choose individual transitions and block-level behaviors to include in our new-style theme. If developed properly, these UI components become building blocks of reusable functionality.

The Uncertain Replacement

In these new-style themes, all of the website’s aesthetic choices will be set in a Controller-style interface. But, this is where WordPress has yet to provide clear direction. We have the Customizer, the Block Toolbar and the Settings Sidebar. All three include Controls for setting and tuning the user interface. The Customizer seems to be setup for overall styling while the Block Toolbar and Settings Sidebar are for block specific changes.

Accessing the Controls for these “editors” are in separate locations. The Customizer interaction is relatively stand-alone as is Gutenberg. There is no direct interaction between them. This appears to be more of a historical evolution in thinking rather than an intentional design decision. Shouldn’t we address all user-interface related Controls from a common place? Or, at a minimum, be able to effortlessly move between them?

Controlled Vocabularies and Wayfinding

Both the Customizer and Gutenberg were designed to be as flexible as possible for the designers/developers of panels and blocks. This has been good for the tool developer community, but will create confusion as we move forward.

Those from the design community understand the value of a controlled vocabulary. In particular, the value it brings to wayfinding.

The lack of guidance on what to name panels and what controls to include in them has created something of a “wild west” as far as the Customizer goes. Theme developers have felt free to organize the Customizer in whatever manner made sense to them. Not unreasonable when it only impacts your theme. Unfortunately, for the consumer of themes, this has led to an inconsistent Customizer experience.

For example, as a WordPress administrator, I should be able to interact with the Customizer in exactly the same way if I want to change the default font family. This wayfinding exercise should be common across ANY theme choice I’ve made. Today, this is not the case.

I fear the same is happening in the burgeoning block developer community. Blocks performing the same function have different names. The grouping of blocks is organized around the vendor rather than by common function.

It remains unclear to me if WordPress recognizes this issue.

Final Thoughts

Replacing themes with blocks of repeatable UI elements; reusable JavaScript code snippets defining transitions; and immutable plugin functions all lends to the integration of modern practices into the product design/development lifecycle. But, we must develop a common organizational structure and naming convention for accessing these tools.

I am optimistic and see great opportunity for the custom development community. Perhaps, less optimistic for companies who made their living selling themes.