A Look at WordPress Themes of the Future

A Look at WordPress Themes of the Future

There’s been a lot of discussion around the future of WordPress themes lately due to the ongoing evolution of the block editor. Now that Gutenberg is expanding into other areas of a site (apart from post content), the definitive end of WordPress themes as we know them today is coming.

But is that really so terrible? No, I don’t think so.

I’m thrilled WordPress is leaning away from a developer-driven site experience and towards a user experience focused on… users. But what do these changes mean for future of WordPress themes?

I’m not sure anyone has a definitive idea, but I do have a couple thoughts on a few directions WordPress themes could take in the near future.

A parent theme within WordPress Core

WordPress themes inherently share lots of markup: headers, main content divs, footers, etc. Sure, there are variations – particularly within headers and footers – but if you were to look at themes within the WordPress Theme Directory, you’ll find that the core of a theme rarely varies significantly.

With that saying, what if WordPress core provided a base set of theme files, essentially becoming the “parent theme” for a new type of future theme?

This core “parent” theme would provide the foundation for common theme markup (blogroll/archive views, loops, page content), basic formatting, block styles, comments, headers, footers… everything you’d need for a basic theme framework.

Themes of the future could leverage this core parent theme by essentially acting as child themes do now: styling and overriding when necessary.

But let’s not stop there.

Designing with CSS custom properties

Instead of directly overriding styles, what if this core parent theme was creatively styled using CSS custom properties with fallback values?

Themes of the future could simply declare their own set of style properties to be applied on the front-end, as well as within the editor – automagically.

At GoDaddy, we’ve laid out the foundation for such a system within our upcoming theme, Go. This methodology made it easy to “skin” markup to create unique styles with minimal effort.

CSS Custom Properties for body colors

In its barest form, themes of the future could comprise a stylesheet, a list of CSS custom properties to set the visual design of a site.

A world of same websites?

I think not. With the right amount of thoughtful CSS custom properties for theme developers to use, I see WordPress themes maintaining a firm sense of design personality. Personality is already super relevant in theme design, now that themes are becoming less about page layouts, headers, footers, and widgets – and more about style and personality.

Themes will undoubtable be different. But we are creative beings. We’re good at figuring out how to express ourselves, using just about anything. Check out all the different designs I spun up using just WordPress, CSS custom properties within the Go WordPress theme, and CoBlocks:

Starter templates created with the Go WordPress theme by GoDaddy
All built using core WordPress, the Go theme, and CoBlocks

Sure, there are plenty of considerations to review to base WordPress themes on a design system like this, but there’s obviously something here to think more about.

So why does all this matter?

It matters because this new “parent” theme within WordPress core could be tweaked whenever necessary. Imagine a future where WordPress sites are constantly meeting new markup and accessibility guidelines, supporting future core features when they’re available, and providing a stable page editing experience – all regardless of the active theme.

Themes could actually follow DRY. Developers wouldn’t have to include all the “fluff“ every theme needs. In theory, these themes of the future would hardly need any modifications to work with future versions of WordPress at all – if any. Sustainable, one word that’s not particularly top-of-mind when it comes to themes – today.

Although a bit cliche, this sort of future theme would likely “just work”. Ironically taking a full circle back to the origin of WordPress theming, where simplicity and design ruled.

