CRM: Align admin footer with the unified Jetpack footer

[CGastrell]

Fixes JETPACK-1508

Summary

Aligns the Jetpack CRM admin footer with the unified Jetpack admin-page footer used across the other Jetpack products, following the same pure-PHP/CSS approach as the header work in jetpack#47871. This standalone repo doesn't ship @automattic/jetpack-components, so the React JetpackFooter component isn't available. The look is reproduced with PHP markup and SCSS instead.

Before: "Thank you for using Jetpack CRM." + "Jetpack CRM v6.8.1"

After: Jetpack logo + "Jetpack" (left) · Automattic "An Automattic Airline" byline (right)

Changes

• includes/ZeroBSCRM.AdminStyling.php — swap the two footer filters' output to the Jetpack logo (left) and Automattic byline (right).
• sass/emerald/_jpcrm_footer.scss (new) — restyle #wpfooter on CRM pages: top border, #fcfcfc surface, flex layout, byline pushed right. WPDS tokens with hardcoded fallbacks, mirroring _jpcrm_top_menu.scss. Three of them are written as var(--short, var(--long, #hex)) because this repo still pins @wordpress/theme@0.13.0, which only defines the short-form names. They pick up the long-form names automatically once Bump @wordpress/theme to 1.x and migrate to renamed WPDS token names #13 bumps the package.
• sass/jpcrm-emerald.scss — @use the new partial.
• admin/settings/general.page.php — the "Show admin credits" description promised "Powered by Jetpack CRM" footers. It doesn't do that any more, so it now describes the Jetpack and Automattic logos.

Gating (unchanged)

All the existing conditions are preserved. The footer renders only on CRM admin pages, and only when the "Show admin credits" setting (showpoweredby_admin) is on. The branding sits inside ##WLREMOVE blocks so it's stripped from white-label builds.

To be clear about where that happens: nothing in this repo strips the markers. scripts/build-plugin.sh leaves them alone, and the stripping is done by the white-label pipeline outside this repo. So it can't be verified by running make release here.

The SCSS is guarded with #wpfooter:has(.jetpack-footer__logo) so no border or surface is drawn when the footer is empty (credits off, or white label).

Two deliberate behaviour changes

• The CRM version no longer shows anywhere in the admin UI. That matches the other Jetpack products, which don't show a version in the footer either. update_footer still runs at priority 11, so the WordPress version stays suppressed on CRM pages as before. The plugin version is still on the Plugins screen.
• The footer is now visible below 782px. Core hides #wpfooter at that width; the new base rule outranks it. This is what the unified footer does, so it's intentional, but it isn't obvious from the diff.

Testing

