Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Anfängerfragen ›

Suche Upgradeempfehlungen einer existenten Drupal7 Site auf 9/10?

Eingetragen von dennis.drupal (7)
am 28.07.2022 - 17:39 Uhr in
  • Anfängerfragen

Hallo Kollegen,

obwohl schon seit 5 Jahren im Forum präsent, heute mein erster Beitrag bei dem ich mir eine generelle Vorgehensweise eines Upgrades einer existierenden Drupal7 Installation erhoffe.
Letztlich mach ich das Update/Upgrade selber. Ich benötige nur die Einschätzung eines/einiger Drupal Wissenden.

Vor geschätzt 10 Jahren habe ich eine Drupal7 Installation komplett neu aufgesetzt und Stück für Stück mit Inhalt versehen. Sie ist relativ umfangreich geworden. Ich nutzte den bescheidenen Inhalt einer damals existierenden "IchHabeKeineAhnungInstallation" eines Bekannten mit Null IT Kenntnissen.
Schon vor 5 Jahren plante ich ein händischen Upgrade der existenten Drupal7 in eine Drupal8 Installation. Ich gab schnell auf. Heute sehe ich Drupal9 ist der stabile Standard. Auf meinen verschobenen Upgradewunsch bin ich gekommen weil ich auf ein Artikel zu Drupal10 gestoßen bin und sehen wollte was mich ein Upgrade "kosten" würde.

Gänzlich neu ist für mich die Verwendung über den Composer, der inzwischen für 7,8 und 9 empfohlener Standard sein soll. Klar könnte ich den Link meiner händischen Drupal7 Installation hier nennen, schrecke jedoch eher davor zurück. Vielleicht gebe ich den Link den einen oder anderen Antwortenden persönlich. Da ich jedoch damals nur banale Extra-Module einband und heute nur eines dieser Module abgelaufen und nicht mehr gepflegt wird und eine händische Installation Pflicht war, war ein Wechsel auf eine neue Lösung obligatorisch.

Das also zu meiner Ausgangssituation. Jetzt meine Fragen.

Drupal9 oder Drupal10.1 (März23) bevor EndOfLive für Drupal7 (Nov23) erreicht wird?
Composer als neue Strategie werde ich akzeptieren. Ich plane neben der existenten Drupal7 Installation im WebRoot Verzeichnis eine neue Zweitinstallation in der ersten Unterverzeichnisebene parallel aufzubauen, z.B.

Drupal 7 http://url/
Drupal 10.1: http://url/drupal10/

Bin ich mit der händischen Neuinstallation von der Neuinstallation zufrieden, tausche ich nur die Webroot aus und jeder Besucher sieht nur noch die Neuinstallation, also

Drupal 10.1 http://url/
Drupal 7 http://url/drupal7/

Und belasse die Altinstallation noch eine Weile unter neuer Sub-URL bevor ich sie nach Monaten Ereignislosigkeit letztlich händisch lösche.

Zusammengefasst möchte ich wissen Drupal9 oder warten auf Drupal 10 als neue Zielumgebung und ob meine paralleler Lauf von Alt- und Neuumgebung als parallele Umgebung Sinn macht/so funktioniert.

Ich bin zwar kein Drupaler, sondern ein schlichtes Urgestein aus der Unix-IT und skrupellos mich mit neuen Technologien auseinanderzusetzen. Ist meine schlichte Vorgehensweise ein auch empfohlener Vorgehensweg für ein Drupal-Upgrade?

Grüsse
Dennis

‹ (Gelöst,...) Taxonomie Beziehungen ausblendbar im Backend? (Gelöst,...) Node nur in einer Sprache Ausliefern ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Hi Dennis, Grundsätzlich ist

Eingetragen von montviso (2115)
am 29.07.2022 - 07:53 Uhr

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.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Subdomains ist ein guter Vorschlag

Eingetragen von dennis.drupal (7)
am 29.07.2022 - 09:14 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Guck mal, hier habe ich das

Eingetragen von montviso (2115)
am 29.07.2022 - 10:10 Uhr

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. ;-)

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

tools ala drush

Eingetragen von dennis.drupal (7)
am 29.07.2022 - 15:48 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Drush installiere ich unter

Eingetragen von montviso (2115)
am 29.07.2022 - 16:15 Uhr

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. ;-)

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

composer

Eingetragen von dennis.drupal (7)
am 30.07.2022 - 06:33 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ja, Drupal 8/9 ohne Composer

Eingetragen von montviso (2115)
am 30.07.2022 - 10:05 Uhr

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.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

PHP Version, die nächste Mutation

Eingetragen von dennis.drupal (7)
am 31.07.2022 - 08:17 Uhr

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
?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Du musst wissen, dass die PHP

Eingetragen von montviso (2115)
am 31.07.2022 - 11:34 Uhr

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?

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

PHP unterschiedliche Version des Providers

Eingetragen von Martin Gr. (140)
am 31.07.2022 - 11:59 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

php konsole und web interface

Eingetragen von dennis.drupal (7)
am 31.07.2022 - 13:56 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wie oben geschrieben, habe

Eingetragen von montviso (2115)
am 31.07.2022 - 22:01 Uhr

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.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Fehlercode: SSL_ERROR_NO_CYPHER_OVERLAP

Eingetragen von dennis.drupal (7)
am 03.08.2022 - 15:13 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Bei Strato kann man doch

Eingetragen von montviso (2115)
am 03.08.2022 - 18:36 Uhr

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.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • Matomo(?) in Seite, aber Deinstalliert!
  • Upgrade Drupal 7 auf Drupal 9 / Inhalt erstellen zeigt nur Fehler an
  • Olivero veraendern
  • Fehlermeldung nach Update auf Drupal 10
  • Wie Button erstellen?
  • footnotes bei D10 und CKE5
  • ckeditor Bilder skalieren
  • Bild in welcher Form die Beschriftung!
  • Drupal 10 und Adaptive Theme 2.0
  • Drupal Commerce: Deprecated Module deinstallieren: CKEditor, RDF
  • [gelötst] Migration einer Seite von D8.9 auf 9 resp 10
  • Theme Olivero - Rand entfernen?
Weiter

Neue Kommentare

  • @onkel Bob,Erst mal
    vor 3 Tagen 4 Stunden
  • Prinzipiell geht das schon.
    vor 3 Tagen 4 Stunden
  • Rubi_2021 schriebWie genau
    vor 1 Woche 1 Tag
  • Ok, war ein Versuch. ;-) Kann
    vor 1 Woche 2 Tagen
  • Danke
    vor 1 Woche 2 Tagen
  • Redest Du von dem
    vor 1 Woche 2 Tagen
  • Mit sticht das hier ins
    vor 1 Woche 2 Tagen
  • Mit welcher Version Drupal
    vor 1 Woche 2 Tagen
  • Bitte um Hilfe
    vor 1 Woche 2 Tagen
  • Fehler trotz Neuinstallation
    vor 1 Woche 2 Tagen

Statistik

Beiträge im Forum: 248796
Registrierte User: 19831

Neue User:

  • J. Berten
  • vohome
  • DerRalph

» Alle User anzeigen

User nach Punkten sortiert:
wla9333
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3845
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 1 Benutzer und 6 Gäste online.

Benutzer online

  • wla

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association