Leonardus Nugraha 10:00 am on July 18, 2023
Tags: , ,   

Miscellaneous Editor changes in WordPress 6.3

In this post, you will find 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. for smaller changes to the editor in WordPress 6.3.

Table of contents

Post editor iframed

From WordPress 6.3 on, the post editor will be iframed if all registered blocks have a Block API version 3 or higher. Adding version 3 support means that 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. should work inside an 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., though the block may still be rendered outside the iframe if not all blocks support version 3.

It is worth noting that the Site Editor and Page Template Editor have always been iframed, alongside block and pattern previews, and will continue to be iframed regardless of the Block 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. version.

To make adoption easier, all assets (styles and scripts) added through the enqueue_block_assets PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher action will now also be enqueued for the iframe. For more details, see #48286.

It’s also worth noting that enqueue_block_editor_assets should not be used to add stylesheets for editor content. Please use enqueue_block_assets instead. If you don’t want styles to load on the front-end, you can use an is_admin() condition.

For backward compatibility, we will clone stylesheets added via enqueue_block_editor_assets if the stylesheet contains a .editor-styles-wrapper, .wp-block, or .wp-block-* selector, but a warning message will be logged. You should use enqueue_block_assets instead, or block.json if you’re adding block styles, theme.json for block-based themes, or add_editor_style() for classic themes.

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 are asked to make blocks compatible with the iframed methods and support version 3 and to report any problems with those changes. In a future version of WordPress, the editor content will load within an iframe regardless of the Block API version.

For more information about why iframing the editor content is preferred, please revisit the post Blocks in an iframed (template) editor.

Edit: there’s a new page in the Block Editor Handbook on enqueuing assets in the editor, provided by @ndiego.

Props to @ellatrix for the 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..

Publish types for plugins packages enabled

TypeScript developers appreciate having great in-editor type-hints and compiler warnings. With the changes for WordPress 6.3, contributors reduced the reliance on DefinitelyTyped, and increase code maintainability. Various wordpress packages were published to allow TypeScript to emit types by parsing the JSDoc comments.

