← Back to Blog

How to Let Clients Update WordPress Content Without Breaking Layout

The ticket is almost always the same: change the headline, swap a photo, point the button at a new page. The client can do that — if the theme lets them touch content and not layout.

Most “let the client edit” setups do the opposite. Elementor, Divi, or Full Site Editing hands them a canvas. Block-role plugins lock Gutenberg in wp-admin. Neither matches a custom PHP theme that was designed to stay put.

This is the agency handoff for that site: clients update website content on the live page. Developers keep the grid.

What “breaking layout” actually means

Layout breaks when someone can add, move, or restyle structure:

Copy changes do not break layout. A new H1 in the same heading slot does not. A replaced image in the same wrapper does not.

If the client can only edit marked text, images, and links, the design in git stays the design on the live site. That is the contract. (We already argued the page-builder version of this in Clients Don't Need Page Builders.)

The usual options — and why they miss

Give them a page builder. Fast handoff. Then you maintain two designs: the one you shipped, and the one they assembled last Thursday.

Lock Gutenberg with Editor Access, Block Editor Roles, or Multigovernance. Useful if the site is blocks. It does not help a page-about.php hero that was never a block.

Park copy in ACF and send them to wp-admin field names. Safer than Elementor. Still disconnected from the live page — and marketing copy in postmeta is a search problem of its own (ACF alternative for page copy).

Gutenberg front-end editors (FrontEdit, Frontpen, and similar). Fine when the page is already blocks. They do not mark regions in a handwritten PHP template.

None of these is “wrong.” They solve a different site.

The contract that works on custom themes

  1. Developer owns structure. Section order, CSS, which components exist.
  2. Client owns words, photos, and destinations. Headlines, body, images, button URLs.
  3. The plugin in the middle enforces that. No inserter. No drag-to-resize. Only marked regions.

On a Live CMS theme that looks like HTML comments in the template:

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

The client clicks the heading on the live page, types, publishes. They never see a field group named homepage_hero_v3. Setup is in the developer quickstart; the longer product story is the inline content editor pillar.

A short handoff checklist

Before you give a client the keys:

Do that once and the “can you just…?” queue shrinks. You are not training them to be layout engineers.

FAQ

How do I let clients edit WordPress without breaking the design? Only expose content: text, images, and links the developer marked. Do not give clients a page builder, the block inserter, or theme files. On a custom PHP theme, that means front-end regions in the template — not a second design tool.

Is locking Gutenberg enough? If the site is built from blocks, role and lock plugins help. If the site is a classic or custom PHP theme, locking the block editor does not create editable template regions. You still need a content surface that matches the theme.

Where should clients make the change? On the live (or staging) page they already see. Click the headline, change it, publish. Admin field UIs work for data records. They are a poor map for “the words in the hero.”

Get Started

If this is the handoff you want — clients update content, layout stays in the theme — Get Started on the homepage. The product demo shows the click-to-edit surface.

More context: how Live CMS works and the rest of the blog.