Make WordPress Core

Keyboard Shortcuts | Hide comment threads
Felix Arntz 11:05 pm on December 29, 2021

Enhanced lazy-loading performance in 5.9

Lazy-loading images was introduced in WordPress 5.5 and later expanded to also cover iframes in WordPress 5.7. In the upcoming WordPress 5.9 release, the implementation for both has received some fine tuning to improve performance.

A performance analysis from mid-2021 had discovered that the lazy-loading implementation from WordPress had been causing a slight performance regression in the Largest Contentful Paint metric (LCP). As outlined in the referenced post, the reason for that was that images and iframes in the initial viewport would be marked to lazy-load them, since the WordPress implementation would mark nearly all images with loading="lazy". The aforementioned post then further explains that this can be improved by skipping addition of loading="lazy" for the first content image or iframe, which in the vast majority of cases will appear within the initial viewport. WordPress can only make educated guesses around that and not be 100% certain, but an analysis taking into account 50 popular themes showed that the enhancement brought LCP improvements across the board, up to 30% faster page load. WordPress 5.9 now comes with this refinement implemented, leading to the corresponding enhanced LCP performance.

How it works

So far, fine tuning which images and iframes should be lazy-loaded or not has been possible using the wp_img_tag_add_loading_attr and wp_iframe_tag_add_loading_attr filters, and these are still available as before. However, to improve the performance out-of-the-box without requiring a developer to customize the behavior, WordPress will now skip the very first “content image or iframe” on the page from being lazy-loaded. The term “content image or iframe” here denotes any image or iframe that is found within content of any post in the current main query loop as well any featured image of such a post. This applies to both “singular” and “archive” content: In a “singular” context the first image or iframe of the (only) post is not lazy-loaded, while in an “archive” context the first image or iframe of the first post in the query is not lazy-loaded.

Customizing the behavior

The approach of not lazy-loading the first content image or iframe enhances LCP performance correctly for the majority of themes, which use a single-column layout for post content. For themes with alternative layouts such as multi-column, a new wp_omit_loading_attr_threshold filter is now available and can be used to change how many of the first images/iframes should be skipped from being lazy-loaded – per the above, the default is 1. It is recommended for theme authors to use this filter in cases where based on the layout it is likely to have more than one content image/iframe in the initial viewport.

For example, a theme that uses a three-column grid of posts in its archives could leverage the filter to override the threshold to 3 on archive pages, which would then result in the first three content images/iframes not being lazy-loaded. The following code snippet illustrates what that could look like:

1
2
3
4
5
6
7
function skip_lazyloading_on_first_three_archive_images( $omit_threshold ) {
    if ( is_home() || is_archive() ) {
        return 3;
    }
    return $omit_threshold;
}
add_filter( 'wp_omit_loading_attr_threshold', 'skip_lazyloading_on_first_three_archive_images' );

The refinement of the lazy-loading implementation should notably improve LCP performance for most sites that rely on it, while not having adverse effects for sites where the default heuristics described above do not apply to. That is only a solid starting point though. In the future, specifically with the more semantic content specification that block-based themes will facilitate, we will be able to further fine tune the lazy-loading implementation by using the available block information.

For more background information on the changes described above, see #53675.

Props to @adamsilverstein and @audrasjb for review and proofreading.

#5-9, #dev-notes, #feature-lazyloading, #performance

Jb Audras 10:45 pm on December 29, 2021

A Year in Core – 2021

Here’s some aggregate data for 2021 about WordPress Core contribution on Trac. Please note: it only include code contributions and it does not include contributions on GitHub repositories like Gutenberg.

The raw data for this post are on this public spreadsheet. You might find that easier to read if you have low vision or colorblindness; the graphics below are a snapshot pulled together to include as much information as possible in this blogpost.

General Trac overview

In 2021, the WordPress Core team shipped 1852 commits. 2797 tickets were opened, 2732 tickets were closed, and 408 were reopened.

Also, 2572 people contributed to WordPress source code using Trac, and 305 people made their very first contribution to WordPress Core ♥️

JanFebMarAprMayJunJulaugSepOctNovDecTotal
Commits6217511097142286174175103573271441852
Tickets closed236315372147182355248210157882711512732
Tickets reopened263345212537773622193136408
Tickets created2002803711771973202882971611261901902797
New contributors144314223537151218147110305
Contributors120229165117280400154132156905551742572
This chart can be scrolled horizontally

Check out the Trac timeline in the graph below:

Here’s how many props and new contributors the Core project had per month. The most prolific month was November, in the WordPress 5.9 beta cycle, followed by June (WP 5.8 beta cycle).

Components activity

How did 2021’s commits break out by Core Component?

The most prolific components were:

  • Build/Test Tools with 310 commits (17% of all listed commits)
  • Docs with 198 commits (11% of all listed commits)
  • Editor with 188 commits (10.5% of all listed commits)
  • Bundled Themes with 144 commits (8% of all listed commits)
  • Coding Standards with 140 commits (8% of all listed commits)
  • Then comes Media, REST API, Code Modernization, External Librairies, Administration, Upgrade/Install, Site Health and Posts/Post Types. The other components each had fewer than 30 commits this year.

Data fetched from WordPress.org profiles

The data below comes from matching contributors’ usernames, as mentioned in Trac props, with their profiles on WordPress.org. One caveat: usernames that did not match a profile on dotorg, or that left blank their country/company information, filled in non-exploitable info got ignored. After all, “The Universe” or “The place to be” are not known countries 😆

Contributions by country

The next graph shows the number of props received by country. The top eight countries, based on the number of props received, are these:

  • United States with 1142 contributions
  • France with 266 contributions
  • Russia with 227 contributions
  • The Netherlands with 225 contributions
  • India with 219 contributions
  • Australia with 211 contributions
  • United Kingdom with 112 contributions
  • Canada with 102 contributions

