Manzoor Wani 6:04 pm on September 9, 2026
Tags: , , node-js, npm   

Updating WordPress to use Node.js 24 and npm 11

As of September 8th, the versions of Node.js and npm required for WordPress development are now 24.x (minimum 24.18.0) and 11.x (minimum 11.16.0).

This applies to trunk in both repositories, the wp/7.1 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". in gutenberg, and the 7.1 branch in wordpress-develop. Older branches remain unchanged (requiring >=20.10.0 and >=10.2.3 of Node.js and npm, respectively). See “What’s next” below for details on the long-term plan.

Required action by contributors

Here is a list of steps that you may need to take to continue contributing to WordPress:

  1. Update your local environment to a version of Node.js >=24.18.0.
    • With nvm, run nvm install && nvm use inside your wordpress-develop or gutenberg checkout to pick up the version from .nvmrc, then reinstall dependencies with npm ci.
    • Similar commands exist if you use fnm (Fast Node Manager): fnm install && fnm use.
  2. If you have an open pull request, merge or rebase the latest trunk into it. 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/, the required CI checks now run on Node.js 24, so PRs based on an older trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. will not contain the required checks until updated merging will be blocked by the repository’s configured rulesets.

The .nvmrc files temporarily pin 24.18 (major.minor) to make it easier for contributors to have the required version when they use nvm use. It will be relaxed to the major version later, per the upgrade handbook page.

Timing Node.js Upgrades

While running the most recent version of any software is highly desirable, sometimes it’s perfectly fine to remain on a stable, supported version. While 20.x has not been Active LTS since October 2024, it has remained a Maintenance LTS release until reaching end-of-life in April 2026. As a result, packages and ecosystems have begun to drop support (GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ announced the removal of 20.x from Actions runner images), and a growing queue of tooling and security work has combined to make running more modern versions a necessity.

What this unblocks

