Premium Analytics: carry widget.json metadata through the registry and REST

[retrofox]

Fixes #

Proposed changes

This ports the upstream lib/experimental/dashboard-widgets delta that pairs with the @wordpress/widget-primitives / @wordpress/widget-dashboard 0.3.x line (already bundled since #50293) into our PA-namespaced copy of the backend.

The wp-build manifest already emits the declarative widget.json metadata; this PR makes the PHP pipeline carry it end-to-end.

• Widget_Type
  Gains the five declarative metadata fields: category, title, description, help, keywords (all null when a widget does not declare them).

• Registry hydration translates the user-facing strings on the way in,...
  ...using the new src/widget-i18n.json schema and core's translate_settings_using_i18n_schema().

One deliberate divergence from upstream: a widget with no textdomain falls back to the jetpack-premium-analytics domain instead of skipping translation, since every bundled widget shares it.

This matters because the client overlay prefers the server value (record.title ?? metadata.title), so an untranslated server string would otherwise beat the widget module's translated __() title.

• The help note is sanitized at registration
  Content keeps only em/strong markup, and links missing a label or href are dropped.

• The jetpack/v4/widget-modules REST record now exposes the five fields.
  null values are safe: useWidgetTypes() falls back to the widget module's metadata.

• New Widget_Metadata_Test covers the translation domains (default and widget-declared), the help sanitization rules, and the REST record end to end.

Side effect worth noting: registry-time availability filter candidates now carry category, which was the missing prerequisite for server-side category-based gating discussed around #50002 / #50031.

Related product discussion/links

• Premium Analytics: update widget packages and promote in-body controls to widget attributes #50293 bundled the 0.3.x widget packages and the wp-build version whose manifest emits these fields.
• Upstream reference: Gutenberg lib/experimental/dashboard-widgets as of the canary the bundled packages were cut from.

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

No.

Testing instructions

• Check out the branch and build the package: jetpack build --deps packages/premium-analytics.
• Confirm the generated manifest carries the metadata: entries in projects/packages/premium-analytics/build/widgets/registry.php include category, title, description (and help / keywords as null for now).
• On a connected test site, request /wp-json/jetpack/v4/widget-modules as an admin: each record should now include category, title, description, help, keywords in addition to the existing name / render_module / widget_module / presentation.

Before

After

• Load the Premium Analytics dashboard and open the widget inserter: widgets keep their titles and descriptions (now server-fed through the record overlay), and everything renders as before.
• Run the package test suite: composer phpunit in projects/packages/premium-analytics (335 tests, includes the new Widget_Metadata_Test).

[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

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/premium-analytics/src/widget-modules.php	28/52 (53.85%)	7.04%	-1 💚
projects/packages/premium-analytics/src/widget-types.php	57/64 (89.06%)	62.98%	-10 💚

Full summary · PHP report · JS report

[chihsuan]

Nice work. this matches the upstream dashboard widget metadata pipeline, with a reasonable PA-specific text-domain fallback.

The only remaining items are the two failing CI checks. Once those are fixed, this looks good to merge.

[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 (WordPress.com Site Helper), and enable the update/pa-widget-metadata-pipeline branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/pa-widget-metadata-pipeline

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