Overview

In #3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row we added support for collapsed inputs where the input matched the default static prop expression.
We didn't prohibit the use of uncollapsed inputs in content exports, test data etc because that would have added a lot more changes to the merge request.
We've seen the loose support cause issues on sites with exported values.

Proposed resolution

Don't allow uncollapsed inputs when using the default expression/static prop source

User interface 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

larowlan created an issue. See original summary.

wim leers’s picture

Thanks for opening this issue! @mglaman and I discovered this while debugging why content exported using https://drupal.org/project/default_content but then updated manually over time didn't behave as expected. This turns out to have been the reason.

wim leers credited mglaman.

wim leers’s picture

Assigned: Unassigned » larowlan
Priority: Normal » Major

The sibling of this issue is simpler: #3538503: Disallow component trees with `component_version: active` — already fixed 👍

That sibling issue does not require any changes because it would've taken component_version: active as the input and then "upcasted" it to the actual active component version. IOW: it didn't make it into any component tree stored in the DB (content component trees for XB fields) nor in config (config component trees in XB config entities).

This one, however, does require existing component trees to be updated. Which means this will require the very first update path that spans both content and config entities 🤓

Given that that requires expertise with writing update paths, and @larowlan just worked on the very first config update path in #3533458: Change CodeComponentDataProvider::getRequiredXbDataLibraries() to base its logic on information provided by the front-end rather than on naive string/regex matching, assigning to him, and bumping to Major.

larowlan’s picture

I'm curious as to why this requires a content update path.

\Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem::preSave calls \Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem::optimizeInputs which calls \Drupal\experience_builder\ComponentSource\ComponentSourceInterface::optimizeExplicitInput which calls \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\GeneratedFieldExplicitInputUxComponentSourceBase::collapse

That code has existed since #3529622: Make auto-save manager only support passing and returning entity objects, remove support for arbitrary data, use deterministic hashing to ensure entries are actually updates which was before a beta release.

I don't think we need to provide an update path for any sites older than that because there's been other API breaking changes since then.

I agree we do need to support an update path for component trees stored in config (pattern, content template, default values).

I'm not sure there's any way we can provide an update path for default content. Perhaps we can detect that during an event in the default content import stages and just trigger a deprecation.

larowlan’s picture

Made some progress on this today

Update path is done for config, see #6 for why I don't think we need this for content.

Remaining phpunit failures are tricky

1) The magic 'uuid is cast to a target id' on default content import with media references
2) \Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\ComponentInputsEvolutionTest::testStorablePropShapeChanges which is showing that parsing from client model for the non-active version isn't collapsing properly. Will need to dig into that.

larowlan’s picture

Priority: Major » Critical

This is critical because it unearthed a possible data-loss/corruption bug in ClientServerConversionTrait

larowlan’s picture

Assigned: larowlan » Unassigned
Status: Active » Needs review

This is green now

larowlan’s picture

Expanded the change record

penyaskito’s picture

Status: Needs review » Reviewed & tested by the community

LGTM, added comments to MR.

penyaskito’s picture

Assigned: Unassigned » larowlan
Status: Reviewed & tested by the community » Needs work

I guess we want to revert 9ee987bf and rebase with HEAD for phpstan.

wim leers’s picture

Status: Needs work » Reviewed & tested by the community
Related issues: +#3538537: Update path tests should also run against non-SQLite DBs

#6++
#9++

This again touching the update path test DB fixtures increases the importance of #3538537: Update path tests should also run against non-SQLite DBs.

LGTM — just a few questions and minor remarks! 😊

larowlan’s picture

Assigned: larowlan » Unassigned

Addressed the minor remarks/questions

  • wim leers committed 66e9e1be on 1.x authored by larowlan
    Issue #3538487 by larowlan, wim leers, penyaskito, mglaman: Don't allow...
wim leers’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, and turns out my sole "real" question was moot, I misread! 🙈

wim leers’s picture

This unblocked #3538537: Update path tests should also run against non-SQLite DBs — MR rolled there, and landed! 🥳

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.