PHP in 2026: What Actually Matters for New York Developers

PHP never died, it just stopped being fashionable and got a lot better. If you’re maintaining a WordPress site, a Laravel app, or some legacy codebase that still pays the bills, the language you’re running in 2026 is not the PHP you learned in 2012. Here’s what actually changed and what I’d focus on if I were you.

PHP 8.4 and 8.5 Are Not Incremental

PHP 8.4 shipped in November 2024 and 8.5 landed in November 2025, and together they moved the language further than the entire 7.x line did. The big one for most teams is property hooks, which let you define get/set logic directly on a typed property instead of writing a getter and setter pair and pretending that’s clean code.

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

That replaces about fifteen lines of boilerplate. Asymmetric visibility is the other quiet win: you can make a property publicly readable but only privately writable, which kills a whole class of accidental mutation bugs.

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

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

$order = new Order();
echo $order->status; // fine
$order->status = 'lost'; // fatal error

If you’re still on 8.1 or 8.2, you’re leaving performance and safety on the table. Upgrading is usually a week of work, not a quarter.

Stop Writing Your Own Auth and Session Code

The single most common security problem I see in code reviews is hand-rolled authentication. People write their own password hashing wrappers, their own session handling, their own CSRF tokens. In 2026 there is no reason for this. Use password_hash() with PASSWORD_ARGON2ID, use your framework’s session layer, and if you’re not on a framework, use a maintained library.

$hash = password_hash($plain, PASSWORD_ARGON2ID);

if (password_verify($input, $hash)) {
 if (password_needs_rehash($hash, PASSWORD_ARGON2ID)) {
 // upgrade the stored hash on next login
 }
}

That password_needs_rehash check is the part everyone forgets. It’s how you migrate hashing algorithms without forcing a password reset on your whole user base.

Composer Hygiene Is a Security Practice

Your composer.lock file is a list of every third-party decision your project depends on. Treat it that way. Run composer audit in CI, pin your platform requirements, and actually read the changelogs when a major version bumps.

composer audit --locked
composer outdated --direct

I’ve watched a client site get flagged for a vulnerable transitive dependency that nobody on the team had ever heard of. It came in through a package they installed two years prior and forgot about. Automated auditing catches that in seconds.

Static Analysis Is No Longer Optional

PHPStan and Psalm have gotten good enough that running them at a high level is genuinely cheaper than debugging production. Start at level 5, work up. It will feel annoying for a week and then you’ll never go back.

// phpstan.neon
parameters:
 level: 8
 paths:
 - src
 treatPhpDocTypesAsCertain: false

For a legacy codebase, don’t try to fix everything at once. Add a baseline file, get CI green, and chip away at the baseline over time. That’s how you make progress without freezing feature work for a month.

Where the New York Market Actually Is

I work out of Commack, and most of the PHP work I see on Long Island and in the city falls into two buckets: agencies maintaining client sites on WordPress or Craft, and small product teams running Laravel or Symfony. Both buckets have the same problem, which is that the original developer left and nobody wants to touch the code. Modern PHP tooling (typed properties, static analysis, real test suites) is what makes that codebase approachable again for whoever comes next. If you’re weighing a rewrite against a cleanup, this is usually the deciding factor. That’s also why I lean on custom web development rather than template work when a client’s needs have outgrown the off-the-shelf option.

Things I’d Skip in 2026

• Frameworks that haven’t shipped a release in two years, no matter how much you like the syntax.
• Rolling your own ORM. Just use Doctrine or Eloquent.
• Micro-optimizing with echo instead of print. The difference is noise.
• Arguing about tabs versus spaces. Set up a formatter and move on.

FAQ

Is PHP still worth learning in 2026?

Yes, if you want to work on the web. It runs a huge share of the sites you use daily, the job market for it is real, and the language has gotten genuinely pleasant since 8.0. It’s not a growth story like Rust or Go, but it’s steady work.

Should I upgrade from PHP 7.4 to 8.4 or go straight to 8.5?

Go to 8.5 if your dependencies support it. The jump from 7.4 is significant either way, so test on a staging environment first and expect a few deprecation warnings to clean up.

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

Plain PHP is fine for small scripts and one-off tools. The moment you have users, sessions, and a database, a framework saves you more time than it costs. Laravel and Symfony are the two I’d look at first.