Why WordPress Should Adopt PER-CS and Drop Support for EOL PHP versions

Ten years ago, we wrote about upping PHP requirements in WordPress themes and plugins. Back then, WordPress still supported PHP 5.2, a version that had been deprecated for four years. We argued that developers should push the ecosystem forward by requiring modern PHP in their own projects.

A decade later, not much has changed.

WordPress still clings to its own coding standards while every other major PHP framework has aligned with PSR and PER-CS. It still officially supports PHP 7.2, a version that reached end-of-life in November 2020, over five years ago. It still enforces conventions like Yoda conditions and spaces inside parentheses that make WordPress code look and feel foreign to the rest of the PHP world.

At Roots, we’ve used PSR standards since day one. We’re asking WordPress to follow the rest of PHP.

WordPress stands alone

Here’s where the major PHP frameworks stand on coding standards:

Project	Standard
Laravel	PSR-2, PSR-4
Symfony	PSR-1, PSR-2, PSR-4, PSR-12
CakePHP	PSR-12
Yii	PSR-12
Magento	PSR-1, PSR-2, PSR-12
Drupal	Custom, but uses PSR-4 autoloading
WordPress	Custom (WPCS)

CakePHP adopted PSR-2 back in 2014 with version 3.0. That was eleven years ago. Laravel, Symfony, Yii, Magento have all embraced the standards that PHP-FIG established to reduce friction when scanning code from different authors.

WordPress is the outlier.

PER-CS (PHP Evolving Recommendation – Coding Style) is the current living standard maintained by PHP-FIG. It extends and replaces PSR-12, adding support for modern PHP features like enums, attributes, match expressions, named arguments, and short closures. It evolves with PHP itself. Meanwhile, WPCS remains frozen in patterns established when PHP 5 was still relevant.

The readability problem

This isn’t just about being different for the sake of it. Several WPCS conventions actively hurt code readability.

Yoda conditions

WPCS requires putting the constant on the left side of comparisons:

// WPCS requires this
if ( 'publish' === $post->post_status ) {
    // ...
}

// Everyone else writes this
if ($post->post_status === 'publish') {
    // ...
}

The second version reads like English. The first reads like you’re talking backwards.

The original justification was preventing accidental assignment — writing = when you meant ===. But that was a valid concern in 2005. Today, PHPStan, Psalm, and every modern IDE will scream at you the moment you make that mistake. Yoda conditions sacrifice readability to solve a problem that tooling solved years ago.

Spaces inside parentheses

WPCS requires spaces after opening parentheses and before closing ones:

// WPCS
if ( $condition ) {
    do_something( $arg1, $arg2 );
}

foreach ( $items as $item ) {
    process_item( $item );
}

// PER-CS and literally every other PHP project
if ($condition) {
    doSomething($arg1, $arg2);
}

foreach ($items as $item) {
    processItem($item);
}

No other major PHP project does this. Not Laravel. Not Symfony. Not CakePHP. Not Yii. Not Magento. Not Drupal. Just WordPress.

It adds visual noise. It fights against IDE defaults. And it makes WordPress code instantly recognizable as “that weird PHP dialect” to anyone coming from the broader ecosystem.

The cumulative friction

These aren’t preferences. They create real problems:

• Developers constantly override their IDE’s defaults
• Mental context-switching when moving between WordPress and other PHP projects
• New developers from Laravel or Symfony backgrounds face an unnecessary learning curve
• WordPress code can’t easily be extracted into general PHP packages

The recent proposal to allow short echo tags is a step in the right direction. It’s the most-requested issue in the WPCS repository. But allowing <?= is just one small piece of a much larger alignment problem.

The PHP version problem

WordPress recommends PHP 8.3 or greater. But it still officially supports PHP 7.2.24+.

Here’s what the current WordPress.org stats show:

PHP version	Usage	EOL date	Status
8.5	0.13%	—	Current
8.4	4.58%	—	Current
8.3	15.89%	Dec 2027	Active support
8.2	27.52%	Dec 2026	Security support
8.1	15.66%	Dec 2025	EOL this month
8.0	5.94%	Nov 2023	EOL for 2 years
7.4	22.62%	Nov 2022	EOL for 3 years
7.3	2.08%	Dec 2021	EOL for 4 years
7.2	1.83%	Nov 2020	EOL for 5 years
7.1	0.47%	Dec 2019	EOL for 6 years
7.0	0.76%	Dec 2018	EOL for 7 years
5.6	1.66%	Dec 2018	EOL for 7 years

