Repository navigation
Admin: share the Jetpack logo mark between the masthead and the Akismet footer - #52694
Conversation
…et footer The same SVG was inlined in both files, byte for byte. Height, class and accessible name differ per call site, so they become parameters.
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
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! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
1 file is newly checked for coverage.
|
In this plugin "Chrome" on its own reads as the browser, so the old name parsed as the Google Chrome logo. "Admin chrome" is the phrase the codebase already uses for this UI, as in Akismet_Admin_Chrome.
Proposed changes
The green Jetpack mark was inlined as a raw SVG string in two neighbouring admin-chrome files, byte for byte identical in
viewBox,filland path data. This moves it to oneAdmin_Chrome_Logo::render()helper and has both call sites use it.Height, class and accessible name genuinely differ per call site, so they become parameters rather than being flattened:
2016jp-akismet-logorole="img" aria-label="Jetpack logo"aria-hidden="true"The a11y split is deliberate, not drift — the Akismet mark sits beside visible "Jetpack" text, so announcing it twice is noise. Passing no label is what makes the mark decorative.
The helper lives in
src/rather than onJetpack_Admin_Pagefor the reasonFooter_Linksalready documents: WordPress.com Simple declares its own stub of that class, andAkismet_Admin_Chromeruns there viaAkismet_Admin_WPCOM.Nothing renders differently. Attribute order is preserved so both call sites emit exactly the markup they emitted before, and a test pins those two exact strings so a future tidy-up of the attribute order fails loudly instead of silently changing output.
Not in scope
Per the issue:
packages/logois untouched (its emblem carries anid, no height, and no label hook, so it isn't a drop-in), as is the black footer mark inwrap_ui()and the ~12 JSX/other copies of the path data elsewhere in the monorepo.Before / after
Admin_Chrome_Logo::render()has exactly two call sites, and the masthead one has two wrapper branches, so there are three distinct rendered outputs. All three are below. The page that callswrap_ui()(Modules, About, Debug, Publicize, Stats) does not vary the logo, so those are the same three cases rather than extra ones.Captured on a live Jurassic Ninja site at 1440×900, same window and same crop for every frame. "Before" is
trunk; "after" is this branch. Only the plugin build changed between the two passes — site state was held constant, with the two masthead cases toggled by a query-param filter rather than by reconfiguring the site.1. Masthead — My Jetpack available (logo wrapped in
<a>)2. Masthead — My Jetpack unavailable (logo wrapped in
<span>)3. Akismet settings footer (16px, decorative)
These are pixel-identical, not just similar
Each pair has the same dimensions and the same SHA-256 over the decoded PNG pixel data:
652178cf1a2ec011652178cf1a2ec01194fdd51eafc39a9c94fdd51eafc39a9c6d07e099e4c3d0a86d07e099e4c3d0a8And the DOM read live on each revision agrees:
<svg>attributesA→Aheight="20" role="img" aria-label="Jetpack logo"— unchangedSPAN→SPANheight="20" role="img" aria-label="Jetpack logo"— unchangedheight="16" class="jp-akismet-logo" aria-hidden="true"— unchangedRelated product discussion/links
JETPACK-2763. Surfaced while reviewing #52606, which hoisted the masthead copy into a variable and made the duplication visible.
Does this pull request change what data or activity we track or use?
No.
Testing instructions
The claim is that this changes nothing a user can see, so the useful test is proving that:
trunkand compare. I did this on a live instance by renderingJetpack_Admin_Page::wrap_ui()andAkismet_Admin_Chrome::render_footer()throughwp eval-fileon both revisions — 3813 bytes, byte-identical, covering the masthead and the Akismet footer.jp docker phpunit jetpack -- --filter='Admin_Chrome_Logo_Test|Akismet_Admin_Chrome_Test'→OK (14 tests, 44 assertions).Akismet_Admin_Chrome_Testexercises both real call sites;Admin_Chrome_Logo_Testcovers labelled vs decorative, the omitted-when-empty class, per-caller height, and the two exact output strings.Gates run
jp docker phpunit jetpack(filtered) — 14 tests, 44 assertions, passjp phan plugins/jetpack— no issues outside test filesphp -lon all touched files — clean