Inline Content Editor for Developer-Built WordPress Themes

Short answer: An inline content editor for a custom WordPress theme lets clients change marked text, images, and links on the live page while the developer keeps layout in PHP and CSS. LiveCMS marks those regions with HTML comments in your templates and saves published content to post_content, so no page builder or block editor is involved.

Agencies that ship custom WordPress themes hit the same handoff every time: the client needs to update a headline, swap a photo, or change a button URL, and the only safe path is a developer ticket — unless you hand them a page builder and inherit the support debt that follows. Gutenberg front-end editors assume the page is made of blocks. Structured inline editing on the live custom theme is the missing path: mark the regions clients may touch, leave layout in PHP and CSS, and let authorized users click the page they already see. See the product demo for how that looks in practice.

What “inline content editor for WordPress” usually means (and the gap)

Search for an inline or front-end content editor for WordPress and you will find several legitimate plugins. They solve a real problem — for a different kind of site than a custom-theme agency usually ships.

• FrontEdit — front-end edits without opening wp-admin, built around Gutenberg’s content model: you change what the block editor already owns.
• Frontpen — useful when the page is already assembled as editable blocks, not when the hero heading is a PHP echo inside page-about.php.
• Frontend Text Edit — a fair fit for simple copy tweaks on block or classic content. It is not a contract about which template regions exist.
• ACF Inline Editing for Blocks — ACF’s inline path for block fields. Coherent if the site is Gutenberg plus ACF. It assumes blocks. It does not mark a region in a handwritten PHP template.
• Jamie's Front-End Editor and Visual Edit Lite: more block-side options. Jamie's edits block text, links, buttons and images, with page and block locks. Visual Edit Lite targets block themes and static-HTML sites converted to WordPress, and its FAQ says the visual editor does not apply to classic PHP themes.
• Bindery: the closest in spirit. Regions are declared in code or on a settings page, on any classic or block theme, and edited values are stored in its own database table. See Bindery vs LiveCMS.

None of these tools is “wrong.” Most of them are block-centric. The gap appears when the page is a developer-built custom theme: Tailwind or Bootstrap markup, get_header() / get_footer(), and hardcoded sections that were never registered as blocks. Those template regions are the product. Clients still need to change the words, images, and links inside them. That is the workflow how LiveCMS is built to cover — a longer companion to the rest of the LiveCMS blog.

Front-end editor vs page builder vs block editor

These three phrases get used as if they were the same product. They are not.

A front-end editor (or inline editor) means the person making the change is looking at the live page. They click what visitors see. The question that matters is what they may change: a field the developer marked, or the whole layout.

A page builder (Elementor, Divi, Beaver Builder, and similar) is a design surface. Clients can add sections, move columns, and restyle components. Agencies adopt them so clients “won’t need a developer,” then inherit a second design system and tickets when a grid breaks. That pattern is the subject of Clients Don't Need Page Builders.

A block editor (Gutenberg, including Full Site Editing) is WordPress’s native composition model. Front-end Gutenberg editors and ACF inline-for-blocks sit on that model. Right choice when the site is blocks. Wrong assumption when the site is a custom PHP theme that was never meant to be rearranged in the browser.

The gap is not “WordPress has no front-end editing.” The gap is custom PHP theme template regions that should stay structurally fixed while remaining editable as content.

The custom-theme workflow agencies actually need

A healthy agency handoff looks boring on purpose. The developer owns the template, the CSS, and the list of fields. The client owns the words, the photos, and the destinations. The plugin in the middle should enforce that contract — not invite the client to become a layout engineer. Try the click-to-edit surface on the homepage demo, then use the rules below.

What clients should be allowed to change (text, images, and links)

Everyday content work on a marketing site is a short list:

• Text — headings, paragraphs, button labels, captions. A client should change “Spring sale” to “Fall sale” without opening a PHP file or guessing which ACF field name maps to the hero.
• Images — hero photos, team portraits, feature illustrations. They should pick from the Media Library or upload a replacement. The theme still decides crop, srcset, and wrapper markup.
• Links — CTA URLs, “open in new tab,” and the visible label on a button. Editors should not have to ask a developer to change href. That specific field type is walked through in How to create editable links.

