Base styles: Fix admin-page-layout header selector for admin-ui 2.1#49006
Merged
Conversation
@wordpress/admin-ui 2.1.0 (Gutenberg PR WordPress/gutenberg#78001) removed render={ <header /> } from the Page header's Stack, so the rendered element changed from <header> to <div>. The mixin's > header selectors silently stopped matching and the header was no longer pinned at the top of the flex column. Anchor to > :first-child instead — Page always renders its Header as the first child of the page wrapper, regardless of element type. Forward-compatible with 2.1+ and backward-compatible with 2.0.
CGastrell
added
[Status] In Progress
[JS Package] Base Styles
[Status] UI Changes
Contributor
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Contributor
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
…lable-middle selector Mirrors the selector change in 8e4d22a onto the `:not(header)` companion rule. Same upstream cause — admin-ui 2.1 renders the page header as a `<div>` instead of `<header>`, so position-based selectors are required to keep the scrollable-middle partition correct.
CGastrell
added a commit
that referenced
this pull request
May 22, 2026
Replace the three `> header` selectors in the AdminPage SCSS module with `> :first-child` so they keep matching after @wordpress/admin-ui 2.1 changed the page header element from <header> to <div>. Together with #49006 (which applied the same fix to the shared admin-page-layout mixin in js-packages/base-styles), this resolves the publicize page header spacing regression that surfaced on PR #48404 — the title/subtitle ' compaction' was the cumulative effect of the three jetpack-side overrides (sticky-disable, border removal, visual-slot centering) silently ceasing to fire, not a missing gap. Also bumps @wordpress/admin-ui from 2.0.0 to 2.1.0 in this package as the consumer-side pin of the version this fix targets.
CGastrell
added a commit
that referenced
this pull request
May 22, 2026
….1 (#49018) * Components: fix AdminPage SCSS module header selectors for admin-ui 2.1 Replace the three `> header` selectors in the AdminPage SCSS module with `> :first-child` so they keep matching after @wordpress/admin-ui 2.1 changed the page header element from <header> to <div>. Together with #49006 (which applied the same fix to the shared admin-page-layout mixin in js-packages/base-styles), this resolves the publicize page header spacing regression that surfaced on PR #48404 — the title/subtitle ' compaction' was the cumulative effect of the three jetpack-side overrides (sticky-disable, border removal, visual-slot centering) silently ceasing to fire, not a missing gap. Also bumps @wordpress/admin-ui from 2.0.0 to 2.1.0 in this package as the consumer-side pin of the version this fix targets. * Search e2e: adapt header-logo locator to admin-ui 2.1's <div> page header The dashboard test was scoping the Jetpack Logo locator via `page.locator( 'header' )` — coupling to admin-ui 2.0's <header> element. admin-ui 2.1 renders the page header as a <div> (WordPress/gutenberg#78001), so the locator finds nothing once this PR's admin-ui pin lands. Swap the locator to `.jp-admin-page__page > :first-child` — same positional pattern this PR uses in the SCSS module, matches both the old <header> and the new <div>. Updates the surrounding comment to explain the choice.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes header growing to fill the flex column on dashboards that adopted the shared
jetpack-admin-page-layoutmixin once@wordpress/admin-uibumps to 2.1.x.Proposed changes
admin-page-layout.scss's two header-anchoring selectors from.jp-admin-page__page > headerto.jp-admin-page__page > :first-child.Why
@wordpress/admin-ui2.0.x rendered the<Page>'s header as a<header>element (viarender={ <header /> }on the Stack). 2.1.0 removed that render prop — see Gutenberg PR WordPress/gutenberg#78001 ("Fix nested landmark in header") — so the header is now a plain<div>. Verified locally against both versions resolved undernode_modules/.pnpm/:@wordpress/admin-ui@2.0.0—src/page/header.tsxline 36:render={ <header /> }@wordpress/admin-ui@2.1.0—src/page/header.tsxline 58: no headerrenderprop on the outer StackWith the element change, our
> headerselector silently stops matching: the header losesflex-shrink: 0and grows to fill the flex column, and the tabs-strip flush-fit rule stops firing too.Why
:first-childadmin-ui's
<Page>always renders<Header>as the first child of the page wrapper (src/page/index.tsx).> :first-childis therefore stable across element changes inside<Header>'s render tree and works for both 2.0 (<header>) and 2.1+ (<div>). The CSS-Modules class hash on the new wrapper is not selector-stable, so structural selection is the only forward-compatible option.Context
This surfaced via Renovate PR #48404 (bundled
@wordpress/*bump to 2.1.x). Without this change, dashboards using<AdminPage>(VideoPress, Search, Newsletter, Protect, etc.) show a header that grows to fill the flex column once they pull admin-ui 2.1+.Related product discussion/links
@wordpress/*monorepo bump to 2.1.x).Does this pull request change what data or activity we track or use?
No.
Testing instructions
This is an SCSS-only change in a shared mixin. To verify functionally:
@wordpress/admin-ui@2.1.xinstalled, build a consumer of the mixin — for example:<AdminPage>(e.g. VideoPress, Search, Newsletter, Protect).@wordpress/admin-ui@2.0.x(e.g. trunk pre-Renovate) — the layout should be identical to before (> :first-childmatches the<header>element just like> headerdid).:has(.jp-admin-page-tabs) > :first-childrule still applies itsborder-bottom: none; padding-bottom: 0).