History & Versions

PHP started life as something far smaller than a "programming language." In 1994, Rasmus Lerdorf wrote a set of Perl scripts to track visits to his online résumé and released them the following year as "Personal Home Page Tools" (PHP Tools) — a grab-bag of CGI binaries for handling forms and displaying dynamic content. There was no grand design for a language ecosystem; it was a practical toolkit that happened to solve a problem enough other people also had. Understanding that origin story matters because a lot of PHP's quirks — its permissive type system, its huge and inconsistently named standard library, its focus on "just get the web page rendered" — trace directly back to being built pragmatically, one feature at a time, rather than designed up front.

From a toolkit to a language: PHP/FI and PHP 3

Lerdorf's tools grew into "PHP/FI" (Personal Home Page / Forms Interpreter), which added a proper parser and database support. By 1997, two other developers, Andi Gutmans and Zeev Suraski, rewrote the parsing engine from scratch and released it as PHP 3 — the first version that looked recognizably like the PHP still in use today, with a consistent syntax and support for third-party extensions. At this point "PHP" stopped standing for "Personal Home Page" and became the recursive backronym still used now: PHP Hypertext Preprocessor.

PHP 4: the Zend Engine arrives (2000)

Gutmans and Suraski rewrote the interpreter's core a second time, naming it the Zend Engine (a blend of their first names). PHP 4 shipped on top of it in May 2000 and was dramatically faster and more reliable than PHP 3, with better session handling and support for a much wider range of web servers. The Zend Engine has remained the foundation of every PHP release since — what changed in later versions is which iteration of that engine ships underneath.

PHP 5: real object-oriented programming (2004)

PHP 3 and 4 had bolted-on, half-finished object support: objects were copied by value like any other variable, there was no concept of visibility (public/private/protected), and no interfaces. PHP 5 introduced Zend Engine II, which rebuilt the object model from the ground up — objects now behave like proper references, and the language gained visibility modifiers, abstract classes, interfaces, exceptions (try/catch), and static members. This is the release that made PHP a credible platform for building structured applications rather than loose scripts, and it is roughly the baseline that most "classic" PHP tutorials and legacy codebases still assume.

A PHP 5-style class — this syntax still works today

PHP

<?php

class Invoice
{
    private float $total;

    public function __construct(float $total)
    {
        $this->total = $total;
    }

    public function formatted(): string
    {
        return '$' . number_format($this->total, 2);
    }
}

$invoice = new Invoice(1299.5);
echo $invoice->formatted();

PHP 7: the performance leap (2015)

There was never a widely released PHP 6 — an ambitious project by that name (focused on native Unicode support) was abandoned after years of stalled development, and the version number was retired to avoid confusion with documentation that already referenced it. When the next major release shipped in December 2015, it jumped straight to PHP 7. Its headline feature was an internal rewrite of the Zend Engine, developed under the project name "phpng" (PHP Next Generation) and released as Zend Engine 3. It restructured how PHP represents values in memory, roughly doubling real-world throughput and cutting memory usage compared to PHP 5, with no changes required to most existing application code. PHP 7 also added scalar type declarations (int, string, float, bool on function signatures), return type declarations, and the null coalescing operator ??.

Features PHP 7 made possible

PHP

<?php

function formatPrice(float $amount): string
{
    return '$' . number_format($amount, 2);
}

$config = $userConfig['theme'] ?? 'light'; // null coalescing operator

echo formatPrice(19.999); // $20.00

PHP 8: modern PHP (2020 onward)

PHP 8.0, released in November 2020, brought a JIT (Just-In-Time) compiler — code paths that benefit from it can be compiled to machine code at runtime instead of being interpreted every call, which helps CPU-bound workloads far more than typical request/response web pages, but matters a great deal for things like image processing or long-running scripts. Alongside the JIT, PHP 8.0 introduced union types (int|string), named arguments, the match expression, attributes (structured, native annotations replacing docblock comments), constructor property promotion, and nullsafe operator (?->). Point releases kept adding real language features rather than only bug fixes: PHP 8.1 added enums and readonly properties; PHP 8.2 added readonly classes and disjunctive normal form types; PHP 8.3 added typed class constants. Each of these tightens PHP's type system and reduces the amount of boilerplate needed to write correct code.

