Editor Chat Agenda: 30 June 2021

Facilitator and notetaker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, June 30, 2021, 04:00 PM GMT+1.

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

  • Gutenberg 10.9.
  • WordPress 5.8 (Project board)
  • Monthly Plan for June 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 & Navigation Editor.
    • Full Site Editing.
    • Mobile Team.
  • Task Coordination.
  • Open Floor.

If you are not able to attend the meeting, you are 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, #core-editor, #core-editor-agenda, #meetings

Various Block Editor API removals in WordPress 5.8

Removed APIs

Keeping deprecated 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/. APIs around has a cost on performance and bundle size. This means at some point we need to consider removing some of the very old deprecated APIs, especially the ones with very low usage. WordPress 5.8 does remove two APIs that were deprecated on WordPress 5.2.

  • EditorGlobalKeyboardShortcuts component, this was a component used to define some keyboard shortcuts of the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, it was not really meant to be used by third-party developers. We verified that it’s not used by any pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party in the repository but if you rely on this component, it should be safe to just replace with VisualEditorGlobalKeyboardShortcuts.
  • The hasUploadPermissions selector from the core store. We contacted all the three plugins in the repository that were still using this 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.. If you’re still relying on this selector on a private site/plugin, it can be safely replaced with select( 'core' ).canUser( 'create', 'media' )

Removed blocks

Before WordPress 5.0 and in the very early days of the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin, we used to have a block called Subheading, this block has never been included in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as stable, it was hidden and deprecated very early. We expect its usage to be very small. WordPress 5.8 removes the code of this block meaning that if you open content relying on that block in the editor, it will ask you to fallback to the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. block instead. We don’t expect this to have a noticeable impact on the frontend of your site.

#5-8, #block-editor, #dev-notes

REST API Changes in WordPress 5.8

The following is a snapshot of some of the changes to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. in WordPress 5.8. For more details, see the full list of closed tickets.

Widgets

WordPress 5.8 sees the introduction of a new 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 widgets editor and with it the creation of several REST API endpoints dedicated to 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. management. Before diving in to how the new endpoints operate, I’d like to provide some background about how widgets work that should make the following sections more clear.

Instance Widgets

The predominant way to create widgets is to subclass the WP_Widget base class and register the widget with register_widget. These are referred to as “multi” widgets. These widgets have multiple instances that are identified by their number, an incrementing integer for each widget type.

Each instance has its own setting values. These are stored and fetched by WP_Widget which allows for the REST API to include these values. However, since a widget’s instance can contain arbitrary data, for example a DateTime object, the REST API cannot always serialize a widget to 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.. As such, a widget’s data is always serialized using the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher serialize function and then base64 encoded. This data is also exposed with a hash value which is a wp_hash signature of this value to prevent clients from sending arbitrary data to be deserialized with unserialize.

For widgets that can be safely accept and expose their instance data as JSON, pass the show_instance_in_rest flag in the $widget_options parameter.

class ExampleWidget extends WP_Widget {
    ...
    /**
     * Sets up the widget
     */
    public function __construct() {
        $widget_ops = array(
            // ...other options here
            'show_instance_in_rest' => true,
            // ...other options here
        );
        parent::__construct( 'example_widget', 'ExampleWidget', $widget_ops );
    }
    ...
}

Reference Widgets

Far less common, but still supported, are widgets that are registered using wp_register_sidebar_widget and wp_register_widget_control directly. These are referred to as “reference”, “function-based”, or “non-multi” widgets. These widgets can store their data in an arbitrary location. As such, their instance values are never included in the REST API.

Widget Types

Accessible via /wp/v2/widget-types, the widget types endpoint describes the different widget types that are registered on the server. The endpoint is accessible to users who have permission to edit_theme_options. By default, this is limited to Administrator users.

Response Format

{
  "id": "pages",
  "name": "Pages",
  "description": "A list of your site’s Pages.",
  "is_multi": true,
  "classname": "widget_pages",
  "_links": {
    "collection": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/widget-types"
      }
    ],
    "self": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/widget-types/pages"
      }
    ]
  }
}

Encode Endpoint

Multi widgets have access to the /wp/v2/widget-types/<widget>/encode endpoint. This endpoint is used to convert htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. form data for the widget to the next instance for the widget, render the widget form, and render the widget preview.

For example, let’s say we want to interact with the MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. widget. First, we’ll want to request the widget form from the server.

POST /wp/v2/widget-types/meta/encode
{
  "instance": {},
  "number": 1
}

For now, let’s assume we’re working with a new widget. The instance is empty because this is a new widget, so we’ll be rendering an empty form. The number argument can be omitted, but including one is recommended to provide stable input ids. You’ll receive a response similar to this. The widget preview has been snipped for brevity.

{
  "form": "<p><label for=\"widget-meta-1-title\">Title:</label><input class=\"widefat\" id=\"widget-meta-1-title\" name=\"widget-meta[1][title]\" type=\"text\" value=\"\" /></p>",
  "preview": "<div class=\"widget widget_meta\">...</div>",
  "instance": {
    "encoded": "YToxOntzOjU6InRpdGxlIjtzOjA6IiI7fQ==",
    "hash": "77e9f20acb54fa4f77de5a865333c0e6",
    "raw": {
      "title": ""
    }
  }
}

The provided form can then be rendered and edited by the user. When you want to render a new preview or are ready to begin saving, call the encode endpoint again with the url encoded form data and the instance value returned from the first response.

POST /wp/v2/widget-types/meta/encode
{
  "instance": {
    "encoded": "YToxOntzOjU6InRpdGxlIjtzOjA6IiI7fQ==",
    "hash": "77e9f20acb54fa4f77de5a865333c0e6",
    "raw": {
      "title": ""
    }
  },
  "number": 1,
  "form_data": "widget-meta%5B1%5D%5Btitle%5D=Site+Info"
}

