fix: hide unavailable My Jetpack links in Boost and Jetpack

[LiamSarsfield]

Proposed changes

Use My Jetpack's shared admin-page availability check for Boost's links, with a compatibility guard for older package versions. Only link Jetpack's masthead logo and title to My Jetpack when its page is reachable; preserve the branding when it is unavailable.

Include one focused regression test per behavior and changelog entries for Boost and Jetpack.

Before / after

Captured on a live Jurassic Ninja site at /wp-admin/admin.php?page=jetpack_modules, 1440×900. The site is in Offline Mode, so My_Jetpack_Initializer::should_initialize() returns false and the My Jetpack page is genuinely never registered — the exact condition this PR handles. Baseline is the Jetpack build JN ships (16.3-a.3), which already has #52557's Footer_Links but still renders the masthead anchor unconditionally.

Both shots are hovering "Jetpack". At rest the two states are pixel-identical: .jp-masthead__title-link uses the same colour as the surrounding text with text-decoration: none, and .jp-masthead__logo-link is styled by class, so swapping <a> for <span> moves nothing. Hover is where the difference is visible.

Before — "Jetpack" underlines, linking to an unreachable page	After — plain text, no link

Measured in the DOM on the same page, same site:

	Before	After
.jp-masthead__logo-link tag	A	SPAN
logo href	…page=my-jetpack#/overview	none
.jp-masthead__title-link present	yes	no
My Jetpack links in masthead	2	0
Logo SVG still rendered	yes	yes (role="img")
Masthead title text	Jetpack / Offline Mode / Modules	Jetpack / Offline Mode / Modules

Branding is preserved in both — only the links go away.

Related product discussion/links

Follow-up to #52557. The editor page-load correction is being handled separately.

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

No.

Testing instructions

1. With Boost and Jetpack active, verify My Jetpack links appear when its admin page is registered and the current user can edit posts.
2. Disable My Jetpack initialization or remove its registered page. Verify Boost hides its My Jetpack and license links, and the Jetpack Modules masthead retains its logo and title without links to My Jetpack.
3. Run Boost's Config_Test and Jetpack's Akismet_Admin_Chrome_Test PHPUnit cases.

[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), and enable the fm/boost-745-footer-followups branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fm/boost-745-footer-followups

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!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: October 6, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Boost plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/boost/app/admin/class-config.php	47/49 (95.92%)	-1.95%	1 ❤️‍🩹
projects/plugins/jetpack/_inc/lib/admin-pages/class.jetpack-admin-page.php	139/196 (70.92%)	4.07%	-5 💚

Full summary · PHP report · JS report

[LiamSarsfield]

Validation history moved from the PR description:

Validation: Boost Config passed 9 tests / 40 assertions; Jetpack admin chrome passed 9 tests / 30 assertions. The Boost regression fails against the original code. Pipeline harnesses also reproduced both original bugs and checked the fixed rendering. PHPCS, PHP syntax, compatibility commit hooks, Jetpack Phan, and changelog checks passed. Boost Phan reports two existing findings in unchanged files. Boost's JavaScript suite passed. An initial Jetpack JavaScript failure did not recur on clean trunk or the separate editor-fix branch: both reruns passed all 225 suites / 1,872 tests.

Styled masthead browser verification remains outside the pipeline's isolated test environment; its rendered evidence used controlled WordPress functions without compiled styles.

[xavier-lc]

Review

Reviewed at b444cd9def30fd5c7630280d8eba8fe707d053ed — 6 files, 77 lines.

The core logic is right, and the gating is consistent across every My Jetpack entry point in wrap_ui(): L277, L303 and L397 now share one flag, and class-akismet-admin-chrome.php:350 was already gated. Timing works out too — Boost's only caller runs on admin_enqueue_scripts and wrap_ui() renders during page output, both well after admin_menu populates $_registered_pages. No selector risk from the <a> → <span> swap: jp-masthead__logo-link and jp-masthead__title-link are styled by class rather than a.…, so the span keeps its 24px box, and neither class is used as a JS hook anywhere in the monorepo (the only JSX match is the separate React dashboard masthead, which links to #/settings).

No blockers. Six suggestions below; 5 and 6 are the ones I'd actually action, the rest are polish.

---

Markup

1. [suggestion] The conditional element is split across four if/else/endif blocks

jetpack/projects/plugins/jetpack/_inc/lib/admin-pages/class.jetpack-admin-page.php

