Migration Drupal-6 nach Drupal-7

Ich betreibe mittlerweile einige Drupal-Installationen, wovon die meisten noch mit Drupal-6 laufen.

Für ein Upgrade steht nun Drupal-7 und Drupal-8 zur Verfügung und es gibt sowohl von 6-nach-7, als auch für 6-nach-8 einen Migrationsweg.

(Für Drupal 6 / Drupal 7 nach 8 Migration )

1. Vor einem Upgrade sind nun die Verfügbarkeit von zusätzlich genutzten Modulen zu prüfen.

(Module die nach 2016 nicht mehr aktualisiert wurden, sind aussortiert)

Veraltete Module (<2016)

Tabelle Stand: 2020-12-23

Ohne Zusatzmodule würde ich direkt zu Drupal 8 wechseln. Die Modulunterstützung wird immer besser (die API hat sich im zu 6-nach-7 nun wieder geändert, da kommt man als Modul-Entwickler kaum hinterher)

Aber auch für Drupal 7 werde ich auf einige Module verzichten müssen:

• “Nodewords” werde ich durch “Metatag” ersetzen, auch wenn es derzeit nur für die Startseite benutzt wird und die Verwendung von meta-description und meta-keywords nicht mehr so relevant wie früher ist.
• Alle bisherigen Redirect Module ersetzen durch “Redirect”, zum individuellen erstellen von zusätzlichen Kurz-URLs
• Verzichten auf: onepageprofile, path_redirect, search_ranking, statistics_advanced (wurde eh nie voll genutzt), statspro, taxonomy_breadcrumb

2. Test-Migration - Nebenwirkungen

In der Anleitung zum Upgrade Drupal-6 to Drupal-7 wird empfohlen, vor einem Upgrade alle contrib-Module zu deaktivieren, zuerst den Core zu aktualisieren und erst dann die Module der Reihe nach wieder zu aktivieren.

1) Ergebnis: Die Inhalte waren da, aber die Inhalte wurde falsch angezeigt. Module “language_sections”, “typogrify” aktivieren brachte leider auch nicht den alten Zustand. Er hatte alle Eingabeformate vergessen.

2) Views Modul braucht in Drupal 7 das “CTools” Modul, leider benutzt das Views Modul einfach eine ctools Funktion ohne die Abhängigkeiten richtig zu deklarieren.
Empfehlung: Alle Module die es gibt gleich aktiviert lassen, um die Einstellungen (Konfiguration) nicht zu verlieren. Alle alten/veralteten/abzuschaltenden Module vorher deaktivieren. UND bereits in Drupal 6 das “ctools” Modul aktivieren (erspart einem von Hand im php-Code das Modul temporär per Hand zu requiren.)

Ebenfalls musste ich erkennen, dass ich selber mit meinem Modul Iframe -zwar mit Drupal-7 kompatibel bin (dort benutze ich nicht mehr CCK, sondern das core Field Modul) allerdings fehlt noch eine cck-Migration des bisherigen Felder-. (2017: Migration gibt es mittlerweile auch)

