Devchat agenda, June 29, 2022

1. Welcome

Last week’s summary

2. Announcements

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/ 13.6 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). 1

3. Blogblog (versus network, site) posts of note

A week in Core, June 27

4. Upcoming releases

The next major is WordPress 6.1.

If you have early tickets, announcements, or you need some help, there’s time here for you.

The next minor is WordPress 6.0.1.

@annezazu has published a team and a schedule!

5. Open floor

Component maintainers with reports have priority. Then, if you have an item, please add it to the comments. If you aren’t going to make the chat, please say so, and the facilitators will bring up your item. If you have a report, the group can post that for you too — again, if a facilitator knows about it.

#6-0-1, #6-1, #agenda

Editor Chat Agenda: 29th June 2022

Facilitator and notetaker: @jorgefilipecosta.

This is the agenda for the weekly editor chat scheduled for Wednesday, June 29, 2022, at 03:00 PM GMT+1. I

This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

If you cannot attend the meeting, you are encouraged to share anything relevant to the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Rollback Feature: Testing Call to Action

While it is a rare occurrence, updating plugins and themes can fail in such a way that leaves the old 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/theme non-functional, and may leave users with a broken site.  #51857 intends to add the ability for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to “rollback” to the previously installed version of a plugin/theme when such a failure occurs.

Over 19 months of development and testing has gone into this feature, primarily by @costdev, @pbiron, and myself (@afragen). Several different solutions and they have led us to the current PR2225.

It was determined that copying the current plugin to an alternate location and in the event of an update failure, copying it back into wp-content/plugins, would be the least resource intensive method. This does require one additional plugin copying operation and two if there is a update failure.

rename() was essential to the rollback feature as many reported issues were timeout issues on some resource starved hosts, #54166 as an example. Using rename() allows us to vastly improve the performance of the current method, rather than using copy_dir() as a recursive file copy. It was thought that this recursive file copy, on some systems, resulted in timeout issues for large plugins.

Do you use a VirtualBox-based environment?

Please follow these steps before continuing.

Call to Action

Big Need:

Broad testing and feedback is needed on many different web hosting platforms, including inexpensive shared hosting, managed hosting, and more.

How do I test Rollback?

Do not test on a production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing..

But do test on a local environment, hosted staging or test environment, or cloud staging or test environment.

  1. Here are some large plugins used for testing: akismet, jetpack, mailpoet, woocommerce, wpforms-lite, wordpress-seo
    • WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/: wp plugin install akismet jetpack mailpoet woocommerce wpforms-lite wordpress-seo
  2. Do this from the plugin’s page on https://wordpress.org/plugins by navigating to the “Development” tab, clicking “Advanced” to the right, and downloading an older version from the dropdown at the bottom of the page. You can also install the current version then modify the version in the plugin’s main file to decrement the version number.
  3. Install the WordPress Beta Tester plugin, set to Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. and Nightlies. Go to Dashboard > Updates and click the Update to latest 6.1 nightly button.
  4. Install the Rollback feature plugin or test using the PR2225 in WordPress/wordpress-develop.
  5. Please make a note of the time required to perform plugin updates. Your phone’s stopwatch function may be the easiest method to do this.

Testing a single plugin update:

  1. Navigate to Plugins > Installed Plugins.
  2. Click “Update Now” located within the plugin row.

Testing bulk plugin updates via “Plugins”:

  1. Navigate to Plugins > Installed Plugins.
  2. Select another two plugins, select “Update” from the Bulk Actions dropdown, and click “Apply”.

Testing bulk plugin updates via “Dashboard”:

  1. Navigate to Dashboard > Updates
  2. Tick all plugins with an available update.
  3. Select “Update” from the Bulk Actions dropdown, and click “Apply”.

Testing updates via WP-CLI (if already familiar).

Validation of successful updates

This requires activating all the testing plugins on your testing site. Unsuccessful updates should show PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher Errors or PHP Fatal Errors.

  1. Activate each of the plugins that were updated.
  2. In WP Adminadmin (and super admin), navigate to each plugin’s menu pages.
  3. Navigate the frontend of your test site.
  4. Navigate to your wp-content/upgrade/temp-backup/plugins folder. It should be empty.

Forcing an update failure

Use the following 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. to force an update failure. This will reinstall the previously active plugin/theme.

