PHP 8.2: What Does it Mean for WordPress, Plugins, and Developers?

PHP 8.2.0 made its debut on December 8, 2022. As a major update, it brings performance improvements and simpler syntax. PHP 8.2 introduces greater type safety as a feature with null, false, and true as standalone types. One of the biggest changes likely to challenge WordPress developers is the addition of readonly classes, which disallow dynamic properties.

Dynamic properties are deprecated and will produce a fatal error in PHP 9 or possibly PHP 10. While potentially painful — especially for WordPress core — deprecation is a key feature and a gift to developers from PHP.

Let’s take a look at the recent evolution of PHP — and WordPress. How do WordPress developers maintain backward compatibility while taking advantage of new features that will benefit end users? This is a key theme in the relationship between both open-source projects.

Keeping Up With PHP Development in WordPress

WordPress core maintains significant backward compatibility with no planned end-of-life dates when old versions won’t be supported. Because backward compatibility is so prioritized, it falls to WordPress businesses to determine their own product or service life cycle. What versions of PHP will they support?

In contrast with WooCommerce, which requires a minimum of PHP 7.4, WordPress core currently only recommends PHP 7.4 or higher. It “also works with” PHP 5.6.20, which reached its end-of-life date at the end of 2018. The WordPress project notes this and warns that using unsupported PHP versions “may expose your site to security vulnerabilities.” (WordPress.org Requirements)

Fortunately, only 5.1% of all WordPress sites currently use PHP 5.6, and only 2% use an even older version. 20% are using PHP 7.0 to 7.3, and the largest group (56.7%) is using PHP 7.4. (WordPress.org Statistics)

PHP 7.4 Has Reached Its End-of-Life

Unfortunately, PHP 7.4 just reached its EOL date at the end of November 2022. PHP 8.0 has less than a year left for its official security support through most of 2023. The current and actively supported version, PHP 8.1, will age out at the end of 2024. PHP 8.2, which just had its first stable release, will have security support until December 2025.

This is a fast release cycle, and it’s no surprise the WordPress ecosystem struggles to keep up with it. With about half the web running on WordPress, it’s a big ship that can’t turn quickly. It’s far more of a balancing act than a race toward the bleeding edge. PHP 8 has many benefits, however. There are big performance-enhancing features like Just-in-Time (JIT) PHP compilation at runtime for faster execution with less memory usage.

The Tradeoff Between Backward Compatibility and Stability, Forward Thinking and Innovation

Should we cater to the widest possible audience of users or maintain currency with PHP? This question has always been a dilemma for WordPress developers, hosts, and product companies. There is no single correct answer. All decisions are tradeoffs.

Agencies and freelancers with long-term clients and legacy sites face the same problem. Should they update minimum PHP requirements? Doing this may force their existing customers to make significant changes to their sites or see them break.

On the one hand, staying up to date with PHP improves security and performance. The latest programming concepts and capabilities may be valuable to developers adding new features to a WordPress plugin. On the other hand, delaying the minimum required PHP version will please a broad customer base. However, stability becomes complacency and obsolescence at some point.

It’s a “pay me now or pay me later” situation. Eventually, you have to rip off the bandaid and update the minimum PHP requirement.

Telemetry Can Tell You When to “Rip Off the Bandaid”

Any breaking change to a software product will result in a burst of support tickets. Good data and telemetry about user environments help determine the least disruptive time to raise a minimum PHP version requirement. That’s why plugin owners need to know their users’ PHP version adoption.

WordPress.org tracks the PHP version used by every WordPress site. The same isn’t true for WordPress plugins. Developers need to gather those numbers with their own tools.

Prioritizing backward compatibility is high-maintenance work. Supporting a very large and diverse user base is great for the end user, but it means developers have to keep their code working with many different environments. “I love supporting older PHP versions as new features are added,” — said no developer, ever!

It’s not just legacy PHP they have to worry about — it’s also legacy databases and dozens of other variations in the WordPress stack. Edge cases crop up and confound even the experts when there is a wide spectrum of WordPress server environments with obsolete elements.

The Best Time to Raise Your Minimum PHP Requirement

The iThemes Security Pro 7.2 release is a good example of raising a WordPress product’s minimum PHP requirement to deliver both innovation and stability for existing customers.

Case Study: iThemes Security Pro

As of the 7.2 version release, iThemes Security Pro has required PHP 7.3 or higher and supports up to 8.1. The iThemes Security Pro team decided to update their PHP requirement to implement the WebAuthn framework. The implementation required libraries that need PHP 7.3+ to manage encryption and public keys. The 2FA, passkey, and biometric login features introduced in iThemes Security Pro 7.2 are a direct result of this decision. At a time when passwords are broken, the iThemes Security team brought passwordless login to WordPress for the first time as the primary user authentication experience.

