Yes, I replace the old modification and I test the two new solutions you've proposed.

 

I do an other test : When I put the additionnal JS code in form.php : I have the lock problem

When I delete the additionnal JS code in form.php : No more lock problem.

 

So, I don't understand, if it's works for you...

 

I join you my file form.php ;)

That's strange, but if it works by removing that additional JS code - then you would have the original code, right?

And didn't that cause the issue the first time?

This is what the code does:

 

<?php if (JRequest::getInt('step')=='1') { ?>  //THIS LOOKS FOR THE STEP PARAMETER WE PASSED

//WHEN STEP IS == 1 THE CODE BELOW GETS RAN        <script language="javascript">            var XHRCheckin = new Ajax('index.php?option=com_k2&view=item&task=checkin&cid=<?php echo $this->row->id; ?>', { //THIS BEGINS THE 'CHECK IN' PROCESS TO UNLOCK THE ARTICLE                method: 'get'            });            dummy = $time() + $random(0, 100);            XHRCheckin.request("t"+dummy); //THIS SETS THE TIME AT WHICH THE ARTICLE GETS //'CHECKED IN'            parent.$('sbox-window').close();  //THIS CLOSES THE WINDOW            window.parent.location.reload(); //THIS RELOADS THE PAGE           </script>        <?php    } ?>

 

 

So as far as I understand it - with the code above, when that step parameter gets passed into the form via the URL (when the user clicks save) it will run the defined code.

The issue with my original code was that it did not check-in (unlock) the article.

When you click 'cancel' or 'close', there is a check to see if the article has a $this->row->id, if so, it checks the article in (unlocks the article).  In my code I didn't need to do that, because you're clicking 'save', so the article will always have a row->id, by the time this code is ran.  All I did was take the code that 'checks in' the article from the cancel/close buttons and adjust it to the code that gets ran when the user clicks 'save'.

I'd be interested to see if others are having this same issue - as you can see from the code above, you shouldn't be having the lock issue any longer.  This is a strange one for me...

Which code do you 'remove' for it to work?

When I remove all YOUR code, so I have to click on save, and the cross to quit the pop-up, and like that, no lock problem.

 

Could you send me your files form.php and item.php file (the two files we've modify).

 

You use SEF urls ?

 

Thanks ;)

I do use SEF url's, and I use default Joomla SEF.

 

I've attached my form.php and also my item.php file for you to have a look at.

I did a check of your form.php and mine, and the files match (according to Notepad++).

 

 

I don't understand...

 

I create an article with your JS Code, in back-end I have the lock problem.

I open a new page, I put : mywebsite/index.php?option=com_k2&view=item&task=checkin&cid=[num_article_locked]

Then, I return in back-end, and the article is no longer locked.

 

Nevertheless, your code do that validation with this url automatically, so I don't understand why it don't work...

 

 

Hmmm, so for some reason that Ajax hit to the url is not completing it looks like.

Because the Ajax hit is doing the same thing you are doing by opening a new browser and going to that URL, it's just being done automatically.

 

So for some reason your code is not running that bit of Ajax - that seems odd...

Does the rest of the code run?  Does the box close, and the page refresh?

 

Yes the box close and the page refresh, it's very weird...

 

I replace my two files by yours, it doesn't fix the problem :/

I find something :) !!

 

With Google chrome it works, my article are not locked.

So it's Firefox (I use the new Firefox 4 version) that bug...

 

 

I confirm, it works also with IE, so it's really Firefox 4 who don't call the Ajax part, how we can fix it ? :)

 

Thanks again ;)

Ah cool,

Yea, I use Firefox 3.6 or whatever the current non-beta release is.  I think Firefox 4 is still in beta isn't it?

Check in IE to see if that works - just to make sure.

 

Looks like I might have to make some changes to try and adjust for users who are on firefox 4 (which I think would be a very small population right now)

On IE it works, but Firefox 4 is not a beta, it's a final version :/

 

So, it's really weird but now, I know the source of lock problem :)