add_filter( 'upgrader_install_package_result', function() {
  return new WP_Error( 'simulated_error', 'Simulated Error' );
});

Testing update failures

When testing for failures on the bulk update in update-core.php you must use the PR. There is a modification in the PR that stops WP_Upgrader::unpack_package() from deleting the items in the temp-backup directory.

Needed Feedback?


How long did the update(s) take?

  • Your phone’s stopwatch may be the easiest option for logging the time to update.
  • Please test without the Rollback plugin or PR active for a baseline.
  • Reinstall the earlier versions as before.
  • Test the updates again with the Rollback plugin or the PR active.
  • Please provide the list of updated plugins/themes, the timings, and your environment details.
    • web host
    • PHP version
    • nginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/., apacheApache Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free., etc
    • WordPress version
  • Continue

Did you receive any “Failed to update” errors?

  • Yes:
    • Please provide environment details.
    • Please provide the name of the plugin(s) that failed.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or using WP-CLI?
  • No: Continue

Did you receive any Fatal Errors when browsing your site after the update?

  • Yes:
    • Please provide your environment details.
    • Please provide the name of the plugin(s) that resulted in Fatal Errors.
    • Please provide the Fatal Errors that were displayed.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or WP-CLI?
  • No: Continue

Was the wp-content/upgrade/temp-backup/plugins folder empty?

  • Yes: Thank you! Please report your results, and environment details, in the comments below.
  • No:
    • Please provide your environment details.
    • Please provide the name of the plugin(s) that remain in wp-content/upgrade/temp-backup-plugins.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or WP-CLI?

Where do I report issues?

Please report test results or issues as comments on this post. Please list your environment in your results.

Editing assistance from birds and squirrels, also @ironprogrammer, @davidbaumwald, @hellofromtonya

#rollback

WordPress 6.1 Planning Roundup

WordPress 6.1 will be the third major release of 2022. Following WordPress 6.0 Arturo, 6.1 will aim to refine those experiences found in Arturo and in 5.9 Joséphine [ref]. In preparation, this post includes target dates, features, and a call for the release’s squad.

This release cadence will consist of a long alpha and two short 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. periods before the 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). phase. According to the schedule proposed below and 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/ release cadence, WordPress 6.1 would include up to Gutenberg 14.1 for a total of 11 Gutenberg releases, the same amount as WordPress 6.0 included.

Proposed WordPress 6.1 Schedule

MilestoneDate
Alpha (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. open for 6.1 release)May 3, 2022
Beta 1 & Feature FreezeSeptember 20, 2022
Beta 2September 27, 2022
Release Candidate 1October 4, 2022
Release Candidate 2October 11, 2022
Release Candidate 3October 18, 2022
Dry RunOctober 24, 2022
WordPress 6.1 General releaseOctober 25, 2022

Proposed WordPress 6.1 Release Leads

Release LeadRelease Lead The community member ultimately responsible for the Release.: Matt Mullenweg
Release Coordinator: TBD
CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Lead: TBD
Editor Tech Lead:  TBD
Core Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead: TBD
Editor Triage Lead: TBD
Documentation Lead: TBD
Marketing & Communications Lead: TBD
Test Lead: TBD
Design Lead: TBD

All release decisions will ultimately be this release teams’ to make and communicate while gathering input from the community.

Join The Squad!

If you are interested in being a part of 6.1’s release squad, please show your interest in the comments below. Roles can be shared among more than one person!

#6-1, #planning

Proposal: Editor Weekly Bug Scrubs

This post is a proposal to start weekly Editor Bug Scrubs in #core-editor the week of June 28th. The scrubs will have a singular focus on issues in the Gutenberg GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ repository. If you have feedback, please comment by June 24th, 2022.

Overview

New in the WordPress 6.0 release cycle, the role of Editor Triage Lead triages 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/ issues in the release and, to that end, runs weekly 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 in #core-editor.

As the release progressed, it became clear just how valuable these weekly meetings were in moving issues forward. And as the launch drew near, George Mamadashvili (@mamaduka) suggested continuing the scrubs a weekly, regardless of the release schedule.

Gutenberg right now has more than 4,200 open issues, and the number grows faster by the month.

And that number, especially out of context, makes a fairly convenient data point for observers to cite as evidence the project is not production-ready. Now, the same records that show the issues also show that dozens of contributors regularly and actively triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. these issues.

