PHP Turns 31 and Vonage Watches PHPVerse

It’s remarkable to think that June saw PHP turning 31 years old. From its origins as a basic scripting language to help a single developer to an Open Source juggernaut of the web, it’s been quite the journey. If you’re curious to see what the current state of PHP is like and where it’s heading, you’ll get a pretty good picture from reading this summary.

For my day-to-day work, I am, at heart, still a PHP Developer. Anything that I build, from demos to Open Source contributions, has centred around Vonage’s PHP SDK. This is something core to what we do; individual languages and their communities are important to be connected to.

Following on from me interviewing the Executive Director of The PHP Foundation, JetBrains announced another yearly instalment of PHPVerse, an online-only day conference for PHP developers. This year, as with last year, it delivered a stellar lineup of Open Source regular faces to speak on a variety of community subjects. In this article, I’m going to go through half the talks with commentary to either keep your PHP knowledge shiny, or if you aren’t a PHP developer, you might find some insight into why it’s still so popular. Expect part two to follow.

Elizabeth Barron: Getting To Know the PHP Foundation

I started with mentioning Vonage speaking to Elizabeth, so it probably makes sense to begin with this talk. Since its creation, it has been refreshing to have an Open Source governance infrastructure for PHP. The Foundation has been added to The Linux Foundation, received a significant boost of funding from the Government of Germany, and now has a team of internal, fully paid developers across the world.

This talk concentrated on where she has steered the Foundation starting out, and what planning is underway, as well as thoughts on the future. So, I’ll break them down into these three areas.

One: Findings

Starting out, Elizabeth decided to listen. This involved many, many calls (around 60, your author being one of them) to gather PHP Developers’ thoughts on where the language is at. The conclusion was four different areas for attention:

·      Transparency

·      The perception of PHP outside of our community

·      Lack of new developers for growth

·      Internals & the voting process

Two: Actions

As a result of these findings, the following initiatives have been launched under the umbrella term “Special Interest Groups” (SIG):

·      Ecosystem Security Team SIG

·      PHP Outreach Ambassador Program SIG

·      Onboarding SIG

·      Cryptography SIG

·      Community Events SIG

·      Accessibility SIG

Anyone who is interested in joining these groups can find out how on The PHP Foundation Blog

Three: The Future

The biggest problem PHP faces is a perception problem, not a technical one. She concluded that the language is stable, the community large and engaged, so reasons to be cheerful.

Nils Adermann: Composer and Packagist Supply Chain Security in 2026

Following on from the announcement this year of an Ecosystem Security team at The PHP Foundation, it seems apt that Nils came on to talk about Supply Chain security. We’ve seen several high-profile cases in the past five years, such as the XZ Utils compromise, where a rogue maintainer managed to sneak a backdoor into ZX Utils release tarballs: something used on many major Linux distributions. There have also been increases in local machine attacks, which is unsurprising given that AI tooling plus IDEs such as VSCode and PHPStorm are now doing a lot of external calls to write code. These tools also have Open-Source plugin marketplaces, resulting in GitHub repository access being one of the most common attacks across most major package managers.

Composer’s Risk Surface: Publishing

Composer's publishing model has always had a structural advantage: when you tag a release on GitHub, Packagist records a URL pointing at the GitHub API, which dynamically generates a zip file directly from the source code.

The downside is that these dynamically generated zip files are not stable. They change over time, which means you cannot sign them securely. While Composer’s lock file will pin a commit for a given tag, it means that for security auditing, developers have to carefully review lock files. I don’t know if you’ve worked on a large project, but these can get super large. Packagist (the company behind Composer), however, has an update review feature, so there is tooling out there to take some pain out of this.

Shipped Security Features

A number of security measures have already been shipped to combat supply-chain attacks.

·      Stable Version immutability

·      The Dependency policy framework

·      Source code fallback if zip download fails now disabled by default

·      Aikido Security automatic scans

·      Public transparency log

New Features in Development

·      Centralised package portfolio security control for larger projects, e.g. Symfony

·      Release cooldown, to allow for automatic scanning