Contributors (people) by country

In 2021, people from more than 56 countries contributed to WordPress Core.

The top eight countries by contributions, expressed as the number of props received, are:

  • United States with 155 people
  • India with 58 people
  • United Kingdom with 34 people
  • France with 26 people
  • Germany with 23 people
  • The Netherlands with 20 people
  • Canada with 16 people
  • Australia with 15 people

Contributions by company

In 2021, people from at least 236 companies contributed to WP Core.

These companies each contributed (well, their people did) to more than 50 commits:

  • Automattic with 785 contributions
  • Yoast with 379 contributions
  • Whodunit with 215 contributions
  • Advies en zo with 191 contributions
  • Bluehost with 146 contributions
  • Human Made with 131 contributions
  • Google with 87 contributions
  • iThemes with 73 contributions
  • Dekode Interaktiv with 52 contributions

Contributors (people) by company

The graph below is also interesting, because it shows that a huge number of companies have only one contributor—or a very few contributors. The exceptions are Automattic, with 85 core contributors on Trac in 2021, Yoast (18 contributors) and 10up. Only those three companies had more than ten people credited on Trac in 2021.

What did 2021 hold for Core Committers?

33 Core Committers committed code to the WordPress SVN repository this year:

@sergeybiryukov (729), @desrosj (272), @hellofromtonya (159), @johnbillion (93), @peterwilsoncc (86), @ryelle (61), @audrasjb (59), @noisysocks (54), @joedolson (46), @gziolo (42), @timothyblynjacobs (38), @youknowriad (38), @davidbaumwald (31), @antpb (26), @whyisjake (20), @jorbin (19), @azaozz (18), @jorgefilipecosta (15), @johnjamesjacoby (13), @ocean90 (12), @clorith (10), @spacedmonkey (9), @adamsilverstein (8), @flixos90 (7), @jffng (6), @pento (6), @iandunn (5), @mikeschroder (4), @westonruter (4), @joemcgill (3), @rachelbaker (2), @isabel_brison (2), and @swissspidy (1).

Of the 1852 commits, 729 were made by people working at Yoast, 426 from employees of Automattic, and 272 came from Bluehost people:

Thanks to @marybaum for the copy review and to @flixos90 and @adamsilverstein for proofreading.

#contributions, #contributors, #team-update, #week-in-core, #year-in-core

Daniele Scasciafratte 11:46 am on December 30, 2021

Amazing!
There are similar data for 2020 and 2019? Just to see how the pandemic affected and time changed the contributions?

Another questions there are contributions by company that have committers but there are tons that don’t have committers but contribute too. I think that can interesting to see how much the company “not so much” involved contribute to WordPress.

Jb Audras 12:24 pm on December 30, 2021

Thank you @mte90!
As far as I know, this is the first time we published this type of post, so it’s hard to compare… 🤷‍♂️ but the data for other years are still available (it’s a fair load of work to put them together though) 🙂

Except for the last graph (committers), the company graphs are not only listing committers contribution but all contributors credited in commits (using “props”). So yes, everyone who helped on a ticket committed in 2021 is listed in this post. See the spreadsheet for more details and a full contributor list.

Daniele Scasciafratte 12:30 pm on December 30, 2021

Thanks I misunderstood contributors with committers 🙂

Fabian Kägy 1:19 pm on December 28, 2021

Take more control over Inner Block Areas (as a block developer)

Prior to WordPress 5.9 the only way to work with inner block was to use the <InnerBlocks /> component. One downside of this approach is that in the editor this creates additional DOM nodes that wrap the markup of the inner blocks. This makes it more difficult to style these inner blocks areas to match what the enduser will see on the site.

With WordPress 5.9 we’re introducing a new react hook called useInnerBlocksProps that allows you to change this and take more control over the markup of inner blocks areas. The useInnerBlocksProps is exported from the @wordpress/block-editor package same as the InnerBlocks component itself and supports everything the component does. It also works like the useBlockProps hook introduced with apiVersion: 2 in WordPress 5.6.

To use the hook, take the object returned from calling the hook and spread it onto the host element you want to render the inner blocks into. For example:

1
2
3
4
5
6
7
8
9
10
function BlockEdit(props) {
    const blockProps = useBlockProps();
    const innerBlocksProps = useInnerBlocksProps();
 
    return (
        <section {...blockProps}>
             <div {...innerBlocksProps} />
        </section>
    );
}

The above code will render to the following markup in the editor:

1
2
3
4
5
<section>
    <div>
        <!-- Inner Blocks get inserted here -->
    </div>
</section>

The hook also accepts two arguments:

  1. The first argument accepts an object containing additional props that are added to the element in the dom. For example, to add a custom class name to the inner blocks area you pass { className: 'my-class' } as the first argument.
  2. The second argument is also an object and can contain any properties to control the behavior of the inner blocks area. It accepts all options like allowedBlocks, template, templateLock, renderAppender, etc. You can find the full list of supported properties in the InnerBlocks props documentation
1
useInnerBlocksProps( additionalWrapperProps, innerBlocksProps );

Saving the inner blocks

To save inner blocks content there is a special variant of the hook, this is similar to the component-based approach that uses <InnerBlocks.Content /> in the save method of a block. For hooks, you add .save to the end of the hook like so:

1
2
3
4
5
6
7
function BlockSave( props ) {
    const innerBlocksProps = useInnerBlocksProps.save( { className: 'my-class' } );
 
    return (
        <section {...innerBlocksProps} ) />
    );
}

