[wp-trac] [WordPress Trac] #65126: Implement a lock mechanism for Site Editor templates (wp_template, wp_template_part) similar to the existing Heartbeat-based post locking system.
WordPress Trac
noreply at wordpress.org
Fri Apr 24 20:00:00 UTC 2026
#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------+---------------------------------------
Reporter: sparshie | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1
Component: Editor | Version: 5.9
Severity: normal | Resolution:
Keywords: needs-patch | Focuses: administration, template
-------------------------+---------------------------------------
Comment (by sparshie):
Replying to [comment:1 westonruter]:
> And I presume this post locking should not be enforced in favor of real-
time collaboration (RTC) when that is enabled. See
https://github.com/WordPress/gutenberg/issues/76985
>
> Since I also assume this will be part of the next major release, I'm
milestoning accordingly.
Thanks for the feedback and for updating the milestone.
I wanted to provide more context on why this change is needed.
On our implementation, we transitioned certain editorial workflows from a
custom post type to `wp_template` (Site Editor). In this setup, the
existing post locking mechanism does not apply, as it relies on
traditional `postId`-based locking. As a result, multiple users can edit
the same template simultaneously without any warning, which has led to
unintended overwrites and loss of changes.
To address this, I implemented a lock mechanism similar to the existing
Heartbeat-based post locking, adapted for entity-based editing used by the
Site Editor. This ensures:
* Users are notified when another user is editing the same template
* A soft-lock experience with options to either take over or exit
* Prevention of silent overwrites in non-collaborative scenarios
Regarding real-time collaboration (RTC):
I agree that locking should not be enforced when RTC is enabled. The
implementation is designed to be conditional, so locking is disabled when
collaborative editing is active and only applied as a fallback where RTC
is not available.
I’ve attached a patch to this ticket with the proposed approach and would
appreciate feedback on:
* Whether this aligns with the intended direction for entity-based editing
* The approach for detecting and deferring to RTC
* UX expectations (soft lock vs strict enforcement)
This solution is currently being validated in production on our end.
Thanks again for the guidance.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/65126#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list