Overview
Discovered while reviewing #3460230: Component entity config dependencies are incomplete: missing ComponentSourceInterface::calculateSettingsDependencies() to compute deps for field storage + instance settings + widget.
SdcPropKeysConstraintValidator::validate() should trigger a validation error when there's keys present in the given type: sequence that do not exist on the SDC. It currently does not:

Proposed resolution
- ✅
Fix the validator - ✅
Add tests - 🆗
Update→ #3503087: Disallow SDCs with `type: string, enum: …` with an empty string listed to convey optionality: the prop should then just be optional already did this!ComponentValidationTest: it has 2@todos pointing here. Recommendation: introduce a newxb_test_sdc:hero-with-ctatest SDC. That'd then also allow removing the dependency on core'ssdc_testmodule.
User interface changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2025-05-21 at 12.25.35 PM.png | 433.31 KB | wim leers |
Issue fork experience_builder-3525759
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
Comment #2
wim leersNone of the code in
0.xcan generate this, it had to be manually constructed by @tedbow in a test.Therefore, even sites created on
beta1should never run into this. Even if that's the case, the update path would be trivial 👍Comment #3
wim leersComment #4
wim leersI think this is a great issue to start contributing to XB :)
Comment #5
meghasharma commentedComment #7
meghasharma commentedI updated the SdcPropKeysConstraintValidator::validate() method to check for extra keys in the input mapping that are not defined in the SDC props.
To support this, I added a new extraMessage property to the SdcPropKeysConstraint class for the error message.
Comment #8
wim leersLooking good! That’s step 1 done 😄
Steps 2 and 3 are in the issue summary, do you think you could handle those too? 🙏
Comment #9
larowlanI think is probably moot post #3528362: Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema as the validation won't pass because the version doesn't match?
Comment #10
wim leers🤔 I think it can still be wrong.
Because
\Drupal\experience_builder\ComponentSource\ComponentSourceBase::generateVersionHash()looks atThere's nothing preventing
$typed_source_specific_settingsto 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.Comment #11
wim leersGiven @larowlan's #9, I figured I'd just get this done 😇
Comment #13
wim leersThanks, @meghasharma, for getting this going! :)