Drupal Configuration Management: Export, Import & Config Split richtig gemacht

Wer schon mal versucht hat, eine Drupal-Website professionell zu betreiben, kennt die Horrorgeschichte: Der Kunde hat auf der Live-Site einen neuen Content Type angelegt. Sie haben parallel lokal ein neues Modul konfiguriert. Beim Deployment überschreiben Sie versehentlich die Live-Config. Chaos.

Die Lösung: Drupal Configuration Management (seit Drupal 8). Endlich können wir Konfigurationen wie Code behandeln: versioniert, reviewbar, deploybar.

Aber wie nutzt man das System richtig? Und wann brauche ich Config Split? Hier ist mein Battle-Tested-Workflow aus 15 Jahren Drupal-Entwicklung.

Die Basics: Was ist Configuration Management?

In Drupal 8+ wird zwischen zwei Datentypen unterschieden:

1. Content (Nodes, Media, Taxonomy Terms) → Bleibt in der Datenbank
2. Configuration (Content Types, Views, Felder, Module-Settings) → Wird als YAML-Dateien exportiert

Das Geniale: Konfiguration kann jetzt aus der Datenbank in Dateien exportiert werden und umgekehrt.

Die wichtigsten Drush-Befehle

# Alle aktiven Configs aus der DB nach YAML exportieren
drush config:export
# Kurzform:
drush cex

# Alle YAML-Configs in die DB importieren
drush config:import
# Kurzform:
drush cim

# Status: Was ist anders zwischen DB und Dateien?
drush config:status
# Kurzform:
drush cst

Der Standard-Workflow (ohne Config Split)

1. Lokale Entwicklung

Sie bauen ein neues Feature (z.B. einen Content Type “Produkt”):

1. Legen den Content Type über die UI an
2. Exportieren die Config: drush cex
3. Git zeigt neue/geänderte YAML-Dateien im Ordner /config/sync/
4. Commit & Push

git status
# modified: config/sync/node.type.produkt.yml
# modified: config/sync/field.field.node.produkt.body.yml
git add config/sync/
git commit -m "feat: Add Product content type"
git push

2. Deployment auf Stage/Production

Auf dem Server:

git pull
drush config:import
drush cache:rebuild

Done. Das Feature ist live.

Das Problem: Unterschiedliche Umgebungen

Aber was, wenn Sie auf Development das Modul devel aktiviert haben wollen, auf Production aber nicht?

Wenn Sie jetzt drush cex machen, wird der Status von Devel mit exportiert. Beim drush cim auf Production würde Devel aktiviert werden. Nicht gut.

Lösung: Config Split.

Config Split: Konfigurationen pro Umgebung

Das Modul Config Split erweitert das Configuration Management um die Möglichkeit, unterschiedliche Config-Sets für verschiedene Umgebungen zu definieren.

Installation

composer require drupal/config_split
drush en config_split -y

Setup: Drei Umgebungen (Dev, Stage, Prod)

1. Ordnerstruktur anlegen

mkdir -p config/splits/dev
mkdir -p config/splits/stage
mkdir -p config/splits/prod

In Ihrer settings.php:

// Standard Config Sync
$settings['config_sync_directory'] = '../config/sync';

// Environment Detection
if (getenv('ENVIRONMENT') === 'dev') {
  $config['config_split.config_split.dev']['status'] = TRUE;
  $config['config_split.config_split.stage']['status'] = FALSE;
  $config['config_split.config_split.prod']['status'] = FALSE;
}
elseif (getenv('ENVIRONMENT') === 'stage') {
  $config['config_split.config_split.dev']['status'] = FALSE;
  $config['config_split.config_split.stage']['status'] = TRUE;
  $config['config_split.config_split.prod']['status'] = FALSE;
}
else {
  // Production
  $config['config_split.config_split.dev']['status'] = FALSE;
  $config['config_split.config_split.stage']['status'] = FALSE;
  $config['config_split.config_split.prod']['status'] = TRUE;
}

2. Config Splits über die UI anlegen

Gehen Sie zu: /admin/config/development/configuration/config-split

Split: Development

• Label: Development
• Folder: ../config/splits/dev
• Complete Split: Module auswählen
  • devel
  • stage_file_proxy (lädt Files von Production nach, statt sie lokal zu haben)
  • webprofiler
  • views_ui
  • field_ui

Split: Stage

