Make WordPress Core

Opened 16 years ago

Closed 13 years ago

Last modified 13 years ago

#6774 closed enhancement (duplicate)

Remove _edit_lock on save or exit

Reported by: aaroncampbell's profile AaronCampbell Owned by: azaozz's profile 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)

#1 @AaronCampbell
15 years ago

  • Milestone changed from 2.9 to 2.8

#2 @jacobsantos
15 years ago

  • Keywords needs-patch added

#3 @Denis-de-Bernardy
15 years ago

  • Version set to 2.7

#4 @Denis-de-Bernardy
15 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.

#5 @Denis-de-Bernardy
15 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

#6 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 2.8 to Future Release

moving to Future, pending a patch

#7 @azaozz
15 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).

#8 @azaozz
13 years ago

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

Closed as duplicate of #18515.

#9 @ocean90
13 years ago

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