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

Dev Chat Agenda for July 21, 2021

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

Blogblog (versus network, site) Post Highlights

5.8 Schedule 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

Introducing “Update URI” plugin header in WordPress 5.8

WordPress 5.8 introduces a new 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. available for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors. This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the 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/ Plugin Directory.

Previously, any custom plugin which used the same slug than a plugin hosted on WordPress.org was taking a significant risk of being overwritten by an update of the latter.

WordPress 5.8 introduces a new Update URI plugin header field. If the value of this new field matches any URI other than https://wordpress.org/plugins/{$slug}/ or w.org/plugin/{$slug}, WordPress will not attempt to update it.

If set, the Update URI header field should be a valid URI and have a unique hostname.

Please note that authors of plugins hosted by WordPress.org don’t need to use this new header.

Some examples include:

  • Update URI: https://wordpress.org/plugins/example-plugin/
  • Update URI: https://example.com/my-plugin/
  • Update URI: my-custom-plugin-name

Update URI: false also works, and unless there is some code handling the false hostname (see the hook introduced below), the plugin will not be updated.

If the header is used on a w.org hosted plugin, the WordPress.org 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. will only return updates for the plugin if it matches the following format:

  • https://wordpress.org/plugins/{$slug}/
  • w.org/plugin/{$slug}

If the header has any other value, the API will not return any result. It will ignore the plugin for update purposes.

Additionally, WordPress 5.8 introduce the update_plugins_{$hostname} 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., which third-party plugins can use to offer updates for a given hostname.

This new hook filters the update response for a given plugin hostname. The dynamic portion of the hook name, $hostname, refers to the hostname of the URI specified in the Update URI header field.

The hook has four arguments:

  • $update: The plugin update data with the latest details. Default false.
  • $plugin_data: The list of headers provided by the plugin.
  • $plugin_file: The plugin filename.
  • $locales: Installed locales to look translations for.

They can be used to filter the update response in multiple use cases.

For reference, see tickets #32101, #23318, and changelog [50921].

Thanks @milana_cap for proofreading.

#5-8, #dev-notes

Editor Chat Agenda: 21 July 2021

Facilitator and notetaker: @andraganescu

This is the agenda for the weekly editor chat scheduled for Wednesday, July 21, 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/..

  • WordPress 5.8 final release.
  • What’s new in Gutenberg 11.1.0
  • Whats next in Gutenberg: July and August.
  • Project updates based on the latest site editing scope & 5.8 Priorities:
    • 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.

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

WordPress 5.8 Release Day Process

We’re less than 24 hours away from WordPress 5.8! If you would like to help with the final steps of the release, here is how you can join in.

The current plan is to start the release process at Tuesday, July 20, 2021 1500 UTC in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

The major version release process can take a bit more time than the Betas or Release Candidates do, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We will be working through the Major Version Release process for anyone who wants to follow along. Earlier today the pre-final release dry run was coordinated in #core (Slack archive).

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the different server configurations available. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. will also need testing.

