Hello,

I'm new to K2, and I have googled this and searched extensively for an answer but have been unable to come up with one.

 

As a last effort I figured I would post here to see if anyone has been able to find an answer to my issue.

 

When a user submits an article on the front-end:

Is there a way to make the 'save' button behave like the default Joomla buttons (i.e. save the article, and close the pop-up-window)??

 

This is the ONLY thing holding me back from finishing up a site I've been working on.  K2 has many features by default I really enjoy.

 

The 'Save' button not working the same was as the default Joomla buttons is the only downside - unfortunately this is for a very 'user-friendly' site, where the plan is to have lots of user submissions from people who may not be tech savvy - so having the 'save' button Save the article and close the window is essential.

Has someone done this?  Is it possible?

I am interested in this solution as well...

I've noticed something when tracking this down - I've found some things I can change to make the form work as a 'save & new' type save button, but the window doesn't close.  The article does save however, and is not 'locked' by the user which is what happens when you add an article with the 'default' settings.

 

In it's default settings, when someone adds a form and clicks 'save', nothing happens (except the sidebar shows the saved information - which if you're not showing that you wouldn't even notice).  When you click "toggle sidebar" then it shows the website & the text that says the item has been saved.

It still doesn't close the window however.  That seems like a bug to me - that you have to click "toggle sidebar" to get it to trigger the save process & message.

 

I'm still digging to see if I can find where to close the window.

 

I've been able to confirm that this is indeed the case.

If you add new item from the front-end, and fill out the form (and have NOT saved it) - If you click "toggle sidebar" (hidden by default), then click "toggle sidebar" a second time - your form is cleared and nothing is saved.

 

Pretty big bug I think (if no one else has noticed this)

If you comment out the following code it will remove the 'toggle sidebar' button which should save users from figuring out this frustrating bug and losing work mid-stream ( the file is found in your_site\components\com_k2\views\item\tmpl\form.php)

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

 

 

Hanny said:

 

 

In it's default settings, when someone adds a form and clicks 'save', nothing happens (except the sidebar shows the saved information - which if you're not showing that you wouldn't even notice).  When you click "toggle sidebar" then it shows the website & the text that says the item has been saved.

It still doesn't close the window however.  That seems like a bug to me - that you have to click "toggle sidebar" to get it to trigger the save process & message.

 

 

 

I have successfully done it.

 

Scratch what I wrote earlier (although I kept the 'toggle sidebar' removed);

 

If you add the following line of code to your item.php file it will close the window after the article is saved (the file is found in your_site\components\com_k2\views\item\tmpl\form.php)

 

Add this code at or around line 36 - after the line 'submitform( pressbutton );'

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

 

So it should now look like:

<?php endif; ?>submitform( pressbutton );parent.$('sbox-window').close();

 

I'm currently working on the javascript needed to refresh the page once the window closes so you'll see the 'Item Saved' text at the top of the screen.

 

If you do not change line 254 as I said to do earlier - the article will be 'locked' on the backend - if you want the article to save without being locked you can change the text on line 254 to read:

<a class="toolbar" href="#" onclick="javascript: submitbutton('save'); return true;">

If you do this - the 'your item has been saved' text will not show - I'm working on resolving this

 

 

 

I hope this helps other people who were running into the same issue as me.

 

 

Okay, here's how it's done. I was barking up the wrong tree originally!! It's fixed and works great on every browser!! Check it out - add a little code to two places and you're good to go!

If you have users creating articles from the front end and you want the 'save' button to close the model box window that pops up when they add or edit an article - just follow the steps below to achieve this:



*Note: there are a few other fixes that work to close the box, but not refresh the page - this does both.



The key is passing an extra parameter through the URL that gets created when the user clicks "Save", then we just check to see if that parameter (which I will call 'step') exists - if it does, we refresh the page.



Lets follow along, first we must add this parameter to the URL created -

Open the item.php file located at:

Yoursite->administrator->components->com_k2->models->item.php



On or around line 646 - you will see some text that resembles:

case 'save': default: $msg = JText::_('Item Saved'); if ($front) $link = 'index.php?option=com_k2&view=item&task=edit&cid='.$row->id.'&tmpl=component'; else $link = 'index.php?option=com_k2&view=items'; break;


So what we need to do is add our parameter to that URL so it will look like this (remember I called the parameter 'step', and will be setting it =1) - the code will now look like this:



if ($front) $link = 'index.php?option=com_k2&view=item&task=edit&cid='.$row->id.'&step=1&tmpl=component';




Now when the user clicks 'save' the parameter 'step' is getting passed along, and when the form reloads to show the user their information they had entered, step=1!



So then we have to add the php to check for that - that's simple enough:

Open the form.php file located at:

Yoursite->components->com_k2->views->item->tmpl->form.php



In there you can see where the form actually begins (on or around line 249), what we want to do is just add a little bit of php that checks to see if our 'step' parameter is equal to 1. If it is - we'll refresh the parent page using some javascript, that will automatically close the model box and cause the 'item saved' text to display to the user letting them know what happened.

The existing code looks like :

<form action="index.php" enctype="multipart/form-data" method="post" name="adminForm" id="adminForm"> <div class="k2Frontend"> <table class="toolbar" cellpadding="2" cellspacing="4">




When finished it will look like this:



<form action="index.php" enctype="multipart/form-data" method="post" name="adminForm" id="adminForm"> <div class="k2Frontend"> <?php if (JRequest::getInt('step')=='1') { ?> <script language="javascript"> window.parent.location.reload(); </script> <?php } ?> <table class="toolbar" cellpadding="2" cellspacing="4">




That checks to see if 'step' is =1. If it is - it runs javascript to refresh the parent window - closing the box and refreshing the page automatically.



This ensures the easiest possible thing for the user (i.e. they don't have to click 'back' and 'refresh' which is extremely counter-intuitive) and gives the front end user a back-end experience.



I hope this helps people - it took me a LOT of chasing things in the wrong direction before I thought of this solution.

I'm pretty saddened the developers never helped with something that's affected so many people, but oh well - problem was solved!



Keep on, keepin' on!



























Okay, here's how it's done.

If you have users creating articles from the front end and you want the 'save' button to close the model
box window that pops up when they add or edit an article - just follow
the steps below to achieve this:



*Note: there are a few other fixes that work to close the box, but not refresh the page - this does both.



The key is passing an extra parameter through the URL that gets created
when the user clicks "Save", then we just check to see if that parameter
(which I will call 'step') exists - if it does, we refresh the page.



Lets follow along, first we must add this parameter to the URL created -

Open the item.php file located at:

Yoursite->administrator->components->com_k2->models->item.php



On or around line 646 - you will see some text that resembles:

case 'save': default:
$msg = JText::_('Item Saved');
if ($front)
$link =
'index.php?option=com_k2&view=item&task=edit&cid='.$row->id.'&step=1&tmpl=component';
else
$link = 'index.php?option=com_k2&view=items';
break;

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.

Thanks for the fix. For the most part it works... but sometimes it goes into an infinite loop. When I create a new post and save, it will close the K2 window and then refresh the page over and over again.

Does this happen to anyone else?

I haven't experienced that yet.

Maybe that comes from the closing the page.

 

I'll have to look into it - also, I've added the bit of code that 'checks in' the article on save as well so it works as originally intended.

I will post the code here shortly.

Many thanks for this Hanny... either way this is great logic. I've been looking for this solution for a long time too and this is hands down the most comprehensive fix.

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.