Blog

The WordPress Evolution Toward Full-Site Editing

The block editor was a game-changer for WordPress. The idea that we can create blocks of content and arrange them in a component-like fashion means we have a lot of flexibility in how we create content, as well a bunch of opportunities to develop new types of modular content.

But there’s so much more happening in the blocks ecosystem since the initial introduction of the editor. Last year, Dmitry Mayorov wrote about the emergence of block variations and how they provide even more flexibility by extending existing blocks to create styled variations of them.

Screenshot of the block inserter in the WordPress post editor. The word buttons is typed into the search field and three button options are displayed below it, one for buttons, one for wide buttons, and one for full buttons.
Three buttons variations in the WordPress block inserter

Then we got block patterns, or the ability to stitch blocks together into reusable patterns.

Full page screenshot of the WordPress post editor. On the right is the post content, which includes a large bold title in black above two paragraphs. On the left is the block inserter expanded with the Patterns tab active and displaying two options for header patterns.
Block patterns are sandwiched between Blocks and Reusable Blocks in the block inserter, which is a perfect metaphor for where it fits in the bigger picture of WordPress editing.

So, that means we have blocks, block variations, reusable blocks, and block patterns. That’s a lot of awesome tooling for designing layouts directly in the editor!

But you may have heard that WordPress has plans for blocks that go beyond the post editor. They’re outright targeting global elements — menus, headers, footers, and such — in an effort to establish full-site editing (FSE) capabilities right in WordPress.

Matt Mullenweg introduces the Twenty Twenty-One theme and its beta full-site editing capabilities.

Whoa. I certainly cannot speak for everyone else, but my mind instantly goes to what this means for theme developers. I mean, what is a theme where the templates are designed in the editor instead of code? I’d imagine a theme is a lot like a collection of shells that contain very little markup. And perhaps more development goes into creating blocks, block patterns and block variations to stitch everything together.

That’s actually the case, and you can test it now. Make sure you’re on WordPress 5.6+, then install the experimental TT1 Blocks theme and Gutenberg plugin.

Cracking open the theme, it’s really two PHP templates then — get this — HTML files used for block templates and block template parts.

The way block template and block template parts are separated closely mirrors the common current approach of separating templates from template parts.

I’m personally all-in on this direction. I’d even go so far as to say (peeking over my shoulder at Chris) that CSS-Tricks is all-in on this as well. We made the switch to blocks last year and it has reinvigorated our love for writing blog posts just like this one. (Honestly, I would have probably written something like this in the past with a code editor first, then port it to WordPress with the classic editor. That was a better writing experience for me at the time.)

Full-page screenshot of the WordPress full site editor with a solid black sidebar on the left with navigation to switch between them templates and site content, and the editor on the right with a mint green background and blocks arranged on the page for the site header, navigation, placeholder content, and three footer widgets.
The TT1 Blocks theme adds a “Site Editor” that takes its cues from the theme’s block templates and block template parts.

While I’m bullish on blocks, I know others aren’t. In fact, I work with plenty of folks who are (and I mean this kindly) blissfully ignorant of the block editor. Developing for the block editor is a huge mental shift and there’s a lack of documentation for it at the moment. Things are still very much in active development, and iterations to the block editor come with every new WordPress release. Can’t blame folks for deciding to wait for the next train as things settle and standards evolve.

But, at the same time, it’s true to Matt Mullenweg’s now infamous advice to WordPress developers in 2015: Learn JavaScript, deeply.

I was (and am still very much) excited about blocks. Full-site editing freaks me out a bit, but that’s mostly because it moves the concept of blocks outside the editor, where I’m only now beginning to get a good feel for them.

Whatever it all means, what I’m looking forward to most is an official release of a default theme that supports FSE. Remember the first time you opened up a WordPress theme? I marveled at the markup and spent countless hours picking at lines of code until I made it my own. That’s the experience I’m expecting the first time I open up the new theme.

Until then, here’s a sorta roundup of ways to stay in the loop:

  • Make WordPress Design – The handbook lists FSE as one of the team’s current priorities with an overview of the project. It was last updated May 2020, so I’m not sure how current the information is and whether the page is still maintained.
  • How to Test FSE – Instructions for setting up a FSE site locally and participate in testing.
  • TT1 Theme Repo – See what’s being reported and the status of those issues. This is the spot to watch for theme development.
  • Gutenberg Plugin Repo – Issues reported for the plugin. This is the spot to watch for block development.
  • Theme Experiments Repo – Check out more themes that are experimenting with blocks and FSE.
  • #fse-answers – A collection of responses to a bunch of questions about FSE.
  • #fse-outreach-experiment – Slack channel for discussing FSE.

The post The WordPress Evolution Toward Full-Site Editing appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.