• Label: Stage
• Folder: ../config/splits/stage
• Hier oft ähnlich wie Dev, aber vielleicht ohne Devel

Split: Production

• Label: Production
• Folder: ../config/splits/prod
• Complete Split: Modules
  • google_analytics (nur auf Prod tracken!)
  • Produktions-spezifische Dienste

3. Export mit Config Split

Sobald Config Split eingerichtet ist, ändert sich der Workflow leicht:

drush config:export

Das war’s. Config Split übernimmt automatisch die Aufteilung.

Sie werden jetzt sehen:

• Gemeinsame Configs landen in /config/sync/
• Dev-only Configs landen in /config/splits/dev/
• Prod-only Configs landen in /config/splits/prod/

4. Import mit Config Split

Auf jedem Environment:

drush config:import

Je nachdem, welcher Split in der settings.php aktiv ist, werden die richtigen Configs aktiviert.

Best Practices aus der Praxis

1. Nie auf Production Konfigurationen ändern

Die Live-Site sollte immer nur Configs importieren, nie exportieren.

Workflow:

• Alle Config-Änderungen lokal machen
• drush cex
• Git Commit
• Deployment auf Stage → Test
• Deployment auf Prod

2. Config Import in Deployment-Script

Mein Standard-Deploy-Script (für CI/CD):

#!/bin/bash
git pull
composer install --no-dev
drush updatedb -y         # Database Updates
drush config:import -y    # Config Import
drush cache:rebuild       # Cache leeren

3. Kollaboration im Team

Wenn mehrere Entwickler parallel Config-Änderungen machen:

# Nach git pull
drush config:import
# Jetzt eigene Änderungen machen
drush config:export
git add config/
git commit -m "feat: Add new view for products"

Falls es beim Import zu Merge-Konflikten kommt (zwei Leute haben dieselbe View bearbeitet), müssen die YAML-Dateien manuell gemerged werden. YAML ist zum Glück gut lesbar.

4. Config Read-Only auf Production

Um sicherzugehen, dass niemand auf Production versehentlich Configs ändert:

// settings.production.php
$settings['config_readonly'] = TRUE;

Dann wirft Drupal einen Fehler, sobald jemand etwas über die UI speichern will.

Häufige Fehler und wie man sie vermeidet

Fehler 1: UUID-Konflikte

Problem: Sie importieren eine Config, die eine UUID referenziert, die es nicht gibt.

Lösung: Niemals Configs zwischen komplett unterschiedlichen Sites kopieren. Wenn doch, UUIDs anpassen oder besser: Features-Module nutzen.

Fehler 2: Partial Imports

Problem: Sie importieren nur einzelne Configs mit drush config:import --partial.

Lösung: Nur in Notfällen nutzen. Es kann zu inkonsistenten Zuständen führen. Besser: Immer alle Configs auf einmal importieren.

Fehler 3: Config Split Status vergessen

Problem: Sie haben lokal den Production-Split aktiv und exportieren versehentlich die falsche Config.

Lösung: Immer drush cst (config:status) vor dem Export checken. Oder noch besser: Environment-Detection in settings.php (siehe oben).

Erweiterte Patterns: Conditional Splits

Manchmal will man Configs nicht nach Environment splitten, sondern nach Feature-Flags.

Beispiel: Ein neues Payment-Gateway, das nur für Beta-User aktiv sein soll.

// settings.php
if (getenv('FEATURE_NEW_PAYMENT') === '1') {
  $config['config_split.config_split.new_payment']['status'] = TRUE;
}

So kann man Features graduell ausrollen, ohne Code-Branches.

Fazit

Drupal Configuration Management war für mich der Gamechanger in Drupal 8+. Endlich kann ich Websites deployen wie moderne Apps: Mit Git, Code-Reviews und automatisierten Tests.

Config Split macht das Ganze praxistauglich für echte Projekte mit Dev/Stage/Prod-Umgebungen.

Mein Rat:

1. Richten Sie Config Management ab Tag 1 ein
2. Nutzen Sie Config Split für alles, was auch nur ansatzweise umgebungsspezifisch ist
3. Deployen Sie nie wieder manuell Configs über die Drupal-UI

Ihre Deployments werden schneller, sicherer und nachvollziehbarer.

Fragen zu Configuration Management oder Config Split? Ich helfe Ihnen gerne bei der Einrichtung eines professionellen Drupal-Deployment-Workflows. Kontakt aufnehmen