But the process for working through any set of issues on GitHub or tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. is informal — that is the nature of 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.. Which also means, therefore, that the process utterly depends on the interests and skillsets of those contributors who show up and do the work.

The result is an ad-hoc process that has produced hundreds of stale issues. Many of those are no longer relevant, but they stay open because nobody formally closes them. And truly important issues are at a nontrivial risk of slipping through the cracks.

Weekly bug scrubs will not single-handedly solve these problems. But they will dedicate a solid hour every week when team members (including you, who are reading this now!) get together, review issues, and make concrete plans to resolve them.

And during release cycles, the structure will give Editor Triage Leads a ready structure and a team of contributors to get more done, and produce a better experience, with every new version of WordPress.

Proposal

  • What will happen? An Editor Weekly Bug Scrub meeting, in #core-editor 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/., every Tuesday at 1400 UTC.
  • When will they start? The week of June 28, 2022.
  • How will people know they’re happening? The scrubs will be on the Meetings Calendar.
  • What will they cover? Bug scrubs will follow the normal process in the Handbook — but address only Gutenberg issues on GitHub. 
  • Who will run these scrubs? Members of the Gutenberg Triage Team. Nick Diego (@ndiego) and George Mamadashvili (@mamaduka) will run the first several. Then other team members will get onboarded for future sessions. 
  • How will they work with the release cycle?
    • As soon as the release squad has a designated Editor Triage Lead, that person will lead the meetings and tailor triage efforts to he release in progress. 
    • At launch, meeting leadership will go back to the Gutenberg Triage Team. Ideally, Editor Triage Leads will have come from the Gutenberg Triage Team, so that transition should be seamless.

Next Steps

So what do you think?

Please share your comments by June 24th. If the community agrees Editor Bug Scrubs would be a good thing, the first scrub will be Tuesday, June 28, 2022, at 1400 UTC.

Props to George Mamadashvili (@mamaduka), Justin Tadlock (@greenshady), Héctor Prieto (@priethor), and Birgit Pauli-Haack (@bph) for their help in putting this proposal together.

(Ed. note: Also, did you know that anyone can lead a bug scrub, for any reason? That means you! And you can focus your scrub on any tickets you like, or any Gutenberg issues. (The difference: most of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. runs on Trac, which uses tickets and patches. The 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 runs on GitHub, which uses issues and pull requests. – @marybaum)

#bug-scrub, #editor, #gutenberg

Global Styles variations in WordPress 6.0

Theme authors can now create multiple theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. variations and place them into their theme’s /styles folder. From there, users can switch between the various presets to something that suits them best.

Custom JSON files should follow the standard theme.json schema and their filename is going to be used as the variation’s label in the UIUI User interface (example blue.json).

Webfonts handler

A webfonts handler has been included in this release, allowing theme authors to include multiple font options within a single theme.json file or to offer vastly different styles by utilizing different font options in their multiple theme.json variations.

{
  "settings": {
      "typography": {
          "fontFamilies": []
      }
  }
}

Here’s a more robust example of how to implement this new option:

{
	"settings": {
		"typography": {
			"fontFamilies": [
				{
					"fontFamily": "-apple-system,BlinkMacSystemFont,\"Segoe UI\",Roboto,Oxygen-Sans,Ubuntu,Cantarell,\"Helvetica Neue\",sans-serif",
					"name": "System Font",
					"slug": "system-font"
				},
				{
					"fontFamily": "\"Source Serif Pero\", serif",
					"name": "Source Serif Pero",
					"slug": "source-serif-pero",
					"fontFace": [
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "normal",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Roman.ttf.woff2" ]
						},
						{
							"fontFamily": "Source Serif Pero",
							"fontWeight": "200 900",
							"fontStyle": "italic",
							"fontStretch": "normal",
							"src": [ "file:./assets/fonts/SourceSerif4Variable-Italic.ttf.woff2" ]
						}
					]
				}
			]
		}
	}
}

Right now, there is only support for top level settings and the more granular option of defining fonts per 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. is not currently available. For further inspiration, theme authors can review the approach the default Twenty Twenty-Two theme has taken since it will ship with three style variations with different fonts for WordPress 6.0.

