Themes Set Up for a Paradigm Shift, WordPress 5.8 Will Unleash Tools To Make It Happen

For much of WordPress’s history, the foundational elements of building a theme have been slow to change. Every so often, developers would get a new feature, such as child themes, featured images, nav menus, and template parts. Each of these was epic in its own way. However, theme authors had ample time to adapt to these single feature introductions.

When the block editor landed, it did so with a bang. Love it or hate it, it shifted how we think about design for the web. It was not one of those one-off enhancements, regardless of how many times we were told it would “just work” with any theme. It sometimes does not technically break things. Support and integration are necessary for an ideal user experience, and theme authors have been slow to catch up.

With WordPress 5.8, theme authors are gearing up for another paradigm-shifting set of changes. Josepha Haden Chomphosy, WordPress Executive Director, announced last week that several Full Site Editing (FSE) sub-components will begin shipping with the next release.

In the latest episode of the WP Tavern Jukebox podcast, Nathan Wrigley hosted guest Anne McCarthy. He asked her to calm people’s fears over upcoming changes. “So, as an example, let’s imagine that we’re a theme developer. We may be getting concerned that themes are going to become a thing of the past, that the livelihood that we’ve created for ourselves is going to disappear before our eyes.”

It is a common question. Since the inception of Gutenberg, particularly its features that fall under FSE, themers have wondered if there would be a place at the table for them. If WordPress is moving toward a grander page-building experience, where do themes fit in? If users can change the layout or manipulate all of the styles, what is the theme’s job?

These questions are finally getting some answers. We can see the real-world changes introduced in recent months. They paint a much clearer picture, defining the role of themes in WordPress’s future.

“And for theme authors, themes are going to be so important in a full site editing world,” said McCarthy. “And one of the things I am so excited about is that there’s going to be a ton of what they’re calling…the idea of these hybrid universal themes that can work with, for example, template editing.”

She is referring to a recent discussion that makes some distinctions between universal and hybrid themes. Essentially, universal themes would work in both a classic or block editor context, depending on what the user chose. A hybrid might support parts of the block experience but have a path to becoming a universal theme that fully caters to any user down the road.

While this does not wholly address theme authors’ concerns, these are the building blocks that Gutenberg contributors are thinking about. First and foremost, they want a solid user experience. However, the discussions show that they also recognize that theme developers need to opt into new things at their own pace, supporting features as they understand them and learn how to implement them. This provides a path forward for traditional themes to transition into the new era and be built from scratch with new tools.

Themes may well be more vital to WordPress’s future than they were in the past.

New Tools Coming in WordPress 5.8

Decorative image of a wooden desk with various tools lying on it.

The site editor and global styles features are not planned to ship with WordPress 5.8. However, the upcoming release is set to introduce some powerful tools for theme authors. This will be a pivotal moment for theme development companies that want to make their mark in the space. The right team with a forward-looking mindset stands to disrupt the market and make millions. And, there is room for the authors who just want to build cool stuff.

It all starts with the new template-related blocks that should be enabled in the next major update. In particular, the Query block provides an alternative to what was formerly only possible via code and carefully constructed theme options. Coupling it with existing features opens us to a world of possibilities.

For example, I chose a theme from the most popular list on WordPress.org that looked to have one of the most complex query and loop setups of the bunch. The following is the homepage of EnterNews:

Homepage design with various post sections for a news website.
EnterNews WordPress theme homepage.

Anyone familiar with theme development can tell you that it would take at least eight different queries to create that homepage design without looking at the code. The only way to build that and allow users to customize which posts appear is through a series of theme options (probably category-based dropdown select boxes).

If the Query block ships with WordPress 5.8 as expected and is also enabled for any theme, this layout is suddenly possible directly from the block editor — no site editor necessary. Via block patterns, users can insert these “sections” of different Query blocks in their page and reorder them. However, it requires buy-in from the theme author.

As I said earlier, theme authors have been slow to adopt block-related features as a whole. Undoubtedly, the system for the EnterNews homepage is already getting the job done. And, if it works for the theme’s current user base, there may seem to be little incentive to change.

However, there are real benefits from a development angle to transitioning to a new system. The most obvious is that it requires little code compared to the PHP needed for building customizer options. Block patterns are little more than HTML with bits and pieces of JSON configuration in the mix. Developers can literally build them from the editor and copy/paste the code part.

