ETBS Edit Conflict Guard

Description

WordPress already tells you when someone else is editing a post: the “currently editing” notice under the post title. That notice is only a warning, though. It does not stop the second editor from clicking Update or Publish, and it does not stop the save. If two people edit the same post around the same time, whoever saves last silently overwrites the other person’s changes, and nothing in WordPress core prevents that.

ETBS Edit Conflict Guard adds a real, per-post exclusive lock on top of that notice. While one user has a post open for editing, it blocks every other user from saving it, and it tells them clearly why.

How it works

• Opening a post’s edit screen tries to acquire a lock on that post (first person to open it gets the lock).
• While the edit screen stays open, the lock is automatically extended through the standard WordPress Heartbeat API.
• Clicking Save Draft, Update, or Publish (Classic Editor or Block Editor) checks the lock. If someone else holds it, the save is blocked and a modal explains why.
• The lock is released automatically when the save succeeds, or when Heartbeat stops (for example the tab is closed) and the lock’s expiration time passes.
• The block is enforced on the server as well, on the Classic Editor’s post save and the Block Editor’s REST save, so the lock still holds even with JavaScript disabled or the connection unreliable.

All post types that have an admin UI are covered by default (attachments are excluded); any of them can be excluded from the Settings screen. The lock check only runs at the moment Save/Update/Publish is clicked — simply opening the edit screen shows nothing extra.

Settings

Under Settings > Edit Conflict Guard:

• Lock expiration, in seconds.
• Post types to exclude from locking.
• Whether moving a locked post to trash is also blocked (off by default; when on, any move-to-trash of a locked post is blocked, even from the lock holder’s own other tab — force delete is not affected).
• A live table of every post currently locked, with a per-row Force Release button for administrators.

Known limitations

Edit Conflict Guard is intentionally strict and, as a result, has a few rough edges worth knowing about up front:

1. Block Editor trash notice. When the “Move to trash” action is blocked, the server correctly rejects it (the post stays published), but the Block Editor itself may briefly show a “Moved to trash” success notice anyway. This is WordPress core’s own optimistic UI, not a lock failure — reloading the post list confirms the post was never actually moved.
2. Bulk trash actions. If the trash guard is enabled and a bulk “Move to Trash” action from the post list includes a locked post, processing stops at that post; posts later in the batch are left unprocessed.
3. Permanent deletion bypasses the trash guard. The trash guard only covers moves to the trash. A permanent delete that skips the trash entirely — for example wp.deletePost over XML-RPC on a custom post type, which WordPress core deletes outright instead of trashing — is not blocked, even while the post is locked.
4. No Multisite support. Locks are not aware of, or shared across, sites in a Multisite network.
5. Locks apply to the holder too. By design, even the user who holds the lock is blocked from saving the same post from a second tab or window. This is deliberate, not a bug — the plugin cannot tell two tabs from two different editors.