If the ticket is “change the headline,” “swap the photo,” or “point the button at the new landing page,” the client should finish it on the live page.

What clients must never touch (structure, layout, and blocks)

The other half of the contract is just as important:

• Structure — section order, which components exist on the page, whether the hero is a split layout or a full-bleed banner. That is the theme.
• Layout and CSS — grid columns, spacing, type scale, breakpoints. A client who can drag padding will eventually ship a broken mobile view.
• Blocks — adding, removing, or nesting Gutenberg blocks. If the theme is not a block theme, the block inserter is not a gift; it is a second page that can contradict the first.

When clients can only edit marked regions, layout tickets drop. When they can add blocks or builder widgets, the agency maintains two designs: the one in git and the one a client assembled last Thursday. For the full agency playbook on that handoff, read how to let clients update WordPress content without breaking layout.

How LiveCMS works as a front-end content editor

This section is a skim. Architecture lives in How LiveCMS redefines the WordPress editing experience. Implementation notes are in the developer quickstart. Here is the mental model before you choose a tool.

Mark regions with HTML comments

Developers wrap existing template output in HTML comments. The comments are invisible in the browser. They name a field and a type. WordPress escaping stays in the template.

<!-- lcms:text hero_heading -->
<h1><?php echo esc_html($heading); ?></h1>
<!-- /lcms -->

<!-- lcms:image hero_image -->
<div class="hero-media">
    <img src="<?php echo esc_url($hero_image); ?>" alt="" />
</div>
<!-- /lcms -->

<!-- lcms:link cta_link -->
<a href="<?php echo esc_url($link_url); ?>">
    <?php echo esc_html($link_text); ?>
</a>
<!-- /lcms -->

lcms identifies a LiveCMS marker. text, image, and link are the field types. hero_heading, hero_image, and cta_link are names you choose. The surrounding HTML is ordinary theme code — Tailwind classes, Bootstrap utilities, or custom CSS all stay yours.

There is no ACF field-group UI to keep in sync with the template, and no Gutenberg block to register for a region that was never a block. The full type table (textarea, repeater, post picker, and the rest) is in the developer setup guide.

Clients click the live page

A logged-in user with edit_posts turns on LiveCMS from the admin bar. Marked regions highlight. The client clicks the heading they already see, edits it, and saves. The same path works for images and links. Visitors who are not logged in never see the editor. Training is: see it, click it, change it — not hunting a field named homepage_hero_v3 or guessing which block is on screen.

Content stays in post_content

Published content is written to the standard WordPress post_content column on wp_posts. That is a deliberate choice.

Yoast, Relevanssi, SearchWP, and core WP_Query already read post_content. If the same copy lived only in wp_postmeta — the ACF default — those tools would need extra filters or would miss the fields. This is not a ranking trick. It means visitors see the same content WordPress already indexes. You are not maintaining a shadow copy that SEO and search plugins cannot see. If ACF is the tool you are replacing for marketing copy, the ACF alternative for page copy guide walks through that trade-off.

Drafts and crash recovery use JSON files in the theme, so the work is git-friendly across local, staging, and production. The published source of truth is still post_content. More on that split is in how it works.

Drafts, versions, and rollback

JSON drafts cover a crashed tab. Version snapshots cover yesterday’s better headline.

Core LiveCMS includes inline editing, JSON drafts, and publishing into the database. Pro adds unlimited versions, visual diff, rollback, and multi-editor tracking — that is the Pro line as it stands.

If version history is the evaluation criterion, read Your Content, Any Version: Instant Restore. Restore happens on the page you are already editing.

When to use LiveCMS vs Gutenberg front-end editors vs ACF

Use the site you are actually building.

Choose a Gutenberg front-end editor (FrontEdit, Frontpen, Frontend Text Edit, or a similar block-aware tool) when the page is Gutenberg, the client already knows the inserter, and you want them to edit those blocks without opening wp-admin. That is a coherent stack. Do not wrap the same page in a second field system. For a side-by-side of the two most common block-aware options, see FrontEdit vs Frontpen vs LiveCMS.