Notes

  1. The variations require using the version 2 of theme.json.
  2. Right now when a variation is applied its contents are still merged with the theme and core theme.json, but it’s not possible to override a single value in an array of items or merge arrays. For example adding a value in settings.color.palette would replace the entire palette.

For more info see #38124.

Props to @annezazu for collaborating on this note.

#6-0, #dev-notes, #dev-notes-6-0

Block editor styles: initiatives and goals

The CSSCSS Cascading Style Sheets. rendered by the 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 needs improvement.

The challenges are many and they have been documented. There are, nevertheless, several recurring themes:

  • An overabundance of rendered inline style tags and duplicated CSS rules. For example, see #41434.
  • Confusing or meaningless classnames, or the lack of semantic and utility classes. See the proposals in #38719 and #38998
  • Difficulty extending and customizing styles for themes due to high specificity. Touched upon in this post, and demonstrated in issues such as #40159, #36135 and #37590.

The purpose of this post is to highlight ongoing initiatives targeted at addressing these issues, and to outline longer-term ambitions to output more readable, efficient and extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. frontend styles. 

Roadmap

Phase 1: block styles consolidation and refactoring the layout abstraction

Goals:

  • To audit and consolidate where the code generates block support CSS in the backend so that they are delivered from the same place (as opposed to multiple places). This covers CSS rules such as margin and padding, typography, colors and borders. 
  • Removing repetitive layout-specific styles and generating semantic class names for each layout. 

Phase 1 is currently underway. 

The focus in Phase 1 has been to lay a foundation that will make it easier to introduce iterative improvements. 

Rather than printing block styles on demand from multiple locations, the focus is to create a single, centralized agent responsible for generating them, and, in later phases, assume the responsibility of processing and rendering better frontend CSS.

Work on this has started and is progressing well. See Tracking: Add a Style Engine to manage rendering block styles #38167.

A pull request that reduces rule duplication and institutes semantic class names for the layout block support is ready for review. It also centralizes layout definitions, which will pave the way towards adding additional layouts in the future.

See: Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json #40875

Phase 2: global styles consolidation and reducing style tags

Goals:

  • Connect global styles to the same mechanism with which we’re generating block styles.
  • Reduce the number of inline style tags we print to the page for block, layout and elements support.
  • For layouts, use a presets-like approach to generate semantic class names for attributes of layouts.

Building upon Phase 1, the outcome of this phase is to have a single styles “generator” capable of building CSS for both block and theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML./global styles.

In Phase 2, the objective is to explore how we can leverage this consolidated system of style generation by first grouping, then rendering a minimal set of style tags to the page. 

This includes, for example, moving block supports styles such as layout and elements to a single style 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.), then identifying other candidates for optimization.

There are already some very early, investigative PRs:

With regards to layout support, extending the group of semantic/utility classes to combine common attributes such as content justification and orientation, further reducing repetitive layout-specific styles.

Phase 3 and beyond

Proposed goals (in no particular order and not exclusive):

  • Continue with style consolidation, address edge cases or unique blocks that require special handling, such as the Gallery block.
  • Explore pre-render CSS rule processing with the intention of deduplicating other common and/or repetitive block styles.
  • Extend the scope of semantic class names and/or design token expression, and encapsulate rules into stable utility classes.
  • Establish and document standards by which to extend/override CSS.
  • Propose a way to control hierarchy and specificity, and make the style hierarchy cascade accessible and predictable. This might include preparing for cascade layers until they become more widely supported, and allowing for opt-in support in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ via theme.json.
  • Allow for rendering styles in asynchronous contexts. See #35376

The intention is to publish GithubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ discussion threads for these topics to gather ideas and feedback.

How we’re going and how we’ll get there

The expectation is for the layout refactor and much of the styles consolidation work mentioned in Phase 1 to ship in WordPress 6.1

Phases 1 and 2 aim to ameliorate pain points, and also set things up for future enhancements in Phase 3++.

Style nirvana might well be out there, however the path comprises individual stepping stones, discovering how individual parts contribute to the whole, and balancing compatibility and stability with innovation.

If we can keep refining and narrowing the scope, shipping in stages, and laying out the foundations, I think we’ll be in a better position to manage the risks and challenges and greatly improve the condition of our rendered styles and frontend output. 

