WordPress post locking, explained

WordPress post locking is designed to stop two people from editing the same post at the same time without realizing it.

If one editor opens a post and another editor tries to work on that same post, WordPress can detect the existing editing session and warn the second user.

The system helps prevent a familiar collaborative-editing problem:

Editor A opens a post
↓
Editor B opens the same post
↓
both make different changes
↓
one person saves
↓
the other person saves later
↓
someone's work is overwritten

WordPress reduces that risk through a combination of:

• post locks;
• the Heartbeat API;
• autosaves;
• per-user autosave revisions;
• editing-session checks;
• takeover controls.

Post locking is therefore not an isolated feature. It is part of WordPress’s broader editing and collaboration system.

This guide explains how WordPress post locking works, where the lock is stored, how long it lasts, how Heartbeat keeps it fresh, what happens when another editor opens the post, how takeover works and why disabling or heavily throttling Heartbeat can affect collaborative editing.

What is WordPress post locking?

WordPress post locking is a mechanism that records which authenticated user is currently editing a post.

Core provides the wp_set_post_lock() function to mark a post as being edited by the current user.

Conceptually:

User 17 opens Post 482
↓
WordPress records:
timestamp + user 17
↓
another editor opens Post 482
↓
WordPress checks the existing lock

If the lock is still considered active and belongs to another user, WordPress can treat the post as currently being edited elsewhere.

Why does WordPress need post locking?

Traditional WordPress editing is not the same as a real-time collaborative document system where several users continuously merge changes into one shared document.

Without coordination, two people editing the same post can create conflicting versions.

Imagine this sequence:

10:00
Sarah opens article

10:02
Michael opens same article

10:10
Sarah saves revision A

10:13
Michael saves revision B
based on older content

Michael may unintentionally replace changes Sarah made after he opened the editor.

Post locking reduces the likelihood of that situation by telling editors that someone else already has an active editing session.

Post locking is not the same as file locking

The term “lock” can sound more absolute than the mechanism actually is.

WordPress is not locking a physical PHP file or database table.

It is maintaining editing-state information associated with a WordPress post.

The relevant state says, approximately:

this post was recently being edited
by this user

WordPress can then use that information when deciding how another editing session should behave.

Where does WordPress store the post lock?

WordPress stores the editing lock in post metadata using the key:

_edit_lock

The current wp_set_post_lock() implementation builds the value from:

• the current Unix timestamp;
• the current user’s WordPress user ID.

The stored value is structured approximately like:

timestamp:user_id

For example:

1788422400:17

This means WordPress has enough information to determine:

• when the lock was last refreshed;
• which user owns the lock.

What is _edit_last?

You may also encounter another WordPress post-meta value:

_edit_last

This records information related to the user who last edited the post.

It is not the same thing as:

_edit_lock

The distinction is important:

_edit_lock
→ current/recent editing session

_edit_last
→ last editor information

Core can use _edit_last as a fallback when interpreting older lock data that does not contain a user ID.

How WordPress checks whether a post is locked

WordPress provides:

wp_check_post_lock()

The official wp_check_post_lock() documentation describes it as determining whether a post is currently being edited by another user.

The check essentially evaluates:

• whether the post exists;
• whether an _edit_lock value exists;
• whether the user recorded in that lock exists;
• whether the lock timestamp is recent enough;
• whether the lock belongs to someone other than the current user.

A post is not considered locked against its own editor

Suppose:

User 17
owns current lock

and:

User 17
asks WordPress whether post is locked

WordPress does not treat that user as being blocked by their own lock.

The important conflict is:

current user
≠
user holding active lock

How long does a WordPress post lock last?

Current WordPress Core uses a default lock-check window of:

150 seconds

or:

2 minutes 30 seconds

This value appears in the current wp_check_post_lock() implementation.

The logic compares the lock timestamp against the current time.

Conceptually:

lock timestamp
>
current time - 150 seconds

→ lock is recent

If the recorded editing activity is older than the permitted window, WordPress no longer treats that metadata as an active lock for another user.

