WordPress 5.9 Release Squad

WordPress 5.9 is full steam ahead towards the December 14, 2021 release date. With the Go/No Go deadline behind us, the necessary roles required for this version’s release squad have become more clear, and the team is starting to take shape.

Below is the list of roles the squad roles for the 5.9 release with confirmed contributors listed. Any role listed with a hand raised emoji (✋) still need contributors and volunteers.

  • Release LeadRelease Lead The community member ultimately responsible for the Release.: @matt
  • Release Coordinators:
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: @chaion07, @audrasjb.
  • Editor Tech: @noisysocks, @mamaduka.
  • Editor Design:
  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech: @hellofromtonya. ✋
  • Theme Leads: @kjellr, @jffng.
  • Technical Writer: @psykro. ✋
  • Documentation Leads: @mkaz, @milana_cap.
  • Marketing & Communications: @chanthaboune. ✋
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Lead:
  • Test Leads: @boniu91, @annezazu.

Some Notes

  • The release squad list on the 5.9 development cycle page has also been updated. As additional contributors are confirmed for the positions needing volunteers, they will only be added to the development cycle page (not accompanied by an additional post here).
  • @noisysocks is coordinating a group of feature-specific contributors, and will be the main information person for all editor related features.
  • All WordPress 5.9 related coordination will happen inside of the #5-9-release-leads 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/. room. This room is a public viewing area for transparency (and knowledge sharing!), but is a workspace for that release squad so please limit posting as much as possible for those not on the release squad.

Props @chanthaboune and @jeffpaul for peer review.

#5-9

DevChat meeting Summary – April 28, 2021

Agenda for the two meetings. Thanks to @peterwilsoncc and @jeffpaul for leading the 05:00 and 20:00 UTC devchats respectively.

Link to 05:00 UTC devchat meeting on the core channel on Slack

Link to 20:00 UTC devchat meeting on the core channel on Slack

Announcements and news

Feedback on posts requested

  • @iandunn needs your input on the topic of assisting 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 developers to avoid specific bugs that result in WordPress end users having a bad experience. He has suggested potential solutions including static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia, and has provided a list of questions to help guide the discussion. Do read it and provide feedback from your perspective.
  • @francina: Would Stats Dashboards Help Your Team? Read this post for more details. Would folks in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. feel that any sorts of stats on a dashboard would support in their work in core?
  • New team CC Search to join WordPress. CC Search, a CC0 (Creative Commons Zero) image search engine, is joining the WordPress project with more than 500 million openly licensed and public domain images discoverable from more than 50 sources, audio and video soon to come. Read this post for more information @chanthaboune: more news and context coming in the next few weeks.
  • Wonderful design reference for those looking for ways to quickly prototype WordPress UIUI User interface in Figma. Read this blog post
  • WP Briefing podcast. @jeffpaul: these are super quick to digest, provide a good on-ramp to what’s latest in WordPress. Check out all the episodes at this link and find links to subscribe in your favorite podcast app.

WordPress 5.8 Release

@francina gave an update – Thanks to everyone who volunteered and right now I can confirm these roles:

Release leadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg (@matt)
Release Coordinators: Jeff Paul (@jeffpaul) and Jonathan Desrosiers (@desrosj)
Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead: Luke Carbis (@lukecarbis)
Core Tech Lead: Helen Hou-Sandí (@helen)
Editor Tech Lead: Riad Benguella (@youknowriad)
Marketing and Communication Lead: Josepha Haden-Chomphosy (@chanthaboune)
Documentation Lead: Milana Cap (@milana_cap)
Support Lead: Mary Job (@mariaojob)
Testing Lead: Piotrek Boniu (@boniu91)

  • @francina: “If I have messaged you and asked to join the release as part of the supporting crew, thanks for being part of the collaborative work that makes WordPress so great. Everyone! Join us in the channel #5-8-release-leads
  • If you have any questions about releases which you are following along, and if you want to ask questions: #core and #core-editor are the right channels
  • 5.8 release team

