Overview

Reported by @tedbow at #3502902: Only auto-save content entities/PageRegion config entities when there are actual changes: simply previewing incorrectly causes them to appear in "Review x changes".

ok. found 1 problem in manual testing

If only change the branding block settings in header and then change back you still have an auto-saved state which results in "review 1 changes" where it should be none.a

— @tedbow at https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...

Only local images are allowed.
— https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...

Proposed resolution

See \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::fixBooleansUsingConfigSchema() and \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::clientModelToInput().

User interface changes

Comments

wim leers created an issue. See original summary.

wim leers credited larowlan.

wim leers credited tedbow.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Parent issue: » #3520484: [META] Production-ready ComponentSource plugins
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue tags: +stable blocker
lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Issue tags: -stable blocker +stable target
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Doesn't this become obsolete thanks to #3523496: Block component instance form values not processed by validation/submit handlers? 🤔

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3500795: [PP-1] Implement client-side validation of block settings

Related: #3500795: [PP-1] Implement client-side validation of block settings, because that's what fixBooleansUsingConfigSchema() points to as the issue where that method will be removed.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Closed (outdated)
Related issues: +#3523496: Block component instance form values not processed by validation/submit handlers

Manually tested this again on #3523496, and I can confirm that this is fixed there! 🥳

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Showing this working, lifting the GIF from #3523496-34: Block component instance form values not processed by validation/submit handlers:

mayur-sose’s picture

mayur-sose commented

Verified the changes :

ID Test Scenario Steps Expected Result Pass/Fail
TC1 Changing branding block setting triggers auto-save
  1. Open the Experience Builder and go to a page with a header block containing branding settings.
  2. Change a branding block setting (e.g., toggle a boolean setting ON/OFF).
 UI shows "Review 1 changes" indicating an auto-save was triggered by your modification. Pass
TC2 Reverting branding block setting removes pending auto-save state
  1. After TC1, change the branding block setting back to its original value (as it was before your first edit).
 UI returns to "No changes" state; "Review 1 changes" text in the UI disappears.
No auto-save is retained.		 Pass
TC3 Changing branding block ON and back OFF does not result in type bug
  1. Toggle a boolean setting from its original value (e.g., "false"→"true"), then back.
  2. Observe the state and auto-save.
 No auto-saved state remains; "Review 1 changes" is not shown since values match the saved state. Pass
TC4 No string-to-bool type mismatch in stored values
  1. Perform TC1 and TC2.
  2. Inspect auto-saved payload (network or DB) after reverting setting.
  3. Confirm data type in payload.
 No unwanted type conversion (e.g., "true" (string) vs true (boolean)) leads to a false-positive pending change. Pass
TC5 Editing other fields works with correct auto-save behavior
  1. Edit a field OTHER than block settings, save, and revert back.
  2. Observe auto-save state/UI feedback.
 "Review 1 changes" only appears with real pending changes; disappears when all values match the saved state. Pass