Configure Kirby via env . variables

[vholer]

Allow adjusting Kirby configuration via environment variables, effectively overriding options configured in site/config/config.php. Use case here is to enforce some site-specific defaults, so that the person doesn't have to change the code. We are particularly interested in adjusting the caching settings, so e.g. env. variable KIRBY_CACHE_PAGES_ACTIVE=true might have same effect as setting:

  'cache' => [
    'pages' => [
      'active' => true,
    ]
  ],

We are able to provide a PR draft covering few options to discuss.

[distantnative]

Wouldn't domain-specific config files solve your use case? https://getkirby.com/docs/guide/configuration#multi-environment-setup

[frank-laemmer]

Wouldn't domain-specific config files solve your use case?

We (fortrabbit) aim to provide a hosting software preset for Kirby CMS. For that we don't have (or don't want to have) access on the code.

This is a config file example from Craft CMS:

'devMode' => App::env('DEV_MODE') ?? false

Then with our Craft CMS software preset we can set DEV_MODE to false by default for public environments. This can easily be changed with our dashboard or .env file then, without having to touch code.

I think that is a good, extensible and by now well known pattern, offering additional convenience for users. It's also a path to store additional config, like API keys in a similar fashion. It's also backwards compatible, as one can still use the config files directly.

One use case (for us) would be, to set page caching ON -> #7861 :)

References

• Statamic config via ENV vars intro
• Craft CMS config via ENV intro

[tobimori]

https://github.com/bnomei/kirby3-dotenv can be used in the meantime (works with all modern Kirby versions)

[vholer]

Thanks. Yes, the dotenv plugin is nice, except that it's an extra optional feature. Not the standard (always available) option.

[distantnative]

@frank-laemmer @vholer Thanks for the background. Did I understand your examples right, that e.g. Craft isn't automatically checking for an env variable vs. PHP config value, but you would be happy with a helper that could be used similarly in the Kirby config file?

E.g. like

// site/config/config.php


 'cache' => [
    'pages' => [
      'active' => Kirby::env('CACHE_PAGES_ACTIVE') ?? true,
    ]
  ],

[frank-laemmer]

We created this issue feature request without too much insights into Kirby CMS, but some knowledge of similar systems.

From our (fortrabbit hosting provider) point of view, we'd like to provide some opinionated settings for Kirby. We have 'Bring Your Own Code' (no one-click installers) philosophy. Specifically turning caching on by default would be beneficial, as it can be a mitigation for #7861.

That means, not only that users can set up their own (optional) /site/config/config.php using ENV vars, but Kirby will already 'listen' to ENV vars by default (and fall back gracefully), like Craft CMS and Statamic do.

The plugin by Tobias shows some other use cases. We would probably set APP_MODE=production and APP_DEBUG=false per default too.

Benefits

Most environment specific configuration does not need to be part of code. This is specifically useful when using (and deploying) with Git. Not only can you keep secrets out of code, but also have the same code base running in different environments: local, production, staging.

Drawbacks

From the user point of view, the 'null coalescing operator' syntax may need to be understood. Apart from that, it's opt-in and backwards compatible. One can still use the old syntax. Setting ENV vars is not required at all.

I understand that there are environment specific configuration files. So there would be a bit of feature overlap. But I think the environment specific environment configs and ENV vars can work hand in hand too. Not all environment specific config can be done through ENV vars. Common config can be done by ENV var and again, config and code are better separated.

Kirby shines for simplicity and small footprint. You know your audience. Bringing a new feature is easy, maintaining it forever is hard.

[bastianallgeier]

I think it would be nice to offer such a helper to read env vars more easily. Than you can use them in combination with our configs however fits best and its usage would be explicit instead of automatic. In my opinion, this would fit best to our approach of opting into something.

[afbora]

I would really like this feature. Writing the settings to the .env file and being able to use it as Kirby::env('YAML_HANDLER') from the config file would be very useful. Laravel works similarly.

[frank-laemmer]

Thanks for discussion and evaluation. I am not an active Kirby user. My perspective is trying to streamline deployment and hosting of PHP based software. In that regard, also on my wish-list:

• Dedicated root folder by default like /public (better supporting git based flows). Imagine .env is on root level and it can be accessed through domain.com/.env …
• Queueing to make use of PHP backend workers.
• Frontmatter markdown support (built in).

Then this leads me to thinking whether Kirby CMS could be based on a PHP framework, such as Laravel Symfony, so that it may have some batteries included?

I am sure you have all that and more on the radar. You know your user base and you have the vision where to go with Kirby CMS. Maybe it is indeed more important to keep simplicity (and control) and backward compatibility - or just dare to do things differently. Feel free to reject this idea or wait to get more signal about it.