Posted by joachim on May 21, 2009 at 9:52am
8 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | node system |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Bundle system, Entity system |
Issue Summary
Here's the scenario:
- user created a node type 'foo' in the admin UI
- user then installs a module that adds a node type of the same name (eg, forum, image, program, etc...)
- user is baffled that the node type promised by the module documentation doesn't function as expected.
Obviously, node type modules can check for this themselves, but is this something core should take care of?
I'm looking at the code in node module, and a check could be made in _node_types_build() but what action should be taken if the check fails? It's surely too late by now to cancel installation of the new module.
Comments
#1
subscribing
Wow. That's really hard to tackle.
#2
Maybe this should be done just before or after hook_requirements is called on a module: call the module's hook_(define node types can't remember its name) and check against the database for those node type names and if found, act as if hook_requirements failed.
Or provide a stock check_my_type_doesnt_exist function that custom modules should call in hook_requirements if they define types, but then that's not as nice DX.
Argh, except drupal_check_module() only loads the module's .install, not its .module.
#3
Core should check prior to starting the installation process, and abort the installatin (in time...) with a message if there is such a conflict.
#4
How is this handled in D7?
#5
I was able to reproduce this in 7.x, moving to 8.x to be fixed in there first.
#6
I don't think there's any possible solution for D7- for this.
However, we need to make sure that the new entity and bundle system in D8 properly accounts for this.
E.g., all custom/user-defined bundles could get an enforced prefix of
'custom_'- or alternatively, all module-defined bundles could be enforced to have a prefix of"$module_"- not pretty, but a workaround/solution.#7
I've never run into this, but always prefix $module_ to node types I create. mymodule_foo. Again, this isn't necessarily pretty, and does sometimes cause naming issues, as I like to prefix node type name to field names, leaving field_mymodule_foo_bar as a field name, which often gets up near / over the 32 char limit on field machine names.
#8
Wouldn't a simple check / override in _node_types_build() be enough. It would set the module name and any overridden properties. So module overrides / updates User type and module with higher system weight wins if both define the same type.