Update Drupal 7.42 => 7.69

Sorry, auf Strato läuft PHP 7.3.12, MySQL 5.5.2

Das mit dem totalen Reset habe ich hier gefunden: https://www.drupal.org/docs/7/update/updating-modules

Du findest hier die ausführliche Anleitung um D7 upzudaten:
https://www.drupal.org/docs/7/update

Spiele einfach dein Backup zurück und entweder setzt du die Seite in den Wartungsmodus oder als Neuling würde ich das vollständige Update auf einer Subdomain oder extra Domain durchführen und dann erst auf die eigentliche Domain spielen.

D7 lässt sich simpel über FTP updaten, dauert ca. 2-3 Minuten (Core), die Module selbst kannst du im Admininterface updaten, den Core aber nicht.

Ein automatisches Update von D7 auf D8 ist nicht möglich da sich bei D8 sehr viel in der Grundstruktur geändert hat.

D7 wird aber noch bis November 2021 supported.

Grüße Jenna

Hatte grad gesehen das du den Link schon in deinem Thread erwähnt hast, hier noch ein Video mit Step by Step Anleitung:

https://www.youtube.com/watch?v=Aj3Ujsjnqkw

Grüße Jenna

Also bei einer kleinen Webseite direkt zu WordPress oder Joomla wechseln!
Da kann man alle Updates einfach per Mausklick machen.

Hallo caw,

nun ja, bin jetzt schon einigermaßen ernüchtert. Meine Updateversuche waren extrem kompliziert, man muss ja erst noch alle benötigten Module einzeln per gz/zip ziehen und einspielen. Transparent und Servicefreundlich ist das nicht...

Ich hatte es dann auch geschafft, trotzdem sah die Seite deutlich anders aus. Background images fehlten, etc. und das tue ich mir als Anfänger nicht an, alles wieder glatt zu ziehen. Dabei bin ich im major release 7 geblieben! Wahrscheinlich müsste man auf der neuesten Version 8 einen Aufwand einer Neuprogrammierung einkalkulieren?

Eine echte Überlegung Wordpress zu nehmen und ich werde mal mit meinem Kunden reden. Das ist definitiv viel besser aufgestellt....
Joomla? Gibt's das noch? Hatte ich vor 10 Jahren ähnlich unschöne Erfahrungen...

Joomla gibts noch und hat sich weiterentwickelt...
Wie gesagt: auch da sind Updates problemlos per Mausklick möglich.

Die Erfahrungen, die du hier beschreibst, sind ja wirklich ernüchternd. Ich kann das teilweise bestätigen. Bis man Drupal so weit aufgesetzt, konfiguriert und anschließend das Frontend gestyled hat, ist man mit Wordpress schon dreimal am Ziel. Und das ist ja noch nicht das Ende. Der Wartungsaufwand ist bei Drupal ungleich höher. Die Plugins kann man zwar über das Admin Interface updaten. Aber wie oft habe ich schon erlebt, dass nach einem einfachen Modul-Update irgendwelche side effects die Funktion der Website beeinträchtigten. Und ich rede hier nicht von dev-Versions.

Mein Zwischenfazit nach 8 Jahren Drupal: Ein ungeheuer mächtiges System, mit einer ungeheuer steilen Lernkurve. Usability und intuitive Bedienbarkeit: Fehlanzeige. Ein CMS-Baukasten für Nerds, die weitgehend schmerzfrei sind.

Für kleine Websites setze ich inzwischen nur noch Wordpress ein. Alleine schon wegen des deutlich geringeren Wartungsaufwands.

Unabhängig vom Umfang der Website, sollte man bei Drupal wie bei jedem anderen CMS (auch Wordpress und Co) mit Backups und Test-Systemen operieren. Neben den Hobby-Anleitungen via FTP und PHP-Myadmin kann man Drupal 7 und 8 mit Drush und/oder Composer professionell managen und das am besten auch nicht direkt auf dem Live-Server bezüglich der Code-Updates über Git-Repositories und/oder Composer Install. D.h. Modul Packages runterladen, entdecken und mit FTP verschieben ist nicht ratsam. (ich persönlich diskutiere auch nicht mehr darüber, daß das auf Billig-Webspace nicht oder nur schlecht geht usw.). Code-Update-Routinen in der Datenbank kann man zwar theoretisch noch über "update.php" durchführen, aber auch das geht mit Drush viel besser. Auch bei WordPress geht der professionelle Ansatz Imme rmehr zu Commandline Tools wie dort z.B. WP-Cli.