Choose ACF (including ACF Inline Editing for Blocks) when you already run ACF field groups and Gutenberg or ACF blocks, and you want editors closer to the canvas. Accept the trade: field data lives in wp_postmeta unless you have built a custom save path, so native search and some SEO tools will not see those strings unless you wire them through. ACF remains a strong fit for structured admin forms and relationship fields.

Choose LiveCMS when all of the following are true:

• The theme is developer-built PHP (custom templates, not a page-builder kit).
• Clients need to change text, images, and links — not add sections.
• You want published copy in post_content so core search, Yoast, Relevanssi, and SearchWP read the same page visitors see.
• You do not want an ACF field group or a Gutenberg block for every hero, feature row, and CTA.
• Layout and CSS should stay in git, editable only by developers.

Stay on wp-admin when two editors already know the dashboard and you have no retainer pain. Do not add a front-end layer for sport.

On a hybrid theme, mark PHP regions with LiveCMS and leave block templates on Gutenberg. The tools can coexist if you do not ask either one to own the other’s content model.

Why not contentOnly locking or Block Bindings?

They are the right first choice when the site is built from blocks: both are native WordPress features and cost nothing. But both work on blocks inside the block editor. Neither one can turn a hardcoded PHP template region, such as an echo inside page-about.php, into something a client can edit on the live page.

contentOnly editing has been in core since WordPress 6.1. Set "templateLock":"contentOnly" on a container or pattern and WordPress hides the design tools, hides non-content child blocks, and stops most new inner blocks from being added. In WordPress 7.0 it became the default for unsynced patterns and template parts. It is an editing mode, not a permission, though: a user can still click "Edit pattern" on an unsynced pattern and get full editing. And there's no UI to manage content locking; it's set in code.

Block Bindings (WordPress 6.5+) connect block attributes to a data source: post meta, post data, term data, pattern overrides, or a source you register. By default the supported attributes are a short list: Paragraph and Heading content, Image, Button, navigation links and Post Date. A filter added in 6.9 extends that list, and 7.1 added List Item. It's plumbing for block templates, not a front-end editor.

Option	Works on	Where the client edits	Stops layout changes?	Where the content lives
contentOnly editing	Block patterns, template parts, containers	Block editor	Hides design tools; unsynced patterns can be reopened with "Edit pattern"	Block markup
Block Bindings	Supported block attributes	Block editor	Not a locking feature	The bound source (e.g. post meta)
FrontEdit / Frontpen / Jamie's	Gutenberg blocks	Live page	Edits existing blocks	post_content
Bindery	Any classic or block theme	Live page	Declared regions only	Its own table (wp_bindery_values)
LiveCMS	Custom PHP templates	Live page	Marked regions only	post_content and post meta

If you are moving the site to a block theme, use the native tools. If the theme stays hand-built PHP, mark the regions instead. The full comparison is in Gutenberg contentOnly & Block Bindings vs an inline editor.

Setup path for agencies

This is the agency path, not the full tutorial. The complete markup reference, REST endpoints, and template examples live in the developer quickstart.

1. Confirm the theme is a normal WordPress theme. Templates should call wp_head() and wp_footer() (or get_header() / get_footer(), which fire those hooks). LiveCMS loads through those hooks. WordPress 6.0+ and PHP 7.4+ are the stated requirements.
2. Install the plugin ZIP like any other WordPress plugin. There is no external API key and no front-end build step for the editor itself.
3. Pick one page and mark the client-facing regions. Start with a heading (text), a photo (image), and a CTA (link). Use the comment pattern in the section above. Leave navigation, decorative SVGs, and layout wrappers unmarked.
4. Log in as an Editor or Admin, view the page, and toggle LiveCMS in the admin bar. Confirm the regions highlight and that a save updates the live output.
5. Walk the client through one edit. Headline, image, link. That is the training. Then point them at the homepage if they want to try the same interaction on the public demo.
6. Decide core vs Pro only after the handoff works. Add unlimited versions, visual diff, rollback, and multi-editor tracking when the team needs them — not before the first three fields ship.