·      Staging windows for publishing

·      Enforced Multi-factor authentication (MFA)

·      Immutable artifact hosting by Packagist, to increase package manager trust

How You Can Help

Firstly, there are several steps you can take now to enhance your security. This includes

·      Enabling MFA

·      Use tooling such as Zizmor for CI pipeline security

·      Make sure you are on Composer 2.0

·      Use Private Packagist’s hosting for custom security requirements.

More importantly, developers and organisations can forget the statistics behind something that is, essentially, free. Packagist receives 4800 requests per second, is the de facto only PHP Package Manager, and serves 450,000 packages being installed around 4 billion times a month. While some funding for features comes from The PHP Foundation, it is essential that Packagist receives the funding it needs to maintain this infrastructure. A formal sponsorship programme is being launched this month; if your organisation depends on this infrastructure, then it’s vital it gets the funding it needs.

Jonathan Bossinger: WordPress is Dead, Long Live WordPress

Those that know me have quite possibly seen that I am on somewhat of a crusade against a famous sentence that people trot out which is untrue. If this is true of PHP, it’s fair to say that WordPress has exactly the same baseless opinions thrown at it. The thing is, you don’t get to still run 40% of the web if it’s not worth using.

Jonathan concentrated on a series of myths to dispel, so here are ten conveniently arranged myths he spoke about.

Myth 1: A Legacy, non-PHP-like OOP Codebase

It was quite the surprise for me to learn that all new installs of WordPress use PHP8.3, and now have type declarations, interfaces, and namespaces, after a push from 2020 onwards to modernise the codebase.

Myth 2: No Templating Engine

Block themes now use Block Markup, which is an HTML comment-based templating language. The PHP tags from the old world (anyone nostalgic for the HTML pages littered with PHP mixed in?) have gone, so yes: it now does.

Myth 3: WordPress is Slow

Another accusation that has been made about PHP in general, in the past. WordPress now has a Performance Lab plugin that benchmarks and improves the speed. Speculative loading was shipped into core WordPress 6.8, with a 98.2% performance boost.

Myth 4: Global State all the things

Blocks now have independent states, which can separate the front and backend scopes. Gone is the legacy use of the_post() and other such horrors that I remember many, many years back in WordPress

Myth 5: Custom Fields require Third-Party Plugins

The introduction of the Block Bindings API has now done away with the requirement for custom fields to almost always need a series of third-party plugins to make them work.

Myth 6: You Need to Learn React

Matt Mullenweg perhaps scored a bit of an own goal with this one when the Gutenberg project started to ship. After remarking that developers would need to learn JavaScript as an essential skill, perhaps some PHP developers were concerned. I mean, I would be given that I have a fairly irrational hatred of React. Developers who don’t want to touch the frontend can use the Interactivity API to achieve this, so the interaction is with dynamic blocks.

Myth 7: WordPress is Insecure

Another common one, many steps have been taken to make sure developers are armed with the tools they need to make this not the case. Automatic updates for plugins and themes, rollback protection, and bcrypt password hashing have all shipped, and WordPress itself has no unpatched critical vulnerabilities.

Myth 8: No Dependency Management

While it is true that WordPress doesn’t ship with Composer support out of the box, the Roots Bedrock project enables this. The same team recently launched WP Packages, which is a Composer repository for every free plugin and theme from wordpress.org

Myth 9: Outdated Documentation

Automattic’s Developer Relations team has been busy, as is evidenced by the amount of work they have put into the developer blog, publishing tutorials and the video series Learn WordPress. The developer portal has had a total rehaul, so now themes, plugins, the block editor and the REST API are comprehensively covered.

Myth 10: You Can’t Use Native Modern PHP Exception

True, in the past WordPress had its own Exception object, WP_Error. This constraint has now been removed, so developers are free to create their own custom exception handling. The core team themselves are currently discussing the possibility of removing WP_Error from the code.

Conclusion

Like developers who might judge PHP based on the experience from 20 years ago, it’s worth considering revisiting. The fact is that modern WordPress developers are using tooling like PHPStan, PHPUnit, Composer, etc., but the wider community simply isn’t aware. From this viewpoint, Jonathan issues a challenge to WordPress developers to write about modern development in the platform, and for non-WordPress developers to give it another shot.

