Aktuell: Markdown (2021/12/05)
Um bereits für Drupal-9 bereit zu machen sollte man bereits jetzt das Upgrade auf Version 8.x-2.0 erwägen. Leider sind die Settings nicht ganz kompatibel
Deswegen:
- Durch die Textformate durchgehen /admin/config/content/formats und "überall Markdown deaktivieren*
- dann im Drupal-System: composer require michelf/php-markdown
- neues Markdown installieren (derzeit "markdown-8.x-2.0-rc2")
- /update.php (evtl. Fehler erst einmal ignorieren
- Markdown prinzipiell vorkonfigurieren /admin/config/content/markdown (und php-markdown als "default" setzen Danach kann in den Textformaten wieder das Markdown aktiviert werden als Filter
Trouble-Shooting: wenn das neue Markdown bereits installiert ist, kommt man an die alten Textformatierungen nicht mehr ran, wegen unvollständiger Konfiguration, dann hilft es in markdown/markdown.module um die Zeile 180 herum "if (!isset($lib) || !get_class($lib)) return;" einzufügen, da die Variable $lib da evtl nicht definiert ist.
2. Migration Online
Ansonsten hat auf der Weboberfläche die Online Migration enorm zugelegt und ich werde mich nun darauf beziehen:
1) Zuerst muss man die Grundinstallation für Drupal 8 auf der Webseite durchführen und die Zugangsdaten zu einer leeren DB angeben (es sei denn die stehen bereits in der settings.php)
2) Danach Aktivierung des migrate_tools Modul (Unter "Extend"/"Erweitern" aktiviere "Migrate Drupal UI" (Und Module der bisherigen Installation, die im Upgrade-Status-Monitor grün angezeigt wurden)
3) Nachdem man auf meine.site.de/upgrade gegangen ist, wird einem eine übersichtliche Seite angeboten.
Fix noch die Zugangsdaten zur alten drupal7-Datenabnk eingegeben und den Pfad zur alten drupal7 Installation mit dem sites Verzeichnis, dann kann es losgehen.
WICHTIG: Erst einmal nur die Module bereitstellen, für die auch Daten aus der alten Site übernommen werden sollen. Maintenance-Module, Themes, reine Export-Tools usw. erst einmal weglassen.
Nach dem ersten Weiter (Review Upgrade), sieht man eventuell noch Fehler in einzelnen custom Modulen, die sollte man fixen, ersetzen, oder erst einmal weglassen.
UPGRADE-Fehler
Bei mir gab es diverse Fehlermeldungen, hier mit meinem workaround/Lösung.
- "The "comment" entity type does not exist." => vorab anschalten Modul "comment"
- "Attempt to create a field taxonomy_vocabulary_1 that does not exist on entity type node." => vorab Modul anschalten "taxonomy"
- "The "block_content" entity type does not exist." => "block" war bereits angeschaltet, es fehlte noch "custom_block"
- "The "iframe_widget_urlwidthheight" plugin does not exist." => mein eigenes Modul "iframe", Migrations um WidgetMap erweitert
enable: comment, taxonomy, custom_blocks, views, views_ui, field, field_ui, iframe (und alle Field-Type, die man so braucht)
5 verbliebene Fehler
- "No routes found for "/frontpage"": das Mapping welche node/NN die Startseite für / (Bzw internem Alias /frontpage) machen sollen muss per Hand korrigiert werden (Konfiguration - Website-Einstellungen = administration => configuration => system => basic site settings), oder via Views-Modul und speziellen frontpage-View)
ACHTUNG mit Mysql-8
Es gibt Probleme bei der Migration von 7 nach 8.9 da er die "system" table abfragen will nach der vorherigen Versionsnummer aber scheitert, da "system" mitlerweile ein reserverd-word ist. Es hilft den Tabellen-Namen zu quoten. Keine Ahnung warum das in 8.9.20 nicht standardmässig mit Backticks gequotet wird. Lösung/Workaround siehe https://www.drupal.org/project/drupal/issues/3057305#comment-14354731
Artikel mittlerweile veraltet, @TODO Stand: 2018/12
Im Gegensatz zu komplizierten Sites mit vielen Modulen, die häufig erst für Drupal-7 verfügbar sind (siehe: Migration Drupal-6 nach Drupal-7), können wir für einfache Sites gleich den Schritt nach Drupal-8 wagen.
1. Vor der Migration
Überprüfe vorher alle zusätzlichen Module, ob sie wirklich wichtig sind, ansonsten deaktiviere sie temporär oder für immer.
Wichtig: Views-2 Module macht Probleme, also unbedingt vorher in Drupal-6 schon auf das Views-3 Modul umsteigen.
drush dl ctools
drush en ctools
drush dl views-6.x-3.x-dev
Dann über den Admin -> Ansichten : die einzige oder die wenigen Ansichten (Views) kurz editieren und den Pager anpassen und speichern (siehe: "Pager Issue" ).
Drush hängt leider in der Entwicklung seiner Plugins der schnellen Release-Abfolge bei 8.X immer hinterher. Die aktuell letzte vollständige Unterstützung gibt es bis 8.2.x
3. OLD - Migration mit drush
Drush hängt leider in der Entwicklung seiner Plugins der schnellen Release-Abfolge bei 8.X immer hinterher. Die aktuell letzte vollständige Unterstützung gibt es bis 8.2.x
- Zuerst eine d8-Site aufspielen, ohne irgendwas zu konfigurieren. (Vorher eine passende leere Datenbank anlegen)
drush site-install standard --db-url=mysql://dbuser:dbpassword@localhost/dbname --sites-subdir=mein.host.name --locale=de
OLD: Wir brauchen nun das "migrate_update":https://www.drupal.org/project/migrate_upgrade Modul for drush , und:
drush dl migrate_tools
drush dl migrate_plus
drush dl migrate_upgrade
drush en migrate_tools migrate_upgrade
NEW:
php composer.phar require drupal/migrate_tools
php composer.phar require drupal/migrate_upgrade
- Nun kommt die geniale Migration direkt aus der Drupal-6 Datenbank in die neue Drupal-8 Site
drush migrate-upgrade --legacy-db-url=mysql://db6user:db6pass@localhost/db6db --legacy-root=http://mein.host.name
Die Fehler sollte man sich merken, um das später kontrollieren zu können.
Ansonsten steht nun an, die Webseite aufzurufen und die Text-Filter und Image-Displays anzupassen
drush en libraries markdown language locale
"locale" wird benötigt, damit die Oberfläche auch in Deutsch dargestellt werden kann.
4. Besonderheit nginx und Bilder
Zuerst große Verwirrung: Im neuen Drupal-8 werden keine Bilder angezeigt. Mist(!) - stundenlang rumgedoktort ohne Erfolg. Nachdem ich eine Nacht drüber geschlafen hatte, habe ich es noch einmal mit einer frischen Drupal-8 site (ohne irgendwas zu migrieren) und einem einzelnen Artikel mit Bild probiert. Auch dort wurde kein Bild angezeigt.
Lösung: Der Fehler war in der nginx Konfiguration zu suchen, da in der dortigen drupal.conf eine "Abkürzung" für statische Ressourcen unter /sites eingetragen war, das nginx die selber ausliefern durfte. In Drupal-8 werden die verschiedenen image-styles aber erst bei Bedarf (zur Laufzeit) generiert, müssen also unbedingt auch ins Routing via index.php?q= umgelenkt werden.
# Fighting with ImageCache - or Drupal-8 dynamic image-style-generation
location ~ ^/sites/.*/files/(imagecache|styles)/ {
try_files $uri @rewrite;
}
Wenn das Bild also bereits generiert wurde, darf es auch ausgeliefert werden, andernfalls geht er ins @rewrite und somit zum Routing via index.php