Let that sink in:

• About 30% of WordPress sites run PHP 7.x. Every single 7.x version is end-of-life.
• Over 20% run PHP 8.0 or 8.1, which are either already EOL or will be by the end of this month.
• Only about 48% of WordPress sites run PHP that’s still receiving security patches.

WordPress powers 43% of all websites on the internet. That’s potentially hundreds of millions of sites running PHP versions that haven’t received a security patch in years. This isn’t a theoretical risk. It’s a massive attack surface.

Why this matters

Security

EOL PHP versions get zero security patches from the PHP core team. When vulnerabilities are discovered they don’t get fixed. Sites running PHP 7.4 today are running software with known, unpatched security holes.

WordPress’s continued support of these versions enables complacency. Hosts don’t push upgrades because “WordPress still supports it.” Site owners don’t upgrade because nothing’s visibly broken. The cycle continues.

Ecosystem isolation

WordPress exists in its own bubble. Modern PHP has evolved dramatically: typed properties, union types, enums, attributes, match expressions, constructor promotion, readonly classes. These features enable cleaner, safer, more maintainable code.

But WordPress plugin and theme developers can’t use most of them. Not if they want to support the “minimum” PHP version. So the ecosystem stays stuck writing PHP that looks like it’s from 2015.

Interoperability

Code written to WPCS doesn’t play nicely with the rest of PHP. Want to extract a useful class from your WordPress plugin into a standalone Composer package? Good luck making it feel at home in a Laravel project with Yoda conditions and spaces inside every parenthesis.

The PHP community solved the interoperability problem years ago with PSR standards. WordPress chose not to participate.

A path forward

We’re not suggesting WordPress flip a switch and break millions of sites tomorrow. But there’s a reasonable path toward modernization.

Right now

The short echo tag proposal is a good start. Pass it. Show the community that modernization is possible.

Short term

• Raise the minimum PHP version to 8.2. It’s the oldest version still receiving security patches. Sites running 7.x have had years of warning.
• Deprecate Yoda conditions. Trust the tooling that every modern developer already uses.
• Drop the spaces-inside-parentheses requirement. Align with how every other PHP project formats code.
• Adopt PSR-4 autoloading for new core code.

Long term

• Evaluate PER-CS adoption for new WordPress code.
• Provide a migration path, not a mandate. Existing code doesn’t need to change overnight.
• Position WordPress as a modern PHP citizen rather than an isolated dialect.

The inevitable objections

“This would break backward compatibility.”

No one’s proposing that existing code must change immediately. CakePHP and Laravel both transitioned their coding standards successfully. A multi-year deprecation timeline works.

“Raising PHP requirements would break sites.”

Raising requirements doesn’t break sites, it pushes hosts to finally upgrade. Hosts have had five-plus years of warning about PHP 7.x reaching EOL. WordPress’s continued support is what enables their procrastination.

Every other major CMS has moved on. Drupal requires PHP 8.1+. Joomla requires PHP 8.1+. WordPress requiring a supported PHP version isn’t radical. It’s baseline responsible.

“WordPress developers prefer WPCS.”

That’s fine for developers who live entirely within WordPress. But the PHP community at large uses PSR/PER-CS. Aligning with those standards makes WordPress accessible to the enormous pool of PHP developers who currently view WordPress as “that legacy thing with the weird code style.”

“Yoda conditions prevent bugs.”

They did, in 2005. PHPStan, Psalm, and modern IDEs catch assignment-in-condition mistakes instantly now. The safety benefit that justified Yoda conditions evaporated years ago. The readability cost remains.

It’s time

WordPress powers 43% of the web. With that dominance comes responsibility.

Supporting PHP versions that have been EOL for five or more years is a security liability. Enforcing coding conventions that no other PHP project uses creates unnecessary friction. Remaining isolated from the standards the PHP community adopted over a decade ago benefits no one.

Roots has proven that modern PHP works beautifully with WordPress. We’ve been doing it for over ten years. Bedrock, Sage, and Acorn all follow PSR standards, and they’re better for it.

WordPress should follow Laravel, Symfony, CakePHP, Yii, and the rest of the PHP ecosystem. Raise the PHP minimum. Adopt PER-CS. Join the modern PHP era.

The conversation has already started with the short echo tag proposal. Let’s keep it going.