v2.7.1: block editor fixes, theme-accurate previews, variable autocomplete
Fixed
Code editors were unusable inside the block canvas. wp.codeEditor loads into the admin document, but the block canvas has been an iframe since WP 6.3. A CodeMirror mounted there resolves focus and key events against the outer document, so it rendered correctly and could not be clicked into or typed in. The plain textarea is now used there, as core's Custom HTML block does. Tab in that textarea also silently discarded its indent; it now commits properly.
Block editor UI shipped unstyled. Styles enqueued for the editor only reach the outer admin document, so the block's own chrome had no CSS and the device-preview controls rendered as blank squares with no dashicons. The stylesheet is now registered as the block's editor_style, which is what gets it into the canvas.
Inline block CSS could be silently dropped. Whether a block emitted its <style> was gated on a request-global flag raised by any block on the queried post. A block rendered from a widget, synced pattern, or template part was silenced by a flag raised on another block's behalf. CSS is now tracked per block.
minify_css corrupted quoted strings and math functions. [style*="font-weight: 300"] and [style*="font-weight:300"] are different selectors; collapsing the space merged them. Separately, clamp(6.75rem, 6rem + 2.2vw, 9rem) requires the spaces around +, while the sibling combinator requires collapsing them. Both are now handled.
Changed
- Previews load theme.json global styles alongside every theme stylesheet, so
var()resolves as it does on the front end. - The CSS editor suggests the custom properties the active theme defines, harvested from its stylesheets and theme.json.
- The block editor chrome now follows the WordPress admin: its palette, 2px radii, system font, and standard button treatment.
- The
formattoggle applieswpautop(), matching its label, instead of running the wholethe_contentfilter chain from inside a block that is itself rendering duringthe_content.