WordPress 5.8 ‘Tatum’ Retrospective

A lot of things changed with the way that the WordPress 5.8 release was managed. A retrospective is always a good idea after a project, but in this case I wanted to be sure I cataloged the big changes for anyone who felt that it was different, but couldn’t quite put words to it. I originally shared this with the release team in Slack.

  • The teamwork had a different feeling. Instead of having buddies or cohorts of learning contributors (roughly one-to-one), we put the squad in a public channel to coordinate the work (one-to-many).
  • The release process had a different feeling. We made feature freeze independent of any other type of milestone and also are trying to be more focused about what work is done in each phase.
  • The included features had a different feeling. Instead of flipping the switch on a massive change for everyone, full site editing is being being shipped in smaller, more manageable chunks so it’s easier to catch up and we can iterate as we go.
  • The environment is different. We’ve all been struggling through this pandemic and being isolated from those we care for. Whether we recognize it or not, that has a profound impact on what we choose to do with our spare time, how we are able to meet others where they are, and whether we “grow through” or “bounce back” from hurdles that stand in our way.

Anyone is welcome to participate in this retro, so please take a few moments to fill in the form or leave public feedback in the comments below. It is not anonymous in case I need some clarification, but your email address will not be kept. The form will be open until August 15, 2021.

Thank you everyone for your contribution to this release, and thanks in advance for taking the time to help make future releases even better!

#5-8, #retrospective

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 note 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

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.

Don’t use functions like is_admin() that won’t work in a REST API request

Because the Legacy Widget block makes REST API requests in order to render widgets, admin-only functions like is_admin() and is_plugin_available() are not available.


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

On layout and content width in WordPress 5.8

WordPress 5.8 introduces Global Settings and Global Styles. They allow theme authors to control and style the available features in the editor and the different blocks using a 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..

By using a theme.json file, in addition to the Global styles and settings capabilities, theme authors opt-in into the layout feature for 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. containers.

Layout config

Historically, themes had the responsibility to provide CSSCSS Cascading Style Sheets. styles in order to support aligning content (left, right). With the introduction of the block editor in WordPress 5.0, new alignments has been added to the mix (wide, full). In addition to that, the block editor allowed users to use container blocks (group, columns blocks) which potentially can change how their inner blocks are positioned and aligned. Taking all these variations into consideration has become a very difficult task for theme authors. To address these issues, WordPress 5.8 introduces the layout feature and config.

How do I migrate my theme

Themes that have a centered content area, need to define a layout setting in their `theme.json` file:

{
   "settings": {
       "layout": {
           "contentSize": "800px",
           "wideSize": "1000px"
       }
   }
}  

The block-editor will automatically read this config and provide the corresponding styles in the editor. It will allow all alignments to work properly without requiring the `add_theme_support( ‘align-wide’ )` call.

Themes are still required to provide the corresponding styles in the frontend of their sites, something like:

.entry-content > * {
    max-width: 800px;
    margin-left: auto !important;
    margin-right: auto !important;
}

.entry-content > .alignwide {
    max-width: 1000px;
}

.entry-content > .alignfull {
    max-width: none;
}

.entry-content > .alignleft {
    float: left;
	margin-right: 2em;
}

.entry-content > .alignright {
    float: right;
	margin-right: 2em;
}

Note:

It’s not possible for WordPress to generate these styles automatically for all themes because the entry-content className in the example above is not mandatory and may not exist. In the future, with the introduction of the upcoming block themes, these styles won’t be needed anymore.

Nested Blocks

For themes with the layout config enabled, container blocks (like group blocks) do not automatically inherit the layout config. Meaning the blocks added inside the containers will by default take all the available space and not have any wide/full alignments options unless the user defines the wide and content sizes for that particular container block or “inherits” the config from the default layout.

This also means that themers can drop any alignment specific CSS that was added specifically to support nested blocks.

#5-8, #dev-notes, #gutenberg