The REST API will call the widget’s update function to calculate the new instance based on the provided form data. The instance object can then be used to save a widget via the widgets endpoint.

{
  "form": "<p><label for=\"widget-meta-1-title\">Title:</label><input class=\"widefat\" id=\"widget-meta-1-title\" name=\"widget-meta[1][title]\" type=\"text\" value=\"Site Info\" /></p>",
  "preview": "<div class=\"widget widget_meta\">...</div>",
  "instance": {
    "encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgSW5mbyI7fQ==",
    "hash": "0e9a5bff2d28cba322c8cd27cd4e77af",
    "raw": {
      "title": "Site Info"
    }
  }
}

Widgets Endpoint

The widgets endpoint is used for performing CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) operations on the saved widgets. Like the widget types endpoint, the widgets endpoints required the edit_theme_options capability to access.

To retrieve widgets, make a GET request to the /wp/v2/widgets endpoint. The sidebar parameter can be used to limit the response to widgets belonging to the requested sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme..

To create a widget, for instance the widget from our previous example, make a POST request to the /wp/v2/widgets endpoint. The instance is the same value returned from the encode endpoint. The id_base is the unique identifier for the widget type and sidebar is the id of the sidebar to assign the widget to. Both are required.

POST /wp/v2/widgets
{
	"instance": {
		"encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgSW5mbyI7fQ==",
		"hash": "0e9a5bff2d28cba322c8cd27cd4e77af",
		"raw": {
			"title": "Site Info"
		}
	},
	"sidebar": "sidebar-1",
	"id_base": "meta"
}

The endpoint will return information about the newly created widget.

{
  "id": "meta-1",
  "id_base": "meta",
  "sidebar": "sidebar-1",
  "rendered": "<div class=\"widget widget_meta\">...</div>",
  "rendered_form": "<p><label for=\"widget-meta-1-title\">Title:</label><input class=\"widefat\" id=\"widget-meta-1-title\" name=\"widget-meta[1][title]\" type=\"text\" value=\"Site Info\" /></p>",
  "instance": {
    "encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgTWV0YSI7fQ==",
    "hash": "dac44c3ebfa0428fed61829fa151e4e8",
    "raw": {
      "title": "Site Info"
    }
  },
  "_links": {
    "self": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/widgets/meta-1"
      }
    ],
    "collection": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/widgets"
      }
    ],
    "about": [
      {
        "embeddable": true,
        "href": "https://trunk.test/wp-json/wp/v2/widget-types/meta"
      }
    ],
    "wp:sidebar": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/sidebars/sidebar-1/"
      }
    ],
    "curies": [
      {
        "name": "wp",
        "href": "https://api.w.org/{rel}",
        "templated": true
      }
    ]
  }
}

Since the meta widget (and all other built-in widgets) is registered with show_instance_in_rest enabled you could bypass the encode endpoint and use instance.raw instead. For example, if we wanted to update the widget to have a new title, we could make the following PUT request to /wp/v2/widgets/meta-1.

PUT /wp/v2/widgets/meta-1
{
	"instance": {
		"raw": {
			"title": "Site Meta"
		}
	}
}

A PUT request can also be made to update the sidebar assigned to a widget by passing a new sidebar id in the request.

To delete a widget, send a DELETE request to the individual widget route. By default, deleting a widget will move a widget to the Inactive Widgets area. To permanently delete a widget, use the force parameter. For example: DELETE /wp/v2/widgets/meta-1?force=true.

Sidebars Endpoints

Found under /wp/v2/sidebars, the sidebars endpoint is used to manage a site’s registered sidebars (widget areas) and their assigned widgets. For example, the following is the response for the first footer area in the Twenty Twenty theme.

{
  "id": "sidebar-1",
  "name": "Footer #1",
  "description": "Widgets in this area will be displayed in the first column in the footer.",
  "class": "",
  "before_widget": "<div class=\"widget %2$s\"><div class=\"widget-content\">",
  "after_widget": "</div></div>",
  "before_title": "<h2 class=\"widget-title subheading heading-size-3\">",
  "after_title": "</h2>",
  "status": "active",
  "widgets": [
    "recent-posts-2",
    "recent-comments-2",
    "meta-1"
  ],
  "_links": {
    "collection": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/sidebars"
      }
    ],
    "self": [
      {
        "href": "https://trunk.test/wp-json/wp/v2/sidebars/sidebar-1"
      }
    ],
    "wp:widget": [
      {
        "embeddable": true,
        "href": "https://trunk.test/wp-json/wp/v2/widgets?sidebar=sidebar-1"
      }
    ],
    "curies": [
      {
        "name": "wp",
        "href": "https://api.w.org/{rel}",
        "templated": true
      }
    ]
  }
}

The widgets property contains an ordered list of widget ids. While all other properties are readonly, the widgets property can be used to reorder a sidebar’s assigned widgets. Any widget ids omitted when updating the sidebar will be assigned to the Inactive Widgets sidebar area.

For example, making a PUT request to /wp/v2/sidebars/sidebar-1 with the following body will remove the Recent Comments widget, and move the Meta widget to the top of the sidebar.

PUT /wp/v2/sidebars/sidebar-1
{
  "widgets": [
    "meta-1",
    "recent-posts-2"
  ]
}

For more information about the changes to widgets in 5.8, check out the Block-based Widgets Editor dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

Additional Changes

Posts Collection Tax Query Accepts operator

By default, a post must contain at least one of the requested terms to be included in the response. As of [51026], the REST API accepts a new operator property that can be set to AND to require a post to contain all of the requested terms.

For example, /wp/v2/posts?tags[terms]=1,2,3&tags[operator]=AND will return posts that have tags with the ids of 1, 2, and 3.

