Suche Upgradeempfehlungen einer existenten Drupal7 Site auf 9/10?

Hi Dennis,
Grundsätzlich ist es eine gute Idee, die alte Installation zu bewahren, um noch mal nachsehen zu können.
Eine schlechte Idee ist es, die Installationen mit Unterpfaden aufzurufen.
Ich würde da immer mit Subdomains arbeiten.

Also lasse Deine Installation auf der bisherigen Domain, bis Du mit der Migration durch bist.
Dazu legst Du einen physikalischen Ordner z.B. drupal9 parallel zur D7 Installation ein und dort installierst Du mit Composer.
Erstelle dazu beim Hoste reine Subdomain, die z.B. neu.deinedomain.de heißt und auf das Verzeichnis /deinpfad/drupal9/web gemappt wird.
Das ist eine neue Eigenschaft, dass die Dateien Deiner Installation nicht unter drupal9 sondern drupal9/web liegen.
Natürlich brauchst Du dazu auch eine neue Datenbank.

Später kannst Du dann die Subdomain old.deinedomain.de anlegen und auf das physikalische Verzeichnis der Drupal 7 Installation mappen.
Denke aber dran, einen Verzeichnisschutz auf diese Subdomains zu legen, damit Google nicht seine neugierige Nase auf diese Installationen richtet (wenn man sich das wünscht, dauert es Wochen, wenn nicht, passiert es gleich ;-) ). Weil Du willst ja nicht, dass Kunden später noch Seiten über old.deinedomain.de/xy finden.

In die neue Installation kannst Du dann Deine Inhalte übertragen. Ich mache das mit einem View-Export ins CSV-Format auf der alten Version und mit Feeds-Import in die neue Installation.
Oder händisch, wenn es nur ein paar Seiten sind.

Zu Drupal 9 oder 10 gebe ich mal keine Empfehlung. Ich habe mit 10 noch keine ERfahrung und halte nichts davon, da vorschnell zu agieren. Das gibt erfahrungsgemäß Probleme.
Aber evt. sehe ich es falsch. Das Update von 9 auf 10 soll später mal unproblematisch sein. Vorausgesetzt, man hat dann auch alle 9er Zwischenschritte brav mit Composer vollzogen.

Hallo Regina,

Danke für deinen Beitrag.
Also ändert sich mein Grobplan von

alt: http://meinedomain.de/ (Drupal7)

zu zwischenzeitlich:

alt: http://meinedomain.de/ (Drupal7)
composer-Upgrade: http://drupal9.meinedomain.de/ (Drupal9)

zu letztlich:

http://drupal7.meinedomain.de/ (alt Drupal7)
http://meinedomain.de (neu Drupal9)

Der View-Export/Import über das CSV-Format ist mir neu. Werde ich mir mal anschauen. Vermute aber nicht das ein simpler Export/Import schon 90% der Vorarbeiten macht. Ich gehe von 100% händischer Arbeit aus.
Klar nutze ich für die Major-Upgradeversion neben ein neues Filesystem auch eine neue Datenbank.
Wenn die Systematik von Drupal9 und Drupal10 angeglichen ist, so das ein vergleichsweise einfacheres Upgrade möglich ist, würde es für Drupal9 sprechen.

Danke!
Dennis

Guck mal, hier habe ich das mit View-Export und Feeds Import beschrieben:
https://www.montviso.de/blog/nodes-und-taxonomies-von-drupal-7-auf-drupa...

"Ich gehe von 100% händischer Arbeit aus."
Kann sein, dass das flotter geht, als die Konfiguration der Module für Export / Import.
Ich habe eine Drupal 7 Seite mit 7000 Pflanzen und jeweils ca. 40 Feldern.
Da rentiert es sich definitiv. ;-)

Habe mir den Link angeschaut. Drush hatte ich auch mal dazu installiert. Es ist eine eierlegende Wollmilchsau. Wenn klappt ist gut, ansonsten Fatal. Gerade bei zwei parallelen Installationen ALT und NEU will ich keinesfalls die existierende Installation ändern. Drush sieht die Pfade und holt sich aus den Configfiles alles für den Datenbankzugriff und "wurschtelt" irgendwie herum.
Habe gerade meine alte drush Installation gestartet, um mir eine Hilfeausgabe aufzurufen um einen schlichte read-only Ausgabe zum Ist-Zustand anzeigen zu lassen. Neben der Hilfeausgabe kamen auch ein paar PHP-Warnungen. Sehr wahrscheinlich habe ich eine Uralt-Installation von drush.
Kurz informiert und meine drush.7 und drush.8 Installationen sind steinalt. Aktuelle arbeiten jedoch nur mit Drupal.8 und Drupal.9 und nicht mehr mit Drupal.7.
Deshalb mein bevorzugter Weg direkt mit den mir gebotenen Funktionen von Drupal.X.

