Problem/Motivation

After uninstalling a custom entity-type module, the Admin Toolbar (admin_toolbar_tools) crashes. A derived menu link plugin still references the now-missing entity type and causes a fatal when the toolbar renders.

Steps to reproduce

  1. Enable admin_toolbar and admin_toolbar_tools.
  2. Enable a module that defines a custom entity type (e.g., resource_type).
  3. Uninstall that custom entity-type module.
  4. Load an admin page.

Expected result

  • No fatal errors; toolbar renders. Any derived menu links for the removed entity type are removed/ignored.

Actual result

The website encountered an unexpected error. Try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "resource_type" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 142 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).

Drupal\Core\Entity\EntityTypeManager->getHandler() (Line: 195)
Drupal\Core\Entity\EntityTypeManager->getStorage() (Line: 38)
Drupal\admin_toolbar_tools\Plugin\Menu\MenuLinkEntity::create() (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 194)
Drupal\Core\Menu\MenuLinkManager->createInstance() (Line: 130)
Drupal\Core\Menu\MenuLinkTree->createInstances() (Line: 125)
Drupal\Core\Menu\MenuLinkTree->createInstances() (Line: 107)
Drupal\Core\Menu\MenuLinkTree->load() (Line: 118)
Drupal\toolbar\Controller\ToolbarController::preRenderGetRenderedSubtrees()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 886)
Drupal\Core\Render\Renderer->doCallback() (Line: 431)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 283)
{closure}() (Line: 637)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 282)
toolbar_get_rendered_subtrees() (Line: 295)
_toolbar_get_subtrees_hash() (Line: 168)
toolbar_toolbar()
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 191)
Drupal\toolbar\Element\Toolbar::preRenderToolbar()
... omitted for brevity ...

Proposed resolution

  • In admin_toolbar_tools, guard against missing entity types. In the deriver and/or in Plugin\Menu\MenuLinkEntity::create(), check entity_type.manager->hasDefinition($entity_type_id) before calling getStorage(); skip creating the plugin if not found.
  • Additionally, on module uninstall, trigger a rebuild of menu link plugins to drop stale derived definitions:
    \Drupal::service('plugin.manager.menu.link')->rebuild();
  • Make the deriver resilient to mid-request removals (catch PluginNotFoundException and return no derivatives).
  • Add a test that enables a custom entity type, uninstalls it, then loads an admin route to ensure no fatal occurs.

Comments

joelpittet created an issue. See original summary.

dydave’s picture

Thanks a lot Joël (@joelpittet) for the very clear and detailed description of the issue! 🙏

I started working on this and created a custom module which adds a custom ContentEntityType with an associated bundle as a ConfigEntityType.... Very standard setup that I mostly copied from core modules here and there.

I tried to follow the exact steps described in the issue summary, but unfortunately, I was unable to reproduce the error....

In other words :
1 - Install the custom module which adds the test entity type with its associated bundle.
drush en custom_test_module
2 - Browse to add a test bundle.
3 - Browse an entity bundle route defined by admin_toolbar_tools.
4 - Uninstall the custom module
drush pmu custom_test_module
5 - Refresh the page ==> The associated menus are not there anymore
The route previously browsed in 3 now returns a 404.

I tried different types of setups with/without cache, etc....

But after trying several things I was still unable to reproduce the error and the problematic behavior detailed in the issue summary.

Tested with :

  • admin_toolbar:3.6.2
  • drupal/core: 11.2.5
  • PHP: 8.3

 
Could there by any additional context missing from the description of the issue to actually be able to reproduce the error?
Would there be an example of contributed modules that could potentially be used to reproduce the issue?
Could it be possible to reproduce this type of situation with a Core module that adds an entity type, such as the contact or block_content modules?
 
I've got some code already locally for testing admin_toolbar_tools with a custom entity type, so as soon as I am able to reproduce the issue, its resolution should be pretty straight forward without taking too much time.

Any additional context, information or elements that could help us reproduce the issue would be greatly appreciated.

Feel free to let us know if you have any questions or concerns on any aspects of this comment or the module in general, we would surely be glad to help.
Thanks in advance ! 🙂

joelpittet’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)

Awww man, sorry my steps didn't reproduce the issue I reported. I don't currently have any additional context I could add to this and it looks like nobody else has run into it yet. I will close as can't reproduce until someone else stumbles this way, or I have more to offer.

It was tricky to trace back where the exception was happening, but the callstack was drawing me here 😉

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

dydave’s picture

Thanks a lot Joël (@joelpittet) for the speedy reply and clarifying the issue! 🙏

It's not me going mad, missing something in the testing steps 😆

Too bad this issue doesn't stand anymore, because I think it is probably one of the clearest and best documented ticket I've ever seen in this module 😆

Happy to hear everything is in order though 🥳

Thanks again Joël!
With great tickets like that, you're welcome to drop by at anytime 😉😆

Cheers!