When you use the useInnerBlocksProps.save() hook it only accepts the first parameter, these are the options you want to add to the container element.

Why use hooks?

The hooks allow for new options and nice enhancements. For example, you can take the object returned from the useBlockProps hook—these contain the properties for the block’s wrapping container—and pass them to the useInnerBlocksProps hook. This reduces the number of elements we need to create. For example:

1
2
3
4
5
6
7
8
function BlockEdit(props) {
    const blockProps = useBlockProps();
    const innerBlocksProps = useInnerBlocksProps( blockProps );
 
    return (
        <section {...innerBlocksProps} />
    );
}
1
2
3
<section>
    <!-- Inner Blocks get inserted here -->
</section>

Another benefit to using the hook approach is using the returned value, which is just an object, and deconstruct to get the react children from the object. This property contains the actual child inner blocks thus we can place elements on the same level as our inner blocks.

1
2
3
4
5
6
7
8
9
10
11
function BlockEdit(props) {
    const blockProps = useBlockProps();
    const { children, ...innerBlocksProps } = useInnerBlocksProps( blockProps );
 
    return (
        <section {...innerBlocksProps}>
            { children }
            <!-- Insert any arbitrary html here at the same level as the children -->
        </section>
    );
}
1
2
3
4
<section>
    <!-- Inner Blocks get inserted here -→
    <!-- The custom html gets rendered on the same level -->
</section>

Example:

block.json

1
2
3
4
5
6
7
{
    "apiVersion": 2,
    "name": "example/block",
    "title": "Example",
    "category": "text",
    "editorScript": "file:./index.js"
}

index.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps, useInnerBlocksProps } from '@wordpress/block-editor';
 
import metadata from './block.json';
 
function BlockEdit(props) {
    const blockProps = useBlockProps( { className: 'my-class' } );
    const innerBlocksProps = useInnerBlocksProps(
        blockProps,
        { allowedBlocks: [ 'core/heading', 'core/paragraph', 'core/image' ] }
    );
 
    return (
        <section {...innerBlocksProps} />
    );
}
 
function BlockSave(props) {
    const blockProps = useBlockProps.save( { className: 'my-class' } );
    const innerBlocksProps = useInnerBlocksProps.save( blockProps );
 
    return <section {...innerBlocksProps} />
}
 
registerBlockType( metadata, {
    edit: BlockEdit,
    save: BlockSave,
} )

Thank you, @gziolo and @mkaz for reviewing and proofreading this post.

#5-9, #dev-notes

Tom J Nowell 1:47 pm on December 28, 2021

Glad to see this, one note though:

Another benefit to using the hook approach is using the returned value, which is just an object, and deconstruct to get the react children from the object. This property contains the actual child inner blocks thus we can place elements on the same level as our inner blocks.

Does this not trigger a long running block validation bug?

Fabian Kägy 2:24 pm on December 28, 2021

From what I can tell based on how some of the core blocks are using it here for example: http://wayback.fauppsala.se:80/wayback/20211230153847/https://github.com/WordPress/gutenberg/pull/26031#discussion_r735551782 that shouldn’t be an issue. Totally open to having missed something though.

Jb Audras 12:06 pm on December 28, 2021

A Week in Core – December 27, 2021

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between December 20 and December 27, 2021.

  • 28 commits
  • 45 contributors
  • 36 tickets created
  • 1 tickets reopened
  • 25 tickets closed

The Core team is currently working on the next major release, WordPress 5.9, and the beta 4 was released last week 🛠

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Administration

  • Add “File” to Theme/Plugin Editor menu names and relocate “Plugin File Editor” to Tools for block themes – #54382
  • Make sure the $customize_url variable is always defined in the admin menu – #54682

Application Passwords

  • Show HTTPS required message without filtering when not enabled or not in local environment – #53658

Build/Test Tools

  • Allow the PHPCS plugin in Composer configuration – #54686
  • Restore the https URL for browserify-aes – #54487
  • Separate the tests for recommended PHP and MySQL versions in readme.html – #41490

Bundled Themes

  • Twenty Twenty-Two: Sync updates from GitHub for Beta 4 – #54318

Coding Standards

Docs

  • Improve the @since 5.9.0 note for WP_Theme_JSON::PRESETS_METADATA – #53399

Docs

  • Typo correction in validate_file() comments – #53399
  • Typo correction in wp_dropdown_languages() DocBlock – #53399
  • Typo correction in wp_get_layout_style() introduced in 5.9 – #53399

Editor

  • Add edit_theme_options capabilities to wp_navigation post type – #54487
  • Add missing default template areas to the post/page editor settings – #54679
  • Add support for nameless font sizes in WP_Theme_JSON – #54640, #54487
  • Explicitly declare $post_types and $area properties in WP_Block_Template class – #54670
  • Update wordpress packages for Beta 4 – #54487

External Libraries

  • Update the SimplePie library to version 1.5.7 – #54659
  • Update the SimplePie library to version 1.5.8 – #54659

General

  • Fix 'rel' argument in Tests_Functions_wpListBookmarks test datasets – #53839

Login and Registration

  • Use secondary button style for the Language switcher – #54692
  • Add a filter to allow to disable the Login screen language dropdown – #54675

Plugins

  • Escape the WordPress.org plugin page URL in the Plugin Installation modal – #54362

REST API

  • Support . in theme directory names in WP_REST_Global_Styles_Controller, WP_REST_Templates_Controller, and WP_REST_Themes_Controller – #54596

Script Loader

  • Skip getting 'can_compress_scripts' option in script_concat_settings() during install – #54634

Toolbar

  • Show the Customize link on front end when using a block theme if any plugins use the Customizer – #54683

Props

