Noodling on WordPress in 2023

I was catching up on Matt’s latest State of Word the other day. I’m something of a career-long user and fan.

WordPress has changed a heck of a lot over the past few years. One big change was the Block Editor (aka Gutenberg). I wasn’t maybe on the bleeding edge, but I was a pretty early adopter. I think it’s an awfully good idea and a big upgrade to the page creation and writing experience. Turns out holding onto state data in HTML comments is just weird enough to work.

The Block Editor holds onto the basic existing UX of content editing, and even theme creation. It’s ultimately: “I’m just building a big chunk of content I’m going barf out onto a page somewhere”, but does so more elegantly than a glorified textarea the old editor.

The community did a good job making useful blocks. And, crucially, despite it being a pretty steep learning curve and involving weird technical decisions, we could make our own custom blocks. (I’m pleased they now have an official scaffolding and dev tool, which makes me more comfortable than winging it.)

Matt didn’t just show off the Block Editor, that’s almost old news now, the new story is all about how the Block Editor has made its way into other contexts. Perhaps the Block Editor can become a sort of defacto way to generate content, a widely used open standard. Don’t hate it. So far so good. I’ll say though — might be a good idea to start embracing (declarative) Web Component output sooner than later. The encapsulation possibility there will be clutch for broad usage.

But while the Block Editor was a big change to content editing, and Block development was a new paradigm, it didn’t change theme development all that much. Themes are more about content types and overall page structure and breaking things into logical partials and such. The Block Editor didn’t really get involved there.

But now the new push seems to be Block Themes (is that the same as Full Site Editing, FSE, or not? I don’t even know). I do know that they are very different than (regular?) themes. They might have any PHP files at all (😱), or even CSS (😱) but instead just some JSON configuration for styles. And… maybe not even that… because the UI is more and more in charge of every aesthetic detail. So between Block Themes, Query Loop Blocks, Block Variations, and all this new world… themes (as I think of them, what with the template hierarchy and all that) might just be a thing of the past?

I think that was the spirit of Geoff’s Not Sure How to WordPress Anymore? And raises questions like What even is a WordPress developer?

Certainly, you can just build a WordPress website the same way you could a decade ago (props, to WordPress for backward compatibility). But is that prudent? Are you missing out on important and useful aspects of modern WordPress momentum? Probably!

People certainly are figuring out how to switch, I just haven’t made the mental leap yet. What people were writing about as a modern front-end workflow for WordPress in 2020 definitely isn’t that anymore in 2023.

Part of me thinks WordPress needs to spend a year working on DX. There needs to be a clear message about how people should be thinking about building themes and how to do so with productivity keeping extensibility in mind. And if they come pre-loaded with a WordPress development history, what they could and should do with those skills. Another part of me thinks… maybe that’s exactly what they just did with Block Themes. What I always thought I wanted was to build themes with a modern component model. WordPress in the back, Astro on the front bb. But instead of that component model being a JavaScript framework, its Blocks, and PHP themes are dead. 🤷‍♀️

Oh BTW it’s friggin wild you can run the whole WordPress stack in the browser. No way that isn’t going to change things in years to come.

This content was originally published here.