Content and Configuration Management
Two kinds of change
Drupal separates content (nodes, terms, users, files) from configuration (YAML objects such as content types, views, and fields). Configuration management moves config between environments using export/import, typically with drush config:export and drush config:import, backed by a sync directory. Content is migrated separately with modules or Drush, not by config sync.
The workflow
Make changes in a development environment, export config to the sync directory, commit it, then import in staging and production. Never edit exported YAML by hand and never import over active config without reviewing differences. Use drush config:status to detect drift and drush config:import --diff (or the UI) to preview.
Traps to watch
- UUIDs: config has UUIDs; importing config from a different site can conflict.
- Dependencies: importing a view that references a missing field fails; order matters.
- Content in config: views, blocks, and menus are config, but their content (menu links, block placements with content) may not travel.
- Overrides: settings.php overrides are not exported.
- Deleting config: removing a config file and importing deletes that config and may delete data.
Worked example
A field was added in production directly. Exporting from dev and importing to production will not automatically remove the stray field; you must delete it in the source environment, export, and import. Rule of thumb: the sync directory is the source of truth; make all config changes where you export, never in production.