Closed (fixed)
Project:
Configuration Inspector
Version:
2.1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
27 May 2021 at 15:42 UTC
Updated:
16 Jun 2023 at 13:04 UTC
Jump to comment: Most recent, Most recent file

+ 
Comments
Comment #2
vuilComment #3
wim leersFYI: https://www.drupal.org/project/ckeditor5 also uses validation constraints extensively!
Comment #4
wim leersAnd now Drupal core uses it (because CKEditor 5 was moved into Drupal core). The Group module is also adopting it over at #2925819: Ability to force using a scheme instead of scheme-relative URLs.
Comment #5
wim leersComment #6
kristiaanvandeneyndeYes please! I've just started using constraints on config entities in Group and it's a great way to make sure the business logic is respected both when managing these entities through the UI and through code.
Comment #7
vuilComment #8
wim leersI've started building this! 🥳
I've got it working locally already. I'm building on top of #3359418: Expose validation constraint violations in Config Inspector UI and drush command. I'm starting out with Validatability % first, but that means I've got 95% of what we need in place.
Sneak preview:
Comment #9
wim leersWhile working on this, I've discovered two blocking core bugs, both of which I've added a work-around for:
Comment #10
wim leers1/4 done.
This looks surprisingly simple but took me MULTIPLE DAYS to put together! 😱
Comment #11
wim leers#3359418: Expose validation constraint violations in Config Inspector UI and drush command landed! Now this patch will apply. Re-testing.
Comment #12
gábor hojtsyThe code updates look good :) The only thing I am stuck on is whether "invalidatability" is a word or a good word at least? When I tried googling for it, Google suggested "invalidate ability" which means an entirely different thing. Should it be "--strict-validation" or only "--strict" even?
Comment #13
wim leersBut "strict" already has a particular meaning in the config schema world:
\Drupal\KernelTests\KernelTestBase::$strictConfigSchema:IMHO "validatability" is just fine. Yes, it's kinda like "cacheability" in how little it was used. But it's perfectly valid English. And there is prior use of it beyond Drupal — for example
\Symfony\Component\HttpFoundation\Response::isValidateable().How about
--invalidatable-is-erroror--not-validatable-is-error? 🤔😊Comment #14
wim leersNow validatability is shown in the UI 👍
Next up: showing validation constraints.
Comment #16
wim leersThanks to #14 I noticed that
media.settingshas the typeuriyet is marked as not validatable. That is not correct.The problem:
interface UriInterface extends PrimitiveInterface→ note that this does not inheritStringInterfaceclass Uri extends StringData implements UriInterfaceclass StringData extends PrimitiveBase implements StringInterface…UriimplementsStringInterfacetoo 🤪I didn't account for that in
::computeNodeValidatability(). Fixed.Comment #17
wim leersOops, #14 and #16 were missing the new class that #10 added.
Comment #18
gábor hojtsyI was thinking
--error-if-invalidbut that would be about the validation result not that it can be validated or not. Hm.--error-if-not-validateablecould be an option but I'm still not 100% convinced :D It has a very particular spelling that may be easy to get wrong.Comment #19
wim leersMaybe "strict" is fine. 🤔 Because we'd eventually want
\Drupal\KernelTests\KernelTestBase::$strictConfigSchemato actually validate things too.So … perhaps this is even appropriate! 😄
I'll update the patch and open a core issue for doing exactly that.
Comment #20
wim leers🐛 This means that first "detail" rows are generated for each property path … and then we continue on toward validating, which results in output like this:
👆 Each property path is listed TWICE: once for "validatability" detail, once for "data validity" detail.
That should of course be combined.
Comment #21
wim leersThis is better:
I took the liberty of slightly changing how
--detailworks. Rather than showing only details, I'm now also keeping the row for the containing config. Because that gives you a valuable high-level perspective: the % of validatability and the number of errors. Given the increase in information provided, I think this is a reasonable change.Also fixed the PHPLint error (which does not occur on PHP 8, hence I missed it).
Comment #22
wim leersI changed it to use
--strictbut ran into… turns out
drushreserves this argument:\Drush\Preflight\PreflightArgs::isStrict()🤷♀️So
--strict-validationit is!Comment #23
wim leersFixed a typo from #22 … and refactored the logic to support collecting all validation constraints.
This actually allowed me to delete code! 😅🥳 (Turns out I was computing certain things twice…)
No UI yet: not in Drush nor in the web UI.
Comment #24
wim leersNoticed a bug introduced in #16 while verifying that the output for #23 still matched that of earlier patch iterations (it did — until #16 as expected, which is how I spotted this bug) — I inverted the condition there but forgot about one of the documented edge cases:
BooleanInterface. Correctly handling that again results in significantly higher percentage of validatability, because a lot of config schemas usetype: boolean.Comment #25
wim leersI do not yet see how the list of validation constraints can sanely be shown on the Overview or the List view. But I can see a way for the Tree view:
(Also fixed a missing
usefrom #24 — splitting up in atomic commits allows for easy mistakes 🙈)Comment #26
wim leers… but I really believe that such a bulleted list just does not give enough context. I think symbols can provide a lot of clarity here, without the need for adding a lot of additional words:
P.S.: I went all the way, and made this work well in RTL contexts too:
Comment #27
wim leersAnd now, the ability to list constraints using
--list-constraintsin Drush:I think/hope this proves that this all works great now. Let's switch to the example I used for showing the validatability before:
media.settings:That's the same command as the one above, just replacing
cdn.settingswithmedia.settings. Makes sense to me!IMHO this is ready now. An idea for a follow-up could be to distinguish between inherited constraints vs local constraints — that would make it clear that for example the
_corekey (which is present in bothcdn.settingsandmedia.settings's Drush output) actually is of the type_core_config_info— so adding a validation constraint there would fix it everywhere.Comment #28
wim leersAnother follow-up would be to map the FQCNs to the equivalent types:
\Drupal\Core\Validation\Plugin\Validation\Constraint\PrimitiveTypeConstraintwould becomePrimitiveTypebecause of\Drupal\cdn\Plugin\Validation\Constraint\CdnDomainConstraintwould becomeCdnDomainbecause of… but that's really just a nice-to-have compared to today, where this information is still painfully difficult to access.
Comment #29
wim leersRE: "strict" → created #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate for core.
Comment #30
wim leersComment #31
gábor hojtsyLooks great overall! I think there is a disconnect where we say the data is not validatable and then we say the data is valid :) Can we unbreak the terminology mismatch there?
Comment #32
wim leersGood call!
I was not happy about that either.
Having worked on #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate in the mean time, I think I know how to distinguish:
Valid(when actually properly validatable) vsCorrect primitive type(when no real validation constraints are present, only primitive type is being checked):and in the UI:
What do you think?
Comment #33
andypostThank you Wim! It's very helpful and require to fix previous commit...
But when I'm looking at report in browser/drush the amount of duplicated
Correct primitive typemakes my eyes skip errors because errors are shorter and less visible (skimmable)As this value is displayed for every non-error line it could be added to "legend" (above or below table) to prevent printing expected defaults on each line.
On fresh core install 10.1.x it shows only 2 errors and no performance affected
btw I can't install module for 11.x branch)
Moreover without this patch the variable is undefined in current 2.1.x branch
Comment #34
gábor hojtsyI agree with @andypost that a shorter result would be better with a legend if needed, especially in the drush result.
Comment #35
wim leersAdding a legend is trivial per https://symfony.com/doc/current/components/console/helpers/table.html#sp.... We could choose to add it at the top or bottom.
But …
\Consolidation\OutputFormatters\FormatterManager::write()'s unavoidable call to\Consolidation\OutputFormatters\FormatterManager::validateAndRestructure()unfortunately forcefully requires every row to contain the columns that all other rows have.After a LOT of searching and trial and error I found a way to make it work. But this only allows us putting the legend at the top. (Which is probably preferable anyway.) This is the result:
Note that the legend only appears when needed:
and
I also made it stand out visually:

Finally, I made this work in the UI too:
Comment #36
andypostIt looks great!
Comment #37
andypostIt looks good even on light terminal
Comment #38
gábor hojtsyRerolled following #3361559: Config inspection should wipe relevant caches to always get up-to-date results. Let's make sure it passes our smoke tests.
Comment #40
gábor hojtsyYay, committed! We can refine this forward as needed.
Comment #41
wim leersAWESOME! 😊🥳🙏
I already started working on what I said in #27 and #28:
+
Stay tuned!
Comment #42
kristiaanvandeneyndeOoh, shiny. Nice work!
Comment #43
ronaldtebrake commentedAwesome work, looking forward to using this!
Comment #44
wim leersKept my promise, see #3364412: Improve display of validation constraints: constraint IDs instead of FQCNs and local vs inherited 😄
Comment #45
wim leers