Full Site Editing (FSE) related items

  • Open call to send in your questions on Full Site Editing (FSE) Round 2 – reminder from @annezazu that you can submit questions, no matter who you are. The call closes 12 May 2021. This is part of the collaboration in #fse-outreach-experiment
  • [More posts on FSE in the posts requesting feedback section above]
  • Marketing has social media text available which can be reused to promote the different FSE calls 
  • @helen making a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. based theme with the full site editor

Component maintainers and committers update

  • @sergey: Work has continued on further fixing some long-standing coding standards issues in core, see ticketticket Created for both bug reports and feature development on the bug tracker. #52627 for more details.Build/Test Tools, Date/Time, I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill., Permalinks: No major news this week.
  • @clorith: Site Health catching up a bit on older and unanswered tickets
  • @audrasjb: Menus, Widgets, Upgrade/Install: nothing new. I scrubbed some tickets in the Menus component but no major news to share.
  • Following on from discussion last week @marybaum nominates @abhanonstopnewsuk as co-maintainer for the Help/ About page component 
  • In the last week, they have been going through the tickets since and will give an update in future devchats.

jQuery

  • @Hareesh: some attention requested on #52163. With this out of the way, we would have less jQuery migrate warnings, and it would be easier to fix any remaining warnings.
  • @clorith: jQuery UI hasn’t been updated yet, we are still waiting on their release, which I believe is scheduled for the end of May/start of June 
  • @davidb: jQuery release is right before 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. 1 then, if the dates hold
  • @clorith: Yeah, which is a bit tighter than I’d like, but it is what it is… we’ll have a look once it’s ready to see what’s going on and what the best approach is. Building from source while they’re still modifying it isn’t really an option in my opinion.

Open Floor

  • @notlaura: feedback requested on ticket #53070. Establish a Core CSSCSS Cascading Style Sheets. deprecation path, and ask if anyone is interested in working on it! This is something we’ve been discussing in #core-css

Community

  • @chanthaboune: As you may be aware, many of our fellow contributors are experiencing disruptions in their lives right now above and beyond the (seemingly) routine disruptions of this pandemic life. From big earthquakes to big spikes in COVID cases to unrest right outside their doors, some of your WordPress pals are hurting more than usual.
  • For my part, I can say take whatever time you need to take care of yourselves. You are important and WordPress is not more important than your health and well-being.
  • For all of us, if you haven’t reached out to your friends to see how they are, please do.

Thanks to @meher and @webcommsat for the devchat notes and @marybaum for her help with them.

#5-8, #dev-chat, #fse, #fse-outreach-experiment, #jquery

A Week in Core – April 26, 2021

Welcome back to a new issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between April 19 and April 26, 2021.

  • 20 commits
  • 27 contributors
  • 38 tickets created
  • 2 tickets reopened
  • 31 tickets closed

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component.

Code changes

Bootstrap/Load

  • Add Function for reliable timing data – #39163
  • Improve get_bookmark() test coverage – #52988
  • Remove Internet Explorer 11 from the browserslist#53077
  • Update the caniuse-lite database – #52624
  • Update several dependencies – #52624
  • Add seeking support to stream test library – #52922, #52826

Coding Standards

  • Remove loose comparison in wp-admin/includes/plugin-install.php#52627
  • Use strict comparison in wp-admin/includes/update-core.php#52627
  • Use strict comparison in wp-admin/includes/class-wp-terms-list-table.php#52627
  • Fix minor, inline spacing issue in wp-admin/setup-config.php#52627

Code Modernization

  • Bring consistency to preparing some fields on Networknetwork (versus site, blog) Settings screen: – #51423

Documentation

  • Add a @since note to wp_mail() about using is_email() for validation – #52628

Editor

  • Shape blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor filters to work better with the 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/ 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#52920
  • Abstract block editor configuration – #52920

External Libraries

  • Update Underscore to version 1.13.1 – #45785
  • Update Moment.js to the latest version – #52853

Plugins

  • When loading a plugin in a “sandbox” on activation, do it once – #31104
  • When loading a plugin in a “sandbox” on activation, do it in a separate function – #31104

Posts, Post Types

  • Pass the post object to the_password_form filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.#29008

Upgrade/Install

  • Prevent possible type errors during installation – #51423

Users

  • Share current user instance across functions – #28020

Props

