Don't allow passing uncollapsed inputs if using default expression

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 → .

The sibling of this issue is simpler: 📌 Disallow component trees with `component_version: active` 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 📌 Improve the way to detect if the code component has drupalSettings Active , assigning to him, and bumping to .

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 🐛 Page status changes from "Published" to "Changed" even when no actual changes are made Active 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.

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.