Title: 2021 – Page 46 – Make WordPress Core

---

#  Yearly Archives: 2021

 [  ](https://profiles.wordpress.org/annezazu/) [annezazu](https://profiles.wordpress.org/annezazu/)
10:17 pm _on_ March 23, 2021     
Tags: [core-editor ( 757 )](https://make.wordpress.org/core/tag/core-editor/),
[core-editor-improvement ( 35 )](https://make.wordpress.org/core/tag/core-editor-improvement/),
[gutenberg ( 547 )](https://make.wordpress.org/core/tag/gutenberg/), [performance ( 414 )](https://make.wordpress.org/core/tag/performance/)

# 󠀁[Core Editor Improvement: Performance Matters](https://make.wordpress.org/core/2021/03/23/core-editor-improvement-performance-matters/)󠁿

_Thank you to [@aristath](https://profiles.wordpress.org/aristath/) [@youknowriad](https://profiles.wordpress.org/youknowriad/)
and [@priethor](https://profiles.wordpress.org/priethor/) who helped with this post._

In case you missed the first post on post/page performance, I’d [recommend checking it out first](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/)
before digging into this post, as it helps give greater context into the breadth
of work around performance improvements. This post builds on the discussion by talking
specifically about the approach Core ContributorsCore Contributors Core contributors
are those who have worked on a release of WordPress, by creating the functions or
finding and patching bugs. These contributions are done through Trac. [https://core.trac.wordpress.org](https://core.trac.wordpress.org)
take to managing the performance of the CoreCore Core is the set of software required
to run WordPress. The Core Development Team builds WordPress. Editor itself!

Think of Core Editor Performance as impacting the user experience when creating 
content. It’s the difference between a jarring experience, with the editor barely
keeping up as you type, and a creative one — where adding dynamic content is a breeze
with performance hardly being noticeable. 

With each release of GutenbergGutenberg The Gutenberg project is the new Editor 
Interface for WordPress. The editor improves the process and experience of creating
new content, making writing rich content much simpler. It uses ‘blocks’ to add richness
rather than shortcodes, custom HTML etc. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/),
a performance benchmark is run against the last few releases that compares different
response times for a large post (~36,000 words, ~1,000 blocks). You can find this
benchmark at the bottom of each [“What’s New in Gutenberg” post](https://make.wordpress.org/core/tag/gutenberg-new/).
While this approach doesn’t cover every scenario, and absolute numbers are not intrinsically
meaningful, it has helped identify variations in performance for different releases.
Generally speaking, while the loading time of the editor is important, pay special
attention to typing speed (also known as KeyPress Event speed). This is a far more
important measure when it comes to user experience as this is what allows for the
smooth experience when working in the editor. 

Beyond an overview of neat numbers, what does focusing on Core Editor Performance
entail? [Pulling from the documentation](https://developer.wordpress.org/block-editor/explanations/architecture/performance/),
the following overall metrics are tracked:

 * Loading Time: The time it takes to load an editor page.
 * Typing Time: The time it takes for the browser to respond while typing on the
   editor.
 * 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. Selection Time: The time it takes for the browser to respond
   after a user selects a block. (Inserting a block is also equivalent to selecting
   a block. Monitoring the selection is sufficient to cover both metrics).

Specifically, this work includes everything from improving [how performance benchmarks are measured for PRs](https://github.com/WordPress/gutenberg/pull/28419)
to [smoothing out the experience of using the Block Inserter](https://github.com/WordPress/gutenberg/pull/26348)
to [continually tweaking block interactions](https://github.com/WordPress/gutenberg/pull/25974)
to [improving consistency in performance benchmarks](https://github.com/WordPress/gutenberg/issues/28432).
At the end of the day, Core developers take a comprehensive approach when working
to meet or exceed these performance benchmarks while improving the user experience
for all WordPress users. You can read more about the [journey towards a performant web editor in this very informative post](https://riad.blog/2020/02/14/a-journey-towards-a-performant-web-editor/)
from WordPress Contributor, [@youknowriad](https://profiles.wordpress.org/youknowriad/).

The work on performance is never done though ([just check this PR out](https://github.com/WordPress/gutenberg/issues/30021))
so, if you’re interested in helping in this area, make sure to join [#core-editor](https://wordpress.slack.com/archives/C02QB2JS7),
check out the [current focuses](https://make.wordpress.org/core/tag/gutenberg-next/),
and attend the [Core Editor weekly meeting Wednesday @ 14:00 UTC](https://make.wordpress.org/core/tag/core-editor-agenda/).

[#core-editor](https://make.wordpress.org/core/tag/core-editor/), [#core-editor-improvement](https://make.wordpress.org/core/tag/core-editor-improvement/),
[#gutenberg](https://make.wordpress.org/core/tag/gutenberg/), [#performance](https://make.wordpress.org/core/tag/performance/)

 [  ](https://profiles.wordpress.org/francina/) [Francesca Marano](https://profiles.wordpress.org/francina/)
7:23 pm _on_ March 23, 2021     
Tags: [5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/),
[5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [agenda ( 1,142 )](https://make.wordpress.org/core/tag/agenda/),
[dev chat ( 922 )](https://make.wordpress.org/core/tag/dev-chat/)   

# 󠀁[Dev Chat Agenda for March 24, 2021](https://make.wordpress.org/core/2021/03/23/dev-chat-agenda-for-march-24-2021/)󠁿

Here is the agenda for this week’s meetings to occur at the following times: [March 24, 2021 at 5:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210324T0500)
and [March 24, 2021 at 20:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210324T2000).

## Announcements

 * [WordPress 5.7.1 maintenance release schedule](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-schedule/)

## Blogblog (versus network, site) Post Highlights

 * [[[A Week in Core – March 22, 2021](https://make.wordpress.org/core/2021/03/22/a-week-in-core-march-22-2021/)
 * [What’s new in Gutenberg 10.2? (17 March)](https://make.wordpress.org/core/2021/03/17/whats-new-in-gutenberg-10-2-17-march/)

## Blog posts that need feedback

 * [[[Gallery Block Update – Call for Testing](https://make.wordpress.org/core/2021/03/23/gallery-block-update-call-for-testing/)
 * [Proposal: Native TypeScript support in Gutenberg](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/)

## Components check-in and status updates

 * Check-in with each component for status updates.
 * Poll for components that need assistance.

## Open Floor

Do you have something to propose for the agenda, or a specific item relevant to 
our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group
can either give you the floor or bring up your topic for you, accordingly.

This meeting happens in the [#core](https://wordpress.slack.com/messages/C02RQBWTW)
channel. To join the meeting, you’ll need an account on the [Making WordPress Slack](https://make.wordpress.org/chat/).

[#5-7-1](https://make.wordpress.org/core/tag/5-7-1/), [#5-8](https://make.wordpress.org/core/tag/5-8/),
[#agenda](https://make.wordpress.org/core/tag/agenda/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/)

 [  ](https://profiles.wordpress.org/glendaviesnz/) [Glen Davies](https://profiles.wordpress.org/glendaviesnz/)
4:41 am _on_ March 23, 2021      

# 󠀁[Gallery Block Update – Call for Testing](https://make.wordpress.org/core/2021/03/23/gallery-block-update-call-for-testing/)󠁿

A[ refactor of the core Gallery Block](https://github.com/WordPress/gutenberg/pull/25940)
has been worked on over the last couple of months which will move it from a list
of image tags within 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. content to nested Image blocks using [InnerBlocks](https://developer.wordpress.org/block-editor/tutorials/block-tutorial/nested-blocks-inner-blocks/).
The hope is this change will make things easier for both users and developers.

![](https://glendaviesnz.files.wordpress.com/2021/03/gallery-refactor.gif)

## **Why the change?**

The fundamental reason for this change is to make images behave the same in the 
editor whether they are used as single blocks or as part of a gallery. For example,
for users, this update means that Gallery images would automatically have the ability
to add custom links for each image! It’s also easy now to replace a single image
directly. Other benefits include being able to use the standard move, drag and drop,
copy, duplicate, and remove block functionalities. Keyboard navigation also benefits
from the standard block model.

There have been open issues related to this inconsistency for some time:

 * [https://github.com/WordPress/gutenberg/issues/11436](https://github.com/WordPress/gutenberg/issues/11436)
 * [https://github.com/WordPress/gutenberg/issues/10057](https://github.com/WordPress/gutenberg/issues/10057)

To get around this inconsistency, 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/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. developers often have to duplicate
all of the Image block functionality in custom Gallery block plugins. Tied to this,
plugins that extend the image block haven’t been able to benefit galleries directly.
With this change making image behaviour more consistent between stand-alone images
and those within the gallery, more custom gallery functionality can be implemented
as Block Styles or Block Variations of the coreCore Core is the set of software 
required to run WordPress. The Core Development Team builds WordPress. Gallery block
instead of creating a completely new gallery block.

With each image being a block, server operations are also much more straightforward
since you can get the image IDs directly.

## **In depth testing needed**

While the expectation is nothing changes in terms of output for the end-user, this
is a pretty major change on a technical level for a very popular block, including
a change in the underlying markup to align it with the [W3C WAI guidelines on the grouping of images](https://www.w3.org/WAI/tutorials/images/groups/),
so it’d be a huge help to gather as much testing feedback as possible.

## **Accessing the new Gallery Block**

To test the new Gallery block, you can either checkout the [Gallery refactor PR branch](https://github.com/WordPress/gutenberg/pull/25940)
and test in a local dev environment, or you can download the [Gallery refactor plugin build](https://glendaviesnz.files.wordpress.com/2021/03/gutenberg-gallery-refactor-1.zip)
and install it on any WordPress test site. Once installed you need to enable the
experimental setting ‘Enable the refactored gallery block’:

![](https://glendaviesnz.files.wordpress.com/2021/03/experimental.png)

Only new gallery blocks added after the experimental flag is turned on will be in
the new format, all existing galleries will be editable and viewable in the current
format. You can manually transform an old format gallery to the new format using
the block transform menu and choose the ‘Gallery’ option.

**Important note — only run the Gallery refactor experimental feature on test data**

Although any existing gallery saved content should be unaffected, if you transform
these to the new format, or add new gallery blocks in the new format, these blocks
will be broken if the experimental feature is removed …. **so don’t run the gallery
refactor build against any critical data that you don’t have a backup of**.

## **How can I be sure I am seeing the new gallery block?**

When adding a Gallery block with the refactored gallery, selecting an individual
image in a gallery should show you the same options as for an individual Image block.
Currently, the only settings that will be missing are align and resize as these 
options break the gallery column layout.

Please note that this experimental feature will not currently work in FSE templates.
To see the new gallery block you will need to add the block to a standard post or
page. This change is also not ported to native mobile builds yet.

## **What needs testing?**

### General testing

Here’s a[ list of areas of functionality that need testing](https://github.com/WordPress/gutenberg/issues/29882)
for your convenience that anyone can help test.

### Plugin and theme authors

If you are the author of a plugin or theme that extends or restyles either the Image
block or the existing Gallery block you should:

 * Test how running the new Gallery block format affects the display of existing
   content in the editor or front end.
 * Test your plugin or theme against an existing gallery that has been migrated 
   to the new format.
 * Test with new galleries added with the refactored block.
 * Test how an Image block extensions affect layout, etc. if the Image block is 
   nested within one of the new Gallery blocks.

## **Where to report issues**

Please leave feedback in the comments of this post. If you’d prefer, you’re always
welcome to create issues in this [GitHub repo](https://github.com/WordPress/gutenberg/issues)
directly for 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/](https://wordpress.org/gutenberg/).
If you leave feedback in 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 by the repository
owner. [https://github.com/](https://github.com/), please do still comment below
with the link. Please check against the[ known issues list](https://github.com/WordPress/gutenberg/projects/56)
before reporting.

 [  ](https://profiles.wordpress.org/audrasjb/) [Jb Audras](https://profiles.wordpress.org/audrasjb/)
10:00 pm _on_ March 22, 2021     
Tags: [5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/),
[5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [week in core ( 245 )](https://make.wordpress.org/core/tag/week-in-core/)

# 󠀁[A Week in Core – March 22, 2021](https://make.wordpress.org/core/2021/03/22/a-week-in-core-march-22-2021/)󠁿

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

 * 24 commits
 * 21 contributors
 * 92 tickets created
 * 7 tickets reopened
 * 85 tickets closed

Reminder: WordPress 5.7.1 is [planned for April 14, 2021](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-schedule/),
so we are currently in the development cycle of the next point releaseMinor Release
A set of releases or versions having the same minor version number may be collectively
referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3,
and all other versions in the 5.2 (five dot two) branch of that software. Minor 
Releases often make improvements to existing features and functionality..

Ticketticket Created for both bug reports and feature development on the bug tracker.
numbers are based on the [Trac timeline for the period above](https://core.trac.wordpress.org/timeline?from=02%2F22%2F2021&daysback=7&authors=&ticket=on&sfp_email=&sfph_mail=&update=Update).
The following is a summary of commits, organized by component.

## Code changes

### Administration

 * Make focus states consistent in adminadmin (and super admin) menu when collapsed–
   [#32579](https://core.trac.wordpress.org/ticket/32579)

### Build/Test Tools

 * Update some `devDependencies` – [#52624](https://core.trac.wordpress.org/ticket/52624)
 * Revert [[50540]](https://core.trac.wordpress.org/changeset/50540) – [#52843](https://core.trac.wordpress.org/ticket/52843)
 * Remove explicit puppeteer dependency – [#52843](https://core.trac.wordpress.org/ticket/52843)
 * Move the `get_current_commenter()` method next to the test it’s used in – [#52625](https://core.trac.wordpress.org/ticket/52625)
 * Correct some newly introduced `@covers` tags – [#39265](https://core.trac.wordpress.org/ticket/39265)

### Coding Standards

 * Move some translator comments to the correct place – [#52627](https://core.trac.wordpress.org/ticket/52627)
 * Add missing semicolon to some `endif` keywords – [#52627](https://core.trac.wordpress.org/ticket/52627)
 * Use strict comparison for return type checks in a few functions – [#52627](https://core.trac.wordpress.org/ticket/52627)
 * Use strict comparison in `wp-admin/includes/class-wp-upgrader.php` – [#52627](https://core.trac.wordpress.org/ticket/52627)
 * Add a space before `/` character in some self-closing HTMLHTML HyperText Markup
   Language. The semantic scripting language primarily used for outputting content
   in web browsers. tags – [#52870](https://core.trac.wordpress.org/ticket/52870)
 * Use strict comparison for JSJS JavaScript, a web scripting language typically
   executed in the browser. Often used for advanced user interfaces and behaviors.
   fragment in some admin files – [#52845](https://core.trac.wordpress.org/ticket/52845),
   [#41988](https://core.trac.wordpress.org/ticket/41988)

### Documentation

 * Fix typo in `pre_term_link` filterFilter Filters are one of the two types of 
   Hooks [https://codex.wordpress.org/Plugin_API/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. description – [#52628](https://core.trac.wordpress.org/ticket/52628)
 * Correct formatting for the description of some `register_post_type()` parameters–
   [#52836](https://core.trac.wordpress.org/ticket/52836)

### Emoji

 * Update the Twemoji library to version 13.0.2 – [#52852](https://core.trac.wordpress.org/ticket/52852)

### External libraries

 * Update generated script loader version hashes – [#52850](https://core.trac.wordpress.org/ticket/52850)
 * Further fix jQuery deprecations in WordPress core – [#51812](https://core.trac.wordpress.org/ticket/51812)
 * Update the jQuery Form library – [#52685](https://core.trac.wordpress.org/ticket/52685)
 * Update Clipboard.js library to version `2.0.8` – [#52850](https://core.trac.wordpress.org/ticket/52850)
 * Update jQuery Color library to version `2.2.0` – [#51405](https://core.trac.wordpress.org/ticket/51405)

### Internationalization

 * Update list of continents and cities for the timezone selection – [#52861](https://core.trac.wordpress.org/ticket/52861)
 * Remove duplicate entries from the list of continents and cities – [#52861](https://core.trac.wordpress.org/ticket/52861)

### Media

 * Pass the appropriate reference into `wp_getimagesize` – [#52826](https://core.trac.wordpress.org/ticket/52826)

### Pointers

 * Make pointer border darker to match arrow tip – [#52670](https://core.trac.wordpress.org/ticket/52670)

## Props

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

[@SergeyBiryukov](https://profiles.wordpress.org/sergeybiryukov/) (2), [@laxman-prajapati](https://profiles.wordpress.org/laxman-prajapati/)(
1), [@Bueltge](https://profiles.wordpress.org/bueltge/) (1), [@audrasjb](https://profiles.wordpress.org/audrasjb/)(
1), [@isabel_brison](https://profiles.wordpress.org/isabel_brison/) (1), [@rnaby](https://profiles.wordpress.org/rnaby/)(
1), [@nayanchamp7](https://profiles.wordpress.org/nayanchamp7/) (1), [@desrosj](https://profiles.wordpress.org/desrosj/)(
1), [@hareesh-pillai](https://profiles.wordpress.org/hareesh-pillai/) (1), [@Clorith](https://profiles.wordpress.org/clorith/)(
1), [@melchoyce](https://profiles.wordpress.org/melchoyce/) (1), [@afercia](https://profiles.wordpress.org/afercia/)(
1), [@wangql](https://profiles.wordpress.org/wangql/) (1), [@johnjamesjacoby](https://profiles.wordpress.org/johnjamesjacoby/)(
1), [@whyisjake](https://profiles.wordpress.org/whyisjake/) (1), [@rinatkhaziev](https://profiles.wordpress.org/rinatkhaziev/)(
1), [@hellofromTonya](https://profiles.wordpress.org/hellofromtonya/) (1), [@Mista-Flo](https://profiles.wordpress.org/mista-flo/)(
1), [@terriann](https://profiles.wordpress.org/terriann/) (1), [@mukesh27](https://profiles.wordpress.org/mukesh27/)(
1), and [@jrf](https://profiles.wordpress.org/jrf/) (1).

**Please join me to welcome our 2 new Core contributorsCore Contributors Core contributors
are those who have worked on a release of WordPress, by creating the functions or
finding and patching bugs. These contributions are done through Trac. [https://core.trac.wordpress.org](https://core.trac.wordpress.org)
of the week ♥️[@nayanchamp7](https://profiles.wordpress.org/nayanchamp7/) and [@wangql](https://profiles.wordpress.org/wangql/)

**Core committers:** [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/)(
13), [@desrosj](https://profiles.wordpress.org/desrosj/) (7), [@ryelle](https://profiles.wordpress.org/ryelle/)(
2), [@whyisjake](https://profiles.wordpress.org/whyisjake/) (1), and [@peterwilsoncc](https://profiles.wordpress.org/peterwilsoncc/)(
1).

[#5-7-1](https://make.wordpress.org/core/tag/5-7-1/), [#5-8](https://make.wordpress.org/core/tag/5-8/),
[#week-in-core](https://make.wordpress.org/core/tag/week-in-core/)

 [  ](https://profiles.wordpress.org/get_dave/) [David Smith](https://profiles.wordpress.org/get_dave/)
3:31 pm _on_ March 22, 2021     
Tags: [agenda ( 1,142 )](https://make.wordpress.org/core/tag/agenda/),
[core-editor ( 757 )](https://make.wordpress.org/core/tag/core-editor/), [core-editor-agenda ( 189 )](https://make.wordpress.org/core/tag/core-editor-agenda/),
[meeting ( 405 )](https://make.wordpress.org/core/tag/meeting/)   

# 󠀁[Editor chat agenda: 24th March 2021](https://make.wordpress.org/core/2021/03/22/editor-chat-agenda-24th-march-2021/)󠁿

Facilitator and notetaker: ~[@get_dave](https://profiles.wordpress.org/get_dave/)
~ [@andraganescu](https://profiles.wordpress.org/andraganescu/) (thanks for stepping
in!).

This is the agenda for the weekly _editor chat_ scheduled for [2021-03-24 14:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210324T1400).

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

 * 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/](https://wordpress.org/gutenberg/)
   10.3 release.
 * [WordPress 5.7.1 maintenance release](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-schedule/).
 * [Monthly Plan for March 2021](https://make.wordpress.org/core/2021/03/08/whats-next-in-gutenberg-march-2021/)
   and key project updates:
    - Global Styles.
 *  - BlockBlock Block is the abstract term used to describe units of markup that,
      composed together, form the content or layout of a webpage using the WordPress
      editor. The idea combines concepts of what in the past may have achieved with
      shortcodes, custom HTML, and embed discovery into a single consistent API 
      and user experience. based WidgetWidget A WordPress Widget is a small block
      that performs a specific function. You can add these widgets in sidebars also
      known as widget-ready areas on your web page. WordPress widgets were originally
      created to provide a simple and easy-to-use way of giving design and structure
      control of the WordPress theme to the user. Editor.
    - Navigation Block.
    - Full Site Editing.
 * Task Coordination.
 * Open Floor.

If you can’t attend the meeting, you’re encouraged to share anything relevant for
the discussion:

 * 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](https://make.wordpress.org/core/tag/agenda/), [#core-editor](https://make.wordpress.org/core/tag/core-editor/),
[#core-editor-agenda](https://make.wordpress.org/core/tag/core-editor-agenda/), 
[#meeting](https://make.wordpress.org/core/tag/meeting/)

 [  ](https://profiles.wordpress.org/itsjusteileen/) [Eileen Violini](https://profiles.wordpress.org/itsjusteileen/)
11:01 am _on_ March 22, 2021      

# 󠀁[Core Editor Meeting Notes 17 March, 2021](https://make.wordpress.org/core/2021/03/22/core-editor-meeting-notes-17-march-2021/)󠁿

This post summarizes the latest weekly Editor meeting ([agenda](https://make.wordpress.org/core/2021/03/15/editor-chat-agenda-17-march-2021/),
[slack transcript](https://wordpress.slack.com/archives/C02QB2JS7/p1595426408288500)).
This meeting was held in the [#core-editor](https://wordpress.slack.com/messages/C02QB2JS7)
SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/).
The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/)
channel on [Wednesday, 17 March, 2021, 10:00 AM EDT](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Core+Editor+Meeting&iso=20210317T10&p1=2157&ah=1)
and was facilitated by @itjusteileen.

## **WordPress 5.7 Release **

[WordPress 5.7 ](https://make.wordpress.org/core/5-7/) Esperanza was released 9 
March and planning is underway for [WordPress 5.8](https://make.wordpress.org/core/2021/03/12/early-thoughts-on-wp5-8-planning/)

## **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/](https://wordpress.org/gutenberg/)󠁿 Version 10.**2

Gutenberg 10.2 is due out later today 17 March — 10.2.0 RC1 is [available for download](https://github.com/WordPress/gutenberg/releases/tag/v10.2.0-rc.1).

## **Monthly Priorities**

The monthly post outlining Gutenberg’s [priorities for March 2021](https://make.wordpress.org/core/2021/03/08/whats-next-in-gutenberg-march-2021/)
is available.

[@nosolosw](https://profiles.wordpress.org/nosolosw/) Posted as a comment: [https://github.com/WordPress/gutenberg/issues/20331#issuecomment-800940565](https://github.com/WordPress/gutenberg/issues/20331#issuecomment-800940565)

**Global Styles —**

 * The [last round of mockups for the global styles sidebar](https://github.com/WordPress/gutenberg/issues/27473)
   are live. It has provided a good ground to re-evaluate the 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. format and there’s going to be some formalization of
   the concept of “elements”, see [#29891](https://github.com/WordPress/gutenberg/issues/29891)
   for details.
 * There’s ongoing work for translations [#29828](https://github.com/WordPress/gutenberg/pull/29828)
   and iterate to offer higher-level APIs in the server [#29667](https://github.com/WordPress/gutenberg/pull/29667)
   [#29905](https://github.com/WordPress/gutenberg/pull/29905)
 * We landed some fixes for sub-properties (padding) as well [#29712](https://github.com/WordPress/gutenberg/pull/29712)

This issue description has been updated to focus on the infrastructure parts of 
global styles, that we aim to ship in 5.8. The UIUI User interface tasks have been
moved to the backlog for clarity but will be re-evaluated at a later point.

**Full Site Editing (FSE) —**

[Infrastructure and UI milestone](https://github.com/WordPress/gutenberg/issues/24818)
update from [@vindl](https://profiles.wordpress.org/vindl/)

 * Continued landing improvements for recently merged Persistent List View. The 
   last one added some nice styles for select and hover states ([#29636](https://github.com/WordPress/gutenberg/pull/29636))
 * We experimented with adding contextual 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. pattern inserter for semantic
   template parts ([#29595](https://github.com/WordPress/gutenberg/pull/29595)) 
   and gave up on that approach for now. That will probably be handled by contextual
   pattern transformations instead ([#29890](https://github.com/WordPress/gutenberg/pull/29890))
 * Weird template saving issue after switching FSE themes was reported in [#28951](https://github.com/WordPress/gutenberg/issues/28951),
   and we are looking into fixing it in [#29842](https://github.com/WordPress/gutenberg/pull/29842).

## Task Coordination

[@annezazu](https://profiles.wordpress.org/annezazu/)

 * [High level feedback from the FSE Program](https://make.wordpress.org/core/2021/03/16/high-level-feedback-from-the-fse-program-march/)
 * Shipped the [second round of FSE testing summary](https://make.wordpress.org/test/2021/03/12/fse-program-build-a-homepage-testing-summary/)
 * Continuing to test FSE every day and filing issues as I come across them.
 * Chatted with Taylor Ardnt about a11yAccessibility Accessibility (commonly shortened
   to a11y) refers to the design of products, devices, services, or environments
   for people with disabilities. The concept of accessible design ensures both “
   direct access” (i.e. unassisted) and “indirect access” meaning compatibility 
   with a person’s assistive technology (for example, computer screen readers). (
   https://en.wikipedia.org/wiki/Accessibility) in FSE and filed various issues.

[@paaljoachim](https://profiles.wordpress.org/paaljoachim/)

 * Issue: [Site Editing: It is not clear at-a-glance whether one is editing a template or an item of content](https://github.com/WordPress/gutenberg/issues/27849#issuecomment-799736059)
 * Issue: [FSE: Create more robust autosaving including UI](https://github.com/WordPress/gutenberg/issues/29577)
 * Triaging

[@ntsekouras](https://profiles.wordpress.org/ntsekouras/)
Keep on explorations with
block patterns integrations.

 * Suggest patterns for transformations PoC [PR 29890](https://github.com/WordPress/gutenberg/pull/29890)
 * Suggest Block patterns in block placeholder states is awaiting some updates in
   block patterns [PR 29602](https://github.com/WordPress/gutenberg/pull/29602)

Both try to validate the experimental `scope` in Patterns 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. introduced here
[PR 28891](https://github.com/WordPress/gutenberg/pull/28891) and more explorations
around all these and Template Parts are needed.

[@mattchowning](https://profiles.wordpress.org/mattchowning/)

The mobile team is working on:

 * Global Style Support
 * Reusable blocks
 * Removing ability to switch to the Classic editor
 * Dual-licensing Gutenberg
 * Search block
 * Adding search to the block inserter
 * Embed block
 * Simplification of media insertion flow

[@aristath](https://profiles.wordpress.org/aristath/)

 * This week I focused on tasks needed for the FSE MVPMinimum Viable Product "A 
   minimum viable product (MVP) is a product with just enough features to satisfy
   early customers, and to provide feedback for future product development." - [WikiPedia](https://en.wikipedia.org/wiki/Minimum_viable_product).
   That means primarily working on items outlined in [Issues 22724](https://github.com/WordPress/gutenberg/issues/22724)
 * Other than that lots of PR reviews to keep the cogs moving

[@joen](https://profiles.wordpress.org/joen/)

 * Working on navigation block, focus on burger menu and items in [Issues 27593](http://github.com/WordPress/gutenberg/issues/27593).
 * Have a few PRs out, and these two could use eyes:
    - [PR 29932](http://github.com/WordPress/gutenberg/pull/29932) 
    - [PR 29869](http://github.com/WordPress/gutenberg/pull/29869)
    -  [PR 28575](http://github.com/WordPress/gutenberg/issues/28575) it would help
      me a lot

[@itsjonq](https://profiles.wordpress.org/itsjonq/)

 * Nothing really new. Just continued efforts on integration with the new [Component System](https://github.com/WordPress/gutenberg/issues/28399)
   work
 * Status wise, we’re about [25% integrated](https://status.g2-components.com/)
 * Have to give a big shoutout to sarayourfriend for contributing so much in this
   effort! Also folks like [@Haz](https://profiles.wordpress.org/haz/) and others
   for reviewing + ideas.

[@mamaduka](https://profiles.wordpress.org/mamaduka/)

 * Created [PR 29919](https://github.com/WordPress/gutenberg/pull/29919) to fix 
   the issue with the Image Block resizable box
 * Created [PR 29825](https://github.com/WordPress/gutenberg/pull/29825) add a filterFilter
   Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/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. for “Preferences” modal sections. Would like feedback and eyes here.
   
   [@youknowriad](https://profiles.wordpress.org/youknowriad/) provided [feedback](https://wordpress.slack.com/archives/C02QB2JS7/p1615991213059300?thread_ts=1615991037.055700&cid=C02QB2JS7)
   on the extensibility of JSJS JavaScript, a web scripting language typically executed
   in the browser. Often used for advanced user interfaces and behaviors. in Gutenberg
   which needs an architecture document
 * Currently working on PR to use `image_default_size` option in Image Block, instead
   of hardcoded default.

## Open Floor

A new 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 by the repository
owner. [https://github.com/](https://github.com/) Project Board was created for 
the [Full Site Editing  MVP](https://github.com/WordPress/gutenberg/projects/55)
due in April. Shoutout to [@paaljoachim](https://profiles.wordpress.org/paaljoachim/)
for championing the effort and to [@priethor](https://profiles.wordpress.org/priethor/)
for assisting. Feedback on the next round of FSE testing [Create a 404 Page](https://make.wordpress.org/test/2021/03/09/fse-program-testing-call-3-create-a-fun-custom-404-page/)
is due Wednesday.

As noted by [@matias](https://wordpress.slack.com/team/U02RRJDPG) during the meeting,
more feedback is needed from theme creators and testers taking part in the FSE Outreach
Experiment on the theme.json proposal.

 [  ](https://profiles.wordpress.org/peterwilsoncc/) [Peter Wilson](https://profiles.wordpress.org/peterwilsoncc/)
2:11 am _on_ March 22, 2021     
Tags: [5.7 ( 67 )](https://make.wordpress.org/core/tag/5-7/),
[5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/)   

# 󠀁[WordPress 5.7.1 maintenance release schedule](https://make.wordpress.org/core/2021/03/22/wordpress-5-7-1-maintenance-release-schedule/)󠁿

Since the [release of WordPress 5.7](https://wordpress.org/news/2021/03/esperanza/)
a small number of bugs have been identified will benefit from a maintenance release.

Now, it’s time to merge these changes into a new WordPress minor releaseMinor Release
A set of releases or versions having the same minor version number may be collectively
referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3,
and all other versions in the 5.2 (five dot two) branch of that software. Minor 
Releases often make improvements to existing features and functionality. and to 
address the other tickets that have appeared in the meantime.

The following release schedule is being proposed:

 * 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)](https://make.wordpress.org/core/2021/page/46/?output_format=md#alpha-beta).:
   Wednesday 7 April, 2021 around 23:00 UTC
 * Final release: Wednesday 14 April, 2021 around 23:00 UTC

At the time of writing, 18 tickets have been identified for [the 5.7.1 milestone](https://core.trac.wordpress.org/tickets/minor)
and 48 [tickets submitted since March 9 are awaiting review](https://core.trac.wordpress.org/query?status=!closed&milestone=Awaiting+Review&version=5.7&version=&version=trunk&time=2021-03-09..).

In line with the trial for [consistent minor release leads](https://make.wordpress.org/core/2021/03/16/trial-run-consistent-minor-release-squad-leaders-for-each-major-branch/)
for each major branchbranch A directory in Subversion. WordPress uses branches to
store the latest development code for each major release (3.9, 4.0, etc.). Branches
are then updated with code for any minor releases of that branch. Sometimes, a major
version of WordPress and its minor versions are collectively referred to as a "branch",
such as "the 4.0 branch"., the release leaders for the 5.7.x releases will be:

 * Release leadRelease Lead The community member ultimately responsible for the 
   Release.: [@peterwilsoncc](https://profiles.wordpress.org/peterwilsoncc/)
 * Deputy Lead: [@audrasjb](https://profiles.wordpress.org/audrasjb/)

[#5-7](https://make.wordpress.org/core/tag/5-7/), [#5-7-1](https://make.wordpress.org/core/tag/5-7-1/)

 [  ](https://profiles.wordpress.org/marybaum/) [marybaum](https://profiles.wordpress.org/marybaum/)
4:41 pm _on_ March 21, 2021     
Tags: [5.7.1 ( 20 )](https://make.wordpress.org/core/tag/5-7-1/),
[5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [core ( 745 )](https://make.wordpress.org/core/tag/core/),
[dev chat ( 922 )](https://make.wordpress.org/core/tag/dev-chat/), [meetings ( 14 )](https://make.wordpress.org/core/tag/meetings/),
[summary ( 975 )](https://make.wordpress.org/core/tag/summary/)   

# 󠀁[Dev chat summary: March 17, 2021](https://make.wordpress.org/core/2021/03/21/dev-chat-summary-march-17-2021/)󠁿

[@francina](https://profiles.wordpress.org/francina/) led the chat [on this agenda](https://make.wordpress.org/core/2021/03/16/dev-chat-agenda-for-march-17-2021/).

### Announcements

The big news: [WordPress 5.7 “Esperanza” landed March 9](https://wordpress.org/news/2021/03/esperanza/),
and the group took a well-deserved bow.

Moving on, Francesca highlighted these posts:

 * [A Week in Core – March 15, 2021](https://make.wordpress.org/core/2021/03/15/a-week-in-core-march-15-2021/)
 * [High level feedback from the FSE Program (March 2021)](https://make.wordpress.org/core/2021/03/16/high-level-feedback-from-the-fse-program-march/)
 * [Q2 Listening Hours: April 7th, 2021](https://make.wordpress.org/core/2021/03/12/q2-listening-hours-april-7th-2021/)
 * [Early Thoughts on WP5.8 Planning](https://make.wordpress.org/core/2021/03/12/early-thoughts-on-wp5-8-planning/)
 * [Block Editor Handbook: restructuring project update (March 12)](https://make.wordpress.org/core/2021/03/12/block-editor-handbook-restructuring-project-update-march-12/)
 * [What’s new in Gutenberg 10.2? (17 March)](https://make.wordpress.org/core/2021/03/17/whats-new-in-gutenberg-10-2-17-march/)

[@jeffpaul](https://profiles.wordpress.org/jeffpaul/) noted [Trial run: Consistent minor release squad leaders for each major branch](https://make.wordpress.org/core/2021/03/16/trial-run-consistent-minor-release-squad-leaders-for-each-major-branch/).
Francesca added that the post is both a highlight and a call for volunteers.

[@annezazu](https://profiles.wordpress.org/annezazu/) put out a last call for [FSE Program Testing Call #3: Create a fun & custom 404 page](https://make.wordpress.org/test/2021/03/09/fse-program-testing-call-3-create-a-fun-custom-404-page/).
If you’d like to catch up on the previous two FSE tests, Anne and Francesca said
you can find [previous calls under this tag](https://make.wordpress.org/test/tag/fse-testing-call/).
If you’d like to do your own testing, [the FSE Handbook has a page with instructions](https://make.wordpress.org/test/handbook/full-site-editing-outreach-experiment/how-to-test-fse/).
Capping off the FSE discussion was Marketing Team repTeam Rep A Team Rep is a person
who represents the Make WordPress team to the rest of the project, make sure issues
are raised and addressed as needed, and coordinates cross-team efforts. [@webcommsat](https://profiles.wordpress.org/webcommsat/),
who said you can also share [this LinkedIn promotion.](https://www.linkedin.com/posts/make-wordpress-marketing-team_fse-program-testing-call-3-create-a-fun-activity-6777389468505649152-_ifA)

[@francina](https://profiles.wordpress.org/francina/) then turned to posts that 
need feedback. This [Proposal: A WordPress Project Contributor Handbook](https://make.wordpress.org/updates/2021/03/16/proposal-a-wordpress-project-contributor-handbook/)
drew spirited emoji support from the group. Francesca also reminded the group to
sign up for [the Updates blog](https://make.wordpress.org/updates) to keep up with
a variety of team updates, as well as posts from [@chanthaboune](https://profiles.wordpress.org/chanthaboune/)
about cross-team efforts and the latest news from leadership.

### Components check-in and status updates

[@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/) started with jQuery
news: the version in 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. has updated to 3.6.0, which is mostly
bugbug A bug is an error or unexpected result. Performance improvements, code optimization,
and are considered enhancements, not defects. After feature freeze, only bugs are
dealt with, with regressions (adverse changes from the previous version) being the
highest priority. fixes and improvements. Two callouts:

> Aside from the change to no longer ensure XHTML-compliant tags for you, we do 
> not expect other compatibility issues when upgrading from a jQuery 3.0+ version.
> See ticketticket Created for both bug reports and feature development on the bug
> tracker. [#52707](https://core.trac.wordpress.org/ticket/52707) for more details.

>  jQuery hoverIntent library has updated from version 1.8.3 to 1.10.1. The changes
> all appear to be minor.
> See ticket [#52686](https://core.trac.wordpress.org/ticket/52686) for more details.

[@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) checked in with
Media news: he’s working on landing support for WebP images in 5.8 and would like
testing and feedback on ticket [#35725](https://core.trac.wordpress.org/ticket/35725).

Up next, [@audrasjb](https://profiles.wordpress.org/audrasjb/) said he has nothing
new for Menus and WidgetWidget A WordPress Widget is a small block that performs
a specific function. You can add these widgets in sidebars also known as widget-
ready areas on your web page. WordPress widgets were originally created to provide
a simple and easy-to-use way of giving design and structure control of the WordPress
theme to the user., but he’s quietly scrubbing bugs and watching tickets. On Upgrade/
Install, he highlighted this [feature plugin proposal](https://make.wordpress.org/core/2021/02/19/feature-plugin-rollback-update-failure/)
post.

[@sabernhardt](https://profiles.wordpress.org/sabernhardt/) wrapped up the Component
updates with his announcement of a Toolbar triagetriage The act of evaluating and
sorting bug reports, in order to decide priority, severity, and other factors./bug
scrub for the following day, March 18, at 16:00 UTC.

### Open floor

#### IE11 support

[@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) asked: Given
that the Project [has decided to drop support for IE 11](https://make.wordpress.org/core/2021/03/04/discussion-dropping-support-for-ie11/),
have we discussed a specific release to make that change in?

[The discussion that followed](https://wordpress.slack.com/archives/C02RQBWTW/p1616013287076000)
outlined a general process—notify, then act—but pointed out the group still needs
to make a specific plan for IE11. Adam noted that IE11 is the only major browser
that doesn’t support WebP images.

[@desrosj](https://profiles.wordpress.org/desrosj/) said there might already be 
a notification in place. [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/)
found a ticket, [#48743](https://core.trac.wordpress.org/ticket/48743), to that 
effect. Further discussion also made it clear that the team needs to do more to 
announce the change, including stronger language in relevant tickets ([@desrosj](https://profiles.wordpress.org/desrosj/)
and [@audrasjb](https://profiles.wordpress.org/audrasjb/)), a News blogblog (versus
network, site) post (h/t: [@jorbin](https://profiles.wordpress.org/jorbin/)) and
relevant Handbook updates (h/t [@jeffpaul](https://profiles.wordpress.org/jeffpaul/))

#### “Try FSE?”

[@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/) observed:

> It seems that most of WP users (outside of the contributing teams) are still largely
> unaware that full-site editing is coming later this year.
> Perhaps that’s intentional, but once we have something stable to test, have we
> considered adding a dashboard widget to one of the upcoming minor releases, to
> invite more users to test FSE before final release, like we did with 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/](https://wordpress.org/gutenberg/)
> in [#41316](https://core.trac.wordpress.org/ticket/41316) for WP 4.9.8?

[See the full discussion that followed, with a variety of people sharing a variety of views on the subject.](https://wordpress.slack.com/archives/C02RQBWTW/p1616014148102700)

[#5-7-1](https://make.wordpress.org/core/tag/5-7-1/), [#5-8](https://make.wordpress.org/core/tag/5-8/),
[#core](https://make.wordpress.org/core/tag/core/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/),
[#meetings](https://make.wordpress.org/core/tag/meetings/), [#summary](https://make.wordpress.org/core/tag/summary/)

 [  ](https://profiles.wordpress.org/notlaura/) [Lara Schenck](https://profiles.wordpress.org/notlaura/)
8:08 pm _on_ March 18, 2021     
Tags: [agenda ( 1,142 )](https://make.wordpress.org/core/tag/agenda/),
[core-css ( 191 )](https://make.wordpress.org/core/tag/core-css/)   

# 󠀁[CSS Chat Agenda: March 18, 2021](https://make.wordpress.org/core/2021/03/18/css-chat-agenda-march-18-2021/)󠁿

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled
for [Thursday, March 18, at 10:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=WordPress+CSS+Core+Chat&iso=20210318T22&p1=136&ah=1).
This meeting will be held in the [#core-css](https://make.wordpress.org/core/tag/core-css/)
channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform
[https://slack.com/](https://slack.com/). The WordPress community has its own Slack
Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/).

If there’s any topic you’d like to discuss, or if you have suggestions for discussion
questions, please leave a comment below!

 * Housekeeping
 * Project Updates
    - CSS Audit ([#49582](https://core.trac.wordpress.org/ticket/49582))
    - Color Scheming ([#49999](https://core.trac.wordpress.org/ticket/49999))
       * Reminder: A next week’s meeting on March 25 we will share mock-ups with
         color custom property naming for another UIUI User interface component 
         besides the button.
 * Open Floor + CSS Link Share

[#agenda](https://make.wordpress.org/core/tag/agenda/), [#core-css](https://make.wordpress.org/core/tag/core-css/)

 [  ](https://profiles.wordpress.org/sarayourfriend/) [Sara](https://profiles.wordpress.org/sarayourfriend/)
3:43 pm _on_ March 18, 2021      

# 󠀁[Proposal: Native TypeScript support in Gutenberg](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/)󠁿

## What is TypeScript?

Simply put, and taken from the TypeScript website:

> TypeScript extends 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](https://www.javascript.com/)
> by adding types.

You are able to add types by using the TypeScript language itself, which is a superset
of JavaScript. It resembles JavaScript in every way except for the addition of types.
Alternatively, you can add types through **JSDoc annotations**. 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/](https://wordpress.org/gutenberg/) so far
has opted for the latter.

Type checking is also [coming to PHP](https://www.php.net/manual/en/language.types.declarations.php)
and many other dynamic languages, so increasingly type checking is becoming less
of a foreign concept for fans of dynamic languages.

## What is being proposed?

This post proposes that we transition away from JSDoc annotations and towards the
TypeScript language itself. This is proposed because it unlocks powerful features
of TypeScript that are unavailable through JSDoc annotations and will encourage 
new contributions by community members in this space by lowering the learning curve
and leveraging existing knowledge of statically typed languages.

Essentially this means beginning to use `.ts(x)` files _in addition to_ existing`.
js` files. I emphasize “in addition to” because I want to stress that I am not suggesting
that we eliminate traditional JavaScript from Gutenberg, nor is the proposal to 
fully re-write Gutenberg in TypeScript. The fact is that the majority of Gutenberg
will probably forever remain as plain old JavaScript. However, I think in our coreCore
Core is the set of software required to run WordPress. The Core Development Team
builds WordPress. libraries (`data`, `compose`, `components`, `dom`, etc) we should
transition to a heavier use of type-checking and the TypeScript language itself 
to ease that transition.

## A brief history of TypeScript in Gutenberg

In August of 2019, [TypeScript was first introduced for type checking modules through JSDoc](https://github.com/WordPress/gutenberg/pull/17014).
Then, a few months later in November, type validation for modules was [officially proposed](https://github.com/WordPress/gutenberg/issues/18838):

> While Gutenberg packages are not authored in TypeScript, we can still benefit 
> from its [JavaScript type checking](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html)
> using the JSDoc we already write. This will bring us some benefit of type safety,
> even as we continue to write modules with JavaScript, not TypeScript.
> Andrew Duthie

[Documentation explaining how to use JSDoc with JavaScript was added in December of the same year](https://github.com/WordPress/gutenberg/pull/18920).
The current version of that [documentation lives here](https://github.com/WordPress/gutenberg/blob/b7f341628facdc4b5c46aaf9c8745039dc6aa774/docs/contributors/code/coding-guidelines.md#javascript-documentation-using-jsdoc).
In March of 2020 we began [using TypeScript to output package type declarations](https://github.com/WordPress/gutenberg/pull/18942)
as a way of progressively replacing the DefinitetlyTyped `@types` packages for the`@
wordpress` scope of packages. [Documentation was later added explaining how to type pack](https://github.com/WordPress/gutenberg/tree/b7f341628facdc4b5c46aaf9c8745039dc6aa774/packages#typescript)

[ages with TypeScript and JSDoc](https://github.com/WordPress/gutenberg/tree/b7f341628facdc4b5c46aaf9c8745039dc6aa774/packages#typescript).
Finally, in February of this year, the [`react-i18n` package was added which introduced the first package fully written in native TypeScript](https://github.com/WordPress/gutenberg/pull/28465).

## How we do things today

We use TypeScript to generate `.d.ts` files for certain packages in Gutenberg based
on [JSDoc type annotations](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html).
This allows us to “sprinkle” TypeScript support throughout our normal JavaScript
codebase without having to do re-writes of existing modules in TypeScript. In addition
to generation the TypeScript compiler also checks our code for type safety. For 
example, you type the a function like this:

    ```notranslate
    /**
     * @param {number} x
     * @param {number} y
     * @return {number}
     **/
    function add( x, y ) {
        return x + y;
    }
    ```

And try to pass in a `string` to this function, you’ll get a compiler error. This
is enforced through a pre-commit hook as well as the static-analysis 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 by the repository owner. [https://github.com/](https://github.com/)
action that is run on all PRs.

## Problems with the JSDoc approach

When we adopted JSDoc annotations as our approach to adding types in Gutenberg, 
we hoped we could improve the experience for new contributors by providing great
auto-complete and quality assurance help in editors like VS Code while not requiring
them to actually learn TypeScript. However, adopting the JSDoc syntax actually has
significant downsides. First, few TypeScript examples use JSDoc. When a new contributor
wants to express a moderately complex type, they find themselves translating between
TypeScript example they find online and the less common, JSDoc version. Second, 
there are some features of TypeScript that are completely unavailable in the JSDoc
variant of the syntax. And those features, like template parameter defaults, can
potentially provide a lot of help for developers trying to use Gutenberg’s components
or the `@wordpress/data` package.

## Surprise! We already use TypeScript (compiler)

By now you may have thought to yourself, “Wait, it sounds like we already use TypeScript?”
The secret is that yes, [we already use TypeScript in Gutenberg](https://github.com/WordPress/gutenberg/issues/18838)…
just with the a poorly documented, less expressive syntax (JSDoc). For packages 
that support it (those that already emit their own `.d.ts` files) the TypeScript
compiler is already being used for type checking, as stated above with the addition
example. Likewise, when reading JSDoc typed JavaScript code, one doesn’t need to
just pay attention to the code they are immediately reading, but also displaced 
type definitions (the type definitions live separately from the code itself). **
This means that the effective difference between what exists today and what is being
proposed in this post is a (massive) syntax improvement** as well as the ability
to **unlock TypeScript’s full potential by being able to expressively type core 
libraries like `compose` and `data`**.

While this is admittedly a new syntax and may seem scary, I would urge you to consider
the difference between these two blocks of code:

    ```notranslate
    /**
     * @param {object} props Props
     * @param {string} [props.className] Classname
     * @param {(value: string) => void} [props.onChange] Change handler
     * @param {import('react').Ref<HTMLInputElement>
     */
    function CustomInput( props, forwardedRef ) {
      // ...
    }
    ```

Versus:

    ```notranslate
    interface Props {
      className?: string;
      onChange?: ( value: string ) => void;
    }

    function CustomInput( props: Props, forwardedRef: Ref<HTMLInputElement> ) {
      // ...
    }
    ```

This represents the majority of the changes that would occur if we adopted TypeScript
in places where we currently use JSDoc.

I don’t want to discount the learning curve of a new language—TypeScript definitely
has its own learning curve. However, I think that learning curve is worth the benefits
elucidated in the following section. Likewise, regular JavaScript with JSDoc annotations
will continue to be available as an option and for many use cases it will continue
to be a good option (like adding types to existing code where the types themselves
are straightforward).

For a while, this syntax improvement was not possible because we lacked tooling.
For example, we didn’t have ESLint support and `docgen` was unable to process TypeScript
files. Both of those problems have since been addressed in these PRs:

ESLint support: [https://github.com/WordPress/gutenberg/pull/27143](https://github.com/WordPress/gutenberg/pull/27143)

`docgen` support: [https://github.com/WordPress/gutenberg/pull/29189](https://github.com/WordPress/gutenberg/pull/29189)

Now that these tooling issues are mostly behind us, I think we’re ready to move 
forward with native TypeScript in Gutenberg.

## Benefits of native TypeScript

By allowing native TypeScript support in the Gutenberg repository, we continue to
leverage the existing benefits _we’ve already bought into_ by using the TypeScript
compiler to generate `.d.ts` files (remember that this does not merely extract the
types from the JSDoc comments but also checks the soundness of the code itself) 
with the vastly improved syntax of native TypeScript. It’ll also allow us to leverage
the existing expertise of members of our community who are familiar with TypeScript(
and other typed languages) rather than having to re-learn how to write types using
the far-less than ideal JSDoc support.

Native TypeScript will also unlock the full power of the TypeScript type system.
Currently there are a few edge cases that are explicitly not supported by the JSDoc
annotations. For example, it’s not possible to create optional type parameters. 
The following is impossible to express in JSDoc:

    ```notranslate
    type GenericType&lt;T = any> = { foo: T };
    ```

Furthermore, native TypeScript will allow us to type complex core systems (like `@
wordpress/data` and `@wordpress/compose`) without adding massive amounts of “noise”
to each file in the form of complex, difficult to read, and even harder to maintain
JSDoc type annotatons. For example, typing `createHigherOrderComponent` in native
TypeScript is a breeze relative to the complex expressions you run into trying to
type it using JSDoc annotations. Typing these core systems gives us both the guarantee
of their soundness as we make improvements _and_ grants community contributors using
those libraries the same guarantee that they’re using the 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. in a sound way.

## Where should this change happen and who will it effect?

First, I want to emphasize that this changes basically nothing for custom 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. authors. While`@
wordpress/babel-preset-default` includes TypeScript transpilation support, `create-
block` has not been updated to support TypeScript. Likewise, the dependencies for
block authors, like the `@wordpress/block-editor` package, do not have up-to-date
type definitions (it has defintions on [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/wordpress__block-editor)
but these have probably fallen out of sync with the code itself) or do not have 
type definitions at all (meaning the TypeScript compiler will complain about not
being able to understand your dependencies). TypeScript for block authors will likely
take some significant community support to enable type generation, whether through
native TypeScript or JSDoc type annotations, in higher-level packages.

That being said, let’s take a look at who is _already_ affected by TypeScript in
the Gutenberg code base. One third of Gutenberg packages are currently type checked(
meaning they have a `tsconfig.json`), either fully or partially and the pre-commit
hook won’t let you commit and JSJS JavaScript, a web scripting language typically
executed in the browser. Often used for advanced user interfaces and behaviors. 
code there that wouldn’t be approved by the TypeScript compiler. To make any contribution
to this growing list of packages, you must already know the TypeScript type system
in order to understand type checking errors as well as to understand how to type
any new code that you add. This has been the _status quo_ for many months now (see
the history section above).

Taking a closer look at the packages that currently garner the most contributions
per year, here are the packages that have attracted more than 100 commits in the
last year:

| **package** | **commits** | `**tsconfig**` | **`@types`** | 
| block-library | 1093 |  | x | 
| block-editor | 950 | x (partial) | x | 
| components | 626 | x (partial) | x | 
| e2e-tests | 454 |  |  | 
| edit-site | 292 |  |  | 
| editor | 257 |  | x | 
| edit-post | 246 |  | x | 
| edit-widgets | 163 |  |  | 
| reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. [https://reactjs.org](https://reactjs.org/)-native-editor | 152 |  |  | 
| edit-navigation | 135 |  |  | 
| scripts | 116 |  |  | 
| blocks | 114 |  |  | 
| block-directory | 107 |  |  | 
| interface | 102 |  |  |

The `tsconfig` and `@types` columns denote whether the package is type checked or
has DefinitelyTyped type defintions respectively. At the moment, none of these 14
packages publish type definitions natively and community contributors who use TypeScript
for their projects must rely on DefinitelyTyped when it is available.

The `block-library` package type checks 2 specific files and ignores the rest (for
now, hopefully this will be expanded in the future).

This shows that for the vast majority of contributions, TypeScript support is irrelevant.
Now, that doesn’t meant that TypeScript support isn’t coming to those packages. 
The main roadblock to it, however, are lower level packages that are currently untyped
like `compose` and `data`.

`components` is a bit of an outlier in that it is a widely contributed-to package
that has a lot of it typed. Indeed there is an ongoing effort to type as much of`
components` as possible, due to its wide-spread nature. It is believed that the 
best way to show TypeScript’s power is to have a widely used library like `components`
typed. However, it is roadblocked by `compose` and other core libraries not being
fully typed.

Those low level packages garner far fewer contributions by a much smaller group 
of people than the 14 packages listed in the table above. `compose`, for example,
received under 60 significant (non publish, non dependency update, and non documentation
update) commits over the last year from a group of less than 10 people. By progressively
and carefully re-writing _parts_ of `compose` in native TypeScript, we can have 
a ripple effect where the benefits of TypeScript will by felt throughout the Gutenberg
codebase without actually affecting how most contributors write their code. Most
contributors consume `compose` in their own code but do not contribute directly 
to it.

In summary, there are a few packages like `compose`, `element`, `i18n`, and `data`
that share the following traits:

 * they are foundational infrastructure packages relied on by everything else
 * they don’t attract mainstream contributor interest. They are worked on mainly
   by “experts”
 * they are more likely to use complicated types with generics and other tricks.
   Functions from `compose` are a crystal clear example of that

Switching these to native TypeScript would have a big impact: **solid type-safe 
foundational libraries**. And the downside is limited: **most contributors don’t
come into much contact with these**.

## The path forward

In packages that support JSDoc type annotations, you can already swap out JavaScript
for TypeScript without any concern as Babel is already ready to consume TypeScript(
it simply strips the type annotations from the files). For example, if you wanted
to re-write and any file that is already JSDoc annotated in TypeScript, you could
do that today without any problems (really, if you don’t believe me try it!). There
may be some caveats like needing to explicitly annotate return types of functions
so that `docgen` can consume them, but these are easy to enforce, beneficial to 
the health of the code in general, and also not different than the limitations that
currently exist with JSDoc—`docgen` will give you a helpful error if it cannot find
the return type of a function you’ve asked it to document and explicit annotation
of inputs and outputs is a good thing and we already do it through the `@return`
tagtag A directory in Subversion. WordPress uses tags to store a single snapshot
of a version (3.6, 3.6.1, etc.), the common convention of tags in version control
systems. (Not to be confused with post tags.).

For packages that are currently not type fully annotated (like `compose`, `dom`,
and `data`) we can begin to progressively re-write the more complex, core parts 
of it in TypeScript. We don’t have to re-write everything, nor should we spend our
valuable time merely re-writing files that don’t need it. However, in the cases 
where native TypeScript allows us to more fluidly, confidently, simply, and beautifully
express the types of a module, we should do so (`compose` and `data` are tremendous
examples of this).

We’ve already seen some of the benefits of using TypeScript JSDoc syntax in Gutenberg.
Our documentation has improved, and everyone from Gutenberg contributors to block
developers to site builders enjoys better auto-complete and error handling in their
editors. When we use the better supported, more expressive standard TypeScript syntax,
we’ll only improve that experience for everyone involved. If you want to contribute
to Gutenberg, don’t be intimidated by the new syntax! TypeScript, much like WordPress,
enjoys a rich, supportive community with many quality examples and tutorials.

## Acknowledgements

Thanks to [@gziolo](https://profiles.wordpress.org/gziolo/), [@griffbrad](https://profiles.wordpress.org/griffbrad/),
[@nerrad](https://profiles.wordpress.org/nerrad/), [@youknowriad](https://profiles.wordpress.org/youknowriad/),
[@jsnajdr](https://profiles.wordpress.org/jsnajdr/) and many others for reviewing
and/or contributing to this proposal.

# Post navigation

[← Older posts](https://make.wordpress.org/core/2021/page/47/?output_format=md)

[Newer posts →](https://make.wordpress.org/core/2021/page/45/?output_format=md)