#Configuration schema

We need to update the deprecations to 11.3.x plus I think the hook this MR adds does not have the correct info the annotation.

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.