Should be able to unlock a post outside of ajax handler

[bbrooks]

Right now you can programmatically lock a post for editing using wp_set_post_lock, but you can't unlock it in a similar fashion. The only unlocking code is found in the ajax handler wp_ajax_wp_remove_post_lock.

I've created a function wp_unset_post_lock in the style of wp_set_post_lock that unlocks a post with a given ID. I've also refactored wp_ajax_wp_remove_post_lock to use this function.

The only resulting difference is that we use the current user's ID instead of the one supplied in the ajax call, but since we're unlocking the post instead of locking it, it doesn't really matter who's ID is in the meta.

This change was requested by Joey Kudish of the VIP team.

[bbrooks]

New post unlocking function and refactor of an ajax handler to use new function

[nacin]

This is a very good idea.

I am not sure if "unset" is the right word. "remove" or "release", maybe?

[bbrooks]

Yeah, the function is hard to name because honestly the whole logic of unlocking posts is less-than-intuitive. To unlock a post, you merely set the lock to a time in the past almost as long as the 'timeout due to inactivity' criteria in the lock mechanism.

That said, 'expire' might be a better verb. How about "wp_expire_post_lock"?

If, however, we're not concerned with the name reflecting the mechanism, it should really just be wp_lock_post and wp_unlock_post.

[ocean90]

wp_remove_post_lock()

[ocean90]

​http://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-07-05&sort=asc#m637320

[nacin]

After some discussion in IRC, this doesn't actually make sense as a 1:1 handler => API change. Let's punt this and re-consider soon.

If necessary, you can unconditionally clear a lock by removing _edit_lock.

[callumbw95]

Hi everyone,

I have just taken a quick look into this now, and implementing a wp_delete_post_lock() function does make a lot of sense from an API perspective, as it would provide a symmetrical counterpart to wp_set_post_lock(). This would certainly be useful for developers building custom admin tooling or headless integrations.

However, I am concerned around the potential risk to the user experience and the increased potential for data loss through adding this function. The current post-locking mechanism is intrinsically tied to the user's session in the editor, with the heartbeat acting as a "still editing" signal. The "Take Over" feature is a deliberate, user-initiated action that makes it clear someone else's work might be interrupted.

Introducing a way to programmatically remove a lock from the backend could break this user-facing contract. A user could be actively typing in the editor, believing they hold the lock, while a background process silently removes it, only to discover this upon their next save attempt, which could result in their changes being unexpectedly overwritten.

I think there is potential for more conversation here around this topic, but seeing as this ticket is so old, and the lack of feedback on this in the last decade, I am going to add the close tag. But do please feel free to continue this conversation further and remove the tag. 😃

[SirLouen]

As @callumbw95 has suggested, there is no feedback for the last decade and given the absence of more information, it's time to close it

But as I always suggest, if @bbrooks wants to provide more information and continue pushing this if it's still useful, feel free to comment back and I will continue following it.