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 (including another edit screen of the same account) holds it, the save is blocked and a modal explains why.
The lock is released when you leave the edit screen, or when Heartbeat stops (for example the tab is closed) and the lock’s expiration time passes. A Classic Editor save also releases it, because the screen reloads. A Block Editor save keeps it, because you keep editing in the same tab.
Autosaves neither take nor release the lock, and the lock never blocks them.
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.
In the Classic Editor, WordPress’s own “currently editing” dialog no longer offers “Take over” while this plugin holds the lock for another account, because taking over would not move this plugin’s lock. The dialog says who is protecting the post instead.

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 runs at the moment Save/Update/Publish is clicked. Opening the edit screen shows nothing extra, except a notice when the same account already has the post open in another edit screen.

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:

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.
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.
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.
No Multisite support. Locks are not aware of, or shared across, sites in a Multisite network.
Locks apply to the holder too. By design, even the account that holds the lock is blocked from saving the same post from a second tab, window or device. This is deliberate, not a bug. The plugin can tell the lock is held by the same account, but a matching account does not prove it is the same person (accounts are sometimes shared), so both are treated the same way. The message says “the same account” for that reason.
Autosave is not blocked. WordPress core usually keeps an autosave away from the post itself by storing it as a separate, per-user revision. Two cases are different: a draft’s own author autosaving that draft, and one account having the same draft open in two tabs. There, the autosave writes to the draft directly, so it can overwrite what someone else saved — including while this plugin’s lock is held by another user. WordPress 7.0 and later narrows this by checking WordPress’s own edit lock first; earlier versions do not check it at all. The notice shown when a second tab opens asks you not to keep editing there, which avoids the two-tab case.
Block Editor “Take over” button. WordPress’s own “Take over” button in the Block Editor cannot be removed by a plugin. Taking over moves WordPress’s lock but not this plugin’s, so saving stays blocked until the other editor closes their screen or an administrator force-releases the lock.
Saves made without WP_ADMIN defined are not blocked. WP-Cron, WP-CLI, XML-RPC and front-end code that calls wp_update_post() directly are let through, because they cannot show a message and would otherwise fail on visitors’ screens. Note that admin-post.php and admin-ajax.php define WP_ADMIN themselves, so a front-end form that posts to either one is still blocked while the sender is logged in. A save made by a logged-out visitor is let through even there, because a logged-out request is exempt as well. Saves through the REST API and the admin screens (including Quick Edit and bulk edit) are still checked.