Complete PHP Tutorial

PHP carries a reputation formed around 2009 and rarely updated since. The language people describe — no types, inconsistent standard library, sprawling include files — is PHP 5. The language you would actually write today has scalar and return types, nullable and union types, enums, readonly properties, constructor promotion, fibers, a JIT compiler, and a package manager that made the ecosystem coherent.

That gap matters practically, because the internet is full of PHP advice written for the old language. Code that uses mysql_* functions, builds queries by concatenation, or suppresses errors with @ is not merely dated — it is teaching habits that cause the exact security bugs PHP is blamed for.

What modern PHP actually looks like

The single biggest change is that types are now worth using. With declare(strict_types=1) PHP stops coercing arguments silently, which turns a class of quiet wrong-answer bugs into immediate errors — and makes static analysis genuinely useful.

<?php
declare(strict_types=1);

enum Status: string {
    case Active   = 'active';
    case Disabled = 'disabled';
}

final class User
{
    public function __construct(          // constructor promotion
        public readonly int $id,          // immutable after construction
        public readonly string $email,
        public readonly Status $status = Status::Active,
    ) {}

    public function isActive(): bool      // return type, checked
    {
        return $this->status === Status::Active;
    }
}

// Null-safe chaining instead of nested isset()
$city = $user?->address?->city ?? 'unknown';

The three errors that account for most PHP support tickets

All three share a shape worth noticing: the limit is a symptom, and the fix is upstream of it. That is true of most PHP configuration errors — php.ini is where the problem surfaces, not where it lives.

Security: the two habits that matter most

PHP's security reputation comes almost entirely from two patterns, and both have had a correct answer built into the language for over a decade. Queries must be parameterised through PDO, not assembled with string interpolation. Passwords must go through password_hash, which selects a strong algorithm, generates a salt, and stores its own parameters so you can raise the cost later without invalidating existing hashes.

Output escaping is the third habit and the one most often applied inconsistently. Escape at the point of output, for the context you are outputting into — HTML body, attribute, JavaScript and URL all need different treatment, which is the argument for a templating engine that escapes by default rather than manual calls scattered through views.

<?php
// Queries: placeholders, never interpolation
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email AND status = :s');
$stmt->execute(['email' => $email, 's' => Status::Active->value]);
$user = $stmt->fetch(PDO::FETCH_ASSOC);

// Passwords: let PHP choose and record the parameters
$hash = password_hash($plain, PASSWORD_DEFAULT);

if (password_verify($plain, $user['password_hash'])) {
    if (password_needs_rehash($user['password_hash'], PASSWORD_DEFAULT)) {
        $newHash = password_hash($plain, PASSWORD_DEFAULT);   // upgrade on login
    }
}

// Output: escape for the context you are writing into
echo htmlspecialchars($comment, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');

Where PHP still wins

PHP's shared-nothing request model is genuinely underrated. Every request starts from a clean state, so a memory leak or a corrupted global in one request cannot affect the next — a class of production incident that long-lived application servers in other languages still fight. Deployment is a file copy. Hosting is cheap and universal.

The result is that PHP remains an excellent fit for content-heavy sites, CMS work, and conventional CRUD applications where time to first working version matters more than raw throughput. It is a poor fit for long-lived stateful connections and CPU-bound computation — not because it cannot, but because other runtimes were designed for it.