Thanks to the 45 people who contributed to WordPress Core on Trac last week: @costdev (7), @hellofromTonya (8), @SergeyBiryukov (5), @audrasjb (5), @jrf (4), @johnbillion (3), @spacedmonkey (2), @schlessera (2), @david.binda (2), @pbiron (2), @ocean90 (2), @marybaum (1), @walbo (1), @youknowriad (1), @rickcurran (1), @TimothyBlynJacobs (1), @ntsekouras (1), @get_dave (1), @joyously (1), @bijayyadav (1), @kafleg (1), @felipeelia (1), @williampatton (1), @manfcarlo (1), @chintan1896 (1), @joen (1), @Mamaduka (1), @dimadin (1), @henry.wright (1), @aezazshekh (1), @rainbowgeek (1), @afragen (1), @sabernhardt (1), @faisal03 (1), @gziolo (1), @jameskoster (1), @poena (1), @annezazu (1), @clorith (1), @courane01 (1), @dryanpress (1), @desrosj (1), @Presskopp (1), @ipstenu (1), and @kjellr (1).

Congrats and welcome to our 5 new contributors of the week: @rickcurran, @bijayyadav, @manfcarlo, @aezazshekh, @rainbowgeek ♥️

Core committers: @sergeybiryukov (12), @hellofromtonya (8), @audrasjb (6), @isabel_brison (1), and @jffng (1).

#5-9, #core, #week-in-core

annezazu 8:29 pm on December 27, 2021

Editor Chat Agenda: 29 December 2021 (skipped)

This week’s meeting is being skipped due to anticipated low attendance at the end of year. Meetings will resume on January 5th, 2022. You’re encouraged to use this time to help test WordPress 5.9 Beta 4. For specific steps and areas to test, you can follow this post on how to test 5.9 features.

If you have anything you’d like to discuss or share asynchronously though, please share in the comments of this post. This includes the following:

  • If you have an update for the main site editing projects.
  • If you have anything to share for Task Coordination.
  • If you have anything you’d like to raise that typically would be discussed in the Open Floor section.

@paaljoachim and myself will follow up on any open ended questions or topics left on this thread.

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

sdwire 1:30 pm on December 28, 2021

I *think* this might belong here? I added a feature request / proposal I’d like people to be aware of.

Feature Request: Broad control over typography in Global Styles
http://wayback.fauppsala.se:80/wayback/20211230153847/https://github.com/WordPress/gutenberg/issues/37635

I realize many of those who aren’t still vacationing are still heads-down testing 5.9 and discussion on broad new proposals like mine may need to wait until there’s more available energy. Perhaps it can come up in the Jan 5 agenda?

annezazu 3:26 pm on December 28, 2021

Hey @sdwire! This definitely belongs here. I think this is wise to bring up on the Jan 5th agenda. For now though, I’ll add some labels and tag some folks in who might be able to give some context/chime in. Thanks for your work there in laying out your idea so clearly.

Ajit Bohra 3:59 pm on December 27, 2021

Editor chat summary: Wednesday, 22 December 2021

This post summarizes the latest weekly Editor meeting (agenda, slack transcript), held in the #core-editor Slack channel, on Wednesday, December 22, 2021, 14:00 UTC.

General Updates

Updates on the key projects

Mobile

@hypest

Shipped

Functionality to customize color for selected words (GSS related).

Fixes

  • Heading block newline when splitting issue.
  • Bottomsheet back-button navigation issue.

In Progress

  • Upgrade to React Native v0.66.
  • Finalizing GSS Font size and line height.
  • Improving reliability of the mobile translations pipeline.

No other project updates at this time.

Task Coordination

@mkaz

A few bits on documentation:

  • In PR 37348 docs were refactored to use JSX/Plain as the toggles for code examples. We don’t need to limit examples to ES5 anymore, so this makes it clearer the difference. Documentation contributor guide was also updated for guidance.
  • PR 36183 adds generated core block documentation from the block.json files. Published here. The item to note is if you change a block.json in a core block, you will need to run npm run docs:build. Your failing commit will tell you have a local change.
  • Take a look at WP 5.9 project board for docs and dev notes, I’m reached out to those listed. We have a goal of getting notes published before RC1, but with late fixes and holidays we won’t have them all. So, if you have any to write, try to make it a priority when you return in the new year.

@mamaduka

  • I’ve been working on WP 5.9 bug fixes for Site Editor and Template Mode.
  • Fixed embed handing in Reusable Blocks.
  • Plus removed a lot of unused code from Site Editor.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

Open Floor

@priethor

  • Congratulating first-time contributors for joining efforts during the 12.2 release cycle:
  • Kudos to @mikachan for becoming a member of the Gutenberg team

@fabiankaegy

  1. I’d love to get some eyes on this Dev Note I drafted here as I am not sure what the correct process for.
  2. I’d love to share discussion on ‘opening the editor interface to more extensibility‘ here and get some opinions on the topic.

Read complete transcript

#meeting-notes, #core-editor, #editor, #gutenberg, #core-editor-summary

Sergey Biryukov 2:09 am on December 25, 2021

Updater initiative status report: December 25, 2021

During 2021, a group of contributors worked to update the WordPress updaters and add some features to make auto-updates safer and dependencies more reliable.

The expected outcomes were outlined in this post in May 2021.

Outcomes 1 and 2 – Make sure the zips download and unpacking are safe and create a mechanism to rollback plugin & theme updates in case of failure

The two goals were solved with one solution, which was merged in Core in September. However, due to some failures on the Chassis/Vagrant development environment, the feature, along with other related tickets, was reverted during WordPress 5.9 Beta period.

Next steps

For the feature ready to be shipped with WordPress 6.0, the discovered issue with Chassic/Vagrant should be resolved. Outreach to hosting companies needs to be done to ensure production environments will behave as expected.