PHP 8.1+ features working together

PHP

<?php

enum Status: string
{
    case Draft = 'draft';
    case Published = 'published';
}

final class Article
{
    public function __construct(
        public readonly string $title,
        public readonly Status $status = Status::Draft,
    ) {
    }
}

function describe(Article $article): string
{
    return match ($article->status) {
        Status::Draft => "{$article->title} is not live yet",
        Status::Published => "{$article->title} is live",
    };
}

$post = new Article(title: 'Launch day', status: Status::Published);
echo describe($post);

Notice how much this example leans on features that did not exist before PHP 8.1: the backed enum, readonly constructor-promoted properties, and named arguments (title:, status:) at the call site. None of this is exotic — it is ordinary, idiomatic PHP for anyone writing against a current PHP version.

Version comparison at a glance

Version	Year	Headline change
PHP/FI	1995	Original CGI toolkit by Rasmus Lerdorf
PHP 3	1998	First rewrite; recognizable modern syntax
PHP 4	2000	Zend Engine introduced
PHP 5	2004	Zend Engine II; real OOP (visibility, interfaces, exceptions)
PHP 7	2015	Zend Engine 3 ("phpng"); major performance jump, scalar types
PHP 8.0	2020	JIT compiler, union types, match, attributes, named arguments
PHP 8.1	2021	Enums, readonly properties, fibers, first-class callable syntax
PHP 8.2	2022	Readonly classes, disjunctive normal form types
PHP 8.3	2023	Typed class constants, json_validate()

How PHP is released and supported today

Since PHP 8.0, the project has settled into a predictable annual cadence: a new minor version (8.1, 8.2, 8.3, and so on) ships roughly once a year, each adding new features on top of the same major version's engine. Every release then goes through two support phases. For two years after release, it receives both active support — bug fixes and security patches. For a further one year, it receives security-only support, meaning only vulnerabilities get patched, not ordinary bugs. After that three-year window closes, the version is end-of-life and receives nothing further, even for security issues.

Support timeline shape for any given PHP minor version

Text

Release  ─────────────▶  +2 years  ─────────────▶  +3 years
   │                          │                          │
   │   Active support         │   Security-only          │
   │  (bugs + security)       │      support              │  End of life
   ▼                          ▼                          ▼

Running an end-of-life PHP version in production

Once a version's three-year window closes, no further security patches are issued for it — ever. Sites still running, say, PHP 7.4 (which reached end-of-life in November 2022) are exposed to any vulnerability discovered afterward, with no official fix coming. Hosting providers and package maintainers also gradually drop support for old versions, so an unmaintained PHP version tends to fail in two ways at once: security exposure that never gets patched, and rising friction every time a dependency updates its minimum requirement.

Check your version: run php -v to see exactly which version and thus which support phase you are on.
Plan upgrades yearly: because a new minor version ships every year and active support lasts two, staying current means upgrading roughly every one to two release cycles, not waiting until end-of-life forces the issue.
Read the migration guide: every major PHP release publishes an official upgrade notes page listing deprecated and removed features — deprecations in one version are frequently hard errors in the next.

Deprecation is a warning, not a courtesy

PHP typically deprecates a feature in one version before removing it outright a few versions later — for example, several implicit type-juggling behaviors were deprecated in PHP 8.1 and became fatal errors in later releases. A codebase that runs cleanly with deprecation notices silenced is not "fine"; it is accumulating work that will eventually block an upgrade.

Tip

When starting a new project, target the latest stable PHP minor version rather than "whatever the last long-term-used version was." You get roughly three years of support from day one instead of inheriting however much of that window has already elapsed, and you avoid writing code against language features that are already on their way to deprecation.