Namespace collision user

I faced same issue with different error.
Got error 'PHP message: Uncaught PHP Exception Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: "You have requested a non-existent service "password_migrate"." at vendor/symfony/dependency-injection/ContainerBuilder.php line 819\n

This issue sounds like we don't validate the name of the features. A user feature conflicts with the 'user' module in core.

I believe a good solution would be some validation which ensures that there is no existing module with the same name out there. In case its detected some helpful information could be thrown.

@dawehner

That sounds right (disallow names of existing modules, not just enabled ones).

To a certain extent we're producing this problem ourselves, since we allow creation of automatically named features without a features bundle prefix. As well as a 'user' feature, our default packaging plugins produce a 'core' one that may be a reserved name even though it's not an extension.

Probably a major issue that Features WSOD's the site by default if you export the features it suggests

Probably a major issue that Features WSOD's the site by default if you export the features it suggests

Indeed.

It's not clear though what we should do here.

The fact that the module exists is not enough, since we may be regenerating a feature we've previously installed.

Whatever handling we add might go in FeaturesManager::initPackage(). But in the case that a machine name is taken, what should we do?

• Silently skip initializing the package?
• Throw an exception?
• Generate a unique name?

Or should we instead create the package but disallow generating it?

If we're detecting conflicts, what module list do we compare candidate names against?

• Enabled on the site?
• Present on the site's file system?
• Present on drupal.org?

The specific problem with user module probably dates from our refactoring in #2401617: Support multiple feature sets. Prior to that work, features always had a prefix. Subsequent to it, we by default offer unprefixed features.

So some possible approaches would be:

• Introduce a prefix for the default features bundle.
• Disable direct use of the default bundle. Instead, require a custom bundle.

But either one would be a major change and would raise various issues. And even this wouldn't guarantee uniqueness.

Here's a preliminary patch that adds validation on requested package names based on machine names of non-feature modules present on the file system.

Will need to update every call to FeaturesManager::initPackage() to handle a FALSE return value. But first, looking for ideas on how to handle exceptions or provide user feedback.

Setting to needs review to see what the testbot makes of this initial draft.

Crosslinking maybe related issue.

Is this reproducible with 8.2.6? Just fixed a similar error by upgrading a site.

I think the related issue on fixing the validation in the New Feature edit form definitely helps a lot with this.

I don't want the "default" bundle to have a prefix. That will drive people crazy. In many use cases people are still using Features the "D7 way" and ignore the bundle namespaces and just want to manually enter the full feature module name. If they enter "myproject_mymodule" even without creating a "myproject" bundle I wouldn't want Features to add "default_" to the front of this or something.

I think if Features tries to init a package with a name that conflicts with existing *installed* modules, then it should generate an exception. I know this might be an issue during installation of a profile where a conflicting module might not be loaded yet, but seems like Drupal itself will still cause an exception once it gets to it.

But just because I have a non-enabled module "mymodule" on a site shouldn't prevent me from exporting a feature with that name (which might be the new version of that module).

I think fixing #2841683: Feature name validation must respect namespace reduces the severity of this issue so down-grading it. If this is still an issue that needs more work I'd like to see more discussion before making any sweeping changes.