Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When installing using drush there is a error reported:
In RouteProvider.php line 211:
Route "admin/config/people/accounts" does not exist.
Failed to run drush en -y user_registrationpassword: exit status 1
Steps to reproduce
ddev config --project-type=drupal10 --php-version=8.2
ddev composer create drupal/recommended-project:^10
ddev config --update
ddev restart
ddev composer require drush/drush
ddev drush site:install -y
ddev composer require drupal/user_registrationpassword
ddev drush en -y user_registrationpassword
Proposed resolution
From:
https://www.drupal.org/docs/develop/creating-modules/let-drupal-know-abo...
If your module offers a configuration form, then you can specify the route to this form here.
The value in the info.yml file should specify a route instead of a path.
Remaining tasks
Change the code
Review the MR/Test the solution
Merge the MR
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Screenshot 2024-12-24 at 23.38.27.png | 95.22 KB | oily |
Issue fork user_registrationpassword-3495504
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
the_g_bomb commentedComment #4
the_g_bomb commentedComment #6
oily commentedFixed PHPCS.
Comment #7
oily commentedFixed typo in steps to reproduce: 'site:install' instead of 'site-install'.
Comment #8
oily commentedSee screenshot showing successful enabling of the module after applying the MR.
Taking the liberty of changing status to RTBTC though I did make a PHPCS commit. I also assume that the tests are not setup properly yet hence they are failing whether an issue is fixed or not.
Comment #9
oily commentedComment #10
the_g_bomb commentedWe should keep the solutions specific to the issue scope. PHPCS issues should be fixed in an issue of its own.
drush site-install is an alias of site:install (https://www.drush.org/13.x/commands/site_install/) so either would work, but you have highlighted an issue in the instructions. drush cannot be called where you changed it as drush has not yet been installed.
I'll further change the instructions.
All that being said, thanks for the review
Comment #11
oily commentedI see what you mean: the PHPCS issues did not result from your commit/ your code. So stricly speaking a new issue should be created for it.
I have been working solely on core commits for some time. I think it is reasonable to fix the PHPCS under this issue. I normally have to fix iteratively PHPCS etc errors per core commit and it can be numerous times to fix one issue.
My approach here is, if it is a matter of whether the PHPCS etc rules themselves are incorrect and need to be changed then IMO that necessitates a new issue. Anyway if a maintainer views this no doubt they will do what they think best.
I mean technically I should wait for the tests to pass. But given that that might never happen I see no point in waiting before changing to RTBTC.
Comment #12
oily commentedAs far as the 'site-install' command goes I recall that it was not recognised and so i tried 'site:install'. However it seems i was mistaken. It is recognised as an alias. Thanks for the correction.
Comment #13
the_g_bomb commentedThanks again.
My approach for contrib modules is that patches often have to be applied to in-use modules. If several patches change things like version requirements or PHPCS errors, then it can prove tricky to get the correct cocktail of patches to apply in composer.
For example, an unneeded version change has been applied to #2928768: username_enumeration_prevention compatiblity, which means this patch and that one cannot both be applied to the module without extra work.
If we keep the scope tight we might limit the overlap, especially if the patches aren't being merged in a timely manner. Lets hope this one goes through quickly.
Comment #14
oily commentedHi, Yes I agree. Keeping atomicity of issues is best. I am not sure how gitlab is setup for this module. I think would be best if merges are only allowed by a maintainer if PHPCS PHPSTAN etc are green.
I would apply as a maintainer but I dont have permission to opt projects into security advisory which is required for this module. To get that you have to create your own project that showcases secure coding practice. Not sure if you have knowledge/ experience of that you could share? I could create test coverage for this issue but will wait for this issue to be handled by a maintainer. Could also create a few basic tests. I am on Slack in #contribute channel and #needs-review-queue-initiative for further discussion.
Comment #16
vladimirausThank you for your contributions.
Merged. 🍻