This episode of the Jukebox Podcast (WP Tavern) features Milan Petrović, a long‑time WordPress developer who presented at WordCamp Europe about the security and performance risks of running legacy PHP with WordPress — and practical steps to modernize safely.
Who Milan is
Milan has worked with WordPress since 2007, building many plugins (especially for bbPress) and running Dev4Press before joining Freemius as a full‑stack developer. Over nearly two decades he’s watched both PHP and WordPress evolve and seen firsthand how older PHP versions create real dangers for sites and plugins.
The problem in brief
Many WordPress users only notice a PHP version number in hosting control panels and may assume “if the site still works, nothing needs changing.” Milan counters this complacency: older PHP branches like 7.x and earlier remain in use on many sites even after end of life, and there are thousands of confirmed, unpatched bugs in those older PHP versions. Because those bugs are public, automated exploit tools can target them regardless of whether a site runs WordPress, a custom app, or plugins.
Why PHP 8.x matters
PHP 8 (and later minor versions) brought language changes that act as native shields against many classes of vulnerability and also deliver significant performance and memory improvements. Milan pointed out that later PHP releases can be dramatically faster and use less memory than 7.4, with real hosting cost and capacity benefits. Beyond speed, PHP 8 adds language features — stricter typing, new attributes and APIs — that make code safer and easier to harden against exploits like authentication bypasses and SSRF.
WordPress’s backward compatibility tension
WordPress’s long commitment to backward compatibility helped drive mass adoption, but it also slowed the platform’s ability to push forward on server‑side requirements. Core still supports older PHP branches, and many plugins do too, because the ecosystem includes millions of nontechnical site owners and countless legacy plugins. Milan argues this makes progress slower, but he suggests a pragmatic path: WordPress could declare PHP 8.x as the new minimum and then modernize the codebase gradually over time rather than all at once.
Who should act and how
– Hosting companies: They have the biggest leverage. Upgrading default PHP versions across their infrastructure yields immediate performance wins and reduces attack surface. Some hosts create custom patched PHP builds, but that can introduce quirks and hidden risks; sticking to official, supported PHP releases is generally safer.
– Plugin and theme authors: Set realistic minimal PHP requirements (Milan has set 8.0 for his plugins) and update incrementally. Use modern PHP features where practical: stricter typing, newer functions and attributes, and replace deprecated patterns.
– Agencies and site owners: Test and upgrade deliberately. Legacy sites that haven’t been maintained need careful testing because updating one plugin or PHP version can reveal other breakages. But a phased approach is achievable: fix high‑risk components first and move forward over months or years rather than expecting wholesale, immediate rewrites.
Vulnerability Lab plugin — a teaching tool
To make the differences tangible, Milan built the Vulnerability Lab plugin. It demonstrates how identical or similar code can behave differently across PHP versions — sometimes exhibiting fatal errors, sometimes allowing exploits, and sometimes being neutralized by new language protections. The plugin highlights examples like authentication bypasses and SSRF, and also shows memory and performance differences. It’s intended for developers and agencies to test on development and staging sites and to present clear, visual evidence to clients who resist upgrades.
Practical advice Milan gives
– Start small and be gradual: introduce stricter typing and modern patterns incrementally rather than attempting a full rewrite.
– Combine approaches: keep using WordPress core security best practices (sanitization, escaping, capability checks) while adopting PHP features that reduce risk at the language level.
– Watch third‑party libraries: many libraries outside WordPress already require newer PHP versions; depending on them can force plugin authors to raise their own requirements.
– Use resources: check the official PHP website for upcoming features and changes, and refer to plugin and library documentation.
Where to learn more and contribute
Milan published the Vulnerability Lab plugin on GitHub and welcomes contributions and suggestions. The PHP project website is recommended for tracking upcoming releases and detailed change logs. The podcast episode notes on wptavern.com include links to Milan’s talk and resources discussed.
Bottom line
Running end‑of‑life PHP exposes WordPress sites to known bugs and automated exploits, while newer PHP versions offer measurable security, performance, and memory benefits. Moving the ecosystem forward will require coordinated action from core maintainers, hosting providers, plugin authors, agencies, and site owners. The migration can be gradual and practical: test on staging, fix critical plugins, adopt stricter typing and modern PHP patterns, and use demonstration tools like the Vulnerability Lab to make the case for upgrading. Milan’s message is clear: modernize deliberately — a small step at a time — to make WordPress sites safer and faster.
