The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
In this post, you will find dev notesdev noteEach 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
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 APIAPIAn 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_assetsPHPPHPThe 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.
PluginPluginA 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.
Props to@ellatrix for the dev notedev noteEach 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:
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:
New slot in the site editor’s Template sidebarSidebarA 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)
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 UIUIUser 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.
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.
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 coreCoreCore 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 APIThe 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 metaMetaMeta 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.
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: