Form Handling and Validation

Analogy categoryAnalogies

Handling a form in PHP means three distinct steps done in order: detecting that a submission occurred, validating that every submitted value is well-formed and meets your business rules, and only then acting on the data (saving it, emailing it, redirecting). Skipping straight to using $_POST values without validation is how invalid data ends up in a database and how injection vulnerabilities creep into an application. A robust handler treats every field independently, collects all validation errors rather than stopping at the first one, and re-renders the form with those errors and the user's previously entered values so they aren't forced to start over.

🏏

Cricket analogy: Reviewing a run-out appeal properly means three steps in order: checking if the ball actually hit the stumps (detect), verifying no no-ball invalidates it (validate), and only then raising the finger (act); a third umpire who skips straight to raising the finger without checking every angle is how bad decisions happen, so a good review checks every angle independently rather than stopping at the first frame.

Detecting submission and reading raw input

Checking $_SERVER['REQUEST_METHOD'] === 'POST' is the standard way to know a form was submitted rather than the page being loaded fresh via GET. Every field should be read defensively with the null coalescing operator, $_POST['email'] ?? '', so a missing key never triggers an undefined-array-key warning; trim() should typically be applied immediately to strip stray whitespace before any further checks run.

🏏

Cricket analogy: Checking $_SERVER['REQUEST_METHOD'] === 'POST' is like an umpire first confirming a ball was actually bowled before reviewing it, rather than reviewing a non-event; reading $_POST['email'] ?? '' is like a scorer defaulting an unrecorded run to zero instead of crashing the scoreboard, and trim() is like brushing dirt off the crease line before measuring it.

php

<?php
declare(strict_types=1);

$errors = [];
$name = $email = $age = '';

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $name  = trim($_POST['name'] ?? '');
    $email = trim($_POST['email'] ?? '');
    $age   = trim($_POST['age'] ?? '');

    if ($name === '' || mb_strlen($name) > 100) {
        $errors['name'] = 'Name is required and must be under 100 characters.';
    }

    if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
        $errors['email'] = 'Please enter a valid email address.';
    }

    $ageInt = filter_var($age, FILTER_VALIDATE_INT, ['options' => ['min_range' => 13, 'max_range' => 120]]);
    if ($ageInt === false) {
        $errors['age'] = 'Age must be a whole number between 13 and 120.';
    }

    if (empty($errors)) {
        // Safe to persist: saveRegistration($name, $email, $ageInt);
        header('Location: /thank-you');
        exit;
    }
}

Validation vs sanitization vs escaping

These are three distinct operations that beginners often conflate. Validation checks whether data meets criteria and rejects it (with an error) if not — an invalid email format should produce an error message, not be silently altered. Sanitization transforms data into an acceptable form, such as trimming whitespace or stripping disallowed characters, and is appropriate when a minor cleanup is reasonable rather than a hard rejection. Escaping happens at output time, transforming data for the context it will be placed into — htmlspecialchars() for HTML, a prepared statement's parameter binding for SQL — and must happen every time data crosses into a new context, regardless of whether it was already validated on input.

🏏

Cricket analogy: Validation is like a third umpire rejecting a delivery outright if it's clearly a no-ball (bad email format = error, not fixed); sanitization is like a groundsman quietly re-marking a smudged crease line before play (trimming whitespace); escaping is like translating the scorecard into the correct format for TV graphics versus the printed program every time it's displayed, regardless of earlier checks.

PHP's filter_var() function with FILTER_VALIDATE_* constants (FILTER_VALIDATE_EMAIL, FILTER_VALIDATE_INT, FILTER_VALIDATE_URL, FILTER_VALIDATE_FLOAT) covers the majority of common single-field validation needs and returns false on failure, which composes cleanly with an if-check without needing a regular expression for common formats.

Client-side validation (HTML5 required/pattern attributes, JavaScript) improves user experience but provides zero security guarantee — it is trivial to bypass by submitting a request directly with curl or disabling JavaScript. Every field must be re-validated on the server regardless of what the client already checked.

Redisplaying the form with errors and old input

After validation fails, the form should be re-rendered rather than the user being sent back to a blank page, with each error message displayed near its corresponding field and each input's value attribute pre-filled from the submitted (but properly escaped) data — commonly written as value="<?= htmlspecialchars($name) ?>". This preserves the user's work and clearly communicates exactly what needs to be fixed, which is standard practice across virtually every production web form.

🏏

Cricket analogy: When a review fails, the umpire doesn't send the batter back to the pavilion blank-handed — the big screen re-shows the exact delivery with the specific reason marked (no-ball line, edge detection), preserving the moment rather than restarting the innings from scratch, which is standard practice in every DRS review today.

Form handling has three ordered steps: detect submission, validate every field independently, then act only if validation passes.
Check $_SERVER['REQUEST_METHOD'] to detect a POST submission; always read $_POST values defensively with the null coalescing operator.
Validation rejects bad data with an error; sanitization cleans data into an acceptable form; escaping transforms data safely for its output context.
filter_var() with FILTER_VALIDATE_* constants handles common field formats like email, integer ranges, and URLs concisely.
Client-side validation is a UX convenience only — server-side validation is mandatory since client checks are trivially bypassed.
Collect all validation errors at once and re-render the form with error messages and previously entered (escaped) values, rather than discarding user input.