The 150-second value can be filtered

WordPress exposes:

wp_check_post_lock_window

which allows developers or plugins to change the lock window.

This means the exact duration on a particular WordPress installation may differ from the Core default.

Therefore:

150 seconds
=
WordPress Core default

not:

an unchangeable universal rule

A lock is meant to be refreshed

The existence of a timeout does not mean an editor normally loses the lock every 150 seconds while actively working.

The editing session periodically refreshes its state.

This is where the WordPress Heartbeat API becomes important.

How the Heartbeat API relates to post locking

The WordPress Heartbeat API provides periodic communication between the browser and WordPress while an administration page remains open.

The official WordPress Heartbeat API documentation describes it as a polling API that sends periodic requests between the browser and server.

Heartbeat can support features such as:

• post-lock refreshes;
• autosaves;
• session-related checks;
• other near-real-time administrative updates.

For a broader explanation, see The WordPress Heartbeat API, explained.

Heartbeat helps WordPress know an editor is still active

Imagine an editor opens a post and works on it for 45 minutes.

The original lock timestamp cannot simply remain unchanged for the entire session.

If it did, the lock would eventually look stale.

Instead, WordPress can refresh the editing lock while the user continues working.

Conceptually:

open editor
↓
lock created
↓
Heartbeat request
↓
lock refreshed
↓
Heartbeat request
↓
lock refreshed
↓
editor remains active

WordPress has a dedicated lock-refresh function

Core includes:

wp_refresh_post_lock()

The WordPress code reference describes this function as checking the lock status on the New/Edit Post screen and refreshing the lock.

This is a major reason WordPress post locking and Heartbeat should be discussed together.

What happens when another user opens a locked post?

Suppose Sarah is editing a page.

Michael opens the same page while Sarah’s lock is still active.

WordPress can detect:

Post 482
locked by User Sarah

and display a notice or lock dialog indicating that another user is currently editing the content.

Core includes the _admin_notice_post_locked() function for displaying the relevant editing-state interface.

The lock dialog identifies the other editor

Instead of returning a generic:

Post locked.

WordPress can identify the user associated with the current lock.

This makes the warning more useful in editorial workflows.

An editor can understand that:

Sarah is editing this post

rather than assuming the site is malfunctioning.

WordPress supports taking over a post

An existing editing lock is not necessarily permanent or impossible to override.

Core’s locked-post interface can offer a:

Take over

action.

If the second editor chooses to take over the post, the editing control can move to that user.

What happens to the first editor after a takeover?

Once another user takes over the post, the first editing session can detect that its lock has been lost.

WordPress includes a specific interface for this situation.

Core’s locked-post code contains a message indicating that the previous editor’s latest changes can be saved as a revision.

This helps reduce the risk that work simply disappears when control changes between editors.

Takeover can be disabled by developers

WordPress exposes the:

override_post_lock

filter.

The official locked-post implementation allows plugins to prevent users from overriding the current post lock.

Therefore the presence of a:

Take over

button can depend on the site’s configuration.

The lock dialog itself can also be filtered

Core exposes:

show_post_locked_dialog

which allows developers to control whether the normal locked-post dialog should be displayed.

There are also actions available around both:

• the locked-post dialog;
• the lost-lock dialog.

This allows editorial-workflow plugins to extend the native behavior.

Post locking does not mean two users can never open the same content

It is better to think of post locking as:

editing coordination

rather than:

absolute database exclusion

WordPress uses the lock to coordinate editor behavior and reduce accidental conflicts.

Other processes can still:

• read the post;
• display it on the frontend;
• query it through WordPress APIs;
• perform operations permitted by Core or plugins.

Post locking is not a publishing permission

Whether somebody is allowed to edit a post is ultimately a capability question.

For example, WordPress may use:

current_user_can( 'edit_post', $post_id )

to determine whether a user has permission to edit the content.

Post locking answers a different question:

Is another editor
currently working on this post?

Capabilities answer:

Is this user allowed
to edit this post at all?