[Request for feedback] Updater Proof of Concept

Over the past month, @aristath and @sergeybiryukov have been working on a proof of concept to solve the two first outcomes highlighted in the Updater Initiative scope post.

They drew inspiration from the https://wordpress.org/plugins/rollback-update-failure/ 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 and tried to address a few tickets.

They created a proof of concept that can be found in a draft PR on https://github.com/WordPress/wordpress-develop/pull/1492/files and does the following:

  • Add new arguments to hook_extra passed by plugin and theme updates to ensure we can rollback to the correct version.
  • After a plugin/theme is successfully downloaded and extracted, the old plugin/theme folder is moved to wp-content/upgrade/rollback/plugins/PLUGIN or wp-content/upgrade/themes/THEME wp-content/upgrade/rollback/themes/THEME (thanks Paul Bigai for catching that)
  • If the plugin/theme was successfully installed, the backup of the previous version we kept in wp-content/upgrade/rollback/ is deleted.
  • If the plugin/theme was not successfully installed, then we cleanup any remnants of files in wp-content/plugins/PLUGIN (or the corresponding folder for themes), and then we move the backup we kept in the rollbacks folder back to its original location.
  • Adds info in the site-health screen, to make sure the rollback folder is writable (or can be created if it doesn’t exist)

That is the basic concept. The team ran some tests, helped by @peona as well and it seems to be working.

The main difference with the rollback-update-failure plugin is that this solution moves the plugin/theme folders instead of zipping/unzipping them. This change should help to make the implementation a bit lighter/safer on shared hosts with limited resources.

Before moving forward, I would like to ask the Upgrade/Install Maintainers to have a look at this and discuss together, in the comments of this post, if you agree with this change, if it works, etc…

I am not setting a deadline for the comments, but ideally, I would like to be able to write a merge proposal for 5.9 so I will review the post in mid-JulyAugust (thanks @meher for pointing out that we are at the end of July already 😂) and nudge a bit more 😉

Thank you all for your help and feedback!

Thanks @ipstenu for the peer review

#updater

WordPress 5.8 Field Guide


UPDATE on 12 July 2021: The Miscellaneous block editor API additions in WordPress 5.8 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. was added to the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor section.


Whether you are a WordPress website user, builder, or developer, WordPress 5.8 brings exciting changes and a hint of even more goodies coming in WordPress 5.9. But we’re getting ahead of ourselves; let us take a look at what to expect in when 5.8 is released.

The WordPress 5.8 release cycle is different from previous ones in several ways, but the release squad navigates it with ease, even though not entirely without pressure. One of these differences is a decision to include an unplanned Beta 4 into the release cycle. This is not such a surprise, given that there are 96 enhancements and feature requests, 170 bug fixes and 24 other blessed tasks, which brings us to 290 Trac tickets in total.

In this Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page., you will notice what is relevant to you and your users among the many improvements coming in 5.8.

Block Editor

The block editor moves onward with regular releases. 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/ version 10.7 is bundled with WordPress 5.8; that totals eight Gutenberg releases (versions 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, and 10.7) all merged into this WordPress release (as the related Gutenberg handbook page makes clear)! Bug fixes and performance improvements from Gutenberg versions 10.8 and 10.9 are also part of 5.8.

The WordPress 5.8 Beta 1 post highlights a lot of the version’s new features and improvements:

  • New site editing blocks
  • The powerful query block
  • The block List view
  • Duotone image effects
  • Updates to existing blocks
  • Recommended patterns

As well, those recommendations integrate with the Pattern Directory on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, template editor, theme.json, and blocks in 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 among other changes.

In the block editor-related dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. below are important details on how theme.json delivers editor style control and associated Global Settings and Global Styles, plus:

  • Blocks in widget areas
  • block.json as canonical way to register block styles
  • deprecation of filters and introduction of context-aware replacements
  • Removal of previously deprecated EditorGlobalKeyboardShortcuts component, hasUploadPermissions selector, and hidden Subheading block
  • The iframed template editor portion of Full Site Editing
  • Block-styles loading enhancements

