Validate inputs of TypeResolver::resolveExpression(): only allow %parent, %type and %key

Implementation discussed with @Wim Leers yesterday.

1. +++ b/core/lib/Drupal/Core/Config/Schema/TypeResolver.php
   @@ -84,8 +84,17 @@ private static function replaceVariable(string $value, $data) {
   +    $previous_name = null;
   

   s/null/NULL/

2. +++ b/core/lib/Drupal/Core/Config/Schema/TypeResolver.php
   @@ -84,8 +84,17 @@ private static function replaceVariable(string $value, $data) {
   +        throw new \LogicException('The only valid usages of a config schema with a % in it are %parent, %key, and %type in ' . $value);
   

   \Drupal\Core\Config\TypedConfigManager::replaceVariable() calls these variable values, we should probably do the same here.

3. +++ b/core/lib/Drupal/Core/Config/Schema/TypeResolver.php
   @@ -84,8 +84,17 @@ private static function replaceVariable(string $value, $data) {
   +        throw new \LogicException('%type can only used when immediatly preceeded by %parent in ' . $value);
   

   Typos 😅

Was looking at the configuration validation issues, and noticed this should actually be marked as postponed, changing status to match the reality.

This would complement 🐛 Consistently use "dynamic type name" and "expression" instead of "variable value" in TypedConfigManager's terminology Fixed very well.

🐛 Consistently use "dynamic type name" and "expression" instead of "variable value" in TypedConfigManager's terminology Fixed landed!

@borisson_: Could we add a secondary MR here that does not modify TypeResolver (which does not exist yet, which is why this issue is postponed), but instead modifies TypedConfigManager? We'd have to rebase the EntityBundleExists MR that this is blocked on, but we probably need to rebase it anyway at this point.

📌 Add new `EntityBundleExists` constraint Fixed landed so this is now unblocked!

Transformed #5 into a MR. Now reviewing 🤓

FWIW, this is becoming more important, because other issues are starting to adopt TypeResolver too — for example 📌 Convert field_storage_config and field_config's form validation logic to validation constraints Needs work .

Fixed the remarks from @Wim Leers. I had to update one existing test: https://git.drupalcode.org/project/drupal/-/merge_requests/6404/diffs?co...

Looking close, two small pieces of feedback 😊

Fixed the first (variable value) remark, the other one is a bit harder to figure out. It's part of the test coverage we created for 📌 Add new `EntityBundleExists` constraint Fixed , not for this issue.
I don't know how to add the requested test coverage.

@borisson_ You'll want to modify the test logic to not just mock a parent level, but a grandparent level. That way you'd be able to at least test %parent.%parent.entity_type_id, and then there's >1 test case again :)

Fixed the feedback, rerolled on 11.x and added test coverage for %key. I think this is now ready for another round of reviews.

Hopefully resolved the new comments.

Was going to RTBC, then spotted one last small problem. 🫣

Updated the issue summary for you :)

Applied Wim's latest suggestion, it is indeed more clear like this.

alexpott → credited phenaproxima → .

Committed and pushed 94e4d4715c to 11.x and fce65ce3aa to 10.3.x. Thanks!

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