"It will unlock when you navigate elsewhere."

this not happen ... document is still in state "checkout".
i see in my profile on list.

"This document is locked for editing by Tomek since pt., 11/07/2008 - 23:05.
Click here to check back in now."

ok, this work good, but it is not a mishmash?

CommentFileSizeAuthor
#10 checkout_avoid_ajax_unlocking.patch640 bytesFrank Steiner
#7 checkout_webfm.patch670 bytesFrank Steiner
#1 checkout.module.patch2.25 KBsmk-ka

Comments

smk-ka’s picture

smk-ka commented
Status: Active » Needs review
StatusFileSize
new checkout.module.patch2.25 KB

Yes, this is a major mismatch, sorry for the trouble...
Can you please test the attached patch? This should fix your issue.

tomaszx’s picture

tomaszx commented

hm, still the same. I think that this is related to: #245685: Page being redirected in a way that will never complete

smk-ka’s picture

smk-ka commented
Status: Needs review » Postponed (maintainer needs more info)

Since 2.2 is out, is this now resolved?

tomaszx’s picture

tomaszx commented

Yes, for me 2.2 works ok.
Thanks Stefan.

smk-ka’s picture

smk-ka commented
Status: Postponed (maintainer needs more info) » Fixed

Closing then.

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-2.0 » 6.x-2.2
Status: Fixed » Active

Hi,

it doesn't work this way when webfm is installed (and maybe other modules using ajax for some edit form stuff). hook_init is called several times during the webfm initialization (I don't understand all of that, but the ajax stuff does some strange things), and $_GET['q'] will be "webfm_js". Therefore, the lock will immediately be removed when webfm is initialized on the web form.

You can't see that by debugging messages when editing the page, because drupal_set_messages issued when ajax does cause the hook_init are cashed. They are shown e.g. when you reload the edit form, then you see sth. like this:

checkout_init
current path: webfm_js
referer: node/138/edit
previous nid: 138
current nid: 
releasing
deleting lock from db
checkout_init
current path: webfm_js
referer: node/138/edit
previous nid: 138
current nid: 
releasing
deleting lock from db
...
...

So, hook_init might not be the right place for this. I don't have an idea for a patch at the moment.

Frank Steiner’s picture

Frank Steiner commented
Status: Active » Needs review
StatusFileSize
new checkout_webfm.patch670 bytes

Hi,

I didn't find a way to change webfm to avoid this problem. webfm adds

    $items['webfm_js'] = array(... 'page callback' => 'webfm_ajax',...)

in hook_menu and uses the URL http://.../webfm_js for interaction between the .js file and the ajax function in the module. So when building the file tree or the list of attached files in the node edit form, the .../webfm_js page is indeed called several times and every time this executes checkout_init.

I didn't find a better way than explicitely checking for the webfm_js url in checkout_init. With this patch, checkout works again with webfm.

smk-ka’s picture

smk-ka commented
Title: It will unlock when you navigate elsewhere » Documents unlocked during AJAX requests
Status: Needs review » Needs work

I see... However, this patch isn't a solution.

I see two possible ways to solve this issue:

  1. Rerolling #235865: Use javascript instead of HTTP referer, my only concerns are A) performance and B) I didn't like that documents are only unlocked using JavaScript but not locked, which might present a problem for those without JavaScript enabled browsers. And, that patch completely removed the traditional way of unlocking IIRC.
  2. Digging in the jQuery sources revealed they're setting an additional HTTP header that can be used to prevent issues like this one:
    		// Set header so the called script knows that it's an XMLHttpRequest
		xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");

    However, webfm.js doesn't seem to use jQuery (checked only 5.x branch), so it would require patching, too. Otherwise we should be safe, as long as modules are using jQuery to request data.

What do you think?

Frank Steiner’s picture

Frank Steiner commented

I agree that 1. doesn't sound nice. About 2., I don't know what jQuery is, so I will have to learn about that and see if I can submit a patch to webmf (no idea if they would accept it, though, there is some kind of silence in the maintenance for the 6.x branch :-().

Frank Steiner’s picture

Frank Steiner commented
Status: Needs work » Needs review
StatusFileSize
new checkout_avoid_ajax_unlocking.patch640 bytes

webfm is using a XMLHttpRequest object for the POST requests. It's no big deal to add 

    xmlHttp.setRequestHeader("X-Requested-With", "XMLHttpRequest");

to webfm.js so that we could use the same check as for jQueries (if I got that right). I tried with the attached patch (and the patched webfm code) and locking works fine now since the webfm queries don't execute the checkout handler anymore.

Would that be an acceptable way? I would submit the patch to webfm if you agree.

smk-ka’s picture

smk-ka commented
Status: Needs review » Fixed

Agreed, committed with slight modifications.

Frank Steiner’s picture

Frank Steiner commented

Thanks! I will submit the patch to webfm.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.