Widgets: carry declarative attributes through the widget pipeline - #82485
Widgets: carry declarative attributes through the widget pipeline#82485retrofox wants to merge 3 commits into
attributes through the widget pipeline#82485Conversation
|
Important Review skippedAuto reviews are disabled on this repository. To trigger a review, include ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
004194e to
619e3c5
Compare
🤖 PR meta 🤖📦 Bundle sizeSize Change: +82 B (0%) Total Size: 8 MB 📦 View Changed
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
|
What
Moves a widget's attribute schema into
widget.jsonand carries it through the build manifest, the PHP registry, and/wp/v2/widget-modules, whereuseWidgetTypesmerges it with the module's entries byid. The three core widgets that declared attributes (activity,events,hello-world) now do so in JSON.Closes #82483. Part of #77629.
Why
Attributes were the only part of the declaration that never left
widget.ts: the server could not see them, a widget without a JS module could not declare any, and field labels bypassedtextdomain. Since the field type registry (#80148) the declarations are plain data, so the split had no reason left.How
packages/wp-build/lib/build.mjs,widget-utils.mjscollectWidgetsreadsattributesfromwidget.jsonandgenerateWidgetRegistrywrites it intobuild/widgets/registry.phpthrough a generic JSON-to-PHP literal helper. Entries without a stringiddrop at build time; the shape is constrained at registration.lib/experimental/dashboard-widgets/widget-types.php,widget-i18n.json,class-wp-widget-type.phpgutenberg_sanitize_widget_attributes()keeps the JSON-expressibleFieldkeys, requires a unique stringid, and stripsisValid.custom.label,description,placeholderand option labels translate through the i18n schema like action labels.lib/experimental/dashboard-widgets/class-wp-rest-widget-modules-controller.phpExposes
attributesin the response and the item schema, withtypeas an open string andrelevanceas an enum.packages/widget-primitives/src/types.ts,hooks/use-widget-types.tsWidgetAttributeRecordis the wire form of an attribute and joinsWidgetModuleRecord. The hook resolves record attributes on both paths: a record without a module gets its schema for the first time, and a record with a module merges byid, the record winning a shared key and module-only entries appended.widgets/activity,widgets/events,widgets/hello-worldThe declarations move to
widget.json.activityandeventsdropwidget.ts;hello-worldkeeps it forexample.Docs
The architecture document, the two package READMEs and the field types story describe the new home and the merge rule.
Testing
Open the dashboard, add the WordPress events widget and confirm the location control renders in the tile header. Add Activity and open its settings to see "Items per page".
Confirm the REST record carries the schema:
Follow-ups
attributesinschemas/json/widget.jsononce Widgets: Addwidget.jsonmetadata schema #77640 lands, derived from the DataViewsFieldtype@wordpress/widget-primitivesinpackage.json; dropping it needs a lockfile update