With some small tweaks to assist its inference capabilities, TypeScript can generate extensive type definitions even for store objects without migrating much code to TypeScript. So far, the following packages are using this process now:

  • Publish rich text build types (#49651)
  • Convert wp data controls to typescript (#49647)
  • Publish build types for notices (#49650)
  • Publish types for plugins package (#49649)

The work for some larger packages is still in progress, such as blocks, editor, and block-editor.

See #49649 for more details.

Props to @noahtallen for the dev note

Allow dragging-and-dropping images from the inserter to image blocks

The updates to the onDragStart prop of the <Draggable> component switched the synchronous callback function from an asynchronous one. Previously, it used to be called asynchronously with a slight delay set by setTimeout(onDragStart, 0). The previous behavior posed a limitation as users were unable to add additional data for the drag event due to security measures implemented by web browsers.

This change should have minimal impact on existing code. However, if it does affect your code, you can maintain the original behavior by wrapping your event callback inside a setTimeout function as shown below:

-onDragStart={ () => { doSomething(); } }
+onDragStart={ () => { setTimeout( doSomething, 0 ); } }

See #49673 for more details.

Props to @kevin940726 for the dev note

New slot in the site editor’s Template 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.

Extenders can now add additional information in the site editor’s Template sidebar. With the new slot named PluginTemplateSettingPanel the information will appear below the main information, similar to below example of the Template Card. (See Code Example)

import { MyTemplateSettingTest } from '@wordpress/edit-site';
const MyTemplateSettingTest = () => (
	<PluginTemplateSettingPanel>
		<p>Hello, World!</p>
	</PluginTemplateSettingPanel>
);

For more details, see #50257.

The site editor, showing settings panel with additional slot below the template card.

Props to @ntsekouras for the dev note

New `ungroup` transforms API

Block Transforms is the API that allows a block to be transformed from and to other blocks, as well as from other entities.

From now on, via the optional transforms key of the block configuration, blocks can use the ungroup subkey to define the blocks that will replace the block being processed. These new blocks will usually be a subset of the existing inner blocks, but could also include new blocks.

If a block has an ungroup transform, it is eligible for ungrouping without the requirement of being the default grouping block. The UIUI User interface used to ungroup a block with this API is the same as the one used for the default grouping block. For the Ungroup button to be displayed, you must have a single grouped block selected, which also contains some inner blocks.

ungroup is a callback function that receives the attributes and inner blocks of the block being processed. It should return an array of block objects.

Example:

export const settings = {
    title: 'My grouping Block Title',
    description: 'My grouping block description',
    /* ... */
    transforms: {
        ungroup: ( attributes, innerBlocks ) =>
            innerBlocks.flatMap( ( innerBlock ) => innerBlock.innerBlocks ),
    },
};

For more details, see #50385.

Props to @ntsekouras for the dev note

Block variation transforms in block switcher

Block Variations is the API that allows a block to have similar versions of it, but all these versions share some common functionality. Each block variation is differentiated from the others by setting some initial attributes or inner blocks. Then, when a block is inserted, these attributes and/or inner blocks are applied.

From now on, variations with a scope: transform will be prioritized in the block switcher menu so that they are easier surfaced in existing user interface (UI) patterns. Noting that the existing UI in the block’s inspector controls regarding the variation transformations is preserved as is.

For more details, see #50139.

Props to @ntsekouras for the dev note

Prioritizing Blocks in the Inserter

In this PR, we added a way to control what blocks are shown in the block inserter for a particular block. This allows a block to suggest particular blocks which are going to be most useful.

For example, when inserting a block within the Navigation block, we specify core/navigation-link and core/navigation-link/page as these are the most commonly used inner blocks.

prioritizedInserterBlocks is a property of the InnerBlocks component. To use it, pass prioritizedInserterBlocks as a property of the options argument passed to useInnerBlocksProps.

prioritizedInserterBlocks takes an array of the form {blockName}/{variationName}, where {variationName} is optional.

As a result, the blocks you specify in prioritizedInserterBlocks should be the first ones in the block inserter:

Props to @scruffian for the dev note

Renaming Reusable Blocks to Patterns

Reusable blocks have been renamed to Patterns in WordPress 6.3. For backward compatibility, the default behavior of  core/block remains exactly the same as with Reusable blocks. The block content is still saved to the wp_block CPT and any changes to the block content are reflected across all instances of the block. This default behavior of the Pattern block is referred to in the UI as ‘synced’.

The Pattern block also has a second option in 6.3 which is ‘unsynced’. When ‘unsynced’, the block will behave the same as the existing theme and plugin patterns, i.e. the patterns blocks will be inserted as standalone blocks, and any edits affect only that instance.

In order to track the synced and unsynced status, a new postmeta field has been registered for the wp_block CPT called wp_pattern_sync_status. If this postmeta field is undefined, the pattern is considered synced, and if the pattern is unsynced, this will be set to unsynced. Because this is a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. field, it is exposed as a top-level field in the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. instead of a metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. property, so it will appear on the wp_block as entity.wp_sync_status.

Because the synced Patterns do not require the new postmeta field, we don’t anticipate any impact on plugins that may modify the existing reusable block behavior. The only impact we anticipate is on any plugins that manipulate the DOM based on selectors that depend on the text Reusable block(s) existing in the UI. These selectors would need to be adjusted to expect the text Pattern instead.

Props to @glendaviesnz for the dev note

Patterns on the create a new template modal

In WordPress 6.2, we introduced a new modal for creating templates. This modal presents the option to start a new template from a “blank” state or use the current fallback of the template. In WordPress 6.3, we expanded this modal’s functionality to display patterns that are suitable for a given template.

For a pattern to appear in the modal, it needs to specify a property called templateTypes, which is an array containing the templates where the patterns can be used as the full content.

Here’s an example that demonstrates adding a pattern to the start of a 404 template:

register_block_pattern(
	'my-patterns/404-template',
	array(
		'title'      => __( 'New 404 pattern', 'gutenberg' ),
		'templateTypes' => array( '404' ),
		'content'    => '<!-- wp:paragraph {"align":"center","fontSize":"x-large"} -->
						<p class="has-text-align-center has-x-large-font-size">404</p>
						<!-- /wp:paragraph -->',
	)
);

Props to @jorgefilipecosta for the dev note

Props to @bph and @annezazu for reviewing the post

#6-3, #dev-notes, #dev-notes6-3