Over the past year, PR-72973 accumulated a long list of work blocked on these versions. Highlights:

  1. Isolated dependencies (PR-76195): switching Gutenberg to npm’s linked install-strategy so packages can only import what they declare. This closes a six-year class of “works in the monorepo, breaks for consumers” bugs in the published @wordpress/* packages. The implementation (PR-75814) has been ready since February and kept rebased against trunk the whole time. That continuous testing surfaced bugs in npm’s isolated mode and led to three major features contributed upstream to npm 12, so the tooling is ready the moment we flip the switch.
  2. OIDC trusted publishing (PR-77227): publishing the @wordpress/* packages from CI without a long-lived npm token, eliminating a whole categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of supply-chain risk. Requires npm 11.5.1+.
  3. Supply-chain hardening for every contributor: the minimumReleaseAge protection already configured in Gutenberg only takes effect on npm 11, so it now applies to every local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer., not just CI.
  4. TypeScript without a build step: Node.js 24 runs TypeScript natively via type stripping. With the coding guidelines recommending TypeScript for new code, scripts and tools can be written in TS and executed directly.
  5. Queued dependency updates that require Node.js 22+: Lerna 10, Lighthouse 13, webpack-dev-server 6, markdownlint-cli, and others.
  6. Platform improvements: full ES module/CommonJS interop, and native glob, fetch, and crypto APIs that let us drop packages like rimraf, fast-glob, uuid, and node-fetch, shrinking the dependency tree that supply-chain attacks target.
  7. npm 12 locally: npm 12’s Node.js requirement (^22.22.2 || ^24.15.0 || >=26.0.0) is now satisfied, so contributors can adopt its install-time security improvements today.

What’s next?

This is just the first step in this plan to upgrade the WordPress codebase to use the latest versions of Node.js. Here is an outline of the tasks that are targeted next.

Upgrading to Node.js 26.x

When choosing which version to target, the guidance is to only choose versions with Active LTS status (currently 24.x). 26.x will be given this status later this year, in October. The goal is to ride the momentum from this change and upgrade to 26.x at that time.

The relevant workflows in both repositories will be updated to run the relevant tests against Node.js 26 to get a head start on this effort.

What does this mean for older branches?

In general, the goal is for the underlying tools to be as consistent as possible across all versions of WordPress that are eligible to receive security patches. This includes the versions of Node.js and npm whenever possible, provided upgrading does not result in changes to the user-facing software.

Contributors have begun exploring the feasibility of updating Node.js to 24.x in the 6.4-7.0 branches of WordPress (and wp/X.Y branches in gutenberg), all of which currently use 20.x. The hope is that all of these branches can also be updated to 26.x in October along with trunk. 

The 6.3-4.7 branches will remain on Node.js 14.x and there are currently no plans to upgrade them.

Increase the minimum required version of npm

As detailed above, the jump to 11.16.0 unlocks several security features. Security-focused work has continued into npm 12.x with install-time improvements.

The Node.js team recently announced that npm 12 will not be bundled with Node.js 26. Historically, the minimum version of npm required to contribute to WordPress has been set to the version bundled with the respective Node.js version. This avoids making the requirement more complicated than it needs to be, and contributors are always free to run any version that satisfies the minimum.

Because these security features are significant, the goal is to raise the minimum required version of npm to 12.x to ensure that everyone contributing to WordPress benefits from these security features.

Because this deviates from the historical practice, it requires some exploration to ensure that the w.org build server and explicit pins in each relevant repository all work as intended. That roadblock is already been cleared in the gutenberg repository when PR-82235 made devEngines.packageManager in package.json the single source of truth for the npm version that CI and the release tooling install. Moving Gutenberg to npm 12 now becomes a one-line change.

Because this upgrade may involve more changes due to enhanced security measures, upgrading this independent of Node.js will likely make this more manageable.

Changes to the Node.js project’s release strategy

Starting with version 27.x, Node.js will move from two major releases per year to one major release per year and the odd/even distinction is eliminated. Future upgrades will be planned around that cadence.

Notes

  1. The update initially landed in the Gutenberg repository through PR-80395 but was reverted due to some unanticipated Actions workflow failures in older numbered branches of wordpress-develop. These were addressed in #66040, and the changes were merged again in gutenberg through PR-82370. In wordpress-develop, the upgrade landed in r63539/#65451.

Preparing for this update took a considerable amount of time and effort. Thank you to everyone involved for helping to make WordPress better and easier to maintain. There are awesome things ahead.

Questions or problems after updating? Comment here or ask in #core-editor.

Props to @aduth, @desrosj, @jsnajdr, @jonsurrell, @mciampini, @tyxla, @mamaduka for driving and reviewing this work, @aduth and @desrosj for reviewing this post, and to the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Systems team for preparing the build servers for the new version of Node.js.

#build-test-tools, #gutenberg, #node-js, #npm

Jb Audras 3:23 pm on September 9, 2026
Tags: , , ,   

Bug Scrub Schedule for WordPress 7.2

It’s time to get WordPress 7.2 ready for release, and help is needed to ensure it’s smooth and bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-free. Whether you’re an experienced contributor or joining in for the first time, everyone is welcome! 🎉

Schedule Overview

Regular bug scrubs are being held twice a week with @audrasjb and @im3dabasia1 leading them. As the release date approaches and activity ramps up, the number of scrubs may be increased. These efforts will help ensure everything is on track for a smooth launch. Participation is welcome at any of these sessions, so feel free to join. Bring questions, ideas, and let’s scrub some bugs together!

Weekly Bug Scrub Schedule 🗓️

Alpha Bug Scrubs

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. Bug Scrubs

Focus: issues reported from the previous beta.

Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). Bug Scrubs

Focus: issues reported from the previous RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..

Where?

All scrubs happen in the #core channel on Make WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. Just hop in at the scheduled time to get started! If you haven’t joined Slack yet, now’s the perfect time.

Want to Lead a Bug Scrub? 

Reach out in Slack, and assistance will be provided to get everything set up. Everyone is welcome—whether you’re a developer, designer, tester, or work on documentation, you can help! Just hop into the #core channel on Slack during any of the scheduled times. No experience? No problem—feel free to ask for help anytime! It’s a great way to contribute, learn new things, and connect with the community.

Check this schedule often, as it will change to reflect the latest information.

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

For your reference, here are some of the recurring sessions:

Have a recurring component scrub or triage session?

PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @audrasjb or @im3dabasia1 on Slack to have it added to this page.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at any time? Yes, you can!

How? Ping @audrasjb or @im3dabasia1 on Slack with the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 7.2-focused? Awesome! It can be added to the schedule here. You’ll get well deserved props in Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub?

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook.

Props @im3dabasia1 for proofreading and review.

#7-2, #bug-scrub, #core

Jeffrey Paul 3:13 pm on September 9, 2026
Tags: ,   

Announcing the WordPress 7.2 Release Squad

This post is announcing the formation of the 7.2 release squad after a call for volunteers.

Exciting News: The WordPress 7.2 Release Squad is assembled!

As with the 6.7, 6.8, 6.9, 7.0, and 7.1 release cycles, WordPress 7.2 will continue the approach of forming a smaller, focused Release Squad. This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams. The goals are to reduce the overhead on the Release Squad while still ensuring each Make Team’s contributions and priorities are represented throughout the cycle, and to reduce overlap between a Make Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. and that team’s Release Squad Leads. Noteworthy Contributors will be captured from Team Reps towards the end of the release cycle.

The number of volunteers far exceeded the available squad roles, so we selected folks whose experience and focus best aligned with the needs of the 7.2 release. If you weren’t selected this time, your contributions are still incredibly valuable, and there are plenty of ways to stay involved throughout the release cycle, including testing, bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, triage, documentation, and more. Every contribution helps move WordPress forward, and we’re grateful for your continued participation.

While the Default Theme (aka Twenty Twenty-Seven) leads are included in the squad above, it’s worth resurfacing the Twenty Twenty-Seven: Team Announcement post from earlier this year. In addition to the design and development leads, the team includes a dedicated lead mentor role (Juanfra Aldasoro) and an intentional focus on creating structured, supported opportunities for new contributors to get involved in the default theme effort.

Big thanks to everyone who volunteered for the release squad, and heartfelt appreciation to everyone helping move WordPress 7.2 forward through testing, triage, documentation, bug scrubs, and more. Your efforts make this release possible, and there’s a lot to be excited about as WordPress 7.2 comes together!

Props to @jorbin for reviewing this post and @jorbin, @desrosj, @annezazu, and @4thhubbard for helping assemble the 7.2 release squad.

#7-2, #planning

Amy Kamala 2:38 am on September 9, 2026
Tags: , , , ,   

Dev Chat Agenda – September 9, 2026

The next WordPress Developers Chat will take place on Wednesday, September 9, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

The various curated agenda sections below refer to additional items. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda or bring them up during the dev chat.

Announcements 📢

7.2

7.1

General

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.

Open floor  🎙️

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.

#7-1, #7-2, #agenda, #core, #dev-chat

Lance Willett 8:53 pm on September 8, 2026
Tags: ,   

Join the PHPUnit test cleanup for 7.2

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. runs about 31,000 PHPUnit tests on every commit. These tests need maintenance just like core code: many leak state into other tests, some assert nothing, and several are coupled to networknetwork (versus site, blog) calls.

A goal for the Build/Test Tools component for the 7.2 release is to reduce build time and load across wordpress-develop and related repos. A healthier test suite will help!

This post is intended to show the pieces any contributor can claim, the same way the JSHint effort did in 2013. Same model is running today for 7.2 in PHPStan (#65817), docblocks (#65860), TypeScript (#65997), and JSDoc (#66033).

We need two kinds of help: 1) fix patches and 2) code reviews.

Why now

  • We can now measure the suite. Pushes to trunk now publish timing metrics to CodeVitals, and we can now flag tests that take too long as candidates to improve (see #65887).
  • Isolation helps find good next fixes. Running the tests in random order exposes tight coupling and shared state. Two batches of fixes are already in from 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 contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/, and 13 more pull requests are open that need your help (see #65893).
  • We are shaping a queue for you to jump right in: pull requests with no reviewer, and umbrella tickets with no owner yet.

How to claim a new piece

  1. Pick an item from the tracks of work below; leave a comment on the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. and here on this post.
  2. Open pull requests and help review and finalize existing PRs.

Please follow the handbook pages on running the suite and writing PHP tests.

Reviewers wanted

Test isolation, #65893. Run the touched directory under two random seeds and once in default order, and confirm the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. restores state in tear_down() or the base testcase rather than special-casing one test. Examples: #13181 adminadmin (and super admin), #13186 comment globals, #13187 user fixtures, #13191 Ajax hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., #13193 rewrite and query, and #13205 themes.

External 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. guard, #63083. #13407 makes a test fail if it reaches the network without being in the external-http group. See the description for a 5-step test plan.

Strict assertions, #64895. #12583, #11707 and #12613. Check each assertSame() against the function’s documented return type.

Class split, #65208. Eighteen pull requests are open; the ticket lists them. Check that the file name matches the class name, that @covers moved with the tests, and that npm run test:php -- tests/phpunit/tests/admin passes.

Here are the tracks of work

First core contribution? Start with #65819, the catch-all for small test fixes. Great spot to jump in.

Continue reading →

#build-test-tools, #phpunit

Aditya Dhade 5:14 pm on September 8, 2026
Tags: , , , ,   

Performance Chat Summary: 8 September 2026

The full chat log is available beginning here on Slack.

WordPress Performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

  • @spacedmonkey shared ongoing work to improve query caches and requested more eyes on the work. The idea came from a chat with @peterwilsoncc on the RTC ticketticket Created for both bug reports and feature development on the bug tracker. #65487, and @spacedmonkey said the idea has legs. PR #12220 has some test coverage, and all other query caches introduced already have test coverage. More tests could always be added, but testing remains tricky because the change does not introduce new functionality. @spacedmonkey requested feedback from @westonruter, @mukesh27, and @adamsilverstein.
  • @westonruter said PR #13084 for elimination of script/style concatenation in favor of prefetch remains at the top of performance radar. No chance to pick up the work again since WCUS, but the PR is believed to be almost ready for merge.
  • @b1ink0 is reviewing and testing the view transition PR #11912. @westonruter responded that should make adminadmin (and super admin) navigation feel much better.

Our next chat will be held on Tuesday, September 22, 2026 at 16:00 UTC in the #core-performance channel in Slack.

#core-performance, #hosting, #performance, #performance-chat, #summary

Benjamin Zekavica 4:44 pm on September 7, 2026
Tags: , ,   

WordPress 7.1 Release Retrospective

A huge congratulations, and a giant thank you to everyone who helped make WordPress 7.1 happen! The release was only made possible by your dedication and hard work. You all are heroes.

Now that the development cycle is over, it’s time for a retro. You’re invited to share your thoughts on the 7.1 cycle, on processes, squad, or anything else about the release cycle. I know you all have a lot to say after that whirlwind, so please do. Feedback loops help uncover what is and is not working so that the release process can be improved. 

Please share your feedback using this form or by dropping a comment below by September 30th. Even contributors who did not contribute directly to the release are welcome.

Someone who was simply watching the release will have thoughts and opinions that vary from someone who was more heavily involved. It’s important for diverse perspectives to be represented in feedback for big picture clarity. So no matter who you are, please speak up.

The survey is not anonymous, but submissions will be anonymized in the follow up summary. Your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is only needed for any additional questions.

The form and comments will be open until September 30, 2026, and a summary of feedback will be published soon after.

Thank you for taking the time to give your valuable feedback, and thank you again for your amazing investments in 7.1 “Mary Lou”. Together, future release cycles will be even better.

Props to @krupajnanda and @annezazu for the pre-publish review.

#7-1, #release, #release-process

Adam Zieliński 9:49 am on September 4, 2026  

Runnable code examples are now live in the Code Reference

WordPress 7.1 shipped the first two runnable code examples in the Code Reference. They are powered by WordPress Playground, and more are coming in 7.2.

On the WP_HTML_Processor::class_list() Code Reference page, select Run button in the code snippet and the code example will run right there, in your browser.

Runnable snippets can be defined in the DocBlock of each method directly in the WordPress codebase. They use a slightly different syntax from the regular code examples:

<?php
/**
 * Generator for a foreach loop to step through each class name for the matched tag.
 *
 * ```php interactive
 * $p = new WP_HTML_Tag_Processor( "<div class='free &lt;egg&gt;\tlang-en'>" );
 * $p->next_tag();
 * foreach ( $p->class_list() as $class_name ) {
 *   echo "{$class_name} ";
 * }
 * // Outputs: "free <egg> lang-en "
 * ```
 */
public function class_list() {}

The part that makes it interactive is the ```php interactive language tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) on the code fence. A handbook page with all the details and instructions for authoring interactive code snippets will be published shortly.

Props to @jonsurrell, @dmsnell, @westonruter.

+make.wordpress.org/docs/

+make.wordpress.org/playground/

Joen Asmussen 7:03 am on September 4, 2026  

Replacing Dashicons in the admin bar and menu

A patch has been in progress since June that replaces Dashicons in the adminadmin (and super admin) bar and the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. with WordPress icons, using the wp_get_icon() function that was introduced in WordPress 7.1. Props to @fushar, @wildworks, and @lucasmdo for moving this forward. Because the change being proposed is very visible, it deserves a wider audience than it has had so far.

Continue reading →
annezazu 7:56 pm on September 3, 2026
Tags: , , ,   

WordCamp US 2026: PHP conversation

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