Drupal 8 is currently enabling a bunch of cache-related settings (e.g. the page cache, CSS/JS aggregation, etc) for sites that install via the Minimal profile.
I think that should be considered more carefully.
The primary audience for the Minimal profile is an advanced site builder who wants to configure a new site from scratch. This person is not necessarily an experienced developer, but probably at least dabbles in a bit of custom code (especially CSS and JS) while building out a site.
Caching and aggregation get in the way of what this user is trying to do, especially if they are making a bunch of small CSS tweaks to a theme. (Of course they can turn these performance settings off, but that's one extra step for them to do before building out their site, and is kind of backwards.) See also: https://www.drupal.org/node/606840#comment-2160470
It's true there are ways to override cache settings in code, so that they are off for development but left on "for real" in the actual site configuration. These techniques have been used by developers for a long time and have sort of been formalized in Drupal 8 (see https://www.drupal.org/node/2259531). However:
More generally, the purpose of the Minimal profile is to be minimal. Caching and aggregation are extra layers on top of your site, so turning them on isn't really consistent with that...
Of course, the downside to this is that people might forget to turn these settings on when they launch their site. That is a risk. But the Minimal profile makes clear it's for advanced users only - and an advanced user should know about Drupal's performance settings. If they're not that advanced, they probably should have used the Standard profile (which I agree should configure these kinds of performance settings to be on by default).
Comments
Comment #1
fabianx commentedIf we got things right then anything a site builder does flushes the appropriate tag and such the page cache, too.
So they never should have to deal with that.
If however they are e.g. doing template work, then they need to disable the render cache anyway, which also disables page cache in turn.
I am fine with a developer profile, but not having to turn things off, indeed lets you forget to turn them on before going to production.
Maybe contrib is a good place for a good development friendly dev profile (including twig cache, aggregation, page cache, render cache, setting some advanced debug vars like twig_cache and soon render_cache_debug_output, ...)?
Comment #2
webchickI think the question is, what is the end game of the advanced site builder who wants to configure a new site from scratch? Presumably, it is to put that site online at some point. And when they do so, they will desire that site to be fast.
The nice thing about example.settings.local.php (which we might want to rename to make this clearer, not sure) is that you simply copy/rename that one file to sites/default, uncomment 3 lines in settings.php, and you're good to go to start modifying things. And that's regardless of which D8 profile you start with. Versus having to dig around in whatever install profile the site is using to figure out if it did or did not enable caching by default, and then dig further to find out where all the settings are to turn it on in the event that it didn't. Versus add those 3 comment lines back in the prod settings.php, on every Drupal 8 site you build.
Comment #3
webchickThis is also the reason why I'm a bit mystified why this change wasn't done at the config get default value level and was instead done at the install profile level, but I digress.
Comment #4
fabianx commented+1 to #2
#3: Because we actually want to move the page_cache to a module and then the default config change does not work anymore, but installing that module by default in the profile does work.
Comment #5
David_Rothstein commentedThat right there is the tricky point, though. If you use settings.local.php during initial site building, you must take special steps (either changing settings.php, or not deploying settings.local.php, or whatever) when you push your site out to production for the first time. If you don't remember that and simply copy your files and database up to the production server (or if you don't have a separate production server and have been developing on the real server all along, as is certainly common) then settings.local.php will be used on your production site.
Personally, I am much more concerned that an advanced site builder (but not-so-advanced developer) using the Minimal profile would make that mistake, vs. forgetting to go to the Performance page and check the performance/cache settings before their site goes live. (The latter is something any advanced site builder, Drupal or not, is going to have a pretty good idea to do.)
Also, I just tried this out and if you do accidentally wind up using settings.local.php in production, you enter some kind of bizarro world. Because your site will have caching completely turned off, but if you go to the Performance page, all the checkboxes will tell you that caching is turned on. This is really confusing. Maybe it's a bug? (It's certainly different than the way settings.php overrides work in Drupal 7.)
Overall I am not convinced settings.local.php is a great solution for this particular demographic.
To clarify, I do think it's good that the default values of the performance-related settings are (mostly) on by default - that way, install profiles will usually just automatically have them on. I just think we should consider making the Minimal profile one of the rare ones that opts out of this.
Comment #6
berdirThat's a good point. The settings.local.php approach is specifically useful when using version control and/or having a proper deployment process. But trying to upload D8 over an FTP-like protocoll (sftp or whatever) is going to drive people insane anyway.
My original suggestion was to do the opposite of what we do now. Have an example settings.local.php for *production* because I think that's the better approach for real sites, enforcing that production settings are enabled, not the other way round.
Anyway, I agree that IMHO minimal should have those disabled, especially when page caching becomes a module. There are many other "useful" things that we explicitly don't enable there as well.
Different yes, but by design. Editing editable config will always only show you the actual configuration. Which makes sense. What doesn't is that we're missing an ability to tell the user that he has local overrides. Which is very annoying but not something we can change (we'd need to understand how forms are connected to config keys, we don't have that)
Comment #7
fabianx commentedI think we need to add a requirements check for when you use the null cache backend, but there are also legitimate use cases for that ...
Back to discussing a development toggle? Even if it needs a container rebuild?
Comment #21
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #22
smustgrave commentedSo I believe this can be closed out. With Drupal CMS and recipes I know the plan is to get rid of minimal and standard profiles and do some kind of hybrid and lets recipes handle the rest.