By writing less code, it lowers the potential for security issues and other bugs. Theme authors can also be less rigid in their design, allowing users to move pieces of the layout around.

The Query block is not the only one slated for inclusion in 5.8 outside of a block-based theme context. The Navigation, Site Title, Site Logo, and more are ready to ship. Most such blocks are vital components for building an entire page. Theme authors could start handing over the tools for building complex landing pages on launch day this July.

Stepping Stones

Decorative image of stepping stones between reeds.

Not every theme author needs to step up and attempt to revolutionize the theme space — though I am looking forward to those who do. Others might want to take a more measured approach. FSE is a set of many sub-components, some of which are shipping with WordPress 5.8. Many of these do not require developers to opt into them. They will “just work.” Sort of. Mostly.

Users will be able to switch to a template-editing mode directly from the block editor. From there, they can create entire page templates of their choosing. Theme authors can either stand in their way by not styling for blocks or make the experience more enjoyable.

The widgets screen and customizer will allow end-users of traditional themes to insert blocks in any of their sidebars. Some theme authors will need to account for this in their designs. The HTML output might throw off some layouts. For those who are not ready, they should disable block-based widget support.

The most crucial tool, however, is entirely optional for theme authors. That is the introduction of theme.json support. The theme.json file is the cornerstone of future theme development. It acts as a config file for block settings and styles, allowing theme authors to set up the defaults for anything.

In a nutshell, theme developers can set up any of the block options from this file, and those options are automatically handled in the editor and on the front end.

Themes can also define defaults for block options that do not yet exist in the interface. The system will automatically output these as styles, even if users cannot change them in 5.8.

Again, this means less code work for themers in the long run. While there will likely always be a place for custom CSS, some themes could essentially be built from theme.json configurations. That is not possible today. However, theme authors can start taking advantage of this tool.


Themes are not going the way of the dinosaur. All of that overly complex PHP code work necessary in the past might just be. The shift is putting themes back into their proper place: design. Previously available tools such as patterns and styles coupled with the new pieces like theme.json and template-related blocks will be the backbone of the new system. It is all starting to come together.

The transition will take some time, and each themer will need to decide for him or herself how much they want to take on. But, the time is near. I might even crank up the old code editor and start putting together a project myself. There has never been a better time to be excited about theme development than now.

18

