WordPress 5.4 makes several DOM structure changes on 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. Ideally, your code doesn’t depend on WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. class names or a specific DOM, since class names and the DOM structure are not part of the WordPress public API.
Remove legacy “editor-” class name compatibility
WordPress 5.2 updated the CSS Cascading Style Sheets. class names of a lot of the components in the block editor, changing
editor- prefixes on those class names to
block-editor-. Where the old class names still existed, largely in component references, the conventional wisdom urged developers to avoid those references or update them accordingly.
In WordPress 5.4, these old
editor--prefixed class names are gone from components in the block-editor scripts. If you’re still referencing the editor-prefixed CSS class name of a component, you’ll need to update to the block-editor- equivalent.
Div with class edit-post-layout__content removed
The `edit-post-layout__content` div is gone from the DOM of the block editor. Check your custom styles and plugin 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 files to make sure you’re not targeting it fir styling.
Blocks and rich text components lose redundant wrappers
The key to this refactor: moving controls out of the elements and into adjacent popovers, which made four
div wrappers redundant—so now they’re gone.
The result: significant performance improvement—and the editor-content DOM looks a lot more like the front end. So styling blocks is now a lot easier for both block and theme authors. Eventually, the plan is to let blocks render the very same tree in the editor as on the front end.
Here’s how those changes have affected the block-editor DOM:
block-editor-rich-text class is now part of the editable element, unless you’re still using the
wrapperClasses prop (which you should really stop using). If you really need a wrapper around the editable element, you’re better off creating your own.
data-block attribute, containing the block ID, has relocated to the outer block wrapper element. The
block-editor-block-list__block-edit class is gone completely; so is the
div element. Selectors like
.wp-block > .block-editor-block-list__block-edit > [data-block] won’t work anymore. Use
.wp-block or just the
[data-type] attribute instead.
Simpler block margins
17877 changes the way the block editor lays out blocks. Before now, every block came with built-in padding, left and right, and negative margins to compensate.
Well, in a bid to radically simplify the CSS you need to style blocks, to develop blocks, to build themes and style the editor in your themes, the built-in padding and negative margins are refactored out of existence—they’re GONE.
Now, if your current block or editor styles have been compensating for those previous margins/paddings, they might look a little off in version 5.4. If so, try getting rid of the styles you wrote to compensate.
#5-4, #block-editor, #dev-notes