Help required – Hosting companies

Would it be possible to get a hosting company to set up different environments to test the patch in multiple scenarios? Including testing on shared servers from hosting providers who aggressively throttle resources.

Outcome 3 – Have managed updates (database migrations)

@aristath did a first exploration, but nothing substantial was presented to the other contributors yet.

Next steps

Evaluate if this is beneficial for plugin developers and create user stories before writing code, to make sure the solution addresses a specific, shared problem.

Outcome 4 – Create a unified JSON convention for requirements and dependencies

After a lot of conversations, the contributors moved away from a JSON file in favor of a “Requires Plugins” header based on feedback to this PR. Then, they focused on admin UI improvements using that header to solve what appears to be the most common use case: protect the user from fatal errors when installing a plugin without the required dependencies and guide them to complete the installation.

Looking back at the conversations (Trac and Slack) it looks like there is not enough clarity on the best possible method to solve the user issue, or what “dependencies” mean (soft vs. hard dependencies).

For plugin developers, the main issue is to avoid different plugins introducing implementations to check for the existence of dependencies and take appropriate actions. This is, in fact, something that is already happening. The problem is solved by each plugin developer. Would it be possible to solve it with a unified convention?

For end-users, the issue is with add-ons. For them to work, they need another plugin to be activated. If plugin and theme developers don’t properly check for the existence of plugins before using them, there is a risk of getting fatal errors on the user site.

Next steps

@peterwilsoncc suggested proposing a feature project. Right now, there is a Google Document with some notes about the solutions but the problem and the why are missing. This project is not tied to a release right now since it is still in the discovery phase.

  • Evaluate the problem from the point of view of plugin developers. Is it beneficial to have a unified solution for Core or does it not make a difference? Help from the plugin team and plugin authors is needed.
  • Write the user stories from the end-of-user point of view.
  • Write a proposal for a feature project with the findings from the two explorations.

Do you want to help?

If you want to help, please join the #core-auto-updates chats, Tuesdays at 5PM UTC in 2022.

Thanks!

Thank you @francina and @aristath for the peer review.

Andy Fragen 3:05 am on December 25, 2021

Thanks @sergeybiryukov. I’ve added some background to the problem and the why in the Google doc.

It would be nice to get more input so that we can move forward with a feature project post.

webcommsat AbhaNonStopNewsUK 9:39 pm on December 22, 2021

Dev Chat summary: December 22, 2021

Dev Chat agenda.

The meeting was led by @webcommsat and @marybaum.

Start of the Dev Chat meeting in the Make WordPress core slack.

You can find last week’s notes in at Dev chat summary, December 15, 2021.

Announcements

Please join the discussion @chanthaboune has started on 2022 release planning.

WordPress 5.9 release updates

The WordPress 5.9 Beta 4 has landed. Please download and test! Thanks to everyone who has been involved in the release so far and getting the Beta 4 out the door.

Beta 4 fixes 20 bugs that surfaced in Beta 3. Please test them and report your findings on the announcement post.

It does not look like a Beta 5 will be necessary at this stage. RC1 is scheduled for January 4, 2022. The revised 5.9 release schedule.

If there are no big issues, the release will continue to follow the plan from November 22, 2021 – more details on the 5.9 post.

Blog posts to note

What’s new in Gutenberg 12.2? (December 22, 2021)

A Week in Core. Three new contributors to core this week – welcome to them all.
The next New Contributor Meeting for core is scheduled for 12 January 2022 at 19:00 UTC. If you have any questions on contributing to core before that, just bring them up here in #core any time outside of any ongoing meeting, or in the open floor section of the weekly dev chat, and someone should follow up.

Please continue to share the Help test WordPress 5.9 features. This replaces the ongoing call for FSE testing promotions until after 5.9 is released. Thanks @annezazu

WordPress 5.9 is now available for translation. The new theme with this release, Twenty Twenty-Two, can also be translated. Thanks to all the polyglots across the world who have started working on translating the next release.

The annual community survey closes next week on December 30, 2021. Still time to complete it.

Component Maintainers update

Build/Test Tools Component

Update via @sergeybiryukov: Some enhancements were made to the unit test suite:

  • Reduce the use of unnecessary randomness in tests to increase the overall reliability of the tests. See ticket #37371 for more details.
  • Remove an assertion in filter_rest_url_for_leading_slash(). This assertion could mask the fact that some other tests don’t perform an assertion. See ticket #54661 for more details.

Thanks @johnbillion and @johnillo, a new contributor! 

Date/Time, General, I18N, Permalinks

Update via @sergeybiryukov: No major news this week.

Quick/Bulk Edit component

Update from @nalininonstopnewsuk: For the Quick/ Bulk Edit component, we are continuing to work through and reading all the previous materials in the background while the primary focus is on 5.9. We want to run a bug scrub on the tickets the week after 5.9 is out. 

About / Help page component

Update via @webcommsat: More updates have been done this week on the text and Figma. Will update the ticket today.

You can also join the collaborations cross-team on social media posts on the release features.

Open Floor

  1. Proposal for an enhancement ticket. 

@maksimkuzmin  would like some comments on this message in Slack before Jan, 12?

Will raise a ticket and provide a UI draft. Design input suggested.

Discussion suggested moving the ticket to 6.0.

2. Request to add thoughts on the Performance Team GitHub Issues and Projects. 

@Sergio Scabuzzo from the measurement group in the team encouraged contributors to look at the ideas. http://wayback.fauppsala.se:80/wayback/20211230153847/https://github.com/WordPress/performance/projects

3. A second enhancement proposal

