In a recent Jukebox Podcast interview, developer Milan Petrović laid out a stark warning: running legacy PHP on WordPress sites is a growing security and performance liability. With nearly two decades in the WordPress ecosystem—building plugins, running Dev4Press, and now working as a full‑stack developer at Freemius—Milan has watched both WordPress and PHP evolve. His message is simple but urgent: modernize your PHP stack, and do it thoughtfully and gradually.

Why PHP version matters

Many WordPress users notice a PHP version number in their hosting control panel without understanding its consequences. PHP versions change the language itself: newer releases bring performance optimizations, memory improvements, and language features that reduce the risk of common vulnerabilities. PHP 8 was a major milestone, bringing native protections and patterns that can neutralize entire classes of exploits that were easy to trigger in older PHP branches.

The risk of staying on old PHP

Milan points to a worrying reality: thousands of open bug reports exist for older PHP branches like PHP 7 and even PHP 5, and many WordPress sites still run those versions. Those publicly documented bugs provide attackers with a detailed playbook. While some hosting providers maintain custom patched builds of PHP, such customizations can introduce their own quirks and hidden risks. The safest path for most sites is to rely on officially supported PHP releases and to move forward rather than remain years behind end-of-life versions.

Backward compatibility vs. security

WordPress’s long-standing commitment to backward compatibility helped drive its adoption. It allowed users and hosts to avoid frequent server upgrades and made WordPress accessible to non-technical customers. However, that same policy has also slowed the adoption of newer PHP features inside core and among plugin authors. Milan suggests that a policy shift—declaring a modern PHP version as the minimum supported—would encourage developers and hosts to update and would open the door for safer, stricter coding patterns across the ecosystem.

What modern PHP buys you

– Security: Newer PHP versions include language-level protections and runtime changes that neutralize many legacy exploits, such as certain authentication bypasses and server-side request forgery patterns.
– Performance: PHP 8.x continues to improve execution speed and reduce memory usage; Milan notes that PHP 8.5 is significantly faster and more memory-efficient than PHP 7.4. This translates to lower hosting costs and the ability to serve more sites with the same resources.
– Developer ergonomics: Features like stricter typing, attributes, and other modern language constructs make code clearer and less error-prone—reducing the surface for vulnerabilities.

Why migration is hard

Upgrading a site’s PHP version is not always simple: plugins or custom themes written years ago may break under stricter runtimes. Managed hosts that push updates face support burdens when customer sites suddenly fail. Some site owners treat their WordPress install like a bicycle that “just works” and resist maintenance. Milan argues that upgrades don’t need to be radical or immediate—instead they should be steady, incremental, and well-tested.

A practical tool: Vulnerability Lab plugin

To illustrate the differences between PHP versions, Milan created the Vulnerability Lab plugin. It’s targeted primarily at developers and agencies: the plugin runs small, demonstrative code patterns that behave differently on older and newer PHP releases. In practice it can show how the same code might fail, produce errors, or be exploitable on PHP 7.4 while being neutralized or more efficient on PHP 8.x. One example in the plugin demonstrates both improved security and dramatically lower memory usage when run on a newer PHP version.

The plugin is open source and available on GitHub. Milan envisions expanding it into a pattern library: documented examples of legacy patterns and their modern equivalents, annotated with the PHP version that introduces each improvement. Agencies can use such demonstrations to persuade clients that upgrading PHP is necessary, not optional.

A combined approach to security

Milan stresses that upgrading PHP is not a silver bullet. WordPress core practices—escaping, sanitization, capability checks, and other security hardening—remain essential. The goal is a combined approach: continue applying WordPress best practices while migrating code to leverage modern PHP features that reduce risk and improve resilience.

How to move forward

– Start small and iterate: adopt stricter typing and modern functions in parts of your codebase rather than attempting a full rewrite.
– Test carefully: use staging environments with the target PHP version to find and address compatibility issues before touching production.
– Monitor third-party library requirements: many PHP libraries now demand newer PHP versions, and using up‑to‑date libraries may force (or justify) an upgrade.
– Host and developer collaboration: hosts can phase upgrades and provide clear migration support; developers should clearly state minimum PHP requirements for plugins and themes.

Where to learn more

Milan recommends php.net for authoritative information on upcoming PHP features and version timelines. Tracking official change lists helps developers know what features and protections are available and in which versions. For WordPress-focused patterns and community efforts, Milan’s GitHub-hosted Vulnerability Lab is a practical place to see concrete examples and contribute.

Final word

The tension between ease-of-use and security is central to WordPress’s growth story. Milan’s plea is not to abandon that accessibility but to lead a gradual, community-driven modernization. Adopting modern PHP versions yields immediate gains in security and performance, and a steady upgrade strategy—backed by tests, tooling, and clear communication—can bring millions of sites toward a safer future.

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.