Check of $value not covering LinkItem cases in link contraint validators

Created on 13 September 2023, about 2 years ago

Problem/Motivation

In certain cases, the $value parameter passed into the validators inside core/modules/link/src/Plugin/Validation/Constraint seems to be an instance of LinkItemInterface. All these validators check if the value is actually set using the following condition:

  public function validate($value, Constraint $constraint) {
    if (isset($value)) {

In the case of an LinkItem with an empty value of its uri main property this check above will pass, even though the LinkItem->getEmpty() would return FALSE. This is weird and will lead to notices like the following in case the a LinkItem with an empty uri is passed in because of the $value->getUrl(); statement further below for example in \Drupal\link\Plugin\Validation\Constraint\LinkAccessConstraintValidator::validate():

Deprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\Core\Url::fromUri() (line 281 of core/lib/Drupal/Core/Url.php).

This is sort of related to the discussion in https://www.drupal.org/project/drupal/issues/3262935#comment-15005255 ๐Ÿ“Œ Link field validation constraints don't give enough detail Needs work

Steps to reproduce

See steps in https://www.drupal.org/project/drupal/issues/3348390#comment-15228424 ๐Ÿ“Œ Improve the way entity forms are "disabled" early when an entity is being edited in a workspace Needs work as long as that patch is not applied/committed.

Proposed resolution

Check if the value passed in is LinkItemInterface instance and if that is empty skip the validation.

๐Ÿ› Bug report
Status

Active

Version

10.1 โœจ

Component
Linkย  โ†’

Last updated 12 days ago

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @s_leu
  • Status changed to Needs review about 2 years ago
  • last update about 2 years ago
    Patch Failed to Apply
  • Here a basic patch to illustrate the idea of how to change this. The added code should probably be moved into a base class if this approach makes sense at all.

  • Status changed to Needs work about 2 years ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Thank you for reporting.

    Wonder if we could get a test-only patch showing the issue.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur

    Akhil Babu โ†’ made their first commit to this issueโ€™s fork.

  • Pipeline finished with Failed
    over 1 year ago
    Total: 186s
    #77238
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur

    Akhil Babu โ†’ changed the visibility of the branch 3387013-check-of-value-11 to hidden.

  • Pipeline finished with Failed
    over 1 year ago
    Total: 198s
    #77241
  • Merge request !6163Resolve #3387013 โ†’ (Open) created by Akhil Babu
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur

    Akhil Babu โ†’ changed the visibility of the branch 3387013-check-of-value to hidden.

  • Pipeline finished with Canceled
    over 1 year ago
    Total: 103s
    #77248
  • Pipeline finished with Failed
    over 1 year ago
    Total: 169s
    #77249
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur
  • Pipeline finished with Failed
    over 1 year ago
    Total: 634s
    #77259
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur

    I was able to recreate this issue, but only with the help of custom code.

    • Go to admin/config/development/logging, select 'All' and save.
    • Add a link field with Unlimited cardinality to article content type.
    • Create a new article, add one link and save
    • Add a form after to article edit form
    • Load the node and call validate() method.[$entity = $form_state->getFormObject()->getEntity(); $entity->validate();]
    • Now try to edit the previously created node.

    The errors appear only when validate() is called on node object when we are in the node edit form. For example

    /**
     * Implements hook_preprocess_HOOK() for page.html.twig.
     */
    function MY_MODULE_preprocess_page($variables) {
      \Drupal::entityTypeManager()->getStorage('node')->load(1)->validate();
    }
    

    will not trigger any errors when the node is viewd. But will trigger error when edit form is loaded.

    When the edit form is loaded after adding a link item to an unlimited cardinality link field, Drupal automatically appends a new link widget below the existing one to add a second link item. Somehow, this second item is also validated when the node is validated from the edit form, and this triggers the NULL warning. This won't happen when the node is loaded from any place other than the node edit form. So, maybe the logic in the validate() method needs to be fixed.

    I have created a test to show the bug.

  • Status changed to Needs review over 1 year ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Akhil Babu Chengannur
  • Status changed to Needs work over 1 year ago
  • The Needs Review Queue Bot โ†’ tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide โ†’ to find step-by-step guides for working with issues.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dcam

    dcam โ†’ changed the visibility of the branch 3387013- to hidden.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dcam

    dcam โ†’ changed the visibility of the branch 11.x to hidden.

  • Merge request !13130Converted #2 to an MR and added unit tests โ†’ (Open) created by dcam
  • Pipeline finished with Failed
    17 days ago
    Total: 214s
    #586945
  • Pipeline finished with Canceled
    17 days ago
    Total: 127s
    #586950
  • Pipeline finished with Success
    17 days ago
    Total: 509s
    #586951
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dcam

    I converted the patch in #2 to an MR and added Unit tests.

Production build 0.71.5 2024