Title of Session: PHP version support
Facilitator: @mikeschroder
Notetaker 1: @flixos90
Notetaker 2: @courane01
From the session schedule:
Currently, WordPress does not officially fully support PHP 8.0+. This discussion will focus on how WordPress can support and align with modern PHP versions, and how to drop support for PHP versions that are end-of-life (“EoL”). There is urgency to this as PHP 8.0 will be EoL in November, and PHP 7.4 reached EoL last November.
Raw Notes
- Several hosting providers expressing support for running automated tests for PHP version support across hosting providers
- Is WordPress 6.3 fully supporting PHP 8? – Basically yes (PHP 8.0 and 8.1 compatible with known exceptions, Trac tickets available for all exceptions) https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/
- PHP 8 “beta” tag was removed after WP 6.3 release https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/
- Encourage/support plugins supporting it
- Attention was raised for Juliette’s published post asking for support on WPCS which is critical to facilitate PHP version support in the future https://make.wordpress.org/core/2023/08/21/wordpresscs-3-0-0-is-now-available/
- Hosting team’s PHP test runner project (running core unit tests on several hosts) has issues with PHP 8 – who can help fix/maintain this project? https://make.wordpress.org/hosting/test-results/
- PHP 5.6 support being dropped in WP 6.3 hopefully encourages hosting providers to jump up to supporting more recent PHP versions including 8+
- PHP version usage of WP sites
- Big push on GoDaddy to get sites on PHP 8+, vast majority of migrations (>70%) has gone smoothly (~18% marked as “high risk” updates)
- Bluehost checking factors like closing body tags, document size changing etc.
- Is there room to open-source tooling for checking that PHP update was successful or is causing errors on the site?
- While there’s a desire in collaborating on tools across hosting providers, historically differences between platforms has hindered that → knowledge sharing rather than actual tooling
- Users don’t care what version of PHP they are on, managed hosts manage that for them
- Can we use WP-CLI for supporting updates? Useful by hosts
- Min/max for PHP for the plugins/themes
- Max version hasn’t been needed before
- List of deprecations that would cause PHP incompatibility, run a scanner.
- Max version puts the work on plugin/theme maintainers, and less useful.
- Implement automated scanner in plugin and theme directories to detect PHP version issues → responsibility of meta team
- Paid plugins have another issue: many sites no longer have active licenses and therefore don’t receive the updates that would add PHP 8+ support
- WP plugin repository is not able to force-update premium plugins, particularly if they use the new upgrade URI header introduced a while ago (which bypasses wp.org completely)
- Steps to encourage plugin support
- email plugin authors prompting to update, but anticipate plugins to end
- display info on plugin page
- integrate into Plugin API, health check could warn them
- Security plugins could tackle Tide scores and compatibility – WP Scan mentioned as a possible option
- Resources:
- For the bulk of sites, ensuring PHP support of ~50 most popular plugins will be enough, then the long tail of 100s or 1000s of plugins only applies to a relatively smaller amount
- What educational resources can LearnWP create to help educate on what/why/how to update? https://github.com/WordPress/Learn/issues/new?assignees=&labels=Awaiting+Triage%2C+Needs+Subject+Matter+Expert&projects=&template=topic-idea.md&title=Topic+Idea%3A+TOPIC+TITLE
- How to start contributing to PHP areas
- Speed at which we drop older versions of PHP – can we correlate versions of WP with PHP?
- Who can update the PHP? Often hosts deploy it
- Current 5% rule is based on overall WP sites’ PHP version usage, could we make it based on only recent WP version sites’ PHP version usage? – That would not make a notable difference, there is not a real correlation between using old WP versions and PHP versions, which makes sense since the hosting provider controls PHP support regardless of WP. wp.org internally has that data available, and it’s only ~0.1% different from overall PHP version usage.
- Extender ecosystem is waiting on Core
- Bottleneck of keeping up
- How can we keep support financially or with labor long-term maintenance of the WPCS / PHP compatibility tooling?
- Long-term additional contributors would be great, but short-term the barrier of entry to this work is so high that support of the existing contributors is essential
- Generally, the WP project is focused on getting more contributors, but sometimes there may be more value in identifying and funding already experienced contributors, or attract specific contributors with specific expertise needed
- mentorship for PHP niche areas, separated out from the rest of Core new contributor table
- Conclusion
- Find funding for contributors and tooling, also mentoring
- repo plugins to WP users
- Hosting companies working together to find common versions encounter errors