PHP in 2026: What Still Matters and What You Can Ignore

Most PHP advice on the internet was written for PHP 5.3 and never updated. That’s a problem, because the language has changed a lot in the last few years and so has the way people deploy it. Here’s what I’d actually tell someone maintaining or starting a PHP project in 2026.

Use a supported version, and know where the line is

PHP 8.1 hit end of life in December 2025. If you’re still running it, you’re not getting security patches, which means every new CVE in the interpreter is yours to deal with alone. As of early 2026, the versions getting active support are 8.3, 8.4, and 8.5. PHP 8.2 is in security-only mode and follows 8.1 out the door at the end of this year.

The practical move is to target 8.3 as your floor and 8.4 or 8.5 as your ceiling. That gets you typed class constants, property hooks, asymmetric visibility, and the new #[Deprecated] attribute without forcing anyone on your team to upgrade their local tooling twice in one year.

Stop writing code PHP 8 made obsolete

A few patterns I still see in codebases that were “modernized” years ago but never finished:

Manual null checks instead of the nullsafe operator (?->)
Long switch blocks that should be match expressions
Constructor property promotion skipped in favor of writing out the assignment five times
Reading config with isset() chains instead of null coalescing assignment (??=)

None of these are bugs. They’re just noise that makes the real logic harder to find. Here’s the difference in practice:

// Old way
class Order
{
 private User $user;
 private float $total;

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

// PHP 8+ way
class Order
{
 public function __construct(
 private User $user,
 private float $total,
 ) {}
}

Same behavior, half the lines. Multiply that across a real application and you get a codebase people can actually read.

Enums finally replaced your constants class

If you’re still using const STATUS_ACTIVE = 1; and a comment explaining what 1 means, enums have been the answer since 8.1 and most teams still haven’t switched. Backed enums give you type safety, a cases() method, and the ability to attach behavior without a lookup array.

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

 public function isFinal(): bool
 {
 return $this === self::Cancelled;
 }
}

// Type-safe, no magic numbers
function markShipped(Order $order): void
{
 if ($order->status->isFinal()) {
 throw new RuntimeException('Cannot ship a cancelled order.');
 }
 $order->status = OrderStatus::Shipped;
}

The compiler catches the mistake where you’d previously have caught it in production.

Composer is not optional and never was

I still occasionally see projects with a vendor/ folder checked into git and no lock file. That’s a supply chain problem waiting to happen. In 2026, minimum expectations:

composer.lock committed, vendor/ ignored
Dependencies pinned to specific versions in production deploys (composer install --no-dev, not update)
Regular composer audit runs in CI, not just when something breaks
PHP version constraints in composer.json that match what you actually deploy on

That last one bites people constantly. If your composer.json says "php": "^7.4|^8.0" but you deploy on 8.4, you’re telling Composer it’s fine to install packages you can’t run.

Frameworks: pick one and go deep

Laravel and Symfony are still the two serious choices for application work, and both have matured in ways that reduce the amount of boilerplate you write. Laravel 12 ships with a slimmer default skeleton and better first-party tooling around queues and testing. Symfony 7 keeps pushing the component-first approach that makes it easy to pull in just what you need.

What I’d avoid in 2026 is building a new project on a framework that hasn’t had a major release in three years, or rolling your own router and ORM because “it’s not that hard.” It is that hard, and you’ll spend six months rediscovering why the existing ones look the way they do.

Performance: opcache and JIT, honestly

Every few years someone rediscovers the JIT and announces that PHP is now a systems language. It isn’t, and for typical web request workloads the JIT buys you very little. Opcache, on the other hand, is still the single biggest free win available, and people leave it misconfigured constantly.

; php.ini, production
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.jit=disable
opcache.preload=/var/www/app/preload.php

Set validate_timestamps=0 in production so PHP stops stat-ing every file on every request, and clear the cache as part of your deploy. Preloading is worth doing for larger codebases, but measure before you assume it helps.

Where the real bottlenecks live

Almost every slow PHP app I’ve looked at was slow because of the database, not the language. Common culprits:

N+1 queries hidden behind an ORM’s lazy loading
Missing indexes on columns used in WHERE and JOIN
Doing work in a request that belongs in a queue
Caching something that’s cheap to compute while leaving the expensive thing uncached

Profile first. Xdebug’s profiler, Blackfire, or even just EXPLAIN ANALYZE on your slowest query will tell you more in ten minutes than a week of guessing.

Security basics that still get skipped

PHP’s reputation for being insecure is mostly a reputation for applications built by people who didn’t use the tools the language gives them. The list hasn’t changed much:

Use prepared statements. PDO with emulated prepares turned off. No string concatenation into SQL, ever.
Escape output with htmlspecialchars($value, ENT_QUOTES, 'UTF-8') or your framework’s equivalent. Don’t hand-roll it.
Use password_hash() with the default algorithm (currently bcrypt) and password_verify(). Don’t invent your own.
Set session.cookie_httponly=1 and session.cookie_secure=1, and regenerate the session ID on login.
Keep dependencies patched. Most breaches in PHP apps come in through a package, not the core language.

When PHP is the wrong tool

I’ve written PHP for a long time and I’ll still tell you when not to use it. Long-running data processing jobs, real-time services with persistent connections, and anything where you need tight control over memory are better served elsewhere. PHP is excellent at taking an HTTP request, doing a bounded amount of work, and returning a response. That covers a huge amount of the web, but not all of it.

If you’re maintaining a legacy app and trying to decide between a rewrite and incremental modernization, the honest answer is usually incremental. I’ve written about that side of the work under custom web development if you want the longer version, including how I approach projects that are already in production and can’t be taken offline.

FAQ

Should I upgrade to PHP 8.5 right now?

If you’re on 8.3 or 8.4 and your dependencies support it, yes, it’s a low-risk upgrade. If you’re on 8.1 or older, upgrade to 8.3 first, fix the deprecations, then move forward. Don’t skip two majors in one jump.

Do I need a framework, or can I write plain PHP?

Plain PHP is fine for small scripts and internal tools. The moment you need authentication, routing, a database layer, and background jobs, a framework saves you months. Laravel and Symfony are both good choices; pick based on what your team already knows.

Is PHP still worth learning in 2026?

Yes. A large share of the web runs on it, the language keeps improving, and there’s steady demand for people who can maintain and modernize existing applications. The bar is higher than it used to be, which is good for people who clear it.