Thereâs a famous quote from the OWASP Top Ten documentation that reads roughly like this: âExperts sometimes say something is important even though the data doesnât support it.â That single sentence captures a tension that runs through every technical community, but nowhere is it more visible right now than in the world of PHP.
On one side, you have the PHP Internals team â core contributors pushing the language forward with strict typing, performance improvements, and modern paradigms. On the other side, you have the vast majority of working PHP developers managing legacy codebases, satisfying conservative clients, and deploying on shared hosts that havenât seen an upgrade in years. These two groups share a language, but they increasingly inhabit different worlds.
The Two Sides of PHP
PHP has always been a language of contradictions. It powers massive enterprise applications like Facebook and Wikipedia, yet it also runs countless small contact forms and family blog sites. Itâs a language that evolved from a set of Perl scripts into a fully-featured, modern programming ecosystem. That evolution, while impressive, has created a rift between those who can afford to chase the latest version and those who cannot.
The Enterprise / Modern PHP Developer
This developer works with Docker containers, continuous integration pipelines, and deployment automation. They use Symfony or Laravel, write tests as a matter of course, and probably contribute to open source projects. For them, upgrading PHP is straightforward â change a version number in a Dockerfile, run the test suite, fix any deprecation notices, and deploy. They benefit directly from every performance improvement and new feature. Strict typing makes their code more reliable. Union types make their interfaces more expressive. Attributes clean up their annotations.
This developer reads the PHP RFCs, has opinions on named arguments, and probably follows the PHP Internals mailing list. They represent the aspirational future of PHP, and the core team builds the language with them in mind.
The Small Shop / Legacy Developer
This developer supports a mountain of custom PHP code written over the last fifteen years. Their clients refuse to pay for rewrites. Their hosting company finally upgraded from PHP 5.3 to 5.6 last year and considers that cutting-edge. They are not using Composer. They may not even use a framework. Their code is a mix of procedural scripts, copy-pasted snippets from forums, and the occasional class file that someone wrote back when PHP 5 first introduced object-oriented features.
For this developer, every breaking change is a crisis. Every deprecated feature is technical debt they cannot pay down. They know they should upgrade, but they lack the time, budget, and authority to do so. And when they look at the PHP community, they see a group of people talking past them.
My Experience with PHP Internals
I spent a chunk of time following the PHP Internals mailing list. I wanted to contribute. I had ideas, bug reports, and the occasional patch. What I found was a space that did not feel welcoming to someone outside the core circle. Discussions were technical and fast-moving. The social dynamics were established. Newcomers asking basic questions were often met with impatience or silence.
This is not unique to PHP. Every open source project struggles with the tension between keeping discussions productive and welcoming new contributors. But for PHP, this dynamic has real consequences. When the people building the language are disconnected from the people using it, the language evolves in directions that create pain for the majority of its user base.
The Real Cost of Breaking Changes
Let me share a personal story. When the PHP community was preparing for PHP 7, I was working with clients who were still running PHP 5.4. Some were on 5.2. PHP 5.6, with its lovely features like variadic functions and constant arrays, might as well have been science fiction. These were not neglectful developers. They were small business owners running custom e-commerce sites, nonprofits with donated hosting accounts, and agencies balancing a dozen legacy projects on a shoestring budget.
For them, upgrading PHP meant: checking every line of code for incompatibilities, testing every third-party library (most of which were abandoned), coordinating with a hosting company that had no incentive to upgrade, and praying nothing broke in production. That kind of upgrade costs time and money they did not have.
What they needed from PHP was stability. No breaking changes. A clear, slow migration path that let them keep their sites running while gradually modernizing. What the core team needed was the opposite: the ability to modernize the language, drop old baggage, introduce strict standards, and push PHP into a competitive position against languages like Python and JavaScript.
The Value of PHP 7+
Lets be clear about something: PHP 7 and everything that followed has been outstanding for the language. The performance improvements alone â the PHPNG engine made PHP two to three times faster â were transformative. Applications that struggled under PHP 5 could suddenly handle twice the traffic on the same hardware. That is a concrete, measurable win.
Strict typing, while controversial at the time, made PHP code more reliable and easier to reason about. Combined with a strong type system, PHP became a language that could compete seriously in the enterprise space. Return type declarations, scalar type hints, nullable types, union types, and match expressions all made the language more expressive and less error-prone.
Modern PHP is a genuinely good language. It borrows the best ideas from its peers while maintaining its unique character. The people who built it deserve credit for that.
But.
For the small shop developer, these improvements come at a cost. Every new feature is another thing to learn. Every deprecated feature is another legacy codebase that will eventually break. The gap between âPHP I can writeâ and âmodern PHPâ grows wider every release cycle. Beginners used to be able to pick up PHP by reading a tutorial and uploading a file to a shared host. Now the recommended setup involves a local development environment, a package manager, and familiarity with concepts like autoloading and dependency injection. The barrier to entry is higher.
Finding Balance
The tension between progress and stability is not unique to PHP. Every mature platform faces it. Python went through the Python 2 to Python 3 transition, which took over a decade and is still not fully resolved. JavaScript evolves at a breakneck pace through TC39 proposals, and the ecosystem fragments accordingly. The difference is that PHP carries a disproportionate share of legacy code written by non-specialist developers.
The beauty of PHP has always been its accessibility. You can build a multi-tenant SaaS platform with it. You can also build a simple contact form. Both are valid uses of the language. Both should be supported. The challenge for the PHP community is to keep pushing the language forward without leaving behind the developers who made PHP popular in the first place.
Real-World Applications
How Different Scales of PHP Shop Operate
An enterprise PHP shop runs on modern infrastructure. They deploy containerized applications, use CI/CD pipelines, and monitor performance metrics. Their codebase is modular, tested, and follows established patterns. Upgrading PHP is a routine part of their maintenance cycle.
A small PHP shop runs on whatever the hosting company provides. They FTP files to a server, fix bugs in production, and cross their fingers when a client asks for a new feature. Their codebase is a monolith of accumulated decisions, some good, most pragmatic. Upgrading PHP is an event they postpone indefinitely.
Both shops are running PHP. Both are valid. But the gap between their experiences is enormous, and it grows with every release.
Hosting Challenges
Shared hosting remains the entry point for many PHP developers. Go to any cheap hosting provider and you will find PHP 7.4 or 8.0 at best, alongside outdated MySQL versions and no SSH access. These hosts have no incentive to upgrade. Their customers do not ask for it, and upgrades risk breaking existing sites. The result is an ecosystem where the latest PHP features are irrelevant to a significant portion of the user base.
Managed WordPress hosting is better, but even there, the upgrade cycle lags months or years behind the PHP release cycle. WordPress itself recommends PHP 7.4 or later, but millions of WordPress sites still run on older versions because the hosting environment has not been updated.
Upgrade Paths
For developers stuck on legacy PHP, the upgrade path is painful but not impossible. The key steps are:
Audit your codebase. Find every deprecated function call and every feature that changed between your current version and your target version. Tools like PHPCompatibility can help automate this.
Set up a staging environment. You cannot safely upgrade without testing. Many hosting companies offer staging sites, or you can set one up locally with Docker.
Fix deprecation warnings systematically. Work through them one category at a time. Most deprecations have straightforward replacements.
Update or replace third-party dependencies. Abandoned libraries are often the biggest blocker. Look for maintained forks or alternatives.
Run your test suite. If you do not have tests, write smoke tests for your most critical paths before attempting the upgrade.
Make the switch. Coordinate with your hosting company or update your deployment pipeline.
None of this is easy, but it is doable. The community has produced excellent migration guides for each major version. The PHP manual includes detailed upgrade notes.
Best Practices for the Community
Respect All Skill Levels
The PHP community needs to be more intentional about welcoming developers at every level. Not everyone contributes to open source. Not everyone uses the latest version. Not everyone writes tests. That does not make them less of a PHP developer. Mocking shared hosting or procedural code only drives people away from the community and makes the divide worse.
Documentation Improvements
The PHP manual is excellent, but it could do more to bridge the gap between versions. Highlighting not just what changed but why and how to migrate would help developers understand the evolution of the language. More âbefore and afterâ examples showing how code looked in older versions versus modern PHP would provide practical guidance.
Upgrade Guides
Every major release should include comprehensive, practical upgrade guides written for non-experts. Not just a list of breaking changes, but a step-by-step walkthrough of the migration process. Real examples. Common pitfalls. Hosting company recommendations.
Long-Term Support Considerations
The PHP community has discussed LTS releases for years. The argument against is that LTS releases fragment the ecosystem and reduce the incentive to upgrade. The argument for is that many organizations need a stable target they can rely on for years at a time. Given that PHP already has de facto LTS through distribution packages (Ubuntu ships PHP versions for years), formalizing the approach might reduce confusion.
Learning from the Divide
What Enterprise Developers Can Learn from Small Shops
Not everyone has the luxury of a modern stack. Enterprise developers benefit from understanding the constraints that small shop developers face. That awareness leads to better libraries, clearer documentation, and more thoughtful deprecation strategies. When you build a package that works well on PHP 8.2, ask yourself whether it could also work on PHP 7.4 with minimal changes. The answer is often yes.
What Small Shop Developers Can Learn from Enterprise
Modern PHP practices exist for a reason. Version control, testing, dependency management, and deployment automation all save time and prevent disasters. You do not need Docker and Kubernetes to benefit from Composer and PHPUnit. Start small. Use version control for every project, even the tiny ones. Use Composer to manage dependencies for new projects. Write one test for the most critical path in your application. The benefits compound.
What the Core Team Can Learn from Both
The PHP Internals team does difficult, often thankless work. They maintain a language used by millions of developers across the full spectrum of technical sophistication. Listening to that full spectrum â not just the loudest voices on Twitter or the mailing list â would produce better decisions. Surveys, user research, and direct outreach to underserved segments of the community would reveal pain points that the current process misses.
Frequently Asked Questions
Q: Which PHP version should I use for a new project in 2022? A: PHP 8.1 or 8.0. Both are actively supported, fast, and packed with features. Start with the latest stable release unless you have a specific reason not to.
Q: Should I upgrade an existing PHP 5.x project? A: Yes, but plan it carefully. Audit your codebase, set up a staging environment, and upgrade incrementally. Going from 5.6 to 7.4 and then to 8.x is safer than jumping directly.
Q: How long does a typical PHP upgrade take? A: For a small to medium project with a clean codebase, a major version upgrade takes one to three days of development time plus testing. For a large legacy project with no tests, it can take weeks or months.
Q: What if my hosting company does not support modern PHP? A: Consider switching hosts. Many affordable providers support PHP 8.x. If switching is not an option, you can use a compatibility layer or consider a Platform-as-a-Service solution that gives you more control over the runtime.
Q: Is it worth learning PHP in 2022? A: Yes. PHP powers a huge portion of the web. Job demand remains strong, especially for developers who understand modern PHP alongside legacy maintenance. The language continues to evolve rapidly.
Q: How do I handle abandoned third-party libraries during an upgrade? A: Look for maintained forks on Packagist or GitHub. If none exist, consider replacing the library with a modern alternative or maintaining a private fork with the necessary compatibility fixes.
Q: What are the most common breaking changes to watch for during upgrades? A: Deprecated function removals (especially in PHP 8.x), changes to error handling (most errors are now exceptions), and changes to the behavior of loose comparisons. Always review the upgrade guide for each major version.
The Path Forward
The PHP community does not need to choose between progress and accessibility. It needs both. The core team should keep pushing the language forward, because stagnation is death for a programming language. But they should also invest in making the transition easier for the majority of developers who cannot keep pace.
The small shop developers need to accept that change is inevitable and invest incrementally in modernizing their practices. The enterprise developers need to remember that not everyone shares their circumstances and build tools and documentation that work for everyone.
We are all experts in our own experiences. The developer running PHP 5.6 on a shared host knows things about real-world deployment constraints that a core contributor writing PHP 8.x RFCs may not. And that core contributor knows things about language design and performance optimization that the small shop developer may not. Neither perspective is wrong. Both are incomplete.
The strength of PHP has always been its diversity. It runs on cheap shared hosts and massive server clusters. It is written by beginners copying tutorials and by engineers building distributed systems. Bridging the gap between these worlds does not mean slowing down. It means bringing everyone along for the ride.
That starts with respect. Respect for the developer who cannot upgrade. Respect for the developer who pushes for change. And respect for the messy, imperfect, beautiful reality that PHP powers a huge chunk of the web, from the simplest contact form to the most complex enterprise application. If we can hold onto that respect, the divide is not a weakness. It is our greatest strength.