Lines 277 to 287 in b444cd9

	<?php if ( $my_jetpack_available ) : ?>
	<a class="jp-masthead__logo-link" href="<?php echo esc_url( admin_url( 'admin.php?page=my-jetpack#/overview' ) ); ?>">
	<?php else : ?>
	<span class="jp-masthead__logo-link">
	<?php endif; ?>
	<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" height="20" aria-label="<?php esc_attr_e( 'Jetpack logo', 'jetpack' ); ?>"><path fill="#069e08" d="M16,0C7.2,0,0,7.2,0,16s7.2,16,16,16s16-7.2,16-16S24.8,0,16,0z M15,19H7l8-16V19z M17,29V13h8L17,29z"></path></svg>
	<?php if ( $my_jetpack_available ) : ?>
	</a>
	<?php else : ?>
	</span>
	<?php endif; ?>

<a>/<span> is opened in one block and closed two blocks later, so nothing can pair the tags and a future edit to the logo has to be mirrored in both halves. Hoisting the markup once and branching on whole elements reads better and drops the duplicated esc_url( admin_url( … ) ) at L304:

$my_jetpack_url = admin_url( 'admin.php?page=my-jetpack#/overview' );
$jetpack_logo   = '<svg xmlns="…" role="img" aria-label="…">…</svg>';

<?php if ( $my_jetpack_available ) : ?>
	<a class="jp-masthead__logo-link" href="<?php echo esc_url( $my_jetpack_url ); ?>"><?php echo $jetpack_logo; // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped ?></a>
<?php else : ?>
	<span class="jp-masthead__logo-link"><?php echo $jetpack_logo; // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped ?></span>
<?php endif; ?>

2. [suggestion] Give the logo <svg> a role="img"

jetpack/projects/plugins/jetpack/_inc/lib/admin-pages/class.jetpack-admin-page.php

Line 282 in b444cd9

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" height="20" aria-label="<?php esc_attr_e( 'Jetpack logo', 'jetpack' ); ?>"><path fill="#069e08" d="M16,0C7.2,0,0,7.2,0,16s7.2,16,16,16s16-7.2,16-16S24.8,0,16,0z M15,19H7l8-16V19z M17,29V13h8L17,29z"></path></svg>

aria-label on an <svg> with no role is inconsistently exposed by assistive tech. Previously the anchor carried the interactive semantics, so the label had a fallback path; as a bare <span> child it is the only accessible name left.

(Minor, related: .jp-masthead__logo-link:focus now also applies to a non-focusable <span> in the unavailable case — dead but harmless.)

3. [suggestion] // "Jetpack" is a product name, do not translate. now appears three times in this file

jetpack/projects/plugins/jetpack/_inc/lib/admin-pages/class.jetpack-admin-page.php

Lines 304 to 315 in b444cd9

	<a class="jp-masthead__title-link" href="<?php echo esc_url( admin_url( 'admin.php?page=my-jetpack#/overview' ) ); ?>">Jetpack</a><?php // "Jetpack" is a product name, do not translate. ?>
	<?php else : ?>
	Jetpack<?php // "Jetpack" is a product name, do not translate. ?>
	<?php endif; ?>
	<span class="jp-masthead__title-separator" aria-hidden="true">/</span>
	<?php if ( $is_offline_mode ) : ?>
	<span class="jp-masthead__title-offline"><?php esc_html_e( 'Offline Mode', 'jetpack' ); ?></span>
	<span class="jp-masthead__title-separator" aria-hidden="true">/</span>
	<?php endif; ?>
	<span class="jp-masthead__title-current"><?php echo esc_html( $current_label ); ?></span>
	<?php else : ?>
	Jetpack<?php // "Jetpack" is a product name, do not translate. ?>

The PR adds the third. The <h2 class="jp-masthead__title"> block owns the fact — state it once above the if ( $current_label ) and drop all three inline copies.

Backward compatibility

4. [suggestion] The method_exists() guard falls through to false rather than to the previous behavior

jetpack/projects/plugins/boost/app/admin/class-config.php

Lines 141 to 144 in b444cd9

	public static function is_my_jetpack_available() {
	return method_exists( My_Jetpack_Initializer::class, 'is_admin_page_available' )
	&& My_Jetpack_Initializer::is_admin_page_available();
	}