Profi-Tools wie drush oder Bedienung mit composer vereinfachen vieles und könnten im Fehlerfall inkonsistente Systeme zurücklassen. Deshalb mein Wunsch direkt und händisch zeitaufwändig vorzugehen.

Was mich zu einer neuen (eigentlich selbstverständlichen) Modifizierung meiner Vorgehensweise führt.

I Backup Filesystem&Datenbank Drupal.7
II Restore Filesystem&Datenbank auf meinen Laptop, um sicherzustellen, das ich auch nach Zerschiessen einer existenten Drupal.7 Installation auf dem Server, diese wieder zum Laufen bringe
III Erstellen einer Drupal.9 Installation aufrufbar unter anderer SubDomain, aber auf gleichen Server
IV Händischer Upgrade unter Sicherstellung das die alte Drupal.7 Installation immer erreichbar ist, somit kann der Upgrade Wochen oder Monate beanspruchen, denn hast Du keine Ahnung, sorge für Netz und doppelten Boden ;-)

eine,zwei Jahre später Update Drupal.9 auf Drupal.10 mit gleichen Randbedingungen

Drush installiere ich unter Drupal 9 lokal.
D.h. ebenfalls mit Composer.
Du brauchst dann natürlich eine viel neuere Version, als für Drupal 7.
Ist aber kein Problem, weil Du die ja dann mit composer require... speziell für die neue Version installierst.
Drush ist ein gutes Werkzeug, mit dem ich Module aktiviere, die ich mit Composer installiert habe, die Datenbank-Updates nach Installation oder Update von Core / Modul mache ich damit und Cahce leeren...solche Sachen.
Vorausgesetzt, man verwendet den richtigen Pfad, funktioniert das wunderbar. Hat man den falschen Pfad, passiert einfach nichts.
Wenn Du Probleme hast bei D9 und dem zugehörigen Universum, dann vermutlich, weil Du noch das ganze Wissen von D7 im Kopf hast.
Aber funktioniert ja mit Composer alles ganz anders und wenn man es mal halbwegs blickt, dann sehr sehr smart.
Hat bei mir aber auch lange gedauert. ;-)

War vielleicht die Ursache, weil mein Versuch ohne composer vor Jahren mit Drupal.8 zu viele inkonsistente Ergebnisse brachte.
Jetzt habe ich neben composer 1.4.2 auch composer 2.3.10 installiert. Drush wollte ich auch so aktualisieren, doch alle howtos scheinen nur noch den Weg über "composer require" vorzuschreiben.
Unter Drupal.7 nutze ich nur das web-Interface. Module und Updates installiere ich händisch. Nur noch das Aktivieren per web-Interface, so auch Aufräumarbeiten wie Cache leeren. Ich kenne nur die Prinzipien von Drupal.7, finde sie logisch und nutze sie voll aus.
Auch für's Backup werkeln irgendwelche alten Scripte von mir. Muss selbst nachschauen wie ich Filesystem und DB sicherte. Ein Restore auf meinem Laptop steht noch aus, um sicherzustellen, das meine Backups kein Binärschrott sind.
Das einzig Fatale ist, die Produktivumgebung von Drupal.7 läuft auf einem Massenhoster mit verkrüppelter Umgebung. Abgespeckt für den Massenbetrieb. Ist auch nicht mein Baby, ich bin nur der Admin für einen Kumpel mit seinem kommerziellen Auftritt.
D.h. viele Howtos funktionieren nicht komplett und man muss an einigen Stellen wissen was gemeint ist, um es händisch mit Hostingmitteln nachzuziehen.
Ist man fünfmal auf die Nase gefallen, lernt man wenigstens wie es funktioniert.

Ja, Drupal 8/9 ohne Composer enden im Nirwana - bestenfalls, eher in der Hölle. ;-)
Composer 2* läuft wesentlich performanter, als Composer 1*.
Damit komme ich auch bei All-Inkl und Ionos auf shared Hosting-Paketen klar.
Alternativ ist eine lokale Testumgebung sinnvoll.

Zum Backup arbeite ich auch mit scripten, die Datenbank und Dateien sichern und per Cron ausgeführt werden.
Für schnelles Backup zwischendurch verwende ich phpmyadmin und Winscp für die Dateien.

Wenn ich was mache, mache ich es richtig oder gar nicht.

Nächstes winziges Problem. Der Server des Dienstleisters gibt mit php die voreingestellte Version 7.4.30 vor. Dir 8-er Kandidaten sind verfügbar, Doch ein schneller Wechsel zu php 8.1lies die alte Drupal.7 Installation nicht mehr funktionieren. Also Schritt zurück und den Softlink zur 7.4.30 belassen.

Das führt mich zur Frage, führe ich dann eine Drupal.9 Installation mit composer durch, kann ich den Link zu /bin/php81 als php-Interpreter irgendwie vorgeben/erzwingen? Oder greifen diverse Subprozesse immer auf /bin/php, den Softlink zu /bin/php74, zu?

