Superglobals
Every chapter so far has used data written directly into the script. Real web applications need to receive data from the visitor — typed into a form, or included in the URL. PHP exposes this through a set of special built-in arrays called superglobals, available automatically in every scope without needing to be passed in.
$_GET — Data From the URL
Everything after the ? in a URL is a query string — pairs of key=value joined with &. PHP parses this automatically into the $_GET array. This is exactly how search results pages, filtered listings, and pagination links typically pass information.
$_POST — Data From a Submitted Form
A form's method="post" sends its field values in the request body rather than visibly in the URL — used for anything that changes data, submits sensitive information (like a password), or sends a larger amount of data than comfortably fits in a URL.
GET vs POST — When to Use Which
| Use GET when… | Use POST when… |
|---|---|
| The request just retrieves/filters data (a search, a page link) | The request changes something (a comment, an order, a login) |
| It's fine for the data to appear in the URL, and be bookmarkable | The data is sensitive, or simply too large for a URL |
Checking Whether Data Was Actually Submitted
$_POST['username'] would trigger an "undefined array key" warning. Checking $_SERVER['REQUEST_METHOD'] first, and using the ?? null coalescing operator (from Chapter 3) as a fallback, are both genuinely standard defensive habits.
$_SERVER — Information About the Request and Environment
$_SERVER holds a large set of details about the current request and the server environment — used far more sparingly than $_GET/$_POST, but genuinely useful for logging, basic analytics, or deciding behaviour based on the request method.
$_GET/$_POST values straight back out, which is fine for learning but is NOT safe for a real, public-facing site — a visitor could submit HTML or script tags as their "username" and have them rendered on the page (a vulnerability called XSS, Cross-Site Scripting). The fix — htmlspecialchars() — and broader input validation are covered properly in the Intermediate course; treat every example in this chapter as for learning the data-flow mechanics only, not as production-ready code.
Coding Challenges
Write a simple HTML form with a text input named "city" that submits to itself using GET. In the same file, check if "city" is present in $_GET and if so, echo "You searched for: [city]" — otherwise echo "Enter a city above."
Write a form with two number inputs, "num1" and "num2", submitting via POST. On submission, add the two numbers together and echo the result — remember $_POST values arrive as strings, so consider whether you need to cast them.
📄 View solutionWrite a script that checks $_SERVER['REQUEST_METHOD'] and echoes "This was a GET request" or "This was a POST request" accordingly. Test it by visiting the page normally (GET) and by submitting a simple test form that posts to it.
Chapter 8 Quick Reference
- $_GET — data from the URL's query string (?key=value)
- $_POST — data from a form submitted with method="post"
- GET vs POST — GET for retrieving/filtering, POST for changing data or sensitive input
- $_SERVER['REQUEST_METHOD'] — check this before assuming $_POST data exists
- ?? (null coalescing) — safe fallback for a possibly-missing array key
- $_SERVER — request/environment info: method, script path, user agent, IP
- Security note — never echo raw user input on a real site; htmlspecialchars() and validation come in the Intermediate course
- Next chapter: includes — include, require, and organising code across multiple files