Closed (cannot reproduce)
Project:
Admin Toolbar
Version:
3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 Aug 2025 at 22:56 UTC
Updated:
14 Oct 2025 at 19:11 UTC
Jump to comment: Most recent
Comments
Comment #2
dydave commentedThanks 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
ContentEntityTypewith an associated bundle as aConfigEntityType.... 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_module2 - 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_module5 - 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 :
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_toolswith 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 ! 🙂
Comment #3
joelpittetAwww 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 😉
Comment #5
dydave commentedThanks 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!