Cms: Bring back support for environmentVariables (sort of)

[brandonkelly]

We should bring back support for the environmentVariables config setting, but only as a way to define _actual_ environment variables (using setenv()). Then discard them.

We should also bring back environment variable tag parsing in things like asset volume settings, but for the _actual_ environment variables; not a Craft-specific concept of them. So if a volume’s File System Path is set to {FOO}/images, {FOO} would be replaced with the value of a FOO environment variable (fetched via getenv() – so it doesn’t matter how it was set).

[khalwat]

I like the idea and think it will reduce quite a bit of confusion that people are having. I wish it wasn't coming post-RC, but better than post-GA!

Will this environmental variable parsing work everywhere that a micro-template is parse via renderObjectTemplate() or will it only work in specific places?

I could see it being useful beyond just Asset Volumes and Assets... maybe even with a renderEnvironmentObjectTemplate() method that does it automatically, and is used for any AdminCP fields that use micro-template rendering?

[brandonkelly]

It would need to be separate from renderObjectTemplate(), as that assumes that all {singleBraceTags} are references to properties of the passed-in object.

[khalwat]

Right, that's what I'm suggesting. A renderEnvironmentObjectTemplate() method that first parses any matching ENV vars, and then calls renderObjectTemplate() on the result.

p-code:

foreach $curlyBraceMatches as $curlyBraceMatch {
    if ($matchEnv = getEnv($curlyBraceMatch)) {
        replaceEnvVars($curlyBraceMatch, $matchEnv);
    }
}
$this->renderObjectTemplate();

[brandonkelly]

Took this in a slightly different direction. Instead of re-adding support for the environmentVariables config setting (and redefining what it means), I’ve added support for a new aliases config setting, which can be used to define new Yii aliases. Plus, asset paths and URLs can now begin with an alias (as well as site URLs). And for backwards compatibility, if no aliases config setting was defined, Craft will fallback to environmentVariables (and log a deprecation error).

I’ve also added a migration that will automatically convert volume settings that begin with a Craft 2-style environment variable tag, so that they follow the new @alias/subpath format instead.

In summary, Craft 2’s environmentVariables are now replaced with aliases, and the syntax is a bit different (@alias/subpath instead of {variable}subpath), but for all intents and purposes they basically work the same.

[khalwat]

Very clever.