Milan Petrović has been developing for WordPress since 2007 and recently presented at WordCamp Europe on a topic many site owners and developers underestimate: the real risks of running legacy PHP and the benefits of moving to modern PHP 8.x. With decades of experience building plugins (notably for bbPress) and now working as a full‑stack developer at Freemius, Milan explained why upgrading PHP is both a security imperative and a performance win.
Why PHP version matters
Most WordPress users notice a PHP version number in their hosting control panel without understanding its consequences. PHP is the language that runs WordPress, themes, and plugins. Older PHP branches (like 7.4 and earlier) no longer receive fixes, and public bug reports for those versions remain open. Milan highlighted that thousands of confirmed bugs exist for PHP 7 and 5 branches—many of which are security‑relevant—and those bugs will never be fixed for unsupported versions. That means attackers can study public reports and build automated exploits that target whole classes of servers, regardless of the CMS being used.
The practical effects of staying on legacy PHP
– Increased attack surface: Unpatched, publicized bugs give attackers ready instructions for exploitation. That makes sites running unsupported PHP an attractive target.
– Unpredictable hosting patches: Some hosts maintain custom PHP builds or apply their own patches. While well‑intentioned, custom builds can behave differently from official PHP, introduce quirks, or inadvertently open new vulnerabilities.
– Compatibility fragility: Older plugins and custom code may break when moved forward, but staying on old PHP leads to growing technical debt and rising risk over time.
What PHP 8 brings to the table
Milan emphasized that PHP 8 is a major milestone. Beyond new language features, modern PHP versions include security improvements and significant performance gains. In some demonstrations, PHP 8.5 used dramatically less memory and ran identical code substantially faster than PHP 7.4—Milan cited performance gains that can exceed 50% in some cases. That means hosting providers can serve more sites with fewer resources, and site owners can see speed and memory benefits without changing application code.
Security by design vs. whack‑a‑mole sanitization
The talk positioned modern PHP features as “native shields” that reduce the need for fragile, manual sanitization patterns that developers have patched and re‑patched over the years. Milan used concrete exploit examples—authentication bypasses and server‑side request forgery (SSRF)—to show how identical code can be exploitable on legacy PHP but neutralized on newer PHP versions. He argued developers should design plugins and themes to be secure by design, leveraging modern language features rather than repeatedly chasing individual vulnerabilities.
Vulnerability Lab: a teaching tool for developers
To demonstrate the differences, Milan created the Vulnerability Lab plugin. It’s a developer‑focused tool that runs example code and shows how exploits behave under different PHP versions. The plugin can highlight both security outcomes and performance metrics (like memory usage) so developers and agencies can make a clear, demonstrable case for upgrading. Milan intends to expand the project into a pattern library that documents old‑style patterns and their safer, modern counterparts. The plugin is on GitHub and open to contributions.
Who should act and how
Milan addressed the roles of three groups:
– Hosting companies: They can accelerate adoption by offering newer PHP versions and encouraging—or requiring—clients to upgrade. Hosts also gain immediate infrastructure benefits from reduced memory usage and higher throughput.
– Developers and agencies: Update plugin and theme code gradually. Set a sensible minimum PHP version for your projects (Milan personally uses PHP 8.0+ for his plugins) and modernize incrementally: introduce stricter typing, replace deprecated functions, and adopt safer patterns as you go.
– Site owners: Treat your site like equipment that needs maintenance. Check PHP version in your hosting control panel, test on staging environments before upgrades, and be prepared to update or replace abandoned plugins that prevent safe upgrades.
Why WordPress as a platform matters
WordPress’s commitment to backwards compatibility has driven adoption but also slowed progress toward modern PHP standards. Milan suggested WordPress should more quickly move the minimum supported PHP forward (for example, making 8.x the baseline) to push the ecosystem toward safer defaults. He acknowledged that such a change must be gradual and community‑driven—there are many legacy sites and plugins that require careful migration and testing—but also argued that leadership from the Core project would accelerate adoption by hosting companies and plugin authors.
Practical starting points
– Test before you update: Use a staging environment to run your site under the newer PHP version and check for compatibility issues.
– Upgrade dependencies: Many third‑party PHP libraries already require PHP 8.x. Updating them can force a controlled move to newer PHP versions.
– Modernize incrementally: Start with small, low‑risk changes (strict typing, minor API replacements) and fix issues plugin‑by‑plugin.
– Use demonstration tools: Vulnerability Lab and similar tools can help convince stakeholders by showing concrete security and performance differences.
Final takeaway
Upgrading PHP is not just a performance tweak; it’s a security upgrade that reduces long‑term risk. The path forward is collaborative: hosting providers, plugin authors, agencies, and site owners all have parts to play. Milan’s message is pragmatic—modernize gradually, use the new language features to build security by design, and avoid the false comfort of “if it works, don’t change it.” The cost of inaction is real: more fragile sites, bigger attack surfaces, and avoidable performance costs.
If you want to explore Milan’s demonstrations, check the show notes for the WP Tavern podcast episode featuring his talk and the Vulnerability Lab plugin on GitHub for examples you can run and adapt.