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.

Problem/Motivation

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.

Proposed resolution

Two solutions have been proposed to solve this problem:
- Prefix "custom_" or "$module_" before machine name of node type.
- Make an implementation of hook_requirements() that detects this condition and throws an error that describes the situation and prevents the installation from proceeding.

Remaining tasks

Some patches have been created to fix the issue but the biggest issue is the path to be taken in order to fix the issue. Some are suggestion prefixing "custom_" before the machine name of the node type. Some patches have been made with this in mind but have not yet been successful. Others feel that it is a issue that is going to occur only rarely and such a major change should not be made for this issue. There should rather be a check to detect this condition and throw an error that would let users become notified that a problem exists and would offer them the option to handle it on their own terms.

#1887654: Creating a config entity with an existing machine name shouldn't work

Files: 
CommentFileSizeAuthor
#30 468976-30-only-test.patch4.42 KBmarthinal
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 67,538 pass(es), 1 fail(s), and 0 exception(s). View
#27 node-468976-27.patch2.32 KBward marzouki
FAILED: [[SimpleTest]]: [MySQL] 63,054 pass(es), 1 fail(s), and 3 exception(s). View
#19 node-468976-19.patch2.54 KBryanissamson
FAILED: [[SimpleTest]]: [MySQL] 49,225 pass(es), 270 fail(s), and 60 exception(s). View
#19 interdiff.txt1.29 KBryanissamson
#18 node-468976-18.patch3.58 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] 50,294 pass(es), 6 fail(s), and 0 exception(s). View
#18 interdiff.txt874 bytestim.plunkett
#16 node-468976-16.patch3.49 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] 49,349 pass(es), 270 fail(s), and 60 exception(s). View
#16 interdiff.txt1.24 KBtim.plunkett
#15 node-468976-15.patch3.23 KBryanissamson
FAILED: [[SimpleTest]]: [MySQL] 49,239 pass(es), 271 fail(s), and 59 exception(s). View
#13 node-468976-13.patch1.04 KBryanissamson
FAILED: [[SimpleTest]]: [MySQL] 49,128 pass(es), 275 fail(s), and 59 exception(s). View
#11 node-468976-11.patch2.18 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] 50,000 pass(es), 1 fail(s), and 0 exception(s). View

Comments

sun’s picture

subscribing

Wow. That's really hard to tackle.

joachim’s picture

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.

Leeteq’s picture

Core should check prior to starting the installation process, and abort the installatin (in time...) with a message if there is such a conflict.

Leeteq’s picture

Version: 6.x-dev » 7.x-dev

How is this handled in D7?

amateescu’s picture

Version: 7.x-dev » 8.x-dev

I was able to reproduce this in 7.x, moving to 8.x to be fixed in there first.

sun’s picture

Title: Check node type doesn't already exist when installing a module that implements hook_node_info » Module-defined bundle is not installed when a custom with same name already exists
Priority: Normal » Major
Issue tags: +Entity system, +Bundle system

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.

Everett Zufelt’s picture

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.

Alan D.’s picture

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.

catch’s picture

Issue tags: +needs backport to D7

Tagging.

rkjha’s picture

  1. Install Drupal8.x-dev using the Standard Profile.
  2. Create a new custom node type named Custom Node Type at admin/structure/types.
  3. Create a module named Foo which creates a new custom node type named Custom Node Type.
  4. Go to node/add and you find that the module didn't create a new node type named Custom Node Type. For that matter, even if it did, you don't know if it did. When you go to create a new content type using Custom Node Type, you find, to your horror, that it has the fields and properties as dictated by the node creation in Step 2 and not as dictated by the installed module.
tim.plunkett’s picture

Status: Active » Needs review
FileSize
2.18 KB
FAILED: [[SimpleTest]]: [MySQL] 50,000 pass(es), 1 fail(s), and 0 exception(s). View

Here's a test following the steps described in #10.

Status: Needs review » Needs work

The last submitted patch, node-468976-11.patch, failed testing.

ryanissamson’s picture

FileSize
1.04 KB
FAILED: [[SimpleTest]]: [MySQL] 49,128 pass(es), 275 fail(s), and 59 exception(s). View

Going off of sun's idea in #6. Adding "custom_" prefix before machine name of node type.

ryanissamson’s picture

Status: Needs work » Needs review
ryanissamson’s picture

FileSize
3.23 KB
FAILED: [[SimpleTest]]: [MySQL] 49,239 pass(es), 271 fail(s), and 59 exception(s). View

