Gutenberg contentOnly & Block Bindings vs an Inline Editor for Custom Themes
Short answer: Use templateLock: "contentOnly" and the Block Bindings API when the site is built from blocks: a block theme, Full Site Editing, or block patterns. They are native and free. Use an inline editor such as LiveCMS when the theme is hand-built PHP, because those templates have no blocks for either feature to lock or bind.
Both features come up whenever an agency asks how to stop clients breaking a layout. They are good answers, but to a slightly different question: "how do I curate the block editor?" This post explains what each one does, according to the WordPress developer docs, and where an inline editor on the live page fits instead.
What does templateLock "contentOnly" do?
Content-only editing arrived in WordPress 6.1. You set "templateLock":"contentOnly" on a Group, Cover, or Columns block (or a third-party block that supports the templateLock attribute), usually inside a pattern or template. According to the Block Locking API docs, WordPress then:
- hides all design tools for that container while keeping content editable;
- hides non-content child blocks such as spacers and columns from List View and makes them un-editable;
- locks the child blocks against moving and removal;
- stops new child blocks from being inserted.
Two details matter for client handoffs. The block toolbar shows a "Modify" option that lets a user switch the broader design tools back on, and the docs say it can't currently be removed programmatically. And there's no UI to manage content locking; it's set in code. So contentOnly is a strong guardrail for a block-built page. It's an editing mode inside the block editor, not a permission system, and it only acts on blocks.
What does the Block Bindings API do?
The Block Bindings API shipped in WordPress 6.5. It connects a block attribute to a data source, so the value comes from that source when the page renders.
The Bindings reference lists the default supported attributes: Paragraph and Heading content, several Image attributes (including URL and alt), Button URL and text, navigation link URLs, and Post Date.
Core sources include core/post-meta and core/pattern-overrides. WordPress 6.9 added core/post-data and core/term-data, plus a filter to extend the supported attributes. Post meta has to be registered with show_in_rest, and keys that start with an underscore can't be bound.
The API has grown each release:
- 6.6: editors can change a custom field's value directly from the connected block, blocks bound to the same field stay in sync, and editing respects the user's permissions. Synced pattern overrides also arrived in 6.6, built on bindings.
- 6.7: public editor APIs, such as
registerBlockBindingsSource, let plugins define how a custom source reads and writes values in the editor. Ablock_bindings_source_valuefilter can also adjust values on render.
In short, Block Bindings is data plumbing for block templates. The editing still happens in the block editor, on blocks.
Can they make a classic PHP theme client-editable?
Not on their own. Picture a typical agency template: page-about.php echoes a hero heading, a photo, and a CTA inside hand-written markup and Tailwind or Bootstrap classes. There's no Group block to lock and no Paragraph block to bind. To use either feature, you'd first rebuild those regions as blocks, a pattern, or a block template.
If the site is already moving to a block theme, that rebuild is worth doing, and you should use the native tools. If the theme is going to stay hand-built PHP, the rebuild is a big change made just to get an editing guardrail.
How does an inline editor on a custom theme differ?
LiveCMS starts from the template instead of the block tree. The developer wraps each region clients may change in an HTML comment, such as <!-- lcms:text hero_heading --> … <!-- /lcms -->. Logged-in Editors and Admins switch LiveCMS on from the admin bar, click a marked heading, image, or link on the live page, and save. Anything left unmarked (wrappers, grids, navigation, CSS) stays out of reach, and published content is saved in post_content.
There's no "Modify" toggle, because clients never get design tools in the first place. The trade-off is that a developer has to mark the regions in PHP, and the approach doesn't help a site built entirely from blocks. The inline content editor guide covers the full workflow.
When to use which
| Situation | Best fit | Why |
|---|---|---|
| Block theme or Full Site Editing site | contentOnly + Block Bindings | Native, free, already in the editor clients use |
| Block patterns that clients fill in | contentOnly (and pattern overrides for synced patterns) | Locks structure, keeps text and media editable |
| Block template showing custom field values | Block Bindings with core/post-meta |
Binds Paragraph, Heading, Image, or Button to registered meta |
| Classic PHP custom theme, staying classic | LiveCMS | Marks regions in the template; no blocks needed |
| Gutenberg page, clients want to edit on the front end | A block-based front-end editor | See FrontEdit vs Frontpen vs LiveCMS |
| Any theme, no-code region setup | Bindery | See Bindery vs LiveCMS |
| Marketing copy that must be searchable | LiveCMS or core content | Copy in post_content; see the ACF alternative for page copy |
The honest rule: follow the theme's architecture. Block-built sites should use the block tools. Hand-built PHP themes get more from marking regions in the template than from adding blocks just to restrict them.
FAQ
Is contentOnly locking enough to stop clients changing a layout? On block-built pages it removes most design controls: it hides design tools, locks child blocks against moving and removal, and blocks new inner blocks. Users can still switch to "Modify" from the block toolbar, and it only affects blocks, so hardcoded regions in PHP templates are untouched.
Which WordPress version added the Block Bindings API? WordPress 6.5. Version 6.6 added editing a custom field's value from its connected block and synced pattern overrides, 6.7 opened public editor APIs for custom sources, and 6.9 added the post-data and term-data sources plus a filter for extra supported attributes.
Can Block Bindings replace ACF or an inline editor on a classic theme? Not directly. Bindings connect supported block attributes to sources such as registered post meta, so they need blocks. A classic PHP template that echoes its own markup has nothing to bind until those regions are rebuilt as blocks.
Should I use contentOnly and Block Bindings on a block theme instead of LiveCMS? Yes. On block themes and Full Site Editing sites the native tools fit the editor your clients already use. LiveCMS is meant for developer-built classic PHP themes.
Where does LiveCMS store the content clients edit?
Published values are saved in post_content, so native WordPress search and SEO plugins read the same text visitors see. The developer decides which regions are editable by marking them in the template.
Get Started
If your sites run on hand-built PHP themes and you want clients editing marked regions on the live page, Get Started.