#Configuration schema

Thanks, @meghasharma, for getting this going! :)

Given @larowlan's #9, I figured I'd just get this done 😇

🤔 I think it can still be wrong.

Because \Drupal\experience_builder\ComponentSource\ComponentSourceBase::generateVersionHash() looks at

    $normalized_data = [
      'settings' => $typed_source_specific_settings->toArray(),
      'slot_definitions' => $this instanceof ComponentSourceWithSlotsInterface
        ? self::normalizeSlotDefinitions($this->getSlotDefinitions())
        : [],
      'schema' => $this->getExplicitInputDefinitions(),
    ];

There's nothing preventing $typed_source_specific_settings to contain too much data — that'd just end up being hashed along with it; still resulting in a predictable version … just one based on mismatched settings.

In fact, \Drupal\Tests\experience_builder\Kernel\Config\ComponentValidationTest::setUp() proves that this is still the case.

I think is probably moot post 🐛 Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema Active as the validation won't pass because the version doesn't match?

Per @larowlan at 📌 [SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees Active , this MR blocks that one.

Updated /admin/appearance/component to show the number of versions of each component, and shows the active version upon hover.

Thanks, @larowlan, for pushing this to completion! All I had to do here was fix nits, and add docs for the tricky bits 😊

Issue summary updated.

This should be ready for review 🤞

This is passing now

🏗️ picking this up

Picking up where Wim left off.

@larowlan mentioned he wasn't happy with one area. I investigated and implemented a counterproposal.

AFAICT this also blocks #3519878 now, see #3519878-22: [PP-1] ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities → . IOW: I think/hope that once this is fixed, the remaining test failures there will disappear.

The test coverage here is definitely sufficient, so removing tag.

P.S.: This removed a few @todos pointing to 🐛 SdcPropKeysConstraintValidator::validate() should complain about extraneous keys too, not just missing keys Active , because those bits were getting in the way of getting this MR to pass. This is critical for data model stability, so this takes precedence.

Root cause: #1989468-4: Weird messing with 'default_value_function' in date widgets ? → .

Thanks! Will review 😊

Got something going that uses the schema, but I'm not 100% happy with it.
I think its probably ok, but there's a chicken-egg scenario with creating a version string vs having a component typed data adapter that prevents using being able to use \Drupal\Core\Config\Schema\TypeResolver::resolveDynamicTypeName

The workaround seems ok, but is not ideal.

Squashed and rebased this branch since it wasn't rebasing cleanly.

🥳

BTW, 📌 Constraint slot names allowed by XB in its component tree Active added a todo pointing here — this MR should be able to drop those lines.

Re #12 that makes sense.
I think we can include the 'current schema' in the hash calculation and that gives us item 3 from the issue summary

Will pick that up today

#6: gave this some more thought.

You’re right that it’s impossible to validate old versions (any besides the active one) if they depend on data not contained within the config entity.

So … I think the solution is actually very simple, plus it would prevent brittleness in the future: only validate active_version!

That way, even if a ComponentSource plugin changes what information is used to deterministically compute the hash, old versions (hashes) continue to work fine. Because in the proposal I made in the issue summary, any such logic change would have caused all old versions (hashes) to become invalid 🙈

And that is actually perfectly in line with the source-specific settings for old (non-active) versions: those already use type: ignore because the config schema for older versions might have been different. What we’re dealing with here is similar.

Didn't get to reviewing this today :/