@maksimkuzmin suggested: Most of the times bespoke themes built relying on page templates to set up specific page to the specific type of page. E.g. Search Page is bound to the page-search.php template in the code. The major lack of functionality is to have a function that will quickly retrieve page(s) by the given template name. Without building a WP Query, etc. Sort of get_page_by_template( $template_file ).

This enhancement will further be discussed and potentially reconsidered in a pre-existing ticket: #16264.

4. Bug report potentially related to 5.9

@afragen: FYI, posted bug report and PR for #54682, believed to be 5.9 related.

Next meeting

Dev Chat will take place next week, Wednesday 29 December 2021 at 20:00 UTC in the Make WordPress Core Slack for a quick check-in.

Props: Dev Chat summary by @webcommsat. Thanks to @marybaum and @sergey for proofing.

#5-9, #dev-chat, #summary

Anton Vlasenko 8:16 pm on December 22, 2021

What’s new in Gutenberg 12.2? (22 December)

“What’s new in Gutenberg…” posts (labeled with the #gutenberg-new tag) are published following every Gutenberg release on a biweekly basis, discovering new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project.

If you observe the Gregorian Calendar, New Year’s Eve is fast approaching, which means that the time has come for the next release of Gutenberg!

Gutenberg 12.2 has just been released! It’s the last minor Gutenberg release in 2021. This release improves compatibility with the upcoming WordPress 5.9 release and block themes. Also, it brings new features, code quality improvements, and bug fixes. You can find the release highlights below.

Table of contents

Seamless navigation between the Site Editor and the Template List

Gutenberg 12.2 takes the Template List one step beyond, improving its user experience and performance. Thanks to its new client-side routing, WordPress doesn’t need to reload the page when navigating between the Site Editor and the Template List, reducing the time spent rendering unneeded HTML code.

Improvements to post comments

Starting with Gutenberg 12.2, the Comments Query Loop block is now able to display nested comments. This improves user experience as it is now much easier to understand if a comment responds to another comment or is just a first-level comment.

Also, the new Comments Pagination Numbers block allows displaying page numbers inside the Comments Pagination block, which in turn can be used inside the Comments Query Loop block. This improves the UI because users can quickly navigate the comments using the page number.
Also, the pagination in the Comments Query Loop block now works similar to the pagination for posts.

A new home for border controls

Although lots of blocks are already taking advantage of border supports, this release switches border supports to the ToolsPanel, and sets which border properties are displayed in the ToolsPanel by default. The ToolsPanel, first introduced in Gutenberg 11.3, offers progressive discovery options for those provided through block supports, improving the user experience and consolidating the sidebar UI.

New font size labels in the FontSizePicker component

Gutenberg 12.2 improves the way font sizes are displayed in the sidebar by using a sequence of numbers (1, 2, 3, 4, 5) as labels for the font sizes. These simplified labels can accommodate use cases with complex CSS values, helping users understand the available font sizes.

Improved color picker

More components are being iterated in this release. In an effort to reduce sidebar clutter and improve the design tools user experience, all blocks, including those that use custom color implementation, can now take advantage of the new dropdown-based color picker. This improved UI is easier to use, especially when editing a few colors back-to-back.

Preview for Block Styles in the Widget Editor

While Gutenberg 12.0 introduced block styles preview on hover for the Block Editor, this release brings this functionality to the Widgets Editor, too. It’s now possible to preview style variations in the Widgets Editor when editing blocks that support this (e.g., Image, Table, Button blocks) by hovering or focusing over the style name, for full accessibility support.

Changelog

Enhancements

Block Library

  • New block: Add Comments Pagination Numbers block. (36890)
  • Comment Template block: Handle nested comments. (36065)
  • Comments Query Loop: Improve context handling in inner blocks. (37196)
  • Image: Reflect media deletion in the editor. (35973)
  • Navigation:
  • Add navigation blocks post-processing after migration from menu items. (36950)
  • Refactor modal padding to be simpler and more flexible. (37323)
  • Remove Navigation Menus from the Appearance menu. (37212)
  • Add clearance for appender in submenus. (36720)
  • Refactor handling of padding for group and column blocks. (37356)
  • Template Part: Add actions that fire during the loading process of block template parts. (36884)

Styles and design tools

  • Add the Welcome Guide option to the More Global Styles Actions dropdown. (37180)
  • Make the Blocks section more distinguishable. (37293)
  • Move the Edit colors button to a standard menu item. (36842)
  • Move Duotone palette to the bottom of global styles gradients. (37253)
  • Border controls: display border properties in the ToolPanel. (34061)

Components

  • FontSizePicker: Use an incremental sequence of numbers as labels for the available font sizes at the segmented control (conditionally). (37038)
  • ColorPalette: Improve accessibility and visibility. (36925)
  • ToolsPanel: Standardize input control label margin. (36387)
  • Unify styles for ColorIndicator with how they appear in Global Styles. (37028)
  • Update PanelColorGradientSettings component to use dropdowns. (37067)

Site Editor

  • Add the Customizer back to the Appearance menu. (37175)
  • Add client-side routing for Site Editor. (36488)
  • Add a new aria-pressed attribute to the Toggle navigation button. (37351)
  • Template revert flow: Make label description source agnostic. (37004)

Packages

  • Scripts: Enable React Fast Refresh for block development. (28273)
  • List Reusable Blocks: Refactor ImportForm into a functional component and use hooks. (36938)

Widgets Editor

  • Implement preview for blocks. (37012)

Post Editor

  • Template Part block should not be available in the Post Editor inserter. (37157)

Bug Fixes

  • Remove 4 instances of gutenberg text-domain from Core. (37229)

Block Library

  • Fix return type in the DocBlock. (37352)
  • Fix deprecated usage of passing null to explode function. (37392)
  • Gallery:
  • Fix color issue for captions with hyperlinks in the Gallery block. (37033)
  • Fix documentation and function naming for gallery block registration in PHP. (37132)
  • Remove placeholder border. (37050)
  • Post Comments:
  • Fix form-submit styles by adding button classes to the submit button in the post-comments block. (37245)
  • Fix width of the post comment form input. (37238)
  • Use block markup for the comment form button when using a block theme. (37315)
  • Comments Pagination Block: Add default styling. (37057)
  • Image:
  • Set image display mode to grid when no alignment is set to align caption onresize event properly. (35787)
  • Fix resizer controls being hidden in Safari when switching between alignments. (37210)
  • Navigation:
  • Fix gutenberg_ prefixed function references in Core. (37021)
  • Fix navigation justifications. (36991)
  • Fix vertical alignment of page list in the modal. (37321)
  • Remove hardcoded typography units. (37349)
  • Fix vertical layout. (37009)
  • Switch to addEventListener event for load event in the navigation block view script. (37135)
  • Don’t request the deprecated navigation areas endpoint outside of the Gutenberg plugin. (37187)
  • Navigation Link Control: Hide the Transforms component when no options are available. (37284)
  • Remove the deprecated navigation area block from the inserter. (37026)
  • Query Loop: Add useBlockPreview component, fix alignment of the Query Loop block in the editor. (36431)
  • Query Pagination: core/query-pagination-next and core/query-pagination-previous blocks: change the markup on the first and last pages of the pagination. (36681)
  • Search: Fix application of border color class in the editor. (37242)
  • Template Part:
  • Fix isMissing condition check. (37370)
  • Use Core version of template and template part post types and REST endpoints for WordPress 5.9, with backward compatibility for WordPress 5.8. (36898)
  • Update the micromodal package to include a click-through fix. (36837)

Components

  • Card: Support the extraSmall option for the size prop. (37097)
  • Drop Zone: Fix HTML drop issues with the Windows browsers. (37151)
  • Don’t load Radio and RadioGroup components directly. (36934)
  • DuotonePicker typo fix. (36662)
  • Element: Ensure that the package uses the up-to-date React types. (37365)
  • Fix incorrect rendering of ToggleGroupControl‘s active state. (37332)
  • Hide the remove control point button because removing it would break gradient control. (37186)
  • Import experimental Heading and Text Components. (37290)
  • Make the color popover on the gradient picker appear as expected. (37115)
  • Remove unused reakit-utils dependency from peer dependencies. (37369)
  • Storybook: Fix deprecated disabled key. (37112)
  • ToggleGroupControl: Fix extra update on incoming change. (37224)

Site Editor

  • Allow global styles sidebar panels to fill vertical space. (36845)
  • Display a notice if export fails. (37131)
  • Fix edit template part link in header dropdown. (37249)
  • Fix template resolution to give precedence to PHP templates defined in a child theme. (37074)
  • Hide the block appender in the Template Part editor. (37213)
  • Improve notification when saving content in the Site Editor. (36897)
  • Improve handling of parsed requests. (37209)
  • Sync Export API error codes. (37347)
  • Template Editor Mode: Hide editor mode switcher. (37359)
  • Use server definition for the Template Areas. (37215)
  • Fix the white screen of death on the Templates page when user avatars are disabled. (37458)

Styles

  • Allow selector ordering to ensure theme.json root selector margin takes precedence. (36960)
  • Custom keys from theme.json: Fix kebabCase conversion. (37380)
  • Do not remove theme presets if defaults are hidden. (37008)
  • Fix CSS Custom Properties for presets in the Site Editor. (36851)
  • Fix how appearanceTools works. (37254)
  • Fix styles for previews and patterns. (37296)
  • Font sizes: Update default values. (37381)
  • Remove CSS that causes conflict with theme.json. (36424)

Design Tools

  • Border Style Control: Update styling for consistency with border width control. (37244)
  • Border panel:
  • Don’t restore deselected border color when width gets changed. (37049)
  • Update the value of the ColorPicker component when color is cleared. (37048)
  • Gradients
  • Fix clearing a custom gradient from throwing a React warning. (37051)
  • Enable adding custom gradient when gradients are disabled. (36900)

Compatibility with Core and library code

  • Fix array key warning in block supports layout. (37101)
  • Templates: Search for old template names in the parent theme too. (36910)
  • Fix theme requirement validation when using WordPress 5.8. (37226)
  • Fix WordPress 5.9 check for conditionally running code. (37235)
  • Fix mistake in the_remove_theme_attribute_in_block_template_content function. (37137)
  • Gallery: Enable the new gallery block by default if running in Core. (37134)

Packages

  • Core Data: Fix returning empty array in the getEntityRecords function for unknown entities. (36984)
  • Include @babel/core as a dependency where applicable. (37328)
  • Format library: Fix unsetting highlight color. (37062)

Block Editor

  • Mark the last change as persistent on save. (36887)
  • Fix content loss when ungrouping template parts or reusable blocks. (37280)
  • Simplify the RESET_BLOCK action to fix the loss of content when using template part focus mode. (37283)

Post Editor

  • Multi-Entity Saving: Decode HTML entities in item titles. (37353)

Documentation

  • Update documentation related to schemas. (37294)
  • Remove versioning in theme schema descriptions. (37165)
  • Fix the broken link on the plugin description page. (37362)
  • Handbook:
  • Add information about skip links to the block theme overview. (36555)
  • Add closing ticks for blockGap code example. (37338)
  • Add how-to guide documentation template. (36694)
  • Add link and details for npx in create block tutorial. (37376)
  • Consolidate React Native documentation. (36685)
  • Fix a link to the how-to guide template. (37191)
  • Move classes used in the navigation block from the component to the new readme. (37375)
  • Update Format API how-to guide. (37298)
  • Update broken links. (37121)
  • Improve formatting of headings in the contributors’ guide. (36689)
  • Fix type for prefix transformation. (36362)
  • Fix broken links in the Resources section. (37307)
  • Remove the semicolons from the JSON examples. (37129)
  • Packages:
  • Block Editor:
    • Add a documentation note about inner blocks and excerpts. (36405)
    • Update example of usage for suggestionsQuery component. (37281)
  • Componentes:
    • Add missing changelog entries. (37384)
    • Fix code formatting for card components. (37268)
    • Fix importing from the wrong package. (37192)
    • Fix missing link for shortcut documentation. (36800)
    • Update QueryControls README.md. (37233)
  • Site Editor: Update support documentation URL in the Welcome Guide. (37176)

Code Quality

Compatibility with Core

  • Better synchronization between Gutenberg and Core code. (37141)
  • Move WordPress 5.9 wp-admin menus compatibility code to lib/compat folder. (37257)
  • Move the block page templates hook into compat/5.9 folder. (37142)
  • Move template loader hooks and functions into lib/compat folder. (37149)
  • Synchronize wp_is_block_theme function and block-templates block support with Core. (37218)

Global Styles

  • Do not register Global Styles custom post type in WordPress 5.9. (37282)
  • Port Global Styles code to lib/compat/wordpress-5.9:
  • CSS custom properties. (37334)
  • Front assets. (37335)
  • Rename WP_Theme_JSON_Resolver methods to make them compatible with Core. (37393)

Packages

  • Dependency Extraction Webpack Plugin: Sort externalized dependencies report. (37377)
  • Block Editor:
  • Iframe component: Use block settings to pass assets. (37193)
  • Remove duplicate block styles. (37133)
  • Specify the WordPress versions where API is deprecated. (37150)
  • Components
  • Refactor DatePicker into a functional component. (36835)
  • Storybook: Update to version 6.4. (37367)
  • Data
  • Ensure that redux is listed as a dependency. (37364)
  • wordpress/data: Refactor use-select component in preparation for adding types. (37017)
  • Scripts: Update dependencies shared with other WordPress packages. (37395)

Site Editor

  • Remove unused PHP code. (36997)
  • Revert Site Editor: Set the on the list page to be the same as the CPT name. (37270)

Block Library

  • Remove gutenberg_ prefix from @wordpress/block-library. (37341)
  • Block Library: Rename Query Pagination blocks. (37091)

Tools

Testing

  • End-to-end Tests:
  • Increase delay in image block end-to-end test to fix intermittent failure when clearing URL field. (37136)
  • Update Multi-Entity Saving test to improve reliability. (37139)
  • Sanitize flaky test report file names. (37390)
  • Retry login again after a bad nonce request to prevent intermittent test failures. (37219)
  • Fix Multi-entity saving and Template parts related tests. (37333)
  • Fix Heading test. (37382)
  • Re-enable most of the navigation block end-to-end tests. (37214)
  • Use global transients for PHPUnit tests. (37122)
  • Fix usage of useSetting('color.palette'). (37108)
  • Add tests for the new gallery hooks. (36801)

Linting

  • ESLint:
  • Add support for ESLint v8. (36283)
  • Fix Babel config resolution when a custom ESLint config is present. (37406)

Build Tooling

  • Specify PHP version in Composer. (37007)
  • Remove unused jest-serializer-enzyme dependency. (37373)
  • Remove some labels from the Experiments section of the changelog. (37098)
  • npm:
  • Fix package dependencies issues discovered with pnpm. (37396)
  • Use the latest minor version of webpack in Gutenberg. (37371)
  • Fix build failure on Windows. (37189)

Performance benchmark

VersionTime to render first blockKeypress event (typing)
Gutenberg 12.25.672 s42.38 ms
Gutenberg 12.15.484 s37.17 ms
WordPress 5.85.807 s46.5 ms

Thank you, @priethor, for coordinating the release process, proofreading, and helping to select release highlights!
Thank you, @jameskoster and @joen for helping me to prepare visual assets and proofreading the release post!
Thank you, @mamaduka, for uploading the plugin to WordPress.org!
Kudos to all the other contributors who have helped to make this release possible.

#block-editor, #core-editor, #gutenberg, #gutenberg-new

marybaum 5:14 pm on December 22, 2021

Dev Chat agenda for 22 December 2021

Announcements

The WordPress 5.9 Beta 4 has landed. Please download and test! 

Blog posts of note

Beta 4 fixes 20 bugs that surfaced in Beta 3. Please test them and report your findings on the announcement post.

What’s new in Gutenberg 12.2?

@audrasjb has the latest issue of A Week in Core.

Here is the revised release schedule.

And please join the discussion @chanthaboune has started on 2022 release planning.

Got other posts that should get the Core team’s attention? Please add them in the comments.

Upcoming releases

The current upcoming major release is version 5.9.

RC1 is set to release on 4th January and means two things:

Hard string freeze, including all the strings for the About page.

And Trunk branches to 6.0 alpha, so if you have a feature you’d like to see in the next major version, this is the time to start on it!

Component Maintainers

From now until launch, devchat will skip a formal check-in so the group can have a longer Open Floor. If you’re a maintainer who’d like to get help with a blocker or share success, add your item to the comments.

Open Floor

Add your topic to the comments, and enjoy priority for your topic at the beginning of Open Floor.

See you Wednesday at 20:00 UTC!

#agenda, #core, #dev-chat

#agenda, #dev-chat

#agenda, #core, #dev-chat, #week-in-core