Module-defined bundle is not installed when a custom with same name already exists

subscribing

Wow. That's really hard to tackle.

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

How is this handled in D7?

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

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.

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.

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.

Tagging.

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.

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

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

again, combined with Tim's test.

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 :)

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

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

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.

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

Edited Issue Summary

Updated issue summary.

Tagging for reroll.

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

Started work

salah has assigned this to me

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"

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.

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

The patch applied cleanly but failed the test.

This is a special case of #2140511: Configuration file name collisions silently ignored for default configuration

Minor tag cleanup - please ignore.

#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.

Removed the "Needs reroll" tag.