[RESOLVED] Best way to clear session vars with RESET button ?

[Stinger51]

When going back to a previous page because the form validation directs the user to go back due to an input error, I typically use a variable construction on the page that is doing the validation like this:

$SESSION['svMyVar'] = $POST[$my_var]; // store var from previous page as a session var

Then, when returning to the previous page I use this:

$my_var = $_SESSION['svMyVar']; // restore the original var

So, I can now repopulate the associated form field (e.g. a text input box) with the original value. Hey, nobody wants to piss off the user by making them re-enter any values, right? :queasy:

I'm not sure this is the best way to do this, but this technique works fine . . . EXCEPT when I go to clear the original form with a RESET button (maybe the user wants to start completely over, who knows?). The session vars do not clear, only non session vars are cleared.

So, how can I clear the session vars using the RESET button? (Yeah, yeah, I know, use Javascript for form validation and never leave the page. :rolleyes: But that won't help me here with the session vars).

Thanks in advance.

[bradgrafelman]

Are you talking about a real reset button, as in:

<input type="reset">

? If so, you'll either need to a) use some AJAX to send a request back to your server so that you know to clear the session, or b) change it to a submit button that actually submits the form to a script that detects which button (Submit vs. Reset) was pressed and acts accordingly (such as possibly re-displaying the form again after clearing out the session).

[Stinger51]

Thanks for your suggestion. Here is what I tried.

On form 1, I have this "reset" button:

<input type = 'submit' name = 'reset' value = 'Clear Form'>

On form 2, I have this code at the top of the page:

session_start();
if (isset ($POST['reset']))
{
unset($SESSION['svMyVar']); // clear the session var
header("Location: first_form.php"); // send the user back to form 1
}

However, upon returning to form 1, the session var still holds the original value! I even tried throwing in the kitchen sink by putting the following inside the curly braces (before the redirection):

session_unregister($SESSION['svMyVar']);
$SESSION['svMyVar'] = ' ';
session_destroy();

But the session value refuses to be cleared of any value! I have also made sure that register_globals = off in the php.ini file.

The interesting thing is, if I hard code this line on form 1 :

unset($_SESSION['svMyVar']);

then the variable is finally cleared. But that won't help me here, because this will clear the variable every time the form is loaded (I just wanted to see if it would work).

I'm out of clues on this one.

[bradgrafelman]

For one, definitely don't use [man]session_unregister/man (for reasons that should become obvious once you visit it's manual page).

For another, try adding a call to [man]session_write_close/man after you clear the appropriate session variable but before you do the header() redirect. Also, after you call header() to redirect the user back to the form, consider adding an [man]exit[/man] so that the script immediately ends execution.

[Stinger51]

>> Also, after you call header() to redirect the user back to the form, consider adding an exit so that the script immediately ends execution. <<

Thanks, that solved the problem. I'm not sure why, other than the script must have kept running after the redirection? Seems kind of crazy. Why would the script continue to run after the redirection? But making sure the script terminated with the exit() solved everything.

Much obliged.

[bradgrafelman]

Stinger51;10993672 wrote:

Why would the script continue to run after the redirection?

Why wouldn't it? You simply told PHP to include a certain HTTP header whenever it comes to the point of sending these headers to the client.

Calling [man]header/man with a 'Location:' HTTP header does not redirect anything; it simply queues up an HTTP header to be sent (along with several others).

[Stinger51]

That is an astounding observation. I've never seen this topic discussed about 'redirection' and the header() function anywhere else -- save here. Even the PHP.net manual does not discuss this peculiarity.

So, I've learned a good lesson here, that sending a raw header does not terminate the rest of the PHP script. This seems to get into the grey area between the machinations between Apache server and the inner workings of PHP (or other scripting languages).

Very interesting, as Artie Shaw would say.

Thanks again for your insight into this. This have saved me from pulling out all my hair, or at least beating my skull to death on the PHP Altar.

[bradgrafelman]

Stinger51;10993735 wrote:

I've never seen this topic discussed about 'redirection' and the header() function anywhere else -- save here. Even the PHP.net manual does not discuss this peculiarity.

What "peculiarity" ? And yes, the manual page for [man]header/man does show using 'Location:' headers followed by a call to [man]exit[/man] so that the rest of the code is not executed.

Stinger51;10993735 wrote:

sending a raw header does not terminate the rest of the PHP script.

Of course not... all HTTP requests and responses are preceded by HTTP headers. Why would sending a header terminate a script when it hasn't even gotten a chance to start sending output yet?

Stinger51;10993735 wrote:

This seems to get into the grey area between the machinations between Apache server and the inner workings of PHP (or other scripting languages).

What grey area? Apache simply spits out whatever PHP tells it to, including HTTP headers.

EDIT: As an example of what I was referring to above in the PHP manual, take this simple code example provided in the 'Parameters' section:

PHP Manual wrote:

<?php
header("Location: http://www.example.com/"); /* Redirect browser */

/* Make sure that code below does not get executed when we redirect. */
exit;
?>

Note the second code comment not only explains the need for [man]exit[/man] to prevent PHP from continuing on to the rest of the code, but it also shows that no 'redirection' has been done at all (the comment says "when we redirect", as if talking about the future, not "when we redirected" as if the header() call itself caused a redirection).