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:

Example 2-6. A simple HTML form
<form action="action.php" method="post"> <p>Your name: <input type="text" name="name" /></p> <p>Your age: <input type="text" name="age" /></p> <p><input type="submit" /></p> </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:

Example 2-7. Printing data from our form

Hi <?php echo $_POST['name']; ?>. You are <?php echo $_POST['age']; ?> years old.
A sample output of this script may be:
Hi Joe. You are 22 years old.

It should be obvious what this does. There is nothing more to it. 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.

User Contributed Notes
Dealing with Forms

yasman at phplatvia dot lv
05-May-2005 03:18


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-Apr-2005 11:09


That is only if you don't do validation on the .php page.

You should create a method that checks if the current user has permission to delete.

user at NOSPAM dot example dot com
25-Nov-2004 01:38


Doing something like:



"delete from some_table where id=' " . $_GET['id']



could be a bad idea from a security standpoint.



All a hacker has to do is change the URL to something like:



blah.com?id=1 or id != 1



...and delete all the rows from some_table.

grant_floyd at yahoo dot not dot yohoo dot com
22-Apr-2004 12:54


Refering to the GET/POST usage in the HTML specification mentioned:



Although GET will normally be used for requesting information from a webserver the length of the URL is limited to a maximum number of characters. So if you have a form which submits lots of information and text selections you will have to use a POST.



Likewise, sometimes it doesn't make any sense to create a form with a POST method to do something to the server.



For example, if you have a website with a list of users and you want to select one of them to delete, each username could be a 'Delete user' link.  It is easier to create a link called /website/deleteuser.php?id=<userid> for each, where deleteuser.php contains the (pseudocode):



"delete from usertable where id =" . $_GET['id']



Finally, $_REQUEST is the simplest default retrieval method as it combines GET, POST and COOKIE information. One thing to be aware of is that it combines the information in an order of precedence defined by the server.



For example, if a website has a cookie with $username and you make up a POST form and use a variable '$username' you may get the $_POST['username'] value instead of the $_COOKIE['username'], causing you some confusion.



The order is defined on the server as 'variables_order'. This set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". So in the above example 'P' for POST comes before 'C' for COOKIE.

sethg at ropine dot com
01-Dec-2003 03: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.

RobertMaas at YahooGroups dot Com
31-Aug-2003 01:48


Regarding debate over GET and POST method:

One disadvantage of the POST method is that you can't

bookmark it in a URL. So if you want ot make a URL

that bookmarks both the WebPage and some form contents,

you have to use the GET method, i.e. webpage?formcontents.

Warning, the Apache server logs the complete URL including

formcontents in a file that anyone can read, so be sure

never to include a password in the form in GET method,

regardless of whether bookmarked or onetime.



For example, my CGI site has a login form, and I have

a bookmark for specifying my own (rather long) e-mail

address, but do *not* include my password in that bookmark,

rather I click on the link and get the login form with

my e-mail address already filled in but I still have

to type my password, and of course it's a POST instead

of GET form when I then submit it with password.

http://shell.rawbw.com/~rem/cgi-bin/

  LogForm.cgi?id=RobertMaas@YahooGroups.Com

(Cliki complained it was too long so I had to split it.)