PHP gets declared dead every few years, and every year it quietly powers most of the web you use. But the language has genuinely changed a lot since the PHP 5 days, and 2026 is a good time to separate what actually matters from the noise. Here’s the honest version of where PHP stands right now, with code you can run.

The version question, settled

If you’re still on PHP 7.x, you’re running an unsupported version. PHP 7.4 hit end of life in November 2022. PHP 8.0 and 8.1 are also past their security support windows. As of 2026, the versions getting active bug fixes and security patches are PHP 8.2, 8.3, 8.4, and 8.5.

PHP 8.4 shipped in November 2024. PHP 8.5 landed in November 2025. Both are stable and production-ready. If you’re starting something new, run 8.4 or 8.5. If you’re maintaining something old, the upgrade path from 8.1 to 8.4 is usually less painful than people assume.

Property hooks are the big one

PHP 8.4 introduced property hooks, and this is the feature that changes how you write classes day to day. Instead of writing a getter and setter for every property, you attach logic directly to the property.

class User
{
 public string $email {
 set (string $value) {
 if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
 throw new InvalidArgumentException("Bad email: $value");
 }
 $this->email = strtolower($value);
 }
 }

 public string $displayName {
 get => $this->firstName . ' ' . $this->lastName;
 }
}

You get validation on write and a computed value on read, without the boilerplate. If you’ve written a lot of Java-style getters in PHP over the years, this is the payoff. It’s also the kind of thing that makes old codebases look ancient by comparison.

Asymmetric visibility

Also new in 8.4: you can make a property publicly readable but only writable from inside the class.

class Order
{
 public private(set) string $status = 'pending';

 public function markPaid(): void
 {
 $this->status = 'paid';
 }
}

$order = new Order();
echo $order->status; // works, reads "pending"
$order->status = 'paid'; // Error: cannot modify from outside

Before this, you had to either expose a setter (bad) or make the property private and write a getter (verbose). Now you get the read-only-from-outside behavior for free. Small thing, saves real code.

What to stop doing

Stop using mysql_* functions. They were removed in PHP 7. If you still see them, that code is ancient and probably broken. Use PDO or mysqli.
Stop trusting $_REQUEST. It merges GET, POST, and cookies, which makes it a security footgun. Be explicit about where input comes from.
Stop hand-rolling password hashing. password_hash() and password_verify() with the default algorithm are correct. Don’t invent your own.
Stop ignoring strict types. Putting declare(strict_types=1); at the top of your files catches a whole class of bugs before they hit production.

Composer is not optional

If you’re still copying library files into a folder, you’re doing it wrong in 2026. Composer has been the standard for over a decade. Autoloading, version constraints, lockfiles, security auditing via composer audit. It’s all there.

composer require monolog/monolog
composer audit
composer outdated --direct

That last command tells you which of your direct dependencies have newer versions available. Run it monthly. Old dependencies are how sites get compromised, more often than any clever attack.

Frameworks: Laravel and Symfony still run the show

Laravel 11 and 12 are the current major lines, and Symfony 7 is the current major. Both are actively developed and both target modern PHP. If you’re building anything with real business logic, pick one and use it. Writing raw PHP for a full application in 2026 means reinventing routing, ORM, validation, and auth, badly.

For smaller stuff, a static site generator or a thin framework is often the right call, and that’s a decision I walk through with clients regularly when doing custom web development for local businesses. The framework question matters less than matching the tool to the actual job.

Performance in 2026

PHP 8.x with OPcache and JIT is fast. Not “fast for PHP” fast. Actually fast. The JIT compiler added in PHP 8.0 helps most on CPU-heavy workloads, less on typical web request/response cycles, but the baseline interpreter improvements from 7.x to 8.x are substantial on their own.

The real performance wins in most apps come from:

Enabling OPcache with a sane opcache.memory_consumption and opcache.max_accelerated_files
Caching database queries that don’t change often
Not loading 40 Composer packages when you need three
Using a real object cache (Redis or Memcached) instead of hitting MySQL for everything

A well-configured PHP 8.4 app on modest hardware handles more traffic than most sites will ever see. The bottleneck is almost never the language.

Static analysis is now standard

Tools like PHPStan and Psalm catch type errors, dead code, and logic bugs before you deploy. Running PHPStan at level 6 or higher on a new project should be the default. On older codebases, you ratchet the level up over time rather than trying to fix everything at once.

composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src --level=6

It’s not a silver bullet, but it catches the kind of mistake that otherwise shows up as a 500 error at 2am.

So does PHP have a future?

Yes, and a boring one, which is the best kind. It runs roughly three quarters of the web by most measurements. WordPress, which powers a huge chunk of that, is on PHP. So is Laravel, Symfony, and every major CMS you’ve heard of. The language keeps shipping meaningful improvements on a yearly cadence, and the ecosystem is mature enough that you’re not fighting your tools.

If you’re choosing a stack in 2026 and PHP fits the problem, use it without apology. If you inherited a PHP codebase that’s stuck on 7.x, upgrading is worth the effort. The gap between 7.x and 8.4 is not cosmetic.

FAQ

Is PHP still worth learning in 2026?

Yes. There’s more PHP code running in production than almost any other server language, which means there’s steady work maintaining and extending it. It’s also a genuinely pleasant language now if you use modern versions and tooling.

Should I upgrade from PHP 7.4 to 8.4 directly?

Usually yes, but test first. The biggest breakages are removed functions, stricter type handling, and deprecation warnings that turn into errors. Run your test suite against 8.4 in a staging environment before touching production.

Do I need a framework, or is plain PHP fine?

Plain PHP is fine for small scripts and simple sites. Once you need user accounts, a database with relationships, or an admin panel, a framework pays for itself within weeks. Laravel and Symfony are both solid choices.

PHP in 2026: What Actually Changed and What Still Matters