Lock release strategy is ill-conceived -> Module is useles that way
| Project: | Checkout (Content locking) |
| Version: | 6.x-2.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Hi,
the idea to have a pessimistic locking for drual is very important. The checkout module is doing a good job, but it fails when it comes to the release strategy.
Theres two ways to release the lock:
1) After some time by the cron
2) Leaving the edit-page.
"Leaving the edit page" means react on url-requests. And this is the big problem!
Checkout releases the lock when:
- User reload the edit-page
- User opens a link form edit-page e.g. in a new tab
- User uploads a image/file with ajax-funtionality in the edit-page form
- Ajax-Refresh e.g. in a block
- FCK-Editor do a request while loading
- ...
There's some issues, going back to that problem:
http://drupal.org/node/366776
http://drupal.org/node/355782
http://drupal.org/node/349326
http://drupal.org/node/322248
and so on...
You can check this with the firefox-extension Live HTTP Headers 0.14.
I spend many hours to find this. :)
In my case the FCKEditor requests a url (fckeditor/xss to load some XSS Filter) during loading itself. That releases the lock. So: It lock on click 'EDIT' and after loading the whole form, it's released!
A quick'n'dirty workaround for me case:
<?php
// function checkout_handle_request($uid) - Line 211
// Check whether to release a previously edited node.
if ($previous_nid && (!$current_nid || $current_nid != $previous_nid)) {
if(strpos($_GET['q'], 'fckeditor') === FALSE) // Add an exception
{
checkout_release($previous_nid, $uid);
}
}
?>I think a new strategy is necessary.
It could be like this:
- To release the lock, user have to klick the SAVE Button.
- But what happens when the user leaves the edit-page without saving?
Then the cron (running maybe every 5 minutes) releases the lock. - What happens when user needs more than 5 Minutes to edit?
When a user starts edting a node, a timer starts also. After some time (e.g. 5 minutes) a message (Javascript-Alert-Box) reminds the user to klick the PREVIEW button. This actions locks the node again.
With this strategy there still some "deadtime", but better than now.
Does someone have a better suggestion, you're welcome to share information.
I'm going to vaction for 4 weeks until easter. After that i gonna start the implementation of my idea. I will release than a patch here.
Bye Franzer
#1
I am not convinced that this strategy is any better than what we have now. Checkout already implements timer based unlocking, enforcing this to 5 minutes would collide with the existing functionality. And automatically unlocking a node after 5 minutes and requiring an editor to click some button - come on, that sounds like punishing the editor for doing his/her work... ;)
I think the only way to reliably solve this problem is to introduce AJAX based (un-)locking, ie. working with the onload and onunload browser events, and skipping server side locking altogether. That way you can be sure that a node is only released after you're really leaving a page, and not by some background action, like it's currently the case.
#2
I do agree with your points of unlocking
AJAX based (un-)locking, ie. working with the onload and onunload browser events
There should be some Ajax facility that whenever user tries to navigate to other page or try to close browser window from the Node editing Page it should prompt the user whether he/she is interested in saving the node if yes then save and release and navigate to the user's desired page else release the node and navigate to the user's desired page.
#3
Just a small note: asking whether any changes to a node edit form should be saved (or discarded otherwise) is not the purpose of this module, I am pretty sure that there are existing modules for exactly that task.
Regarding AJAX based locking: create an initial patch and become the next Checkout hero :)
#4
So what happens to users without javascript? Are they not allowed to edit pages? Or will they be able to edit the page even if it's locked?
Relying on javascript is never good in my opinion. We don't want to force our users to enable javascript to edit a page at our site.
#5
I've just realized FranZer used the latest stable release, which doesn't yet contain the AJAX unlocking protection, d'oh! :(
@FranZer
Please update to the latest development snapshot. As long as modules are properly using jQuery's AJAX methods (and FCKEditor module does), there is code that prevents nodes from being unlocked by AJAX requests.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.
#7
Where exactly can you find the latest dev snapshot? In the releases list there is no dev branch for drupal 6 only drupal 5.
#8
And modifying the link to match naming conventions doesn't do the trick either...
#9
Just enabled development snapshots. Alternatively, you could checkout from CVS.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.