Thanks to the 27 people who contributed to WordPress Core on Trac last week:

@peterwilsoncc (3), @hellofromTonya (3), @SergeyBiryukov (2), @jrf (2), @hellofromtonya (2), @hareesh-pillai (2), @matt (1), @xknown (1), @youknowriad (1), @nosolosw (1), @jeremyfelt (1), @andraganescu (1), @azaozz (1), @jorbin (1), @silb3r (1), @andy (1), @chaion07 (1), @mensmaximus (1), @DrewAPicture (1), @dd32 (1), @Mike_Cowobo (1), @TimothyBlynJacobs (1), @rmccue (1), @lukecarbis (1), @donmhico (1), @chriscct7 (1), and @shital-patel (1).

Congrats to our 2 new contributors of the week: @silb3r, and @Mike_Cowobo ♥️

Core committers: @sergeybiryukov (7), @peterwilsoncc (4), @desrosj (4), @davidbaumwald (2), @gziolo (2), and @jorbin (1).

#5-8, #week-in-core

WP5.8 Squad Call for Volunteers

Edit: 4/23/2021 @ 19:10 UTC – changed the references to contributors in the last paragraph to 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/ usernames to help to make the connection. – @desrosj

With the schedule finalized and parts of 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/ phase 2 getting ready to merge, it’s time to put together a squad of focus leads for WordPress 5.8.

You can read more about the different roles in the handbook.

Here are the squad roles available:

The roles of release leadRelease Lead The community member ultimately responsible for the Release. and marketing/communications lead will be filled by @matt and @chanthaboune, respectively.

Expectations

Focus leads should be available for at least 5-6 hours a week to perform their tasks, with more time as milestones like Betas, Release Candidates, and General release approach. On the days of those milestones, you might need to dedicate 4-6 hours to WordPress on one day.

There are no limitations to where you come from. We are a global community, open 24/7 so you will schedule scrubs, if needed, according to your availability and potentially find a deputy to cover other timezones.

Because 5.8 is going to be a busy release, the squad won’t have mentorship or ride-along opportunities, like it did in the past, but as Josepha mentioned there is a public channel for the team to coordinate so that others can learn through observation.

This doesn’t mean you need to have all the answers to volunteer. 🙂 There will be a bunch of people available to help and support (the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team representatives, long-time contributors, etc…).

Are you interested?

Please leave your name in the comments with the role you are interested in or reach out to me (@francina), @audrasjb or @chanthaboune if you have any questions before raising your hand.

Thanks!

#5-8, #planning

Proposal: Treat FLoC like a security concern

Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.

TL;DR: FLoC places people in groups based on their browsing habits to target advertising.

Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.

This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.

So What Now?

WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with a few lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses.:

function disable_floc( array $headers ) : array {
	$permissions = [];
	if ( ! empty( $headers['Permissions-Policy'] ) ) {
		// Abort if cohorts has already been added.
		if ( strpos( $headers['Permissions-Policy'], 'interest-cohort' ) !== false ) {
			return $headers;
		}
		$permissions = explode( ',', $headers['Permissions-Policy'] );
	}

	$permissions[] = 'interest-cohort=()';
	$headers['Permissions-Policy'] = implode( ',', $permissions );
	return $headers;
}
add_filter( 'wp_headers', 'disable_floc' );

What About Admins Who Want FLoC?

Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.

Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.

What Do You Mean By “Treat It Like A Security Concern”?

  1. Include 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. the next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., rather than waiting for the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.;
  2. Back-port the patch to previous versions of WordPress.

Why Treat It That Way? Why Not Just Wait For The Next Major Release?

Well, keep your eyes peeled, because there is a ticketticket Created for both bug reports and feature development on the bug tracker. for future releases on its way!

While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.

Request For Comment

Please join the discussion below!

Whether want to show support, disagree vehemently, or just want to make the implementation the best that it can possibly be, please have your voice be heard.

I’m aware that there is a lot of discussion on other platforms, including Twitter on this matter, but we won’t see all of it, so in addition to spreading the conversation there, please comment here too, so that it can be considered when this is discussed at development meetings and when the ticket is created (consensus building first – and that is done here 😉 )

