Thorsten: /* Content Sync */

2026-08-18T16:42:33Z

Content Sync

← Nächstältere Version		Version vom 18. August 2026, 16:42 Uhr
Zeile 20:		Zeile 20:
	Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.		Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
	<pre>		<pre>
	[[drush]] content-sync:export		drush content-sync:export
	drush content-sync:import		drush content-sync:import
	</pre>		</pre>

Thorsten am 18. August 2026 um 16:38 Uhr

2026-08-18T16:38:56Z

← Nächstältere Version		Version vom 18. August 2026, 16:38 Uhr
Zeile 20:		Zeile 20:
	Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.		Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
	<pre>		<pre>
	drush content-sync:export		[[drush]] content-sync:export
	drush content-sync:import		drush content-sync:import
	</pre>		</pre>

Thorsten am 18. August 2026 um 15:39 Uhr

2026-08-18T15:39:47Z

← Nächstältere Version		Version vom 18. August 2026, 15:39 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
	==Konfiguration exportieren (YAML)==		==Konfiguration exportieren (YAML)==
	Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:		Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
Zeile 85:		Zeile 86:

	'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.		'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Thorsten: /* Entscheidungshilfe */

2026-08-18T15:35:00Z

Entscheidungshilfe

← Nächstältere Version		Version vom 18. August 2026, 15:35 Uhr
Zeile 49:		Zeile 49:
	! Methode !! Für !! Aufwand		! Methode !! Für !! Aufwand
	\|-		\|-
	\| Default Content \|\| Demo-Inhalte mit Modul ausliefern \|\| gering		\| [[Default Content]] \|\| Demo-Inhalte mit Modul ausliefern \|\| gering
	\|-		\|-
	\| Content Sync \|\| Staging→Live, identische Site-Struktur \|\| gering–mittel		\| Content Sync \|\| Staging→Live, identische Site-Struktur \|\| gering–mittel

Thorsten: Die Seite wurde neu angelegt: „==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/…“

2026-08-18T14:58:34Z

Die Seite wurde neu angelegt: „==Konfiguration exportieren (YAML)== Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert: <pre> drush config:export --destination=/pfad/zum/backup/config </pre> ==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/…“

Neue Seite

==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==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: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
drush content-sync:export
drush content-sync:import
</pre>
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: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
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 <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! 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 (<code>uid</code>), 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. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-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 <code>uid</code>-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 <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-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 <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.

Drupal - Versionsgeschichte

Thorsten: /* Content Sync */

Thorsten am 18. August 2026 um 16:38 Uhr

Thorsten am 18. August 2026 um 15:39 Uhr

Thorsten: /* Entscheidungshilfe */