At WordCamp Europe, developer Milan Petrović used his WP Tavern podcast appearance to make a simple but urgent case: if your WordPress site, plugin stack, or hosting setup is still tied to legacy PHP, you are carrying avoidable security and performance risk. Petrović argued that newer PHP 8.x releases are not just incremental upgrades, but a practical way to reduce exposure to known bugs, improve efficiency, and push the WordPress ecosystem toward safer defaults.
Milan Petrović’s message on legacy PHP in WordPress
Petrović has worked in the WordPress ecosystem since 2007, building plugins, especially for bbPress forums, through his company Dev4Press before joining Freemius in 2024 as a full stack developer. In the interview, he said that nearly two decades of work across WordPress and PHP have made the security implications of older runtimes hard to ignore.
His WordCamp Europe presentation, titled Secure by design, hardening plugins with PHP 8.x, focused on a theme many site owners never think about until something breaks: the version of PHP powering their sites. He said too many users see PHP only as a number in a hosting panel, without understanding that it affects security, speed, and memory usage.
Why PHP 8.x matters for WordPress security
Petrović said PHP 8 was a major milestone because it gives developers more than just new syntax or conveniences. In his view, the real change is that modern PHP offers built-in protections and language-level improvements that can neutralize common attack paths more effectively than legacy code running on older branches.
He described legacy PHP as an “active invitation for automated exploitation,” especially when code remains on versions that are past end of life. In the conversation, he pointed to the large number of open bug reports on PHP 7 and PHP 5 as evidence that some problems will never be fixed in those branches.
- PHP 7.4 reached end of life four and a half years ago, according to Petrović.
- He said there are 3,000 to 4,000 open bug reports for PHP 7 and PHP 5.
- He warned that many of those issues are security-related and publicly documented.
That public documentation, he argued, creates a roadmap for attackers. Once a version is unsupported, security fixes stop arriving, but the bugs remain visible to anyone willing to look for them.
The trade-off WordPress made with backwards compatibility
One of the central tensions Petrović discussed is the long-standing WordPress commitment to backwards compatibility. He said that policy helped WordPress adoption by making it easier for users and hosting companies to stay on older infrastructure without frequent upgrades.
That choice helped WordPress become cheap to host and easy to deploy, but it also slowed progress. According to Petrović, Core is still affected by support for older PHP versions, and the platform remains several years behind the end of life of the runtimes many sites still use.
He said WordPress does not need to change everything at once, but it should move faster in adopting newer minimum PHP versions. In his view, even a relatively small step such as making PHP 8.0 the minimum would pressure the wider ecosystem to modernise.
What a minimum PHP 8 requirement could change
Petrović said raising the minimum version would not require immediate rewrites of WordPress Core, but it would open the door to gradual internal improvements. He specifically mentioned stricter typing and the ability to modernise the codebase over time rather than in a single, disruptive migration.
He also stressed that plugin authors would likely follow that lead. In his own work, he said he has already set PHP 8.0 as the minimum requirement for his plugins this year, even though updating legacy code is a gradual process rather than a one-time task.
Performance gains are part of the argument
The security case was not the only point Petrović made. He said each newer PHP version tends to deliver measurable performance improvements without any code changes, including around 5 to 10 percent more performance per release. He added that PHP 8.5 is more than 50 percent faster than PHP 7.4.
He also cited a slide from his talk showing that the same code can consume far less memory on PHP 8.5 than on older releases. For hosting companies, that difference matters because lower memory use and higher throughput can translate into running more sites on the same infrastructure.
Petrović framed that as a strong business case, even if migration requires investment. In his view, hosts that support newer versions can free resources, improve performance for customers, and reduce the cost of running their platforms.
Why migration is slow despite the benefits
So why has the industry not moved faster? Petrović said the answer varies by hosting provider. Managed hosts are often more aggressive about pushing upgrades, but they also carry the support burden when plugins or sites break after a server-side change.
He said some customers expect their websites to behave like static objects: if the site worked yesterday, they assume it should work forever. That expectation creates friction, especially when old plugins or custom code have not been maintained in years.
At the same time, he noted that many plugin developers have already moved on to PHP 8 support, particularly for popular plugins that have had the resources to modernize. The harder cases are older sites with dependency chains that are expensive to test and risky to change.
- Managed hosts may push upgrades, but they inherit the blame when something breaks.
- Older plugins can fail on newer PHP if they were never updated.
- Custom site changes can make one fix trigger another issue elsewhere.
Vulnerability Lab: a plugin built to demonstrate the problem
To show the differences between old and new PHP in a practical way, Petrović created the Vulnerability Lab plugin for his talk. He said he built it specifically to demonstrate how the same code behaves differently across PHP versions and to make security issues easier to understand.
The plugin is aimed at developers, not casual users. Petrović said it can show fatal errors on PHP 7.4 in one case, while the same code runs normally on a newer version. He also said one example demonstrates both security and performance by showing that the same code uses almost half the memory on the newer runtime.
He plans to expand the plugin with more examples, and said it is available on GitHub for contributions. He also suggested the idea could evolve into a pattern library showing how common legacy approaches can be improved with modern PHP features.
His broader point for WordPress developers
Even while advocating for PHP upgrades, Petrović was clear that modern PHP is not a replacement for established WordPress security practices. He said escaping, sanitisation, and other Core protections still matter and should remain part of any secure plugin or theme.
His argument is that the best results come from combining those WordPress-native defenses with the safeguards and capabilities built into PHP 8.x. He said developers can start small, updating one function, one pattern, or one plugin at a time rather than trying to rewrite everything at once.
What developers and site owners can take from the talk
Petrović’s message was aimed at multiple audiences at once: developers, hosting companies, agencies, and ordinary site owners. For developers, he wants the ecosystem to treat modern PHP as a baseline rather than an optional enhancement. For hosts, the appeal is performance, resource savings, and fewer long-term risks.
For site owners, the takeaway is more mundane but just as important: if your WordPress site is still running on an old PHP version, there may be hidden security and compatibility costs you do not see in daily use. As Petrović put it, the transition does not have to happen all at once, but it does need to start.
Explore more: Blog Our Services Contact Us
Source: Original report
Was this helpful?
Last Modified: August 10, 2026 at 4:48 pm
1 views