YOU DO NOT HAVE TO BE A DEVELOPER TO PARTICIPATE. There will be a ticket on core.trac.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/ where we will discuss all of the technical stuff. I’m tremendously grateful that there are so many developers, Core, MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and others, around, but blogblog (versus network, site) posts on make.wordpress.org are the places that are accessible to techies and non-techies alike 🙂

Version Control:
1. Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).
2. Code snippet updated based on suggestions below. Thank you to Tom for the snippet and to everyone who suggested conditionally appending, rather than replacing.
Added some more info to the Request for Comment.
#core-privacy

Making WordPress Releases Easier

Update: Let’s move forward with the March release, a July release (to give folks time to adjust their company plans), and a final release in December. I will create a plan to help us lessen the burden of releases, and in December I will see what we’ve accomplished and get some 2022/23 target release months published.

The past few weeks have been very busy in terms of WordPress’ release cadence. There has been the WP 5.6.1 release, WP 5.7 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. 1, and discussions to start organizing the next major and minor releases are already underway. The roadmap for the year promised four major releases, as well as any follow-up minor releases, and flags have been raised about how we can accomplish that.

tl;dr I’ve been exploring the problem of making the release process easier with WordPress contributors for 3+ years; high level notes are shared below. From my research, the work to automate what we can (and potentially get the project ready for more releases per year) would take 3-4 dedicated developers who are proficient in our backend tools/infrastructure, at least a project manager, 1-2 internal communications people, and probably a year or more of work (if we had all the resources, and they were working at full capacity). This means that 4 major releases is not a viable plan in 2021.

What are the challenges?

  • Balancing developer needs with user needs. A rapid release cycle (CI/CD) definitely appeals to some developers. In my observation, our users see no difference between our nuanced guidelines around minors vs majors, and currently experience each type of release (~9ish on average) as “yet another thing I have to update.”
  • Balancing the OSS philosophy of releasing early and often with the reality that we ship a CMS to ~39% of the web. In my observation, our commitment to backward compatibility and relative consistency is key to our users’ continued use of WordPress, and makes “ship, then iterate” more challenging.
  • WordPress takes a responsive approach to open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. product and project management, despite our scale. Contributors expect WordPress maintainers to seek out and respond to feedback on both product and process, which is time-consuming.
  • Related, every release team — major or minor — makes hard calls and unpopular decisions. This results in fatigue and increased risk of burnout in contributor roles that have a limited pool of trained and experienced candidates. The more releases, the more fatigue and burnout risk we run.
  • Currently, only a small number of active contributors can do the administrative work required during a release, and they split that responsibility across releases for the year. The onboarding process for contributors with that skill set is lengthy, and the main mechanism we use to recruit and start training them (our in-person events) is not available.
  • Automating the basic tasks involved in a major or minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. requires time from skilled developers as well as product ownership and project management. In my observation, we do not have people with those skills and extra time available to help here, given our ongoing need for increased project coordination.

What changes are needed?

  • Better testing: That would include automated testing, security testing, smoke testing, E2E tests, beta testing, etc.
  • Seasoned CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers: Many more of them, and also more of their time focused on Core.
  • Better handoff in design/dev iterations: The WordPress project has more developer contributors than design contributors, and few people who have the time, experience, and skill required to coordinate the work at scale.
  • Shifts in our collective philosophies: A shift to a culture of review, to an ideology of continuous development (as it relates to CMSs and software that is open to a vast networknetwork (versus site, blog) of extenders), and finally a shift in the nuanced application of OSS methodologies (aimless contributions vs agenda-free contributions, non-reciprocal vs no value, coordination vs dictation, etc).

What could we change right now?

  • Mentorship: The mentorship programs that are in place across teams in the project, could stand a fresh eye to account for active and passive learning that happens during in-person events. If we gave it a little more definition, and some better tools, then we could potentially remove that barrier to entry for all future contributors.
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.: There was a call for this at the end of 2018, and it suffered from a bit of a false start. Triage is not only a key part of maintaining WordPress, it’s also the common denominator in the paths of success for many of the long-term contributors I’ve spoken to.
  • Feature Proposals: The feature proposal process was suspended during the first phase of 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/, but I think it’s time to revive it. The benefits of this process are that discussions can happen on the Make network, which opens up feedback to a broader audience, so that when a proposal gets to any final decision makers, the questions have all been answered (or at least asked).
  • Product/Project Processes: This is hard in open source. We know that trying to design by committee is prone to failure, but making that work have a clear owner feels like we’re walling off the future of the project. I have no solutions, but I will start a few conversations in the near future so we can collectively come to a potential way forward.

