jamiemarsland

Thank you for this, and for the clear replication steps. You were completely right, and this was the most important thing to get sorted, so I appreciate you taking the time to lay it out.

This is fixed as of version 0.4, which is now available. Front-end editing now takes WordPress’s own post lock, so it and the block editor share the same lock. If someone is already editing a page, anyone else who opens it (on the front end or in the back end) sees a clear “so-and-so is currently editing this page” notice and the content is read-only for them until it’s released. As a backstop, if the content did change underneath an editor somehow, the save is now rejected with a “reload to see the latest” message rather than silently overwriting the other person’s work. So the last-save-wins behaviour you described is gone from both directions.

Please update to 0.4 and it should behave the way you’d expect. Thank you again for the report. It genuinely shaped the release.

Thank you, this is great to hear. And thanks for pointing out the Metabox custom post type compatibility, that’s really useful for others to know. You’re spot on about the block note too: the plugin edits block markup, so a post created the classic way needs converting to blocks first for it to take effect.

Worth a heads-up: a 0.4 update is landing shortly with some meaningful improvements. Safer concurrent editing (two people can no longer overwrite each other), a fix for a line-break bug that could invalidate a block, and a new setting to enable editing on additional block types beyond the defaults. Thanks again for the kind words and the helpful detail.

Thank you, Alessio, this is kind, and your suggestion is the reason it now exists.

You asked for a way to lock editing of a whole page or the content inside a specific container, and that’s live as of version 0.3. There are two ways to use it:

To lock a whole page, tick “Lock this page” in the new Front-End Editing box when you’re editing the page. To lock just one section, select the block (a Group that wraps a section, say), open its Lock option (the padlock in the block’s Options menu), and that block plus everything inside it becomes read-only on the front end. You can also add the CSS class fie-no-edit to a block if you prefer.

The locks are enforced when saving, not just hidden in the interface, so they hold up properly. Update to 0.3 and you should have exactly the finesse you were after. Thank you again for the nudge. It made the plugin better, and there’s more coming.

Thank you, genuinely. This is exactly the kind of feedback that makes a plugin better, and I appreciate you taking the time to test it properly and write it all up rather than just leaving a rating.

First, the two issues you posted in the support thread: you were right on both, and they’re fixed in the upcoming 0.4 (releasing on 15th July). The concurrent-editing one was the serious one. It will use WordPress’s own post lock, so two people (front end or block editor) can’t overwrite each other, with a save-time conflict check as a backstop. The “block validation” error from pressing Enter is fixed too. Line breaks now save cleanly.

On the bigger point, that the editing scope is too strict, that’s fair and I won’t be defensive about it. A few things have already moved: 0.3 added the ability to lock whole pages or individual sections, and 0.4 lets you enable additional block types yourself, including third-party ones like Kadence. Editing the link itself, not just the link text, is a real gap and it’s on my list. Moving and adding blocks is a deliberate line I’ve drawn for now, but I hear you that the boundary can confuse the very people this is for.

On “a solution in search of a problem,” that’s the critique I think about most, so I want to answer it properly. The distinction I’m chasing is narrow but I believe real: this is for the client who will never open wp-admin or Gutenberg at all. Not an editor-role user with a streamlined admin, but someone editing the words directly on the live page, in context, with no interface to learn. For a lot of small-business clients that difference is the whole point. But you’re right that if a client is comfortable in the block editor, Gutenberg’s own content-locking is the better fit, and I’d happily point them there.

So: early days, and aimed at a specific person rather than everyone. Thank you for keeping an eye on it. Feedback like this is genuinely shaping where it goes.