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.



I work on CodePen! I'd highly suggest you have a PRO account on CodePen, as it buys you private Pens, media uploads, realtime collaboration, and more.

Get CodePen PRO

18 responses to “Noodling on WordPress in 2023”

  1. Dave Mackey says:

    Joel ( , et al.’s work on a common block protocol is pretty interesting too – I look forward to seeing where that ends up.

    imho, the transition from traditional WP to Gutenberg was pretty painful from a developer perspective. I haven’t been doing much WP development recently (lately it’s been Django and Vue) but WP still holds a very fond place in my heart and I still run a number of sites on it.

    Since I haven’t been doing development with WP recently I can’t speak to the DX experience. I have seen some of the posts indicating positive changes in the DX in the recent past. If there are still gaps I’d love to see some time dedicated to the DX.

    We could also use a good book on “modern” WordPress development (e.g. w/block editor). Have any free time on your hands Chris? Always appreciate the high quality of your articles.

  2. After working with PHP WordPress since 2006 and essentially ignoring Gutenberg until now, this post is timely. I worked on a bunch of headless sites but those don’t make sense to me considering that FSE will be the WP paradigm for the next 10 years so I decided to go all in and recommended that for a client with the caveat that I β€” and literally almost no one β€” knows the “right” way to build a FSE theme/site/whateveryouwanttocallit today.

    The links you posted are definitely helpful but I agree some DX work needs to be done. It is the wild wild west for FSE when WordPress is 39% of the web. That is sure to change in the near future but I found the lack of a clear development path a bit shocking.

  3. Scott Fennell says:

    People who build entire sites using FSE: Is your layout in version control somehow? If so, how? If not, does this bother you?

    • Kaspars says:

      All of the FSE content is stored in the DB (in the post_content of wp_template and wp_template_part post types) and there is no way to control it via source code which is why most large-scale sites still don’t embrace FSE.

      The second challenge with blocks is that their output (including HTML markup) is stored in the DB so updating any of that requires scanning through all posts which isn’t sustainable. This is why most custom blocks for enterprise use must be built as dynamic blocks that only store the block wrapper and JSON props in the DB while the render logic is handled 100% server side. This allows for changes to the markup and render logic after a block has been added to any part of the site.

      Finally, the block editor doesn’t have a way to lock down editing parts of content to specific user roles which means that users can accidentally break layouts and change settings. This is useful for small sites with a few pages but becomes a significant overhead on larger sites, especially for QA when the changes are not associated with code pushes.

      • James Tryon says:

        A couple of small things. There are built-in revisions, but they do suck.

        Secondly, you can now lock blocks or groups of blocks.

        (There is a slight chance that comes on next week in 6.2 vs. 6.1. You could also install the Gutenberg plugin to get the newest features faster. )

      • Andrei Chira says:

        I think I remember reading about a way to enable content-only editing for blocks, and the block controls will not be visible to editors, so they cannot break the layout, they can just change text & images. It will probably get more polished along the way.

  4. Nabeel says:

    In the recent couple of years, I started to lean more toward full site editor, and less use of themes. Oxygen builder helped with that.

  5. Mizagorn says:

    Hey, Chris, thanks for the food for thought. I don’t actively seek out authors in any genre (sorry!) but I do certainly enjoy reading yours when they show up in my news feed.

    Love your comment about productivity with extensibility!

    When you steered towards block themes, you said, “They might have any PHP files at all…” Perhaps there is a NOT missing there, or did I misunderstand the sentence?

    Keep up the great content. You rock!

  6. I will say that once you get the hang of where to look, the DX for building customizations in the block editor is kinda awesome compared to the old editor. WordPress provides several very useful blocks, a fetch API that handles authentication, and even a redux store that you can manipulate to work with the saving operations. If you’re using post meta or taxonomies they just work, and even support validations from the registration.

    The block editor is amazing. It really is. I’m building better things for people than I’ve ever built, in less time, and it all feels so seamless.

  7. Ben Word says:

    PHP themes are dead

    No sir! I wrote more about this here:

    • Aaron says:

      I definitely agree to that, Ben. And I hope that there is a significant enough group of WP developers that work with more “php based themes” to create great custom made websites.

      For a while now I’ve been the Flynt starter theme which focuses more on a classic editor experience (non Gutenberg) based around ACF and Timber but otherwise stays very sleek. As a developer it’s by far the best DX I had and enables me to build complex sites in maintainable way by using components. Also I think it makes for a good, simple editor experience that can be quickly understood.

  8. Eldar Osmic says:

    I just like new WordPress. It is almost enough just to style existing core blocks and play with CSS for block styles. Easy and fun.

  9. Anh Tran says:

    I have the same feeling. I haven’t switched everything to the block themes yet, and I’m still using and making traditional themes, but I’m not sure how long can I do that.

    However, writing in Gutenberg is nice and I think Matt and WordPress did it well.

  10. Block Themes (is that the same as Full Site Editing, FSE, or not? I don’t even know)

    A block theme is just a theme built with nothing but blocks :)

    Full Site Editing is the old name for Site Editing and encompasses all the site editing features like the Site Editor screen, the global styles system, theme.json, style variations, template parts, the new site blocks (site logo, site title, site tag line, feature image, post title, comments etc. ),

    Not all site editing features are limited to block themes, you can combine PHP and HTML templates, template editing, classic menus, and the customizer all in one hybrid theme.

  11. Brian Steele says:

    Chris, I’m just curious if you’ve had a look at Pinegrow for creating native blocks? It’s pretty easy to do and once you’ve used it to create a theme or plugin, Pinegrow is no longer required. You can even paste code into PG (for example, from CodePen) and make it a native block.

    I read they’re looking into FSE, but I’m not quite sure how it will eventually fit in. One advantage of how it works now is that you can keep your project under version control.

    In case haven’t already seen it, here’s a good intro to how it works:

  12. TW says:

    Very good article, which comforts me, that I’m not alone in my confusion about how to implement the good working “old” php functionality into a FSE theme. To be honest, FSE for me sounds a little bit like an illness, such as BSE …
    But what the hell you all mean with “DX”? I know UX, UI, AI, JS … can someone please can make me smarter about DX?
    Thanks a lot :-)

  13. thebiglechowski says:

    I’ve been a WP developer for years, and I like the new block editor and standards they are trying to achieve. However, the glaring flaw is still that the editor and the front end are still disconnected. You can use block editor but it (very likely) looks nothing like it does on the front end. You’re still just writing rich text but in a “blocky” way.

    The reason that Elementor and others are still used is because it’s a literal WYSIWYG, you can see the changes made in real time. IMO until block editor moves to the front end to enable live editing, it’s always going to be behind. All my clients want this too, because for people who run businesses they don’t want to have to learn all about a back end editor and then have to bounce back and forth between front and back end to see if their changes take or not. This is why the customizer was built, but unfortunately with FSE it still requires separation from the front end.

    On top of that even though I can see that the WP team is trying to make more styles editable. What if I want a header that hides when scrolled. Or to change the mobile menu icon? Or apply custom animation to elements etc. Or want responsive style changes? There’s so much depth to constructing a design, and with the editor you quickly hit a wall and are then forced to slap on custom CSS/JS – this is a similar problem with many themes unfortunately, even paid ones.

    FSE is a great idea but until it can 1) offer the same level of customization / responsive design granular control as Builder plugins do and 2) work on the front end, I don’t really see it being a viable option for a lot of developers, besides for very simple websites.

Leave a Reply

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

Back to Top ⬆️