Linux 软件免费装
Banner图

ETBS Edit Conflict Guard

开发者 etbsjp
更新时间 2026年10月2日 07:29
捐献地址: 去捐款
PHP版本: 7.4 及以上
WordPress版本: 7.1
版权: GPLv2 or later
版权网址: 版权信息

标签

editorial workflow post lock multi author concurrent editing save conflict

下载

1.1.1 1.1.0 1.2.0 1.2.1

详情介绍:

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 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: 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 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.
  6. 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.
  7. 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.
  8. 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.

安装:

  1. Upload the plugin files to the /wp-content/plugins/etbs-edit-conflict-guard directory, or install the plugin directly through the WordPress plugins screen.
  2. Activate the plugin through the "Plugins" screen in WordPress.
  3. Go to Settings > Edit Conflict Guard to review the lock expiration, excluded post types, and trash guard option.

屏幕截图:

  • The "Currently Locked Posts" table on the settings screen, listing each locked post with its editor, lock time, expiration, and a Force Release button.
  • The save-blocked modal shown in the Classic Editor when another user already holds the lock on the post being saved.
  • The save-blocked modal shown in the Block Editor (Gutenberg) when another user already holds the lock on the post being saved.
  • The support links as they appear on the Plugins list row and in the footer of the Settings > Edit Conflict Guard screen.
  • The notice shown on a second edit screen when the same account already has the post open elsewhere, saying that this screen cannot save.
  • Core's post-locked dialog in the Classic Editor, with Edit Conflict Guard's explanation added and the "Take over" button removed.

升级注意事项:

1.2.1 Fixes meta box fields (SEO plugins, custom fields and similar panels) silently not being saved in the Block Editor since 1.2.0. Please update, then re-enter anything that was lost. 1.2.0 Fixes the lock being released by an autosave or a Block Editor save, which left posts unprotected without any warning. Also clearer messages when a second tab of the same account blocks a save. 1.0.3 Uninstalling in earlier versions deleted your saved lock-expiration and excluded-post-type settings. Update to keep your settings when uninstalling.

常见问题:

How is this different from the "Someone else is editing this" notice WordPress already shows?

That built-in notice is informational only; it does not stop a second user from saving. This plugin adds an actual block: if someone else holds the lock, clicking Save/Update/Publish is refused and the user sees a modal explaining why (in Quick Edit the same reason appears inline instead), rather than silently overwriting the other person's changes.

A lock seems stuck. How do I clear it?

Locks release automatically once their expiration time (set under Settings > Edit Conflict Guard) passes without the holder's edit screen sending a Heartbeat, for example if their browser tab was closed without saving. If you need it cleared immediately, an administrator can open Settings > Edit Conflict Guard and use the Force Release button next to that post in the "Currently Locked Posts" table.

Does this plugin work on Multisite?

Not currently. Locks are per-site; there is no cross-site awareness in a Multisite network.

I blocked a trash action, but the screen still said "Moved to trash". Did it fail?

No — the post was not moved. This happens only in the Block Editor: WordPress core shows an optimistic success notice before the server response arrives, and the server has already rejected the request. Reloading the post list will show the post still in its original status.

Can the person who holds the lock still lock themselves out?

Yes, deliberately. If the same account opens the same post in a second tab, window or device, the second one is blocked from saving just like any other user would be. The plugin can tell the two belong to the same account, but that does not prove it is the same person, so it applies the same rule to everyone. Close the other edit screen and save again.

更新日志:

1.2.1 1.2.0 1.1.1 1.1.0 1.0.3 1.0.2 1.0.1 1.0.0