Thanks to all the folks who have shared their wisdom so far. ❤️ If you’d like to contribute, or have feedback or ideas on present or future initiatives, please leave a comment on one or all of the ongoing projects I’ve linked to in this post. 

Acknowledgements: This post was co-authored with @andrewserong and @isabel_brison, with the assistance of @apeatling and @matveb.

#core-css, #core-editor, #gutenberg

WordPress 6.0.x release team and 6.0.1 schedule

The 6.0.x releases will follow the same consistent minor release leads strategy as the 5.8.x releases and 5.9.x releases did. For the 6.0.1 point releases, the release leads will be:

  • Release LeadRelease Lead The community member ultimately responsible for the Release. / CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tech: @sergeybiryukov
  • Release Deputy / Editor tech: @zieladam

@zieladam is going to help with 6.0.1 but, for a 6.0.2, there’s an opening if someone is able to help. I’ll keep this post up to date as that changes.

6.0.1 proposed schedule

The following schedule is being proposed for 6.0.1:

  • 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).: July 5th, 2022
  • Final release:  July 12, 2022

@sergeybiryukov will run mission control for this release.

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

As of the publish date of this post, 4 Trac Tickets have been fixed and are ready to be backported to the 6.0 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". to be included in 6.0.1. 6 additional tickets either need testing or have 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. in order to be considered for backporting. 

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ issues updates

As of the publish date of this post, there are 13 pull requests ready for backporting to the 6.0 branch.

Release coordination

The #6-0-release-leads channel will continue to be used for all coordination and conversation related to the 6.0.x releases. This matches the pattern of communication that worked well for the 5.9.x cycle!

#6.0 #6.0.1

Performance increase for sites with large user counts (now also available on single site)

In WordPress 6.0, websites with more than 10,000 users will see improvements in handling users. Prior to changes in #38741, sites with more than 10,000 users would suffer from slow page loading time in the user and post list screens. 

The user screen was slow because a complex SQL query was run to get the number of users for each role. This sometimes resulted in page timeout or failures to load. On the post edit screen, a dropdown of authors in the quick edit option used to change the post’s author. On large sites, this results in thousands of options rendered on the page, which creates a large amount of markup and causes timeouts and slowdowns. 

Introducing large sites

The idea of a large networknetwork (versus site, blog) in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site configurations of WordPress has existed since WordPress 3.0. A network is considered large when it has over 10,000 users. When marked as such, any real time calculation of the number of users is skipped and all counts of users are deferred to scheduled (cron) events. 

This idea of a large network has now been ported to single site installs of WordPress. Any site with more than 10,000 users is marked as large. Once this threshold is met, real time counts, such as ones noted above, no longer occur on every page load. This means that when viewing user lists, the count next to each user role will be missing. This massively improves the performance of the page page load and prevents slow database queries causing PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher timeout errors, which in turn helps ensure the user list renders every time on large sites. 

This change includes some new functions:

  • get_user_count
    Now available for both single- and multi-site installations. For sites with over 10,000 users recounting is performed twice a day by a scheduled event. 
  • wp_update_user_counts
    Perform a user count and cache the result in the user_count site option. 
  • wp_is_large_user_count
    Determines whether the site has a large number of users. The default threshold of 10,000 users can be modified using a 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. of the same name.

Now that the get_user_count is available for both single and multisite, it is strongly recommended not to use the count_users function in your code. This function is not performant and is the root cause of issues noted above. Wherever possible, every instance of count_users in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been converted to use get_user_count, which is also recommended action 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 authors. 

Props to @kkautzman, @milana_cap, and @bph for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #performance

Proposal: Disallow assignments in conditions and remove the Yoda condition requirement for PHP

After discussion with several coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers and WordPress leads, the title and the contents of the text were changed to clarify that this is a proposal and not a decision set in stone.

This proposal is the continuation of the long discussion on the WordPress Coding Standards (WPCS) repo.

Yoda conditions (or Yoda notation) is the programming style where the parts of an expression in the condition are reversed from the ‘typical’ order.

In a large part of the world, the natural reading order is left to right (LTR). This is what most programming languages adhere to. That means the variable assignments or echo/print statements are written with the variable first:

$post_type = 'post';

echo $post_type;

With the same idea in mind, conditions can also be written left to right, like:

if ( $post_type == 'post' ) {
    $category = get_the_category();
}

With Yoda conditions applied, the above condition would be written as:

