Silverstripe-framework: Better support for custom host/base url in CLI / env vars

[dhensby]

Following on from #6337 we need to make sure CLI tasks can correctly work out their intended full URL.

Previously this was doing using $_FILE_TO_URL_MAPPING which has now been removed.

The environment variable SS_HOST has been added, but this only addresses the host name and not the protocol or base url (the sub directory that SS may be running in on a domain).

We currently have the ability to set Director.alternate_base_url as well as alternate_protocol and alternate_host. These can be used in combination but their effect isn't limited solely to CLI and this may be undesirable or inflexible on sites that require multiple domains to run.

Therefore, some environment variable(s) should be made available to provide a fallback when there is no other means to determine the host/protocol/base url.

---

Side note: it is currently possible to set the alternate_base_url to a full url (eg: https://example.com/base/). I feel this is confusing and we complicates our code and makes the behaviour less predictable. It may be worth deprecating this variable and replacing it with base_path as it appears the original intention was really only to set the base directory. It also leads to unexpected behaviours; if alternate_protocol is set, which protocol should be used - the one from the alternate_base_url or from alternate_protocol?

[sminnee]

Side note: it is currently possible to set the alternate_base_url to a full url (eg: https://example.com/base/). I feel this is confusing and we complicates our code and makes the behaviour less predictable.

I'm not sure I agree. A URL captures protocol, host, and path in a single well-recognised string.

It also leads to unexpected behaviours; , which protocol should be used - the one from the alternate_base_url or from alternate_protocol?

Maybe we shouldn't have alternate_host and alternate_protocol? I agree that we should only have 1 way of providing a given piece of config.

---

In any case we should pick between either providing these options:

• SS_HOST - e.g. "localhost"
• SS_BASE_PATH - e.g. "/subsite"
• SS_PROTOCOL - e.g. "https"
• SS_PORT - e.g. "8080", "80", "443", or ""/null to infer from the protocol

Or this one:

• SS_BASE_URL: "https://localhost/subsite"

---

The other question how this manifests as Director properties. We have alternate_base_url / alternate_host, which are slightly confusing names.

The best bet is probably to treat the values as the canonical URL rather than the default, and for instance when sending emails from a web request, favour the use of canonical URLs.

Additionally, perhaps we should refactor how Director is triggered so that we're always passing it an HTTPRequest object, and then Director doesn't need to be responsible for all this URL inferencing.

[sminnee]

Alternatively an SS_WEBROOT environment variable could be use to infer the sub-paths. It would essentially be treated the same as the key of file-to-url-mapping, but wouldn't support multiple values.

SS_HOST = 'localhost'
SS_WEBROOT = '/Users/sminnee/Sites'

[sminnee]

@silverstripe/core-team my recommendation here is that we return to something closer to SS3's approach and allow for a SS_BASE_URL environment variable that can be a URL. This is a compact and intuitive way of providing host, base path, protocol, and port in a single config option.

Can we get some votes on that solution?

[tractorcow]

Yes that's fine. we could support 'mixed' protocol by allowing protocol-less urls. E.g. //google.com/subdir.

[dhensby]

I'm happy with a single consistent approach. At the moment, in 3, there are to many options. Alternate Base URL can mean base path or full URL...

[tractorcow]

Fix at https://github.com/silverstripe/silverstripe-framework/pull/6798