WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#6774 closed enhancement (duplicate)

Remove _edit_lock on save or exit

Reported by: AaronCampbell Owned by: azaozz
Milestone: Priority: high
Severity: normal Version: 2.7
Component: JavaScript Keywords: needs-patch
Focuses: Cc:

Description

I see the functions wp_check_post_lock and wp_set_post_lock, but I don't see any wp_release_post_lock. Am I missing it? It seems like a lock should be lifted when the user navigates away from that page (either by saving or by going to another location/exiting). Currently, the warnings seems misleading.

Change History (9)

comment:1 AaronCampbell5 years ago

  • Milestone changed from 2.9 to 2.8

comment:2 jacobsantos5 years ago

  • Keywords needs-patch added

comment:3 Denis-de-Bernardy5 years ago

  • Version set to 2.7

comment:4 Denis-de-Bernardy5 years ago

  • Priority changed from high to highest omg bbq

I'd like to see this one fixed in WP 2.8 and will offer $25 to whoever submits the patch that makes it into WP 2.8. Email sales at semiologic.com to collect the bounty.

comment:5 Denis-de-Bernardy5 years ago

  • Component changed from General to JavaScript
  • Owner changed from anonymous to azaozz
  • Priority changed from highest omg bbq to high
  • Severity changed from major to normal
  • Type changed from defect (bug) to enhancement

there currently is this line:

$time_window = apply_filters( 'wp_check_post_lock_window', AUTOSAVE_INTERVAL * 2 );

in other words, the lock's time window is rather short. we'd only ever get a lock when two users edit a post, one after the other.

suggested fix:

  • We add an onUnload event to the page using jQuery
  • onUnload even sends an ajax request to remove the lock

comment:6 Denis-de-Bernardy5 years ago

  • Milestone changed from 2.8 to Future Release

moving to Future, pending a patch

comment:7 azaozz5 years ago

Tested running a release_lock function with ajax on window.onunload. The problem is that when the user reloads the write page, the lock is removed with the ajax and added back with the normal request. If the ajax is delayed (internet routing problems, packet loss, etc.), it may arrive after the normal reload request and the post will be unlocked until the next autosave.

In that terms decreasing the $time_window to AUTOSAVE_INTERVAL + 35 seems better (30 sec. is the default connection timeout).

comment:8 azaozz3 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Closed as duplicate of #18515.

comment:9 ocean903 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.