community.getk2.org/forum/topics/k2-add-new-item-window-resi...

 

It's on that page where the 'checkin' fix is located.

Essentially your form.php should look like this (where it checks for step==1)

<?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: 'post'            });            dummy = $time() + $random(0, 100);            XHRCheckin.request("t"+dummy);            parent.$('sbox-window').close();            window.parent.location.reload();                   </script>            <?php    } ?>


That will 'checkin' the article after the save, close the modal box, and refresh the page.

 

I'm note sure if that may help to fix the infinite loop - but worth a shot?  I'm still wondering how or why it goes into an infinite loop... for some reason the browser you were using must have 'held onto' that JS somehow and kept refreshing it.

Because once the page was 'refreshed' that javascript wouldn't be on the refreshed page, so I'm not sure how it keeps calling the refresh command... Hmm....

 

Sorry for the late reply, and thank you very much for attempting to fix this.

 

The new code still doesn't fix the infinite loop. I now know that the infinite loop happens when the user creates posts on the first login. If the user logs out, then logs back in, there is no infinite loop. Weird.

 

How do I go about closing the window, but not refreshing? I suppose I would rather the user refresh manually than experience an infinite loop.

On second thought... I'm using sh404SEF... that probably has something to do with it?

another issue....when sh404sef is switched on, and user click on {Toggle sidebar} this will result in jump to home page from submisstion form ? anyone expereinced this issues?

Hmm, I am not sure as I haven't tested it with SH404SEF installed (I guess I'll have to eh?).  I guess that may have something to do with it.  I think that this will be resolved once I change it to not 'refresh the parent page', but rather send the user to a specific page ('their page -> where their new article will show').

 

I wonder if something you could try would be switching the two lines -

parent.$('sbox-window').close();

window.parent.location.reload();

 

Maybe switch it to be:

window.parent.location.reload();

parent.$('sbox-window').close();

Perhaps for some weird reason it's closing the box, and then the page refresh is getting 'caught' on something because maybe it's looking for some sort of 'end' to the code and just keeps looping.  Just a quick fix you could try that might work.

My only thought is that maybe it won't work because the page will start to reload before the close window command gets run - but give it a shot - let me know.

 

Also if you wanted to get rid of page refresh, simply remove the line:window.parent.location.reload();

 

That will just make the box close.

Nish, I also experienced that same issue - it's not just when 404sef is enabled, it's just a legitimate 'bug' in their code.

 

I don't allow frontend users to play with the options in the sidebar so I just disabled it all together.  One headache solution at time for me :-D hehe

Toggle sidebar issue is now resolved by adding following code to form.php file. around line 245 I added follwoing code first

 

<?php# Using REQUEST_URI  added to resolve SH404SEF conflict, which return to home page when Toggle Sidebar clicked.$editurl = $_SERVER;?>

 

 

and then change the code

<a href="#" id="k2ToggleSidebar"><?php echo JText::_('Toggle sidebar'); ?></a>

 

to

 

<a href="<?php echo $editurl;?>#" id="k2ToggleSidebar"><?php echo JText::_('Toggle sidebar'); ?></a>

 

which then resolve the problem.

Excellent!

You should write up a bug thread, and post that in there so people know it's a genuine bug that has a solution :-D

 

Awesome work :)

I tried your suggestion but it didn't fix it. It's really weird isn't it. I spend hours trying various fixes but nothing helps. I think I'm just going to stick with only closing the window.

 

Oh I tried it without sh404sef also but that's not the cause of the problem.

community.getk2.org/forum/topics/k2-add-new-item-window-resize

 

Try the solutions listed there (I believe on page 18 is where we're at now), we're working on making it redirect to a specific page - that should hopefully fix the refresh issue.

 

However, to get it to do that, you need to disable the calender functions of the form.php - so if having your users be able to put in the dates themselves is important, it probably won't help much (for now).

 

We'll keep plugging away.