[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