It would have been possible to build these new features for iThemes Security Pro by rewriting the WebAuthn libraries for compatibility with older versions of PHP. Of course, that would be much more work and create additional code to maintain. The wiser course was to keep up with the PHP community at a moderate pace by adopting dependencies that require PHP 7.3 or higher. Most of their users were already there. That’s why the iThemes Security development team decided to raise the minimum PHP requirement for new and existing users.

Case Study: GiveWP

Managing change can be even more challenging for WordPress products that are heavily invested in the Gutenberg block editor, like GiveWP. The stability and slow rate of change in WordPress core may be frustrating to back-end PHP developers, but it’s allowing front-end JavaScript/React developers to drive the platform forward.

Jason Adams, GiveWP’s Manager of Development, notes they don’t have to be backward compatible because they can migrate users across versions as the site editor evolves. However, “There’s no such thing as a migration for PHP,” he commented. Eventually, they’ll have to adapt toward the PHP 9 architecture and away from the newly deprecated features in PHP 8.2.

There’s no single “right time” for every product across the WordPress ecosystem to update minimum PHP requirements. “It’s not a problem you can solve philosophically,” Adams told me. It really comes down to a judgment call. How many users will be negatively affected? If 90% or more are on PHP 7.2 or 7.4, raising the minimum requirement to that level is viable.

Those numbers can vary widely depending on a product’s specific user base, says Adams. A product used by more technically adept customers will tend to be closer to the currently supported PHP versions. A product like GiveWP, with many non-profit organizations using it, will need to put more weight on backward compatibility. Another way forward is to branch off legacy code in a long-term release that will be supported but not see new features added. When users are ready to make the upgrade, they could migrate to a new major release built for future PHP compatibility.

Deprecation Notices Drive Development Forward

WordPress.com has just rolled out PHP 8.2 as an option for its Business and Ecommerce plans with hosting features activated, and in the WordPress.org ecosystem, well-engineered older code is unlikely to break or become insecure with the next major PHP version release. Even though the WordPress.org core codebase officially offers only “beta” support for PHP 8.0, it usually works just fine with the latest versions of PHP, and so do well-supported plugins. They won’t throw fatal or parse errors. You shouldn’t even see many warnings with debugging turned on. You may see a lot of deprecated function notices, which aren’t errors — yet.

The frustrations of a fast PHP release cycle have a lot to do with developers getting bogged down in the weeds refactoring their code and playing catchup with deprecated aspects of PHP. This critical work may leave them with less time to explore and innovate with new concepts and capabilities the latest PHP version brings.

The Glass Half Full: Deprecated Features Push PHP Developers Forward

There’s another way to look at this situation. Dealing with deprecated features of PHP is actually forward-looking. It compels developers to become fluent in the next iterations of an evolving language. Without this enforced exercise, existing knowledge would more easily settle into old habits. Old habits become bad habits when they’re obsolete.

Deprecation notices are pointing out things that work now but will break in future versions of PHP. This is good for you if you’re a developer, as Brent Roose explains. If developers pay attention to those notices, they will have plenty of time to get on top of any deprecated code. And it shouldn’t be a blocker to minor version updates.

Timothy Jacobs, iThemes Security Lead Developer and WordPress Core Committer, says it’s good to have deprecation warnings. They push developers forward to embrace “more correct” and “less fragile” code. Their work will be more secure, performant, mistake-proof, and better able to cope with edge cases. In this view, E_DEPRECATED notices filling up your error log is “like an early warning system. It’s telling you that things will break in the future, but they aren’t broken now.”

Doing Without Dynamic Properties After PHP 8.2

Nikita Popov’s reasons for phasing out dynamic properties in PHP 9 is a good example of PHP’s evolutionary drive toward more resilient code and programming conventions:

The motivation for this change is twofold: To prevent mistakes (due to typos or renames) in the common case, and to make intentional uses explicit. The core problem is that reading from a non-existing property issues a diagnostic that makes the issue immediately apparent, while writing to a non-existing property is entirely silent. PHP gives no indication whatsoever that the programmer has made a mistake.

The Beauty of Ever-Evolving, Elegant Code

Brent Roose’s two-minute video on the evolution from PHP 5.6 to 8.2 is a brilliant and simple visual illustration of how far PHP has come from 2014 to the present. Using the example of a simple data transfer object, Roose shows how the PHP 5.6 code shrinks to a much simpler and overall more elegant block of code on the way to PHP 8.2.

As Roose notes in his tips for dealing with dynamic properties (which are deprecated in PHP 8.2), developers should have plenty of runway to update their existing code before deprecation warnings turn into fatal errors. That runway will diminish quickly, however, and WordPress is a special case. Tonya Mork has an accepted proposal in Trac for handling unknown dynamic properties deprecations in WordPress core. She and Juliette Reinders Folmer are concerned that WordPress developers won’t have enough time to refactor their code. The special challenges of maintaining forward and backward compatibility for a twenty-year-old project can’t be ignored. Mork, Reinders Folmer, and Sergey Biryukov have been the largely unsung heroes of this daunting task.

