Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem
Postponed on #2407505: [meta] Finalize the menu links (and other user-entered paths) system
Shortcut entity validation misses the logic from ShortCutForm::validate(). This is critical as the validation logic will be missed from RESTful validation. (see #1696648: [META] Untie content entity validation from form validation)
Proposed resolution
Convert the logic to entity validation and leverage entity validation in form validation.
Remaining tasks
Implement proposed resolution.
User interface changes
-
API changes
-
Comment | File | Size | Author |
---|---|---|---|
#24 | d8_shortcut_fail.patch | 2.1 KB | fago |
#20 | shortcut-entity-validation-2403847.20.patch | 7.51 KB | larowlan |
#20 | interdiff.txt | 2.57 KB | larowlan |
#18 | shortcut-entity-validation-2403847.18.patch | 6.79 KB | larowlan |
#18 | interdiff.txt | 3.77 KB | larowlan |
Comments
Comment #1
fagoComment #2
dawehnerTried on of the conversions in order to be able to review other ones.
In general though this can't be right, given that its incredible hard to pull the value you want to validate.
$value
passed into the validator though for itself is NULL, at least in the form.
Comment #3
BerdirLooks like the patch contains some the bulk action access changes as well, hard to find the relevant parts :)
Comment #4
dawehnerThese little details ;)
Comment #5
BerdirUserNameConstraintValidator might be a useful example to look at, according to that, the value you get are the $items.
Comment #6
fagoIf what you want to validate is the 'value' property only, you could just add your constraint via setPropertyConstraints() to value - then you'll just get that value passed.
Ususally, validatiors have a check for $value bing NULL and return doing nothing if so, such that NULL values go through fine / no double violations happen when a required field is missing.
Comment #7
fagoYes, except the field is empty - then you'll get NULL.
Comment #8
dawehnerI tried to use
->setPropertyConstraints('value', ['ShortcutPath'])
but this does not trigger the validator at all,maybe the arguments are a little bit different?
Comment #9
larowlanGood one for re-roll in today's office hours
Comment #10
PinoloComment #11
Pinolo@fago: isn't setPropertyConstraints() supposed to go away, as per https://www.drupal.org/node/2335633 ?
Comment #12
alimac CreditAttribution: alimac commentedWe should all try and use the same sprint tag. According to https://groups.drupal.org/node/447258 it should be SprintWeekend2015 with no #.
Comment #13
manningpete CreditAttribution: manningpete commentedI could apply the patch, so no reroll is needed.
Comment #14
PinoloI think the issue about $value being always NULL should be investigated more thoroughly, which is what I'm trying to do now. Moreover, I find very strange that, if I leave blank the path value, when I reach the ShortcutPathConstraintValidator->validate() function, the value has already been altered to "
<front>
".Comment #15
PinoloAfter going through the issue queue, I think this issue should depend on #2235457: Use link field for shortcut entity (thus making that one critical, too). Turning the path field into a "standard" link field should make some parts of this patch obsolete. As @berdir puts it in the other issue's description: "Shortcut still has (pretty hacky) separate fields for that".
Quick recap:
* given the hackiness of the shortcut path field implementation, there can only be a hacky way of getting the value to validate
* as of now, the extracted value can never be NULL or empty because, before arriving here, ShortcutPathValue::setValue() kicks in
Comment #16
PinoloComment #17
jibranWrong class name. Also first back slash missing.
First black slash missing.
Comment #18
larowlanso yeah, path is a computed field so the $items are always null, so we need to go the typed-data/metadata way
Comment #19
jibranThanks for the fixes. Here are some minor points. It is ready imo.
Isn't it all installed as a part of $modules?
We can try admin patch. We can try entity path.
We can try extrnal url.
In other words we can have more asserts :)
Comment #20
larowlanno worries
Comment #21
jibranAwesome!
Comment #23
alexpottThis issue addresses a critical bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 4a3abdc and pushed to 8.0.x. Thanks!
Comment #24
fagoLooking at the committed patch, I'm sry I think I've to re-open this. Problem is, the validated path field is computed - but computed fields are skipped on entity validation. This is green and works as it always directly validates the path field, but any logic invoking $entity->validate() would miss it.
Also, I found some other not so critical remarks:
This is wrong. We can just leave it out - it's not useful for custom constaints and needs to be fixed for lists.
From reading, I did not understood why I must say. But it has to do with computed fields being skipped, I'd assume.
Anyway, the logical level to put this would be the field item imo, as it really just validates a single item - not a list items. That way, the constraint would apply to theoritcally multi-value field properly and there should be no need to fetch the typed data object.
Tried to convert it and ran into the issue of validation being skipped -as this is all computed. (see above)
Anyway, I attached the patch I started. Not sure what's the best way to fix here. Imho, not running validation on computed things makes sense - it's computed, not user inputtted data. So it's this field which weirdly is not always computed: It only computes the value, if there is none set. Not sure how to fix this best yet.
Maybe we could fix validation of computed fields, such that we only run it as soon as custom constraint has been added?
Comment #26
alexpottOkay I've reverted so we can get more discussion about #24 - not I also discussed this patch wrt to the current discussion on path and menu link storage. I felt that committing this was the best way to go because it added tests that would be helpful if shortcut was converted to use the new storage.
Comment #27
larowlanbot review of #24
Comment #29
larowlanTo be honest I think the answer is postpone this until #2407505: [meta] Finalize the menu links (and other user-entered paths) system and #2235457: Use link field for shortcut entity are done.
After that is might no longer be a computed field
Comment #30
fagoYes, that fixes the issue with computed field validation. Agreed, this is the right way forward then.
Comment #31
fagoComment #32
tstoecklerJust one additional note since this is already reverted. This might be moot if this gets reimplemented in some way, but the current
ShortcutPath
constraint and validator in the patch are completely generic (they only rely on Core's PathValidator) so there's no reason for them to live in shortcut module. Validating paths on entities will be pretty useful for contrib.Comment #33
dawehner@tstoeckler
Good point
Comment #34
YesCT CreditAttribution: YesCT commentedComment #35
amateescu CreditAttribution: amateescu commented#2235457: Use link field for shortcut entity got in and now ShortcutForm does not do any custom validation anymore. The link field uses
Drupal\link\Plugin\Validation\Constraint\LinkTypeConstraint
so I think this issue can be closed.Comment #36
fagoAgreed - great to see this solved that way.