Twenty Twenty-One: Search block "Button inside" input border appears on front end but not in block editor

[levinbaria]

Theme: TwentyTwentyOne.

In the TwentyTwentyOne theme for WordPress, when using the Search block with the Button position set to "Button inside", the block editor (editor view) may not display a border around the search input, even though it appears correctly on the front-end (site view).

Theme: TwentyTwentyOne.

In the TwentyTwentyOne theme for WordPress, when using the Search block with the Button position set to "Button inside", the block editor (editor view) may not display a border around the search input, even though it appears correctly on the front-end (site view).

Trac ticket: https://core.trac.wordpress.org/ticket/63888

[sabernhardt]

The "Button inside" style intentionally removed the border from the input field (see ​PR 912 and ​PR 673).

Twenty Twenty-One added border: none in the editor but relied on the block library styles to remove the border from the front end. Then GB41393 lowered the specificity (0-1-0), and the theme's default border overrides that now (0-2-0).

To follow the original design, the front-end styles would need adjusting instead of editor styles. However, the border is part of the appearance since November 2022. People who have chosen the "Button inside" option in the past few years might appreciate that it has a border now. Changing the editor styles to match the front could be the better choice.

[karmatosed]

I’d advise to update the editor to match the front end. The border has been there since 6.1, and people may have chosen this style because of how it looks. Keeping that appearance seems less disruptive than removing it now.

For now, adding to get the patch updated to that.

In the Twenty Twenty-One theme, the Search block's "Button inside" style shows a border around the input/button group on the front end but not in the block editor. The theme's editor styles (_editor.scss) explicitly set border: none on the input for this style, originally relying on the block library's own front-end CSS to draw the border there. A later Gutenberg change (GB41393) lowered the specificity of that block-library rule, so the theme's own border rule now wins on the front end while the editor keeps hiding it — the two views have been out of sync since WordPress 6.1.

Per the ticket discussion, the maintainer team decided the editor should be updated to match the front end (the border has shipped on the front end since 6.1, so removing it now would be more disruptive than keeping it). This PR removes the border: none override in _editor.scss and regenerates the corresponding rule in the compiled style-editor.css, so the editor preview matches the front-end appearance.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5
Used for: Implementation and PR description, based on ticket discussion and root-cause analysis in the Trac comments. Verified against a local build with a live before/after comparison in the block editor. Reviewed by Igor Rozum.