Build/mirror test: #48627 (newsletter mu-wpcom)#48655
Build/mirror test: #48627 (newsletter mu-wpcom)#48655
Conversation
mu-wpcom-plugin previously vendored the entire automattic/jetpack-newsletter package because jetpack-mu-wpcom required it via composer to call Settings::init() / Reader_Link::init() and to resolve Settings, Reader_Link, and Urls class names from wpcom-admin-menu, wpcom-admin-bar, and launchpad-task-definitions. On Atomic sites that run both the standalone Jetpack plugin and mu-wpcom-plugin, the entire ~8.7 MiB build/ payload of jetpack-newsletter shipped twice. Drop the composer require and rely on the Newsletter package being provided by a sibling plugin's Jetpack autoloader: the standalone Jetpack plugin on Atomic, or the wpcom platform's bundled Jetpack source on Simple. Every call site that touches a Newsletter class is now class_exists()-guarded so mu-wpcom degrades gracefully when no sibling provides the package. The Settings::init() call in class-jetpack-mu-wpcom.php is preserved (still needed on Simple where load-jetpack.php does not run); only the dependency plumbing changed. Phan can no longer see the Newsletter classes from mu-wpcom's analysis context (the dep is gone), so each call site uses an FQ string in the class_exists guard and a @phan-suppress-next-line annotation on the actual method/constructor call, matching the existing pattern used elsewhere in mu-wpcom (wpcom-themes/wpcom-theme-tracking.php, custom-css/custom-css.php). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
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 🤖 🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so: Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Mu Wpcom plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Wpcomsh plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 4 files.
If appropriate, add one of these labels to override the failing coverage check:
Covered by non-unit tests
|
Build/mirror test for #48627 — that PR is currently in Draft state, so the "Push to mirror repos" job is skipped and the
try/newsletter-bootstrap-via-modulebranch is missing on theAutomattic/jetpack-mu-wpcom-pluginandAutomattic/wpcomshmirror repos. That makes it impossible to spin up a Jurassic Ninja site withbranches.jetpack-mu-wpcom-plugin=...&branches.wpcomsh=...against the original PR's branch.This PR is identical in content to #48627 (rebased on current trunk) and is not draft, so the mirror push runs and the matching branch lands on each mirror repo.
Do not merge. This is a build-only test branch — it will be closed once #48627 is marked ready for review (or merged) and the original branch's mirrors are populated.
Testing
JN spawn URL once the mirror branches are live:
Does this pull request change what data or activity we track or use?
No.