again, combined with Tim's test.

tim.plunkett’s picture

FileSize
1.24 KB
3.49 KB
FAILED: [[SimpleTest]]: [MySQL] 49,349 pass(es), 270 fail(s), and 60 exception(s). View

Two problems with my test:

  • The existing assertions needed to be updated for the 'custom_' prefix
  • The new assertion needs to use the UI, not the API, for it to expose the bug properly

Of course, this all assumes this is how we want to solve this problem, which I'm not convinced of :)

Status: Needs review » Needs work

The last submitted patch, node-468976-16.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
874 bytes
3.58 KB
FAILED: [[SimpleTest]]: [MySQL] 50,294 pass(es), 6 fail(s), and 0 exception(s). View

The 'custom_' prefix was getting added on every time the content type page was saved, it should only happen on creation.

ryanissamson’s picture

FileSize
1.29 KB
2.54 KB
FAILED: [[SimpleTest]]: [MySQL] 49,225 pass(es), 270 fail(s), and 60 exception(s). View

This was still happening in the UI when editing. tim.plunkett fixed it in this patch.

Status: Needs review » Needs work

The last submitted patch, node-468976-19.patch, failed testing.

heyrocker’s picture

It seems from a functional perspective that a better option would be to detect this condition and throw an error of some sort that describes the situation and prevents the installation from happening at all. timplunkett suggested this might have to happen in hook_requirements() but I'd rather see the user a) notified that a problem exists and b) offered the option to handle it on their own terms. The automated addition of 'custom_' to the machine name seems pretty hack to me for a situation that is mostly likely pretty damn rare.

sun’s picture

rkjha’s picture

Issue summary: View changes

Edited Issue Summary

heddn’s picture

Issue summary: View changes

Updated issue summary.

Cottser’s picture

Issue summary: View changes
Issue tags: +Needs reroll

Tagging for reroll.

Rajesh Ashok’s picture

The last patch #19, failed testing. Should we reroll this patch ?

Salah Messaoud’s picture

Assigned: Unassigned » Salah Messaoud
Issue tags: +TUNIS_2014_JANUARY, +#SprintWeekend2014

Started work

ward marzouki’s picture

salah has assigned this to me

ward marzouki’s picture

Assigned: ward marzouki » Unassigned
Status: Needs work » Needs review
FileSize
2.32 KB
FAILED: [[SimpleTest]]: [MySQL] 63,054 pass(es), 1 fail(s), and 3 exception(s). View

I have rerolled the patch against HEAD

Please note that this patch was a year old, and there has been many changes to HEAD since then. The biggest change is that this patch made changes to a file that no longer exist below is the merge message.

"deleted by them: core/modules/node/content_types.inc"

joachim’s picture

The patch at 27 only contains the tests, it doesn't have the changes to actual code.

To fix this, you need to figure out where the code that used to be in core/modules/node/content_types.inc has been moved to. The changes in the patch #19 to core/modules/node/content_types.inc need to be applied manually to this new file, once you find it.

Status: Needs review » Needs work

The last submitted patch, 27: node-468976-27.patch, failed testing.

marthinal’s picture

Status: Needs work » Needs review
FileSize
4.42 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 67,538 pass(es), 1 fail(s), and 0 exception(s). View

This test should fail. I don't know if this is the best way to make it fails... other possibilities are welcome :)

I prefer to fix the problem with a message to the user where we communicate the reason and ... then to offer the possibility to change the machine name from the current type active not altering the name of the node type by default in the contrib module.

As I can see hook_requirements invoke all the hooks only at the update phase ... So, where is the best place to do this? Here I am.

Status: Needs review » Needs work

The last submitted patch, 30: 468976-30-only-test.patch, failed testing.

Keith Eldridge’s picture

Status: Needs work » Needs review

30: 468976-30-only-test.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 30: 468976-30-only-test.patch, failed testing.

Keith Eldridge’s picture

The patch applied cleanly but failed the test.

alimac’s picture

Issue tags: -#SprintWeekend2014 +SprintWeekend2014

Minor tag cleanup - please ignore.

alexpott’s picture

Status: Needs work » Closed (duplicate)

#2140511: Configuration file name collisions silently ignored for default configuration is fixed and now if you do try to install a module that provides configuration that matches something that is in the active storage you get an exception before the module is installed.

DamienMcKenna’s picture

Issue tags: -Needs reroll

Removed the "Needs reroll" tag.