One of the goals of the Gutenberg 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/ project’s phase 2 is to expand the usage of the Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor to other WordPress admin (and super admin) pages like the widgets screen.
In order to achieve this goal, it’s important to be able to reuse the block editor in a context independent from the post editor without any dependency to the post object. That’s where the new
block-editor module comes in.
In WordPress 5.1 and earlier, the block editor relied on the
wp-editor script and style handles and under the
wp.editor global variable.
WordPress 5.2 extracts some parts of the
editor module into a new module called
block-editor. This module is now available as a registered WordPress script using the
wp-block-editor script and style handles and under the
wp.blockEditor global variable.
Important distinctions about the new
- The editor module is kept, but is only responsible for fetching/updating post objects, and rendering post specific UI User interface components.
- The block editor module is a generic module responsible for rendering block editor UI, updating the list of blocks, and providing reusable components for third-party blocks.
There’s no backward compatibility breakage involved in this reorganization, as usage of the editor module provides proxies for APIs that were moved to the block-editor module in WordPress 5.2.
For example, in WordPress 5.1, blocks had to use the
wp.editor.BlockAlignment component to support alignment. This component will continue to work as expected, but
wp.editor.BlockAlignmentToolbar is now just a proxy to the block editor component
However, relying on the editor module as a dependency means that your block/code is loading the full editor module, which might not be needed for the block editor that will be included in the widgets screen in the future.
For this reason, it’s recommended that you make your blocks independent from the editor module and any post object. Instead of relying on the editor module proxies, you are encouraged you to your code to target the block-editor APIs instead.
wp-block-editor instead of
wp-editor as script and style dependencies for your WordPress registered/enqueued scripts and styles.
- Using the
wp.blockEditor.* components instead of
- Using the
core/block-editor data module selectors and actions instead of the
Components and Higher-Order Components Moved to block-editor
This is the exhaustive list of the components and higher-order components that were moved to the
Selectors Moved to
This is the exhaustive list of the data module selectors that moved to the
Actions Moved to
This is the exhaustive list of the data module actions that moved to the
Styles and Class Names
The components that moved from the editor module to the block-editor module are internally using CSS Cascading Style Sheets. class names that follow the package they’re declared in.
For example, the
editor-inserter__toggle class name is now renamed
The old class names have been retained to minimize any backward compatibility concern, but the CSS styles are now targeting the new class names.
Ideally, you should rely on components in your own code instead of the internal class names used in the WordPress admin. But if you do use those classes, make sure to rename them accordingly.