Cached configuration does not work

[ArturCiolkiewicz]

Winter CMS Build

dev-develop

PHP Version

8.1

Database engine

MySQL/MariaDB

Plugins installed

Winter.Demo

Issue description

After using the cache, the configuration does not work, the error prevents the use of the configuration cache.

Winter CMS 1.2.1 (dev-develop too)
PHP 8.1.15

Steps to replicate

php artisan config:cache or artisan:optimize

Workaround

To restore configuration php artisan config:clear configuration or delete the /storage/framework/config.php file

[bennothommo]

I've taken a look into this today, and it might be more difficult than first thought.

There's two issues at play:

Config repository

Our Config Repository class is based on the old method that pre-Laravel 5 used, in that config files are loaded as they are needed (ie. the app.php config file is only loaded when you try to get a config variable that starts with app, like app.debug). This has the consequence that when running config:cache, if a particular config hasn't been used at that point, config:cache doesn't save it.

I found when I fixed the command, all the database and cookie settings were missing, among others - this was because those configs hadn't been accessed yet. Laravel 5+ uses a method of loading all the config files in the config directly immediately on initialisation - it means a slightly longer initial load time, but it does mean that everything in the config folder is available across the board. But this leads to the second problem...

Mutiple environments

Winter allows multiple environments to be defined, each with their own config, by allowing a subdirectory inside the config folder for the environment, ie. config/develop, config/production. If an environment is accessed and an override is available, it will use the overridden config in the environment directory over the one that is in the root config directory. In addition, the config/environment.php file allows the environment to be defined based on hostname, effectively allowing multi-sites. However, there won't be a hostname when running config:cache on CLI.

This means that if we were to adopt a loading method similar to Laravel 5+, and load all config files before caching, we'd have to generate multiple caches, one for each environment possible.

---

Ultimately, I'll have to do some digging on how much the configuration cache actually helps with performance with Winter. If we're talking very minimal performance benefit, I'm inclined to just remove config:cache. If there is a benefit, then we're gonna have to rewrite the config system a bit to fix both issues above.

[LukeTowers]

@saturnino are you interested in playing around with it and seeing what the performance difference is if we were to go ahead with these changes?

[gregoryloichot]

Hi. Just migrate from october to Winter :), and I sent 4hrs to figure out how to make it work. But ok it's a bug.
Would be very very appreciate if this could be fix (even with .env files).

[LukeTowers]

@gregoryloichot could you test on October how much of a performance difference config:cache made? Having hard numbers would help prioritize this; at the moment none of the core team uses the command because we haven't seen an appreciable benefit from using it; but if someone was to demonstrate a measurable impact it would be easier to justify spending the time to fix it.

[github-actions]

This issue will be closed and archived in 3 days, as there has been no activity in this issue for the last 6 months.
If this issue is still relevant or you would like to see it actioned, please respond within 3 days.
If this issue is critical for your business, please reach out to us at [email protected].