-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config Overrides #10573
Config Overrides #10573
Conversation
Added tests 🌈 |
# Conflicts: # src/config/GeneralConfig.php
How would this handle properties that can be either a string or an array, such as loginPath, where there may be different values for each site? Also, seems like plugin settings should be factored in, somehow. |
Because those are just typed as I was considering anything beyond a simple csv string to array out of the scope of this, as that comes with more baggage, and there are other tools that already do it: https://github.com/josegonzalez/php-dotenv, https://packagist.org/packages/symfony/dotenv. If someone needed to set a complex var like via env like this, I would just suggest they do it themselves in general: [
'loginPath' => ['siteA' => App::env('SITE_A_LOGIN_PATH'), 'siteB' => App::env('SITE_B_LOGIN_PATH')]
] We could go down the road of parsing these, or implement env dot notation, but that seems like a whole other concern. |
This doesn't happen automatically right now, but any plugin could opt-in by making a Config class that extended |
Re: plugins – we could check for a |
What it does:
craft\base\Config
forDbConfig
,GeneralConfig
to extend.init
, it checks all of it's public properties and:ENV_PREFIX
is set (snake_cased and uppercase).CRAFT_DISABLED_PLUGINS=foo,bar
)Notes:
protected
and implement a__get
. I did it this way so it it only ever happens once, oninit
(or if you explicilty callnormalize
).ENV_PREFIX
forGeneralConfig
toCRAFT_
. Since that is shared with a few constants (andApp::env
now checks constants) we just need to make sure we don't have a constant and a general config prop named the same thing…or we could set the prefix toCRAFT_GENERAL_
, but that seemed a bit lame.DbConfig
prefix toDB_
, since that is what our starter uses, but it could just as easily beCRAFT_DB_
.renamedSettings
logic there.