18 responses to “Themes Set Up for a Paradigm Shift, WordPress 5.8 Will Unleash Tools To Make It Happen”

  1. How will FSE impact using WordPress for organization/company websites. In that context, themes are meant to be locked down to ensure there is a consistent design. And moving theme development from code to the UI is not good if you have a workflow dependent on using version control for your theme.

    Report

    • This is exactly my concern with both Gutenberg and FSE.
      There is NO WAY I want my client’s junior staff dragging a Query block onto the home page so they can accidentally show “latest news” 3 times.

      I do not want clients dragging theme elements around and they don’t want that either. They want simple editing. They want to update their “about us” and edit their product details, and their text and images, but that’s it.

      My clients do ask for better editing of course, such as : “how do I add a table and set the padding” or “how do I turn off the big image which is at the top of some pages”. But any time I have a client’s employee who decides to start “improving” the company site it’s a disaster. Most clients never want to edit their templates !!

      The assigned staff who are tasked with updating the content of client sites sites are usually the most junior and inexperienced. If there’s a firm of architects then web updating falls to the intern or graduate who can’t be trusted to make a decent cup of coffee yet.

      My job as their WP web developer is to make the editing experience foolproof.
      My job as web support is very often un-FUBAR-ing the mess they make when editing the site. If some exhuberant employee has installed a weird banner plugin, or pasted a bunch of Wysiwyg HTML into the page.

      I want a locked down editor for clients, I need locked templates which don’t allow them to break the layout.

      It seems like all this full-site-editing development is all for amateur businesses who run their own Wix style sites. Basic blogs and 1-man-bands. Micro businesses.

      Where are the tools for devs like me who need to lock WP down in a myriad of ways to provide a robust CMS to clients?
      Where is the feature set for SME websites? I need to lock these templates in 50 ways so that “Daft” Jimmy can’t drag in queries on the home page and edit the main menu!

      Report

      • It seems like all this full-site-editing development is all for amateur businesses who run their own Wix style sites.

        This is also my impression. Might be a nice idea for some personal website of some tech savy devs who like to change everything once in a while but not really thought through for real world company sites where some random person gets “assigned” to “update the website” and has no idea what a block is and never will have. They look for those fields for a title and a text and a publish button and nothing more…

        Report

      • This is so spot on and thank god im not the only one with that kind of mindset. I dont get the idea WP being a ‘builder’ because it causes even more problems. Ive been developing custom themes for 8 years or so and ive never had the need froms clients to edit the sites and add banners.
        Thanks Steve!

        Report

    • If anything, you will eventually have more control over locking down design and layout elements than what is possible with traditional WordPress. You would be able to lock templates, enable or disable blocks and patterns based on permissions, and more. Much of this is possible now, and we can expect more advanced features in the future.

      Remember that “locking down” things like this outside of the basic role capabilities is not native to the classic editor either. Developers have to build such things on top of it, regardless of the editor.

      As for developing from code instead of a UI, I don’t see anything having to change in that regard for agencies and other developers.

      Report

      • Yeah. In the future.

        I am NOW working with clients on their site.
        I create NOW new sites for them.
        And NOW i do not want my clients change the full site design.

        The WP Updates are a running experiment with every update and new features. Opens more and more design features for the client – i and the client do not want.

        As a long WP developer – currently i am making some tutorials in laravel and sympfony – to get the controll back. my client only wants to change the content, not the design.

        Report

        • There is nothing stopping you from doing that now. You do not have to give control over the design to your clients.

          I am happy to talk specifics and help out where I can if you run into an issue — I am a developer too. If there’s something I don’t know, I’ll try to find out or find someone who does know. Seriously, shoot me a message at justin@wptavern.com or on WP Slack @greenshady anytime.

          Report

        • I am NOW working with clients on their site.
          I create NOW new sites for them.
          And NOW i do not want my clients change the full site design.

          I’m in the same position as you. So far, I’ve used the block editor for a couple of client sites and every now and then I receive an email asking me to fix a page layout because the client screwed it up while adding and deleting blocks. Thankfully, those are not very complex sites so it’s not difficult for me to fix them. For the rest of my sites, I still resort to the classic editor.

          Report

      • The block editor and FSE should really have permission handling built in from the get go before more is merged as part of core. Just because the TinyMCE editor was flawed before does not mean that the new editor should be even more flawed regarding permissions.

        Report

  2. WordPress improvements are not killing themes but page builders as Elementor or Visual Composer. If I would be part of the team of those companies I would be very concerned about my future.

    Sadly, because I’ve enjoyed of both for many years.

    Report

  3. Big changes coming. As a designer who works with other site builders, I’m looking forward to the shift.
    One thing I’m wondering is how will the Query block work in “a world of blocks”.
    Will it rely mainly on CPTs & Taxonomies – will these be the developer way -, not custom fields?

    Report

  4. In regard to the comments above and without any doubt a dev will have to define block usage by utilizing the user roles.

    The coming FSE features mentioned above are certainly interesting and I am looking forward to explore them fully.

    To be honest they sound much more interesting for a theme dev like me than anything else block-based yet (except for the widget areas, which we kind of got a preview of already). The reason might be that I am coming from a dinosaur world where you keep your content separated from your design — as much as you can at least. Fancy block patterns will work on landing pages, but probably not on ten year old blogs and magazines trying to keep their content future proof for the next 20+ years. Nobody wants to back edit years of content for a new screen-size, design fad, a simple theme change or whatever might come in the following years (kiss – keep it simple stupid!). Looking at past experiences, I just say short-codes and translation plugins!

    While this might at least partly explain the hesitance of theme developers jumping on the “block wagon” fully committed, I fully share Justin’s outlook that there has never been a better time to be excited about theme development than now.

    Report

  5. WordPress need to update gutenberg blocks and add few more options like table of content, pro & cons section and few others so that bloggers need not install 3rd party plugins

    Report

  6. Hello all,
    all nice concepts in the pipeline, but again not thoroughly thought in times of responsive webdesign.
    For me it seems like there are things released that are in “early” or “proof of concept” state.
    As a theme developer, integrator or client i can adjust things like color, font size or line height etc. for the component or theme wide, but there is no settings for breakpoints or responsiveness. This will lead to inconsistent interfaces from different theme companies and block lib companies, further leading to inhomogeneous ecosystems.
    There seems to bee a lack of clear strategy/ definition/ target group for whom the new tools are (its just the, oh we need to take care of wix, squarespace and co.), there is no clear ux and implementation resulting.

    Report

  7. I agree 100%
    Why do people buy themes ? Because they look good.
    Gutenberg provides better design features, specific block design for a unique and coherent theme design. More freedom and power in the hands of the theme designer, in short.

    I am always puzzled by recurrent comments from web designers regarding the danger of customers messing with their websites. Here’s my take on this issue.

    Gutenberg answers the opposite needs of the DIY customer and web designers quite well.

    If you’re a DIY person, it’s more fun than ever. Total freedom with Gutenberg.

    If you’re creating a web site for a customer – in essence not a DIY person, keep that in mind -, no worry : you can lock blocks into place, can’t you ? There’s a solution for that : template_lock, built in core. Want to lock block-styling options as well ? The use of ACF blocks or any equivalent solution is a simple answer : data is decoupled from the design. Appropriate freedom for the customer.

    Yes, it is easy to turn a great looking theme/website into something nondescript. All you need is an access to the website’s backend and no knowledge of website design. The typical scenario is the small business owner hoping to save money going the DIY route, buying an option packed premium theme believing he will get the same result as the demo that seduced him. What ensues is usually a total design disaster. But all is fine : he did not want to invest in the first place.

    Still, some web designers seem to give admin rights to their customers. Why ?
    Worse : many use such best-selling DIY premium themes. These were not built for web designers. Others give access to their favourite page builder, with some quick instructions. Don’t complain if mayhem follows. Don’t be lazy.

    The same goes for standard Gutenberg blocks, conceived with a DIY approach in mind to compete with Wix and the likes. Such a crucial strategic choice required no barrier between data and design. For that reason, unless you love spending time on customer support, avoid them if you’re a web designer : they were not meant for you in the first place. (But they are awesome for theme designers, selling good looking DIY themes.)
    Again, do bear that in mind : DIY freedom for the customer is the enemy of any web designer.

    As is, you can create and lock block templates (populating a page, a post, with a set of predefined blocks, locked into place ), but you can’t lock block-styling options easily, not yet (as far as I know). No need to complain, Gutenberg has you covered : you are free to create as many blocks as you want, with full control. All the tools you need to do so are available. Some block building tools and block libraries already offer such options out of the box. They do come with a price, as they are built for professional web designers.

    With such tools, securing access to parts of a WordPress website, guaranteeing the integrity of its design, while enhancing its flexibility, has never been so easy.

    True, the era of spaghetti code is now gone, no more messing around using snippets of php, tons of plugins, shortcodes and stuff to tweak a template. WordPress embarked on a much needed journey, reinventing itself as a clean and reliable solution for the future, with higher and stricter standards as far as code is concerned. That leaves out many “intermediate level” web designers who relied on such cheats/tricks, unless they adapt. But is it bad ?

    In any case, I have never seen customers asking for admin rights and full control of their website. They are customers because they want to trust the expertise of an agency and not waste time. Appropriate user roles are enough, if they need any – making regular content updates on specific pages, being able to blog, are legitimate needs, accessing everything is not. And again, in such cases, lock what is supposed to be locked.
    And yes it is easier and faster to set up and fine-tune with Gutenberg.

    Bear in mind that most of the time customers don’t want to handle content updates themselves, and don’t even want to run a blog. Just don’t ever sell them how easy it is to do so with WordPress, snapping your fingers, because it is not, unless you love to provide endless customer support on trivial stuff. Spare some precious time, yours and theirs, and provide updates/upgrades for a fee. That works with content too. Lock everything that should be. And make more money in the process. Reward yourself. Your customers will love you.

    In short the issue is often a business model issue : a misconception of the customer’s needs coupled with a loose sales strategy (or none at all), on top of a lazy choice of tools. For a web designer, selling the DIY mantra to customers is a very bad idea. Giving in to a full access prerequisite is also a no-go. If a would-be customer requires it, just don’t take that job, leave hell to others.

    Even if you did – giving the customer full access to the website – and a nasty mistake happened, a one-click backup restore would save the day, would it not?
    Undesirable behaviours are best avoided through a proper locking strategy, though. Educating the customer is key. So is adopting a proper approach to building a website for a customer : use the right tools.

    Report

Newsletter

Subscribe Via Email

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

%d bloggers like this: