Milana Cap 11:17 am on May 3, 2022
Tags: , ,   

Block Editor miscellaneous Dev Notes for WordPress 6.0

Updated 2022-05-07 with a table of content, two more 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, and 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. and some formatting –bph

Table of Contents

Removed bottom margin on LineHeightControl component

Several UIUI User interface components currently ship with styles that give them bottom margins. This can make it hard to use them in arbitrary layouts, where you want different amounts of gap or margin between components.

To better suit modern layout needs, we will gradually deprecate these bottom margins. A deprecation will begin with an opt-in period where you can choose to apply the new margin-free styles on a given component instance. Eventually in a future version, the margins will be completely removed.

In WordPress 6.0, the bottom margin on the LineHeightControl component has been deprecated. To start opting into the new margin-free styles, set the __nextHasNoMarginBottom prop to true:

<LineHeightControl
  value={ lineHeight }
  onChange={ onChange }
  __nextHasNoMarginBottom={ true }
/>

For more info see #37160.

Props to @0mirka00 for writing 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, and 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.. (top)

Unrecognized 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. preservation

We’ve started making strides in preserving unrecognized content in the editor, also called (sometimes incorrectly) “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.” or “missing.” In situations where the editor is unable to validate a loaded block against its implementation we run into numerous cases where content has previously been lost or corrupted, notably when inner blocks are involved.

Currently, we’re on the journey to preserving that original unrecognized content but have many corners in the project to update before it’s finished. Notably, when loading posts in the editor or in the code view that content will be preserved as it was loaded. Surprisingly, this lets us do something we’ve never been able to do before: intentionally create certain kinds of broken blocks within the code editor, or modify and fix blocks in the code editor whose block implementation is missing.

Still on the list to update are smaller parts of the flow such as the array of confusing block resolution dialogs and operations as well as certain validation steps that currently fail but shouldn’t.

In short, if you’ve been frustrated by the editor breaking your posts as soon as you hit “save” then good news is coming in 6.0.

For more info see #38794, #38923, and #39523.

Props to @dmsnell for writing this dev note.(top)

Registration of Blocks from within Themes

Until WordPress 6.0, building blocks inside plugins was the only way possible if you wanted to use block.json. This remains to be the recommended way to build Custom blocks  going forward. Blocks add functionality and therefore should be built as plugins that stay active even when a new theme is enabled. 

There are however instances where the styling and functionality of a block is so tightly coupled with a theme that it doesn’t make sense to have a block active without a given theme. This is true when building custom solutions, and the blocks are site-specific and not used for other instances. Furthermore, from discussion with agency project managers and developers, it turns out that there are considerable deployment costs when separating comprehensive solutions.

Each implementation had to reinvent a way to register blocks within themes, as WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. wouldn’t allow for it. With 6.0 the registration of blocks using block.json from within a theme is now technically standardized. You can use the same register_block_type function as you would inside 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 and all the assets that you may register in the block.json file like the editorScript, style, etc get enqueued correctly.

For more info see #55513.

Props to @fabiankaegy for writing this dev note.(top)

Comments blocks – Enable legacy Post Comments block

With WordPress 6.0, there is a new set of blocks to show the Comments of a post:

  • Comments Query Loop: An advanced block that displays post comments and allows for various layouts and configurations.
    • Comment Template: Contains the block elements used to display a comment, such as the title, date, author, avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. and more.
    • Comments Pagination: Displays next/previous links to paginated comments where this has been enabled in the comment settings in the WordPress adminadmin (and super admin)
      • Previous Page: Displays the link to the previous page of comments.
      • Page Numbers: Displays a list of page numbers for comments pagination.
      • Next Page: Displays the link to the next page of comments.

The legacy Post Comments block, which directly renders the comments.php file, has been deprecated and hidden. It will still work for themes currently using it, but it won’t appear in the inserter.

The new set of blocks provides almost the same functionalities with the benefit that the layout and styles can be customized from the Editor. However, if any user wants to re-enable the Post Comments legacy block, they can use the block registration filters and adapt it to their needs. For example, this piece of code shows the legacy block in the inserter again and removes the “deprecated” from the title:

function wporg_enable_post_comments_legacy_block( $metadata ) {
    if ( 'core/post-comments' === $metadata['name'] ) {
        $metadata['title'] = esc_html__( 'Post Comments', 'textdomain' );
	$metadata['supports']['inserter'] = true;
    }
    return $metadata;
}
add_filter( 'block_type_metadata', 'wporg_enable_post_comments_legacy_block' );

For more info see #34994.

Props to @SantosGuillamot and @annezazu for writing this dev note.(top)