There are two ways to help test the package:

  • Use WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ to test: wp core update https://wordpress.org/wordpress-5.8.zip
  • Directly download the BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./RC version (e.g., https://wordpress.org/wordpress-5.8.zip)

In particular, testing the following types of installs and updates would be much appreciated:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLI or one-click installers.
  • Test upgrading from 4.0.33, 4.9.18, 5.7.2, and 5.8 RC 4 as well as any other versions possible
  • Remove wp-config.php file and test fresh install
  • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installs
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does Multisite upgrade properly?

Finally the following user flows, on desktop and mobile, would be great to validate work as expected:

  • Publish a post, including a variety of different blocks.
  • Comment on the post.
  • Install a new 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, or upgrade an existing one.
  • Change the site language.
  • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

You can even start this early, by running the WordPress 5.8 RC4 packages, which are built using the same method as the final packages.

#5-8, #release-process

What’s new in Gutenberg 11.1.0? (21 July)

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 a new version is available! Gutenberg 11.1 adds the ability to edit a 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. border easily, enables drag and drop support for the List View component, and includes many 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 centered around the Widgets Editor and Block Library.

Block supports: border

Take an early look at custom block borders! When borders are enabled in a theme.json file, and a block declares that it supports it with the block 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., a new block panel is available that lets us change the border radius, width, style, color, and border units.

Set and style custom block borders

List View drag and drop

Intuitively move and reorder blocks using drag and drop in the List View.

Use the persistent list view to reorder blocks

11.1.0

Enhancements

  • Adminadmin (and super admin) panel available as PWA. (33102, 33310)
  • Block Breadcrumbs: Small chevron icon for breadcrumb separators. (33042)
  • Block Library:
    • Columns Block:
      • Add stack on mobile setting to allow for columns without mobile breakpoints. (31816)
      • Add the percent unit to the default units in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. (33468)
    • Latest posts: Remove grey color for dark themes. (33325)
    • List Block: Add link color control to list block. (33185)
    • Post Terms Block: Add a “separator” attribute to post-terms block. (32812)
    • RSS Block: Update block styles. (33294)
    • Tag Cloud Block:
      • Add ability to change number of tags shown. (32201)
      • Remove editor style so editor matches frontend. (33289)
  • Design Tools, Border:
    • Add support for custom border units. (33315)
    • Update border support UIUI User interface. (31585)
    • Set border style none when border width zero. (32080)
  • Link Editing: Add Unlink button to LinkControl popover. (32541)
  • List View: Enable drag and drop in List View. (33320)
  • 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: Adds auxiliary class names for editor styles. (33388)
  • General UI:
    • Block Settings Menu: Don’t render ‘Move to’ if there is only one block. (33158)
    • Disable ‘Post Publish’ button if saving non-post entities. (33140)
    • Preferences: Polish labels and consolidate options in preferences. (33133)

New APIs

  • 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/.: Block editor settings endpoint. (33128)
  • UI Components: Add a SearchControl component and reuse across the UI. (32935)

Performance

  • Improve List View performance. (33320)
  • Pattern Directory: Caching updates. (33052)

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

  • Improve high contrast mode rendering of icon buttons. (33062)

Bug Fixes

  • Block Breadcrumbs: Fix breadcrumbs htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. structure and ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. warnings. (33159)
  • Block Editor:
    • Move layout styles to document head (instead of rendering inline). (32083)
    • Warn only in edit implementation when using useBlockProps. (33380)
    • Iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.: Remove reset styles. (33204)
  • Block Library:
    • Buttons Block: Remove green background color in button preview. (33116)
    • Embed Block: Include missing attributes when upgrading embed block. (33235)
    • Image Block:
      • Improve “can switch to cover” check. (33095)
      • Fix replace link control styling. (33326)
    • 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. Block:
      • Prevent entering invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. values in the Query Loop block configuration. (33285)
      • Update getTermsInfo() to workaround parsing issue for translatable strings. (33341)
    • Search Block:
      • Fix search block button position dropdown accessibility/UXUX User experience issues. (33376)
      • Update search block to handle per corner border radii. (33023)
    • Site Title: Decode entities in site title. (33323)
    • Home Link: Remove padding. (33461)
    • Post Except: Fix excerpt_more 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. conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. and remove wordCount attribute. (33366)
  • Design Tools:
    • Color: Prevent color panel from showing as empty. (33369)
    • Duotone:
      • Avoid rendering duplicate stylesheet and SVG. (33233)
      • Update conditions to hide duotone panel. (33295)
    • 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.
      • Allow themes to provide empty values for color.duotone and spacing.units. (33280)
      • Specify what settings can be part of settings.layout. (33303)
  • Rich text:
    • Fix format deregistration. (31518)
    • Autocomplete: Reset state for empty text. (33450)
    • Run input rules after composition end. (33416)
  • Site Editor: Close navigation 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. when all posts clicked. (33393)
  • Slash Inserter: Fix slash command focus style. (33084)
  • Widgets Editor:
    • Fix moving inner blocks in the Widgets 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.. (33243)
    • Fix inserter size on Widgets Editor 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.. (33118)
    • Merge conflicting wp.editor objects into a single, non-conflicting module. (33228)
    • Retrieve latest widgets before loading sidebars. (32997)
  • Writing flow:
    • Allow select all from empty selection. (33446)
    • Attempt to fix preview end-to-end failure. (33467)
  • Components:
    • Suggestion List: Check if a node exists to scroll into view. (33419)
    • Navigation component: Fix item handling onClick twice. (33286)
  • Editor: Extract snackbars into a separate component. (33355)

Experiments

  • Component System:
    • Promote g2 Popover as Flyout. (32197)
    • Add useControlledValue. (33039)
    • Add normalizeArrowKey. (33208)
    • Add mergeEventHandlers. (33205)
    • Add useCx. (33172)
    • Add useLatestRef hook. (33137)
    • Remove @emotion/css from Divider. (33054)
  • Navigation Block:
    • Add Color Options for Submenus. (31149)
    • Change Navigation block markup on front end only. (30551)
    • Improve handling of open overlay. (32886)
    • Menu item placeholder inheritance. (32512)
    • Pass block attributes with rendering with location. (33043)
    • Refactor of navigation block rendering using location attribute. (33244)
  • Global Styles:
    • Cover against non existing styles. (33127)
    • Missing link color on style properties to css var mapping. (33150)
    • Preset variables not being user on the site editor. (33149)

Documentation

  • Admin PWA: Make readme private. (33216)
  • Handbook:
    • Block API:
      • Apply enhancements included in WordPress 5.8. (33252)
      • Clarify the type of apiVersion in block metadata. (33249)
      • Fixes a typo in the documentation for block supports. (33247)
    • Block Editor API: Changes to support multiple admin screens in WP 5.8. (33262)
    • Custom Block Editor: Fixed bad image syntax and bold text. (32897)
    • Fix API documentation for data reference guides. (33384)
    • 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 Release: Update Gutenberg release documentation to clarify release post workflow. (33328)
    • theme.json:
      • Add examples and highlight backward compatibility. (33421)
      • Update theme.json documentation for WordPress 5.8. (33131)
      • Fix codetabs syntax in theme.json documentation. (33417)
    • Use markdown headings instead of links for API declarations. (33381)
  • Update documentation for link color in WordPress 5.8. (33162)
  • Packages:
    • Add PanelBody for InspectorControls. (33227)
    • Correct wrong setState call. (32808)
    • Remove withState HOC references. (33173, 33222, 33259)

Code Quality

  • Avoid calling gutenberg_ functions within code shipped through WordPress Core. (33331)
  • Block Editor:
    • Refactor the user autocompleter to avoid apiFetch and rely on the data module. (33028)
    • Warn when useBlockProps hook used with a wrong Block API version. (33274)
  • Block Library:
    • Image Block: Fix uncaught error. (24334)
    • Latest Posts Block: Refactor to drop apiFetch usage in favor of using the data module. (33063)
    • Template Part Block: Remove unnecessary function exists check on wp_filter_content_tags. (33182)
  • Components:
    • BlockNavigation: Restructure the BlockNavigation component. (31892)
    • Box Control: Rename VerticalHorizontalInputControls to AxialInputControls. (33016)
    • GradientPicker: Stabilises GradientPicker and CustomGradientPicker components. (31440)
    • Toolbar: Enforce isAlternate on ToolbarDropdownMenu. (33129)
    • ZStack: Remove @emotion/css from ZStack. (33053)
  • Packages: Hoist dependencies for WordPress packages. (33387)
  • Plugin: Remove deprecated APIs that are no longer supported in version 11.0. (33258)

Tools

  • Testing:
    • Add basic Site Title block coverage. (32868)
    • Add some functionality to createUser and deleteUser. (33067)
    • Enable previously skipped widgets tests. (33121)
    • Skipping more end-to-end tests. (33353)
    • Skip unstable end-to-end tests. (33352)
    • Switch to new puppeteer APIs for emulating conditions. (33410)
    • Update end-to-end tests to use new puppeteer drag and drop api. (33386)
  • Dependencies:
    • Update CopyWebpackPlugin to v6. (33220)
    • Upgrade Husky to 7.0.0 and git ignorance improved. (33183)
    • Upgrade Puppeteer to 10.1. (33327)
    • Upgrade Storybook to v6.3. (33219)
  • NPM Packages: Introduce release types to npm publishing script. (33329)
  • Plugin: Introduce tools folder with configuration files. (33281)
  • Workflows:
    • Release Workflow: Remove “experimental” status from WP 5.8 stable items. (33214)
    • Re-enable manually triggered workflows on forks. (32821)
    • Use NPM caching built into action/setup-node. (33190)

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 11.16.38s26.12ms
Gutenberg 11.06.06s29.55ms
WordPress 5.78.52s36.26ms

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

Thanks to @javiarce for creating the release post assets, @cbringmann for proofreading, and @priethor, @youknowriad, and @get_dave for guiding me through this release!

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

Introducing the template editor in WordPress 5.8

Update on 23/06/2021:

  • Added the default template section.
  • The template editor is now opt-in instead of opt-out for classic themes.

One of the first Full Site Editing tools introduced in WordPress 5.8 is the template editor. The template editor is a special mode available in the post editor that allows you to create, assign, and edit 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. templates to specific posts and pages.

Template Editor in action

Theme blocks

Block Templates take over the whole page allowing you to layout and design the entire page in the editor. Note, this does mean your theme’s provided PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher template won’t be used when rendering a post or page using a block template.

When creating a block template, you can use any of the blocks you’re already familiar with in the post editor.

Additionally a new set of theme blocks are introduced in WP 5.8 that can be useful when building templates. These theme blocks are:

  • Site Logo
  • Site Tagline
  • Site Title
  • 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.
  • Post Title
  • Post Content
  • Post Date
  • Post ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. 
  • Post Featured ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.
  • Post Categories
  • Post Tags
  • Login/out
  • Page List

Architecture

The templates are saved as a Custom Post TypeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. named wp_template. A 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/. end point is also available to fetch these templates.

Default Template

When users create new custom templates, a default template containing the site title, post title and post content is used but theme authors can choose to provide their own styled default custom templates by hooking into the editor settings and providing a `defaultBlockTemplate` as an HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. string or by using a dedicated HTML file.

add_filter( 'block_editor_settings_all', function( $settings ) {
     $settings['defaultBlockTemplate'] = file_get_contents( get_theme_file_path( 'block-template-default.html' ) );
     return $settings;
});

Theme Support

By default, the template editor is disabled for themes, but themes can choose to enable it with the following line added to their functions.php file.

add_theme_support( 'block-templates' );

Note, that if themes decide to use the newly introduced 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. file config, they are automatically opted-in into the template editor.

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

Refining WordPress core’s lazy-loading implementation

Since the image lazy-loading feature was originally added to WordPress core in 5.5, by default every post content image as well as every image rendering using the wp_get_attachment_image() function (which includes featured images) is lazy-loaded. This optimization follows the typical implementation of the feature in other projects, without consideration for whether an image appears above or below the fold. Due to the available metrics at the time it was decided to leave fine-grained control over opting out certain images from being lazy-loaded to theme authors, since the position of images heavily depends on the current theme layout. See also the following paragraph in the original announcement post:

Theme developers are recommended to granularly handle loading attributes for images anytime they rely on wp_get_attachment_image() or another function based on it (such as the_post_thumbnail() or get_custom_logo()), depending on where they are used within templates. For example, if an image is placed within the header.php template and is very likely to be in the initial viewport, it is advisable to skip the loading attribute for that image.

It was recently discovered that the current WordPress core implementation of lazy-loading has room for improvement as it can regress the Largest Contentful Paint metric (LCP) when hero images above the fold are being lazy-loaded. Therefore, the default behavior of the existing lazy-loading implementation should be refined in order to better take this nuance into account.

Omitting the loading attribute on certain elements

As mentioned before, WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is unable to reliably assess whether an image is going to appear above or below the fold, since it depends on the currently active theme. Furthermore, the loading attributes are added on the server-side, which has no notion on the influencing client factors like viewport size. Because of those reasons, fine-grained control over lazy-loading images (and iframes) still remains with theme authors. However, we can fine tune WordPress core’s lazy-loading implementation to behave in a way that improves the situation for the vast majority of cases, to achieve better LCP values out of the box.

Now, one could argue that lazy-loading should be entirely removed again to avoid any negative impact on LCP. However, that would also remove all the benefits that lazy-loading comes with, which is reducing bandwidth and wasting fewer networknetwork (versus site, blog) resources, which in itself can impact Core Web Vitals (CWV) metrics. The preferable default behavior here would be to find a solid middle ground between those trade-offs. This leads to the following goal for the WordPress core implementation:

The first “x” content image(s) should not be lazy-loaded by default, with “x” being as high as possible so that there is little to no LCP regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. and as low as possible so that there is little to no regression in the total bytes loaded.

(Note that this also includes iframes, but they are less commonly used as hero elements, so for simplicity this post mentions primarily images.)

To determine the right value for “x” (i.e. the number of images/iframes to omit from being lazy-loaded by default), I conducted an analysis using two versions of a small prototype 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 which prevents the loading=”lazy” attribute from being added to the first 1 or 2 content images respectively. The analysis relied on the following methodology:

  • Test across the 50 most popular themes according to the 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/ popular themes search
  • Test on a demo site without any plugins active (except for the lazy-loading prototype plugin), for an archive view with 5 posts (where every post has a featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.) and for a single post view (where the post has a featured image as well as 5 images within its content), i.e. 2 different types of URLs
  • Test for 2 viewports, “mobile” and “desktop”
  • Use WebPageTest for the individual scenarios (200 in total), with 9 test runs for each scenario in order to counter variance and rely on the median result

That analysis produced the following results:

  • Omitting the first content image from being lazy-loaded resulted in a median LCP improvement of 7% (1,877ms compared to 2,020ms with current core behavior) and a median image bytes increase of 0% (368KB compared to 369KB with current core behavior). → Omitting the first content image clearly results in an LCP improvement while not noticeably regressing on image bytes saved.
  • Omitting the first two content images from being lazy-loaded resulted in a median LCP improvement of 5% (1,927ms compared to 2,020ms with current core behavior) and a median image bytes increase of 2% (378KB compared to 369KB with current core behavior). → Omitting the first two content images produces worse results for both metrics than only omitting the first one, i.e. it is better to only skip lazy-loading for the first content image, and therefore no additional tests with larger numbers of images not being lazy-loading are needed.
  • Both fixes actually perform even better in LCP compared to the results with lazy-loading completely disabled. This confirms that completely disabling lazy-loading is not a solution to the problem.
  • Drilling further into the results for omitting the first content image, 42% of scenarios result in a median LCP improvement of greater than 10%, with the maximum improvement being 33%. 5% of scenarios result in the median LCP being more than 10% worse, with the maximum here being 21%. → While the median LCP improvement across all themes is only 7%, there are larger notable wins for a significant number of themes, while notable losses are minimal.
Relative LCP change of the fix compared to the current behavior across all tested scenarios

Following up on the findings on the LCP regression from lazy-loading as well as the analysis about the potential fix, the following refinement to the lazy-loading implementation in core is being proposed for WordPress 5.9:

  • Instead of lazy-loading all images and iframes by default, the very first content image (also considering featured images) or content iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. should not be lazy-loaded.
  • This is a more sensitive default than what the current implementation uses, that on average and at scale will result in better LCP performance out of the box, while keeping necessary bandwidth low.
  • Despite this change of the default behavior, responsibility for fine grained control of which elements should be lazy-loaded remains with theme authors. As a theme author, you are still recommended to specify a loading attribute value for images presented by the theme. Particularly pay attention if your theme relies on less standard layouts, e.g. a grid or slider view of posts or if post content only appears far down the page.

A TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. for adding this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to core has been opened in #53675 for further review and discussion.

Props to @addyosmani, @adamsilverstein, @desrosj for review and proofreading.

#feature-lazyloading

Block API Enhancements in WordPress 5.8

Starting in WordPress 5.8 release, we encourage using the block.json metadata file as the canonical way to register 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. types. The Block Metadata specification has been implemented and iterated over the last few major WordPress releases, and we have reached the point where all planned features are in place.

Example File

Here is an example block.json file that would define the metadata for a 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 create a notice block.

notice/block.json

{
	"apiVersion": 2,
	"name": "my-plugin/notice",
	"title": "Notice",
	"category": "text",
	"parent": [ "core/group" ],
	"icon": "star",
	"description": "Shows warning, error or success notices…",
	"keywords": [ "alert", "message" ],
	"textdomain": "my-plugin",
	"attributes": {
		"message": {
			"type": "string",
			"source": "html",
			"selector": ".message"
		}
	},
	"providesContext": {
		"my-plugin/message": "message"
	},
	"usesContext": [ "groupId" ],
	"supports": {
		"align": true
	},
	"styles": [
		{ "name": "default", "label": "Default", "isDefault": true },
		{ "name": "other", "label": "Other" }
	],
	"example": {
		"attributes": {
			"message": "This is a notice!"
		}
	},
	"editorScript": "file:./build/index.js",
	"script": "file:./build/script.js",
	"editorStyle": "file:./build/index.css",
	"style": "file:./build/style.css"
}

Benefits using the metadata file

The block definition allows code sharing between 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/., PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, and other languages when processing block types stored as 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., and registering blocks with the block.json metadata file provides multiple benefits on top of it.

From a performance perspective, when themes support lazy loading assets, blocks registered with block.json will have their asset enqueuing optimized out of the box. The frontend CSSCSS Cascading Style Sheets. and JavaScript assets listed in the style or script properties will only be enqueued when the block is present on the page, resulting in reduced page sizes.

Furthermore, because the Block Type REST API Endpoint can only list blocks registered on the server, registering blocks server-side is recommended; using the block.json file simplifies this registration.

Last, but not least, the WordPress Plugins Directory can detect block.json files, highlight blocks included in plugins, and extract their metadata. If you wish to submit your block(s) to the Block Directory, all blocks contained in your plugin must have a block.json file for the Block Directory to recognize them.

Block registration

PHP

The register_block_type function that aims to simplify the block type registration on the server, can read now metadata stored in the block.json file.

The function takes two params relevant in this context ($block_type accepts more types and variants):

  • $block_type (string) – path to the folder where the block.json file is located or full path to the metadata file if named differently.
  • $args (array) – an optional array of block type arguments. Default value: []. Any arguments may be defined.

It returns the registered block type (WP_Block_Type) on success or false on failure.

Example:

notice/notice.php

<?php

register_block_type(
	__DIR__,
	array(
		'render_callback' => 'render_block_core_notice',
	)
);

Note: We decided to consolidate the pre-existing functionality available with register_block_type_from_metadata method into register_block_type to avoid some confusion that it created. It’s still possible to use both functions, but we plan to use only the shorter version in the official documents and tools from now on.

Related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.#53233.

JavaScript

When the block is registered on the server, you only need to register the client-side settings on the client using the same block’s name.

Example:

notice/index.js

registerBlockType( 'my-plugin/notice', {
	edit: Edit,
	// ...other client-side settings
} );

Although registering the block also on the server with PHP is still recommended for the reasons above, if you want to register it only client-side you can now use registerBlockType method from @wordpress/blocks package to register a block type using the metadata loaded from block.json file.

The function takes two params:

  • $blockNameOrMetadata (string|Object) – block type name (supported previously) or the metadata object loaded from the block.json file with a bundler (e.g., webpack) or a custom Babel plugin.
  • $settings (Object) – client-side block settings.

It returns the registered block type (WPBlock) on success or undefined on failure.

Example:

notice/index.js

import { registerBlockType } from '@wordpress/blocks';
import Edit from './edit';
import metadata from './block.json';

registerBlockType( metadata, {
	edit: Edit,
	// ...other client-side settings
} );

Related PR: WordPress/gutenberg#32030.

Internationalization support in block.json

WordPress string discovery system can now automatically translate fields marked as translatable in Block Metadata document. First, in the block.json file that provides block metadata, you need to set the textdomain property and fields that should be translated.

Example:

fantastic-block/block.json

{
	"name": "my-plugin/fantastic-block",
	"title": "My block",
	"description": "My block is fantastic",
	"keywords": [ "fantastic" ],
	"textdomain": "fantastic-block"
}

PHP

In PHP, localized properties will be automatically wrapped in _x function calls on the backend of WordPress when executing register_block_type function. These translations get added as an inline script to the plugin’s script handle or to the wp-block-library script handle in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The way register_block_type processes translatable values is roughly equivalent to the following code snippet:

<?php
$metadata = array(
	'title'       => _x( 'My block', 'block title', 'fantastic-block' ),
	'description' => _x( 'My block is fantastic!', 'block description', 'fantastic-block' ),
	'keywords'    => array( _x( 'fantastic', 'block keyword', 'fantastic-block' ) ),
);

Implementation follows the existing get_plugin_data function which parses the plugin contents to retrieve the plugin’s metadata, and it applies translations dynamically.

Related Trac ticket: #52301.

JavaScript

You can also now use registerBlockType method from @wordpress/blocks package to register a block type that uses translatable metadata stored in block.json file. All localized properties get automatically wrapped in _x function calls (from @wordpress/i18n package) similar to how it works in PHP with register_block_type. The only requirement is to set the textdomain property in the block.json file.

Example:

fantastic-block/index.js

import { registerBlockType } from '@wordpress/blocks';
import Edit from './edit';
import metadata from './block.json';

registerBlockType( metadata, {
	edit: Edit,
	// ...other client-side settings
} );

Related PR: WordPress/gutenberg#30293.

Extracting translations

The ongoing effort to improve the internationalization of client-side JavaScript code made necessary by moving to the block-based editor has led to several improvements to the i18n make-pot command from WP-CLI as of v2.5.0 release. It now also parses the block.json file as it is defined in the Block Metadata document.

Related PR: wp-cli/i18n-command#210.

New filters

There are two new WordPress 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. that can be used when block types get registered with register_block_type function using the metadata loaded from the block.json file.

block_type_metadata

Filters the raw metadata loaded from the block.json file when registering a block type. It allows applying modifications before the metadata gets processed.

The 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. takes one param:

  • $metadata (array) – metadata loaded from block.json for registering a block type.

Example:

<?php

function filter_metadata_registration( $metadata ) {
	$metadata['apiVersion'] = 1;
	return $metadata;
};
add_filter( 'block_type_metadata', 'filter_metadata_registration', 10, 2 );

register_block_type( __DIR__ );

block_type_metadata_settings

Filters the settings determined from the processed block type metadata. It makes it possible to apply custom modifications using the block metadata that isn’t handled by default.

The filter takes two params:

  • $settings (array) – Array of determined settings for registering a block type.
  • $metadata (array) – Metadata loaded from the block.json file.

Example:

function filter_metadata_registration( $settings, $metadata ) {
	$settings['api_version'] = $metadata['apiVersion'] + 1;
	return $settings;
};
add_filter( 'block_type_metadata_settings', 'filter_metadata_registration', 10, 2 );
		
register_block_type( __DIR__ );

Props to @priethor and @audrasjb 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..

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

Editor Chat Agenda: 14 July 2021

Facilitator and notetaker: @annezazu

This is the agenda for the weekly editor chat scheduled for  Wednesday, July 14, 2021, 02:00PM 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 (Project board) & WordPress 5.8 RC 3
  • Project updates based on the latest FSE scope & 5.8 Priorities:
    • 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.

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