PHP in 2026: What Actually Changed and What Still Matters

PHP turned 30 last year, and it is still the language running most of the web. But the PHP most people learned in 2015 or even 2020 looks nothing like what I write today. If you are maintaining an older codebase or starting something new, here is where things actually stand in 2026.

The version situation, plain and simple

PHP 8.5 shipped in November 2025. PHP 8.4 is still widely deployed and gets security support into 2028. PHP 8.3 is in security-only mode now. And PHP 7.4? End of life since November 2022. If your site is still running 7.x, you are running unpatched code on the public internet. That is not a hypothetical risk.

Every major host and platform has moved. WordPress requires 7.4 minimum but recommends 8.2+. Laravel 12 requires PHP 8.2+. Symfony 7.2 requires 8.2+. If you are stuck on an old version because “the site works fine,” the site works fine until it doesn’t.

Checking what you are actually running

<?php
// Don't trust the control panel. Ask PHP directly.
echo PHP_VERSION; // e.g. 8.5.2

// And check what extensions are loaded
print_r(get_loaded_extensions());

I have seen hosting dashboards claim 8.1 while the actual CLI binary was 7.4. The web SAPI and the CLI can differ. Verify both.

What actually changed in 8.x worth caring about

A lot of the 8.x changelog is noise for day-to-day work. These are the ones that changed how I write code.

Constructor property promotion

This alone cut a huge amount of boilerplate out of my classes.

<?php
// Before
class User {
 private string $name;
 private string $email;

 public function __construct(string $name, string $email) {
 $this->name = $name;
 $this->email = $email;
 }
}

// Now
class User {
 public function __construct(
 private string $name,
 private string $email,
 ) {}
}

Readonly properties and readonly classes

Readonly properties landed in 8.1, readonly classes in 8.2. If you are building value objects or DTOs, this is the tool.

<?php
readonly class Money {
 public function __construct(
 public int $cents,
 public string $currency = 'USD',
 ) {}
}

$price = new Money(4999);
// $price->cents = 5000; // Fatal error. Good.

Enums

Real enums, not class constants pretending to be enums.

<?php
enum OrderStatus: string {
 case Pending = 'pending';
 case Shipped = 'shipped';
 case Delivered = 'delivered';

 public function label(): string {
 return match($this) {
 self::Pending => 'Awaiting fulfillment',
 self::Shipped => 'On the way',
 self::Delivered => 'Delivered',
 };
 }
}

The match expression

Stricter than switch, returns a value, no fall-through bugs. I have not written a switch statement in years.

Named arguments

When a function takes five booleans, named arguments save you from reading the signature every time.

<?php
setcookie(
 name: 'session',
 value: $token,
 expires: time() + 3600,
 secure: true,
 httponly: true,
 samesite: 'Lax',
);

PHP 8.4 and 8.5: the newer stuff

8.4 brought property hooks, which let you define get/set logic directly on a property without writing separate methods.

<?php
class Temperature {
 public function __construct(
 public float $celsius = 0,
 ) {}

 public float $fahrenheit {
 get => ($this->celsius * 9 / 5) + 32;
 set => $this->celsius = ($value - 32) * 5 / 9;
 }
}

$t = new Temperature(20);
echo $t->fahrenheit; // 68
$t->fahrenheit = 32;
echo $t->celsius; // 0

8.4 also added asymmetric visibility (public private(set) string $id), a new #[Deprecated] attribute, and a proper array_find() family that replaces a lot of awkward array_filter plus reset() patterns.

<?php
$users = [
 ['name' => 'Ana', 'active' => false],
 ['name' => 'Bill', 'active' => true],
];

$first = array_find($users, fn($u) => $u['active']);
// ['name' => 'Bill', 'active' => true]

8.5 focused more on the engine and on developer experience than on headline syntax. The pipe operator (|>) landed, which cleans up long transformation chains. There is also a persistent curl share handle and better clone with syntax for modifying objects during clone.

Things that are still true and always will be

• Escape output. htmlspecialchars($value, ENT_QUOTES, 'UTF-8') on anything that touches the browser. No exceptions.
• Use prepared statements. PDO or mysqli, bound parameters, every time. String concatenation into SQL is how sites get owned.
• Type everything you can. Parameter types, return types, property types. The engine catches more than you expect.
• Run static analysis. PHPStan or Psalm at a reasonable level will catch bugs before your users do.

A prepared statement, done right

<?php
$pdo = new PDO('mysql:host=localhost;dbname=app;charset=utf8mb4', $user, $pass, [
 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
 PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
 PDO::ATTR_EMULATE_PREPARES => false,
]);

$stmt = $pdo->prepare('SELECT id, email FROM users WHERE email = ? AND active = 1');
$stmt->execute([$email]);
$row = $stmt->fetch();

Note ATTR_EMULATE_PREPARES => false. That forces real server-side prepared statements instead of PDO faking it. It matters.

Modern tooling

Composer is still the package manager, no real challenger. For code style, PHP CS Fixer and Laravel Pint are the usual choices. For static analysis, PHPStan. For testing, PHPUnit 11 or Pest if you prefer a cleaner syntax.

If you are deploying, stop uploading files over FTP. Use a build pipeline, even a simple one. Run composer install --no-dev --optimize-autoloader as part of the deploy, not by hand on the server.

Should you upgrade, or rewrite?

Upgrading from 8.0 to 8.4 is usually a day or two of work on a well-tested codebase. Going from 7.4 to 8.4 is a bigger job because of breaking changes in how PHP handles undefined variables, string-to-number comparisons, and dynamic properties. That last one bites a lot of older code.

If the codebase has no tests, no Composer, and uses mysql_* functions, a rewrite is often cheaper than a migration. I have done both. The answer depends on how much of the code is actually still doing something valuable.

For projects where the backend has grown tangled or the original build was outsourced and never documented, it often makes sense to bring in custom web development help rather than trying to untangle it solo. That is true whether you are on Long Island or anywhere else. The geography matters less than having someone who will read the code before touching it.

What I would tell someone starting today

Learn PHP 8.4 or 8.5 syntax from the start. Do not learn 5.x patterns and then unlearn them. Use a framework if you are building anything with users, forms, and a database. Laravel and Symfony both have excellent documentation and active communities. Write tests for the parts that handle money, auth, or data you cannot afford to lose.

And read the official migration guides when you upgrade. They are dry but they are accurate, which is more than you can say for most blog posts about PHP. Including, possibly, this one. Verify anything version-specific against the docs at php.net before you ship it.

FAQ

Is PHP still worth learning in 2026?

Yes. It powers the majority of websites, has a huge job market, and modern PHP is a genuinely pleasant language to write. The reputation problem comes from old code, not the current version.

What PHP version should I be running?

8.4 at minimum. 8.5 if your dependencies support it. Anything below 8.2 is a liability, and 7.x should be treated as an emergency.

Do I need a framework?

For a simple script or a small API, no. For anything with authentication, a database, and multiple pages, yes. Laravel or Symfony will save you more time than they cost.