WordCamp US 2026: PHP conversation  🔗 **Source:** [WordCamp US 2026: PHP conversation](https://make.wordpress.org/core/2026/09/03/wordcamp-us-2026-php-conversation/) At WordCamp US 2026, a group of contributors gathered for an informal conversation about the relationship between the WordPress project and the PHP language and community. The discussion was held under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule), so notes below are not attributed to individual participants. **Attendees:** [@jorbin](https://profiles.wordpress.org/jorbin/) [@johnbillion](https://profiles.wordpress.org/johnbillion/) [@obenland](https://profiles.wordpress.org/obenland/) [@griffbrad](https://profiles.wordpress.org/griffbrad/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@dmsnell](https://profiles.wordpress.org/dmsnell/) [@jason\_the\_adams](https://profiles.wordpress.org/jason_the_adams/) [@desrosj](https://profiles.wordpress.org/desrosj/) [@mdawaffe](https://profiles.wordpress.org/mdawaffe/) [@4thhubbard](https://profiles.wordpress.org/4thhubbard/) [@westonruter](https://profiles.wordpress.org/westonruter/) [@annezazu](https://profiles.wordpress.org/annezazu/). A framing question opened the conversation: what are our current pain points with the language, historically and today? #### Pain points and concerns ##### Perception and Community Relations * Many in the PHP community don’t consider WordPress developers to be “PHP developers.” Part of this is due to WordPress being seen as dragging PHP backwards because of its backwards compatibility commitments. * Many PHP language features are discussed on the internals mailing list without a WordPress perspective in the room. This is something anyone can join but that we haven’t necessarily prioritized and causes missed opportunities. * When folks raised a WASM proposal, there wasn’t interest at the time. It might be a more apt time to revisit this conversation. ##### Backwards compatibility and the plugin ecosystem WordPress’s long backwards compatibility window creates friction across the ecosystem: * Plugins that depend on other packages run into trouble because the broader PHP ecosystem doesn’t support versions as far back as WordPress does. * Possible responses discussed: contacting plugin authors directly, delisting incompatible plugins, and leaning on plugin developers to be more proactive. A complicating factor: most plugin authors aren’t keeping plugins up to date, and many don’t log in at all. * One forward-looking, wishlist idea that doesn’t solve backwards compat but that could potentially help with plugin security: PHP could add a language feature to load modules with flags applied, enabling a security policy for plugins. Any code required by untrusted code would itself be tainted as untrusted. ##### Testing and tooling * It can be hard to produce verifiable cases to test compatibility. * There’s an upcoming (not yet ready) release of PHP\_CodeSniffer that fixes a lot of what we don’t currently have sniffs for. This would help extenders come up to standard quickly. * Code is landing in Gutenberg that isn’t compatible with PHP 7.4. Differences between the automated tooling for Gutenberg versus Core cause issues when that code flows into Core. * A nightly PHP Docker container to run locally would help. WordPress could put in the work to do it. [Early follow has started here](https://core.trac.wordpress.org/ticket/65904). #### PHP version adoption PHP 7.4 is still running on roughly 18% of websites ([stats](https://johnbillion.github.io/wp-stats/php.html)). There’s been less of a compelling reason for sites to upgrade recently. Ideas discussed: * A coordinated push from hosts to get more sites upgraded. * Making PHP 8.x meaningfully faster for WordPress, so speed becomes the compelling reason to upgrade. * Security is already a reason to push on to update since older PHP versions that WordPress supports are no longer receiving security patches. * The issue is not that folks are on old versions of WordPress itself. Stats could be pulled to see whether that has changed. #### WASM The last time a WASM proposal was raised it failed to gather enough interest for people to advance it into an RFC. At the same time, PHP receives lots of security issues, and reducing surface area could be helpful to them. WordPress is already using WASM client-side and with Playground. A more meaningful conversation with the PHP community about WASM would be worthwhile. Tied to this, it may be worth running a PHP extension with WASM, gathering operational data and experience, and sharing that back with the PHP internals to show real world use. #### Context for historical involvement We discussed why more involvement hasn’t happened without any one structural issue to point to. The main venues are PHP Internals and PHP-FIG. WordPress discussed joining FIG roughly 12 years ago but decided it didn’t want to be involved and wouldn’t get any benefit. There have long been backchannel relationships and occasional public collaboration, but nothing intentional. Some context on why involvement has been limited: * WordPress doesn’t need much from the language and has always been conservative in adopting language features. Server performance and security are what pull WordPress in; language features are pushed harder by frameworks like Laravel. * This kind of collaboration is a constant uphill battle: highly technical, intense work requiring focus, time, and persistence across many people, and even when it makes something better for WordPress, it may still take ten years for WordPress to be able to take advantage of them due to the long-tail support for older PHP versions. * There’s an inherent mindset shift between software developers and language developers (examples raised: translations, time/date handling). * There is a reported history of patches stalling upstream. #### Language features, version gating, and polyfills A provocation was shared for this discussion: Could WordPress start gating features by PHP version aka “if you want feature X, you must run PHP X”? . Generally, WordPress uses polyfills to fill gaps, and there was discussion of collaborating with PHP on early polyfills: * When PHP 7 features were polyfilled early in a dedicated file, WordPress could implement features on top of that API faster. * It was discussed that polyfilling new functionality could disincentivize people to update their PHP versions. It was discussed that this argument may not hold: that instead of doing what it claims, it only causes breakage for sites with older PHP veresions and the incentivization loop is broken. * The absence of polyfills led to the creation of multiple incorrect implementations in Core. Having polyfils would be a way of giving proper tools to prevent ad-hoc, insecure, and incomplete implementations in WordPress. * WordPress requires only a small number of PHP extensions (currently just json and mysql). Per the data from sites phoning home, PCRE is present on 100% of WordPress sites and could be made required. + The required/suggested page is out of date in a few ways and needs updating. #### Incentives for hosts to update Attendees who work at or with hosts shared what would motivate PHP upgrades: * Higher asset utilization. “Run 40% more websites on the same RAM,” with fewer people needed to monitor server security. * Security and performance generally, framed as “save by updating.” * Data from Automattic’s servers could show noticeable differences between PHP versions. There used to be PHP benchmarking across versions; WordPress.com is already on PHP 8.4. * New PHP features might enable new technologies, such as AI-focused capabilities. * MySQL has the same dynamic: new capabilities (vector search, for example) are being built while WordPress still supports very old versions. #### Plugin developers A release email could be sent to plugin developers when their plugins aren’t compatible with a PHP version. #### Opportunities for overlap with PHP Core * Performance. There are Core PHP devs that have done substantial performance work in the text processing and other low-level functions space, and the last few PHP releases have all included heavy optimizations. WordPress sees benefits in the HTML API but can’t take full advantage the way it could if that work were upstreamed. * Upstreaming spec-compliant web standards into PHP: HTML parsing, URL parsing, HTTP header parsing, Query arg parsing, MIME content-type inference. This is an area WordPress could help improve or sponsor work on, which would benefit WordPress and PHP at large. * WASM (see above). * Pushing hosts to update PHP (see above). * Do more to report back to the PHP internals and RFCs what our measured impacts are for different changes. Potential namespace resolution changes in PHP came up as an example as that would have real world impact on Gutenberg and new AI work (ex: the PHP AI Client). #### Staffing around PHP compatibility Staffing currently feels solid. Some history and risks: * There were rough patches, notably the PHP 8.0 update; 8.x releases have been more inclined to introduce breaking changes than past versions. * The bigger struggle is getting non-Core people (especially plugin developers) to be proactive about PHP compatibility. * WordPress makes local environments available to run tests against new PHP versions as soon as possible, and the “beta” support label for new PHP versions was dropped. * PHP 9 might be a bigger issue. If a major syntax change in PHP 9 makes it impossible to ship a WordPress release supporting both PHP 7.4 and 9, mitigations discussed: asking PHP to produce nightly builds (playground lets you run WordPress on upcoming PHP versions), running WordPress Docker images against PHP nightlies, and taking unit tests out of the Docker container for more flexibility. #### Potential follow-ups * Have a more intentional conversation with the PHP community about WASM. * Pull WordPress version stats to check whether old-WP-version distribution has changed. * Explore benchmarking data to give hosts a compelling upgrade story and to do an upgrade push. * Explore upstreaming HTML API work into PHP/find ways to sponsor PHP core development on behalf of WordPress. * Explore compatibility emails to plugin developers. * Follow the PHP\_CodeSniffer release that adds missing sniffs, and the namespace resolution discussion., WordCamp US 2026: PHP conversation, Make WordPress Core, 01m1n5w2gpztvww00aae4m73sg.