Improve error in Editor::calculateDependencies() to get clearer understanding

Which update is executing when that occurs?

It seems to be ckeditor5 (list_start_reversed). No error when ckeditor5 is disabled.

Using drush to update db:

...
[notice] Update started: ckeditor5_post_update_list_start_reversed
>  [error]  Error: Call to a member function getConfigDependencyName() on null in Drupal\editor\Entity\Editor->calculateDependencies() (line 122 of /core/modules/editor/src/Entity/Editor.php) #0 /core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(321): Drupal\editor\Entity\Editor->calculateDependencies()
...

It looks like something is wrong with editor module configuration on the site. How is configuration managed on the site?

Are you running any patches?

@cilefen
In my case it's ckeditor5_post_update_list_multiblock:

 [notice] Update started: ckeditor5_post_update_list_multiblock
>  [error]  Error: Call to a member function getConfigDependencyName() on null in Drupal\editor\Entity\Editor->calculateDependencies() (line 122 of /var/www/about.moyakala/html/web/core/modules/editor/src/Entity/Editor.php) #0 /var/www/about.moyakala/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(321): Drupal\editor\Entity\Editor->calculateDependencies()

What exactly do you mean with "How is configuration managed on the site?".

@larowlan
No, I'm not running any patches for core.

I've solved it by uninstalling ckeditor5, running the update, reinstalling ckeditor5 and manually reconfigured the corresponding text formats.

This is definitely due to invalid configuration - \Drupal\editor\Entity\Editor::getFilterFormat() has returned a NULL which means that the editpr configured text format does not exist.

I think should make the following change to \Drupal\editor\Entity\Editor::calculateDependencies() so the error is more explicit and easier to track:

  public function calculateDependencies() {
    parent::calculateDependencies();
    $filter_format = $this->getFilterFormat();
    if ($filter_format === NULL) {
      throw new \RuntimeException(sprintf('The editor "%s" has the filter format "%s" but the filter format does not exist', $this->id(), $this->format);
    }
    // Create a dependency on the associated FilterFormat.
    $this->addDependency('config', $filter_format->getConfigDependencyName());
    // @todo use EntityWithPluginCollectionInterface so configuration between
    //   config entity and dependency on provider is managed automatically.
    $definition = $this->editorPluginManager()->createInstance($this->editor)->getPluginDefinition();
    $this->addDependency('module', $definition['provider']);
    return $this;
  }

Thanks @alexpott - You saved my day.

After adding your change to \Drupal\editor\Entity\Editor::calculateDependencies() (and adding a missing ")") I was able to debug my test setup:

[notice] Update started: ckeditor5_post_update_list_multiblock
>  [error]  The editor "webform_default" has the filter format "webform_default" but the filter format does not exist 
>  [error]  Update failed: ckeditor5_post_update_list_multiblock 
 [error]  Update aborted by: ckeditor5_post_update_list_multiblock 
 [error]  Finished performing updates. 

So it was an editor format from an uninstalled module, that I tested a while ago.

After running drush config:delete editor.editor.webform_default I was able to run drush updatedb without errors.

Bumping to major, this is preventing updates to 10.2 for multiple users, 💬 core modules won't update with Drupal 10.2.1 Active appears to be the same issue.

I've done everything listed and still just hangs.....I uninstalled CKEditor5 and still didn't update.....I've cleared everything multiple times.....when I run a browser debug it says this is the problem:

/home/customer/www/url/public_html/site/core/misc/message.js

Uncaught TypeError: Cannot read properties of null

at this point in the message.js file below:

static defaultWrapper() {
let wrapper = document.querySelector('[data-drupal-messages]');
if (!wrapper) {
wrapper = document.querySelector('[data-drupal-messages-fallback]');
wrapper.removeAttribute('data-drupal-messages-fallback');
wrapper.setAttribute('data-drupal-messages', '');
wrapper.classList.remove('hidden');
}
return wrapper.innerHTML === ''
? Drupal.Message.messageInternalWrapper(wrapper)
: wrapper.firstElementChild;
}

@Kent8 Is that error happening in addition to the one that is the subject of this issue?

If yes, does trying everything include modifying calculateDependencies as shown in comment #8 to uncover the bad configuration?

I think it's probably the same problem....I have modified calculateDependencies but I can't find the message about the bad configuration.... I have to run things manually....with an FTP client....would you have an idea where I should look.....I have added the code to the settings file to display messages but can't seem to see it....Thanks..

fyi....you can uninstall a module and when you re-install the module it applies the updates from that modules update php file in core -> modules....kind of a workaround.....problem there is still the system module you can't uninstall......

@Kent8 From your description it is impossible to guess, if it has anything to do with this issue. So you should solve that one first (and maybe open a new issue for this case) to be able to read the missing error message.

Uncaught TypeError: Cannot read properties of null

This means that no <div data-drupal-messages> and no <div data-drupal-messages-fallback> exists. Besides that core/misc/message.js should check for the existence of the fallback this could be because (just guessing):

• Your theme or a module disabled these message placeholders (like I did in a minimal base theme)
• You disabled "Primary admin actions" or "status messages" in your block layout

This is interesting. #9 shows/proves that this was a failing update because of rather broken configuration on the site in the first place. It was only a matter of time before somebody would hit that problem.

Given that, I don't follow your reasoning, @longwave, because I don't see how many people could be affected by this?

#11: that's a JS error and appears unrelated to this error that occurs only during applying updates.

IMHO we should rescope + retitle this issue to add the improvement that @alexpott proposed in #8 to make this problem (broken config) easier to diagnose for the next person to run into this.

Do you agree, @longwave?

Ran into the same issue updating from 10.1.7 to 10.2.2.

I had previously uninstalled the Webform module, too. And "webform_default" was also still in my configuration.

#9 saved my day. Many thanks!

From reading this seems the issue was with webform potentially. But seems additional logging could of helped.

Decreasing priority since #17 appears to confirm #9.

Think updating core to output better error message makes sense. Especially since the change provided in #9 has helped a number of people here.

Based on #8 I am changing this to a task. I am un-assigning so anyone can create an MR based on #8.