See #41287 for more details.

Props to @noisysocks for reviewing.

#5-8, #dev-notes, #rest-api

Block-based Widgets Editor in WordPress 5.8

WordPress 5.8 introduces a new 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 widgets editor to the Widgets screen (Appearance → Widgets) and CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (Appearance → Customize → Widgets). The new editor allows users to add blocks to their 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. areas using the familiar block editor interface introduced in WordPress 5.0. This gives users powerful new ways to customise their sites using the rich library of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and third party blocks. Existing widgets and third party widgets will continue to work and can be used alongside blocks.

Opting out of the block-based widgets editor

The block-based widgets editor is enabled in WordPress 5.8 by default. There are several ways to restore the classic editor:

  • A theme author may include remove_theme_support( 'widgets-block-editor' ). Learn more.
  • A site administrator may use the new use_widgets_block_editor filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. Learn more.
  • A user may install and activate the Classic Widgets plugin.

New Widgets screen

The widgets.php adminadmin (and super admin) screen (Appearance → Widgets) now loads a block-based widgets editor which exists in the @wordpress/edit-widgets package.

The editor is built using ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. and is similar to the editor used for posts and pages (@wordpress/edit-post) and uses many of the same subsystems: @wordpress/interface and @wordpress/components for UIUI User interface, @wordpress/block-editor for block editing, @wordpress/data and @wordpress/core-data for persisting changes, and so on.

A new filterable function, wp_use_widgets_block_editor(), is used by widgets.php to determine whether to load the new block-based editor or the classic editor.

The Widgets screen is extendable via block editor APIs such as registerPlugin, registerBlockType, registerBlockVariation, and so on.

The Widgets screen uses new REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. endpoints which are detailed in a seperate dev note.

New Customizer control

The Widgets section in the Customizer (Appearance → Customize → Widgets) now loads a new control (WP_Sidebar_Block_Editor_Control) which contains an embedded block-based widgets editor that exists in the @wordpress/customize-widgets package.

The editor is built using React and uses @wordpress/block-editor and @wordpress/components to implement its block editing interface. It does not use @wordpress/data or @wordpress/core-data to persist changes. Instead, the existing Customizer JavaScript API is used.

A new filterable function, wp_use_widgets_block_editor(), is used by WP_Customize_Manager to determine whether or not to log the new block-based editor control or the classic editor control.

The block-based widgets editor in the Customizer is extendable via block editor APIs such as registerBlockType, registerBlockVariation, and so on.

New block: Legacy Widget

Existing widgets and third party widgets can be edited in the block-based widgets editor via the new Legacy Widget block. This block has an identifier of core/legacy-widget and exists in the @wordpress/widgets package. The Legacy Widget block is compatible with most third party widgets.

Broadly speaking, the Legacy Widget block has three states:

  1. Select. When first inserted, the block displays a list of widgets available to choose from. The list can be customised using the widget_types_to_hide_from_legacy_widget_block filter.
  2. Edit. When selected, the block displays the widget’s control form fields. This is determined by the widget’s WP_Widget::form() implementation.
  3. Preview. When not selected, the block displays a preview of how the widget will look once saved. This is determined by the widget’s WP_Widget::widget() implementation. A “No preview available.” message is automatically shown when widget() does not output any meaningful HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. Learn more.

The Legacy Widget block is not available in other block editors including the post editor, though this can be enabled for advanced use cases.

New widget: Block

Blocks added to widget areas are persisted using the same widget storage mechanism added in WordPress 2.8. Under the hood, each block is serialised into HTML and stored in a block widget. This is represented by a new WP_Widget_Block subclass that extends WP_Widget. A block widget is a specialised case of the HTML widget and works very similarly.

If blocks are added to a widget area, and then the block-based widgets editor is disabled, the blocks will remain visible on the frontend and in the classic widgets screen.

Tips to prepare for the new block-based widgets editor

Use the widget-added event to bind event handlers

The Legacy Widget block will display a widget’s control form in a way that is very similar to the Customizer and is therefore compatible with most third party widgets. Care must be taken, however, to always initialise event handlers when the widget-added jQuery event is triggered on document.

( function ( $ ) {
    $( document ).on( 'widget-added', function ( $control ) {
        $control.find( '.change-password' ).on( 'change', function () {
            var isChecked = $( this ).prop( 'checked' );
            $control.find( '.password' ).toggleClass( 'hidden', ! isChecked );
        } );
    } );
} )( jQuery );

Use block_categories_all instead of block_categories

The block_categories filter has been deprecated and will only be called in the post and page block editor. PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers that wish to support the widgets block editor should use the new block_categories_all filter which is called in all editors. See #52920 for more details.

Allow migrating from widgets to blocks

Many core and third party widgets have a functionally equivalent block. For example, core’s Recent Posts widget is analogous to core’s Latest Posts block.

In order to avoid duplicate functionality, is is recommended that plugin authors provide a way for users to convert their existing widgets to any equivalent block. WordPress 5.8 provides a mechanism for doing this using block transforms:

  1. Configure your widget to display its instance in the REST API by setting show_instance_in_rest to true in $widget_options.
  2. Add a block transform to your block from the core/legacy-widget block.
  3. Hide your widget from the Legacy Widget block using the widget_types_to_hide_from_legacy_widget_block filter.

There is a guide containing more detailed instructions in the Block Editor Handbook.

Don’t use @wordpress/editor

Many legacy widgets call the wp.editor.initialize() 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/. function to instantiate a TinyMCE editor. If a plugin or block uses the @wordpress/editor package and enqueues wp-editor as a script dependency, this will re-define the wp.editor global, often resulting in a wp.editor.initialize is undefined error.


Written by @andraganescu and @noisysocks.
Thanks to @talldanwp, @isabel_brison, @kevin940726, and @get_dave for reviewing.

