I still read messages like this in WordPress developer Facebook Groups and Twitter:
Clients breaking sites is a common issue for developers. And that’s because block theme development is entirely different to classic theme development.
In “old” WordPress, clients couldn’t change their website significantly unless you allowed them to.
In modern WordPress, it’s the other way around. Clients can change anything unless you prevent them.
And that’s because WordPress users have access to all blocks by default, in every editor. And with these blocks come the default customization options–of which there are many.
Therefore, removing any unwanted customization tools should be the first task on any website you build for clients.
What features should how you remove?
My checklist goes like this:
- Remove WordPress.org repositories: Patterns, Block, Media.
- Remove unwanted blocks.
- Remove unwanted customization options.
- Remove unwanted block styles.
That is the basis for every block theme project I do. For Hybrid Themes, you should also look into disabling block widgets and the page template editor.
How should you go about removing blocks?
By default, WordPress shows all available blocks in all editors. Meaning that the content editor also gives access to theme building blocks.
The removal strategy, therefore, depends on whether the client should have access to theme and layout blocks.
A typical scenario is that you want to remove any theme and most layout blocks from Posts. This post type is all about content.
If you use the content editor as a page builder, a common approach in hybrid themes, you can give access to the relevant blocks there.
Even if you use a block theme, I would still remove blocks like widgets.
Remember that removing blocks does not prevent them from being used in patterns. Because you should only prevent blocks from showing up in the inserter. Do not unregister Core blocks; it’s a surefire way to create bugs.
A possible refinement here would be to add an additional layer that targets user roles. For example administrator users can get access to more blocks, and this way, create patterns from blocks that authors might not get access to.
Make sure to lock these patterns though. Else authors might remove blocks that they can’t re-add themselves because you filtered them out.
How should you go about removing customization options?
There will always be customization options that you do not want at all. For those, just remove them using theme.json. This not only works for Core blocks, but also for all well-coded blocks in plugins.
Then there might be customization options that you want for some blocks, but not others. For those you can use theme.json as well to remove them for specific block types.
Typically I wouldn’t want text blocks (heading, paragraphs, lists,…) to have background color selectors. Because I prefer to use Group blocks for that. This is possible to achieve with just a few lines of JSON.
Then we get to the more advanced use cases. What about a client that uses Posts for plain content, and Pages for building layouts?
In that case, use the PHP filters for theme.json. The way I approach this is that I temporarily change the theme.json to remove all the settings I want.
Then I copy and paste this JSON into my PHP filter callback, and use json_decode() to transform it into an array. It’s a workflow that sounds awkward, but that works really well.
In opposition to theme.json, the PHP callbacks have access to the wider application context. So you can filter per post type, and per user role.
Technical implementation
When I launched the first version of my block theme development course, it wasn’t possible to control the editor experience.
This only changed with the introduction of theme.json in WordPress 5.8, and then the PHP filters in 6.1. Now there is a lot to cover.
So much that my Block Theme Academy course bundle contains an entire set of lessons that only focusses on this aspect: controlling the Block Editor.
It contains all the lessons and code snippets necessary to lock websites down. And as a bonus you get the Bare-bones Starter Theme, which gives you a clean slate to start from.
But before you jump onto the implementation, I want you to pause. Because with the right starting points and information, this isn’t too hard.
But what is harder is coming up with the approach for how you want to handle things. This depends a lot on the types of clients you have, the projects you build, and how you build these projects.
Planning your customization strategy
So what I’d encourage you to do next week is analyze your specific needs, and come up with your own starter checklist and theme.
It’s fine if it’s not the end all be all. But just get started.
Because don’t make the two mistakes I have seen on the last two block theme development projects I worked on:
- Not locking things down: If there is a customization option, sooner or later your client will use it.
- Locking down after the fact: This results in a lot of unnecessary “where did X go?” conversations with your clients.
What’s the better approach?
Come up with a customization strategy before the client ever opens the WordPress admin.
And if what you gave access to is not enough, you can always add more customization options.
But do so deliberately, and sparingly. And you’ll enjoy the same peace of mind as you did in “old” WordPress.
Cheers,
Fränk
