Settings That Can be Overridden in settings.local.php

There are a ton of things you can override in your settings files, but knowing what to type can be a little tricky.

A few examples are given in default.settings.php in the "Configuration overrides" section. The examples are:

I use the first one pretty often to add something like "(DEV)" to the end of the site name to help me know which site I'm looking at. The other ones though, I probably wouldn't override in my settings file.

There are also a handful of more useful ones in the relatively new "example.settings.local.php" file. You can browse that for yourself. For the next little bit, I'm going to walk you through a few different kinds of overrides (what they are and where to find them) and you should be able to take it from there.

Some of the most common overrides I use are:
* Database credentials (Each environment is usually different)
* Caching (Force caching on production, never cache on dev or staging)
* Theme Debugging (Disabled on production and staging, Enabled on dev)
* Service API Keys (ie: Mailchimp, Google Analytics, etc. Use live key on production, and a test key - or no key - on dev and staging)

Let me show you where to find each of those types of configuration.

Where to Find Configuration Settings That Can Be Overridden

The available configuration options are found in module schema files at paths like "modulename/config/schema/modulename.schema.yml".

For the system settings, like caching, they'll be in "/core/modules/system/config/schema/system.schema.yml".

If we open that up you'll see that it's a standard .yml file. I won't go into detail on .yml files at this point, I'll just show you how to navigate this file to find the config values that you need.

System Configuration

At the top of this file, you'll see "system.site", this might look familiar since we've already talked about it twice when discussing how to override the site name. The config override we used was $config['system.site']['name'] = 'My Drupal site';, so we see where the "system.site" portion came from, and if you look down the hierarchy a little bit, you'll see "name" underneath "system.site".

Let's break this down real quick.

When putting your config override in your settings file, you'll start with the top-most level in the schema hierarchy, then you'll look under the "mapping" level (don't include "mapping", it's just there to say what can be mapped under a given option) and use the option you want as your second parameter. In the case of the site name, that would give us $config['system.site']['name']. Now, what we put to the right of the "=" depends on what type of data is used.

"Name" uses a "label" (which is text), "mail" accepts an email address, "mail_notifications" accepts a string. So, those are examples of text values. But there's also "admin_compact_mode" which is boolean, so it accepts TRUE or FALSE. And "weight_select_max" which accepts an integer.

CSS Aggregation

Sometimes, you'll have to dig down further than just one level in the hierarchy. Let's tell our development site to never aggregate CSS files so that we can debug our theme easier.

(Right now if I inspect an element on the page, you'll see that the css is being served from the "/sites/default/files/css" directory. This indicates that the css is being aggregated. Let's override that.)

Back in our system.schema.yml file, I'll scroll down to the "system.performance" section, and under mapping, we'll find the "css" section. Then under the css mapping we'll find "preproces", which is the type "boolean". So, to disable css aggregation, we can put the following in our settings file.

Now, we need to rebuild the cache so that our new setting can take effect.

With that done, we can go back to the site and refresh the page. And then, when we inspect an element, you'll see that the css is being served from the Bartik theme directory. So CSS aggregation is disabled!