Post locking and autosave are related but different

WordPress autosave protects unsaved editing work.

Post locking coordinates simultaneous editors.

They solve different problems:

Post locking
→ avoid conflicting editors

Autosave
→ preserve ongoing edits

However, the two systems interact closely.

Heartbeat also powers autosave behavior

WordPress includes:

heartbeat_autosave()

The official heartbeat_autosave() documentation describes it as performing an autosave through Heartbeat.

This means Heartbeat can simultaneously participate in:

editing-session coordination
+
content preservation

Autosaves can become per-user revisions

When WordPress cannot safely update the original draft directly, autosave data can be stored as a special revision for the current user.

The wp_autosave() function documents this behavior.

For non-drafts or another user’s draft, WordPress can create a per-user autosave rather than simply overwrite the original post.

The Block Editor also uses autosave endpoints

Modern WordPress editing is not limited to the older admin-AJAX autosave path.

The Block Editor can interact with autosave data through the REST API.

The current WP_REST_Autosaves_Controller::create_item() implementation explicitly checks the post lock before deciding whether an author’s draft can be updated directly.

If the active editing circumstances do not allow that direct update, WordPress can create an autosave revision instead.

Post locking and revisions are not the same feature

A revision is a stored historical version of content.

A post lock is current editing-state metadata.

Think of them like this:

lock
→ who is editing now?

revision
→ what did the content
look like at an earlier point?

See How WordPress post revisions work for the revision system itself.

Why revisions matter during editing conflicts

If control of a post changes between users, retaining alternative versions can provide a recovery path.

This is particularly important when:

• two editors had the same content open;
• one user takes over;
• an autosave exists;
• content changed during an editing conflict.

Post locking attempts to prevent the conflict.

Autosaves and revisions help reduce the damage when overlapping editing still occurs.

What happens if an editor closes the browser?

If the editor leaves the page, Heartbeat no longer continues refreshing the lock indefinitely.

The stored _edit_lock value may remain in the database for a while, but its timestamp eventually becomes too old to qualify as an active lock.

This is why WordPress does not require every editing session to explicitly delete the metadata before anybody else can edit the post.

The timestamp itself allows stale locks to expire logically.

What happens if the editor loses internet connectivity?

If Heartbeat requests stop reaching the server, the lock may stop being refreshed.

Eventually another user may no longer see the editing session as active.

Meanwhile, the disconnected editor may still have unsaved changes in their browser.

This is one reason collaborative editing should not rely on the lock system alone as an organizational workflow.

Teams should still communicate when several people work on the same important content.

Why does WordPress sometimes say a post is locked when nobody is editing it?

A stale-looking lock can happen for several reasons.

The other editor only recently left

The lock window may not have expired yet.

The browser closed unexpectedly

The last lock remains recorded until it becomes old enough to be ignored.

Heartbeat is delayed

Slow requests or server load can affect the timing of editing-state updates.

A plugin changes the lock window

The site’s effective timeout may differ from WordPress Core’s default.

Custom editorial software modifies locking behavior

Plugins can hook into several parts of the locking system.

The post lock is intentionally temporary

A permanent lock would create a serious usability problem.

Imagine:

editor opens page
↓
browser crashes
↓
permanent lock remains
↓
nobody can edit again

The time-based system avoids this by treating sufficiently old locks as inactive.

Post locks can appear in the Posts screen

WordPress does not only check locks when another user opens the full editor.

Core also contains:

wp_check_locked_posts()

which checks lock status for posts displayed in the Posts list.

This allows editorial teams to see that a piece of content is currently being worked on before opening it.

Quick Edit also respects post locking

Post locking is relevant outside the full editor.

Core’s Quick Edit processing uses post-lock checks when handling inline saves.

This helps prevent a second user from silently changing post data through the list table while another editor owns a current lock.

Preview operations can also check the lock

The WordPress post_preview() function checks editing permissions and post-lock state when preparing previews.

This is another indication that the lock is part of WordPress’s larger editing workflow rather than merely a visual dialog.