How WordPress Core Keeps Up with PHP and Maintains Backward Compatibility

In their discussion of Dynamic Properties and Magic Methods in PHP 8.2, Mork and Reinders Folmer point out that WordPress’s roots in PHP 3 and 4 keep it in a solidly procedural programming universe while PHP continues to advance as an object-oriented language. Core developers need to figure out a way to maintain the behavior of legacy code in today’s PHP without breaking backward compatibility “and still make the code better and more secure and mitigate the PHP 8.2 dynamic properties deprecation,” as Reinders Folmer puts it. “We are actually making our own lives very difficult with [WordPress core’s] no [backward compatibility] break rule,” she notes in the video.

“There a good reason for it,” Mork responds — “it’s for users. Users have confidence that they can push that button and upgrade, and that we’ve thought about backward compatibility, that we’ve prioritized it. It’s a cornerstone for us … so users can have the confidence to upgrade.”

All Development is Maintenance…

It’s a unique challenge to try to backport “modern” PHP to work with the two previous major versions of PHP for the sake of maintaining backward compatibility in WordPress core. Plugin developers have a much easier task of updating their code in ways that can take advantage of new features, like PHP 8.2’s readonly classes and dynamic properties deprecation. Much of this work is largely a form of maintenance too.

Architecturally, the changes PHP 8+ are bringing in focus on programming concepts like immutability. Immutable data structures “don’t inherently fix security issues,” but they do help developers’ code be less error-prone and more correct, according to Jacobs:

I wouldn’t say that an immutable data structure is innately secure, and a mutable data structure is insecure. Rather, immutable data structures can help to eliminate programming mistakes that can lead to security issues. By reducing the number of different states that our code can exist in, we can reduce our code’s complexity, and therefore reduce the chances of making mistakes.

Code That’s More Correct is Likely to Be More Secure

The best reason to maintain code to the standard of actively supported PHP versions is the reduce security risks. PHP 8.2 brings in helpful “guard rails” in Adams’ view but little that will excite programmers or be seen as game-changers. Something like the #[\SensitiveParameter] attribute might be more practically significant since it allows sensitive data to be filtered out of stack traces that often go to third-party services. Introduced in PHP 8, attributes are Adams’ pick for the last innovation that caught his eye for enabling something that you couldn’t do previously: “describe something [like classes, variables, methods, etc.] from a meta-perspective.”

Taking advantage of new features in PHP 8.0 to 8.2 and future releases is where developers’ creativity can shine, but simply supporting those versions, so plugins and WordPress core don’t break on them, is both practical and vital.

…And All Maintenance is Art

Jeff Atwood has an old but outstanding blog post titled “The Noble Art of Maintenance Programming” that I read recently, thanks to Kale Davis’s Hacker Newsletter. “Maintenance programming is widely viewed as janitorial work,” Atwood writes. This reminded me of the artist Mirele Laderman Ukeles, whose “Maintenance Art Manifesto” has always struck me as very relevant to programming and web development:

Two basic systems: Development and Maintenance. The sourball of every revolution: after the revolution, who’s going to pick up the garbage on Monday morning? […] Development systems are partial feedback systems with major room for change. Maintenance systems are direct feedback systems with little room for alteration.

“Who’s going to pick up the garbage on Monday morning?”

Laderman Ukeles was a young artist and new mother in 1969 when she wrote the manifesto and declared Maintenance is Art. She was frustrated with the way we separate cutting-edge works of art and high-status labor from the work that makes them possible. Parenting, teaching, or just putting on an art show are things artists do that aren’t recognized as part of their work. To point this out, Laderman Ukeles did a memorable exhibit based around herself acting as an art museum janitor. Then she spent most of her (ongoing) career as the New York City Department of Sanitation’s artist-in-residence. Her first project in that role was personally thanking all 8,500 sanitation workers “for keeping New York alive.”

Atwood has a similar take on programming. He quotes several major figures in software engineering who say the denigration of maintenance work is all wrong. Robert L. Glass felt “Maintenance is a significant intellectual challenge as well as a solution and not a problem,” so it ought to be regarded as an important task for the most skilled people. Joel Spolsky wrote long ago that developers are lazy, and the reason they “always want to throw away the code and start over” is that “it’s harder to read code than to write it.”

“All programming is maintenance programming”

In a conversation with Andy Hunt, Dave Thomas argued, “All programming is maintenance programming because you are rarely writing original code. …. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, “I’m maintaining from day one.” The disciplines that apply to maintenance should apply globally.” Hunt agreed, “It’s only the first 10 minutes that the code’s original when you type it in the first time. That’s it.”

Atwood ultimately leans toward this viewpoint but echoes the common WordPress developer perspective that I heard from Jason Adams and Timothy Jacobs. The special art of WordPress development/maintenance?

“It’s a balancing act.”