From the schedule session:
From time to time, it’s necessary to delay adoption of newer versions of our underlying technology, either because our software isn’t yet fully compatible or we otherwise cannot recommend the use of the new technology. This is an appropriate measure to take when we are thinking through the promises we make to our users, but what should be the acceptance criteria for reconsidering a delay?
Facilitator: Marius L. J. (@clorith)
Notetaker: Weston Ruter (@westonruter)
Raw Notes:
- We’re using node 16 instead of node 18
- Ramifications are different for PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. vs JS version bumps. Dependency chain for JS is way more difficult, such as updating ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/..
- We should separate discussion when between foundational tech when there is dependencies
- PHP version is out of our control so it is a harder conversation.
- We can control updates to jQuery, React, and aspects of our build tool stack.
- We have a React abstraction layer, so we have more flexibility to upgrade.
- If we bump the minimum version of PHP, we can actually control the version. But we don’t want that control because we want wider reach.
- We can’t force a PHP version, without requiring user action.
- CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. recently changed the minimum PHP version to 7.0, and there was a lot of discussion about whether to go directly to 7.4. There are some criteria already for PHP upgrades, a threshold for upgrading. PHP 7 is already end of life, and PHP 8.0 is end of life. We need to keep moving with PHP. How do we keep from breaking user sites?
- We want WordPress to be used by people, but we want users to be running the best PHP.
- We’re also out of control of browser versions, but this is less of an issue lately. But there will eventually be another browser needing such support.
- Are we trying to maximize compatibility or push development forward? False dichotomy.
- There are multiple forces at play. If we continue to support old versions of PHP, the less we can effectively test on those versions and that tools are nonexistent. Users are worse off by not pushing PHP forward.
- Two extremes: we support all PHP versions or we only support bleeding edge. Where do we sit in that range? We have to educate users to push them forward.
- Back-compat was a great strategy for adoption, but WP is behind the curve in most respects. Now that we are the dominant platform, we have the responsibility to set a good example. We need to not only not break websites for responsible users, but we shouldn’t be striving to not break sites that are already broken. We should re-think whether we are doing anyone a favor if we keep 15-year old updates alive at this point.
- We have to accept that we’re going to make choices that will alienate some users. But WordPress is decisions not options. There is an acceptable user loss rate. We are more willing to accept developer pain and compat breakage than we are to break users’ experiences. Cost of losing developers is less than losing losers.
- WordPress at its base is opinionated. Laravel is a framework and can drop support for anything but the latest PHP user. This is not an option for WordPress, which is run by users not developers, for the most part.
- What is the criteria for reconsidering upgrade?
- Two factors:
- Security implications: You don’t want to encourage people to run on insecure PHP. Could be a pressing issue to force the upgrade.
- Expected cost if you don’t do it: If you wait for a longer time, it will accumulate technical debt. The cost grows exponentially. If you get so late to the party, users could abandon WP altogether because it’s easier to go with another platform. Important to keep incrementally bumping PHP and node consistently so that sites don’t fall behind.
- Counterpoint: More frequent updates are less expensive.
- This would be a best case scenario. The larger the batch change is, the bigger the risk.
- Enterprise sites often don’t upgrade WordPress for a year.
- Doing a forced update is a risk for users. It’s a tradeoff.
- Why have we delayed version updates? Updates to PHP or node may be too frequent to be practical for WordPress to keep up on. We don’t update npm packages to the latest with each release. It’s pretty risky when PHP is 8 years out of date, but it’s not risky when a simple npm package is a couple weeks stale.
- For node, if you skip updates for a package, and your code all depends on out of date packages, it’s way more difficult to update in batch than it is to update on a regular basis. There is a frequency where every day is too costly. It’s important to review changes, but you don’t want to wait too long. Important to get the right batch frequency.
- PHP has a very large attack surface. Same for React and jQuery. An npm package in build tools has a very small attack surface. In an ideal world, everything would be up to date all the time, but the reality is it won’t happen. The reality is that all software has vulnerabilities.
- Updates can also introduce vulnerabilities.
- If you have multiple projects and you keep them all up to date, then at least you have the same attack surface. If they aren’t all consistent, then you have to worry about patching differing versions.
- Adding more dependencies makes things worse. WordPress PHP dependencies have been tightly coupled. But this is not the case for JS packages. Any JS package is a potential attack surface, with implications for security and performance.
- If we don’t stay up to date, we miss out on features and functionality that we need (e.g. collaborative editing)
- Updating React from 16 to 18, we’re pretty aggressive. We didn’t even use the compatibility shim. Are we really being blocked on developing new features with PHP?
- Is the 5% threshold a problem? The issue is PHP is moving too fast. There will be a time that our tooling won’t work anymore across the range. PHP 9 will be really hard to keep compatibility. If WordPress can’t be run on the most recent version of PHP, is it seen as a viable project anymore?
- PHP is 70% of websites, and WordPress is 40% of websites. Is PHP a viable project if WordPress can’t run on it? We should question decisions that PHP makes. WordPress Foundation petitioned for PHP 7.4 security to be maintained, but it was not successful. PHP core developers don’t seem to care about WordPress.
- Upstream projects that WordPress uses have some responsibility. We care about the users. And we are increasingly causing developers pain. Would WordPress ever fork PHP? It has to be a conversation. React maintaining back-compat is a similar situation.
- PHP will become irrelevant if it abandons the ecosystem. Laravel is successful and PHP is mainly concerned about it being supported.
- We have to build on top of our dependencies, and it is a big problem when we don’t have a good relationship with our dependencies.
- When a new PHP version comes out, should we prompt users to upgrade?
- If we let the gap of versions keep growing, it will eventually be insurmountable. We need to look at the cadence/velocity and make sure we are aligned. We need to match the velocity somehow.
- With every PHP version that is left in the dust by PHP, there are many servers that still run them.
- There are actually quite a few servers have latest WP and latest PHP.
- If we make enterprise sites impossible to upgrade WordPress on PHP, they just won’t upgrade.
- Carrot and stick: performance and security.
- If the WordPress project will make it clear what the cadence is, the hosting providers can make a plan for how to upgrade PHP on a regular schedule.
- The WordPress project doesn’t do well to communicate future expectations. Businesses of any size plan out their budgets. Clearer expectations well in advance will be much more effective. We need to move away from the 5% trigger to something that is deterministic in time. We should set the expectation, and if the threshold is still too high, we can still consider.
- For PHP 5.6, there were a couple hosts primarily responsible.
- For some hosts, there’s no business reason to go back and force PHP upgrades. Hosts see things as still working, and upgrades can break things.
- If there is a rhythm and cadence to upgrade process, then this would be an expectation in the WordPress space.
- Since automatic updates have been enabled, it’s way easier to upgrade PHP because the latest versions of WP are compatible.
- If we can get to a point where anything prior to auto-updates is no longer considered
- Users will care more about the latest and greatest WordPress. They won’t see PHP updates, but they will see WP updates.
- The PHP update nags in dashboard and Site Health have been held back because of 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 for PHP 8, but now that the beta label has been removed we can prompt to upgrade.
- What is the user benefit to upgrade PHP? This should be made clear in the update nags. If the next version of WP won’t be compatible with the current version of PHP, users will get pushed to upgrade.
- Maximum version compatibility of PHP is also a problem. WordPress is not fully compatible with PHP 8.2. Sites often have to downgrade to 8.1.
- Hosts are able to customize the update nags. Users don’t care, however. They expect hosts to handle it.
- Key points
- Nice if core made a call on a version gap for underlying technology we rely on
- Communicating fixed upgrade timeline for when we will be upgrading (7.0 upgrade came out of nowhere) so hosts can be ready
- Criteria for when to delay: if the upgrade doesn’t provide any kind of benefit, be it security or functionality, then it’s easier for developers to take that paint. We need more clarity on how much pain we are willing to accept.
- WordPress project can create marketing buzz to say that users have to update PHP version to get the cool new features
- WordPress could possibly limit only features to work on latest PHP versions.
- If we really want to get users to update, we need more than big scary language. Users will look at these things.
- Site Editor could have been gated behind PHP version
- 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 is a carrot to get users to upgrade PHP. Plugins are the conditional features. Plugins do move the market here.
- It has to be a visible feature to get the user to update.
- Why not go all the way to have newer versions of WordPress require new PHP versions, as opposed to gating specific versions. Otherwise we have more branches to maintain. But some features could be gated behind new PHP versions.