Drupal: Unterschied zwischen den Versionen

Aus Dokument
Zur Navigation springen Zur Suche springen

Thorsten (Diskussion | Beiträge)

3 Benutzergruppen
70 Bearbeitungen
VisuellWikitext
// via Wikitext Extension for VSCode
 
Markierung: Manuelle Zurücksetzung
 
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
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).
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)==
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>


Drupal ist ein freies Content-Management-System (CMS) und Framework.  
==Inhalts Backup==
==Drupal ist Installieren auf Ubuntu 24.04==
===Inhalte als CSV/XLSX===
===Schritt 1: Nginx, Postgrsql und PHP installieren===
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.


# Installieren Sie Nginx, Postgrsql und PHP mit dem folgenden Befehl:
====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
<pre>
sudo -u postgres -i
drush content-sync:export
createdb -E UTF8 -O thorsten drupall
drush content-sync:import
psql -d drupall -c "CREATE EXTENSION postgis;" # Erweiterung hinzufügen
</pre>
psql -d drupall -c "CREATE EXTENSION hstore;" # Erweiterung hinzufügen
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.
psql -d drupall -c "ALTER TABLE geometry_columns OWNER TO thorsten;" # Rechte setzen
psql -d drupall -c "ALTER TABLE spatial_ref_sys OWNER TO thorsten;" # Rechte setzen


exit
====Migrate API====
sudo apt update
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.
sudo apt install nginx php-fpm php-pgsql php-xml php-curl php-gd php-mbstring php-xmlrpc php-zip php-intl php-json php-opcache -y
* 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>
</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.


===Schritt 2: Drupal herunterladen und konfigurieren===
====Entscheidungshilfe====
# Wechseln Sie in das Webroot-Verzeichnis:
{| class="wikitable"
<pre>
! Methode !! Für !! Aufwand
cd /var/www/html
|-
</pre>
| [[Default Content]] || Demo-Inhalte mit Modul ausliefern || gering
# Laden Sie die neueste Version von Drupal herunter:
|-
<pre>
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
sudo wget https://www.drupal.org/download-latest/tar.gz
|-
</pre>
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
# Entpacken Sie das Archiv:
|-
<pre>
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
sudo tar -xvzf tar.gz
|}
</pre>
 
# Benennen Sie das Verzeichnis um:
====Benutzerdaten ausschließen====
<pre>
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.
sudo mv drupal-11.0.6 drupal
 
</pre>
'''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).


# Erstellen Konfigurationsdatei settings.php:
'''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>
<pre>
sudo cp /var/www/html/drupal/sites/default/default.settings.php /var/www/html/drupal/sites/default/settings.php
process:
sudo chmod 666 /var/www/html/drupal/sites/default/settings.php
  uid:
    plugin: default_value
    default_value: 1
</pre>
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.


===Schritt 3: Nginx-Konfiguration===
'''JSON:API''':
<pre>
* 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>
sudo apt-get install nginx
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
sudo rm /etc/nginx/sites-enabled/default
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.
</pre>
# Erstellen Sie eine neue Konfigurationsdatei:
<pre>
sudo nano /etc/nginx/conf.d/drupal.conf
</pre>
# Fügen Sie den folgenden Inhalt ein:
<pre>
server {
    listen 80;
    server_name localhost;
    root /var/www/html/drupal;
    index index.php index.html index.htm;
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    }
    location ~ /\.ht {
        deny all;
    }
}
</pre>


'''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).
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Aktuelle Version vom 18. August 2026, 16:42 Uhr

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)

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.



Hinweis


Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).



Abgerufen von „https://mediawiki.wissen-ahrensburg.de/index.php?title=Drupal&oldid=615“