When the loaded copy of jetpack-my-jetpack predates is_admin_page_available(), returning false hides every My Jetpack link and the upgrade/license CTAs (canOfferUpgrade() in _inc/overview/lib/use-modules-state.ts, LicenseKeyLink, BoostAdminPage's license action) — a strictly worse outcome than the behavior it replaces.

AGENTS.md § Package and API Reuse asks for a method_exists() guard and a backward-compatible fallback, and the sibling Footer_Links::get_my_jetpack_products_section() does exactly that. Two lines:

if ( method_exists( My_Jetpack_Initializer::class, 'is_admin_page_available' ) ) {
	return My_Jetpack_Initializer::is_admin_page_available();
}
return class_exists( My_Jetpack_Initializer::class ) && did_action( 'my_jetpack_init' ) > 0;

Calibration: jetpack-autoloader loads the highest bundled version and Boost ships its own copy of the package, so in practice the guard should always be true once this lands. Treat it as convention-alignment rather than a live risk — though the failure mode is silent, which is the argument for the fallback.

Tests

5. [suggestion] The $_GET snapshot and try/finally protect nothing

jetpack/projects/plugins/jetpack/tests/php/_inc/lib/Akismet_Admin_Chrome_Test.php

Lines 218 to 237 in b444cd9

	$original_get = $_GET;
	$_GET['page'] = 'jetpack_modules';
	try {
	$render_masthead = function () {
	$markup = $this->render(
	static function () {
	Jetpack_Admin_Page::wrap_ui( '__return_empty_string' );
	}
	);
	return substr( $markup, 0, strpos( $markup, '</header>' ) );
	};
	$this->assertSame( 2, substr_count( $render_masthead(), 'page=my-jetpack#/overview' ) );
	unset( $_registered_pages[ get_plugin_page_hookname( 'my-jetpack', 'jetpack' ) ] );
	$masthead = $render_masthead();
	$this->assertStringNotContainsString( 'page=my-jetpack', $masthead );
	$this->assertStringContainsString( '<svg', $masthead );
	$this->assertMatchesRegularExpression( '/<h2 class="jp-masthead__title">\s*Jetpack\s*<span/', $masthead );
	} finally {
	$_GET = $original_get;

WP_UnitTestCase_Base::set_up() calls clean_up_global_scope(), which does $_GET = array();, so the next test never sees a dirty $_GET. Dropping $original_get, the try and the finally also removes a level of indentation from the whole test body.

6. [suggestion] assertSame( 2, … ) doesn't say what the 2 is, and nothing asserts the wrapper element survives

jetpack/projects/plugins/jetpack/tests/php/_inc/lib/Akismet_Admin_Chrome_Test.php

Lines 230 to 234 in b444cd9

	$this->assertSame( 2, substr_count( $render_masthead(), 'page=my-jetpack#/overview' ) );
	unset( $_registered_pages[ get_plugin_page_hookname( 'my-jetpack', 'jetpack' ) ] );
	$masthead = $render_masthead();
	$this->assertStringNotContainsString( 'page=my-jetpack', $masthead );
	$this->assertStringContainsString( '<svg', $masthead );

The 2 is logo + title; worth naming in a message. More usefully, assertStringContainsString( '<svg', $masthead ) still passes if the <span> wrapper were dropped entirely and the SVG left loose — which is exactly what "Keep the masthead logo slot sized when the My Jetpack link is dropped" had to fix, so it's the regression most worth pinning:

$this->assertStringContainsString( 'class="jp-masthead__logo-link"', $masthead );

in both the available and unavailable states.

Otherwise the tests are well-targeted: the Boost test exercises the real Initializer (not a mock) through Brain Monkey shims, and the Jetpack test correctly sets $_GET['page'] so $current_label is non-empty and the title link actually renders.

---

What I verified

Check	Result
PHPCS, all four changed PHP files	pass (run locally)
jp test php plugins/boost	pass (run locally, worktree at this head)
jp docker phpunit jetpack	not run locally — needs a full jp build plugins/jetpack; CI's PHP 7.4 → 8.5 matrix covers Akismet_Admin_Chrome_Test and passes
Phan	not run locally; CI Static analysis passes
CI overall	80 pass, 18 skipped, 0 failing

Other checks all clear: changelogs (both plugins touched directly, both entries valid and correctly typed — no package changed, so the indirect-plugin rule doesn't apply); no public API removed or resignatured; no new cross-package FQN references and automattic/jetpack-my-jetpack is a declared require in Boost's composer.json; no Phan suppressions or baseline growth; no new dependencies; PHP 7.4-compatible throughout; comment-rot.awk and comment-budget.awk both returned zero candidates (finding 3 is a trailing comment on an HTML line, which those scripts skip); no CSS changed, so no RTL surface; no tracking or data collection introduced.

Security-wise the tightened check is strictly more restrictive, and add_submenu_page() already returns early without touching $_registered_pages when the user lacks the page capability — so the registered-page test is itself capability-aware.

Two non-code notes: the no-mistakes-pipeline-attestation comment in the description pins head_sha 890ded46, so its review/test "completed" steps refer to an older tree; and the PR still carries [Status] Needs Author Reply + [Status] In Progress rather than [Status] Needs Review and a type label.

[LiamSarsfield]

Thanks @xavier-lc . I applied all six in 103c950:

1. The masthead now builds $my_jetpack_url and $jetpack_logo once and branches on a whole <a> or <span>. The duplicated esc_url( admin_url( … ) ) is gone.
2. Added role="img" to the logo <svg>.
3. The "Jetpack is a product name, do not translate" note now appears once, above the title block. I removed the three inline copies.
4. Config::is_my_jetpack_available() now falls back to class_exists( My_Jetpack_Initializer::class ) && did_action( 'my_jetpack_init' ) > 0 when is_admin_page_available() does not exist.
5. Removed the $_GET snapshot and the try/finally from Akismet_Admin_Chrome_Test.
6. The assertSame( 2, … ) now has a message saying the 2 is the logo and title links. The test also checks that class="jp-masthead__logo-link" is present when My Jetpack is available and when it is not.

I also set the labels to [Status] Needs Review and [Type] Bug, and removed the stale pipeline attestation from the description.

[Copilot]

Copilot review overview

🟡 Changes recommended

The critical WordPress.com Simple compatibility issue and moderate test-state cleanup remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Avoid resolving Footer_Links on WordPress.com Simple · New
• Restore $_GET['page'] after the test · New

What changed in this PR

This PR hides unavailable My Jetpack links in Boost and Jetpack while preserving branding and supporting older package versions.

Changes:

• Adds availability-aware Boost configuration and tests.
• Gates Jetpack masthead and footer links.
• Adds Boost and Jetpack changelog entries.

File	Summary	Review notes
projects/​plugins/​jetpack/​tests/​php/​_inc/​lib/​Akismet_Admin_Chrome_Test.php	Tests unavailable masthead behavior.	Moderate: restore $_GET['page'] after the test (3 votes).
projects/​plugins/​jetpack/​changelog/​masthead-my-jetpack-availability	Documents the Jetpack fix.	No final comments.
projects/​plugins/​jetpack/​_inc/​lib/​admin-pages/​class.jetpack-admin-page.php	Gates masthead and footer links.	Critical: guard Footer_Links availability on WordPress.com Simple (1 vote).
projects/​plugins/​boost/​tests/​php/​admin/​Config_Test.php	Tests registered-page availability.	No final comments.
projects/​plugins/​boost/​changelog/​boost-my-jetpack-availability	Documents the Boost fix.	Nit: use the adjacent component prefix and clearer user-visible wording (1 vote).
projects/​plugins/​boost/​app/​admin/​class-config.php	Adds compatibility-aware availability checks.	No final comments.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xavier-lc]

I don't think this holds, on two counts.

The cited docblock says the opposite. src/class-footer-links.php:15-16 reads:

Autoloaded from src/ rather than shared through Jetpack_Admin_Page: WordPress.com Simple declares its own stub of that class, so loading ours there fatals.

"That class" is Jetpack_Admin_Page, the immediately preceding noun — not Footer_Links. The docblock exists to explain why Footer_Links was extracted into src/ in the first place: so it can be resolved without pulling in Jetpack_Admin_Page. There is no wpcom stub of Footer_Links.

Jetpack_Admin_Page is already loaded by the time this line runs. The statement is inside Jetpack_Admin_Page::wrap_ui(), so it cannot be what loads the colliding class — every route into it needs the class resolved first:

• _inc/lib/admin-pages/class.jetpack-admin-page.php:124 (self::wrap_ui())
• _inc/lib/admin-pages/class-jetpack-about-page.php:88
• class.jetpack-admin.php:570
• modules/stats.php:373
• projects/packages/publicize/src/class-publicize-ui.php:88

On the partial-bootstrap concern specifically: AGENTS.md asks that code reachable that way not depend on non-autoloaded dependencies. Footer_Links is classmap-autoloaded ("autoload": { "classmap": ["src"] } in the plugin's composer.json), which is exactly that shape.

The ! is_wpcom_platform() check on the footer is a product decision about which links wpcom shows, not a load guard — and it stays where it is.

[xavier-lc]

$_GET can't leak between tests here — WordPress's own test case resets it before every test, so the save/restore was dead weight (which is why it was removed).

The chain, end to end:

• WP_UnitTestCase_Base::set_up() calls clean_up_global_scope() unconditionally — tests/phpunit/includes/abstract-testcase.php:123
• clean_up_global_scope() does $_GET = array(); — same file, :241-246
• abstract class WP_UnitTestCase extends WP_UnitTestCase_Base {} — empty body, no override
• Automattic\Jetpack\PHPUnit\WP_UnitTestCase_Fix defines only getAnnotations(), getGroups() and checkRequirements(); it doesn't touch set_up()

So a later wrap_ui() test starts with an empty $_GET regardless of what this one leaves behind, and can't render the Modules title unexpectedly.

Verified by running the class against this tree: jp docker phpunit jetpack -- --filter=Akismet_Admin_Chrome_Test → OK (9 tests, 32 assertions).