Fabien Potencier: Symfony At Scale

Symfony was the first PHP framework I ever used. In fact, when I was doing ad-hoc training, I trained in Symfony 2. Since those days, the project has grown massively. Fabien has been the man at the helm for over 20 years.

What maintenance does Fabien need to administer? Well, there are more than three hundred repositories, with 5000 tagged releases a year. 25% of all Composer Packagist downloads come from Symfony (though Fabien is quick to note that downloads tend to be a bit of a vanity metric because of pipeline downloads).

An aspect that I find really interesting about Symfony is how the framework is structured: it is both a fully-fledged framework, and simultaneously a series of stand-alone components. Because of this design, it’s used as the engine for other large projects such as Joomla! and Drupal, but also as components used by projects like Laravel and Magento, all of which are mentioned by Fabien.

For many years at the start of my career, the “microservices” vs. Monorepo debate raged. So, interestingly enough, Fabien tells us of his conscious decision right at the start of Symfony 2 that everything would live in the same repository, under symfony/symfony. A tool he created called Splitsh handles installation, which listens for GitHub webhooks that then pull in any other packages requested during the installation under the symfony namespace, including Symfony AI, Twig, Symfony UX and Symfony Console, to name a few. These are called “sub-splits”.

How Has Symfony Been Able To Do This?

Fabien outlines four core areas that have got Symfony where it is today.

Firstly, stability within the core team. Fabien at the helm, 30 core developers with many long tenures.

Next, an opinionated framework. I am a very, very big fan of this approach, because when I have to work in the Node world, I am constantly bamboozled by the many, many options you can take when coding. There is a consistent code style (“The Symfony way”) and open standards (PSR).

For your clients that rely on the framework, consistency is key. Symfony is set up for two minor releases per year, and one LTS release every two years.

Finally, something dear to my heart because of the maintenance we have to do on the Vonage PHP SDK: semantic versioning. I cannot understand how we released software before without using semantic versioning.

Automation and AI

A tricky aspect of maintaining an Open Source project of this size is that you’re going to need the right processes and therefore the right tooling to help you achieve it. Throughout most of Symfony’s life, it’s been a lot of manual steps. AI has, however, changed this.

Custom agents have been created by Fabien to handle the majority of bulk and repetitive tasks. These include handling the investigative work behind difficult merge conflicts, especially since Symfony currently has to maintain six tagged branches.

The release process itself is now run by a PHP agent written by Fabien himself. This agent takes the release command, then asks what kind of release it is, replies with a release plan that must be reviewed, and then can execute when confirmation is given. It even has a skill added to be able to generate draft blog posts for releases.

AI’s Upsides and Downsides: Security

Perhaps it’s because of the speed at which we are moving in the age of AI, but the downsides are not always discussed so openly. Fabien tells us that they used to get a security audit once a month. Now they get one a day. Even recently, they’ve shipped a Symfony version that fixed 50 common vulnerabilities (CVEs).

This sheer volume of high cadence is being driven by one thing: LLMs. The reason that I state that I feel there are upsides and downsides is that the Symfony team is now essentially required to be using LLMs to fix this amount of code, because if the Symfony team doesn’t, someone else will find a CVE via an LLM. The other downside is having to vet the responses for false positives, but overall there is a positive step in that Fabien aims to use this tooling to ship hardened releases, rather than patching them after.

Conclusion

Essentially, Symfony goes from strength to strength, and Fabien and the core team have been using every tool available to them to stay on top of a PHP Framework that does some of the heaviest lifting in the entire industry. Personally, I’ve seen so many changes (I think the release of Symfony Flex was around the time I moved to other frameworks) and came back to a dizzying array of capabilities with brilliant documentation.

Next Time…

There were eight talks in all, so look out for round two, where I’ll be covering AI with Ashley Hindle and Jeffrey Way, Drupal with Mike Merchel, and PHP RFC’s with Larry Garfield.