,

Will WordPress 6.6 have components?

These past few weeks, I’ve been chipping away at a few new site builds while also testing out WordPress 6.6, a remarkably “big” release considering the relatively short release cycle. I can’t decide if this release will actually change my workflow in a meaningful way, but (like I’ve said the last five releases) I can see the potential for what’s coming in the future.

That said, I’ve been seeing a lot of buzz about a few of the major features, and specifically a number of educators using the word “components”. A true component-based web design system inside of WordPress would be the developers dream, but I just don’t think we’re there yet.

We can get there, we’re just not there yet.

Component Basics

A component is just an isolated piece of design/functionality that can be reused and re-purposed throughout a site. There’s probably other words that are better for this, and a better definition, but this’ll do. The end goal for most developers I talk to is that some aspects of a component can be edited, others can’t, and it can all be version-controlled.

There’s probably four key elements we need solved for this feature:

  1. Ability to control the markup/structure, the HTML
  2. Ability to control the styling, the CSS
  3. Ability to mark specific dynamic/editable data
  4. Ability to add interactivity, frontend JS

And a fifth requirement is that no components should be loaded on the frontend of the site if the component isn’t being used.

Now, if you’re with me so far and have some block editor experience, you’re probably thinking of blocks. And yes, blocks check all of these boxes and are working pretty well as smaller components, but what happens when you want a slightly larger component than a single block could handle, maybe an image carousel instead of a single image, or a hero section instead of a single heading?

That’s where block patterns come in. Block patterns are going to probably be the true component system of WordPress, but right now they’re not powerful or consistent enough, because they don’t let you really handle those 4 key areas mentioned above.

Most developers I know who want to have the type of control we’re talking about will end up making a custom block, maybe with some inner blocks, where they can fully control the markup and bundle their own CSS and JS if needed. Its probably the best solution for right now, but it’s clunky, time-consuming, wasteful, and not the best long-term strategy. (I’d probably put ACF Blocks forward as the most popular version of this approach.)

Right now WordPress has a number of key features that could one day give us true components:

  1. Synced Block Patterns – Ability to control the markup/structure, the HTML
  2. Section Styles / Block Style Variations – Ability to control the styling, the CSS
  3. Block Bindings API / Pattern Overrides / Content Locking – Ability to mark specific dynamic data
  4. Interactivity API – Ability to add interactivity, i.e. frontend JS

All of these features are moving forward, but let’s talk about two of these features that are getting a big update in this release, Section Styles and Synced Pattern Overrides.

What are section styles?

If you haven’t seen it, “Section Styles” is sort of a fancy name for block style variations, and sort of something else. Here’s a tweet thread where I’ve been collecting more of my thoughts as well as a livestream where I built a few section styles and demoed their capabilities.

In block themes, you can add a /styles directory to include theme style variations, basically alternate versions of theme.json with different colors, fonts, etc. Well, now you can add little mini json files that include block style variations, alternate designs but scoped for individual blocks.

Here’s an example of a block style variations for the button block:

The user can pick a style and it presets a bunch of design options: color, border, font, etc.

The reason they’re now being called “Section Styles” is because they also let you add styles for nested elements or nested blocks. So you could create a style variation called “Dark Mode Section” and include what background color it should be AND what color all the text should be, the links, even the default design of the buttons inside.

Here’s an example of “Dark Mode” section that includes color and text options for the headings, buttons, etc.

So far, these have been really handy to set up a few default block style options like ‘fancy subheadings’ (for the paragraph and heading block), an ‘outline button’ style (for the button block), and custom header and footer menu styles (for the navigation block).

But they’re called ‘Section Styles’ because they’re mostly powerful when you add them to the Group or Cover blocks and use them to design an entire section, like above. That ability to click one style and all the content conforms to a design standard- no weird accessibility contrast issues- is really powerful.

So I’m excited. Sort of. There are limitations. You can’t control every style that’s available in CSS. You can’t control anything that’s layout related, like alignment, gap, flex controls, etc. You can’t control pseudo-classes or pseudo-states for blocks. You can’t control sections nested inside of other sections. You can’t hide block settings if you just wanted to show your section styles to users. You can’t add multiple section styles to a single section. And you will end up with a LOT of Group block section styles, cluttering up the UI, if you’re not careful.

The main problem with most of these limitations, though, is that most seem to be intentional with the spirit of the feature, so they’ll probably be limitations we’ll have to work around by writing our own CSS separately.

Synced Pattern Overrides

Let’s switch talk about another feature that’s was slated for WordPress 6.5 but coming in WordPress 6.6: Synced Pattern Overrides (formerly partially-synced patterns).

Block Patterns are critical. I place their importance (structurally) somewhere between blocks and the template hierarchy itself. If there’s a path towards components, this is it.

Synced patterns (formerly reusable blocks) are patterns that can be changed in one place, but updated everywhere. We’re getting closer.

And synced pattern overrides are the idea that you can have block patterns that are mostly synced (in terms of layout, structure, and design) but allow each instance to have different content (namely text and images right now).

Here’s a synced pattern on my site where I can override the heading and button text if I want:

While I’m very excited about this feature, I haven’t really had a chance to use it just yet: mostly because theme developers cannot include synced patterns in their themes. Yeah, synced patterns can only exist in the database of an individual site.

