Implement automatic fallback to server-side widget value transforms in "page data" (content entity form)

Open on Drupal.org →

Created on 21 March 2025, 13 days ago

Overview

Quoting @effulgentsia from #3506467-38: Make Media Library widget work from "page data" (content entity form) → :

If a contrib/custom widget doesn't include one (or opt into using the no-op one), the system should fall back to a server request that uses Form API + Widget API to go from widget input to field value and then the prop expression to go from field value to prop value. In this way, Drupal's existing ecosystem of widgets continue to work, and ones that include client-side transforms (or can use the no-op one) just work faster (without a network request once we implement 📌 Implement endpoint for realtime preview Active ).

For context:

Client-side transforms: 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active
Server-side massaging: 📌 Support server side massage and validation of component prop form values Active
Field Widgets that are not yet supported because no client-side transforms exist yet: \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldWidgetSupportTest, introduced in 📌 Provide visibility into which (core) field type props can be mapped into Content Type Templates vs not Active

Proposed resolution

Implement this fallback mechanism.
Prove that this results in a working Field Widget for a test-only Field Widget using an end-to-end test.
Ideally this would actually prove that of the Field Widgets for which no client-side transforms have been defined yet actually do automatically work thanks to this new infrastructure. Per #3512433-6: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported → , that list is currently (March 21, 2025):
comment_default, daterange_datelist, daterange_default, datetime_datelist, datetime_timestamp, entity_reference_autocomplete, entity_reference_autocomplete_tags, file_generic, language_select, moderation_state_default, oembed_textfield, options_buttons, path, telephone_default, text_textarea, text_textarea_with_summary, text_textfield, uri

User interface changes

None.

📌 Task

Status

Active

Version

0.0

Component

Redux-integrated field widgets

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

Live updates comments and jobs are added and updated live.

stable blocker

Contributed project blocker
It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

e2e

Sign in to follow issues

Comments & Activities

Issue created by @wim leers
Comment 10 days ago →
🇺🇸United States effulgentsia
Even though my quote referenced in the issue summary was in the issue about the "page data" form, it was actually a statement about the component inputs form and just used as a point of comparison. So, re-titling this issue accordingly.

Currently, there is no client-side transformation that runs when widget inputs are updated on the page data form, so this issue isn't applicable there, though it's possible that at some point we'll want to open a separate issue to add client-side transformations on the page data form. I don't think there's currently a use-case for that though, since the fields on the page data form are intentionally the ones that (for the most part) don't have any representation in or impact on the preview (with the exception of potentially changing the content of Blocks, such as the page title block).
Comment 7 days ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
I don't think there's currently a use-case for that though, since the fields on the page data form are intentionally the ones that (for the most part) don't have any representation in or impact on the preview (with the exception of potentially changing the content rendered in Blocks, such as the page title block).

That will completely change with 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active !

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024