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

Performance team meeting summary 30 August 2022

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

Announcements

  • @flixos90: multiple announcements
    • Team Rep nominations reminder
    • If you are contributing to the WordPress/performance 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/ repository (or any WordPress GitHub repository FWIW), please link your 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/ and GitHub accounts if you haven’t done so. You can do so at https://profiles.wordpress.org/profile/profile/edit/group/1/
    • If you have been contributing to the team’s efforts (e.g. GitHub, discussions, conversations in this chat, …) but don’t have the “Performance Contributor” badge on your profile, you may request to have it added by requesting to join the group at https://profiles.wordpress.org/associations/performance-contributor/
    • If you are contributing to the WordPress/performance GitHub repository, please be aware of a new rule to avoid naming your regular temporary coding branches something like feature/. That feature/ prefix will be reserved for special protected feature branches going forward
      • @adamsilverstein: other than the ‘feature/’ prefix, are there any other conventions we want to follow / is that documented somewhere?
      • @flixos90: Only feature/ and release/ must not be used for regular coding branches (a pull request to document this has since been opened)

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: we have been working on responding to feedback on the WebP ticketticket Created for both bug reports and feature development on the bug tracker. (#55443) and conducting research around the potential usefulness of a “threshold” size above which jpegs would be generated instead of WebPs.  The research used 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/ to run many images through WordPress image compression with WebP quality set at 82, 84 & 86 to investigate how often WebP images are larger than the JPEG equivalent, at what image dimensions, and by how much. I will be summarizing the research in my response on the ticket shortly
    • there seems to be strong agreement that we should only output a single mime type. The main question now is if the mult-mime support is worth keeping – the code adds a good bit of complexity to media, and isn’t strictly required for the approach we are considering now… so we are trying to weigh the pros and cons of keeping it. It might make sense to revert and re-introduce when we have support for async media generation (something we are already working on)
  • @joegrainger: Working on creating sub-issues with implementation details for Regenerate existing images and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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. for Update core functions to support multiple mime types
  • @mukesh27: Working on WebP core follow-up patch https://github.com/WordPress/wordpress-develop/pull/3036 and Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket with performance focus
  • @wpgurudev: Basic regenerate-existing-images module PR has been merged, follow-up PR for background job taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. up for final review; background job class PR is ready, waiting for taxonomy PR to get merged, so that tests can be added
  • @pbearne: Dominant color is getting pushback; would like to suggest that we put it behind a theme feature flag (show-dominant-color) and we add it to the media library in wp-adminadmin (and super admin)
    • @flixos90: We should evaluate that pushback closely. Can you elaborate why it should be controlled by the theme instead?
    • @pbearne: The push back seems to have the theme of “we like this but themes should control the look and feel”
    • @flixos90: So it would mean the data is still added to every image upload, but the theme decides how to use that color information? Sounds reasonable
    • @flixos90: discussing this further will be made a dedicated agenda item next week

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @tillkruess: focus had one core merge last week (see PR / changeset), with great results already (see chart from wordpress.org below, shared by @dd32)
MySQL throughput dropping from roughly 1.5M to pretty much half following the commit

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” 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/.
  • @furi3r: persistent object cache Site Health PR was merged (see changeset / ticket), what is left for the full page cache PR (see ticket)?
    • @flixos90: haven’t re-reviewed it yet since last week, but if all the feedback from then has been addressed and the merge conflicts are fixed, this should be good to go
  • @furi3r: can try to get a Draft for the dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. by next week, I’ll be on holiday after that, so maybe someone can take over if not ready/published

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • @mehulkaklotar: working on proposal 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 Check plugin

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • @pushpakpop: we have started research around the approach for the JavaScript orchestration project

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @mukesh27: PR to fix unexpected input Warning message during release build/test process ready for re-review

Feedback requested

Open Floor

  • @olliejones: Database Performance Health Checks module proposal (continued from last week)
    • @olliejones: Is DBMS server performance part of the mission of this group?
      • @flixos90: Absolutely! Every aspect of performance is relevant to the team’s mission
    • @olliejones revised this health-check module proposal to simplify the output (see https://github.com/WordPress/performance/issues/475 and please look at the “Other” section), agrees with last week’s conversation about excess complexity; we’ll do all the checks and only report the trouble spots
      • @flixos90: In that case I’d argue there is still a lot of complexity. Implementing each of these tests in a reliable way is probably not trivial. To clarify, I’m not saying we shouldn’t do it. I’m only suggesting we start with only one of them for the first version and add the others in additional iterations
      • @olliejones: FWIW I have a prototype I’ve been testing against old versions of DBMS software as well as new versions. The tests were designed to cope with missing RDBMS features in the old versions. Yeah, complex, for sure. But doable.
    • @flixos90: Does anybody have objections against this module proposal?
      • Quick survey of thumbs up / thumbs down resulted in 9 thumbs up and 0 thumbs down
      • @olliejones will start a pull request introducing the module; if it shows that some bits there are too complex to get through in a reasonable time, we can still re-assess if we want to narrow down the scope

Our next chat will be held on Tuesday, September 6, 2022 at 15:00 UTC in the #core-performance channel in Slack.

#performance, #performance-chat, #summary

Devchat agenda, August 24, 2022

1. Welcome

Feel like catching up ahead time? Here’s last week’s summary.

2. Announcements

WordPress 6.0.2 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 has landed! Please download and test.

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

@zieladam would like feedback by September 9 on a new system for updating HTML attributes.

Got a post to share? Add it to the comments.

4. Upcoming releases

The next major is 6.1.

If you have an update, plan to bring it up here.

The next minor is 6.0.2.

The RC is out! Look for the release next Tuesday at 16:00 UTC.

5. Components and tickets

Are you a component maintainer? Shepherding a ticketticket Created for both bug reports and feature development on the bug tracker.? 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 is five weeks away, so the time is ripe!

6. Open floor

Please add your item to the comments.

See you tomorrow at 20:00!

#agenda, #core, #dev-chat

Moving Core block styling to JSON

An effort is currently underway in 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, to streamline and standardize the way that blocks are styled by moving key 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. styling into 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..  This post lays out the reasoning behind this change and the impact it will have for both themes and block authors going forward.

What is theme.json?

Theme.json is a file which provides a single place to configure the behavior of  themes.

It plays an important role in the Full Site Editing project, by storing information about a site’s appearance and providing this in a machine readable format to be consumed by the Editor interface.

One of the key elements of this is the Global Styles interface within the Site Editor which allows users with a UIUI User interface to allow them to modify the default appearance settings provided by their chosen Theme.

Why use JSON to represent a theme’s styles?

Expressing a theme’s styles in JSON gives us several benefits:

  1. It enables users to modify the visual appearance of their site via the UI provided by Global Styles, without needing to write any CSSCSS Cascading Style Sheets..
  2. We have more control and consistency in how the theme CSS is output, so that we can ensure that user’s settings take priority over theme’s settings, and theme’s settings take priority over coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s settings.

What is changing?

To expand the number of customisation options available to users through the Global Styles UI, we need to configure the default visual appearance of blocks using the same tools that will be used to customize these blocks.  This will make it trivial for themes to overwrite the default styles of a block.

In practical terms this means we need to move the rules that define default block appearance from CSS files, to machine readable JSON files, such as `theme.json` & `block.json`.

How can blocks define styles in JSON?

To make the process of moving core block styles into JSON, some new affordances have been created. 

One of these is that the JSON rules for a block can be saved in the block.json file under a new `__experimentalStyles` key.

For example margins on the image block were expressed in CSS like this:

.wp-block-image {
	margin: 0 0 1em 0;
}

Since this change we can now define margins for image blocks in the block.json file like this:

{
	“__experimentalStyle”: {
		“spacing”: {
			“margin”: “0 0 1em 0”;
		}
	}
}

The CSS that is generated from this change is the same as the original CSS file.

For more details on this approach please see “merging block CSS with theme.json styles”. You can also see an example of how this would be implemented in “Block CSS: Move CSS from the stylesheet to the block definition”.

What are the benefits?

Styles are now customizable

The driving force of this change is to enable users to modify the visual appearance of their site via the UI provided by Global Styles, without needing to write any CSS

However this change also has some very important, and useful, side effects.

CSS specificity and performance

For a long time blocks and themes have been struggling with CSS specificity – blocks want to ensure that they provide enough rules that they look good, whilst themes want to override these rules so that different blocks have a consistent appearance (for example ensuring all your buttons look the same). 

This has meant that blocks have to be very careful about the specificity of the selectors in the CSS they provide, to enable themes to override them. 

By expressing visual styles in JSON, and compiling them as part of the main CSS output of global styles, the order and importance of each rule is clear and computable when the theme.json files are processed.

Global Styles processes the different levels of JSON settings, by merging each of these JSON objects together. Once all of the settings are combined, the Global Styles CSS is generated using the final merged result. This means that the resulting CSS only contains the rules the theme needs.

For those not familiar with how rules in Theme JSON files are turned into valid CSS rules here’s a quick refresher. There are x3 “levels” of JSON file:

  • WordPress Core Theme JSON – this holds the base level styles for WordPress.
  • Theme JSON – this is the `theme.json` file from the currently active Theme which provides theme-specific styles.
  • Custom User Styles – these are rules provided by the Global Styles user interface and have the highest level of importance.

When these different JSON representations of styles are merged together, we only preserve the rules for the uppermost setting for each rule before they are converted to CSS rules. 

By moving block CSS rules to JSON we effectively insert a new level into this hierarchy with WordPress Core `theme.json` being overridden by block styles in `block.json` which is overridden by the `theme.json` provided by the theme which is in turn overridden by custom user styles, created in the Global Styles UI.

For clarity the new rules hierarchy is:

  • WordPress Core Theme JSON
  • Block styles in Block JSON
  • Theme styles from Theme JSON
  • Custom User Styles from Global Styles UI.

This also means that the total CSS output of the system will be smaller, which is a performance benefit. 

Exposing default styles

Another benefit of this change is that the default styles for each block are now exposed in the Global Styles UI, before the user makes any changes, so the starting point is obvious and clear. Now that blocks can define most of their styles in JSON, these default styles can be more easily seen and  configured using the Global Styles interface.

Not only are the styles of blocks themselves configurable but the lower level elements used within blocks can also be exposed to the Global Styles UI.

What are elements?

Elements are low level components for themes and blocks, which don’t need the complexity of blocks.

Block composition has not reached a level of infinite composability, hence it is not always possible or good to use, say, the heading block instead of a HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. heading element, or a button block instead of a HTML button element.

Some good examples of these are headings, links and buttons. 

Links are part of many blocks but do not have a block of their own. Headings and buttons are expressed as blocks but many times the block composition limits us, so we’re better off using an HTML heading or button element.

Also, elements are simpler than blocks; they can be used to express semantic features of blocks and enable users to share styles across multiple blocks. For example style rules for the button element will be used in the search block, the file block and the button block.

The number of elements is currently being expanded. Some new elements we expect to add are a caption element and form elements. It is likely some of them will be absorbed into blocks as the block composition 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. gets better, so the implementation of element support is kept at a minimal state.

Putting it all together – exposing default element styles in the UI

If we put these two new concepts (setting default styles in JSON and element styles) together, we can see how the default styles for button elements are now visible in the Global Styles UI:

This helps users to understand the global styles interface more easily as it shows straight away the relationship between these settings and the visual appearance of the block.

Should I set style rules for blocks or for elements?

Theme authors have the option to set styles in `theme.json` for:

  • blocks themselves. 
  • elements within blocks
  • globally for elements shared by blocks.

 It’s important to understand the precedence of each of these options, so you know which one to choose.

  1. Global element styles apply to all instances of an element. These rules will apply across all blocks, to ensure a consistent appearance between all blocks. In some cases this will depend on blocks implementing the elements API to take effect. For example, this would be useful if you wanted to create a style rule that applied to all button elements on your site.
  2. Block styles apply to all instances of that specific block. This is useful if you want to target particular properties of the block itself. For example this could be used to modify the color of all the text within the search block.
  3. Element styles within blocks are the most specific use case. These rules will only apply to elements within a specific block. If users modify global element rules, these the specific customizations for elements within blocks will still take precedence due to their higher specificity, so the user’s global changes won’t apply unless they modify the element settings for that particular block. For this reason this use case should be uncommon. For example, this is useful if you wanted the buttons in your search form to be a different color to the other buttons on your site.

What does this mean for block authors?

Block authors can already take advantage of some of these changes.

Blocks can already start to use the elements API for composing their markup. Right now this only works for the button and captions elements, but as the number of elements is expanded, blocks will be able to compose their markup using these common elements, which will in turn enable them to be better supported by Global Styles.

Blocks can also start to define their style using the `block.json` file, which allows themes to override block styles using `theme.json`, rather than relying on CSS. Styling a block’s supported features within their JSON configuration enables users to modify them via the Global Styles UI.

What does this mean for themers?

This approach gives more tools to themers, to make it easier for themes to have a more consistent style across all blocks without the need for complex CSS. By using the elements section of the theme.json, themes can create style rules that will apply across all blocks that take advantage of these elements, which makes these rules simpler and easier to maintain.

Will this replace the theme’s CSS?

While simple themes may one day be able to replace all their CSS with theme.json settings, it is expected that most themes will still need to provide their own CSS for the more advanced aspects of their design – for example animations.

Is supports > __experimentalStyles the right place for this?

These styles were initially added to supports > __experimentalStyles so that we could begin this work, but ideally these settings would belong in the style key of block.json. There is an open PR to make this possible.

#dev-notes

Performance team meeting summary 23 August 2022

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

Announcements

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • N/A

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” 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/.
  • @furi3r: Both the core PR for persistent object cache check and PR for full page cache check are ready; @flixos90 will review both of these this week again and commit them if they’re good to go

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • N/A

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • N/A

Feedback requested

Infrastructure

@flixos90

GitHub project

  • N/A

Feedback requested

Open Floor

  • @adamsilverstein: fetchpriority module proposal
    • @adamsilverstein: basically the idea here is to give the browser a hint about which image it should prioritize loading
    • @adamsilverstein: we already have logic in place in core to exclude the loading=lazy attribute from images we expect will be the LCP image; so we should be able to apply the fetchpriority=high to those exact image and see improved/prioritized loading for those images; so we shouldn’t need new logic to determine which image to apply the attribute to
      • @eugenemanuilov: so, we are going to use the wp_get_loading_attr_default function to determine whether we want to use the fetchpriority  attribute or not, right? if so, i think this won’t work because it will return false (which is when we want to add the fetchpriority attribute) only once in the default setup, and most likely that once time will be used when we render a thumbnail
      • @flixos90: Potentially, definitely something along those lines. Or we could check if the image has loading="lazy" on it and only add fetchpriority="high" if not
      • @adamsilverstein: was thinking the latter, running on the same hook where loading=lazy is added, but later
    • @flixos90: this seems to be a technically rather straightforward potential module for the 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. As Adam mentioned, the main purpose of the module would be to allow us to test how this behaves and measure the impact in the real world; from there it could be refined as needed and eventually proposed for WordPress core
    • @adamsilverstein: this is a “good first module” if someone wants to try to pick it up!
    • @olliejones: do you propose to include anything to measure the improvements? Or will measurement be based on lighthouse, etc?
      • @flixos90: I think measurement is generally happening outside of the Performance Lab plugin, e.g. using Lighthouse, WebPageTest (for lab tests) or CrUX, 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 (for field tests)
      • @adamsilverstein: the generator 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.) should indicate the active modules, so part of putting it in a module is helping being able to detect it; that said we could also query for the presence of the fetchpriority attribute itself as well
    • @masteradhoc: nice module. Interested to see how this could turn out on real sites and how much it will help. Read this guide some time ago: https://web.dev/priority-hints/; anything planned or could also be useful with the opposite priority?
      • @flixos90: Hmm I’m unfamiliar for which cases you would realistically want to use fetchpriority="low"; at least for images, we already have lazy-loading, so there adding this probably wouldn’t do much, but of course there are other types of resources where the attribute can be added, so maybe there’s some value there
    • @adamsilverstein: worth noting we recently added “preload” capabilities to core (#42438), but fetchpriority serves a slightly different use case that should have better results for LCP images
  • @olliejones: Database Performance Health Checks module proposal
    • @olliejones: This is 100% back end stuff. The DBMS world (MariaDB / MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.) has lots of new performance-enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. stuff. I propose pointing out that stuff to site owners. Five tests in this module:
      • DBMS server version, with a detail check for the availability of the latest table format.
      • DBMS Connect / Query response time test.
      • Two tests for latest’n’greatest table formats: one for core tables (incl WooCommerce) and another for plugin tables.
      • Finally, a comparison of the data size of the site’s tables with the size of the DBMS server buffer pool, to detect underprovisioned DBMS machines.
    • @olliejones: A previous proposal also included instructions for using 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/ to correct some inefficiencies, but that doesn’t work for Performance Lab: it’s aimed at site owners not server ops people.
    • @flixos90: I think there is a lot to unpack here. I wonder if it might be best to start the module with only 1 or 2 of these checks; we could easily make those different checks even different modules, not sure what the benefit would be to having it all in one module except that it’s all related to DBs
      • @olliejones: Benefit for one module? simpler Settings page, that’s it (also shared code among the tests, but that’s not so important)
      • @flixos90: fair point. But maybe we can still start with a subset of the checks. A bit easier to reason about and focus better. Discussing all these topics at once will be challenging. Maybe you can suggest a first check from the list above to focus on discussing?
      • @olliejones: Either Connect/query latency or buffer pool sizing.
    • following up on this new module proposal will be the first special agenda item next week

Our next chat will be held on Tuesday, August 30, 2022 at 15:00 UTC in the #core-performance channel in Slack.

#performance, #performance-chat, #summary

Performance Chat Agenda: 23 August 2022

Here is the agenda for next week’s performance team meeting scheduled for August 23, 2022, at 15:00 UTC.


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

Giving FSE a More User Friendly Name

tl;dr: The terms “full site editing” and “full site editor” (also abbreviated as FSE) were developed to easily refer to a collection of features and now that those features are integrated into our daily WordPress experience, how can we best update the wording to be more user friendly?

Not sure the difference between 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/, full site editing, and other terms here? Check out this post for high level definitions.

What I know

Many years ago when we started referring to some of the work going into Gutenberg’s Customization phase (Phase 2) as “full site editing” it was meant to differentiate from the work that had come out of Phase 1. Phase 1’s work was focused on bringing blocks to posts and much of the page surrounding posts, but Phase 2 was meant to move those blocks to the rest of the site editing experience—hence “full site editing”.

There are some issues with the term “full site editing”, though.

  • It was already possible to edit every part of a WordPress site using code. The term “full site editing” differentiated between phases of a project, rather than a new capability in the CMS.
  • To us, “full site editing” implies the use of blocks, but for new users there’s no reason for them to expect anything else. The term isn’t descriptive of what makes it unique.

As we continue the move toward a full-featured, true WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience for WordPressers of all skill levels, we should have a way to refer to it that is immediately meaningful for new users of our software, while also being an easy to reference term for all of us building and supporting the software.

What I see 

There are a few existing conversations around renaming Full Site Editing (both from a UIUI User interface/UXUX User experience perspective as well as a development perspective). From what I have seen in my reading, there are two primary contexts from a big picture perspective: Users & Visitors of WordPress; Contributors & Extenders of WordPress. That leads me to think we have two primary use cases for terms as well.

  • Users & Visitors of WordPress: I’ve heard a lot of people outside of the WordPress ecosystem simply referring to this as “the WordPress editor”. That seems mostly applicable to folks building with WordPress, selling on WordPress, or otherwise not creating the CMS itself.
  • Contributors & Extenders of WordPress: I have primarily seen references to “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” with the understanding that work toward Full Site Editing is a suite of tools from within the Block editor, a framework that originated in the Post Editor but is extending to all areas of WordPress like the Site Editor, hence most editing interfaces evolving into “the Block Editor”. This seems mostly applicable to folks working in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., on Themes/Plugins, and by extension, also Training, Design, and Documentation.

What other contexts do you think we need to be aware of as we look toward making this more user friendly?

What I need

As with any audacious journey, one of the things that will hinder our success is not knowing what stands in our way. I would love it if you’d share your thoughts on the following questions!

  1. We’ve referred to it this way for a long time. How can we tackle renaming this together?
  2. It’s in the codebase. How will we make sure people who aren’t regular contributors see this?
  3. And repeating the in-line question from above: What other contexts do you think we need to be aware of as we look toward how to refer to our collective work in the future?

#core-editor, #editor, #gutenberg

Editor Chat Agenda: 24th August 2022

Facilitator and notetaker: @zieladam.

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

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, #editor

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

Hallway Hangout: Editor Tech Lead role 101

Serving as Editor Tech Co-leads for WordPress 6.0, @zieladam and @gziolo not only shipped our most polished version of 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 so far, but they also walked the extra mile to automate a lot of the legwork involved in the process 🎉

For WordPress 6.1, @czapla and @bernhard-reiter will be the Editor Tech Co-leads. Since it is a first for both of them, their predecessors have graciously agreed to walk them through the process.

As this knowledge might be valuable to others – especially future generations of Editor Tech Leads – @annezazu suggested turning this into a public Hallway Hangout that will be recorded and shared. Yours truly, serving as Co-release Coordinator in both 6.0 and 6.1, will join this merry band to facilitate.

In a nutshell, we will be covering the following topics from an Editor Tech Lead perspective:

  • Major versions vs. Minor versions
  • Minor version release process
  • Major version release process

If you’re interested in joining, the Hallway Hangout will happen on 2022-08-11 12:00; a Zoom link will be shared in the #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/. channel before starting. We’d be especially interested to hear from previous Editor Tech Leads about their experience and advice! However, everybody is welcome to join to get a glimpse of the ins and outs of the Editor Tech Lead role and, who knows, maybe volunteer in a future release squad !💥

The recorded session will be added to this post once it’s ready.


Edit on August 12th: Recording is available.

Attendees: @bernhard-reiter, @bph, @czapla, @gziolo, @priethor, @hellofromtonya, @zieladam

Resources shown in the video:


Thanks to @bernhard-reiter for coauthoring and reviewing this post.

#hallwayhangout #6-1 #core-editor