Merge Proposal: Rollback Auto-Update

Background

The biggest risk for a site owner when updating plugins is encountering a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher fatal error that crashes their website. While CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. updates are protected by automatic rollbacks since WordPress 3.7 (#22704), no such protection for plugins was added. Although fatal error protection and recovery mode were added in WordPress 5.2, it requires manual intervention from an administrator, and ideally WordPress should be able to recover on its own in a similar way that Core does. The Upgrade/Install team began exploring rollbacks for 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 updates.

Rollbacks for plugin updates comprises three features:

  1. move_dir() – Introduced in WordPress 6.2 (#57375)
  2. Rollback for plugin/theme update failures when updating manually – Introduced in WordPress 6.3 (#51857)
  3. Rollback for plugin auto-updates when failures are encountered – Covered by this proposal (#58281)

Some background references

Overview

When active plugins are updated, they are briefly deactivated before the new version is installed and reactivated immediately after. Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD).

To further protect websites and increase confidence in automatic plugin updates within WordPress, the Rollback Auto-Update feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. aims to detect PHP fatal errors during automatic plugin updates, and subsequently rolls back to the previously installed version.

This proposal is to merge the changes required to also perform rollbacks when fatal errors occur during attempted plugin auto-updates by default.

Implementation

Rollback Auto-Update performs a loopback request to the homepage to check for PHP fatal errors, using an approach similar to the Plugin or Theme File Editors. If a PHP fatal error is encountered, an error handler logs the specific message and the previously installed version of the plugin is restored. When a plugin rollback occurs, a notification will be sent to the site’s administration email (stored in the admin_email option) notifying them of the failed update and rollback.

The current implementation attempts to detect a PHP fatal error during an automatic update by using a loopback request to the homepage. If the loopback returns an error, a PHP fatal error in the active plugin is assumed and the update will be reverted for safety.

After the problematic plugin is rolled back, the auto-updating process will continue for any other core, plugin, or theme updates that were in queue. When the next check for auto-updates occurs, WordPress will attempt to update the same plugin again.

Previously, maintenance mode was only enabled during installation of an update. However, testing established that disabling maintenance mode during the rest of the process means that active visits to the site can trigger errors. This can have side effects, such as deactivating plugins, etc. Rollback Auto-Update enables maintenance mode for the duration of all automatic updates. While maintenance mode is enabled for longer, this is relative to the number of updates being performed at that given time – usually a very low number – and helps improve stability of automatic updates.

At the time of publishing, this code is being tested on 6,000+ sites running the Rollback Update Failure feature plugin, which has contained the related code since v7.0.0 was released on 10/12/2023.

For easier testing of the feature within wordpress-develop, a merge PR (Core-5287) has been created.

Due to limitations in the ability to modify wp_is_maintenance_mode() in the feature plugin, the PR is slightly different. The feature plugin is available for historical reference. All pre-merge testing should be done using the PR. Some contributors have also been running the PR on sites for a few months.

Example of email text sent to site’s administration email.

Howdy! Plugins failed to update on your site at https://test.xxxxx.net.

Please check your site now. It’s possible that everything is working. If there are updates available, you should update.

The following plugins failed to update. If there was a fatal error in the update, the previously installed version has been restored.

  • This Plugin Should Not Be Used (from version 0.1 to 0.2) : https://wordpress.org/plugins/this-plugin-should-not-be-used/

To manage plugins on your site, visit the Plugins page: https://test.xxxxx.net/wp-admin/plugins.php

If you experience any issues or need support, the volunteers in 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/ support forums may be able to help.
https://wordpress.org/support/forums/

The WordPress Team

Testing

There are no known issues directly related to Rollback Auto-Update that don’t currently exist in Core.

I (@afragen) have been testing using the test plugin. The plugin is on a test site, active, and set to auto-update. I have been running like this since the beginning of the year using the PR and on other sites for several years using the feature plugin.

  1. Install the PR into WP 6.5.x or 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..
  2. Install version 0.1 of the test plugin.
  3. Activate the test plugin and enable auto-updates.

The WordPress.org update 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. will serve the version 0.2 version of the plugin, which will cause a PHP fatal error. To confirm a rollback is successful, data is written to the error.log at every point in the auto-update process, creating an audit trail the user can use to discern the flow and results of rolling back an auto-update. This logging is only intended for testing purposes.

FAQ

Stay up to date with development on the PR. Please comment on the GitHub PR if any problems are discovered. 

  • What happens if loopback requests aren’t working?
    • As demonstrated by the Site Health message for loopback requests that aren’t working: “Loopback requests are used to run scheduled events, and are also used by the built-in editors for themes and plugins to verify code stability.” 
    • Auto-updates shouldn’t run if loopback requests aren’t working. If a loopback request fails due to an 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. error, Rollback Auto-Update will consider it as a PHP fatal error detected, and revert any plugin updates.

As a project, it’s important to continuously evaluate ways to make site management easier for the large majority of users and site owners. Providing safer plugin auto-updates is just one way for WordPress itself to handle problems that may require technical expertise seamlessly for end users.

All feedback will be collected and addressed over the next 2-3 weeks, with the goal of committing to trunk after all feedback is addressed to ensure that the feature gets plenty of testing through the nightly builds early in the WordPress 6.6 release cycle.

Props: @costdev and @desrosj for review and editing.

#6-6, #feature-projects, #feature-autoupdates, #merge-proposals, #rollback

Summary, Dev Chat, April 17, 2024

Start of the meeting in 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/., facilitated by @joemcgill.

Announcements

The WordPress 6.5 retrospective post has been published, please fill in the survey if you would like to leave feedback or suggestions for improvements to the release process.

Forthcoming Releases

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.: 6.6

We are currently in the WordPress 6.6 release cycle. The deadline for leaving feedback on this Planning Proposal post has ended, and we expect a release squad to be announced soon. Please leave a comment if you have any updates to share about this.

Next maintenance release: 6.5.3

WordPress 6.5.3 will be the next maintenance release. @jorbin published this post outlining the schedule.

@jorbin shared:

Work on WordPress 6.5.3 is progressing. The target for release is 7 May and there are 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 happening twice a week.

Of the tickets I’ve reviewed so far, https://core.trac.wordpress.org/ticket/60992 feels like the highest priority. It has a 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. on it that could use some extra testing.

For the full schedule of scrubs or if you aren’t a bug gardener and want to suggest a ticketticket Created for both bug reports and feature development on the bug tracker. for the milestone, see
https://make.wordpress.org/core/2024/04/15/wordpress-6-5-3-an-upcoming-maintenance-release/

As with all minor releases, any and all help is appreciated.

Slack reference

@afragen confirmed that the expected behaviour of the patch for #60992 is: The patch for 60992 allows the redirect after the Activate button on 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 card in plugin-install.php. There continues to be no redirect for the Activate button in any modal, ie “More Details” or “View details” modals.

@costdev confirmed that they’re confident we can land the resolution for 6.5.3.

Next 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/ release: 18.2

Gutenberg 18.2 is scheduled for April 24 and will include these issues.

Discussion

There were several proposed discussion topics for today:

  • How can we get PHP8 support completed and out of “compatible with exceptions”: suggested by @jorbin
  • Aligning the coding standards for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Gutenberg so that both can use the same tooling: also suggested by @jorbin
  • Revisit syncing editor packages early and throughout the release cycle: suggested by @jeffpaul

How can we get PHP8 support completed and out of “compatible with exceptions”

On the first topic, @jorbin noted that: PHP8 support feels to me like one of those things that is kind of stagnent and I would love to see some movement towards full and complete support for all PHP8 versions. I wanted to bring it up as a topic to see if others agree or if people think the current core stance is good.

There is not currently an active effort to reach full support for PHP8.

@jeffpaul noted that: PHP Compatibility and WordPress Versions handbook page that shows PHP8 support (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, compatible with exceptions).

@oglekler mentioned that: I am mostly working with 7.4 and from times to times have surprises like this: #46338.

There are 42.5% of WordPress sites using PHP8+ according to https://wordpress.org/about/stats/.

@ironprogrammer mentioned this related proposal: Proposal: Criteria for Removing “Beta Support” from Each PHP 8+ Version.

@joemcgill suggested this may be a conversation that needs to start in #core-php to see if there is already an active effort in place to continue making progress, and if not, try to kickstart the process.

@jorbin noted that the outline the criteria and process for reviewing each "beta support" PHP version with each WordPress major release  item is what is needed to get completed to move this forward. And then clearing out the php-compatability focus.

@joemcgill added that it seems like one of the biggest risks currently is that WP continues to show only beta support for supported PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions once 8.4 is released later this year, so it would be nice to make progress on this.

@costdev highlighted that this effort should be led by a sponsored contributor, due to the amount of work involved. @jorbin mentioned that if there is a host who wants to sponsor this, please get in touch via a DM or a comment on this post.

Aligning the coding standards for Core and Gutenberg so that both can use the same tooling

@jorbin kicked off this topic with:

This is inspired by two things:

  1. The lack of prettier / mismatched tooling for JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. between the two repos
  2. The conversation/PR a few months back to remove the WordPress-Docs ruleset from Gutenberg

It’s also something I was just raising for visibility.

Slack reference

@joemcgill noted that: As I recall, this has been mentioned as one of the main challenges to more frequent syncing of GB packages to Core, as well. (e.g., https://github.com/WordPress/gutenberg/discussions/59786#discussioncomment-8784550)

It looks like @get_dave was planning on writing a Make Core post following the above discussion on 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 be the repository owner. https://github.com/. In that discussion, @antonvlasenko summarised two issues relating to the PHP side:

  1. Developing the missing linters to enforce WordPress Core standards.
  2. Fixing an issue with synchronizing the rulesets between Gutenberg and WordPress to ensure a unified set of linters.

@jorbin mentioned that for the JS side, there likely is going to need to be a mass reformatting commit or two (if it’s similar to the experience from when jshint was first put into place).

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

@presskopp mentioned: From time to time I like to remind ourselves of the following, never giving up hope to be heard https://wordpress.slack.com/archives/C02RQBWTW/p1627500098438000

@afragen mentioned: Just an FYI. We are working on the merge proposal for Rollback Auto-Update and would like to put it on the agenda for next week.

Props to @joemcgill for reviewing.

#6-6, #dev-chat, #summary

WordPress 6.5.3: An upcoming maintenance release

WordPress 6.5.3 is scheduled to be the next maintenance release for the 6.5 version. Its release will follow the following preliminary schedule:

  • 2 May 2024 – 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). made available and announced here on the make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
  • 7 May 2024 – Final release made available.

Specific times will be decided in advance and adjustments to the schedule may be made. All adjustments will be noted in this post.

Minor or Maintenance releases of WordPress are intended as 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.-fix releases. If you have a 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. that you think should be considered, please put it in the 6.5.3 milestone. If you have a 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 be the repository owner. https://github.com/ issue, please add it to the 6.5.x Editor Tasks board. If you lack bug gardening capabilities and have a ticket or issue you wish to highlight for 6.5.3, please add a comment here.

Note: except in extreme situations, only bug fixes will be considered and generally only bugs that have been introduced during the 6.5 cycle.

Get involved with 6.5.3

Bug Scrubs will happen in the #core room during the following times:

Each of the open tickets is going to require development work along with testing and review. You can also run your own scrubs to help ensure that all of the correct tickets are fixed in this release. Additionally, while the intent is for no new translated strings in this release, some locales have strings in 6.5 in need of translation.

General coordination for the release will happen in the #6-5-release-leads channel and decisions around code for the release will be made in the #core room.

This 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. will be led by @grantmkin and myself (@jorbin).

Thank you to @grantmkin for pre-publication review.

#6-5, #6-5-x

Performance Chat Agenda: 16 April 2024

Here is the agenda for this week’s performance team meeting scheduled for Apr 16, 2024 at 15:00 UTC.

  • Announcements
    • Welcome to our new members of #core-performance
    • Performance Lab 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 version 3.0.0 launch on Mon April 15
  • Priority items
    • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
      • Current release (6.6)
      • Future release
    • Performance Lab plugin (and other performance plugins)
      • Need to finalise a decision regarding streamlining PL plugin and other standalone plugins #1061
    • Active priority projects
      • INP research opportunities
      • Improve template loading
  • Open floor

If you have any topics you’d like to add to this agenda, please add them in the comments below.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Bundled Theme Bug Scrubs

Starting Monday, April 15th 2024 at 13:00 UTC there will be a bundled theme 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. scrub.

Currently, there are over 326 tickets in the bundled theme component queue. Recently, efforts have been made to reduce the queue, which is going well. This is part of the default theme taskforce work this year. Now is also a great time to introduce a scrub as part of that process. The following is what to expect:

  • An hour going through tickets one by one.
  • Progressing each ticketticket Created for both bug reports and feature development on the bug tracker. raised in some way: this might be through keywords or time-framed discussions.
  • The scrub will be held in #core-themes within 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/..
  • Scrubs will be held every two weeks.

Thanks to @poena @luminuu @desrosj for pre-publication review.

#bug-scrub #bundled-theme #core-themes

WordPress 6.5 Release Retrospective

Congratulations to all who helped make WordPress 6.5! Now that it has launched, I invite you to reflect and share your thoughts on the release process and squad to learn, iterate, and improve for future releases. 

Whether you led, contributed, tested, followed along—whatever your role, even if you didn’t have one—you are welcome to participate in this retrospective. So please take a moment to complete the form or leave public feedback in the comments below.

Please note: the survey is not anonymous. That’s in case a relevant person wants to reach you for further clarification. But your email address will not be shared publicly, and nobody is going to use it for any other purpose.

The form and comments will be open until April 26th, 2024. Shortly thereafter, you’ll see a follow-up post with collected, anonymized results.

Again, thank you for your contributions to 6.5 “Regina,” and for taking the time to help make future releases even better!


Props to @akshayar and @marybaum for the peer review

#6-5 #retrospective

#core, #release-process

Summary, Dev Chat, April 10, 2024

Start of the meeting in 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/., facilitated by @mikachan.

Announcements

WordPress 6.5.2 Maintenance and Security Release was released on Tuesday, April 9. WordPress version 6.5.1 could not be released due to a packaging error.

Forthcoming Releases

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.: 6.6

We are officially in the WordPress 6.6 release cycle.

@priethor published this WordPress 6.6 Planning Proposal & Call for Volunteers post recently, and is currently collecting the names of squad and cohort volunteers to share with leadership.

@jeffpaul commented that “at least finalizing the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. & Editor tech leads and an 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). would go a long way towards formally kicking off.”

@jorbin said, “I’ve also seen a couple questions about default themes and getting that kicked off during this release, I think getting an answer there would be helpful”

@joemcgill asked, “…what the focuses of this release would be. @chanthaboune originally proposed that 6.6 be held as a maintenance and polish release in this post, but I’m unsure if that’s still the plan.” And later, “To be clear, I’m not necessarily advocating for 6.6 to be mainly a polish release, I just see the need to be intentional in release planning if we want to actually execute that objective.”

Next maintenance release: 6.5.3

There are currently 13 open tickets in the 6.5.3 release milestone.

Later in the meeting @jorbin shared an initial proposed schedule for 6.5.3.

The first 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. for 6.5 is out, though it was a quick turnaround security release. For a proper minor release, I would like to gather thoughts on the following plan:

  1. @grantmkin has volunteered to help on the editor side (Thank you!)
  2. I would like to suggest a target of 7 May for 6.5.3 with an RC on 2 May. This will allow for about 4 weeks to identify and fix any bugs. I think Tuesday’s have served us fairly well.
  3. To assist in this, I would like to start 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. I’m thinking twice weekly with one focused on tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and one on 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 be the repository owner. https://github.com/ until we get closer to the release with the last few looking at both bug trackers
Slack reference

Next 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/ release: 18.2

Gutenberg 18.1 was released on April 10 and included these issues. 18.2 is scheduled for April 24 and will include these issues.

Discussion

During discussion we checked in on the progress that the 6.5 release coordinators are making on organizing a release retro post (see this thread). @marybaum confirmed that @priethor, @marybaum, and @akshayar are working on this and will update the #6-5-release-leads channel soon.

It was confirmed that retros have been a part of our release process for several previous releases. Many of them can be found by lookin at the retrospective 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 this site.

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

Tony Gravagno proposed that retrospectives could be used for marketing. “People need an occasional reminder and reinforcement that their platform of choice is aggressively maintained, despite occasional press about 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 vulnerabilities … which is all most people see about WP.” He then suggested that this might be better discussed in the #marketing channel.

Damon Cook shared that he has recently added details to the Project Updates and Details area in key Gutenberg GitHub Project boards (example: WordPress 6.6 Editor Tasks). Damon is planning on trying to keep those up to date throughout the cycle.

Screenshot of the status updates screen from GitHub project boards.


This prompted @jeffpaul to ask whether these updates could be provided on make/core to capture a broader audience.

“My lens is for someone who’s not in lots of GitHub issues, PRs, or boards and finds it hard to stay current on what’s transpiring there and thus not as able to contribute without that context.  Trying to find ways to bring some of that scattered context back to make/core for broader consumption and contextual understanding.”

Damon was open to experimenting on how to best cross-share info in both places. “…for now, I just wanted to make folks aware that I’ve started utilizing the feature and can even deactivate or remove it if it is confusing.”

The full conversation about these status updates starts here.

@dmsnell wanted to remind folks about his proposal to remove support for HTML4 and XHTML. “Doing this is mostly ceremonial, since those formats aren’t supported in reality. Removing them officially though gives us liberty to modernize existing code and improve WordPress’ HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.-handling reliability. More info in the linked ticketticket Created for both bug reports and feature development on the bug tracker.#59883“.

Props to @mikachan for reviewing.

#6-6, #core, #dev-chat, #summary

Performance Chat Summary: 9 April 2024

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Welcome to our new members of #core-performance
  • Plan to launch Performance Lab 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 version 3.0.0 on Mon April 15

Priority Items

Structure:

  • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
    • Current release (WP 6.6)
  • Performance Lab plugin (and other performance plugins)
    • Open discussion regarding streamlining PL plugin and other standalone plugins #1061
  • Active priority projects
    • INP research opportunities
    • Improve template loading

WordPress Performance Trac Tickets

  • For WordPress 6.6:
    • @adamsilverstein volunteered to be the performance release leadRelease Lead The community member ultimately responsible for the Release. for 6.6

Performance Lab Plugin (and other Performance Plugins)

  • Open discussion regarding streamlining PL plugin and other standalone plugins #1061
    • @flixos90 at a high level I like what @swissspidy proposed in https://github.com/WordPress/performance/issues/1061#issuecomment-2044774194
      • It would be great if we could have distinct releases per plugin, and automate it completely. Even before we had standalone plugins, the Performance Lab release process involves quite a bit of manual work, like bumping versions and adding changelog in PRs. It takes just a very short time, so not a big overhead, but still prone to human error
    • @joemcgill I definitely like the idea of making the release on GH the result of a release rather than the cause of a release. Seems like we need to better define all of the requirements that an updated process should meet prior to diving into implementation. Is there someone consolidating those requirements?
      • @thelovekesh has volunteered to pick this up, aiming for next Monday to collect everyone’s feedback and to generate a proposed approach
  • @mukesh27 has been working on below some follow-up PRs.
    • PRs that have been merged:
      • PR #1116 – Delete option when uninstalling the Modern Image Formats plugin
      • PR #1117 – Update 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 be the repository owner. https://github.com/ actions dependency
  • @flixos90 opened https://github.com/WordPress/performance/issues/1118 which is about enhancing the npm run since script to support standalone plugins. This unlocks a simple yet valuable improvement to our current publishing workflow for standalone plugins. That said, this is separate from the main discussion we should have here as it doesn’t holistically change anything. I just wanted to mention it for reference

Active Priority Projects

Improve template loading

INP research opportunities

  • @adamsilverstein still working through the results, some discussion has continued in comments on the doc. I also saw @swissspidy opened this ticketticket Created for both bug reports and feature development on the bug tracker. which is related to one of the findings #60962 (thanks!)
    • One other small update, part of the INP doc suggests a move towards Interactivity 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. adoption could be helpful, in that regard I have added custom metrics to httparchive so we can track API adoption: https://github.com/HTTPArchive/custom-metrics/pull/113
  • @westonruter For sites still using MediaElement.js, I’ve identified some code that appears to be needlessly spending ~50 ms (when profiling at 6x CPU slowdown on my machine) to check if the pointer-events style is supported. Since this is now supported by >98% of browsers, I think this entire 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. of logic should be replaced with just a simple export const SUPPORT_POINTER_EVENTS = true given this.
    • Granted, this would be more of a LCP fix than an INP fix since it happens early when the page is loading.

Open Floor

  • @thelovekesh This PR is waiting for review – https://github.com/WordPress/performance/pull/981. Can someone please take a look. Thanks.
  • @spacedmonkey I am going to look into adding new functions for loading multiple networknetwork (versus site, blog) option at once. These plan to mirror the new options for site options. Everyone happy to add this to performance focus?
    • I also want to look into a ticket I created regarding changing how query caches are invalidated
    • At the moment, we use last change as a salt for cache keys. This results in validation but it also means for high traffic sites that generate lots of content, lots of keys being generated. So much so that people are turning the query caches off.
    • I want to find a way to reuse the same query cache keys even after invalidation. Instead of make a new cache and hoping a the existing one falls out of cache, reuse the same key and sort the last modified time as part of the object.

Our next chat will be held on Tuesday, April 16, 2024 at 15:00 UTC in the #core-performance channel in Slack.

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

What Happened to WordPress 6.5.1?

Observant folks will notice that the first 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. for WordPress 6.5 is 6.5.2 instead of 6.5.1. This is due to an error with the initial package. When the 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.) for 6.5.1 was created on the WordPress build server, it was created from a previous revision of the 6.5 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".. As tags are treated as immutable, this meant that WordPress 6.5.1 could not be released.

As a follow-up, the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team will work with 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 and update respective documentation as needed to ensure that everything is done to prevent similar situations.

Thanks to @audrasjb, @davidbaumwald, and @jeffpaul for pre-publication review.

#6-5, #6-5-x

Conducting WordPress performance research in the field

Over the past few years, several Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. posts, for example the 2023 performance retrospective, have referenced field data based on how real users experience millions of real WordPress sites. Such field data can help gather metrics of many different kinds, such as adoption of a feature or even its performance impact. As such, they can be instrumental in demonstrating the success of or potential concerns about a feature or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature..

Gathering this data can be accomplished using public datasets like those from HTTP Archive and the Chrome User Experience Report (CrUX). However, as it requires writing BigQuery queries, getting the data may not be trivial as it is a separate technology not relevant for WordPress core development or 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 development.

To provide a better starting point for those new to BigQuery, 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. Archive, and CrUX, members of the WordPress Performance Team and HTTP Archive have collaborated on a tutorial and reference Colab.

Whether you are new to those technologies or whether you have already written a few BigQuery queries, the Colab provides an introduction and can help build more familiarity. It only assumes some familiarity with SQL in general, such as from writing custom database queries in WordPress. The Colab comes with several queries, alongside their results, which can be used as a reference, and covers use-cases relevant to WordPress core development as well as plugin and theme development. It can be considered a “living resource”, i.e. expect for it to be updated and expanded in the future.

Other than this post, you can also find the Colab linked from a new Make Performance Handbook article on gathering WordPress performance data in the field.

If you are interested in field research around WordPress sites, you may want to take a look and work through the Colab. As it contains a lot of content, please feel free to work through it in multiple sessions.

#analysis, #core, #core-web-vitals, #performance, #plugin, #theme