In a recent Jukebox Podcast interview, Milan Petrović explained why moving away from legacy PHP is critical for WordPress sites — not just for performance, but for security. Milan has worked with WordPress since 2007, built many plugins (especially for bbPress), ran his own plugin company Dev4Press, and now works as a full stack developer at Freemius. His long experience gives him a clear view of how both the WordPress and PHP landscapes have changed and why staying on old PHP is dangerous.
Why PHP version matters
Many WordPress users notice a PHP version number in a hosting control panel and then forget about it. But PHP versions are not just background detail: they include language-level fixes and protections that close entire classes of vulnerabilities. Milan argues that PHP 8 marked a major milestone, introducing native behaviors that neutralize exploits which would succeed on older branches. Beyond security, newer PHP releases bring substantial performance and memory improvements — sometimes freeing up half the memory for the same code and improving speed dramatically.
The legacy problem and the tradeoff
WordPress has prioritized backward compatibility from early on, and that helped make it ubiquitous. The downside is that the core — and many plugins — still run on outdated PHP versions. Milan notes that many sites remain on PHP 7.4 or older, and there are thousands of open bug reports for older PHP branches that will never be fixed. Those public bug details can be used by automated tools and attackers, creating an active threat to sites that remain on unsupported PHP.
Who should act: hosts, developers, site owners
Milan makes the point that responsibility is shared. Hosting companies can drive adoption by offering and encouraging newer PHP versions; managed hosts are already doing this for many customers. Developers should modernize plugin and theme code to take advantage of PHP 8’s features and protections. Site owners, especially those with older, unmaintained plugins, need to be aware that a working site today may be exposing them to serious risk.
A practical path forward
Milan does not expect an immediate drop of support for PHP 7 across WordPress, but he recommends a clearer, faster move toward modern versions. One practical approach is for projects to declare a minimum supported PHP (for example PHP 8.0) and then modernize incrementally. Incremental changes can include stricter typing, replacing deprecated functions, and adopting small language features that reduce vulnerability surface. This phased strategy spreads work over time and avoids sudden breakages.
Vulnerability Lab plugin: a teaching tool
To demonstrate the differences between PHP versions, Milan created a Vulnerability Lab plugin for his talk. It lets developers run example exploit patterns and observe how identical code behaves under old and new PHP versions. Some examples show fatal errors on older versions but clean behavior on PHP 8, while others reveal how updated PHP reduces attack surface and memory use. The plugin is aimed mainly at developers and agencies: it can be used to show clients the concrete effects of upgrading or to test code on different PHP versions. The project is on GitHub and open to contributions.
Why this is also an operations and business issue
Upgrading PHP is not purely technical: it has operational and customer-facing implications. Hosts worry about breakages and the support overhead of migrating millions of sites. Agencies face clients who insist a site “just works” and resist change. Milan likens site maintenance to maintaining a bicycle: if you never look after it, parts will corrode and fail. The goal is not to force everyone abruptly, but to build awareness and enable a gradual migration that reduces risk and yields performance gains.
Third-party libraries accelerate the shift
Outside WordPress, many PHP libraries already require newer PHP versions. If a plugin depends on an external library that raises its minimum PHP, plugin authors are forced to follow. That ecosystem pressure is another reason WordPress and plugin developers will need to modernize: dependencies will push requirements forward independent of WordPress core policy.
Resources and next steps
For developers, the PHP official website documents upcoming releases and detailed change lists — a useful place to track what features and fixes land in each version. Milan advises using the combination of WordPress core security patterns (escaping, sanitization, nonces, etc.) together with modern PHP features. Start small: adopt stricter typing, replace old functions, and test components on newer PHP versions. For hosts and agencies, create safe upgrade paths, test environments, and clear communications for customers.
Conclusion
Milan’s message is straightforward: legacy PHP is an avoidable risk. Upgrading brings security protections, performance improvements, and long-term maintainability. It will require coordinated effort from WordPress leadership, hosting providers, plugin authors, and site owners, and it’s realistic to proceed gradually. Tools like the Vulnerability Lab can help make the differences visible and persuasive, turning abstract advice into concrete evidence for upgrading.
