Simon,

 

Thank you for your input, I have before, and will say again, I value your input, and your help in the past has helped me on many issue. There is some confusion that i MUST clarify. I did not call anybody any names, I am merely repeating K2's response to you. They said they would do nothing to help because I had questioned there know-how, and ergo called them names. Williams answer is inane because it only solves a temporary problem I am utterly astounded at how the bigger picture is being missed. So many people are having this issue, and doing an override is akin to saying " The brakes are faulty, drive slower" it provides a temporary solution. All i am asking, is that K2, say, "yes, we have a problem, there is a solution so easy (so easy that even I, a complete novice worked out) that we will incorporate it into the next K2 as a feature.

I keep hearing "we need to work together to find a solution". I found one, people in this thread have found one! incorporate it! Instead of doing all they can to fight any notion that somebody has dared to question their abilities. Nobody is, We are all in awe of their supreme beings, people jsut get frustrated when such a simple point is being missed.

Answer me this Simon, A car develops a fault, turns out its a "known fault" that affects all cars in that model. Do you fix THAT car, or fix the problem to stop any other cars developing the fault? The end user gets frustrated when the car manufacturer says "its not a bug, its just an inconvenience and anyway were not fixing it because you questioned us". Is that really the impression K2 wants to give?

I thank you again for your valued input.

 

Jasper

Simon,

I apologize if my reply came off a bit crass, and I was under the impression you were a part of the development team.  I am simply surprised that as others have said and I have reiterated, that the developers refuse to acknowledge this as an issue despite the user base that is unhappy with these lacking features.

 

I agree with all the above that we should indeed work together, and I've talked with William (albeit briefly via e-mail) and hopefully we'll be able to bounce some ideas around and continue to work together in organizing a solution that will not cause the weird locked results that juju had discovered.

 

As a community we can do a lot, I think the frustration that builds is because to the coders who developed this solving the problem would probably be very simple, yet they just tell people to 'deal with it'.  It is frustrating for those of us who spend days and weeks struggling just to figure out exactly how to get a hack to make it 'workable', because we would just like a little input.

 

I understand they're busy - they have lots of other things going on, real lives, other projects, etc.  I understand and respect that - but being able to admit something is an issue, and being able to provide perhaps a touch of insight is something I think the entire community would appreciate.

 

I'm with Juju and the others - lets just fix this issue that way the developers can just integrate it into the next release and sign us up to help them in developing new things ;)

Jasper, car analagies dont really work (you buy a car, the there are safety issue both of which are not valid here) but I know what you.

 

Hanny, no need to apologise

 

From what I can see, the original post, to resize the modal window has been fixed with a solution posted in the main post from Jasper? correct?

Then other questions have been raised relating to modal window, specifically the desire to have modal to close upon save?

 

What I would like to suggest is, why not login to simon.getk2.org where you will be able to post an item to the members blog. I can then check out the solution and test it so that I can provide feedback to the team, to see if they will include it.

 

See where we can take this.

Simon

Simon,

The modal window size issue was fixed, temporarily, when K2 release an update, all the changes are wiped, and you have to do them again. The thing I would like K2 (so much) to do, is incorporate it, so for any future releases the modal window has an auto size for all screen resolutions. The reason I am getting exasperated is I know Overrides would help ME, but If i was only interested in helping me, I wouldn't have started this thread, I would like K2 to adapt this change so it helps EVERYBODY. I can do an override, but whats the point of just one person being able to do something. The whole ethos of open source is for  everybody to add and benefit. That's all I'm trying to do, and all Ive been met with is 15 pages of people telling me why they can't, or why I should just deal with it.

 

Thanks again.

jasper.

I have fixed the bug in my code where the article was not 'checked in' upon save.

 

If you want to make it so that the article is also 'checked in' when the user hits save - follow along:

 

In the original steps we added the following to form.php:

 

<?php if (JRequest::getInt('step')=='1') { ?> <script language="javascript"> window.parent.location.reload(); </script> <?php } ?>


 

Simply change that to the following to have the article get 'checked in' when the user saves:

<?php if (JRequest::getInt('step')=='1') { ?>        <script language="javascript">        var XHRCheckin = new Ajax('index.php?option=com_k2&view=item&task=checkin&cid=<?php echo $this->row->id; ?>', {            method: 'get'        });        dummy = $time() + $random(0, 100);        XHRCheckin.request("t"+dummy);        window.parent.location.reload();        </script>        <?php    } ?>

 


I did test this a bit - but if you guys can do any more extensive testing on it that would be great.  Otherwise this should have the 'checkin' and 'checkout' features working as originally intended - and also make the 'save' button operate as it should operate - by closing the shadowbox, and refreshing the page which triggers the 'item saved' text to pop!

 

It also looks like you can make it a bit more 'clean' to the end user by having the pop-up window close immediately (so they don't see a partial reload of the shadowbox before the main page refresh) - If you would like that to happen simply add one line of code to the form.php code above so it looks like this:

 

<?php if (JRequest::getInt('step')=='1') { ?>        <script language="javascript">        var XHRCheckin = new Ajax('index.php?option=com_k2&view=item&task=checkin&cid=<?php echo $this->row->id; ?>', {            method: 'get'        });        dummy = $time() + $random(0, 100);        XHRCheckin.request("t"+dummy);        parent.$('sbox-window').close();        window.parent.location.reload();            </script>        <?php    } ?>


All that code does is has the shadowbox close - and then triggers the page refresh after that.  This worked on my test sites/server - and worked in IE, Chrome, and Firefox - IMO - this is the cleanest way to achieve the desired end result so the user doesn't see some partial re-load of the form.

 

I'll test this tomorrow, but THANKS A LOT !!! I never succeeded without your help !

Finally, it's you, a user, who resolved the problem, it will be great if a K2 developper would include this in the next version of K2...

 

Thanks again, I'll keep you informed.

Thanks juju, lets just hope there's no more bugs in my code :-D  Please let me know if there are (as I am far from a programmer!)

 

Also, I'm going to work on including this into a 'template override', and I will try to post how I do that here in this thread so others may do the same.  Then you can update your K2 without having to worry about the core code overwriting the 'save' feature changes!

Good work guys, I appreciate your work on this.

Simon

I just test your second code, and I still have the lock problem... :/

 

Edit : With the two solutions you've proposed, I still have the lock problem, it's weird because I assume you've test on your website and you don't have problem no ?

 

Nevertheless, I do a very simple test :

 

I log on front-end with an account who have all rights in K2 (edit, publish...).

I log on backend with an admin account.

On the front end I add an article (I clicked on save button, it refreshing).

On back-end I see the article locked.

 

Sorry to bother you...

Did you replace the original php code with the new stuff?

I did test it here, in each browser and it worked fine, so I think this may be more of a troubleshooting issue than something with the code (at least I hope).

 

Could you copy/paste the code you're using here (not the whole form.php - just the parts we edited)?

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 :)