Modern PHP in 2026: What Actually Changed and What Still Matters

Most PHP advice floating around is either five years stale or written by someone who hasn’t shipped anything since PHP 7.4. I’ve been building and maintaining PHP applications for years, including plenty of client work through my custom web development practice here on Long Island, and the language has genuinely changed. Here’s what I’d tell a developer or business owner deciding what to do in 2026.

Where PHP Actually Stands in 2026

PHP 8.4 is the current stable release most hosts are running, with 8.5 rolling out across managed platforms through 2026. The 7.x line is long dead. If you’re still on 7.4, you’re running unsupported software that stopped getting security patches back in 2022. That’s not a “we should upgrade eventually” problem. It’s a “you have a known-vulnerable box on the internet” problem.

The performance story is real too. PHP 8’s JIT and the general engine improvements mean the same code from 2019 often runs 30 to 50 percent faster on 8.4 with zero changes. I’ve migrated apps where the only edit was a composer.json constraint and a couple of deprecated function swaps.

Features Worth Actually Using

Constructor property promotion and readonly

This one cut a lot of boilerplate out of my DTOs and value objects. Instead of declaring properties, then assigning them in the constructor, you do it inline.

final class Money
{
 public function __construct(
 public readonly int $amountInCents,
 public readonly string $currency,
 ) {}

 public function add(Money $other): self
 {
 if ($other->currency !== $this->currency) {
 throw new InvalidArgumentException('Currency mismatch');
 }

 return new self($this->amountInCents + $other->amountInCents, $this->currency);
 }
}

Readonly properties are enforced at runtime. Once set, they can’t be reassigned. That kills a whole class of “someone mutated my object in a weird place” bugs.

Enums

Native enums landed in 8.1 and I use them constantly now. Status codes, order states, roles. They’re type-safe and they can carry methods.

enum OrderStatus: string
{
 case Pending = 'pending';
 case Paid = 'paid';
 case Shipped = 'shipped';
 case Cancelled = 'cancelled';

 public function isFinal(): bool
 {
 return match($this) {
 self::Shipped, self::Cancelled => true,
 default => false,
 };
 }
}

Match expressions over switch

Match is strict, returns a value, and throws on an unhandled case instead of silently falling through. I’ve replaced nearly every switch statement in my codebases with match.

Named arguments

When a function takes four booleans, named arguments save you from counting commas and guessing which true is which.

// Before: what does this even mean?
renderTemplate($view, true, false, true);

// After:
renderTemplate($view, cache: true, minify: false, escape: true);

Property hooks (8.4)

This is the newest one worth knowing. Property hooks let you attach get/set logic to a property without writing a separate getter and setter method.

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

I haven’t converted everything to use hooks, and I wouldn’t. For plain data holders they’re great. For anything with real behavior, explicit methods are still clearer.

What I’d Skip

• Overusing attributes for everything. Attributes are metadata, not magic. If you’re reaching for reflection to make them do real work, you probably want plain code instead.
• Chasing the newest framework feature on day one. Laravel and Symfony both move fast. Wait for the first point release before you rebuild your auth layer on a brand new API.
• Micro-optimizing before profiling. The JIT is good. Your bottleneck is almost always the database query, not the loop.

The Stuff That Still Bites People

Version upgrades don’t fix architecture. I still see:

• Raw string concatenation into SQL. Use prepared statements. This is not negotiable in 2026.
• Secrets committed to git. Use environment variables or a secrets manager.
• No dependency updates for two years, then a panic upgrade. Update monthly and it’s boring. Update yearly and it’s a project.
• Ignoring composer audit. Run it in CI. It takes ten seconds and tells you about known CVEs in your dependencies.

Should You Upgrade?

If you’re on 8.1 or 8.2, yes, plan it. If you’re on 8.3 or 8.4, you’re fine for now. If you’re on 7.4 or older, stop reading and start planning, because you’re one unpatched vulnerability away from a very bad week. The upgrade itself is usually less painful than people fear. It’s the untested code and outdated dependencies that cause the pain, and those need attention regardless of which PHP version you’re running.

FAQ

Do I need to rewrite my app to use PHP 8.4 features?

No. Old code generally runs fine on newer PHP. Adopt features like enums and readonly where they improve new code, but don’t rewrite working code just to use syntax you just learned.

Is PHP still a good choice for new projects in 2026?

Yes, especially for web applications, APIs, and content-driven sites. It’s fast, well-supported, and has a huge ecosystem. The “PHP is dead” line has been wrong for a decade.

How often should I update PHP and my dependencies?

Dependencies monthly, PHP minor versions as they release, and major versions within a year of the previous one going end-of-life. Small, regular updates are far cheaper than emergency migrations.