In order to implement this the spacing of the Gallery images had to be changed from a right margin setting to the CSSCSS Cascading Style Sheets. gap property. Themes or plugins that use a right margin setting to manually adjust the Gallery image spacing may need to be updated to instead override the gap setting.

Default gap changed

The new block editor block gap support functionality has been used to implement this and this adds a default block gap of 0.5em. For some themes that don’t explicitly set this gap, the default will change from the previous 16px to 0.5em. If plugin or theme developers want to ensure that the 16px gap remains the following CSS can be added to the theme, or site custom CSS:

.wp-block-gallery {
	--wp--style--gallery-gap-default: 16px;
}

Gallery Image bottom margins removed

Some themes may have depended on the bottom margin set on the gallery images to provide a gap between two galleries. Because the gallery now uses the flex gap for spacing this bottom margin is no longer set. Themes that were relying on this unintended side effect of the image margins will need to add the following CSS in order to maintain a gap between galleries:

.wp-block-gallery {
	margin-top: 16px;
}

Gallery gutter CSS var deprecated

To keep the naming of the gap setting consistent the --gallery-block--gutter-size CSS var has been deprecated and replaced with --wp--style--gallery-gap-default. --gallery-block--gutter-size will continue to work in release 6.0 and will be removed in 6.1.

Theme authors should be able to provide compatibility for WP 5.9 and 6.0+ with the following:

.wp-block-gallery {
        --gallery-block--gutter-size: var( --wp--custom--spacing--4 );
	--wp--style--gallery-gap-default: var( --wp--custom--spacing--4 );
}

For more info see #40008.

Props to @glendaviesnz for writing this dev note.(top)

New ancestor property in block.json

Block developers sometimes need to restrict where users can place their blocks. For that, developers already count on APIs like block.json‘s parent property or the allowedBlocks option of the useInnerBlocksProps hook that allowed developers to express some basic, direct parent-children relations between blocks.

Since WordPress 6.0, the ancestor property makes a block available inside the specified block types at any position of the ancestor block subtree. That allows, for example, to place a ‘Comment Content’ block inside a ‘Column’ block, as long as ‘Column’ is somewhere within a ‘Comment Template’ block. In comparison to the parent property, blocks that specify their ancestor can be placed anywhere in the subtree, while blocks with a specified parent need to be direct children.

This property admits an array of block types in string format, making the block require at least one of the types to be present as an ancestor.

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "core/comment-content",
    "ancestor": [ "core/comment-template" ],
    ...
}

Block developers can also combine parent with ancestor inside block.json and use them together to express more complex relations if needed. For example:

  • Parent [ 'A' ] and ancestor [ 'C' ] would work as ”parent A and ancestor C”.
  • Parent [ 'A', 'B' ] and ancestor [ 'C', 'D' ] would work as ”parent (A or B) and ancestor (C or D)”.

Note that there are some edge cases uncovered by this APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., like blocks that would require two or more different ancestor types simultaneously.

For more info see #39894.

Props to @darerodz for writing this dev note. (top)

Changes to media object returned from the WordPress data module

A small change has been made to the way the media objects are retrieved using the data module. The “caption”, “title” and “description” properties are returned as strings when using the `wp.data.select(‘core’).getRawEntityRecord` selector or the `wp.coreData.useEntityProp` hook.

Before

const [ renderedTitle ] = useEntityProp( 'root', 'media', id )?.rendered;

After

const [ renderedTitle ] = useEntityProp( 'root', 'media', id );

Props to @youknowriad for writing the note.

Removed Deprecated APIs

Some low-impact APIs that were deprecated on WordPress 5.4 have now been removed:

  • getReferenceByDistinctEdits selector.
  • PreserveScrollInReorder component.
  • dropZoneUIOnly prop in the MediaPlaceholder component.
  • isDismissable prop in the Modal component.
  • wp.data.plugins.control data module.

You can find more details on the #38564 removing these APIs

Slated to be removed in WordPress 6.2

The APIs listed have been deprecated in WordPress 5.3 and were forwarded in the background to the new ones already. They will be entirely removed in WordPress 6.2.

OldNew
wp.editor.+[name]wp.blockEditor.+[name]
wp.data.dispatch( 'core/editor' ).+ namewp.data.dispatch( 'core/block-editor' ). + name
wp.data.select( 'core/editor' ).+ namewp.data.select( 'core/block-editor' ). + name
wp.components.ServerSideRenderwp.serverSideRender

More details and discussion on PR #37854

Props to @youknowriad for writing the note.(top)

#6-0, #dev-notes, #dev-notes-6-0