config-management

Environment

All commands via ssh web drush. Config sync directory: config/sync/ (relative to project root).

Config vs State vs Settings — decide BEFORE storing anything

Drupal has three storage mechanisms; picking the wrong one causes deploy bugs, security leaks, or data loss. Decide with this table:

Question	Use	API
Site-building decision, same across environments?	Config	config.factory (inject)
Runtime data that changes frequently (timestamps, counters, flags)?	State	\Drupal::state()
Environment-specific or secret (API keys, credentials, salts)?	Settings	Settings::get() + settings.php
Admin manages multiple named instances via UI, or needs dependency tracking?	Config entity	—
A few key-value module settings?	Simple config	—

The two classic mistakes:

• A secret in config → exported to YAML, committed to git. Security leak. Store in $settings[...] (settings.php / env var) instead.
• Runtime data in config (last sync time, counters) → drush cex shows permanent diffs and the next deploy overwrites production state. Use State.

Config CAN differ per environment via overrides ($config[...] in settings.php) — the stored default stays shared, the override layers on top at runtime.

Reading vs writing config

$value = $config_factory->get('system.site')->get('name');          // active value (overrides applied)
$raw = $config_factory->get('system.site')->getOriginal('name', FALSE); // stored value, no overrides
$config_factory->getEditable('system.site')->set('name', 'X')->save();  // write (ignores overrides)

Do not use getEditable() just to read, and never save a config object obtained with overrides applied — overrides are read-only.

Modifying config you do not own

Never write directly into another module's config keys. Use third-party settings — they are namespaced and cleaned up on uninstall:

$content_type->setThirdPartySetting('my_module', 'custom_flag', TRUE)->save();