At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US 2026, a group of contributors gathered for an informal conversation about the relationship between the WordPress project and the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher language and community. The discussion was held under the Chatham House Rule, so notes below are not attributed to individual participants.

Attendees: @jorbin @johnbillion @obenland @griffbrad @joemcgill @dmsnell @jason_the_adams @desrosj @mdawaffe @4thhubbard @westonruter @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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. 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 sniffssniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. for. This would help extenders come up to standard quickly.
• Code is landing in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ that isn’t compatible with PHP 7.4. Differences between the automated tooling for Gutenberg versus CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.

PHP version adoption

PHP 7.4 is still running on roughly 18% of websites (stats). 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_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 jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. and mysqlMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com). 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.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ is already on PHP 8.4.
• New PHP features might enable new technologies, such as AI-focused capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)..
• 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 HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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, URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org parsing, HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. 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 “betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” 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.

Props to @dmsnell and @zieladam for reviewing these notes.

#php, #php-compatibility, #summary, #wcus