Bezüglich des inzwischen so großen Versions-Sprungs von core7.42 auf 7.69, der wohl auch Contrib-Module betreffen wird, kann es sein, daß dies nicht immer in einem Schritt funktioniert. Gerade für das schrittweise Vorgehen ist die oben erwähnet Git-Strategie sehr hilfreich. Denn insbesondere bei Contrib-Modulen schleichen sich ab und zu Fehler bei den Versionen ein, die leider manchmal manuelles Eingreifen erfordern. Aber das findet man ja mit Test-Systemen (d.h. Kopien des Live-Systems) heraus. gerade weil das Ziel-System bereits mit PHP 7.3 arbeitet und dies noch nicht so lange im. Code unterstützt wird und evtl. auch noch eines der verwendeten Contrib-Module oder vllt. auch Zustrom Code dazu noch nicht kompatibel ist, kann es sinnvoll sein, die Updates noch auf einer älteren PHP Version durchzuführen und erst dann auf PHP 7.3 zu wechseln, wenn das ausführlich getestet wurde. Solche Probleme drohen auch bei anderen CMS.

Bezüglich des Hinweise auf andere CMS wie WordPress oder Joomla! muss ich der Aussage, Drupal sei für kleine Websites nicht geeignet widersprechen. Mal davon abgesehen, daß dies hier ein Drupal-Forum ist und ich diese "Werbung für andere CMS" nicht für angemessen empfinde, halte ich das für sachlich schlicht falsch. Meiner Meinung nach ist das entscheidende bei der Wahl des CMS, ob dessen professionelle Pflege gegeben ist.
Wenn einem Drupal nicht liegt und man sich nicht so intensiv damit beschäftigen möchte, daß man Drupal wirklich beherrscht ist das für den einzelnen Administrator auch nicht ratsam, sich um Drupal zu kümmern. Allerdings ist der Umstand daß z.B. bei WordPress noch einige Dinge einfacher erscheinen kein Ersatz dafür, sich als verantwortungsbewusster Admin auch mit professionellen Ansätzen bei WortPress zu beschäftigen. Die gerne erwähnte Auto-Update Funktion, an der auch für Drupal gearbeitet wird, erfordert meiner Meinung nach eine essentielle Lücke in der Server-Konfiguration, damit sich das System selbst updaten kann. Das führt zwar zu etwas sichereren Hobby-Systemen, aber meiner Meinung nach weg von einer professionellen Vorgehensweise.

Bei kleinen Websites sollte man sich grundsätzlich überlegen, ob man auf dynamische Funktionen lieber verzichten möchte und statt dessen lieber statische Seiten zu benutzen. Dazu kann man auch Drupal und andere CMS benutzen z.B. über Staticopy, das wir zu diesem Zweck entwickelt haben. Damit halten wir z.B. noch mehrer Drupal 6 Systeme im Betrieb und den Support-Aufwand bei Drupal 7 und 8 gering.
Wenn es denn dynamisch sein soll, wird es wie für Drupal 6 übrigens auch ein LTS-Programm für Drupal 7 geben, so daß die Deadline nächstes Jahr nicht unbedingt so extrem ist, wie es vielen aktuell erscheint.

Das Update des Kerns kannst du per FTP machen. Tausche einfach das System (D 7.6.9) mit der neuen Version (kopieren auf den Server) aus. Dabei darauf achten nicht den ordner /sites, die .htaccess und robots.txt zu überschreiben. Danach im System www.meineseite.de/update.php ausführen. Damit wäre die Kerninnstallation aktuell. Nach meiner EInschätzung sollte es zu keinen Problemen kommen, da die Version noch recht aktuelll ist.

Die Module kannst du über das Backend aktualisieren -> Erweiterunge -> aktualisieren. Danach sollte autommatisch die Update.php ausgeführt werden.

Die genauen Informationen findest du im System unter Reports -> Statusbericht.

Nur weil ein kleines Update gemacht wird, sollte man nicht gleich die ganze Seite verwerfen. Jedes System hat so seine Macken.

Grüße Marcel

@ C_Logemann

