Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
1. Install Features 8.x-3.0-beta3
2. Write 'User' Feature here: admin/config/development/features
3. Rebuild Cache
4. Fatal Error:
exception 'Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException' with message 'The service "ctools.paramconverter.tempstore" has a dependency on a non-existent [error]
service "user.shared_tempstore".' in /vagrant/public/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php:58
Proposed resolution
Set a reserved generic set of feature names
Remaining tasks
User interface changes
API changes
Data model changes
Original report by generalconsensus
Comment | File | Size | Author |
---|---|---|---|
#9 | features-namespace-collision-2723729-9.patch | 2.86 KB | nedjo |
Comments
Comment #2
Bhanuji CreditAttribution: Bhanuji commentedI 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
Comment #3
dawehnerThis 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.
Comment #4
nedjo@dawehner
That sounds right (disallow names of existing modules, not just enabled ones).
Comment #5
nedjoTo 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.
Comment #6
AaronBaumanProbably a major issue that Features WSOD's the site by default if you export the features it suggests
Comment #7
nedjoIndeed.
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?Or should we instead create the package but disallow generating it?
Comment #8
nedjoIf we're detecting conflicts, what module list do we compare candidate names against?
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:
default
features bundle.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.
Comment #9
nedjoHere'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.
Comment #10
nedjoComment #12
geek-merlinCrosslinking maybe related issue.
Comment #13
ccjjmartin CreditAttribution: ccjjmartin as a volunteer commentedIs this reproducible with 8.2.6? Just fixed a similar error by upgrading a site.
Comment #14
mpotter CreditAttribution: mpotter at Phase2 commentedI 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).
Comment #15
mpotter CreditAttribution: mpotter at Phase2 commentedI 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.