As Seth mentions, when a user clicks reload or goes back with the browser button, data sent to the server, may be sent again (after a click on the ok button).
It might be wise, to let the server handle whatever there is to handle, and then redirect (a redirect is not visible in the history and thus not reachable via reload or "back".
It cannot be used in this exact example, but as Seth also mentions, this example should be using GET instead of POST
Dealing with Forms
One of the most powerful features of PHP is the way it handles HTML forms. The basic concept that is important to understand is that any form element will automatically be available to your PHP scripts. Please read the manual section on Variables from outside of PHP for more information and examples on using forms with PHP. Here is an example HTML form:
There is nothing special about this form. It is a straight HTML form with no special tags of any kind. When the user fills in this form and hits the submit button, the action.php page is called. In this file you would write something like this:
Apart from the htmlspecialchars() and (int) parts, it should be obvious what this does. htmlspecialchars() makes sure any characters that are special in html are properly encoded so people can't inject HTML tags or Javascript into your page. For the age field, since we know it is a number, we can just convert it to an integer which will automatically get rid of any stray characters. You can also have PHP do this for you automatically by using the filter extension. The $_POST['name'] and $_POST['age'] variables are automatically set for you by PHP. Earlier we used the $_SERVER autoglobal; above we just introduced the $_POST autoglobal which contains all POST data. Notice how the method of our form is POST. If we used the method GET then our form information would live in the $_GET autoglobal instead. You may also use the $_REQUEST autoglobal, if you do not care about the source of your request data. It contains the merged information of GET, POST and COOKIE data. Also see the import_request_variables() function.
You can also deal with XForms input in PHP, although you will find yourself comfortable with the well supported HTML forms for quite some time. While working with XForms is not for beginners, you might be interested in them. We also have a short introduction to handling data received from XForms in our features section.
Dealing with Forms
08-Nov-2006 10:02
19-Sep-2006 11:36
I agree that the manual is not very clear on how one should structure the files, but it is not true that the action attribute of a form always points to a different file: it can also point to the same file. Say you have a file called myForm.php with the following code:
<html>
<body>
<form method="post" action="action.php" target="_self">
<button type="submit" name="actionToTake" value="Hello there!">Say hello</button>
</form>
</body>
</html>
Then you would indeed need to create a file named action.php and have it do something like <?php echo "<html><body>".$_POST['actionToTake']."</body></html>"; ?>
But you'll often find that it is handier to let myForm.php handle your user's input, so then you would set the action to the current page, and for that PHP has a nice variable $PHP_SELF to help you:
<html>
<body>
<?php echo "actionToTake=".$_POST['actionToTake']."\n" ?>
<form method="post" action="<?php echo $PHP_SELF ?>" target="_self">
<button type="submit" name="actionToTake" value="Hello there!">Say hello</button>
</form>
</body>
</html>
Hope this helps you get started.
05-May-2005 02:18
[Editor's Note: Since "." is not legal variable name PHP will translate the dot to underscore, i.e. "name.x" will become "name_x"]
Be careful, when using and processing forms which contains
<input type="image">
tag. Do not use in your scripts this elements attributes `name` and `value`, because MSIE and Opera do not send them to server.
Both are sending `name.x` and `name.y` coordiante variables to a server, so better use them.
01-Dec-2003 02:55
According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.
You should use the GET method when your form is, well, getting something off the server and not actually changing anything. For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