Can post locking be disabled?

Developers can alter parts of the locking behavior through Core filters and custom code.

However, completely removing editing coordination should be done carefully on sites where multiple users can edit the same content.

Removing the warning does not remove the underlying possibility of conflicting saves.

Disabling the dialog is not the same as disabling conflict risk

For example:

hide lock warning
≠
make concurrent editing safe

If two people can now edit without seeing the warning, the site has removed information about the conflict rather than solved the conflict.

Why disabling Heartbeat can affect post locking

Heartbeat is commonly targeted by performance-tuning advice because it creates recurring requests.

But disabling it without understanding what depends on it can break or degrade editing features.

Post-lock refreshing is one of those features.

If the mechanism that continually reports:

this editor is still here

stops operating, locks can no longer behave with the same responsiveness.

Do not disable Heartbeat globally just to reduce requests

A better approach is to determine:

• where Heartbeat is generating meaningful load;
• which features depend on it;
• whether changing the interval is sufficient;
• whether it can remain enabled in the post editor.

See Reducing WordPress admin server load before making broad performance changes.

Heartbeat frequency affects collaboration responsiveness

WordPress Heartbeat does not necessarily run at one fixed interval in every context.

The official Heartbeat documentation describes polling intervals in the range of approximately:

15–120 seconds

depending on behavior and configuration.

If a site significantly increases the interval, editing-state updates happen less frequently.

That can affect how quickly WordPress notices:

• an active editor;
• a takeover;
• a refreshed lock;
• other Heartbeat-driven changes.

A longer Heartbeat interval is not automatically broken

There is a difference between:

slower coordination

and:

no coordination

A moderately increased interval can reduce request frequency while retaining the underlying mechanism.

An excessively long interval, however, can make collaboration feel unreliable because updates arrive too slowly relative to the lock window and editor expectations.

TheOneWP Heartbeat Frequency

TheOneWP Heartbeat Frequency allows administrators to adjust the Heartbeat polling interval instead of treating performance tuning as a binary choice between:

default frequency

and:

disable Heartbeat completely

When tuning the interval on a multi-author site, post locking should be included in testing.

TheOneWP Heartbeat control

TheOneWP Heartbeat controls where WordPress Heartbeat runs.

For editorial sites, retaining Heartbeat in the post editor can be particularly important because editing features depend on that communication channel.

Do not evaluate Heartbeat only by counting AJAX requests.

Evaluate what those requests are doing.

Autosave frequency is a separate setting

Heartbeat frequency and autosave frequency are related operationally, but they are not identical concepts.

WordPress also has an autosave interval controlling how often editor content should be automatically saved.

TheOneWP Autosave Interval allows that timing to be adjusted separately.

This distinction matters:

Heartbeat interval
→ browser/server communication timing

Autosave interval
→ automatic content-saving timing

Post lock window
→ how recent a foreign lock must be
to count as active

Do not assume changing AUTOSAVE_INTERVAL changes the post-lock window

They are separate settings.

Changing autosave timing does not automatically change the Core:

wp_check_post_lock_window

value.

Likewise, changing the lock window does not redefine the autosave interval.

Post revisions are another separate system

The number of revisions WordPress keeps can also be configured independently.

TheOneWP Post Revisions controls revision retention.

Again:

Post locking
≠
Autosave interval
≠
Heartbeat frequency
≠
Revision retention

They interact, but each solves a different problem.

Post locking in the Block Editor

The modern Block Editor has its own application state around post locking.

The official core/editor data documentation includes selectors such as:

isPostLocked()

isPostLockTakeover()

This allows the editor interface to understand whether:

• the current post is locked;
• the editing lock has been taken over.

Do not confuse isPostLocked with lockPostSaving()

The Block Editor also exposes mechanisms with names such as:

lockPostSaving()

Despite the similar terminology, this is not necessarily the same concept as multi-user post locking.

A plugin can lock post saving for application-state reasons, such as requiring some condition before publishing.

Therefore:

post locked by another editor

and:

