AdminPage: stick JetpackFooter to the bottom of the viewport

[angelablake]

Part 1 of a stacked PR series extracted from #48154 (Jetpack SEO: introduce new SEO product).

This is the smallest, foundational piece: make the shared AdminPage component a flex column with min-height: calc(100vh - --wp-admin--admin-bar--height), and give .jetpack-footer margin-top: auto. Every product using the shared admin shell gets a consistent sticky-footer layout instead of the footer floating up against short content.

Originally authored by @keoshi in #48154; extracted here so it can land independently and unblock the rest of the SEO product split.

Proposed changes

• .admin-page becomes a flex column with a viewport-based min-height, fitting wp-admin's content area.
• :global(.admin-ui-page) flex-grows inside that column.
• :global(.jetpack-footer) claims any leftover vertical space via margin-top: auto.

Related product discussion/links

• Extracted from Jetpack SEO: introduce new SEO product #48154 — see that PR for the SEO product PRD, design, and JETH-10045 references.

Screenshots

Before/after screenshots showing the footer position on a short Jetpack admin page (e.g. My Jetpack landing) — to be added.

Testing instructions

The change affects every Jetpack admin page that uses the shared AdminPage shell (My Jetpack, the main Jetpack settings page, Boost, Protect, Search, Backup, Stats, etc.).

Verify the footer sticks to the bottom on short pages:

• Visit wp-admin/admin.php?page=my-jetpack. With short content, the JetpackFooter should sit at the bottom of the viewport, not float up against the content with empty space underneath.

Verify the footer appears normally on long pages:

• Visit wp-admin/admin.php?page=jetpack#/settings and expand all the cards. The footer should appear at the end of the content with normal scrolling — no clipping, no overlap with content above.

Verify no visual regression on:

• The header layout (JetpackLogo position, tabs alignment, sandbox-domain badge on dev sites)
• Any page using AdminPage that already rendered correctly (Boost, Protect, Search, Backup, Stats dashboards)

Does this pull request change what data or activity we track or use?

No.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the update/admin-page-sticky-footer branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/admin-page-sticky-footer

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/admin-page-sticky-footer

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

This 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. 🤷

Full summary · PHP report · JS report

[simison]

Pretty sure there's a way to do this already without adding all these styles in the admin page component. 🤔 @CGastrell likely knows more. 👋

[simison]

Using the internal CSS selector from admin-ui will break in future and cannot be used as a stable API.

[simison]

Likely works with variable, but noting that the default will be 48px when on mobile.

[CGastrell]

Thanks for splitting this out, @angelablake ! Before this lands I want to flag two things: it overlaps with layout infrastructure we already have, and it couples the shared <AdminPage> to an admin-ui internal class we deliberately migrated away from.

The :global(.admin-ui-page) selector couples us to an admin-ui internal

This hunk is a faithful extraction of @keoshi's original change in #48154, but #48154 was branched off an older trunk. Back then the shared AdminPage module did style :global(.admin-ui-page) (the original diff in #48154 moves and extends that existing block). Since then trunk migrated every one of those rules to :global(.jp-admin-page__page) (#49006, #49018, #49080, #49101), on purpose: jp-admin-page__page is the className we pass to admin-ui's <Page>, so it's the one hook on that node we fully control. admin-ui's own page class is an internal CSS-module name, and it is not stable across builds — which is the whole reason for that migration.

Concretely, "the same" admin-ui 2.1.0 emits different classes depending on which build you run:

• The standalone @wordpress/admin-ui@2.1.0 npm build (and upstream Gutenberg src, which moved Page to CSS Modules in #77088) renders clsx( styles.page, className ) where styles.page is a hashed name like _956b…__page — no literal admin-ui-page at all.
• The WP core bundle in our current Docker image (WP 6.9.4) renders clsx( "admin-ui-page", className ) — a literal admin-ui-page.

Because Jetpack externalizes @wordpress/admin-ui at runtime (it resolves to window.wp.adminUi, i.e. whatever WP core ships), the class that actually lands in the DOM depends on the visitor's WP version. So :global(.admin-ui-page) happens to match on a current WP today, but it's betting on an admin-ui internal that upstream already hashes and that we don't control — exactly the coupling the .jp-admin-page__page convention exists to avoid. (The clear: both added here is also already present on .jp-admin-page__page.)

We already have this layout — jetpack-admin-page-layout

projects/js-packages/base-styles/admin-page-layout.scss already pins JetpackFooter to the bottom of the viewport, using the stable hooks: .jp-admin-page → .jp-admin-page__page (flex: 1 1 auto) → a growing middle section that pushes .jetpack-footer (flex-shrink: 0) to the bottom. It also handles the wp-admin chrome a bare min-height: 100vh can't: hiding #wpfooter and #screen-meta-links, sidebar widths across the auto-fold / mobile / nav-unification breakpoints, and internal scroll containment. It's already opted into by Boost, Protect, Search, Backup, My Jetpack, VideoPress, Publicize, Newsletter, Activity Log, Podcast, Scan, and the Jetpack plugin — i.e. essentially every page this PR's testing instructions name.

Suggested path

To unblock the SEO series now (smallest change): drop the style.module.scss edits from this PR and have the SEO package opt into the mixin, the same way every other product does. The SEO shell uses the shared <AdminPage> with breadcrumbs/title (the admin-ui Page branch), so the -wp-build variant is the right one (it adds the breadcrumb resets):

@use "@automattic/jetpack-base-styles/admin-page-layout" as *;

:global {
  body.jetpack_page_jetpack-seo { // adjust to the SEO page's real body class
    @include jetpack-admin-page-layout-wp-build;
  }
}

That gives SEO the sticky footer (plus the rest of the chrome) on the stable selectors, with zero changes to the shared component.

If the real goal is to make sticky-footer the default for every AdminPage (which is what doing this in the shared module implies), that's a reasonable thing to want — but it should be a deliberate, separate change: implement it on .jp-admin-page__page / .jetpack-footer (not .admin-ui-page), and reconcile with the ~12 packages that already @include jetpack-admin-page-layout so they don't end up with a doubled flex chain or a double-counted min-height. Happy to pair on that if it's the direction you want.

One more heads-up

The SEO package's own _inc/style.module.scss in #48154 also targets :global(.admin-ui-page) / .admin-ui-page__content / .admin-ui-page__header. Those carry the same fragility — they lean on admin-ui's internal class, which is hashed in the standalone build and only literal in some WP core bundles, so they'll silently stop matching when that internal changes. Worth auditing in whichever stacked PR carries that file.

[angelablake]

Thanks @CGastrell ! I'll take your suggestion.

[angelablake]

One more thing while I'm here — also addressed CGastrell's "one more heads-up" paragraph in the same commit: migrated the .neutralBg targets in projects/packages/seo/_inc/style.module.scss off :global(.admin-ui-page) / :global(.admin-ui-page__content) and onto the stable :global(.jp-admin-page__page) hook. So both the layout opt-in and the SEO package's own admin-ui-internal coupling are handled in 19d604e224.

Closing this PR — the work moves into #49203.

(Posted via Claude on Angela's behalf.)