Überlegung Drupal-8: Hauptpunkt der fehlt ist die Migration von Views (2.x) aus Drupal6/7 nach Drupal 8, obwohl Views in Drupal-8 nun ein internes Modul ist. (Es existiert ein migrate-Update-Pfad von Views 6.x-3.x nach Drupal-8, man muss also erst in 6 die Version hochziehen ( [Pager Issue 1090098]:https://www.drupal.org/node/1090098 )

3) Migration der ehemaligen CCK-Felder

• Bilder konnten als Einzel, als auch als Mehrfach-Bilder migriert werden. Da “imagecache” nun im Core ist, muss man die Darstellung der Bilder nun einzeln via “Manage Fields” in jedem einzelnen Inhaltstyp separat einstellen.
• Feld “Text2” hat er als CCK-Migrate nicht korrekt erkannt, er wollte es zu einem IFrame machen anstatt zu einem Textfeld.
• Ohne Für-Tun ist zumindest das Feld Iframe-URL (als Hauptbestandteil) erhalten geblieben.

Upgrade 6 nach 7

Mit “drush” geht es leider derzeit nicht mehr (mit drush6 soll es noch gegangen sein).

Hier empfehle ich:

• die Datenbank in drupal6 bereinigen:
  1. keine Tabellen außerhalb (mit prefix) sondern alle direkt in der DB;
  2. unnötige Module abschalten.
  3. drupal6 und alle Module auf dem aktuellsten Stand
• dann die ganze Datenbank-6 in eine Datenbank-7 zu kopieren
• in drupal7 die settings passend zur neuen Datenbank7 einzustellen
• dann ein oder mehrmahls http://site/update.php aufrufen (evtl dazu zum Upgrade in der settings.php einstellen: $update_free_access = TRUE;

drush_d7 dl admin_menu cck ctools iframe languageicons language_sections redirect token views markdown
drush_d7 en language_sections iframe variable content_migrate cck admin_menu ctools markdown languageicons views views_ui token redirect file image
drush_d7 updatedb

• Dann die “Content → Text filter” nacheditieren, um Markdown u LanguageIcons wieder zu aktivieren
• /admin/structure/content_migrate Migration der bisherigen CCK-Felder als neue “fields”

Angekommen bei Drupal7 - Probleme und Lösungen

CKEditor lief nicht mehr. Früher sagte man welche Felder den CKEditor zeigen sollten und welche nicht. Jetzt geht er rein auf das Eingabeformat los.

• Alle Einstellungen waren weg:
  1. ckeditor unter sites/all/libraries/ckeditor ablegen, und Pfade unter “CK→Globale EInstellungen” anpassen auf “%l/ckeditor”
  2. CKEditor ist nun modular: alle Plugins müssen einzeln im Ordner libraries/ckeditor/plugins landen (Download unter: [ckeditor.com/addons/plugins/all](http://ckeditor.com/addons/plugins/all)
  3. Wichtige Plugins ohne die die Buttons zwar da sind aber keine Funktionalität: clipboard, colorbutton, find, font, indent, indentblock, indentlist, justify, pastefromword, selectall
• Benutzer-Profil-Felder mit Textarea hatten jetzt keinen CKEditor mehr, da dort gar kein Eingabeformat pflegbar ist (Profile fields)
  1. Wenn html im Profil Feld steht, dann wird es auch angezeigt, soweit gut
  2. Um aber auch dem Nutzer die Möglichkeit zu geben mit CKEditor die Felder zu pflegen war ein kleines eigenes Modul nötig, dass die entsprechende hook-Funktion benutzt um das Formular vorab entsprechend zu präparieren:

     function sts_form_alter(&$form, &$form_state, $form_id) {
         switch($form_id) {
             case 'user_profile_form' :
                 $account = $form['#user'];
                 if (isset($form['Persönliches'])) {  # bei uns nur die Felder aus dem Tab "Persönliches"
                     #drupal_set_message(print_r($form['#user'], TRUE), "info");
                     foreach($form['Persönliches'] as $pkey => $pval) {
                         if (preg_match('#^profile_#', $pkey) && $pval['#type'] == 'textarea') {
                             $form['Persönliches'][$pkey]['#base_type'] = 'textarea';
                             $form['Persönliches'][$pkey]['#type'] = 'text_format';
                             $form['Persönliches'][$pkey]['#format'] = filter_default_format($account);
                             $form['Persönliches'][$pkey]['#wysiwyg'] = TRUE;
                             ckeditor_element_info_alter($form['Persönliches'][$pkey]);
                         }
                     }
                 }
                 break;
             case 'forum_node_form' :
                 # hier sollte im EDIT-Modus das Body-Feld nicht nur 20 Zeilen (default) zeigen, sondern mehr
                 $form['body']['und'][0]['#rows'] = 60;
                 break;
             default:
                 #drupal_set_message($form_id, "info");
                 break;
         }
     }

Social Media sharethis Modul liess sich nicht mehr administrieren und Layout war auch verwürfelt

• Nach einigen Versuchen via CSS und Variablen-Hacking direkt im Javascript vom Modul und in der Datenbank, wurde das Modul nun ersetzt durch das Module [shariff](https://www.drupal.org/project/shariff) - die dazugehörige Library von [c’t Heise – Shariff](http://ct.de/-2467514) packen wir wieder unter libraries! git clone https://github.com/heiseonline/shariff.git sites/all/libraries/shariff
• Pinterest Button kann so leider nicht angeboten werden da die sharer-Url von Pinterest eine pinterest-Seite mit https öffnet, um dort die Bilder der eigenen Seite anzuzeigen. Moderne Browser lehnen dann aber Bilder von http-Seiten ab. Alternative, man muss sich auch noch jährlich ein SSL-Zertifikat besorgen.