If an AI coding agent writes your templates, the plugin ships an optional skill that wraps regions with the right comments. A developer can also mark a template by hand in a few minutes. This section is not a substitute for the setup post.

FAQ

What is an inline content editor for WordPress on a custom theme? An inline (or front-end) content editor for a custom WordPress theme lets authorized users change text, images, and links directly on the live page while the developer keeps full control of layout and CSS. Unlike Gutenberg front-end editors that update block markup, a structured tool such as LiveCMS marks editable regions in PHP templates with HTML comments and saves published content into post_content, so clients update what visitors see without opening a page builder or the block editor.

How is LiveCMS different from FrontEdit, Frontpen, or other WordPress frontend editor plugins? Most WordPress frontend editor plugins are built for Gutenberg. They let you change block content on the front end because the page is already a tree of blocks. LiveCMS targets developer-built custom themes: PHP templates, hardcoded sections, and CSS the agency owns. You mark regions with HTML comments, clients click those regions on the live page, and published content lands in post_content instead of a parallel field store. FrontEdit, Frontpen, Frontend Text Edit, and ACF Inline Editing for Blocks remain reasonable choices when the site is blocks-first. LiveCMS is the choice when the site is a custom theme and the client must not become a layout editor. (LiveCMS is not a Learning Content Management System — the “LCMS” abbreviation in e-learning refers to a different category of product.)

How do you let clients update website content without breaking a custom WordPress layout? Keep layout in the theme. Developers decide which elements are editable and wrap those elements in HTML comment markers (<!-- lcms:text … --> … <!-- /lcms -->). Clients change only the marked text, images, and links. They cannot add blocks, drag sections, or edit CSS. Published values save into post_content, so the live page, WordPress search, and tools such as Yoast, Relevanssi, and SearchWP all read the same output. Structure stays in git. Content stays in WordPress.

Is WordPress contentOnly locking enough to stop clients breaking a custom theme? Only if the pages are built from blocks. contentOnly editing hides design tools inside block patterns, template parts and containers, and it's the default for unsynced patterns since WordPress 7.0. But it's an editing mode, not a permission: users can still open an unsynced pattern with "Edit pattern". It also doesn't touch hardcoded regions in PHP templates. Those regions need a tool that marks them in the template.

Can the Block Bindings API replace a front-end editor on a custom PHP theme? No. Block Bindings connect block attributes, such as a Paragraph's content or an Image's URL, to sources like post meta. That's useful in block templates, and editing still happens in the block editor. A PHP template that echoes its own markup has no blocks to bind, so clients still need marked regions to edit that copy on the live page.

Is LiveCMS a WordPress live editor? Yes, for developer-built themes. LiveCMS works as a WordPress live editor: logged-in Editors and Admins toggle it from the admin bar, click a marked heading, image, or link on the live front end, and save. Only the regions the developer marked are editable, and published content is stored in post_content.

Related guides

• ACF Alternative for Page Copy: Keep Content in post_content — Looking for an ACF alternative for marketing page copy? Keep headlines, body text, and CTAs in searchable post_content — not wp_postmeta — with LiveCMS on custom WordPress themes.
• How to Let Clients Update WordPress Content Without Breaking Layout — Give clients a way to change headlines, photos, and links on a custom WordPress theme without opening the layout. Mark the fields. Leave the grid alone.
• FrontEdit vs Frontpen vs LiveCMS — FrontEdit, Frontpen, Jamie's and Visual Edit Lite edit blocks or block themes live. LiveCMS edits developer-marked regions on custom PHP themes.
• Bindery vs LiveCMS: Two Ways to Make Custom-Theme Regions Client-Editable — Bindery and LiveCMS both let clients edit only the regions you allow, on the live page. They differ in setup, where edits are stored, and theme fit.

Try it, then ship it

Request access and get the plugin from Get Started on the homepage or Get Started on the product page. Both buttons open the same form. Use it for free core install access and for Pro interest — Pro adds unlimited versions, visual diff, rollback, and multi-editor tracking. There is no public download; Get Started is how you request the plugin.

Ask questions in Discord, or continue with the rest of the blog.