Achte bitte auf deine Wortwahl! Hobby-Anleitung ist reine Panikmache, das hat schon lange vor Drush und Composer funktioniert. Es reicht wenn man die Datenbank und das Template bei kleinen Websites sichert. Git sehe ich hier als übertechnisiert an. Zudem lebt die Community von Drupal von den Hobby-Tüftlern, die zusammen arbeiten und sich gegenseitig helfen! Bei deinem Post klingt es nach übermässiger Eigenvermarktung die am Ende allen schadet.

Grüße Marcel

naja, wohl eher ein CMS Framework für Leute die wissen was sie tun.

Also ich kann da keinen wesentlichen Unterschied zwischen Drupal und WP feststellen. Auch bei den viel gelobten WP 1 Klick updates knallt es immer wieder gerne, wenn die Installation viele Plugins enthält, was meist nötig ist, damit aus diesem Spielzeug ein halbwegs brauchbares CMS wird.

also das timmt so auch nicht. bei wp hatte ich bisher keine probleme mit irgendwelchen plugins und updates. bei themes schonmal. und außerdem: alles automatisch, ich muss kein composer oder ftp nutzen...

... dann hab ich das wohl geträumt ;). Warte ab, bis die (meist kostenfreien) eingebauten Plugins nicht mehr gepflegt werden. Dann kommen die großen Probleme. Nee, also so sorglos wie WP immer hingestellt wird, ist es nun wirklich nicht.

Nun ja Marcel,

genau das hatte ich versucht mit dem Ergebnis, dass nach der Modulinstallation die Meckerliste von Drupal kleiner und kleiner wurde und dann ganz verschwand, aber die Website danach unvollständig und teilweise zerstört war. Ich habe es auch auf meinem Rechner probiert nicht nur auf nem windigen V-Server mit jeder Menge Einschränkungen. Da habe ich alle Rechte, modernes Ubuntu 18.04 LTS, etc. und trotzdem war der Update nicht von Erfolg gekrönt...

Ich finde die Updateprozedur ein Armutszeugnis und unnötig kompliziert. UNd Drupal 8 habe ich eh schon fallen gelassen... Wenn unsere Entwicklungen in unseren anderen Docker containern genauso wackelig auf updates reagieren würden, wären wir schon längst am Ende....

so was habe ich mir auch gedacht und daher auch mal PHP7.2 instaliert. Ergebnis 1:1. Website kaputt....

Ich werde mich hier ausklinken. Da habe ich ja was losgetreten... Eigentlich war ich nur frustriert und verärgert, dass ein Update solche Probleme aufwirft...

Wer kann denn eine Drupal Website von 7.42 auf eine moderne Version umstellen um solche Warnings wie "deprecated each( ) in file ...." wegzubekommen?

Am besten zum Festpreis, da es eigentlich nur für eine Freundin eine kleine Umstellung ist und wir hier mit Drupal nix am Hut haben: ==> jursch@datenglueck.com

Die Kompatibilitätsmeldungen erscheinen ja nicht in irgendwelchen consolenwarnings die man möglicherweise mit & ~E_DEPRECATED schnell abschalten könnte, sondern frecherweise mitten in den veröffentlichten Seiten, mit roten Rähmchen und rosa background... richtig fucking liebevolles CSS um möglichst maximal auf den Sack zu gehen...

Eine Wutrede über so eine dumme Strategie verkneif ich mir hier jetzt lieber...
--
Gruß
Karsten

Unter "/admin/config/development/logging" kann und sollte man die Error-Messages abschalten. Daß das nicht die Default-Einstellung ist, ist auch meiner Meinung nach keine gute Strategie.

@jannilrau

Ich würde einem Anfängernicht empfehlen, das auf dem Produktivsystem zu machen.
Ich mache - trotz oder wegen 10 Jahren Erfahrung mit Drupal - bei komplexeren Installationen mit vielen Modulen auch immer auf einem Testsystem.
Meistens klappt alles gut, zumindest, wenn man keine zu weiten Versionssprünge hat, aber der Teufel ist ein Eichhörnchen - sagt man bei uns. ;-)

Module müssen natürlich nicht extra geholt und entzippt werden, sondern geht über Backend - wurde ja oben schon geschrieben.

Mit Drush kann man das alles recht bequem auf der Konsole erledigen, ob das bei strato klappt, weiß ich nicht.

