1.0 Problem/Motivation

While execute upgrade we receive abort of execution.

2.0 Detailed steps to reproduce (embed screenshots)

Just use drush updb on site with webforms

Screenshot from 2026-03-25 10-08-26.png

3. 0

We heve lot of instalations and on some of them helped adding

<?php
...
  foreach ($webforms as $webform) {
    $webform = Webform::load($webform->id());
....
?>
CommentFileSizeAuthor
#6 Screenshot from 2026-03-25 20-46-32.png139.52 KBiprosoft
Screenshot from 2026-03-25 10-08-26.png110.5 KBiprosoft

Comments

iprosoft created an issue. See original summary.

karing’s picture

karing
Location 🇨🇦
commented

I can not reproduce this on one of my own sites ->
Note: I also don't get the warning. What Drupal and Webform versions are you using?

root@webform-civicrm.io:/var/www/drupal #sudo -u www-data -E drush updb
 ----------------- ----------- --------------- ------------------------------ 
  Module            Update ID   Type            Description                   
 ----------------- ----------- --------------- ------------------------------ 
  webform_civicrm   8008        hook_update_n   8008 - Update usage of group  
                                                to crmgroup                   
 ----------------- ----------- --------------- ------------------------------ 


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > yes

>  [notice] Update started: webform_civicrm_update_8008
>  [notice] Update completed: webform_civicrm_update_8008
 [success] Finished performing updates.
karing’s picture

karing
Location 🇨🇦
commented

Github PR -> https://github.com/colemanw/webform_civicrm/pull/928

iprosoft’s picture

iprosoft commented

Webform 6.2.10

karing’s picture

karing
Location 🇨🇦
commented

Same here. I have updated a bunch more sites -> this last one uses Drupal 10.5.8 + Webform 6.2.10 + updated from Webform CiviCRM 6.3.1 -> 6.3.2, the update ran without errors. A number of partners tested PR 928.

Any more clues as to what may be different with your setup?

iprosoft’s picture

iprosoft commented
StatusFileSize
new Screenshot from 2026-03-25 20-46-32.png139.52 KB

No clue what could be different, no custom patches etc.

Screenshot from 2026-03-25 20-46-32.png

jmcclelland’s picture

jmcclelland commented

I wonder if this error is related to webform_civicrm? In the screen shot it references an error in WebformEntityStorage.php on line 93 (from the webform module). That is the first line of this function:

protected function doPostSave(EntityInterface $entity, $update) {
    if ($update && $entity->getAccessRules() !== $entity->original->getAccessRules()) {
      // Invalidate webform_submission listing cache tags because due to the
      // change in access rules of this webform, some listings might have
      // changed for users.
      $cache_tags = $this->entityTypeManager->getDefinition('webform_submission')->getListCacheTags();
      Cache::invalidateTags($cache_tags);
    }

    parent::doPostSave($entity, $update);
  }

For some reason `$entity->original` is null in your case. Unless there is some relevant errors earlier in the screen share, it seems that the 8008 upgrade made it successfully all the way up to the point where it is supposed to use the webform API to save the webform and that's where it failed.

iprosoft’s picture

iprosoft commented

The line is the same, there are no changes here.

I just searched between $webform->save(); > $entity->original->getAccessRules(), but unfortunately I couldn't find anything.

It looks like $entity->original isn't being assigned, or for some reason it's being assigned NULL.

iprosoft’s picture

iprosoft commented 
Error: Call to a member function getAccessRules() on null w Drupal\webform\WebformEntityStorage->doPostSave() (linia 93 w web/modules/contrib/webform/src/WebformEntityStorage.php)
#0 web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(489): Drupal\webform\WebformEntityStorage->doPostSave()
#1 web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(257): Drupal\Core\Entity\EntityStorageBase->save()
#2 web/modules/contrib/webform/src/WebformEntityStorage.php(108): Drupal\Core\Config\Entity\ConfigEntityStorage->save()
#3 web/core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\webform\WebformEntityStorage->save()
#4 web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(617): Drupal\Core\Entity\EntityBase->save()
#5 web/modules/contrib/webform_civicrm/webform_civicrm.install(519): Drupal\Core\Config\Entity\ConfigEntityBase->save()
#6 web/core/includes/update.inc(178): webform_civicrm_update_8008()
karing’s picture

karing
Location 🇨🇦
commented

Perhaps this?
https://www.drupal.org/project/webform/issues/3423890

karing’s picture

karing
Location 🇨🇦
commented

Which suggests it's a Drupal Entity API issue.

iprosoft’s picture

iprosoft commented

Yes, it probably is.
I wonder why this only happens for a few webforms, and why they differ from others in that original is not declared.
Edit: problem found, webform_presave hook was adding handler to webform if not exists and calling addWebformHandler

// Create webform handler.
    $handler = \Drupal::service('plugin.manager.webform.handler')->createInstance('webform_caltha_handler')
      ->setWebform($webform)
      ->setStatus(TRUE)
      ->setHandlerId('webform_caltha_handler');
    // Add webform handler which triggers Webform::save().
    $webform->addWebformHandler($handler);

This triggered another save() on object but then it won't have set original param.

Thanks for help!