Initial Documentation for Block-Based WordPress Themes Proposed

In a pull request on the Gutenberg repository yesterday, Riad Benguella created an initial document that outlines how block-based WordPress themes might work. While the document is merely a starting point for the conversation, it is a set of ideas that will likely forever reshape the WordPress landscape. It is paradigm-shifting.

For the first time, theme authors can glimpse what their future holds. Since the inception of Gutenberg, many have asked for more technical details. Particularly, they wanted to know whether themes would be reduced to a stylesheet or a stylesheet and a few PHP files. What would themes look like architecturally? Would themes exist at all?

The document, while open for changes, makes a strong case about the structure of themes going forward. It is clear that much forethought has gone into the proposal. It matches the direction of the experimental site-editing feature in Gutenberg that has already been set in motion. Even though it is subject to change, there seems to be a finality to the overarching idea. The writing has long been on the wall. Now everyone can see the wall. The missing piece is figuring out how to bring the idea to fruition.

What is Full Site Editing?

Before understanding how themes of the future might work, you must first understand the direction that Gutenberg is headed. The end goal for Gutenberg, and eventually WordPress, is for users to have the ability to customize every aspect of their site via the block system. Currently, the block system primarily handles editing post content.

To move to full-site editing, every piece of dynamic data about a site must be a block. For example, a site title block must exist as a placeholder for the site title. Users should be able to place it anywhere they desire to output the title, such as in the header.

This has left theme authors with a reasonable question: If users can move these blocks anywhere, where do themes fit into the picture?

It is easy to see how themes would become little more than a stylesheet that styles every WordPress block while also handling other necessary styles like typography and vertical rhythm. Even then, it makes one wonder if themes, at least in how we have come to know them, are necessary at all.

The Proposed Theme Structure

The proposed structure does not look much different from current WordPress themes. The big difference is that theme templates would become “block templates” and “block template parts.” These templates would be HTML files rather than PHP files.

The following is where the structure currently stands.

theme
|__ style.css
|__ functions.php
|__ block-templates
    |__ index.html
    |__ single.html
    |__ archive.html
    |__ ...
|__ block-template-parts
    |__ header.html
    |__ footer.html
    |__ sidebar.html
    |__ ...

From a templating perspective, it appears relatively normal for a WordPress theme. The files simply have a different type and are organized in specific folders.

However, the difference is how the HTML templates would work. They would essentially become placeholders for blocks. Users would also have the ability to edit or completely overwrite individual templates via the WordPress admin. Because templates are made up of blocks, no code would be necessary on the user’s part. They could simply point and click to insert or remove blocks with their mouse.

In other words, block templates within themes would be unique starting points for users to build their sites.

There are two noteworthy items about the proposed system: themes are still themes and end-users can become theme builders.

The Essence of a Theme Remains the Same

When you cut through everything else, WordPress themes have always been HTML and CSS. The PHP aspect of theming basically mixes PHP function calls (i.e., template tags) within some structured HTML markup. If you look at most themes going through the official WordPress theme directory, you will find that the underlying markup is mostly the same.

In the block template system, this idea doesn’t change. If anything, it could simplify the role of theme author by creating a set of standard elements (blocks) that themes output. If done right, it also creates a standard for class names so that styles can easily be shared across themes and all sorts of similar goodies.

Anyone Can Build a Theme

The initial outline explains the potential of exporting themes:

Ultimately, any WordPress user with the correct capabilities (example: administrator WordPress role) will be able to access these templates in the WordPress admin, edit them in dedicated views and potentially export the templates as a theme.

This is where the proposed system could revolutionize website building. Those without the coding skills to create a WordPress theme today could have the tools to contribute something back tomorrow.

The idea aligns perfectly with the open-source ethos of WordPress. By giving everyone the ability to export their customizations, it provides an avenue for contributing that we have never had before for non-coders. A free directory of customized themes created by and for the community, anyone?

The Design Side of the Equation

Block templates are merely the HTML. Themes will need to stand apart with their CSS. However, there must be standardization to pull this off.

Designers will need to shift to a block-based approach when it comes to design. Some may already be familiar with various “component-based” systems, which would work much the same way. Rather than designing from the top-down, theme authors would approach design on a more atomic level by designing each block.

