Development

Drupal configuration management — why config sync matters

Drupal configuration — content types, views, fields, roles — lives in the database. Config sync moves it to git. Here is why that changes everything.

The problem without config sync

A classic scenario: a developer makes changes in the development environment — adds a field, modifies a view, creates a new content type. Now this needs to go to production.

Without config sync the options are bad:

  • Make the changes manually in production (double work, error-prone)
  • Hope you remember exactly what you changed
  • Export the database from development and import it to production (which wipes production content)

What config sync is

Since Drupal 8, configuration can be exported from the database to YAML files. These files can be committed to git and synchronised between environments.

```bash # Export configuration to files drush config:export

# Import files into the database drush config:import ```

The result: all site configuration — content types, fields, views, roles, language settings, module settings — lives as YAML files in git, under version control.

What config sync covers

Covered:

  • Content types and their fields
  • Views
  • Taxonomy vocabularies
  • User roles and permissions
  • Module settings
  • Language and translation settings
  • Image styles
  • Text formats
  • Menus (structure, not content)

Not covered:

  • Content (nodes, taxonomy terms) — that stays in the database
  • Files and images — those are in the filesystem
  • User accounts

Workflow with config sync

`` development → git push → staging → git pull + drush cim → review → production → git pull + drush cim ``

  1. Make a change in the development environment (add a field, modify a view)
  2. drush cex — export the change to YAML
  3. git add config/ && git commit
  4. Staging: git pull && drush cim — change applies automatically
  5. Production: same

Compare this to WordPress where theme and plugin settings live in the database and syncing between environments is manual work.

Config split — different settings per environment

Some modules have settings that should differ between development and production. For example:

  • Development: devel module enabled, caching off
  • Production: Google Analytics enabled, devel module off

The config_split module lets you define environment-specific configurations that override the base configuration.

Common mistakes

Config import fails with a conflict — someone made manual changes in production. Fix: drush config:status shows the differences. Discuss who is right.

UUID conflict — entities whose UUID does not match. Happens when development and production have diverged. Fix: drush cex from production, merge in git, drush cim in development.

Config not exported before commit — developer made a UI change, forgot to run drush cex. Fix: add drush config:status check to the CI pipeline.

Summary

Config sync is the foundation of a professional Drupal workflow. Without it, every deployment is manual work and a source of errors. With it, configuration is auditable, recoverable, and shareable across the team.

If your Drupal project runs without config sync, let's talk about improving the workflow.

Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us