ValidReferenceConstraintValidator causes a fatal error when $item->entity isn't present

Created on 17 January 2020, about 4 years ago
Updated 12 February 2024, 19 days ago

Undoubtedly, this situation is caused by some combination of contrib (likely Decoupled Auth β†’ and/or Entity Reference Validators β†’ ) or even custom code, but still my question to core is: should it cause a fatal error? Looking at ValidReferenceConstraintValidator later on in the same class it does not assume the existence of $item->entity and instead uses $item->getEntity() (which in my situation, happens to work).

Here's the log of the error, which happens when trying to re-save a user:

Error: Call to a member function isNew() on null in Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator->validate() (line 74 of /var/www/drupal/web/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php)

(To reproduce, one can install the Find It Program Locator and Event Discovery platform's development environment, but i'm looking for more generic advice on whether Drupal core should be more robust, until i track down the cause of the user entity's username item not having the whole entity on it.

πŸ› Bug report
Status

Postponed: needs info

Version

9.5

Component
EntityΒ  β†’

Last updated about 8 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

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

Comments & Activities

Not all content is available!

It's likely this issue predates : some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States Kristen Pol Santa Cruz, CA, USA

    Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

    As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" almost a year ago and there has been no activity since that time.

    Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • πŸ‡«πŸ‡·France jabberwooki

    I got this error too when I tried to set up a computed field programmatically (no use of the Compute Field β†’ contrib module) in one of my content types.

    Here is a simplified way to reproduce the fatal error in a similar context.
    You'll just have to create a very simple custom computed field for the Basic page content type.
    You can use any of your custom modules or create one for testing purpose.

    1- Custom computed field declaration in the .module file

    function my_custom_module_entity_bundle_field_info(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
      $fields = [];
      if ($entity_type->id() == 'node') {
        if ($bundle == 'page') {
          $fields['resources'] = BaseFieldDefinition::create('link')
            ->setLabel(t('Resources'))
            ->setComputed(TRUE)
            ->setClass('\Drupal\my_custom_module\ResourcesLinksComputed')
            ->setDisplayConfigurable('view', TRUE)
            ->setReadOnly(true);
        }
      }
      return $fields;
    }
    

    2- Creation of the custom class to handle the field value calculation
    In the file web/modules/custom/my_custom_module/src/ResourcesLinksComputed.php, add the following lines :

    class ResourcesLinksComputed extends EntityReferenceFieldItemList
    {
      use ComputedItemListTrait;
    
      protected function computeValue() {
        $entity = $this->getEntity();
    
        if ($entity->isNew()) {
          return;
        }
    
          $link = array(
            'uri' => 'https://www.drupal.org',
            'title' => "Drupal web site",
            'options' => array(),
          );
    
        $this->list[0] = $this->createItem(0, $link);
      }
    }
    

    3- Testing your new computed field
    Go to Manage display admin page of the Basic page content type (.../admin/structure/types/manage/page/display).
    You will see the new field "Resources links" in the "Disabled" fields list.
    Drag and drop this field right after the enabled field(s) and save settings.
    Visit any of your basic pages and you will see the Drupal web site β†’ link a the bottom of the page.

    4- Visualizing the fatal error
    Still on your basic page, click on the Edit tab.
    No need to modify any content, you just have save the page and ... Pow !
    White screen with the same error message as mentionned by @lmncn :

    Error: Call to a member function isNew() on null in Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator->validate() (line 74 of core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php). 
    

    Now, if you pass Null instead of $link in the createItem() fonction (line 27 of ResourcesLinksComputed.php), the bug disappears.
    And, as proposed by @lmncn, replacing

    if (!$item->entity->isNew()) {
    

    by

    if (!$item->getEntity()->isNew()) {
    

    in the core web/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php file solves the problem as well.

  • I had this same issue but now realize it was due to a mistake I had made, and it's the same mistake @jabberwooki made in #12. The computed field class for the link should extend `\Drupal\Core\Field\FieldItemList`, not `\Drupal\Core\Field\EntityReferenceFieldItemList`. It was due to this mistake that Drupal was calling ValidReferenceConstraintValidator on this link field which caused the crash in the issue summary.

    After extending from the correct class I removed the patch in #2 from my site and I'm still able to save the node without the crash.

Production build https://api.contrib.social 0.61.6-2-g546bc20