[wp-trac] [WordPress Trac] #18515: UX: better management of workflow in editor (joe is currently editing this post, etc.)

[WordPress Trac]

#18515: UX: better management of workflow in editor (joe is currently editing this
post, etc.)
------------------------------------------------+--------------------------
 Reporter:  azaozz                              |       Owner:
     Type:  enhancement                         |  jayminkapish
 Priority:  normal                              |      Status:  reopened
Component:  Editor                              |   Milestone:  3.3
 Severity:  normal                              |     Version:
 Keywords:  has-patch ux-feedback dev-feedback  |  Resolution:
------------------------------------------------+--------------------------

Comment (by nacin):

 To summarize this ticket, I've looked extensively at the functionality,
 and a decent amount of the code, of both contributions here.

 The plugin from jayminkapish is pretty nifty. I think it has a relatively
 limited use case, but it shows how this may be implemented or desired in a
 real world use case. When stripped down for a core patch, it'd look rather
 simple. If cleaned up, it'd make a great plugin in its own right.

 The patch from benbalter is far more complicated. It introduces a number
 of new constructs and workflows. The basic workflow is very similar to the
 work from jayminkapish. Overall, it's a very good direction we should
 probably take this feature in.

 ----

 I spoke with jane and she suggested that the best fix (and treating the
 rest of this as a future enhancement, after further review of the
 approaches outlined here) would be to ensure we clear the lock when the
 author leaves the page.

 This seems pretty simple to do. There are three reasons why the page will
 be left:
 1. On some sort of POST action such as save or publish.
 2. On an unrelated GET or POST action, such as an unrelated form, or
 clicking elsewhere.
 3. A refresh of the page.

 In cases 2 and 3, we would currently trigger a notice on unload. In cases
 1 and 3, we'd want to keep the lock. Keeping the lock in case 1 is easy.
 Releasing the lock in case 2, but keeping it in case 3, might be
 difficult.

 However, let's assume for a moment that case 3 (a refresh of the page
 other than case 1) is rare. So rare we probably don't even need to account
 for it in a special way.

 So, let's fire an ajax request on unload (cases 2 or 3). In order to
 handle case 3, we provide ourselves a 2-second delay. azaozz's patch does
 this by waiting 5 seconds before forcibly releasing the lock.

 Unfortunately, the approach contains a race condition. By sleeping for 4
 seconds and checking for five seconds, this assumes that the ajax request
 didn't take longer than 1 second to process. Otherwise, it's possible that
 the refreshed page updates the lock and the ajax request then takes it
 away. Another option could be to, via ajax, updating the _edit_lock to
 time() + 5. Of course, you're hoping that overlap doesn't occur in some
 other way.

 So, my proposal: If we knew what the current lock is when making the ajax
 request, then we could see if it's the same lock we ourselves obtained,
 and if so, kill it. We could avoid the race condition by specifying the
 $meta_value for delete_post_meta(), since we'll know what lock and user ID
 we're looking for.

 An interesting footnote, I also looked into update_metadata() and found
 that does not provide the return value of $wpdb->update(), which means if
 you passed a $prev_value, you don't actually know if update_metadata() was
 able to actually find the row to update. Since we won't be receiving the
 result of the ajax request, it wouldn't have been helpful here beyond
 debugging.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18515#comment:13>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software