#5-8 #dev-notes #feature-widgets-block-editor #widgets #block-editor

Miscellaneous developer focused changes in WordPress 5.8

WordPress 5.8 brings a lot of smaller changes that developers should know about. Here’s a breakdown.

Build/Test Tools: Remove IE11 from the list of supported browsers

In WordPress 5.8, phase one of the dropping support for IE11 plan will take place. When considering three different data points, IE11 usage has fallen below a 1% average. After a discussion and debate, the decision was made to remove support for IE 11. In addition to opening the door for using more modern APIs, this will result in smaller script files, lower maintenance burden, and decreased build times.

The wp-polyfill script is responsible for ensuring all newer features function in the older browsers supported by WordPress. In past releases, this script was a copy of the file distributed in the @babel/polyfill package, which among other things, included regenerator-runtime.

This package was deprecated and has been replaced with the core-js package in the build process. core-js allows the polyfill file to be built dynamically, but no longer includes the regenerator-runtime script.

The regenerator-runtime script handle has been added to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and has been added as a dependency to wp-polyfill in order to be backwards compatible with any pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme registering wp-polyfill as a script dependency expecting regenerator-runtime to be present.

It is recommended that developers add the regenerator-runtime script as a dependency to any script that requires it. In future releases, removing regenerator-runtime as a dependency of wp-polyfill will be considered.

There are several other polyfill scripts included in WordPress for the sole purpose of IE11 support. They will continue to be included, but will no longer be loaded by default. They are:

  • wp-polyfill-dom-rect
  • wp-polyfill-element-closest
  • wp-polyfill-fetch
  • wp-polyfill-formdata
  • wp-polyfill-node-contains
  • wp-polyfill-object-fit
  • wp-polyfill-url

For more information, see #52941, #53077, and #53078.

Formatting: More consistency and control over wp_get_document_title()

In wp_get_document_title(), the returned value is currently passed directly through wptexturize(), convert_chars(), and capital_P_dangit(), and is done so after the document_title_parts filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. is run.

This makes it impossible to fully control the output of wp_get_document_title() and is inconsistent with how other similar text is processed with these functions.

The new document_title filter, which is run immediately before returning the results of the wp_get_document_title() function, moves the three formatting functions mentioned above to the new filter hook. This allows developers to further modify the title after being prepared by WordPress, or to modify the functions hooked to this filter as they wish.

For more information, see #51643.

General: Consistent type for integer properties of WP_Post, WP_Term, WP_User and a bookmark object

Some properties of the WP_PostWP_Term, and WP_User classes are documented as integers, so it should be a safe assumption to always treat them as such. However, that is not the case when get_post() or get_term() is called with an editattribute, or js context, because all values are run through esc_attr() or esc_js() in that case, and these properties are unexpectedly converted to strings.

This applies to the following functions:

  • sanitize_post_field()
  • sanitize_term_field()
  • sanitize_user_field()
  • sanitize_bookmark_field()

and the following properties:

  • WP_Post::ID
  • WP_Post::post_parent
  • WP_Post::menu_order
  • WP_Term::term_id
  • WP_Term::term_taxonomy_id
  • WP_Term::parent
  • WP_Term::count
  • WP_Term::term_group
  • WP_User::ID
  • $bookmark::link_id
  • $bookmark::link_rating

