Problem/Motivation

Custom Field on a paragraph is silently failing to save one of its viewsfield subfields, after upgrade to 5.02 release start to experiment some issue in save display option.
Selecting view_id and display and saving the node succeeds with no errors, but the display value is not persisted — it reverts to empty/default. This field was working correctly and stopped without any code or obvious config change that we've identified.

Environment:
- Drupal core: 11.4.5
- custom_field 5.02

Steps to reproduce

1. Edit a node containing a paragraph with Custom Field.
2. Select a View in the view-reference subfield.
3. Select a value in the "presentation" subfield (the required display selector).
4. Save the node.
5. Reopen the node/paragraph and observe that the presentation value is empty, even though the view reference saved correctly.

Expected behavior
Both subfield values should persist after save.

Actual behavior
Only the view-reference subfield persists; the presentation subfield is silently reset/empty, even though the field is configured as required and no validation error is shown. No errors in the browser console or in Recent log messages during or after save.

Proposed resolution

  • CustomItem::setValue() now completes the values array generically from whatever each subfield type declares, before handing it to core, and accepts only property names the type actually declares. It no longer knows about any individual type. Plugin classes and their extra property names are resolved once per field definition and held in a WeakMap keyed on the definition object; that narrows the staleness window rather than closing it, but a stale map can only offer extras the name filter then discards, never a wrong stored value.
  • The overlapping paragraph tests are consolidated into one Functional and one FunctionalJavascript ParagraphsIntegrationTest sharing a single setup trait, replacing five test files and the custom_field_paragraphs_test module. Together they cover the extra properties of every sibling-writing subfield type through a real paragraph form, including the media library modal and the viewfield AJAX display options.
  • Setting a field item more than once from code with nested values still loses extra properties for the other sibling-writing types. That behaviour is not new here and is tracked in #3622588: Extra properties lost when a field item is set more than once with nested values.

Remaining tasks

User interface changes

API changes

  • CustomFieldTypeInterface gains two static methods, alongside the existing static schema() and propertyDefinitions(): getExtraPropertyNames() returns the full names of a subfield's extra properties, and extractExtraPropertyValues() maps a nested value onto them. CustomFieldTypeBase derives the names from schema() and returns nothing from the extraction, so existing type plugins need no changes; ViewfieldType is the only type that overrides the extraction
  • The CustomFieldViewfield data type moves from Drupal\custom_field\Plugin\DataType to Drupal\custom_field_viewfield\Plugin\DataType, so the parent module no longer carries a type that belongs to the submodule. The plugin ID is unchanged, so stored data and property definitions are unaffected. Its setValue() resolves the type plugin through the plugin definition, so the two write paths share one implementation.

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

jowjow created an issue. See original summary.

jowjow’s picture

Assigned: jowjow » Unassigned
apmsooner’s picture

I'm able to reproduce this bug. I'll find a fix for it and provide a patch soon that should resolve. Thanks for reporting this issue.

apmsooner’s picture

Issue summary: View changes
apmsooner’s picture

Version: 5.0.2 » 5.0.x-dev
Status: Active » Needs review

This is fixed and ready to test the 5.x patch. Once confirmed and merged it will be backported to the 4.x branch. Gitlab pipelines aren't showing up in the tickets right now but it passes: https://git.drupalcode.org/project/custom_field/-/pipelines/957891 which is important because extra test coverage was provided to validate the fix.