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.
Reorganization
In WordPress 5.1 and earlier, the block editor relied on the editor JavaScript 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/. module in order to fetch the post being edited and render the block editor corresponding to this post. This module is available as a registered WordPress script using 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 block-editor module:
- 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.
Backward Compatibility
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 wp.blockEditor.BlockAlignmentToolbar.
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.
This involves:
- Using
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 wp.editor.* ones. - Using the
core/block-editor data module selectors and actions instead of the core/editor ones.
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 block-editor module.
- Autocomplete
- AlignmentToolbar
- BlockAlignmentToolbar
- BlockControls
- BlockEdit
- BlockEditorKeyboardShortcuts
- BlockFormatControls
- BlockIcon
- BlockInspector
- BlockList
- BlockMover
- BlockNavigationDropdown
- BlockSelectionClearer
- BlockSettingsMenu
- BlockTitle
- BlockToolbar
- ColorPalette
- ContrastChecker
- CopyHandler
- createCustomColorsHOC
- DefaultBlockAppender
- FontSizePicker
- getColorClassName
- getColorObjectByAttributeValues
- getColorObjectByColorValue
- getFontSize
- getFontSizeClass
- Inserter
- InnerBlocks
- InspectorAdvancedControls
- InspectorControls
- PanelColorSettings
- PlainText
- RichText
- RichTextShortcut
- RichTextToolbarButton
- RichTextInserterItem
- UnstableRichTextInputEvent
- MediaPlaceholder
- MediaUpload
- MediaUploadCheck
- MultiBlocksSwitcher
- MultiSelectScrollIntoView
- NavigableToolbar
- ObserveTyping
- PreserveScrollInReorder
- SkipToSelectedBlock
- URLInput
- URLInputButton
- URLPopover
- Warning
- WritingFlow
- withColorContext
- withColors
- withFontSizes
Selectors Moved to block-editor
This is the exhaustive list of the data module selectors that moved to the core/block-editor store.
- canInsertBlockType
- getAdjacentBlockClientId
- getBlock
- getBlockAttributes
- getBlockCount
- getBlockDependantsCacheBust
- getBlockHierarchyRootClientId
- getBlockIndex
- getBlockMode
- getBlockName
- getBlockOrder
- getBlockRootClientId
- getBlockInsertionPoint
- getBlockListSettings
- getBlocks
- getBlocksByClientId
- getBlockSelectionStart
- getBlockSelectionEnd
- getClientIdsOfDescendants
- getClientIdsWithDescendants
- getFirstMultiSelectedBlockClientId
- getGlobalBlockCount
- getInserterItems
- getLastMultiSelectedBlockClientId
- getMultiSelectedBlockClientIds
- getMultiSelectedBlocks
- getMultiSelectedBlocksEndClientId
- getMultiSelectedBlocksStartClientId
- getNextBlockClientId
- getPreviousBlockClientId
- getSelectedBlockCount
- getSelectedBlockClientId
- getSelectedBlock
- getSelectedBlocksInitialCaretPosition
- getTemplate
- getTemplateLock
- hasInserterItems
- hasMultiSelection
- hasSelectedBlock
- hasSelectedInnerBlock
- isAncestorMultiSelected
- isBlockInsertionPointVisible
- isBlockMultiSelected
- isBlockSelected
- isBlockValid
- isBlockWithinSelection
- isCaretWithinFormattedText
- isFirstMultiSelectedBlock
- isMultiSelecting
- isSelectionEnabled
- isTyping
- isValidTemplate
Actions Moved to block-editor
This is the exhaustive list of the data module actions that moved to the core/block-editor store.
- clearSelectedBlock
- enterFormattedText
- exitFormattedText
- hideInsertionPoint
- insertBlock
- insertBlocks
- insertDefaultBlock
- mergeBlocks
- moveBlocksDown
- moveBlocksUp
- moveBlockToPosition
- multiSelect
- receiveBlocks
- removeBlock
- removeBlocks
- replaceBlocks
- resetBlocks
- selectBlock
- setTemplateValidity
- showInsertionPoint
- startMultiSelect
- startTyping
- stopMultiSelect
- stopTyping
- synchronizeTemplate
- toggleBlockMode
- toggleSelection
- updateBlock
- updateBlockAttributes
- updateBlockListSettings
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 block-editor-inserter__toggle.
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.
#5-2, #dev-notes, #gutenberg