Bei Wordpress mache ich Updates direkt am Produktiv-System dann, wenn ich weiß, dass ich ein einfaches Theme verwende und wenig Plugins.
Also auch nur bei Installationen, die ich selbst erstellt habe, oder wo ich die Plugins alle kenne.

Natürlich nur mit vorherigem Backup.
Weil - zu obiger Diskussion - ich habe da auch schon white Screen erlebt, wenn Plugins nicht mehr kompatibel waren - und nicht nur einmal.

Solche Erfahrungen habe ich bisher noch nicht gemacht. Gut, ich muss vielleicht dazu sagen, dass es wirklich nur kleine Websites sind, die ich mit Wordpress aufsetze. Und wenn ich Plugins verwende, achte ich peinlich genau darauf, nur solche zu verwenden, die über Jahre aktuell gehalten wurden und die von einer sehr breiten Anwenderzahl eingesetzt werden. Dasselbe Vorgehen im Prinzip wie bei Drupal oder jedem anderen Open Source System. Für kleinere Anpassungen schreibe ich mir zudem meine eigenen Plugins.

Der Switch nur zu PHP 7.2 ist evtl. zu kurz gegriffen in Anbetracht dessen, daß Drupal 7.42 aus dem Frühjahr 2016 stammt und erst danach Fit für PHP 7.0 gemacht wurde. Es können auch Contrib-Module die Verwendung von PHP 7.x verhindern.

In solchen Fällen helfen auf Produktiv-Systemen oder wenn der Zugriff auf PHP aus anderen Gründen offen ist zur Not Long-Term-Support (LTS) Versionen von PHP, die Backports von Sicherheitsupdates enthalten. Wenn überhaupt verfügbar im Managed Hosting werden diese dann oft mit Aufpreis angeboten. Auf geschützten Systemen oder lokalen Entwicklungsländern-Umgebungen, die man für das Update nutzen kann, ist der Sicherheits-Zustand von PHP dann aber nicht so wichtig. Und es ist auf jeden Fall ratsam, nach Möglichkeit den Betrieb auf aktueller PHP Version anzustreben. Es kann auch sein, daß die neue Versionen von Contrib-Modulen eine bestimmte höhere PHP Version voraussetzen als andere Contrib-Module überhaupt unterstützen können. Wenn alles auf dem neuesten Stand ist, ist das allerdings selten, aber der Weg dahin in einem einzigen Update, das nun fast 4 Jahre Entwicklung in Core und Contrib überbrücken soll kann evtl. wie schon erwähnt Zwischenschritte benötigen. Ein Szenario, wie Modul X sollte erst zu Version Y angehoben werden, dann der Core auf Version A und danach erst alles auf den neuesten Stand würde mich nicht wundern. Selbst viel genutzte Module mit vielen Maintainern können nicht alle Update-Szenarien berücksichtigen mit unterschiedlichen Start-Versionen in Kombination alle erhältlichen Module. Manchmal schleicht sich sogar ein Update-Fehler in einem einzigen, wichtigen Modul ein. So etwas hatten wir schon beim Rules-Modul, das unabhängig des System drum herum aufgrund eines Fehlers nicht einfach direkt bestimmte Versions-Updates überbrücken konnte. Da musste man dann erst auf eine bestimme Version updaten zusammen mit dem Rest und dann noch mal Rules separat.

Für solche zum Teil sehr aufwendigen Fehlersuchen würden wir übrigens kein Festpreis anbieten, egal wie groß die Website und/oder die/der Kunde/Kundin ist, bzw. ob kommerziell oder unkommerziell/privat.

Für Job-Angebte gibt es übrigens ein eigenes Forum. Ein Link zu diesem Beitrag ist dabei denke ich sehr hilfreich.

Das können wir auch nicht anbieten.
Bzw. haben das lange gemacht. Im unserem Netzwerk sind nun mal viele kleine Kunden.
Aber es wäre einfach auf Dauer ruinös.

Das Gleiche gilt für Wordpress-Projekten die wir übernommen haben.

Meistens bekommen wir ja die Anfragen, weil irgendwas nicht geht, wie es soll.
Der vorherige Dienstleister oder "Freund der Familie", Schulkamerad des Sohns, Studienfreund der Tochter hat keine Zeit oder keine Lust mehr.

Das ist bedauerlich, aber meistens sind die System dann nicht stimmig und der Zeitaufwand ist einfach nicht kalkulierbar.

Bei einem Hoster, wie Strato, gilt das umso mehr.