Time for your feedback!

I believe that it is essential to reduce the effort required to have a successful WordPress release, but that we should start with some planning. I’d like to hear from folks in the comments if you’re interested and available to lead efforts around any of the things listed above, or if you have anything that needs clarification in what I shared!

Proposal: Dropping support for old PHP versions via a fixed schedule

While most people here will probably mostly know me as a (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, 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 and theme builders, the web agencies and the users who often run their business via their WordPress website.

In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.

A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.

With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.

Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.

Chicken vs egg

The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.

Current situation: Classic Chicken vs Egg


WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.

This is circular logic, which as most developers know, never ends well as you end up in an infinite 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. where, in the end, neither moves forward.

So who are these users who don’t upgrade ?

Well, while we can’t know for sure, if we look at the figures, we can see some patterns:

Pie chart with the statistics for which version of WordPress is used by which percentage of users.
In the chart it is highlighted that there are 3.7% of users still on WP 5.1 (PHP stragglers), a whopping 10.6%on WP 4.9 (Gutenberg dislikers) and a similar percentage of users on WP versions older than WP 4.9, a  lot of which may be zombie-sites.

Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.

So let’s look at some likely personas for users who don’t upgrade:

Image showing four persona's:
1. The zombie thinking "Huh, what notice ? what website ?"
2. The overwhelmed person thinking "Admin notices are so noisy, I just ignore them all".
3. The laid-back person thinking "No rush, I'll do it later (when it's needed)".
4. The business person thinking "We'll take the costs last minute and not a minute before".

We have the “zombie” persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without adminadmin (and super admin) involvement, or spam sites etc.

We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.

Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.

And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.

As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out.
For those users, I like to use the car analogy:

A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.

Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).

Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hackedhacked /can’t upgrade anymore). If was your responsibility as a user to act on them after all.

But Juliette, get to the point: how do you think we can get out of this situation ?

Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.

A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.

These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.

The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.

So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.

That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.

Timeline from December 2016 to December 2024 showing the WordPress version released that December and the minimum supported PHP version as of that WordPress version.
WordPress 5.6 in December 2020 would get a minimum of PHP 7.1.
WordPress 5.9 in December 2021 would get a minimum of PHP 7.2, etc
Below the timeline it shows for each PHP version when it was released and until when it will be supported by WordPress.

Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.

For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.

But all those users on old WordPress versions…

Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. security fixes for WordPress versions up to four years back.

Timeline from December 2016 to December 2024 showing that during the lifetime of the upcoming WordPress 5.6 release, the 5.6 release would get active support, but that WordPress 4.7 (released December 2016) up to WordPress 5.5 (released this month) would get security releases (if needed).

What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.

Slide: Example: user on PHP 7.4
* WordPress will offer 5 years of support for the PHP version.
* WordPress will offer 4 more years of security updates for WP versions before the version bump dropping PHP 7.4.
* In total this adds up to 9 years of support.

And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.

Now how does that sound ? Is that a liberal enough policy ?

Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.

But what about the users currently on old WordPress versions ?

To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.

Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.

Slide showing an "Urgency nudges" proposal:
* For websites running on a PHP versions no longer actively supported, an admin notice will be shown.
* As of six months before the planned drop of a PHP version, the admin notice on those sites would change colour to draw more attention to it.
* After the PHP version drop, the proposal is to show a big pop-up on admin login for the first and second year after. The notice is dismissable but will come back once a month.
* For the third and fourth year after support for the PHP version has been dropped, this pop-up will show every time an admin logs into the website.

So… what do you think ? I eagerly await the reactions of you all!

Props to @sergeybiryukov, @joostdevalk and @matt for looking this article over before publication.

#core, #core-php, #php, #request-for-comment