PHP 8.2.0 made its debut on December 8, 2022. As a major update, it brings performance improvements, simpler syntax, and greater type safety with null, false, and true as standalone types. One of the biggest changes likely to challenge WordPress developers is the introduction 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 also how WordPress developers maintain backward compatibility while taking advantage of new features when they will benefit end users the most.
.kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-table-of-content-wrap{background-color:#d7f0fc;border-color:#d7f0fc;border-width:1px 1px 1px 1px;border-radius:16px 16px 16px 16px;}.kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-table-of-contents-title-wrap{border-width:0px 0px 0px 0px;}.kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-table-of-contents-title{color:#0693e3;}.kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-table-of-content-wrap .kb-table-of-content-list{color:#0693e3;}.kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-basiccircle .kb-table-of-contents-icon-trigger:after, .kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-basiccircle .kb-table-of-contents-icon-trigger:before, .kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-arrowcircle .kb-table-of-contents-icon-trigger:after, .kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-arrowcircle .kb-table-of-contents-icon-trigger:before, .kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-xclosecircle .kb-table-of-contents-icon-trigger:after, .kb-table-of-content-nav.kb-table-of-content-id_46a642-47 .kb-toggle-icon-style-xclosecircle .kb-table-of-contents-icon-trigger:before{background-color:#d7f0fc;}
Keeping Up With PHP Development in WordPress
Because WordPress core maintains significant backward compatibility with no planned end-of-life dates when old versions won’t be supported, it falls to WordPress businesses to determine their own product or service life cycle and the versions of PHP they will 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)
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 over 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. The jump to PHP 8 holds many benefits, however, with 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
The tradeoff between catering to the widest possible audience of users and maintaining currency with PHP has always posed a dilemma for WordPress developers, hosts, and product companies. Agencies and freelancers with long-term clients and legacy sites face the same problem: updating minimum requirements may force existing customers to make significant changes to their sites or see them break.
On the one hand, the benefits of staying up to date with PHP are improved security and performance and the latest programming concepts and capabilities for developers. On the other hand, the main benefit of delaying the minimum required PHP is a happy (albeit complacent) and broad customer base. It’s a “pay me now or pay me later” situation. At some point, you have to rip off the bandaid.
Good data and telemetry about user environments can help determine the least disruptive time to raise a minimum PHP version requirement. Most plugin developers keep an eye on those numbers with their own tools, as it’s not a part of the WordPress.org plugin repository’s active install data. Inevitably, any potentially breaking change impacting many people is guaranteed to result in a flurry of support tickets.
Prioritizing backward compatibility involves high maintenance work too. 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.
As of the 7.2 version release, iThemes Security Pro has required PHP 7.3 or higher and supports up to 8.1. The decision to update the PHP requirement for iThemes Security Pro was made 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 its clear 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 features 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.
For WordPress products that are heavily invested in the Gutenberg block editor, like GiveWP, managing change can be even more challenging. 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 depends on a judgment call based on how many users will be adversely affected by the change. 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 let legacy code and its users branch off 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, reasonably 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 generally 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.
There’s another way to look at this situation. Dealing with deprecated features of PHP is actually forward-looking and compels developers to become fluent in the next iterations of an evolving language. Without this somewhat enforced exercise, existing knowledge would more easily settle into old habits that will become bad ones 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 that will be increasingly 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 that things will break in the future, but they aren’t broken now.”
Doing Without Dynamic Properties After PHP 8.2
Nikita Popov’s rationale 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.
Brent Roose’s two-minute video on the evolution from PHP 5.6 to 8.2 is a brilliant and simple visual illustration of PHP’s evolution along these lines from 2014 to the present. Using the example of a simple data transfer object, Roose shows how the PHP 5.6 version shrinks enormously to a much simpler, leaner, and overall more elegant block of code.
As Roose notes in his tips for dealing with dynamic properties (which are deprecated in PHP 8.2), developers should have plenty of runways 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, not to mention the special challenges of maintaining forward compatibility for a twenty-year-old project. Mork, Reinders Folmer, and Sergey Biryukov have been the largely unsung heroes of this daunting task.
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.
The best reason to maintain code to the standard of actively supported PHP versions is for security risk reduction. PHP 8.2 brings in helpful conveniences and “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,” he wrote. 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.
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 how cutting-edge works of art and high-status labor are divided from the work that makes them possible: parenting, teaching artistic skills and traditions, or just putting on an art show. She did a memorable exhibit based around herself acting as a 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.”
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.”
The Best WordPress Security Plugin to Secure & Protect WordPress now 35% off!
WordPress currently powers over 40% of all websites, so it has become an easy target for hackers with malicious intent. The iThemes Security Pro plugin takes the guesswork out of WordPress security to make it easy to secure & protect your WordPress website. It’s like having a full-time security expert on staff who constantly monitors and protects your WordPress site for you.
The post PHP 8.2: What Does it Mean for WordPress, Plugins, and Developers? appeared first on iThemes.