post saving locked by editor state

should not be treated as interchangeable concepts.

Post locking can apply beyond normal blog posts

WordPress uses the term:

post

broadly.

The underlying post system also powers:

• pages;
• custom post types;
• other content stored as WordPress posts.

If a post type uses the normal editing infrastructure, post-lock behavior may be relevant there too.

Custom post types should be tested

A custom post type may have:

• a custom editor;
• custom REST endpoints;
• custom saving logic;
• disabled editor support;
• third-party workflow management.

Do not assume every custom content interface behaves exactly like the standard Post editor.

Post locking does not merge two editors’ work

This is one of the most important limitations.

WordPress post locking is primarily preventative.

It attempts to stop simultaneous editing before conflicting changes accumulate.

It is not a full real-time merge engine that automatically combines:

Sarah's paragraph changes
+
Michael's title changes
+
Anna's block changes

into one guaranteed conflict-free result.

Revisions are not automatic conflict merging either

Revisions can help recover or compare historical content.

They do not magically understand the semantic intention behind two conflicting edits.

If multiple versions exist, a human may still need to decide which content should survive.

Best practice for editorial teams

For multi-author sites, keep the native collaboration features working and add an editorial process on top.

A practical workflow might be:

Writer
→ draft

Editor
→ review

Writer
→ revision requested

Editor
→ final approval

Publisher
→ publish

Roles, statuses and communication reduce the number of situations in which several users need to edit the exact same post simultaneously.

Communicate before using Take over

A takeover button is useful when:

• the original user forgot to close the editor;
• their session has effectively ended;
• another editor urgently needs control;
• the team has agreed to transfer editing responsibility.

It should not become the normal way two editors compete for the same article.

Save important work before handing over editing

If an editor knows another user is about to take over, saving or confirming the current content state reduces uncertainty.

Although WordPress has autosaves and revisions, intentionally preserving important work remains preferable to depending entirely on recovery mechanisms.

How to troubleshoot WordPress post locking

If post locks behave unexpectedly, investigate the entire editing stack rather than immediately deleting metadata.

Check Heartbeat requests

Determine whether periodic requests are still running in the editor.

Check performance plugins

Some optimization tools disable or throttle Heartbeat.

Check custom code

Search for filters involving:

wp_check_post_lock_window

show_post_locked_dialog

override_post_lock

Check the affected user

Verify whether another account actually has the post open.

Check browser tabs

The same user may have old editor tabs open.

Check server delays

Slow AJAX responses can make collaborative features feel inconsistent.

Do not delete _edit_lock blindly

Deleting the lock metadata may make a warning disappear, but first determine whether another person is genuinely editing the content.

If they are, removing the lock manually can recreate exactly the simultaneous-editing problem WordPress was trying to prevent.

When manually clearing a lock may make sense

Manual intervention can be reasonable when you have confirmed that:

• the original editing session is gone;
• the lock is genuinely stale;
• normal expiration or takeover is not working;
• custom code has created an abnormal state.

On a healthy Core installation, ordinary stale locks should normally stop counting as active after the relevant time window.

Post locking and server performance

The lock itself is small metadata.

The more relevant performance consideration is usually the supporting Heartbeat traffic on busy administration areas.

On a large editorial website with many simultaneous editors, Heartbeat can contribute recurring AJAX requests.

That does not mean those requests are useless.

The correct optimization question is:

Can we reduce unnecessary request frequency
without degrading editing workflows?

rather than:

Can we delete Heartbeat
because requests are bad?

Test performance changes with two real editor accounts

Whenever Heartbeat behavior is modified, a simple collaboration test is useful.

1. Log in as Editor A.
2. Open a post.
3. Keep editing session active.
4. Log in as Editor B in another browser.
5. Open the same post.
6. Confirm lock warning appears.
7. Test takeover if appropriate.
8. Return to Editor A.
9. Confirm lost-lock state is detected.
10. Verify recent changes remain recoverable.

This tests the behavior users actually depend on.

Common WordPress post-locking misconceptions

