Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When creating an entity tab form mode, no operation class handler is set. As a result when EntityTypeManagerInterface::getFormObject is called, an uncatched InvalidPluginDefinitionException is thrown.
Steps to reproduce
- fresh install
- create a new vocabulary
- create new form mode for taxonomy terms
- navigate to admin/structure/taxonomy/entity_ui
- create new form mode tab (#3281738: Fix missing config_export in EntityTab)
- create new term in vocabulary
- navigate to newly created tab -> exception
Issue fork entity_ui-3281740
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
attisanThough I'm not 100% sure this is a good solution (actually feels rather sketchy) it does work for us.
Comment #4
joachim commentedIIRC there is a core bug about this problem, which is that the entity type definition expects a form class to be defined for each form mode, but form modes defined in the UI don't define one.
We should reference this in the code here.
Also, the workaround should check for a form class for the form mode before it overwrites it.
Comment #5
attisan@joachim are you referring to #2530086: How can we access the new form modes?? I'll go ahead and update my MR including your mentioned checking (though it should, to my thinking never reach that point as paths are already checked before creation / Entity UI is only handling this request when it stems from a custom Entity tab - but checking won't hurt 😊)
Comment #6
attisanComment #7
joachim commented> but checking won't hurt
It could be that there is some custom code (or even another contrib module -- I think I saw one?) which sets form classes on custom form modes. So we shouldn't clobber that.
Thanks for the tweak. Although, note that inline comments are marked with // and not /** */.
I've rebased the branch too, will merge it and make a new release as was the last of the showstoppers to fix.
Comment #9
joachim commentedComment #10
joachim commentedComment #11
attisanaaah, yes. sorry. Have been so keen to use @see and @todo, I forgot about the coding standard 🙈 😁
Comment #12
joachim commentedIt's ok, I fixed it before merging.
Also I tweaked the @see -- I think the @see needs to be its own line, rather than part of a sentence.