When I built Jamie's Front-End Editor for Content Teams, the idea was simple: let a client fix the words on their live site by clicking the text and typing, without ever opening the block editor or learning WordPress. No dashboard, no interface, just edit the page in front of you.
The idea landed. But the moment real agencies started testing it with real clients, the feedback got sharper and more useful, and the last two releases are almost entirely a response to it. Here's what shipped.
Locking: the feature that made it usable for client work (0.3)
The single most requested thing was control. Letting a content team edit copy is wonderful, right up until someone rewrites your call to action or deletes the one sentence the whole page depends on. An agency needs to hand over the parts that should change and fence off the parts that shouldn't.
So 0.3 added editing locks, and there are two levels.
You can lock a whole page. Open it in the editor, tick "Lock this page" in the Front-End Editing box, and the front-end editor simply won't appear there. Done.
Or you can lock a single block or section. Select any block, a Group that wraps a hero or a pricing table, say, open its Lock option (the padlock in the block's menu), and that block plus everything nested inside it becomes read-only on the front end. If you prefer, you can add the CSS class fie-no-edit to a block instead. Either way, the lock cascades to everything inside.
The important detail: these locks are enforced when content is saved, not just hidden in the interface. A locked block or page can't be edited even by poking at the API directly. Locked means locked.
That one release moved the plugin from "copywriters fixing typos" to something you can actually hand to a client with confidence.
Safer, sturdier editing (0.4)
The next round came straight out of the support threads, and it's about trust.
The most important one is concurrent editing. Previously, if two people edited the same page at once, the last one to save quietly won and the other person's work vanished. That is exactly the kind of thing that erodes a team's confidence in a tool. Now the front-end editor takes WordPress's own post lock, so two people, whether on the front end or in the block editor, can no longer stand on each other. Anyone else who opens the page sees a clear "so-and-so is currently editing this page" notice, and as a backstop the save is rejected if the content changed underneath the editor. Nobody loses work silently anymore.
I also fixed a genuinely annoying bug: pressing Enter while editing could insert invalid markup and trigger a "block validation" error in the editor, which then stripped the change. Line breaks now save cleanly.
You choose which blocks are editable, including third-party ones
This is the big one, and it changes what the plugin can do.
Until now, front-end editing was limited to a handful of built-in blocks: paragraph, heading, and a few others. That was fine for basic copy, but most real sites aren't built from core blocks alone. They use a page builder or a block library, and the headings, text and buttons people actually want to edit belong to those.
So 0.4 lets you decide which blocks are editable, and that list now includes blocks from your theme and your plugins. There's an advanced setting where you pick exactly what you want to turn on, so you can point the editor at, say, Kadence's Advanced Heading and let your content team edit it directly on the page, the same way they would a core heading.
That is a real shift. It means the plugin can slot into a site that was built with Kadence, or another block library, or your own custom blocks, instead of only working on plain WordPress content. You stay in control of the scope, you turn on only what makes sense, and it fails safe on anything that isn't compatible, so nothing breaks.
Every fix came from a user
I want to be honest that almost none of this came from me sitting in a room being clever. It came from people testing the plugin, hitting a wall, and taking the time to write it up properly. The locking, the concurrency safety, the block bug, the wider block support, all of it started as a review or a support post. That is the quiet magic of building in the open on WordPress.org: a stranger makes your software better and everybody wins.
What's next
The plugin is still deliberately focused. It edits content in place, and it isn't trying to be a page builder. But there's obvious polish coming. Next up is editing links, not just link text, so someone can fix a wrong URL without touching code, along with a friendlier way to choose which blocks are editable.
If you're using it and something feels rough or missing, tell me. That feedback is genuinely steering the whole thing.
Leave a Reply