I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button when
I click the refresh button?
Shelly
17  1694 
On Monday 13 November 2006 23:17, Shelly [sh************@asap-consult.com]
wrote in message <C2*****************@newsread2.news.pas.earthlink. net>
I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If
I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button
when I click the refresh button?
Dunno, being a relative newbie to PHP, but a quick Google brings up this
link - http://uk.php.net/isset
Does that help?
"PDannyD" <da*****@scenicplace.freeserve.co.ukwrote in message
news:45591793.0@entanet...
On Monday 13 November 2006 23:17, Shelly [sh************@asap-consult.com]
wrote in message <C2*****************@newsread2.news.pas.earthlink. net>
>I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If
I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button
when I click the refresh button?
Dunno, being a relative newbie to PHP, but a quick Google brings up this
link - http://uk.php.net/isset
Does that help?
The VERY first place I went to was www.php.net. No, it didn't help because
it didn't tell me how to unset a POST'd variable. Thanks anyway.
Shelly
Shelly wrote:
I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button when
I click the refresh button?
Shelly
You can't just unset a $_POST variable (well, you can, but it won't work
like you want). When your user hits reload on the browser, the browser
will resend the post, setting it again.
You can, for instance, have the submit button go to another page to
process the data, then redirect back to your original page with a
header() call.
You can also set a value in the $_SESSION to indicate the page was
submitted; you just need to ensure you have a way of unsetting it once
they leave that page.
There are other ways - but these are the two I use most often.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:EJ******************************@comcast.com. ..
Shelly wrote:
>I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If
I now click the browser refresh button, I get another submittal. How do
I "unset" the status so that it doesn't think I clicked the submit button
when I click the refresh button?
Shelly
You can't just unset a $_POST variable (well, you can, but it won't work
like you want). When your user hits reload on the browser, the browser
will resend the post, setting it again.
You can, for instance, have the submit button go to another page to
process the data, then redirect back to your original page with a header()
call.
I already tried something like this just after I submitted the original
post. I had the original submit button force the processing of the post and
at the end of that processing it was sent to another page, pageRedir.php,
via a header. In pageRedir.php I had it go immediately via a header back to
the original page. A refresh of that original page then still resulted in
another processing.
Anyway, a refresh would still satisfy the isset for the submit button so it
would still be sent to another page. I don't see how this gains anything.
>
You can also set a value in the $_SESSION to indicate the page was
submitted; you just need to ensure you have a way of unsetting it once
they leave that page.
I thought of this too, but didn't see how I could guarantee an unsetting of
the session variable. There are so many ways to leave a page :-). So, I
abandoned this line of thought.
There are other ways - but these are the two I use most often.
Shelly wrote:
If I do a submit and have it come back to the same page, all is fine. If I
now click the browser refresh button, I get another submittal.
Its browser behaviour we can't do anything with php. If you do not want
another submittal when you refresh it, use GET method instead of POST.
-- http://www.mastervb.net http://www.theukmap.com
"lorento" <la**********@yahoo.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Shelly wrote:
>If I do a submit and have it come back to the same page, all is fine. If
I
now click the browser refresh button, I get another submittal.
Its browser behaviour we can't do anything with php. If you do not want
another submittal when you refresh it, use GET method instead of POST.
I wrote a test script with get. It still goes in there.
<?php
session_start();
if (!isset($_SESSION['count'])) $_SESSION['count'] = 0;
if (isset($_GET['test'])) {
echo "Got inside get... <br>";
echo "text=" . $_GET['text'] . "<br>";
$_SESSION['count'] += 1;
if ($_GET['text'] != "get") {
echo "count=" . $_SESSION['count'] . "<br>";
}
$foo = "get";
}
?>
Shelly wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:EJ******************************@comcast.com. ..
>>Shelly wrote:
>>>I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine. If
I now click the browser refresh button, I get another submittal. How do
I "unset" the status so that it doesn't think I clicked the submit button
when I click the refresh button?
Shelly
You can't just unset a $_POST variable (well, you can, but it won't work
like you want). When your user hits reload on the browser, the browser
will resend the post, setting it again.
You can, for instance, have the submit button go to another page to
process the data, then redirect back to your original page with a header()
call.
I already tried something like this just after I submitted the original
post. I had the original submit button force the processing of the post and
at the end of that processing it was sent to another page, pageRedir.php,
via a header. In pageRedir.php I had it go immediately via a header back to
the original page. A refresh of that original page then still resulted in
another processing.
Anyway, a refresh would still satisfy the isset for the submit button so it
would still be sent to another page. I don't see how this gains anything.
That's because you didn't do it like I described. You must have a
DIFFERENT page doing the processing. You can then redirect back to the
original page, if you wish.
>
>>You can also set a value in the $_SESSION to indicate the page was
submitted; you just need to ensure you have a way of unsetting it once
they leave that page.
I thought of this too, but didn't see how I could guarantee an unsetting of
the session variable. There are so many ways to leave a page :-). So, I
abandoned this line of thought.
Or if you have a page leading up it this one, reset it there. For
instance, if this is a confirmation page, you can reset the bit on the
original page where the data was entered.
>
>>There are other ways - but these are the two I use most often.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
["Followup-To:" header set to comp.lang.php.]
Shelly wrote:
If I click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button when
I click the refresh button?
You don't.
What you can do is keep a variable for that specific form.
When you receive the submission, verify the variable to check whether
it's the first post.
<?php
session_start();
if (isset($_POST['theSubmitButton'])) {
if ($_SESSION['submitted']) {
// OOPS!
} else {
$_SESSION['submitted'] = true;
// rest of script;
}
}
// ...
echo '<input type="submit" name="theSubmitButton">';
$_SESSION['submitted'] = false;
// ...
?>
--
I (almost) never check the dodgeit address.
If you *really* need to mail me, use the address in the Reply-To
header with a message in *plain* *text* *without* *attachments*.
"Pedro Graca" <he****@dodgeit.comwrote in message
news:sl*******************@ID-203069.user.individual.net...
["Followup-To:" header set to comp.lang.php.]
Shelly wrote:
>If I click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button
when
I click the refresh button?
You don't.
What you can do is keep a variable for that specific form.
When you receive the submission, verify the variable to check whether
it's the first post.
<?php
session_start();
if (isset($_POST['theSubmitButton'])) {
if ($_SESSION['submitted']) {
// OOPS!
} else {
$_SESSION['submitted'] = true;
// rest of script;
}
}
// ...
echo '<input type="submit" name="theSubmitButton">';
$_SESSION['submitted'] = false;
// ...
?>
This would work in most cases, but not in my situation. You see, my case is
that I display a list of entries (notes) from the database in reverse
chronological order of entry. At the top of the form I have a set of fields
to add a new entry. After the entry is added (via the update) it displays
the the new list with the new entry at the top. The user must be able to
add yet another entry if he puts one in and clicks the submit. What I want
to avoid is having an entry there because of the refresh button.
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:5d******************************@comcast.com. ..
Shelly wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:EJ******************************@comcast.com ...
>>>Shelly wrote:
I have the following for a test of the submit button being pressed:
if (isset($_POST['theSubmitButton'])) {
This works fine and I have been doing this for a long time. Here is the
question:
If I do a submit and have it come back to the same page, all is fine.
If I now click the browser refresh button, I get another submittal. How
do I "unset" the status so that it doesn't think I clicked the submit
button when I click the refresh button?
Shelly
You can't just unset a $_POST variable (well, you can, but it won't work
like you want). When your user hits reload on the browser, the browser
will resend the post, setting it again.
You can, for instance, have the submit button go to another page to
process the data, then redirect back to your original page with a
header() call.
I already tried something like this just after I submitted the original
post. I had the original submit button force the processing of the post
and at the end of that processing it was sent to another page,
pageRedir.php, via a header. In pageRedir.php I had it go immediately
via a header back to the original page. A refresh of that original page
then still resulted in another processing.
Anyway, a refresh would still satisfy the isset for the submit button so
it would still be sent to another page. I don't see how this gains
anything.
That's because you didn't do it like I described. You must have a
DIFFERENT page doing the processing. You can then redirect back to the
original page, if you wish.
Got it! I wrote a little test pair and it worked just as you said. Thanks.
Shelly
"Jerry Stuckle" <js*******@attglobal.netwrote in message
That's because you didn't do it like I described. You must have a
DIFFERENT page doing the processing. You can then redirect back to the
original page, if you wish.
I just put it into my code. I sent it to a notesRedir.php where I do the
processing and then header back to original. It worked like a charm.
Thanks again, Jerry.
Shelly
Shelly wrote:
You see, my case is
that I display a list of entries (notes) from the database in reverse
chronological order of entry. At the top of the form I have a set of fields
to add a new entry. After the entry is added (via the update) it displays
the the new list with the new entry at the top. The user must be able to
add yet another entry if he puts one in and clicks the submit. What I want
to avoid is having an entry there because of the refresh button.
I see you got it! :)
And I like the different page technique better, too!
Anyway, if you want to trust your users ( *NEVER DO THAT* ), maybe this
little change would work:
<?php
session_start();
if (isset($_POST['theSubmitButton'])) {
if ($_SESSION[$_POST['tid']]['submitted']) {
// OOPS!
} else {
$_SESSION[$_POST['tid']]['submitted'] = true;
// rest of script;
}
}
// ...
echo '<input type="submit" name="theSubmitButton">';
$tid = md5(time());
$_SESSION[$tid]['submitted'] = false;
echo '<input type="hidden" name="tid" value="', %tid, '">';
// ...
?>
--
I (almost) never check the dodgeit address.
If you *really* need to mail me, use the address in the Reply-To
header with a message in *plain* *text* *without* *attachments*.
..oO(Shelly)
>If I do a submit and have it come back to the same page, all is fine. If I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button when
I click the refresh button?
After processing the form data use a header() call to redirect the
browser to the same page. If you hit refresh then, the browser just
sends a normal GET instead of repeating his previous POST request.
This also prevents another thing, which could annoy or confuse visitors:
Assume a normal POST submission without a following redirect. If you now
move on to another page and then go back to the previous one using the
browser's 'back' function, in most browsers an ugly message will pop up,
telling you that the page has expired or that is was the result of a
POST operation and asks if the browser should send the POST data again.
Micha
"Michael Fesser" <ne*****@gmx.dewrote in message
news:3a********************************@4ax.com...
.oO(Shelly)
>>If I do a submit and have it come back to the same page, all is fine. If
I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button
when
I click the refresh button?
After processing the form data use a header() call to redirect the
browser to the same page. If you hit refresh then, the browser just
sends a normal GET instead of repeating his previous POST request.
Befoe I fixed it with Jerry's suggestion to send it to another page for
processing and then have that send it back when done, I had a header
statement going to the same page. A refresh STILL resulted in another post
because it passed the isset($_POST['theButton']) test. So, if it sends a
normal GET instead of a POST, why did it still satisfy that isset test?
Shelly
..oO(Shelly)
>Befoe I fixed it with Jerry's suggestion to send it to another page for
processing and then have that send it back when done, I had a header
statement going to the same page. A refresh STILL resulted in another post
because it passed the isset($_POST['theButton']) test. So, if it sends a
normal GET instead of a POST, why did it still satisfy that isset test?
Good question, I can't reproduce that.
Micha
"Michael Fesser" <ne*****@gmx.dewrote in message
news:l6********************************@4ax.com...
.oO(Shelly)
>>Befoe I fixed it with Jerry's suggestion to send it to another page for
processing and then have that send it back when done, I had a header
statement going to the same page. A refresh STILL resulted in another
post
because it passed the isset($_POST['theButton']) test. So, if it sends a
normal GET instead of a POST, why did it still satisfy that isset test?
Good question, I can't reproduce that.
Micha
Strange! When I jsut wrote a very basic one, I got that ugly retry message
on hitting the browser refresh. Of course, the resend then passed the test
and the cancel left me on page 404 :-) Previousely it passed the test?????
Changing things to a GET caused both the submit button and the refresh
button to pass the isset test of the $_GET.
Shelly
Shelly wrote:
"Michael Fesser" <ne*****@gmx.dewrote in message
news:3a********************************@4ax.com...
>>.oO(Shelly)
>>>If I do a submit and have it come back to the same page, all is fine. If
I
now click the browser refresh button, I get another submittal. How do I
"unset" the status so that it doesn't think I clicked the submit button
when
I click the refresh button?
After processing the form data use a header() call to redirect the
browser to the same page. If you hit refresh then, the browser just
sends a normal GET instead of repeating his previous POST request.
Befoe I fixed it with Jerry's suggestion to send it to another page for
processing and then have that send it back when done, I had a header
statement going to the same page. A refresh STILL resulted in another post
because it passed the isset($_POST['theButton']) test. So, if it sends a
normal GET instead of a POST, why did it still satisfy that isset test?
Shelly
Shelly,
Because it doesn't. If the original request was a POST, the refresh
will also be a POST.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: sg |
last post by:
Hi,
I use sessions on my site and i have an admin page where I want to be able
to unset all session variables and destroy the session.
for the moment I do :
<?
session_unset();...
|
by: TooN |
last post by:
Hi,
I'm building an application with over 10thousand database entries. I
was wondering if it would be useful, regarding memory load and server
performance to unset/destroy objects at the moment...
|
by: Sylvian Stone |
last post by:
Hi there - I'm experiencing a very frustrating problem with an
application that submits POST info to a session control file which
then echo's it back to the controls if the page is returned to.
...
|
by: Pete |
last post by:
I have some session variables which get set on page one of my site. I
can set an unset these by passing through a parameter in some URL's.
When the user goes to the second page some checkboxes are...
|
by: Xerxes |
last post by:
Hi,
I have a cart, setup as an associative array (itemid=>qty). When the
cart is displayed, the quantity field is an input box and the value can
be changed to add/remove an item:
echo '<input...
|
by: Csaba Gabor |
last post by:
I have an IMG placeholder for what will normally be a tiny (6x7) img.
Sometimes however, I will use a somewhat larger but still small image.
How can I unset the dimensions for the <IMG...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
