Feature request: Generate fully qualified vanity domain link with `lando drush uli`

[uberhacker]

Lando currently requires lando drush uli -l mysite.lndo.site to generate a login link without http://default/.... It would be nice if you could exclude the -l mysite.lndo.site part of the request if in the project directory.

[uberhacker]

This issue appears to extend to Drupal multisite environments also. It would be very helpful if the -l ... option could be omitted.

[serundeputy]

@uberhacker

• Drupal 7: https://github.com/lando/lando/issues/339#issuecomment-329470443
• Drupal 8: https://github.com/lando/lando/issues/339#issuecomment-329495496

[uberhacker]

@serundeputy: I could do that but lando already knows my vanity domain, right?

[pirog]

@uberhacker so the tricky part here is that lando can really only make a good guess about what URL should be used. The obvious issues are

1. Vanity URLs are not universally used, or in some cases just don't work
2. The user could add (and prefer) a custom vanity URL

There are various things we could do to mitigate those concerns but they seem excessive and still potentially brittle. Personally, i haven't been able to think of a good, simple and clever way to do this reliably. Def up for suggestions.

[uberhacker]

You also have the situation where a request is made by https instead of http. In that case, the hardcoded domain in settings.php causes issues. Drupal internally already knows how to select the correct sites directory based on the url request so, in theory, multisite could "just work" :tm: as long as the project name matches a sites directory.

[pirog]

Yeah i hear that although i think you can use a protocol conditional based on drupals drupal_is_https or the HTTPS server var. Seen a bunch of people do that to setup dynamic protocol $base_url.

The issue is less on the Drupal side and more on the Lando config side eg we don't really have a universally reliable way to divine from Lando which URL the drush command should use

[uberhacker]

Would this be over simplifying things? What if you take the project name: fubar from .lando.yml and look in the sites directory for fubar. If the directory exists, then use all the settings from that directory instead of default.

[pirog]

@serundeputy this issue is plagued by the same underlying problem as the lando open command which is that we have no explicit notion of "primary URL" in lando, or a reliable way to programmatically assign one.

Maybe we should introduce some sort of way the user can specify the primary URL in the .lando.yml file so we can move issues like this and lando open along? Of course, this is something we could set behind the scenes in our recipes as a "sane default" which could then be overridden by the user.

Also worth pointing out that this would be a BIG change so it might not be worth it. Curious about your thoughts @serundeputy

[dustinleblanc]

Pantheon definitely sets a 'default platform domain' which makes having a 'sane default' possible on the platform for Drush commands.

However, Pantheon is far, far more opinionated than Lando. Pantheon allows one single static recipe with pre-defined services and no way to create more.

IMO, while this is a helpful concept, I'd only imagine it applicable to specific recipes, so if we try to do anything about it, it will have to be very recipe specific. I always used $base_url or a really solid drush alias to solve this problem in my experience.

[uberhacker]

Isn't drush already specific to drupal recipes? My point here is that leaving the extra step to the user to configure is unnecessary. Even if the default url is "wrong", the user can still override with -l thedomainiwant.com which is already the way it works currently.

[dustinleblanc]

Very true. Just commenting that implementation should be narrow

[gitressa]

Could this issue be resurrected? If it's possible, using the name: mywebsite value from .lando.yml to set Site URI to http://mywebsite.lndo.site, fx to generate one-time logins for the domain would work in the vast majority of cases. Using $base_url in settings.php was removed from Drupal 8 in 2015.

If a user wants something else, they always have the freedom to qualify it with the -l parameter: drush uli -l http://myotherwebsiteaddress.lndo.site

[pirog]

Very much against this for same reasons as mentioned in comments above. This is something that needs to either work for almost all use cases or shouldn't be done at all. It might make 70% of user's lives easier but it's going to come at the expense of the 30% who see this as Lando "not working" because its not expected that we override tooling in this way.

[gitressa]

All right, I get your point. I just wanted to check if perhaps the underlying issues had been fixed in the meantime. How about this idea you mentioned Jan 7, 2018?

Maybe we should introduce some sort of way the user can specify the primary URL in the .lando.yml file so we can move issues like this and lando open along?

Something like this perhaps?

name: mywebsite
recipe: drupal8
base_url: mywebsite.lndo.site

[dustinleblanc]

fwiw, I've been doing this on our projects for a good while:

services:
  appserver:
    overrides:
      environment:
        DRUSH_OPTIONS_URI: "https://appname.lndo.site"

[pirog]

@dustinleblanc i smell a great guide!!! wanna spin up an issue for it?

[dustinleblanc]

It hath been spun to the up. :+1:

[gitressa]

Yes, I am aware of that solution, I found out about it on this page a few weeks ago: https://docs.lando.dev/config/drupal8.html#default-url-setup

However, it seems a bit convoluted to me, as opposed to simply defining it in .lando.yml with a one-liner. But yes, it works fine :-)

[GoonerW]

I normally use environment files (https://docs.lando.dev/config/env.html#environment-files) for this purpose so we don't check them into source control (unlike .lando.yml).

You could also use a .lando.local.yml file to override them as well but in all cases, updating any of the files will require a lando rebuild as the environment variables are then baked into the container images and don't read .lando.yml on startup.

[gitressa]

Thanks for sharing your approach @GoonerW. I already got so many config files, and would like to keep it at a minimum. But would the set up be something like this?

In .lando.yml:

env_file:
  - defaults.env

In defaults.env:

DRUSH_OPTIONS_URI=http://mywebsite.lndo.site

[GoonerW]

Normally you would have two env files. One .env.example which is checked into source control and lists all the environment variables that need to be configured. The other, .env, that is not checked in but has all the variables set to their appropriate values.

The .env file is also used if you're using the phpdotenv package from Composer with your Drupal environment though this is injected into the PHP environment at runtime (and the variables are not available outside of PHP as a result).

[gitressa]

That makes sense, like default.settings.php to settings.php. Thanks for expanding your explanation.

[dustinleblanc]

I think setting Lando specific env vars that won't change within a Lando context is better done with the env var overrides that showed above. I would use the .env file for things that might change between developers, or things that might need to be set outside of Lando

[pirog]

I'm with @dustinleblanc

[uberhacker]

I think you guys are missing the point of my request. Lando already knows my project name. Just include that internally so none of this extra config is even necessary. Of course, if the overrides are provided, use them instead. Simple enough?