How would one store what a user or visitor typed in an input field in a php variable.
Wouldn’t there also have to be a submit button to tell the php script that the user is done typing and to store the inputted text at that moment?
The browser has to send the form data to the server, this is usually done by clicking on a form submit button.
The form data can be sent to the server in the query string (form method=“GET”, in the php script the data is found in the $_GET superglobal) or as post data (form method=“POST”, in the php script the data is found in the $_POST superglobal).
GET is read by PHP through $_GET and POST is read by PHP through $_POST. Do NOT use REQUEST. While it isn’t important to you now to to distinguish between the two now it will become important and it’s a hard habit to break.
GET
GET requests are meant for read operations from the server. They are transmitted in the URL request.
Example from this very page:
http://www.sitepoint.com/forums/newreply.phpdo=newreply&noquote=1&p=4742197
PHP will see this
echo $_GET['do']; // 'newreply'
echo $_GET['noquote']; // '1'
echo $_GET['p']; // '4742197'
An important thing to remember, if you use a GET the browser will remember the page and the user will be allowed to bookmark the page! If you think the user would want to do this then GET is probably the right route - for example, results from a search form should be retrieved by GET.
GET is somewhat limited in the size of the data that can be transmitted - usually less than 4K, sometimes even shorter - 1K is the safe limit.
POST
POST is meant for write operations that will change the state of the server data. When I finish this post it will be sent to PHP by the POST operation. POST data is sent separately from the URL. POST is the default form transmission method, so if you do <form> without specifying the method it will be sent as a POST. POST requests can get very large - into the megabytes or even gigabytes when posting files - their upper limit is configurable in PHP’s ini file.
POST page results cannot be bookmarked and the browser will not “remember” them, though it can reach them via the back button.
Given this form
<form method="post" action="index.php">
<input type="text" name="fruit" value="apple">
<input type="text" name="veggie" value="veggie">
<input type="submit" name="submit" value="Go">
</form>
When the submit button is pressed index.php will see…
echo $_POST['fruit']; // apple
echo $_POST['veggie']; // vegetable
echo $_POST['submit']; // Go
The Evil $_REQUEST
As mentioned before, request is evil - don’t use it. Why is this so. Well, here…
<form action="index.php?action=write" method="post">
<input type="hidden" name="action" value="read">
</form>
$_REQUEST holds both post and get data, but one overwrites the other, usually in Get, then Post, then Cookie order. But the order is configurable from outside the script, hence you cannot predict it’s value! This can be a security risk. In the above example action is being transmitted by GET and POST simultaneously (So yes, it is possible to mix get and post methods - not advised but possible). Will $_REQUEST[‘action’] = ‘read’ or ‘write’? I don’t know off the top of my head, but I don’t have to worry about it cause I don’t use request - ever (anymore).
By avoiding REQUEST you also have the option of having action mean something different depending on whether GET or POST carries it. For example, $_GET[‘save’] could bring up the form to save something, while $_POST[‘save’] would actually commit the save to the database.