• Verified on a live install in the normal branded state (logo + byline, #fcfcfc surface, computed values matching the real My Jetpack footer).
• Toggled "Show admin credits" off. The footer cleanly reverts to the default empty WP footer, with no leftover styling.
• Emulated the white-label build by stripping every ##WLREMOVE block. The footer renders empty with no Jetpack/Automattic branding leak and no orphaned styling, the header correctly falls back (no "CRM" text), and php -l is clean on the stripped file.

Note: the compiled CSS under css/ is gitignored in this repo, so this PR is source-only. The SCSS is compiled at build/release time.

🤖 Generated with Claude Code

[enejb]

Lets remove these comments.

[enejb]

Do we really need to do this? I don't see a element with a clear class that was added.

[CGastrell]

Keen eye! If it stays visible, it becomes a trailing flex item and the gap pushes the Automattic byline 24px off the right edge. So the rule is doing real work.

[CGastrell]

Added a comment to make it clear, but we can remove that as well

[donnchawp]

I had a read through _jpcrm_footer.scss. A few things on the WPDS tokens, and one comment that needs correcting.

Three of the token names don't exist:

• :8 uses --wpds-color-background-surface-neutral. The real token is --wpds-color-bg-surface-neutral.
• :71 uses --wpds-color-foreground-neutral-strong. Real one is --wpds-color-fg-content-neutral.
• :83 uses --wpds-color-foreground-interactive-neutral-weak. Real one is --wpds-color-fg-interactive-neutral-weak.

I checked against the :root block in the compiled css/jpcrm-emerald.css, which defines 178 of these. None of the three are in there, so the fallbacks are doing all the work and the footer won't follow WPDS when it changes.

Two of the three render the same either way, #fcfcfc and #1e1e1e match the real token values. Line 83 doesn't. It falls back to #646970 where the real token is #707070, so the Automattic byline is the wrong grey. Small, but it's there on screen now.

_jpcrm_top_menu.scss uses bg and fg-content correctly, so at the moment the two partials only look consistent.

Two more where the token does resolve and the fallback is just dead:

• :9 --wpds-color-stroke-surface-neutral-weak is #e4e4e4, the fallback says #e0e0e0.
• :15 --wpds-dimension-padding-xl is 20px, the fallback says 16px.

Nothing renders wrong there, the values never get used. Worth matching them up so nobody reads 16px and believes it.

The comment at :30-32 doesn't match what core does. It says the desktop left margin gets left on #wpfooter, but the rule that actually applies is .auto-fold #wpfooter { margin-left: 36px } in admin-menu.css:549, inside @media only screen and (max-width: 960px). So it's a 36px indent, not the 160px one.

The block itself is fine and I'd keep it. Core hides the footer below 783px (common.css, @media screen and (max-width: 782px) { #wpfooter { display: none } }), but the base rule here un-hides it:

body.jpcrm-admin #wpfooter:has(.jetpack-footer__logo) { display: flex }

No media query, and a specificity of (1,2,1) against core's (1,0,0), so display: flex wins below 782px. I checked in Firefox's mobile emulator at 360x780 and the footer is there and stacked, so :43-56 is doing real work. Might be worth saying that in the comment, it took me a while to work out why the block was reachable at all.

So five token names and one comment. Shout if I've read the specificity wrong.

[CGastrell]

I had a read through _jpcrm_footer.scss. A few things on the WPDS tokens, and one comment that needs correcting.

Three of the token names don't exist:

• :8 uses --wpds-color-background-surface-neutral. The real token is --wpds-color-bg-surface-neutral.
• :71 uses --wpds-color-foreground-neutral-strong. Real one is --wpds-color-fg-content-neutral.
• :83 uses --wpds-color-foreground-interactive-neutral-weak. Real one is --wpds-color-fg-interactive-neutral-weak.

I checked against the :root block in the compiled css/jpcrm-emerald.css, which defines 178 of these. None of the three are in there, so the fallbacks are doing all the work and the footer won't follow WPDS when it changes.

Oh boy, welcome to the madness. We've recenlty had a monorepo update and that go mixed with a var rename of the design tokens. So I triggered a replacement sweep and eventually got it merged into the update.

Let me dig deeper, but I'm not liking this already

[CGastrell]

Dug into the token issue @donnchawp raised — good catch, and there's a wrinkle worth recording.

The rename went the other way. The WPDS tokens were renamed short → long (bg → background, fg → foreground), not the reverse. The long-form names in the footer partial are the newer names — they just don't exist yet in what this repo ships. jetpack-crm pins @wordpress/theme@0.13.0, whose design-tokens.css (compiled into the :root block of css/jpcrm-emerald.css) still uses the old short names. So every long-form token in the footer resolved to nothing and fell back to its hardcoded value. _jpcrm_top_menu.scss uses the short names, which is why it renders correctly today.

So @donnchawp's recommended renames were right for what we ship — I just corrected the reasoning.

Fixed in df8dcb9 (footer partial only):

• The three renamed color tokens now use a double var() fallback: var(--short, var(--long, #hex)) — resolves today against 0.13.0, auto-tracks WPDS after we bump to 1.x, hardcoded value as last resort.
• foreground-neutral-strong was an invented name (exists in neither naming) → now fg-content-neutral, the real #1e1e1e token.
• Corrected the two dead fallbacks on the non-renamed tokens (stroke-surface-neutral-weak #e4e4e4, padding-xl 20px).
• Fixed the byline grey — #646970 → #707070 (the one visible defect).
• Rewrote the mobile comment: the residual indent is the 36px .auto-fold icon-menu margin (admin-menu.css, @media max-width: 960px), not the desktop margin, plus a note on why the mobile rules are reachable below 782px.

Follow-up (separate PR): bump @wordpress/theme 0.13.0 → 1.x. That's the real "adopt the renamed tokens" work. When we do it, the :root block flips to long names + updated values (e.g. stroke-surface-neutral-weak becomes #f0f0f0), and every current consumer needs migrating — right now only _jpcrm_top_menu.scss uses --wpds-* tokens (bg-surface-neutral-strong, fg-content-neutral, fg-content-neutral-weak), so the blast radius is small but real: those short names would stop resolving and drop to fallbacks until migrated. Thanks to the double-var above, this footer needs no changes when that lands — it'll pick up the long names automatically. Tracked in #13.