Synced patterns might make it to theme developers in the next major release, but that’s not a guarantee.

And there’s some functionality that will still be needed, like the ability to bundle section styles with patterns, the ability to give a single pattern the option to toggle section styles, the ability add overrides for other content-ish attributes like background images, and probably support for postmeta fields for better data structuring options.

Note: I should probably have a section here about the Interactivity API as the other part of this, but at this point it’s still waaaaay too complex and undocumented to recommend to theme builders. My impression is the Interactivity API is in its infancy and needs some time to bake.

So, will WordPress have components?

What prompted this stream of consciousness post was the idea that I’ve been seeing from others that we’re finally seeing “components” in WordPress. I get it. Components are extremely common in most other frameworks, and even WordPress core has it’s own “components” library that is used inside the block editor.

But let’s be clear, we’re not really seeing components in WordPress sites, not yet anyway.

The problem here is that these four features all exist in near isolation from each other- you can’t bundle styles with patterns, you can’t control layout from your styles, you can’t add interactivity to patterns, you can’t use post meta bindings for pattern overrides.You can’t let users swap section styles on synced patterns.

There’s just a bunch of limitations in each feature, with one really big central limitation: all of this would need to start with Synced Patterns being allowed to be added to themes and be version controlled, not just live in the database.

The other big limitation is more conceptual. For a developer who is interested in bringing FSE into their workflow, the biggest factor right now is decision fatigue and decision paralysis. Every piece of design you want to create comes with a ton of open questions- how should I build this? Will I be able to edit this later? Should I style it in the editor, in CSS, in JSON? What if I need interactivity? Should I just start adding classes to everything? How fragile will this be when I hand it to a client? Will they be able to intuitively edit what I want them to edit and not break it?

I’m really optimistic, but I think it’s important to have these real discussions, because from the outside it looks like a bunch of disparate features, but no clear articulation of what exactly is trying to be built here.

I’ve sketched out an idea of where I think it should be going, but I could be wrong! And I’d like to know that now so I can go focus on Laravel or Shopify or something.

So. Are you a theme builder / freelancer / agency developer? Do you agree/disagree with this need for “components”? If there was a clear way to build what I described above in the block editor, would that solve some of your problems and get you more interested in FSE? Let me know what you think!

6 responses to “Will WordPress 6.6 have components?”

  1. David Corradini Avatar

    I’m trying very hard. But the style in json with the variables name. It just feel wrong to me.
    The only happy path for me is still acf block that create some kind of the partial sync section you are talking about.
    For the styling, I need tailwind. It feels so much more natural than the wp class names and the all json approach.
    And last, responsive… 2024. No way to manage responsivness in the editor.
    I still have to add tw classes in the editor.
    At the moment I’m really trying, really struggling and really doubting.

    1. Brian Coords Avatar
      Brian Coords

      Yeah a lot of the devs I know have embraced putting Tailwind on top of it to make it more manageable. I would love to say you don’t need to add another design system on top of Gutenberg, but unfortunately that’s just the reality.

  2. Ryan Avatar
    Ryan

    On the team I work with we have go in circles a few times

    – Block styles
    – Block variations
    – No to block styles
    – No to block variations
    – Block patterns
    – Now section styles

    What makes this challenging is that it feels like you can’t just pick on and move forward. There’s not an easy way to “undo” or “update”. If you use a block variation multiple times throughout the site there’s no way to know where that variation was used. Same with unsynced patterns.

    I’m now considering going back to a more class based approach.

    1. Brian Coords Avatar
      Brian Coords

      Yeah agreed. I like that block styles are technically “class-based” in that they just add a class to the block and you can extend it from there. But it’s so limited that it’s almost useless as a feature.

      Every one of these features is like 60% of the way to being useful, but none of them are really professional enough for the agency/team workflow.

  3. Faton Avatar
    Faton

    Hello

    I have also given some thought to future developments. I hope it gets the necessary attention from developers who are familiar with it.

    https://github.com/WordPress/gutenberg/issues/63878

  4. Ryan Avatar
    Ryan

    It’s all nice features but I feel like Gutenberg’s so far away from the web itself. They spend so much energy in making everything different, or simpler if you want to but it’s the built-in pagebuilder of a professional CMS, there’s no need for it to be simple. If you want client editing, then that needs to be a seperate thing. Just because it should be easy for the clients to edit stuff, it shouldn’t mean that we whould live with that simplified interface.

    No section or container element. Everything’s named differently, not div but group. Every single dev who knows HTML can sit down in let’s say Webflow or Oxygen and be like “jup, I want a section and now a container. A div seems nice and let’s add a heading.” In modern WordPress, they’d need a day to figure out how the difference between the site and page editor and to understand section styles and patterns.

    Then, it’s neglecting the simplest things. Why can’t we have a Custom CSS field on every elements’ settings? Why does adding a button require a “buttons” wrapper? Why is there no responsive settings? I get that fluent-auto-responsive-thing but what if I want some more control? Ah nah, having a duotone filter for images was more important.

    I like the block editor, but I feel like in their effort to make dev simpler, they’re actually making it unnecessarily more complex. I have so many friends who come to me saying that they’ve created a simple wp blog a few years ago (classic theme) and now they can’t even change the background color of the site

    So curious where all of this will lead us.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.