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.
Ahoy,
For #1836516: Port Masquerade to D8 and rewrite + simplify it into a new 2.x series, we're developing an integration between latest Masquerade module and Administration menu module, so I have
- A masquerade module feature branch (8.x-2.x-admin-menu)
- An additional admin_menu module to include (8.x-3.x)
...and so I tried this:
http://simplytest.me/project/masquerade/8.x-2.x-admin-menu?add[]=admin_menu
But the resulting demo only contained Masquerade, but not Administration menu for some reason. Is prepopulating additional projects via GET query string battle-tested already? :)
Comment | File | Size | Author |
---|---|---|---|
#13 | drupal_8_additional_modules-1927350-12.patch | 2.8 KB | patrickd |
Comments
Comment #1
patrickd CreditAttribution: patrickd commentedhi!
Additional modules are downloaded by $drush dl, I guess the problem is that admin_menu has no stable release yet
the problem is that I can't add "--dev" to the drush command as that would cause it to download always the dev version instead of the stable one
But yes, that issue is a bit annoying, I would expect it to behave correctly, no matter what core version
suggestions?
Comment #2
sunHm. Technically, http://drupal.org/project/admin_menu shows a 8.x-3.x release though? It is selected as recommended release, so normally drush should download that.
In any case, could we replicate the version selector from the main project to each additional project and make it default to a "- Recommended -" option?
Comment #3
patrickd CreditAttribution: patrickd commentedhmmm, okay I've now tested it again and had a look at the logs afterwards:
So the actual problem is that drush downloads admin menu to
sites/default instead of sites/default/modules.
That's odd, it works perfectly local.
Maybe different drush version, or other environmental side effects. Have to look that up in detail later.
I'd rather not add any more complexity to the submission form. I'm looking at my logs daily and some people already have problems to understand it now. Adding a version selection to addition modules would IMHO mess that up completely.
Comment #4
patrickd CreditAttribution: patrickd commentedAfter some more debugging I found out that drush is not using the correct root directory while downloading the module in drupal 8.
So I added the --root= option
Now another problem occurred:
Which is a known issue for drupal 8, see #1867348: Drush 5 broken on Drupal 8
And was already fixed and committed: http://drupalcode.org/project/drush.git/commit/791fca2bded23ee5dac0610d1...
But not tagged yet for 7.x-5.x
Tried out 7.x-6.x, does not work either because it expects drupal to be already installed before downloading any projects..
Manually replaced drush with current 7.x-5.x version..
Now getting..
Drush 5.0-dev does not support Drupal 8. Use Drush 6 instead. [error]
well, that sucks.. I'll give it another try tomorrow, not sure what to do here yet..
If theres no other way I've to move that drush command after the installation.. thats pretty shitty
Comment #5
sunThanks for looking into this!
I can't tell whether it's safe to use for simplytest.me, but I'm actively using Drush 8.x-6.x (from a git clone).
Comment #6
patrickd CreditAttribution: patrickd commentedComment #7
patrickd CreditAttribution: patrickd commentedTalked with moshe and it sounds like there's no we-just-change-how-drush-gets-called solution, seems like solving this problem requires changing the distributions code too.
Quickfix: Remove "themes" as option from additional modules, so we can let drush put all the stuff into the modules folder.
drush dl $shortname --destination="sites/all/modules"
Alternatively: Instead of just submitting a list of shortnames to the server, also tell him what kind of project it is so drush can put it into the right directory.
drush dl $shortname --destination="sites/all/$type"
I'm not really fond of any of these solutions :-/
Comment #8
sunDoes it expect Drupal core to be installed or just "to be there"? If the latter, couldn't you perform the downloads in a two-step process? I.e., first supply Drupal core, then the projects?
Comment #9
patrickd CreditAttribution: patrickd commentedDrupal 8 core is already there and drush is called like
drush dl admin_menu --root="/where/drupal/is"
and it just downloads it into the drupal root directory
Strangely that works without problems for D7 distributions - which are also not installed when drush dl is called
Comment #10
patrickd CreditAttribution: patrickd commentedOkay, seems like projects get downloaded into an other directory than the drupal root if sites/all exists:
This seems funny to me...
Comment #11
sunHm. Yes, D8 has a new top-level
./modules
directory. Perhaps Drush attempts to download modules into that directory?Comment #12
patrickd CreditAttribution: patrickd commenteddon't know what it tries, but when there's no /sites/all it just puts it into the root
creating the sites/all directory resolves the issue locally..
unfortunately I get
on the server
Tried with different commits in the 8.x-6.x branch of drush, but it just keeps failing
Comment #13
patrickd CreditAttribution: patrickd commentedokay.. I think I figured it out now, seems like preparing an empty settings.php without having drupal installed confuses drush..
Comment #14
patrickd CreditAttribution: patrickd commentedcommitted pushed deployed works
wow this one was annoying
Comment #15
moshe weitzman CreditAttribution: moshe weitzman commentedIt is not clear what drush needs to do here if anything.
Comment #16
patrickd CreditAttribution: patrickd commentedokay, that's kind of an unspecific question..
this issue is about the advanced option called "add an additional project" on simplytest.me.
all projects added will be downloaded using drush, so it can take care of downloading the correct and current stable version.
problem was that I was using drush 5.7 and it didn't work with d8
I upgraded to 6.x and it still did not work because drush kept putting the files into the root directory of drupal, creating an "all" directory resolved that issue.
another problem was that a default.settings.php was copied to settings.php, drush 6 kept failing as long as there was this "empty" settings file
so now drush works just as expected and just downloads a list of contrib projects...
Comment #17
sunIf I understand it correctly, then the two issues seem to be:
Comment #18
patrickd CreditAttribution: patrickd commentedRight, just in addition to point 1: It does not only deny download, drush completely errors with
Drush command terminated abnormally due to an unrecoverable error.
I still consider *this* issue as fixed, I will create two followup's for drush:
#1937050: Drush 6: if no sites/all exists it downloads to root
#1937052: Drush 6: Fatal error with empty settings.php
Comment #19.0
(not verified) CreditAttribution: commentedUpdated issue summary.