As WordPress moves towards strict type comparisons (see #52627 or #52482) it is important to make the type of these properties consistent in all contexts, so that using strict comparison does not cause unexpected issues.

In WordPress 5.8, these functions and properties will now reliably return an be set to integer values.

For more information, see #53235.

Posts/Post Types: Use _prime_post_caches() for speeding up cached get_pages() call

The get_pages() function uses a cache containing the ID of pages matching parameters of a previous call.

The IDs are, on a subsequent call with the same parameters, inflated using the get_post() function call. This works well in terms of the same request, as all the pages were previously added to the in-memory cache.

However, on a subsequent request, when the cache is hit, there are likely no pages already in the in-memory cache, and those need to be fetched from the backend cache server, one by one.

By taking advantage of wp_cache_get_multiple() instead of fetching each individual page from the backend cache server one by one, sites with persistent cache backend will have improved speed, but also sites without a persistent cache backend will benefit from the bulk SQL query constructed by the _prime_post_caches() function.

The performance gains should be most noticeable in case a site has a lot of pages which are being requested via get_pages() function.

For more information, see #51469.

Users: Pass $userdata to the actions and filters in wp_insert_user()

There are several action and filter hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. within wp_insert_user() that would benefit from being able to access the raw $userdata array passed into the function. One use case where this would be useful is extending the wp user import-csv command in WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/. This command is a wrapper for wp_insert_user() but it’s not possible to provide custom user metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields.

Here are the hooks gaining a new parameter:

  • wp_pre_insert_user_data (filter)
  • insert_user_meta (filter)
  • profile_update (action)
  • user_register (action)

This will allow hooked functions to perform more contextual adjustments to new users, and makes supplying custom user meta fields possible.

For more information, see #53110.

Media: Introduce image_editor_output_format filter

As detailed in a previously published dev note, WordPress 5.8 now supports the WebP image format.

WebP is a modern image format that provides improved lossless and lossy compression for images on the web. WebP images are around 30% smaller on average than their JPEG or PNG equivalents, resulting in sites that are faster and use less bandwidth. WebP is supported in all modern browsers according to caniuse.

WordPress 5.8 adds WebP support by @adamsilverstein

When images are uploaded, WordPress generates smaller sub sizes as defined using add_image_size(). By default, WordPress will generate these sub sizes in the same format as the original. Because of the performance benefits of the WebP format, it may be desirable for sub sizes to be generated in WebP instead of the original format.

In WordPress 5.8, the new image_editor_output_format filter hook can be used to change the file format used for image sub sizes. This can be used to switch all sub sizes to WebP, or any other desired format (JPEG, etc.).

The following example shows how to generate all sub sizes for JPG images using WebP:

<?php
function mysite_wp_image_editor_output_format( $formats ) {
	$formats['image/jpg'] = 'image/webp';

	return $formats;
}
add_filter( 'image_editor_output_format', 'mysite_wp_image_editor_output_format' );

Note: both the GD and ImageMagick libraries support the WebP format in both lossy and lossless. However, only ImageMagick supports animated images.

Setting the output format to WebP will verify if the web server supports it, and if not it will not change the format, i.e. won’t work.

For more information, see #52867.

General: Pass the scheme to all the *_url filters

A new parameter representing the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org $scheme has been added to admin_url, includes_url, network_admin_url and user_admin_url filters. This parameter is used for giving context to the URL (such as http, https, login, login_post, admin, relative or null) and was already present in other URL related filters (home_url, rest_url, site_url, to name a few).

For more information, see #52813.

Posts/Post Types: Improve post_exists() query

In previous releases, the post_exists() function did not make use of the database indexes available and was generating a poorly performing query. A new $status parameter has been added to allow developers to specify post_type, post_date and post_status to ensure that the wp_posts table’s type_status_date index is used when determining if a post exists.

For more information, see #34012.

Themes: Introduce the delete_theme and deleted_theme action hooks

These new theme action hooks bring parity to the plugin deletion process and fire immediately before and after an attempt to delete a theme, respectively.

For more information see #16401.

Props @desrosj and @azaozz for review and additional content.

#5-8, #dev-notes

CSS Chat Summary: 24 June 2021

The meeting took place here on Slack. @danfarrow facilitated and wrote up these notes.

Housekeeping

Discussion: Custom Properties (#49930)

hsl colours exploration

--wp-admin--color-neutral-h: 0;
--wp-admin--color-neutral-s: 0%;
--wp-admin--color-neutral-l: 100%;
--wp-admin--color-neutral-hsl:
   var(--wp-admin-color-neutral-h),
   var(--wp-admin-color-neutral-s),
   var(--wp-admin-color-neutral-l));
  • @ryelle pointed out that, as the WordPress colour palette doesn’t follow hsl we would need 3 distinct variables for each colour
  • @colorful-tones expressed a wish to see the core palette streamlined to the central column of colours and then for the other values to be generated using hsl variants using a core set of custom-properties, or new colours altogether
  • @ryelle reported having explored implementing dark mode by inverting colour values e.g. neutral-100 becomes neutral-0, but the results were unsatisfactory
    6
  • Perhaps the upcoming lch CSS colour feature will more readily enable this kind of approach

Crossover with editor (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/) custom-properties

  • @joyously asked if the custom-properties would apply to the UIUI User interface editor, and if the custom-property naming would follow the same convention
  • @ryelle clarified that currently the editor generates custom-properties like --wp-admin-theme-color for each colour scheme. These properties names will hopefully eventually converge with the new Custom Properties we are proposing

Performance

  • @joyously & @colorful-tones wondered if a large number of custom-properties could slow down browsers
  • @ryelle suggested that unchanging custom properties (which ours will mostly be) are less likely to have a negative impact

Workflow

  • @notlaura had asked about @ryelle’s workflow for adding custom properties has been. @ryelle clarified that she has been going through the values in common.css
  • As a way forward to working collaboratively on the PR she suggested each claiming a different file to work through

Cascading custom properties

  • @joyously asked if having many :root level properties is better than having a smaller number of properties which are then overwritten with specific selectors for each location
  • @ryelle responded that she would like to see how an inheritance based system would work
  • @danfarrow observed that the PR uses a form of inheritance by populating some properties with the values of others e.g. --wp-admin-menu--link--background--hover: var(--wp-admin-menu--background);
  • @ryelle explained that this will allow adminadmin (and super admin) schemes to set as few variables as possible, but also have the ability for more granular control if they need it
  • @joyously clarified that she was thinking more of “a small set of properties that are set for each class representing an area of the page”

CSS Link Share / Open Floor

Thanks everyone!

#core-css, #summary

Block supports API updates for WordPress 5.8

Expanding on previously implemented 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. supports in WordPress 5.6 and 5.7, WordPress 5.8 introduces several new block supports flags and new options to customize your registered blocks.

New Supports

color._experimentalDuotone – Adding duotone support to your block is a new experimental feature. To test, set this property to a string that specifies the CSSCSS Cascading Style Sheets. selector where you want to apply duotone. For example, in your block metadata:

supports: {
    color: {
        _experimentalDuotone: '> .duotone-img'
    }
}

color.link – Support for link color was added, this mirrors the usage and support for color.text that was added in WP 5.6.

To use in your block, add the supports flag in the block metadata:

supports: {
    color: {
        link: true;
    }
}

You can define a default value, using attributes and it will also use the values set in theme.json if present. For example:

attributes: {
  style: {
      type: 'object',
      default: {
          color: {
              link: '#FF0000',
          }
      }

Related ticketticket Created for both bug reports and feature development on the bug tracker.: #31524

Stabilized Supports 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.

Two features that were experimental in WordPress 5.7 have been stabilized in WordPress 5.8

  • fontSize previously __experimentalFontSize
  • lineHeight previously __experimentalLineHeight

See Block Supports API documentation for usage details.

The spacing support was updated and expanded to work for server-side blocks, as well as adding granular support to configure spacing for sides (top, right, bottom, left) individually. For example:

supports: {
    spacing: {
        margin: true,  // Enable margin UI control.
        padding: true, // Enable padding UI control.
    }
}

The following example configures side support for just top and bottom:

supports: {
    spacing: {
        margin: [ 'top', 'bottom' ], // Enable margin for arbitrary sides.
        padding: true,               // Enable padding for all sides.
    }
}

The spacing supports can target specific blocks using theme.json, or it’s own attributes. For example, customizing the top and bottom margins for the core/separator block:

"styles": {
    "blocks": {
        "core/separator": {
            "spacing": {
                "margin": {
                    "top": "100px",
                    "bottom": "100px"
                }
            }
        }
    }
}

Props to @mkaz and @nosolosw for help with compiling this dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

Related PRs: #31808, #31332

Tags: #5.8 #dev-notes #gutenberg

Introducing theme.json in WordPress 5.8

WordPress 5.8 comes with a new mechanism to configure the editor that enables a finer-grained control and introduces the first step in managing styles for future WordPress releases.

Controlling settings globally and per blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.

The introduction of blocks has increased the number of settings agencies and developers may need control over. Having a central point of configuration aims to provide a more consistent and complete experience.

By creating a theme.json file in the theme’s top-level directory, themes can configure the existing editor settings (the font sizes preset, whether custom colors are enabled, etc.) as well as the new ones as they are introduced (the duotone preset, whether margin and padding controls are enabled, etc.).

This new mechanism aims to take over and consolidate all the various add_theme_support calls that were previously required for controlling the editor.

The example below shows how to disable custom colors for all blocks:

{
    "version": 1,
    "settings": {
        "color": {
            "custom": false
        }
    }
}

The addition of the theme.json file also provides a way for theme authors to control these settings on a per-block basis ― something that wasn’t possible before. The example below shows how to disable custom colors for all blocks but enable them for the paragraph block:

{
    "version": 1,
    "settings": {
        "color": {
            "custom": false
        },
        "blocks": {
            "core/paragraph": {
                "color": {
                    "custom": true
                }
            }
        }
    }
}

Top-level settings will apply to all blocks that support the relevant setting. However, block-level settings can also override the top-level settings for a specific block. Blocks are addressed by their block name and settings can be added for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as well as third-party blocks.

Note: to retain backward compatibility, the existing add_theme_support declarations from the theme are retrofitted in the proper categories for the top-level section. For example, if a theme uses add_theme_support('disable-custom-colors'), the result will be the same as setting settings.color.custom to false. If a setting is declared in theme.json that setting will take precedence over the values declared via add_theme_support.

See the specification document for a complete list of features and backcompatibility with add_theme_support.

Blocks can access theme settings with useSetting

Core blocks have been updated to respect the new settings coming from a theme via theme.json. For example, if a block supports a UIUI User interface margin control but the theme has disabled margin across the board, the UI control will not be displayed in the editor.

Third-party blocks can also tap into this mechanism by using the useSetting ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. hook in its edit function:

import { useSetting } from '@wordpress/block-editor';
// Somewhere in the block's edit function.

const isEnabled = useSetting( 'spacing.margin' );

if ( ! isEnabled ) {
    return null;
} else {
    return <ToggleControl ... />
}

See the API docs for useSetting.

CSSCSS Cascading Style Sheets. classes for presets are automatically created and enqueued

Previously, themes had to declare presets for the editor and also enqueue the corresponding classes separately.

In the functions.php file, they’d do:

add_theme_support(
  'editor-color-palette',
  array(  /* define color presets, including translations */
) );

And then, in the style.css:

.has-<value>-color { /* ... */ }
.has-<value>-background-color { /* ... */ }
/* etc */

By using a theme.json, the theme only has to declare their presets. The engine will set up the translations and will take care of creating and enqueuing the corresponding styles to both the editor and the front-end:

{
    "version": 1,
    "settings": {
        "color": {
            "palette": [
                {
                    "name": "Color name",
                    "slug": "color-slug",
                    "color": "<color-value>"
                },
                {
                    "name": "...",
                    "slug": "...",
                    "color": "..."
                }
            ]
        }
    }
}

See the specification document for a list of classes generated by preset.

CSS Custom Properties

By phasing out IE11 support, many CSS features become available. One of these now available features is CSS Custom Properties. When a theme adds presets via theme.json, the engine will enqueue both classes and CSS Custom Properties for them.

The example below:

{
    "version": 1,
    "settings": {
        "color": {
            "palette": [
                {
                    "name": "Black",
                    "slug": "black",
                    "color": "#000000"
                },
                {
                    "name": "White",
                    "slug": "white",
                    "color": "#ffffff"
                }
            ]
        }
    }
}

will create this output in CSS:

/* One CSS Custom Property per preset value. */
body {
  --wp--preset--color--black: #000000;
  --wp--preset--color--white: #ffffff;
}

/* The corresponding classes for each preset value. */

.has-black-color { color: var(--wp--preset--color--black) !important; }
.has-black-background-color { background-color: var(--wp--preset--color--black) !important;  }

.has-white-color { color: var(--wp--preset--color--white) !important; }
.has-white-background-color { background-color: var(--wp--preset--color--white) !important;  }

See the specification document for more examples, how to add and use custom properties unrelated to presets, etc.

Managed styles for improved coordination

One of the struggles theme authors face is the conflicts that appear in an environment with core, theme, and user styles as well as the wide design area that comes with multiple blocks that can be combined indefinitely.

The theme.json file absorbs most of the common use cases for styling blocks with the goal of reducing the amount of CSS shipped to the browser, mitigating specificity wars, and providing current style info in the UI controls for users. This is the first step in having a mechanism that consolidates all the three origins of styles (core, theme, user) and that will become more important once users can provide global styles in later phases of the project.

In the example below, a theme provides styles for the top-level and a couple of blocks:

{
    "version": 1,
    "styles": {
        "color": {
            "text": "var(--wp--preset--color--primary)"
        },
        "blocks": {
            "core/paragraph": {
                "color": {
                    "text": "var(--wp--preset--color--secondary)"
                }
            },
            "core/group": {
                "color": {
                    "text": "var(--wp--preset--color--tertiary)"
                }
            }
        }
    }
}

It results in the following CSS output:

/* Top-level styles resolve to the body selector. */body {
  color: var(--wp--preset--color--primary );
}

/* Block styles resolve to the block selector. */
p {
  color: var(--wp--preset--color--secondary );
}
.wp-block-group {
  color: var(--wp--preset--color-tertiary );
}

Any block, both core and third-party, can be targeted by its name.

See the specification document for a complete list of supported styles.

Access to other features

There are some features that are enabled or disabled when a theme has support for a theme.json file:

  • The template editor is enabled.
  • The default layout and margin styles for themes are not enqueued and the new layout options are enabled instead (see related dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for layout).
  • The inner div for the group block (wp-block-group__inner-container) is removed.
  • The default font-family styles for the editor are not enqueued.

#5-8 #dev-notes #gutenberg

What’s new in Gutenberg 10.9? (23 June)

Two weeks have passed since the last GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ release, which means the time has come for a new version. Gutenberg 10.9 introduces rich URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org previews for Link Control, the ability to expand/collapse nested blocks in List View, and a new name for the Query LoopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. 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. — Post Template. The release also includes enhancements and 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 for Widgets Editor.

Rich URL Previews

When clicking on links in the editor, it’s now possible to see a rich preview of a URL including site title, meta description, icon and image. This is the first feature to take advantage of the new `url-details` endpoint, the enhanced form of which was shipped in 10.8. Currently, rich previews are only enabled for links which point to external URLs and then only for rich text blocks that utilize the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. link format library. In the near future however, we expect to extend this to provide previews of internal URLs and to roll out support to more areas of the software.

List View Enhancements

This release brings a new feature to the List View. It’s now possible to expand and collapse nested blocks, which helps users navigate complex block structures. For example, users can collapse the content in sibling columns to concentrate on that hierarchy level and expand a single column to focus on it.

A new home for the Block Manager

The Block Manager has been moved from the Tools menu, and is now integrated with the new Preferences modal under the Blocks section, consolidating all editor-related preferences in the same modal.

Block Manager preferences

Updated template creation modal

This modal has been polished, including an improved welcome guide, to make creating new templates a breeze.

Renamed Query and Query Loop blocks

With the Query and Query Loop blocks becoming stable and coming to WordPress 5.8, they have been renamed to increase clarity about their functionality. The Query Loop block has been renamed to Post Template to better represent its purpose within Query, whereas the Query block label now refers to it as Query Loop.

10.9

Enhancements

  • Components:
    • UnitControl: Reduce code duplication for defined units. (32731)
    • BoxControl: Add support for grouped directions (vertical and horizontal controls). (32610)
    • Notice: Added onDismiss option in createInfoNotice. (32338)
  • Block Library:
    • Latest Posts: Limit latest-post authors dropdown to users with published posts. (32662)
    • Calendar: Add loading and empty state. (31504)
    • Query Loop: Add helpful text to the block. (32694)
    • Query Loop: Rename QueryLoop to PostTemplate and change Query label. (32514)
    • Spacer: Try an alternate min-height fix. (32543)
    • Heading: Show all heading levels in toolbar group. (32483)
    • Post Terms: Add a CSSCSS Cascading Style Sheets. class to identify the taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.. (31832)
    • Legacy 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.: Move block to @wordpress/widgets. (32501)
  • Block Editor:
    • Enhance link control UIUI User interface with rich URL previews. (31464)
    • List View: Allow expanding and collapsing of nested blocks. (32117)
    • Editor Breadcrumb: Add a rootLabelText prop. (32528)
    • Don’t hardcode CSS units. (32482)
    • Refactor LinkControl component to support ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 17. (32552)
    • Remove snapshots from tests for LinkControl. (32592)
  • Block Support:
    • Update border support to allow non-pixel units. (31483)
  • Icons:
    • Add new icons. (32371)
    • Tweak people icon. (32354)
    • Expose trendingDown and trendindUp icons. (32124)
  • Template Editing Mode:
    • Update welcome guide language for the template editor. (32639)
    • Translate delete template confirmation message. (32647)
    • Disable renaming templates named by core; Display descriptions. (32636)
    • Update the template creation modal. (32427)
  • Post Editor:
    • Use the post type singular_name as the root Block Breadcrumb label. (32609)
    • Absorb block manager within blocks preferences. (32166)
  • Widget Editor:
    • Hide some settings from the “Options” menu on small screens. (32690)
    • Add Breadcrumbs Block. (32498)
    • Use button block appender in widget areas. (32580)
    • Add show block bread crumbs feature toggle to more menu. (32569)
    • Unhide the classic menu widget. (32431)

Bug Fixes

  • Block Library:
    • Image Block: Fix cover block exists check. (32666)
    • Embed: Fix embed to paragraph transform when caption has rich text formats. (32355)
    • Columns: Fix deprecation caused when adding a column. (32378)
    • Site Logo: Fix site-logo not getting removed on remove_theme_mod. (32370)
    • Social: Try to fix color inheritance for social links. (32625)
    • Social: Correctly position the link popover when List View is open. (32525)
    • Code: Try an experimentalSelector. (31742)
  • Block Editor:
    • RichText: Fix loss of list content when switching list types. (32432)
    • useBlockDropZone: Fix horizontal indicator. (32589)
    • Inserter: Fix insertion point displaying when there are no inserter items. (32576)
    • Drop indicator: Show around dragged block and show above selected block for file drop. (31896)
    • Fix vertical scroll in horizontal toolbar. (32655)
    • Fix block multi selection in nested blocks. (32536)
    • Fix block toolbar overlap with headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. (32424)
  • Blocks:
    • Avoid keeping the same client ID when transforming blocks. (32453)
    • Allow themes to add inline styles for all blocks when using lazy styles loading. (32275)
  • Components:
    • RadioControl: Add hideLabelFromVision prop. (32414)
    • DatePicker: Fix crash when navigating between months. (31751)
    • Autocomplete: Prevent setting state for unmounted component. (32654)
  • Editor:
    • Make link UI rich previews target agnostic and fix unwanted preview for internal URLs. (32658)
  • Widget Editor:
    • Don’t delete a widget if it is moved to a different area. (32608)
    • Fix button spacing in header. (32585)
    • Decode HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. entities for name and description props. (32503)
    • Fix dirty state after adding new block. (32573)
    • Don’t add undo levels when editing records on save. (32572)
    • Save deleted and restored widgets. (32534)
    • Don’t show widgets in menu without theme support. (32420)
    • Fix inspector opening on click outside widget area. (32450)
    • Legacy Widget: Don’t display “No preview” when widget has image tags. (32605)
  • Post Editor:
    • Prevent locking users in saving state when saving metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes fails. (32485)
    • Edit Post: Add metaBoxUpdatesFailure action. (32623)
  • Full Site Editing
    • Only add skip-link for block themes & templates on the frontend. (32451)
  • Storybook:
    • Fix misc warnings. (32401)
  • Data:
    • useSelect: Silently error (for block zombie children). (32088)

Performance

  • Block Editor: Remove is-typing root class. (32567)
  • Header Toolbar: UseCallback to avoid unnecessary rerenders. (32406)

Experiments

  • Component System:
    • Promote Scrollable component to a full export. (32446)
    • Promote Surface component to a full export. (32439)
  • Global Styles:
    • Allow presets to provide an empty set of values. (32679)
    • Allow theme authors hook into the preset classes generated by global styles. (32627)
    • Update WP_Theme_JSON 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. so presets are always keyed by origin. (32622)
    • Make syntax errors in theme.json visible to users. (32404)
    • Enqueue global styles in editor only once. (32377)
    • Enqueue core and theme colors by using separate structures per origin. (32358)
    • Do not migrate the old typography support if core already did it. (32487)
    • Generate classes and custom properties for global styles in the same way the post editor does. (32766)
  • Full Site Editing:
    • Template resolution for new posts and pages. (32442)
    • Monopolize navigation in Site Editor. (31810)
    • Prevent duplicate queries. (32700)
    • Split theme.css styles loading. (31239)
  • Navigation Editor:
    • Alternative fix: Set persisted menu id when no menus or missing menu. (32313)

Documentation

  • Handbook:
    • Update references to register_block_type_from_metadata. (32582)
    • Fix duotone support documentation. (32440)
    • Detail the Gutenberg release post process. (32429)
    • Update Legacy Widget documentation with new info on show_instance_in_rest feature. (32726)

Code Quality

  • Components:
    • Remove duplicated compose dependencies. (32709)
    • Sort entries in packages/components/tsconfig.json. (32675)
    • Update the popover component to rely on useDialog. (27675)
    • Card: Add types. (32561)
    • Card: Refactor subcomponents folder structure. (32557)
  • Compose:
    • Add types to useDialog and useFocusOnMount. (32676)
    • Add types to withSafeTimeout. (32674)
    • Type withState as any. (32326)
  • Block Library:
    • Page List: Avoid generic function names for page list block internal functions. (32736)
    • Latest Comments: Correct the format used for duplicate hook documentation. (32563)
    • Login/out: Update documentation for render_block_core_loginout function. (32158)
  • Block Editor: Remove unused select block function. (32532)
  • Core Data: Fix typos. (32480)
  • Editor: Fix different typos in inline comments, deprecation warnings and variable names. (32474)
  • Linting:
    • Edit Post: Fix no-string-literals warning. (32518)
    • Add ESLint import resolver. (31792)
  • PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party:

Tools

  • Workflow:
    • Fix the add milestone githubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ action. (32691)
    • Use a different cache key for the PR automation workflow. (32588)
    • Improvements to NPM package caching across workflows. (32458)
    • Limit when release artifacts are built on forks: Pt. 2. (32494)
  • Build:
    • Load .min.js files even in dev mode, output unminified assets only in prod. (32621)
    • Upgrade husky package to the latest version. (32077)
    • Generate minified .min.js and unminified .js files for GB js entry points when building. (31732)
    • Include Legacy Widget block files in the plugin build. (32803)
  • End to End Tests:
    • Update mentions tests to use toMatchInlineSnapshot. (32727)
    • Add more user auto-completer (mentions) coverage. (32697)
    • Ignore JQMIGRATE (jQuery migrate) deprecation warnings. (32656)
  • Linting:
    • Update linting and formatting for test plugin files. (28033)
    • Update Eslint JSDoc package, introducing JSDoc line alignment check. (25300)
  • wp-env: Bump TT1 Blocks to v0.4.7. (32661)

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~36,000 words, ~1,000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

VersionLoading TimeKeyPress Event (typing)
Gutenberg 10.94.50s28.93ms
Gutenberg 10.84.91s30.30ms
WordPress 5.75.71s32.09ms

Kudos to all the contributors that helped with the release! 👏

Thanks, @priethor, @get_dave, and @mikeschroder for helping with the release post.  Thanks to @youknowriad and @bernhard-reiter for coordinating the release.

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

CSS Chat Agenda: June 24, 2021

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday June 24 at 21:00 PM UTC.

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

  • Housekeeping
  • Discussion: Custom Properties (#49930)
    Discuss the workflow for adding Custom Properties to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
    Cross-reference with related Gutenberg discussion (thanks @colorful-tones!)
  • Open Floor + CSS Link Share

If there’s any topic you’d like to discuss, please leave a comment below!

#agenda