Also editiere composer und ändere die erste Zeile von

#!/usr/bin/env php

nach

#!/usr/bin/env php81
?

Du musst wissen, dass die PHP Version, die Du auf der Konsole nutzt, nichts mit der zu tun hat, die Du für Deine Webseite nutzt.
Ob und wie Du das für Konsole erzwingen kannst, hängt vom Hoster ab.
Ich kann Dir raus suchen, wie es bei All Inkl läuft und wie bei Ionos.
Allerdings erst später.
Welchen Hoster nutzt Du?

Hallo zusammen - will euren Dialog nicht stören,

aber ich hab gerade mitgelesen und das gleiche Problem gefunden. Ich kann bei meinem Provider zwar für jedes Projekt scheinbar die PHP Version einstellen - das bedeutet Drupal "startet" nur in der gewünschten Version. Aaaaber, am Server läuft deswegen nicht die gewünschte Version weiter. Wir haben das Problem gefunden, dass dort eine ältere Version läuft - und die kann ich nicht beeinflußen. Wenn ich das richtig verstanden habe greifen in den Modulen viele Skripte in einander und stoßen immer wieder PHP Aufrufe an, dort wird aber nie eine höhere Version aufgerufen, als der Server hergibt. Wenn dessen Version 7.3 ist, dann nutzen alle Folgeschritte auch nur 7.3. und das produziert Fehler, wenn eigentlich bereits höhere Versionen gefordert sind. Man müßte die PHP Version des Servers einstellen können. Dazu meine Frage, kennst du Provider, die das ermöglichen? In diesem Sinne Drupal-friendly Provider? Ich bin bei alfahosting wo das nicht Einzustellen geht.
LG Martin

Danke für den Hinweis.

php --version
PHP 7.4.30 (cgi-fcgi) (built: Jun 15 2022 16:56:47)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Und via web https://meinserver.de/admin/reports/status/php
7.4.30

Sind somit "zufällig" gleich. Aber hätten unterschiedlich sein können.

Der Provider ist Strato. Dieser hat ein administratives Interface und man kann dort aus einer Auswahl verfügbarer, die gewünschte PHP-Version auswählen. Nach dem Wechsel auf die vom Provider empfohlene Version, war die Drupal7 Installation "offline", d.h. eine mystische Fehlermeldung lies nichts anderes mehr ausgeben. Vielleicht hätte ich auch die Drupal7 Instanz durchstarten müssen, ohne zu wissen wie ich es hätte machen müssen. Ggf. ein VM-Reboot, doch wollte ich potentielle Nebenwirkungen nicht kennenlernen.
Ich kenne keine Drupal-Provider, diesem habe ich im Sack gekauft und administriere nur meine damalige Empfehlung, Drupal zu nutzen. Ich habe einen siebenten Sinn für IT-Dinge.

Wie oben geschrieben, habe ich gute Erfahrung mit Composer bei All-Inkl und Ionos.
Strato ist eine einzige Katastrophe aus verschiedenen Gründen.
Eigener Server wäre ideal, aber für viele meiner Kunden bleibt das ein Traum und läuft gut unter den beiden genannten shared hostings.

Die Subdomain war schnell beantragt. Da noch vor dem Wochenende, wartete ich noch reichlich Zeit. Die unverschlüsselte Subdomain war schnell online und erreichbar. Leider klebt der https-Auftritt mit Browserfehlermeldungen der Art "Fehlercode: SSL_ERROR_NO_CYPHER_OVERLAP". Daher mache ich in der Regel alles selbst. Hier träumt der Provider. Die Domain selber ist per http/https seit Jahren online. Über einen Fehler der Art "Subdomain nicht im Zertifikat der Domain aufgeführt" hätte ich gerne hinweg gesehen.

Mein Browser wählt automatisch immer die verschlüsselte Verbindung, wenn verfügbar. Doch bei einer kaputten Konfiguration des Providers antwortet zwar der verschlüsselte Port, aber läuft stur in den o.g.Fehler.

Sollte ich so eine Drupal.9 Installation wagen? Jeder mystische Fehler in der Installation, dem ich nach gehe, existiert praktisch nicht und pflastert eine neue Sackgasse.

Habe schon versucht meinen Browser extrem fehlerkompatibel gegenüber der einen Domain einzustellen. Ohne Erfolg. Gerade läuft ein Endlosscript das solange versucht eine verschlüsselte Verbindung aufzubauen bis es funktioniert. Ich befürchte beim Provider interessiert sich keiner für volllaufene Logfiles.

Bei Strato kann man doch eigentlich einstellen, dass man eine Seite unverschlüsselt aufruft? Zum Installieren via Composer auf der Konsole ist das erst mal wurscht.
Aber ganz ehrlich. Mit Strato wirst Du dieses Problem lösen und ins nächste rennen.