All of the examples thus far have excluded a necessary ingredient of a web application: input from the user.
The most common way you'll get input from your user is via HTML forms that will submit to your server.
(If you're not comfortable with HTML form elements, take the time now to skim through this article: MDN Forms)
To understand how form processing works, it's important to understand that the web works via this two-step process:
- Request: A client (web browser) sends a request to a server (in our case, Apache) via the HTTP protocol.
- Response: The server responds to the request (also via HTTP)
A request will include essential data such as...
- What is the address of the request?
- Is there any cookie data with the request?
- What is the IP address from which the request is coming from?
- What client type (i.e. browser) is the request coming from?
In addition to these details, input data from the user can also be sent as part of the request.
How the data is sent depends on what request type is being used— HTTP protocol supports two types: GET and POST.
- When you visit a web page (either by typing in the URL or via a link), the GET method is used.
- When you submit a form to a web page, either the GET or POST method can be used.
This semester, many of our demos will revolve around an example called foobooks, which will be a simple application for organizing a collection of books.
With that in mind, let's build a super basic iteration of foobooks to demonstrate processing a form with the GET method.
Create a new file called
foobooks.php with this code:
<form method='GET' action='search.php'> <label>Search for a book: <input type='text' name='searchTerm'> </label> <input type='submit' value='Search'> </form>
And a second new file called
search.php with this code:
<?php var_dump($_GET); echo 'You searched for '.$_GET['searchTerm'];
- The form element has a
methodattribute set to
- The form element has an
actionattribute, specifying where this form should be submitted to (
- The single input in the form has a
nameattribute, which will be used to identify that data
Run the above example and submit with the search term “fiction”.
Looking closely at the brower's URL bar, you'll note that the form data is being sent with the request via the URL:
In this example the URL is:
What follows the question mark is the query string:
A query string contains one or more key value pairs of data sent with the request. In this case, the key
searchTerm was set to the value
If you had multiple form inputs, they'd be added to the query string, separated by a ampersand, e.g.:
On the receiving end of things (i.e.
search.php), data from the query string is available via an array,
$_GET is a PHP superglobal— a built-in variable that's automatically created by PHP.
GET Summary: Submit a form via the GET method and all the data from that form will be a) viewable in the URL bar and b) accessible in your script via the $_GET superglobal.
Update the above example with the following changes:
foobooks.php, change the form method to POST
search.php, change both occurances of
foobooks.php and submit the form again.
The output should be the same, but this time the data is not appended to the URL; instead it's attached to the request “behind the scenes”.
Note what happens when you refresh the page— it asks you if you want to re-submit the form data.
GET vs. POST
- GET Requests can be bookmarked, since the data is part of the URL.
- GET Requests can only handle a limited amount of data; roughly 2k characters (give or take, depends on the browser).
- GET Requests can only handle ASCII characters.
- GET Requests should never be used for sensitive data (you don't want things like passwords revealed in the browser URL bar).
- GET Requests should only ever be used to retrieve data (i.e. show me this book, not save this book)
- POST Requests can not be bookmarked; the lifecycle of the data only exists when the request is made.
- POST has much larger data limits relative to GET, and the limits can be configured on your server.
- POST Requests can handle binary file data in addition to ASCII characters (i.e. it can be used to upload files)
- POST Requests should be used in cases where the data is effecting some change on the server. I.e. if a visitor is submitting a form to add a new book, that data will be saved to a database.
Form design flow
There are different ways you can design your form flow— the following describes three different designs.
In this design, the visitor can refresh the
search.php page and re-submit the form data, which might not be ideal if, for example, the purpose of the form is to add a new entry to a database. Given this, this design is best reserved for forms submitted via GET.
In this design,
foobooks.php submits to
search.php to process the form data, which then redirects the visitor to a confirmation page (
This design is ideal for POST forms because the visitor can refresh the confirmation page and not risk re-submitting their data which could result in unintended consequences (like repeat rows in a database table).
In order for this flow to work, we need a mechanism to pass data from the
search.php page to the
done.php page so the results can be shown. One way to do this is via PHP sessions, which are covered in this note set: Cookies and sessions.
The final form flow we'll study submits a form to a processing file (
search.php) which then redirects the visitor back to
foobooks.php, sending with it the results of the processing, also using PHP sessions (similar to Version B).
This flow can be ideal for actions like editing data (e.g. info about a book), where it's often desirable to display the form again after the changes are saved.
More form input type examples
Beyond text inputs (shown in the examples above), your project may also require checkboxes, radios, or dropdown selects. Examples of each can be seen at the following urls.
- Examples: http://php.dwa15.com/forms-inputs/
- Code for examples: https://github.com/susanBuck/dwa15-php/tree/master/forms-inputs