Skip to content
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

[Feature Request] Add systemName config option #3529

Closed
benface opened this issue Dec 6, 2018 · 9 comments
Closed

[Feature Request] Add systemName config option #3529

benface opened this issue Dec 6, 2018 · 9 comments

Comments

@benface
Copy link
Contributor

benface commented Dec 6, 2018

There's already isSystemOn and timezone so I think it would make sense to add systemName.

@brandonkelly
Copy link
Member

Do you have a use case for it, especially where it would make sense to customize it on a per-environment basis? If you just want to be able to edit it in code, that is already possible in 3.1 by editing the system.name value in config/project.yaml.

@benface
Copy link
Contributor Author

benface commented Dec 10, 2018

It's mostly, like you said, to be able to edit it in code, and not so much because it would change per environment (although I can see a use case where someone would want to append (Staging) to the system name for clarity). So for me, the project.yaml solution is great. Thank you :)

@brandonkelly
Copy link
Member

Cool :)

@leevigraham
Copy link
Contributor

@brandonkelly I also wanted this so I can flag if the system is Local / Dev / Prod in the siteName. Also we have a boilerplate and we control a lot of settings / labels from the .env file.

@khalwat
Copy link
Contributor

khalwat commented Jan 22, 2019

@leevigraham sounds like a good use case for https://github.com/TopShelfCraft/Environment-Label

@brandonkelly
Copy link
Member

@leevigraham Next release will allow you to set your System Name setting to an environment variable.

@leevigraham
Copy link
Contributor

👍🏻 Looks like the way Craft is moving is that env variables are going to be used in fields in the admin rather than config overrides?

@brandonkelly
Copy link
Member

Yep, config overrides make less sense now that things are stored and shared in project.yaml (especially sensitive data). If something needs custom values in different environments, better to have the actual config-stored “value” just be a reference to an environment variable.

@khalwat
Copy link
Contributor

khalwat commented Jan 22, 2019

Only argument I could make would be for plugin settings in a multi-environment config, and there only because I'd hate to see my .env with tons of entries in it, none of which are scoped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants