Drupal

Konfiguration exportieren (YAML)

Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:

drush config:export --destination=/pfad/zum/backup/config

Inhalts Backup

Inhalte als CSV/XLSX

Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.

Inhalte auf eine andere Drupal-Site übertragen

Default Content

Modul:

drush en default_content

Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.

• Export:

  drush default-content-export node <nid>

  bzw.

  drush default-content-export-module <modulname>

  schreibt die Dateien nach MODULENAME/content/node/.
• Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook hook_install bzw. default_content_deploy).
• Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

Content Sync

Modul: content_sync. Funktioniert wie drush config:export/import, aber für Content-Entitäten.

drush content-sync:export
drush content-sync:import

Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

Migrate API

Module: migrate_plus, migrate_tools. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.

• Migration-Definition als YAML (migrate_plus.migration.*.yml) mit drei Teilen:
  • source – z. B. url (JSON:API der Quellsite), csv, sql (direkter DB-Zugriff)
  • process – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
  • destination – z. B. entity:node
• Ausführen:

drush migrate:import migration_id drush migrate:status drush migrate:rollback migration_id

Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

Core JSON:API

Kein Zusatzmodul nötig, nur Core-Modul jsonapi aktivieren.

• Alle Artikel:

  GET /jsonapi/node/article

  (Pagination über page[offset]/page[limit])
• Einzelner Node:

  GET /jsonapi/node/article/{uuid}

• Referenzen mitladen:

  GET /jsonapi/node/article?include=field_tags,uid

• Anlegen auf Zielsite:

  POST /jsonapi/node/article

  mit Bearer-Token oder Basic-Auth-Berechtigung.
• Eignet sich als Quelle für eine Migration (siehe Migrate API, source: plugin: url) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

Entscheidungshilfe

Methode	Für	Aufwand
Default Content	Demo-Inhalte mit Modul ausliefern	gering
Content Sync	Staging→Live, identische Site-Struktur	gering–mittel
Migrate API	große/strukturell abweichende Sites, wiederholbare Importe	hoch
JSON:API	Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle	gering (aber manuell)

Benutzerdaten ausschließen

Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (uid), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

Views Data Export: unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

Default Content: Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.

• Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. uid: 1), oder
• Nach dem Export das uid-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
• Per hook_default_content_export_alter() das uid-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

Content Sync: Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das uid-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

Migrate API: am saubersten steuerbar – im process-Mapping das Quellfeld uid einfach nicht mappen oder fix auf einen Default-Wert setzen:

process:
  uid:
    plugin: default_value
    default_value: 1

Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

JSON:API:

• Beim Abruf per Sparse Fieldset das uid-Feld weglassen und nicht in include aufführen:

  GET /jsonapi/node/article?fields[node--article]=title,body,field_tags

• Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert /jsonapi/user/user ohnehin nichts.
• Beim Anlegen (POST /jsonapi/node/article) die uid-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

Empfehlung: Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche uid/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.