So what do you think about the future of Gutenberg and WordPress themes?

  1. I do agree we are moving away from Themes as they are now however I don’t see where we are going as being a core provided base theme.

    That seems really great for blog sites or content producers – where the content output is the most important things – but not so much for e-commerce or enterprise projects.

    A core parent theme would need to be generic and in many cases that means bloat that’s not needed for most people. We could build a load parent but I think that will be quite hard.

    I also don’t think we are going down the route of a theme being mainly just a style definition because that’s the opposite and would be too sparse. Theres more nuance to themes than that and even in future I excepted authors to come up with more and more nuances they want to bundle.

    Where I do think we are going is _the right way_ though and that’s important. I don’t know the exact finishing post we are aiming at but no matter where we end up I know we are facing the right direction currently and are moving forward. It’s been slow for themes for many years and it’s nice to have some momentum here again 🙂

    1. I completely agree William, momentum is great for innovation. My biggest concern is also having too many generic themes, leading to generic websites. I do think however that if we could figure out a design framework to style a theme with personality, that blocks would fill provide the basis for unique websites. We’re really only touching what blocks can do and how unique they really be. Interesting times!

    1. Hey Hashim, that’s totally on point ha! I’m excited for what we’ll come together and figure out. It’s definitely an interesting time to dig into the future of themes.

  2. Love this idea and the designs you built with Go. Not specifically related to the ring but I’m curious how this idea of individual page building with blocks translates into sites that use theme template files, custom post types and lots of post meta. Mainly if your site has hundred of pages that are built with post meta and coded templates versus blocks. I do love Gutenberg. But I feel like building single pages with blocks is not scalable and opens the site up to inconsistencies. Think law firms, accountants, architects. Their profiles all look the same and are built with post meta versus stacking blocks.

    1. Thanks Clayton! We’ll we are going to have block templates/patterns of sorts (likely both full-page and section-based), instead of hard-coded theme-specific templates. That’s already in the works and light-years ahead of hard-coded solutions. CPTs will perform the same as pages, likely with their own set of templates/patterns (block-based of course). Sure, a CPT can opt out of Gutenberg, though I think most solutions would work in a Gutenberg-first manner. You can already set block templates for CPTs; even lock them down.

      Figuring out how these templates and patterns work is a huge effort, but monumental towards pushing Gutenberg to that next level. Here’s a GitHub issue on the Gutenberg repo discussing possible mechanisms.

    1. Super interesting Mike. I imagine with block-based headers and footers, we’ll start to see more of those kind of units coming together – but really, how many variations can we have of those? With either approach, I do believe we’ll need to draw a line in the sand to push themes into the direction WordPress core is headed. You’re 100% right that we need a standardized markup/class system in place for blocks (not sure if/when that’ll happen), but for themes – a core-based “parent” theme would solve most of the qualms we’re seeing today (and help enforce markup/class systems). Gosh, there’s a lot to hash out here – maybe it’s time for a follow up post already ha!

      1. IF there was a core parent theme, it could be a step in the direction I was suggesting.

        When you think about it, what do themes really do for WordPress other than enable layout? And layout has evolved from day 1 when the only viable approach was to build it all yourself.

        Today we have so much in terms of evolution of the web with web components and AJAX and the page builder concept and long page designs that incorporate many layers that it makes sense to codify the 80 percentile patterns into core. Doing so would also give standardization that plugins need to add front-end features that were just too fragile to gain widespread adoption in an era where plugins have to accomodate any and every theme. Besides, the 20 percentile patterns could still be accomplished with a 'template_redirect' hook.

        Further, with the advent of tools like Gatsby and Storybook and thus site builders wanting to move to componentized single page apps, the old theming model is looking rather long in the tooth. It would be much better to move to a PHP-based componentization in core so as not to force wholesale move to JS-based front-ends that require build systems to be set up to be really viable.

        JMTCW, anyway.

  3. I actually *love* the idea of having a core theme you can build upon, mainly because it sounds like a lot of the mundane could be streamlined. If it is easy to hook into then it sounds like a way more efficient way of doing things. CSS properties will certainly make some things easier to style visually, but I do wonder how custom page data would fit into this concept.

    Custom metadata for pages and post types is what sets each site apart visually and functionally. It is in my mind the most important aspect when creating a custom site. If it is easy and quick enough to register custom fields and build it into a custom Gutenberg block then YAASS bring it on. However that is not currently the case and it remains pretty hard for both devs and users to solely rely on GB for a custom made site. I know the development of Gutenberg will take a while, but it would be nice to know how custom fields and functionality will fit into all of this.

    1. I’m honestly torn about custom fields. I understand block development is difficult, but learning the tooling and tactics will only help build better future-ready WordPress websites tomorrow. Sure, custom-field driven WP sites will be around for a while, but they will fizzle out when blocks proliferate into the field-based UX territory. We’re honestly still at the very beginning of this whole evolution!

      If you’re looking to get started yourself, I have some slides here I did at a WCUS 2019 workshop covering the building blocks of building blocks.

  4. Somehow I’m thinking this full site block editing idea will turn theme development on its head, quite literally. Previously, a blank theme didn’t do anything, all the functionality had to be added in a specific theme for the user to be able to work with the software. In the future, the blank theme will offer pretty much everything, so a specific theme will likely have to trim down the options for the user to be able to work with the technology.

    I also don’t really see how having blocks is benefitting anyone over the current template model when it comes to primarily data-driven sites. For those, blocks/sets of blocks will have to be pre-coded and often read-only for editors. I’m sure that will work, because, at the end, that’s only taking an established (mainly php-based) templating system and replacing it with a new (mainly js-based) one. Which is annoying and costly, and of questionable benefit for those use-cases, because clients probably won’t be paying for the reduced productivity in the new system (for those usecases). It may mean WP becoming a less attractive CMS in these cases.

    Will a block based design system be more productive for developer-designers because the approach becomes more visual? Possibly, but it will lead to even more similarity in sites.

    It will certainly become easier to create self-hosted simple websites for people who aren’t developers. Now that’s great, and I understand why WP has decided to go down that path for all kinds of philosophical and psychological reasons, and of course, the competition from hosted services and page builders.

    But it is a strategy that appears to prioritize certain applications of the software over others, and prioritize the need of users (of mainly content-driven sites) over developers (of mainly data-driven sites).

    I’m really hoping the WP community can figure out a templating system that allows to service both groups at least decently. But currently I see future theme coders finding it hard to explain to clients why they should pay for something *limiting* their options (because they all believe they can handle complexity and choice responsibly, until they realize complexity and choice is, for their usual requirements of a CMS, quite wasteful of client resources.

    Just my 2 ct.

  5. A lot of this discussion reminds me of how Squarespace used to work a decade ago up until Version 5 (with Version 6, as a complete rewrite, nuking a lot of the functional flexibility it once had). There was a core template and then just skin “styles” that you could easily modify using an integrated style editor and selectors (similar time how Microthemer works). You could even export your modified style as an XML file and share it with a friend or customer who could easily import it.


    The downside back then was a very limited core layout functionality in Squarespace. With blocks and the full site layout editing of those blocks coming to WordPress though, this will even surpass what Squarespace can do right now which is pretty amazing.

    I guess my only question though is that if WordPress goes with a core template and skin styles (which I’d love to see), you really need some way for these the skin styles to contextual modify themselves if the user moves them around because certain style elements are often based upon their relative position to other elements.

    For example, the prev / next post navigation area at the bottom of a single post page could have a 1 px border line styled above and below it because the style works in that location and layout. If the user decides to move those blocks up, separating them so the previous is to the left of the post title area and the next is to the right of it, that changes everything because there is now no “single” post navigation area. Thus how can the style update, if everything can be moved around now?

    Squarespace 5 could achieve this because layout options were limited back then, thus you could provide a few different style alternatives for the variations. For WordPress full site editing though, this is effective impossible because the creative variations are limitless. So besides offering font pairing and colour palette options, the only thing I could see additionally is design accent images, dividers elements, and background images that the user could insert where they choose to lay them out.

Leave a Reply

Your email address will not be published. Required fields are marked *

Up Next:

WordCamp Europe 2019 and the Bright Future of WordPress

WordCamp Europe 2019 and the Bright Future of WordPress