This post originated as a list of quick posts on bsky yesterday and I thought why not expand on that thread a bit in a more suitable format.
I’ve been spending a lot more time shipping production sites as fully block-based-theme builds over the past year. And some challenges keep coming up. So with the release of WordPress 6.7 happening it’s a perfect time to identify some of the things that could still use further iteration.
Before I dive into the 9 items that came up over and over I want to preface this post though by saying that overall I am really enjoying this new paradigm and wouldn’t want to go back to building non block based themes.
It took us some time to get here. But as of WordPress 6.5 or so, I have made the switch in my mind to have block-based themes be the new default for any build unless there are really good reasons not to go down that route. (Like I wouldn’t want to use it on a headless build, for example)
With that out of the way, let’s get to my list:
1. Navigation Areas (#45512)
In block-based themes, the concept of navigation areas does not exist. Rather, every navigation block stores the ID of the navigation post it is connected to.
This doesn’t transfer across different environments like local & staging.
What makes it even harder is that when you update the navigation menu assigned to the navigation block, it modifies the template part, and therefore, you are now locked out of code updates to the template part.
One workaround for this is to wrap every navigation block in a template part because then that template part can be modified in every environment without the header actually being modified. So you can still make code updates to the header and keep the unique navigation menus assigned. But this approach still comes short in a bunch of ways.
The ideal solution for this would be to reintroduce the concept of navigation areas or maybe some other approach that would solve all the same problems 🙂
2. Restricting template updates in prod
We don’t just change something in prod on large sites with complicated publishing flows. There are procedures in place to track changes and approve things.
As mentioned in the navigation area example above, updating a template locks you out of code updates.
So, it would be really nice to restrict the ability to actually make updates in prod to specific template parts only.
We have experimented with restricting the site editor to super admins only. However, the problem we encountered was that more folks needed the ability to update navigation menus.
So the fact that there is no differentiation between the edit menu capability and the edit templates capability is a problem for us.
3. Seeing which templates/template parts have been modified (#66646)
Building on 1 & 2. If someone actually has modified a template/template part in any environment, the UI should show that much more obviously. Currently, you have to hover over the template and see if the checkbox is disabled or not to see if you are serving the version from Disk or the DB.
I would love to have a clearer indicator showing me which parts have been modified and which parts haven’t.
4. Adjusting the breakpoint at which the navigation block switches to its mobile layout.
The core breakpoint isn’t ideal for most designs. No breakpoint is the right fit for every site, so having some way to adjust it would be super valuable.
5. Synced theme patterns (#59272)
Block patterns are fantastic.
And with the introduction of pattern overrides, they are so much more powerful.
Today, however, those only exist in the DB. So, a user needs to create them in every environment, and changes need to happen in prod.
Defining them in code would be a dream come true.
Since posting this, I have stumbled across this plugin that manually handles the creation/updating of synced patterns across environments for you. Really cool to see a (arguably a bit hacky) solution actually work to solve the problem 🙂 github.com/pbking/synced-patterns-for-themes
6. Better content-only locking. (#52018)
Content-only locking can create such a nice experience. It is at the heart of pattern overrides and many more features in the core.
However, the fact that we cannot add new list items or additional paragraphs inside a content-only locked area really limits its usefulness.
7. Editable block bindings inside templates. (#66931)
The ability to bind blocks to post meta and even have that meta value editable inline is so cool. We should allow bindings inside templates to still be editable when the post is edited with the preview active. Similar to how the post title block and post featured image blocks work.
8. Typography presets (#66932)
We can have presets for font sizes etc.. But more often than not I don’t just want a size but rather a full set of a type style to apply to an element.
My heading 4 style consists of a size, weight, line height, letter spacing, etc.
Defining reusable typesets similar to how text formatting tools such as Google Docs / Pages etc. work would be really powerful.
9. Border radius presets (#64041)
Design systems often have a few predefined radii that get used throughout a site. Having to insert a px value every time manually makes it very inconsistent and hard for editors.
Also, it is almost impossible to change the radius later in a redesign because that raw PX value has been used throughout the site.
This list, of course, is incomplete, not in any particular order of importance. This list simply is a snapshot of some of the things that popped into my head as I was thinking about common issues I keep encountering on builds that I would love to see us tackle in the next few releases 🙂