Sometime in the last few weeks I noticed that drush dre
no longer worked. Drush did not recognize dre
as a valid command.
I upgraded to 8.x-3.0-beta1
yesterday.
I uninstalled devel
.
I cleared the cache.
I installed devel
again.
Drush shows devel
as being installed.
9:21:16 › drush pml | grep -i devel
...
Development Devel (devel) Enabled 8.x-3.0-beta1
...
9:22:48 › drush | grep -i devel
runserver (rs, serve) Runs PHP's built-in http server for development.
views:dev (vd) Set several Views settings to more developer-oriented values.
I have also run /core/rebuild.php a few times for unrelated reasons, and beyond that and drush cr, I don't know of any other ways to "discard" a bad setup. I would prefer not to reinstall everything!
Is there something else that I need to do, such as activate some sort of "development" flag in my Drupal installation, that would enable and activate devel
Drush commands?'
Comment | File | Size | Author |
---|---|---|---|
#3 | drush-service-rename-3106091-2.patch | 345 bytes | epapaniko |
|
Comments
Comment #2
moshe weitzman CreditAttribution: moshe weitzman at Tag1 Consulting commentedThere is no such flag ... Please run `drush cr`. I dont have more suggestions beyond that.
Comment #3
epapaniko CreditAttribution: epapaniko at EWORX S.A. commenteddrush dre
is an alias ofdrush devel:reinstall
defined inDrupal\devel\Commands\DevelCommands
. We have the same issue with all devel commands, we get:We've tested with Drupal core 8.8.1, Drush 9.7.1 and both Devel 8.x-3.x-dev and Devel 8.x-2.1.
It seems that the drush command service is not named properly, renaming it to
devel.commands
and clearing the cache fixes the issue for us in both 8.x-3.x-dev and 8.x-2.1. Attaching patch with the fix.Comment #4
vinmassaro CreditAttribution: vinmassaro commentedCame to this issue because
drush devel:uuid
was not recognized as a command. Patch works, thanks!Comment #7
moshe weitzman CreditAttribution: moshe weitzman at Tag1 Consulting commentedMerged into 3.x and 2.x
Comment #8
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedIs it odd how that was not noticed before? The files were added in this commit in 2017 and not changed since then. So what has suddenly caused the commands not to be found?
Sorry for setting back to 'needs work' but I think there are two things we need to address:
drush.services.yml
needs the 's' on commands then so too shoulddevel_generate/drush.services.yml
?drush devel:
after reverting back to the old incorrectdevel.command:
so I hesitate to provide a patch for develgenerate: when I can't prove that my change has any effectIt looks like something else is going on, which causes many users not to be affected by this change. I think we need to know what is actually happening, as we may be doing the wrong thing for other users by simply adding the 's' without knowing what causes the problem.
If I have got completely the wrong idea, please let me know.
Comment #9
epapaniko CreditAttribution: epapaniko at EWORX S.A. commented@jonathan1055, Ι agree that any changes need to be reflected into
devel_generate
.Two questions:
devel.commands
work for you?devel.command
works?Comment #10
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThanks @epapaniko
devel.commands
and olddevel.command
work. My drush.services.yml file is definitely being used because if I changeservices:
to anything else I get 'The service file "modules/devel/drush.services.yml" is not valid' so I know I am using that file. But whether I havedevel.commands
,devel.command
ordevel.banana
I can still use the drush commandsdrush --version
givesand in 8.9 the version is 10.1.1
Maybe this is only a problem in Drush 9 and not 10? I don't have any immediate way to check that. Maybe someone else can?
For Devel Generate I have noticed another complication which slightly obsures the problem. In src/Commands/DevelCommands.php we have for example
But in devel_generate/src/Commands/DevelGenerateCommands.php there is no : in the command name, we only have
So the namespace "devel-generate:" is not going to be known anyway, and attempting
drush devel-generate:
will not produce anything.drush devel-generate
(without the colon) does produces the commands but they are categorised in the -global group. This can be fixed separately.So the question now is to test Drush 9 against Drush 10
Comment #11
moshe weitzman CreditAttribution: moshe weitzman at Tag1 Consulting commentedI think its a convention for commands to be plural but it shouldn't matter. Both forms should work, for both drush9 and drush10. You should run `drush cr` when changing names and you are testing if things work.
Nothing more to do here?
Comment #12
arnaldopIs it related that some of the commands show up under the
devel
heading, while others show up under the_global
heading?So the commands seemed not to be consistently working for everyone, and they are not being grouped together when running
drush
.As was mentioned above, is this "programming by coincidence"? Is there something else going on that is causing this problem, and the proposed patch is only coincidentally working, or perhaps only working for a few people?
Comment #13
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commented@arnaldop
That's what I mentioned in the second half of #10, this should be fixed but it is not related to the original problem.
@moshe weitzman
At minimum, as per #8.1 we should have
devel_generate/drush.services.yml
being consistent withdrush.services.yml
, whether we choose 'command' or 'commands'Can you explain? Are you saying that anything will do here? If so, then how was the original problem discovered and why was the patch necessary?
@arnaldop, @epapaniko, @vinmassaro As you all experienced the problem with 'command' could you please run
drush devel-generate
(with no : at the end) on the exitsing -dev and tell us what you get. Do you see a list of the matching commands? Or do you get the "There are no commands defined in the {x} namespace" error?If it turns out that we can't explain it, then I'll accept that, and we can just commit the change to use 'commands' in devel_generate/drush.services.yml to be on the safe side.
Comment #14
epapaniko CreditAttribution: epapaniko at EWORX S.A. commentedRunning
drush devel-generate
anddrush devel-generate-menus
on the installation that I encountered the problem result in aHowever, I tested with a fresh install of the
drupal-composer/drupal-project
and the issue does not stand. Even with the olddevel.command
service, drush commands execute fine. So, it seems to be adrupal-project
update to core 8.8.0+ problem. I've tried to pin-point the problematic dependency, but I haven't been able to do it; with everything I've done, I still get the error without the patch.IMHO, since the patched service works on older unaffected installations and fresh installs and fixes the issue on upgraded ones, we should apply the fix on
devel_generate
and resolve this. The fact that devel_generate commands are not under the module's namespace is another issue.Comment #15
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedYes I agree. Moshe said its a convention for commands to be plural which also matches with the drush9 example module and other contrib drush.services.yml files.
Comment #18
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedWhile we are on this subject, I think we might as well define the devel-generate commands to be under the sub-modules namespace. Then instead of the drush command list showing devel-generate commands being grouped under _global we will get:
The original commands can be given as an alias so that any script or habit that devs are using will still work.
Comment #21
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedGiven that the original commit in #5 was for 3.x and 2.x I fixed the devel-generate commands and the namespace on both branches.
Comment #23
merlin06 CreditAttribution: merlin06 at Australian Competition and Consumer Commission (ACCC) commentedThe problem here is drupal/token drush.services.yml defines a "devel.command" service. It should define a "token.command" service.
The drupal/token module is using the incorrect namespace.
Haha my boss has already found this and reported it to drupal/token here: https://www.drupal.org/project/token/issues/3145527
Comment #24
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThanks @merlin06, so there was something unexplained, thanks for solving the mystery.
Comment #25
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commented