“A post lock permanently locks the post”

Incorrect.

Locks are time-sensitive and can expire when they are no longer refreshed.

“The lock lasts exactly 150 seconds in every WordPress site”

Incorrect.

150 seconds is the current Core default lock-check window, and developers can filter it.

“Autosave and post locking are the same feature”

Incorrect.

Autosave protects editing work. Post locking coordinates editors.

“Post revisions are locks”

Incorrect.

Revisions are historical content versions.

“Disabling Heartbeat only removes useless AJAX requests”

Incorrect.

Heartbeat supports functionality such as post-lock refresh and autosave behavior.

“Take over merges everyone’s edits”

Incorrect.

Takeover changes editing control. It is not automatic conflict merging.

“If the lock dialog is hidden, simultaneous editing is safe”

Incorrect.

Removing the warning does not eliminate conflicting saves.

“Post locking is a security permission”

Incorrect.

WordPress capabilities determine whether the user is authorized to edit the post.

WordPress post locking checklist

• Understand that _edit_lock stores current editing-state information.
• Do not confuse _edit_lock with _edit_last.
• Remember that current Core uses a 150-second default lock window.
• Remember that the lock window can be filtered.
• Keep Heartbeat functioning in editorial contexts where post locking matters.
• Do not disable Heartbeat without testing post-lock behavior.
• Do not assume Heartbeat frequency and autosave frequency are the same setting.
• Do not assume revision retention controls post locking.
• Test locking with two separate user accounts.
• Test the takeover workflow.
• Verify the first editor receives the lost-lock state after takeover.
• Keep revisions available where recovery from editorial conflicts matters.
• Check performance plugins when locks behave inconsistently.
• Check custom filters affecting the lock window or takeover behavior.
• Do not manually delete lock metadata without confirming the original editor is gone.
• Use capabilities for authorization.
• Use post locking for editing coordination.
• Use an editorial workflow to reduce unnecessary simultaneous editing.

How TheOneWP relates to WordPress post locking

TheOneWP does not need to replace WordPress Core’s post-locking system to influence how well it behaves.

Several system controls affect the environment around it.

Heartbeat

Heartbeat controls where the WordPress Heartbeat mechanism remains active.

For multi-user editing environments, retaining Heartbeat in the editor preserves the communication channel used by collaboration features.

Heartbeat Frequency

Heartbeat Frequency controls how frequently Heartbeat checks occur.

Changes should be tested against editor responsiveness rather than evaluated only by request count.

Autosave Interval

Autosave Interval adjusts how frequently WordPress automatically preserves editing work.

This is related to the same editing environment, but separate from the post-lock timeout.

Post Revisions

Post Revisions controls revision retention.

Revision history can provide an important recovery path when editorial changes need to be compared or restored.

Related WordPress editing and performance guides

• The WordPress Heartbeat API, explained
• How WordPress post revisions work
• Reducing WordPress admin server load
• WordPress database bloat, explained
• Heartbeat
• Heartbeat Frequency
• Autosave Interval
• Post Revisions

Final thoughts

WordPress post locking is a coordination system designed to reduce accidental editing conflicts.

At its core, the mechanism is relatively simple:

user opens post
↓
WordPress stores lock
↓
Heartbeat refreshes editing state
↓
another user opens post
↓
WordPress detects active foreign lock
↓
warning or takeover workflow

But the surrounding behavior involves several separate WordPress systems:

post locking
+
Heartbeat
+
autosave
+
per-user autosaves
+
revisions
+
capability checks

Understanding those differences matters when tuning WordPress performance.

Reducing Heartbeat traffic can be reasonable.

Changing autosave frequency can be reasonable.

Limiting revision history can be reasonable.

But these settings should not be adjusted as though they were unrelated switches with no effect on editorial workflows.

On a multi-author site, test the result with multiple real accounts before deploying aggressive Heartbeat changes.

The goal is not merely to reduce background requests.

It is to keep WordPress efficient while preserving the mechanisms that stop two editors from quietly replacing each other’s work.