Media

Amongst all Media changes, the highlight is support for the WebP image format. Accompanied by new image_editor_output_format 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. (see #52867), it will set foundation for a real performance boost. You will also notice some UIUI User interface improvements, such as replacing infinite scroll with AJAX response (#50105 and #40330) and copy-link button on media upload screen (#51754).

Plugins

Changes in the Plugins component aim to make 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 lives easier. From better docs search (#50734) and standardizing 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. terminology (#50531) to ability to mark plugins as unmanaged (#32101) and avoid overwriting plugin files caused by update conflicts.

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/.

REST API changes are mainly focused on Widgets and sidebars but there is also a new operator for 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. queries within post collections, support for the eagerly awaited AND comparison, which allows posts meeting all passed criteria are matched (#41287).

Site Health

Amongst the UI fixes, Site Health changes bring new actions for extending the navigation in the Site Health screen (#47225). You will also find new info provided by Site Health via a list of the supported file types for the active image editor (#53022).

Themes

Across the Themes changes you will find two new action hooks, delete_theme and deleted_theme (#16401), a few UI improvements such as clearly showing if a theme is a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. (#30240), update counter in adminadmin (and super admin) menu item (#43697), and removal of “Featured” tab in Add Themes screen (#49487).

Also, older bundled themes are refreshed with some really nice block patterns for your pleasure and inspiration.

Other Developer Updates

There are even more goodies in 5.8! Read through the dev notes below to see details on how Internet Explorer 11 support is being dropped as well as assorted changes to the Bootstrap/Load, Build/Test Tools, Formatting, General, Media, Posts/Post Types, RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., Themes, and Users components.

Alongside the dev notes below, also worth noting is that work has continued during the 5.8 release cycle to increase the compatibility with PHP8 and its new features. Please continue to test your code against PHP8 as we all work towards raising the entire WordPress ecosystem compatibility with PHP8, thank you!

But Wait, There is More!

5.8 offers so much more! Over 170 bugs, 96 enhancements and feature requests, and 24 blessed tasks have been marked as fixed in WordPress 5.8.

Here are a few that haven’t been highlighted:

  • Build/Test Tools: Remove @babel/polyfill in favor of core-js/stable, requires explicit addition of regenerator-runtime as script dependency if IE11 support is still required (#52941).
  • Bundled Theme: Add Block Patterns to Twenty Ten to Twenty Fifteen default themes (#51107, #51106, #51105, #51104, #51103, #51102).
  • Comments: comments_pagination_base missing in get_comment_reply_link() function (#51189).
  • Comments: Comments list’s link should point to an actual article (#52353).
  • Embeds: Process embeds for block widgets (#51566).
  • Emoji: Bump Twemoji from 13.0.1 to 13.1.0 (#52852).
  • External Libraries: Bump jQuery from 3.5.1 to 3.6.0 (#52707).
  • External Libraries: Bump Moment.js from 2.27.0 to 2.29.1 (#52853).
  • External Libraries: Bump Requests from 1.7.0 to 1.8.1 (#53101 and #53334).
  • External Libraries: Bump Underscore from 1.8.3 to 1.13.1 (#45785).
  • Media: Remove infinite scrolling behavior from the Media grid (#50105).
  • Media: Add a copy-link button at the media upload page (#51754).
  • Menus: Add ability to delete multiple menu items (#21603).
  • Revisions: a new dynamic filter to specify post type for number of revisions to save, wp_{$post->post_type}_revisions_to_keep (#51550).
  • Role/Capability: user_can() changed for exist capability for anonymous users (#52076).
  • Upgrade/Install: Remove parsing of readme.txt files from validate_plugin_requirements() (#48520).
  • Upgrade/Install: Fatal error during update to 5.8 of a site with an active Gutenberg plugin (version less than 10.7) (#53432).
  • Widgets: Make sure WP_Widget constructor creates a correct classname value for a namespaced widget class (#44098).
  • And much, much more!

Please, test your code. Fixing issues that your code has with WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. helps you and millions of WordPress sites.

Props to @jeffpaul and @desrosj for contributing to this guide.

#5-8, #field-guide

Consistent minor release squad leaders for each major branch: Trial run retrospective and 5.8.x releases

During the 5.8 release cycle, a Release LeadRelease Lead The community member ultimately responsible for the Release. and Release Deputy was named for all 5.7.x releases in a trial run. The experiment was an attempt to address several pain points that made executing minor releases needlessly difficult. Each of the pain points of the minor release cycle were expanded in detail in the original post.

For the 5.7.x releases, @peterwilsoncc and @audrasjb were named as Release Lead and Release Deputy respectively. In the months between the 5.7 and 5.8 releases, they successfully planned and released 2 minor 5.7.x versions with an average of 4.5 weeks between each. The gap between the final 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. (5.7.2) and 5.8 was 9.7 weeks.

Feedback

In an effort to evaluate how this process went, they were asked for some answers to a handful of questions. Here is some collected feedback from @peterwilsoncc on how the process went.

What went well?

Generally I thought the experiment was successful and it was good to be able to concentrate (and only be expected to concentrate) on the minor releases rather than try to track both major and minor. More specifically:

  • Getting a few more people in the AEST timezone involved than usual helped with coordination.
  • Starting early my time for releases was good for the .1 version as it went longer than expected.
  • Probably should have asked for author rather than contributor permission on w.org/news so I could actually publish the posts I prepared.
  • Having scripts prepped a day in advance was great at reducing stress and allowed for dry-runs (excluding commit).

What went poorly?

  • Night owls or not, I don’t think it was great having me in APAC and @audrasjb in EU working as team leads, everything that was good about release times for me was exactly the reverse for @audrasjb (and @desrosj but to a lesser extent).
  • Better prep on the .1 release could have shortened the time for committing and moving on to the release party.
  • Needed to pull in a couple of people on the release day for the .1 release.
  • Finding someone with mission control access is not easy (especially in timezone). The list of those with permissions is really out of date, and some probably don’t need release permission any more.
  • I didn’t delegate some of the adminadmin (and super admin) stuff well and ended up doing a fair bit at the last minute as a result (on me for not asking).

What did you learn?

  • How to release 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/ packages, although doing so on my first production commits to the repository was a little brave.
  • Depending on the number of security backports, and how far back they need to go, release day for a minor can be busier than a major.
  • Process page in the handbook is quite out of date: updated a few steps after each of the two releases.

What support did you receive?

A lot.

  • @gziolo and @isabel_brison helped a great deal with getting the Gutenberg release process down, especially @gziolo by updating the undocumented steps as I asked questions.
  • @audrasjb, @desrosj and @whyisjake with release processes, both in advance and on the day.
  • Code review of shell scripts to attempt to speed up the process.
  • @dd32 with release day stuff, including catching quite a few things I was unaware of on the day.


What support could you have used?

Needed a lot more support from editor team with some planning tasks. The team was consumed with 5.8 and Full Site Editing, so they did not have much time to spare.

What were some responsibilities or tasks you had to take care of that you did not anticipate?

  • Expected I’d need to prep some release day scripts, but didn’t realize how many until I started doing them. Again, probably would have been helped by better delegation
  • Didn’t realize I’d need to do NPM releases at the start but figured it out well before the actual release

Anything else you feel is worth sharing?

Generally I think it went well and was successful.

Continuing the trial in 5.8.x releases

Because the experiment was generally successful, it will be repeated in 5.8.x releases. To reiterate the ideal criteria that was listed in the original proposal, the two contributors serving as release lead and release deputy will be responsible for:

  • Publishing timelines and plans for each minor release.
  • Executing these plans through release day.
  • Coordinating with the Security Team lead to improve the flow of fixes from the team to users.
  • Assembling and requesting help from other volunteers for each release as deemed necessary (docs, test, specific focus areas, etc.).

Ideally, one of these two contributors has a technical background (with the abilities to identify, confirm, test, and approve 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 changes), and the other has a project manager or coordinator background (with the abilities to create release timelines, coordinate contributors, and help unblock efforts).

One additional (potentially optional) criteria would be that either the lead or deputy be a part of the previous major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.’s squad, or be very familiar with the changes that were introduced in that major release. This would further increase the speed at which the minor releases are able to fix related bugs, as they are already “up to speed” on the changes.

In recent years, the gap between major releases has been, on average, 3 to 5 months. If necessary, contributors can 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.) in and out of the role should circumstances change and it becomes necessary.

If you’re interested in volunteering as a Release Lead or Release Deputy for the 5.8.x releases, please comment below!

Props @peterwilsoncc and @audrasjb for their great work during the 5.7.1 and 5.7.2 releases, and @chanthaboune for pre-publish review.

#5-7, #5-8

Block-styles loading enhancements in WordPress 5.8

WordPress 5.8 improves the way we load 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.-styles by introducing 2 new features:

  • Load styles only for rendered blocks in a page
  • Inline small styles

Only load styles for used blocks

This is an opt-in, non-breaking change. Using the should_load_separate_core_block_assets 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., developers can opt-in to this feature:

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

Prior to WordPress 5.8, styles for all blocks were included in a style.css file that gets loaded on every page. By opting-in to separate styles loading, the following will happen:

  • The wp-block-library stylesheet changes: Instead of loading the wp-includes/css/dist/block-library/style.css file which contains all styles for all blocks, this handle will now load the (much smaller) wp-includes/css/dist/block-library/common.css file, which contains generic styles like the default colors definitions, basic styles for text alignments, and styles for the .screen-reader-text class.
  • Styles for blocks will only get enqueued when the block gets rendered on a page.

The above changes will only apply to the frontend of a site, so all editor styles will continue to work as they did before.

The difference between block themes and classic themes

Block themes

In a block theme, blocks get parsed before the <head> so we always know which blocks will be present prior to rendering a page. This makes it possible to add the block styles to the <head> of our document.

Classic themes

In a classic, php-based theme, when a page starts to render, WordPress is not aware which blocks exist on a page and which don’t. Blocks gets parsed on render, and what that means is that block-styles don’t get added in the <head> of the page. Instead, they are added to the footer, when print_late_styles() runs.

If you have an existing theme and you want to opt-in to this improvement, you will need to test your theme for style priorities. Opting-in to separate styles loading in a classic theme means that the loading order of styles changes. Block styles that used to be in the head will move to the footer, so you will need to check your theme’s styles and make sure any opinionated styles you add to blocks have a higher priority than coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. styles.

Taking advantage of separate styles loading to add pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme styles to blocks

It is possible to use this new feature to attach styles to existing block-styles, by inlining them.

If your theme adds styles to blocks, instead of loading a single file containing all styles for all blocks, you can split styles and have a single file per-block. This will allow you to only load your theme’s (or plugin’s) block styles only when a block exists on a page.

The function below is an example implementation of how to do that, with some additional tweaks:

  • It works both in WordPress 5.8 and previous versions
  • It has a fallback in case the should_load_separate_core_block_assets filter is disabled
  • It adds styles both in the editor and frontend
  • Checks for specific editor block styles.

Feel free to use this as an example, tweaking it to suit your needs and implementation.

/**
 * Attach extra styles to multiple blocks.
 */
function my_theme_enqueue_block_styles() {
	// An array of blocks.
	$styled_blocks = [ 'paragraph', 'code', 'cover', 'group' ];

	foreach ( $styled_blocks as $block_name ) {
		// Get the stylesheet handle. This is backwards-compatible and checks the
		// availability of the `wp_should_load_separate_core_block_assets` function,
		// and whether we want to load separate styles per-block or not.
		$handle = (
			function_exists( 'wp_should_load_separate_core_block_assets' ) &&
			wp_should_load_separate_core_block_assets()
		) ? "wp-block-$block_name" : 'wp-block-library';

		// Get the styles.
		$styles = file_get_contents( get_theme_file_path( "styles/blocks/$block_name.min.css" ) );

		// Add frontend styles.
		wp_add_inline_style( $handle, $styles );

		// Add editor styles.
		add_editor_style( "styles/blocks/$block_name.min.css" );
		if ( file_exists( get_theme_file_path( "styles/blocks/$block_name-editor.min.css" ) ) ) {
			add_editor_style( "styles/blocks/$block_name-editor.min.css" );
		}
	}
}
// Add frontend styles.
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_block_styles' );
// Add editor styles.
add_action( 'admin_init', 'my_theme_enqueue_block_styles' );

Inlining small assets

In some cases small stylesheets get loaded on WordPress sites. These stylesheets require the browser to make an additional request to get an asset, and while they benefit from caching, their small size doesn’t justify that extra request, and performance would improve if they were inlined.

To that end, an inlining mechanism was implemented. This is an opt-in feature, and can be handled on a per-stylesheet basis. Internally, only assets that have data for path defined get processed, so to opt-in, a stylesheet can add something like this:

wp_style_add_data( $style_handle, 'path', $file_path );

When a page gets rendered, stylesheets that have opted-in to get inlined get added to an array. Their size is retrieved using a filesize call (which is why the path data is necessary), and the array is then ordered by ascending size (smaller to larger stylesheet). We then start inlining these assets by going from smallest to largest, until a 20kb limit is reached.

A filter is available to change that limit to another value, and can also be used to completely disable inlining.

To completely disable small styles inlining:

add_filter( 'styles_inline_size_limit', '__return_zero' );

To change the total inlined styles limit to 50kb:

add_filter( 'styles_inline_size_limit', function() {
	return 50000; // Size in bytes.
});

Inlining these styles happens by changing the src of the style to false, and then adding its contents as inline data. This way we avoid backwards-compatibility issues in themes and any additional styles attached to these stylesheets using wp_add_inline_style will still be printed.

Please note that if a stylesheet opts-in to get inlined, that is no guarantee that it will get inlined.

If for example on a page there are 30 stylesheets that are 1kb each, and they all opt-in to be inlined, then only 20 of them will be converted from <link rel="stylesheet"/> to <style> elements. When the 20th stylesheet gets inlined the 20kb limit is reached and the inlining process stops. The remaining 10 stylesheets will continue functioning like before and remain <link> elements.

If your theme opts-in to the separate block-styles, core block styles by default have path defined so they can all be inlined.

Props @sergeybiryukov for proofreading this dev-note.

#5-8, #dev-notes

Editor Chat Agenda: 28 July 2021

Facilitator and notetaker @ajitbohra

This is the agenda for the weekly editor chat scheduled for Wednesday, 28 July 2021, 14:00 UTC.

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/..

  • WordPress 5.8
  • What’s new in Gutenberg 11.1.0
  • 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/ 11.2.0 RC
  • Whats next in Gutenberg: July and August.
  • Project updates based on the latest site editing scope:
    • 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.
    • Template editor.
    • Patterns.
    • Styling.
    • Mobile Team.
  • Task Coordination.
  • Open Floor.

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the meeting in the comments below:

  • 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.

#core-editor #core-editor-agenda #agenda #meetings

Dev Chat Agenda for July 28, 2021

Here is the agenda for this week’s developer meeting to occur at July 28, 2021 at 20:00 UTC.

Blogblog (versus network, site) Post Highlights

5.8 Review

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 the usual agenda items 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 channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-8, #agenda, #core, #dev-chat