There are also many unanswered questions about how styles will eventually work. Currently, there is an open ticket for discussing a style system for blocks. Much of the discussion is around how to integrate a design system with themes.

Join the Discussion

It is important to point out that nothing about this proposal is set in stone. It is a high-level outline of what the future of themes could hold. However, now is time for input from the community, especially theme authors who may have felt a bit out of the loop in the past. Now is the time to make your voice heard and to contribute ideas to the discussion.

The WordPress theme review team also has an open discussion on the future of themes that goes along with this proposal and whether themes should start taking advantage of experimental Gutenberg features.

24

24 responses to “Initial Documentation for Block-Based WordPress Themes Proposed”

  1. Sure a website could be made up of nothing but blocks although a theme would still need some PHP files right.

    One post or page will have to have sections though right??

    possible pre header section
    header section
    Pre Main Content section
    Main Content section
    Post Main content section
    Footer section.

    Throw in display options for each sections and you are good to go.

  2. This concept seems to take current page builders such as Beaver Builder and Themer to the next level. I will be interested to see where the idea goes. Even though I am a web developer, I have always been in favor of empowering site owners to do as much as they can for themselves.

  3. Ultimately, any WordPress user with the correct capabilities (example: administrator WordPress role) will be able to access these templates in the WordPress admin, edit them in dedicated views and potentially export the templates as a theme.

    This is awesome. I imagine the future of themes will be more focusing on customization from some HTML templates. And that makes WordPress more like Blogspot or Tumblr and more fun.

  4. He who forgets history is doomed to repeat the past. While it must be a noble-feeling to enable all humans to become designers, the “everyone enabled” thinkers forget to think deeply beyond code. Everytime in our past that we have put tools into everyone’s hands, the results have been the same: a surge in mediocrity, a loss of the excellence brought by professionals, a proliferation of poorly done work, a decrease in the value. Look at the so-called logo industry. Automation has devalued logos to the point of marginalization. The list is long.

    Long live the good feeling from enabling all. Long live the growth of mediocrity — of a web where already 95 percent of websites are rarely visited.

    One might argue that writing is easy. All you must do is cross out the wrong words. The trouble starts when humans cannot figure out what to cross out.

    Now let the posting of words that praise begin, let them swell into 100 feet waves, let them fill a screen with what we now interpret as loud clapping noise. But noise proves naught. A chicken cackles so loudly you would think she had laid a unique and exciting boulder, when upon looking more closely, it is nothing but another common egg.

    Carry on. Carry on.

    • I could not agree more! In an increasingly specialized world, we want to empower everyone to be generalists. This whole “new” theme-system should be built first and foremost with product makers in mind, not end-users. This would be true empowerment and evolution, both for end-users since they would get better products, and for individuals or companies looking to raise the bar on quality.

  5. Interesting. We could move to a model whereby the .html theme files are, in a sense, a custom post type similar to the difference between Pages and Posts in a standard installation.

    With standardised .css calls and block names, a change in theme would only require a change in stylesheet. I suspect a really good theme designer would then have to explain how s/he designed their sample theme, which blocks they used where, so that users know how to get the same experience themselves.

    So… yeah. Interesting.

    • Chip, to me it is interesting how new themes will co-exist with “classic” themes on WP.org as for at least 2-5 years there will be users still on older WP versions or on newer versions, but with Classic Editor installed.

      It looks that theme authors will be forced to post modern iteration of their themes as new themes, otherwise I do not see how in practical way theme author can serve “classic” theme to users without Gutenberg and “modern” theme to users with Gutenberg.

    • Geocities was a long time ago. I do not think we really risk turning WordPress into Geocities. Sure there will be more ugly websites as it gets easier to design sites, but there will be plenty of people who choose to go with a professional so they can focus on whatever their actual business is.

      At the end of the day WordPress finds itself in a tight spot. Competing with newer sometimes more full featured platforms like Medium, Squarespace, and Wix. Plus having platforms out of their control growing on top of them like Elementor and other site builders.

  6. Hi Justin, this seems like a great step. I feel that at this point of time Gutenberg is half baked and needs to go through a lot drastic changes to compete with popular page builders. The proposed system will not revolutionize website building. There are many tools and system already available today using which anyone can build websites. However not everyone will able be able to create great website for various reasons. I hope the future is bright for the WordPress ecosystem.

    • You are absolutely right. Same was posted by various people already before “forced” launch of Gutenberg last year, but nobody (of the “inner circle”) cared. It’s still half baked, if even half. :-(

  7. Well…
    GB made and continues to make WP a mess. With ever growing inconsistency and increase of possible bug/failure sources. Many devs will abandon WP and head for other platforms to make them more compelling than before. So WP will lose with this GB transformation. At the end also the end users will recognise they lost those devs and that is why end users will need to spend more and more time pimping around with each block instance they put in their content.

    Would have been so much better to launch the GB concept as a new brand.

    • Many devs will abandon WP and head for other platforms to make them more compelling than before.

      When will this mass exodus of developers begin? We’ve seen this same claim for over two years now, but it has yet to start happening.

      WordPress 5.3 had 645 volunteers, which is the largest contributor group ever for a release. I don’t have specific numbers at the moment, but I’m certain that plugin and theme submissions haven’t taken a dive.

      I’m not arguing that there won’t be some folks to leave the project. However, this claim doesn’t seem to be rooted in fact.

  8. Honestly if the theme is just handling the presentation with CSS, and the overall structure can be modified by a user via front end editing, I don’t even see much reason that block templates and what not need to exist. I guess maybe it’s more inline with your article https://wptavern.com/themes-of-the-future-a-design-framework-and-a-master-theme, but changing the presentation on the page via CSS (and if necessary some JS) is trivial. People used to always reference http://www.csszengarden.com/ as a primary influence of how to style themes, but many themes have just become more and more bloated, and shy away from good design principals in the first place. If authors were forced to design blocks and layouts with just css by only modifying the presentation, and not the structural elements – themes would still have just as much diversity as they do today. Sure there might be some slight exceptions, but I think in those cases, a theme adding additional choices to the editor to dictate the styles they add would be a better solution, similar to block styles that already exist today and are rarely used/implemented by themes. Simple examples being sidebar left, sidebar right, dual sidebars, no sidebar – every theme should have this option in the editor, and a user should be able to easily add or delete the sidebars as they choose. Having a header on top, a sticky header, a header that’s fixed on the left or right, etc those things are all trivial and the majority of what theme authors are adding to templates is just unnecessary classes, and checks for customizer controls to change basic things that should already be easily editable no matter what theme a user chooses. For additional flexibility even just having simple hooks to render additional html/class within a “master” template for authors would/should be more than sufficient to achieve any design/development need. Theres of course the developer in me saying I should be able to override anything that I want to still, but if core had controls and ways for users to handle their layout – I could hardly see many use cases where overriding a template would be necessary. Designers focusing on block based components is definitely the future. I guess I do support the “one master theme” approach to an extent, but honestly I am excited to see where Gutenberg takes the future of themes. You’re doing a great job of not letting themes be forgotten and bringing awareness. Thanks!

  9. i’m concerned about the influence of Google/Automattic on what is supposed to be a free software, community-driven project, and I’m also concerned about recreating Geocities, which essentially seems to be what’s going on. That said, if we’re going to build ourselves a rocket ship just to get down the street to the nearest convenience store, are we at least going to use all that power to try to ensure that standards-based, semantic markup ends up becoming popular, and are we going to learn from the mistakes of Geocities/page builders in general and ensure that users aren’t creating websites which then have to be remediated due to accessibility or other concerns? I mean we as a project/community. Also, I’m a little concerned, based on google being involved with this, that we’re essentially doing native AMP, (which has a ton of critiques from those who are concerned about accessibility or just the plain-old open independent web), but for WordPress. There are already standards, (w3C), and I’m not sure I want to see a project like WordPress, (which, like it or not, has a history of completely ignoring said standards, especially when it comes to third-party themes and plugins and even in core), all of a sudden creating a standard, something that normally takes years to do and takes a lot of input from a lot of interested groups. Which seems to be where all this block business is ultimately headed. Same applies to Google, which also has quite a history of ignoring standards, however much they preach about their importance.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.