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.
Joel (https://www.joelonsoftware.com/) , 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.
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.
People who build entire sites using FSE: Is your layout in version control somehow? If so, how? If not, does this bother you?
good point
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.
A couple of small things. There are built-in revisions, but they do suck.
Secondly, you can now lock blocks or groups of blocks. https://fullsiteediting.com/how-to-lock-blocks-and-templates/
(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. )
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.
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.
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!
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.
No sir! I wrote more about this here: https://roots.io/php-themes-arent-dead/
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.
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.
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.
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.
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:
https://pinegrow.com/docs/wordpress/courses-tutorials/flex-creating-a-tailwind-css-theme-with-gutenberg-blocks-and-pinegrow-interactions/
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 :-)
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.