if ( 'post' == $post_type ) {
    $category = get_the_category();
}

The idea behind it is that writing the value on the left side of the condition will prevent accidentally assigning the value to the variable since assignments can’t be made to values.

if ( $post_type = 'post' ) {
    $category = get_the_category();
}

While seemingly helpful at first glance, the obvious problem with them is the decreased readability of code, especially for people with reading disabilities such as dyslexia.

How we got here

When the handbook rule about Yoda conditions was introduced there was barely any static analysis tooling available in the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher world. The only ‘foolproof’ way to prevent accidental assignment in conditions was to invert the order of the value being checked and the variable.

Automated checking for assignments in conditions via PHP_CodeSniffer (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), the underlying tooling for WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards. May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook., became available in 2017. Moreover, the current sniffsniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. enforcing Yoda condition in the WPCS doesn’t protect against accidental assignments in conditions.

Today there is tooling in place that can help with identifying assignments in conditions, making the Yoda rules obsolete.

Keep in mind that strict comparisons (===) are already strongly encouraged and a part of the WordPress-Core ruleset (warning), making accidental assignments even less likely.

A thorough analysis was made by Lucas Bustamante in the WPCS ticketticket Created for both bug reports and feature development on the bug tracker. on the impact this could have on the plugins in the WordPress directory. The analysis showed that Yoda conditions are used in 18.02% of the plugins, so the majority of 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 are using non-Yoda conditions.

What to do next?

The discussion in the WPCS ticket is long and opinionated, but comes down to these points:

Disallow Yoda condition

  • Drop the handbook rule that requires Yoda conditions and instead explicitly disallow using them.

Remove Yoda condition as a requirement

  • Discourage, but don’t disallow Yoda conditions. Just don’t report if the code is or is not using Yoda conditions. The rule would also be dropped from the handbook.

In both cases, assignments in conditions will still be checked for and forbidden.

Impact on the Core code

Disallowing Yoda conditions for WordPress Core would mean that all existing patches on open tickets for Core would need to be revisited and fixed accordingly, which could burden the contributors.

Running the same analysis as Lucas did for plugins, over the WordPress Core, there were 5427 Yoda conditions, and 312 non-Yoda conditions.

Luckily, these are violations that can be automatically fixed using phpcbf tool, but care should be taken to check if all the violations were correctly fixed.

If Yoda conditions are discouraged (option 2), and the existing Yoda conditions in the Core code remain, that would mean less work for the Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org., but also would add lots of inconsistencies in the Core code (mixed Yoda and non-Yoda conditions).

Next steps

The chosen way forward is to remove the Yoda condition as a requirement (remove it from the handbook) but not disallow it for the time being.

For WPCS, that would mean the removal of the Yoda conditions requirement (and sniff) in WPCS 3.0, with a notice that non-Yoda conditions will start to be required in WPCS 4.0 version.

Work is currently actively ongoing to prepare for the WPCS 3.0.0 release. There will be a minimum of six months between the 3.0.0 and the 4.0.0 release to allow time for Core and other projects to adjust.

Once WPCS 4.0.0 version is released, a one-time-only auto-fix of all the remaining Yoda conditions in Core will be made, and any patches to the Core which go in after that will have to use non-Yoda.

How to enforce the non-Yoda conditions in your code

If you are a WordPress plugin or theme developer, and you’d like to enforce non-Yoda conditions in your code, you can use the Generic.ControlStructures.DisallowYodaConditions sniff. In your phpcs.xml.dist file you should add the following sniff:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Example Project" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/squizlabs/PHP_CodeSniffer/master/phpcs.xsd">

    <!-- Your custom rules. -->

    <!-- Disallow Yoda conditions in your codebase. -->
    <rule ref="Generic.ControlStructures.DisallowYodaConditions"/>

</ruleset>

If you want to change the Yoda conditions to non-Yoda conditions, use the phpcbf tool (part of PHPCS) with the Slevomat coding standards. Specifically, the SlevomatCodingStandard.ControlStructures.DisallowYodaComparison sniff that has the fixer for the Yoda conditions.

Props to Juliette Reinders Folmer and Gary Jones for the proofreading and adding valuable feedback on the text. Also, a big props to Lucas Bustamante for the impact analysis on WordPress plugins.

#codingstandards, #php, #wpcs