Update von 8.8.3 auf 8.9.7 via SFTP

Na ja da steht die der Dienst x hat eine Abhängikeit von y Die in Datei z angegeben, wird, aber nicht gefunden wird.. Im Klartext heßt dass: Ich kann mich nicht aktualisieren, weil einer meiner Programmierer, vergessen hat, mir Daten mitzugeben, die ich dafür brauche Alles liebe, deine Drupal-Installation.

Der Tipp:

Hier: https://www.drupal.org/project/drupal/issues/3100173 wird gesagt, dass man das eventuell dann lösen kann, wenn man das Update mit Composer durchführt, nachdem man sein Projekt, falls dessen Abhängigkeiten noch nicht mit Composer verwaltet werden so wie hier: https://www.drupal.org/docs/develop/using-composer/using-composer-to-ins... beschreiben aktuallisiert um dann eine Aktualisierung mittels Composer ausführen zu können und diese schlussendlich mit drush updb abzuschließen.

Ja, ich weiß, das klingt, kompliziert und das mag es für Neulinge auch sein, ist aber im Grund extrem simpel.

Alternativ, kannst du auch einfach warten, bis die fehlende Service-Datei fertig programmiert ist oder einen entspreche enden Bug melden.

Ein Bug im Core., der dazu bereits passen könnte ist der hier. Wenn der Grün wird, dann kannst du das mit dem Update über die UI noch mal versuchen.

https://www.drupal.org/project/drupal/issues/2102293

3.. und letzte Möglichkeit. Du deaktivierst vor dem Update die Media-Library, sodass diese während dem Update in der Datenbank nicht als aktiv gelistet ist und schaltest sie nach dem Update wieder an.

Viel Spaß, beim durchtesten.

Interessant ist auch, dass du sagst, dass du Verzeichnisse hoch-lädst. Das solltest du nicht tun. Lade lieber die funktionierende Version herunter. Führe das Update in einer lokalen Entwicklungsumgebung aus und lade die Aktualisierte Version dann auf den Live-Server, wenn du sicher bist, dass das Update in der Entwicklungsumgebung funktioniert hat. So machst du zumindest zukünftig deine Produktionsseite nicht mehr kaputt.

Vielen Dank für deine umfassende Rückmeldung! Ich muss es wohl mit dem Composer probieren. Des Weiteren siehe Anmerkungen unten.

Wie gesagt: Ich versuche das mal.

Warten ist natürlich für den betreffenden Kunden keine tolle Option.

Probiert, da kommt dann einfach die nächste Fehlermeldung.

TypeError: Argument 1 passed to Drupal\Core\Extension\ThemeHandler::addTheme() must be an instance of Drupal\Core\Extension\Extension, null given, called in /[drupal-installation]/core/includes/theme.maintenance.inc on line 73 in Drupal\Core\Extension\ThemeHandler->addTheme() (line 118 of core/lib/Drupal/Core/Extension/ThemeHandler.php).

Das Problem scheint also tiefer zu liegen.

Danke!

Ich habe mich m.W. strikt an diese Anleitung https://www.drupal.org/docs/updating-drupal/updating-drupal-core-manually gehalten und dort wo angegeben den FTP-Client-Weg gewählt.

Das Ganze liegt als Kopie auf dem Live-Server, in der tatsächlichen Live-Umgebung arbeite ich also nicht.

Ich werde mich mal melden, wenn ich Neues habe.

Viele Grüße
winnewoerp

Glaub mir, das ist nicht mehr der beste Weg.

Ich habe auch einige Drupal Kunden bei Shared Hostern, wo man Composer nicht ausführen kann.
Die sind z.T. schon lange dabei, sind kleine Kunden, die keinen eigenen Server betreuen wollen/können/ oder Betreuung zahlen wollen/können.

Ich habe mir dafür inzwischen eine lokale Umgebung unter Windows 10 mit 2GB memory Limit in der php.ini und mit Composer eingerichtet.
Auf dem Produktivsystem wird eine Zip-Datei aller erstellt, weil dann der Download weniger fehleranfällig ist.
Natürlich Datenbank auch geholt.

Dann wird Update gemacht - und zwar Schritt für Schritt, ohne Auslassung einer Zwischenversion.
Hudeln bringt hier gar nichts. Das musste auch ich als chronisch ungeduldiger Mensch erfahren. ;-)

Danach geht die Zip +Datenbank wieder hoch auf ein paralleles Test-System mit eigener Datenbank neben Produktivsystem, wird noch mal getestet und dann auf Produktiv übertragen.
Ist zwar viel Aufwand, aber das ist auch so kommuniziert beim Kunden.

Wenn die Installation auf neuestem Stand ist und die Versionenschritte klein, kann man auch mal nur die composer.json und composer.lock nach Update vom lokalen Testsystem auf Produktiv übertragen und dort composer install ausführen. Dann werden die auf dem Testystem unter hohem memory Limit ermittelten Abhängigkeiten installiert.

Das erfordert natürlich, dass die Systeme in Bezug auf installierter Module identisch sind.

Was das PHP memory vom Hoster auf der Konsole regelmäßig sprengt, ist der composer require oder update Befehl.
Angeblich soll es irgendwann mit einer neuen Composer-Version besser werden.

Vielleicht würde es bei Dir auch mit FTP klappen, wenn Du eine Version nach der anderen installierst.

Ich habe die Testumgebugn auf Windows. Du kannst aber auch eine VM Linux-Umgebung installieren.

Danke für die umfangreichen Tipps und die Schilderung bei dir bzw. den Erfahrungsbericht. Der entsprechende Kunde hat ein Webhosting-Paket mit SSH-Zugang und Composer kann dort definitiv genutzt werden. Ich werde nun also Folgendes machen (nachdem ich alles für das Update über Composer eingerichtet haben werde):

1. Update auf die neueste Version strikt nach Anleitung per Composer
2. Wenn das nicht klappt: Schritt für Schritt die einzelnen Versionen updaten.

Im Moment bleibe ich bei einer webserverseitigen Entwicklungsumgebung. Wenn ich mal Zeit und Muße habe, richte ich mir aber auch noch einmal eine lokale Variante ein.

Viele Grüße
winnewoerp

Ok,dann drücke ich Dir die Daumen, dass es klappt.

Klar erleichtert es den Workflow, wenn man das Update auf dem Server machen kann.
Das Problem ist ja nicht, dass composer grundsätzlich nicht funktioniert, sondern dass auf shared Hosting auf der Konsole nicht genug PHP memory limit zur Verfügung steht.
Das ist selten der Fall.

Ich habe das mit All-inkl und 1&1 durch diskutiert. Bei All-inkl hat es lange funktioniert, plötzlich nicht mehr.
Sie haben mir bestätigt, dass ein bestimmte composer-Befehl nahezu 2GB memory erfordert.
Man hat aber maximal 512 oder vielleicht auch 1024 MB:
Das reicht nicht und mehr können sie nicht geben, weil sonst die anderen Kunden auf dem Server leiden.

Falls es auf dem shared Webhosting-Paket funktioniert, dann lass mich bitte wissen, welcher Hoster das ist.
Dann empfehle ich das gerne meinen Kunden.

Na, da sagst du was. Bei ALL-INKL bin ich selber, in diesem Falle ist der Kunde bei 1&1. Ich hatte gehofft, dass ich das da einfach per SSH alles in der composer-Variante erledigen kann. Geht es bei denen nicht?

Es hängt natürlich auch immer davon ab, wie umfangreich ein Paket ist und ich kann nur sagen, probiere es aus.
Bei mir ging es definitiv bei beiden nicht und beide Hoster haben mir bestätigt, was Dir auch hier jeder sagen wird.
Es kann nicht funktionieren, dass sehr performance-hungrige Composer-Befehle auf einem shared Paket funktionieren, weil man da anderen Kunden das Wasser abgräbt.
Also haben sie das mögliche PHP memory Limit gedrosselt.
Beide empfehlen, das Composer-Update lokal zu machen.
Wie gesagt, es gibt immer noch die Hoffnung, dass Composer irgendwann weniger Leistung braucht.

Ich danke dir für deine hilfreichen Hinweise!

Mit PuTTY über SSH hat nun alles geklappt (ohne Versions-Zwischenschritte). Es gab keine Probleme mit dem Memory Limit. Der Kunde hat ein großes Webhostingpaket mit unbegrenztem Speicherplatz, aber leider mit einer Maximalzahl von Dateien. Diese Grenze wurde während des Update-Prozesses überschritten und führte zu einem Fehler. Ich habe dann die Verzeichnisse core und vendor lediglich verschoben anstatt (wie in der Anleitung beschrieben) aus dem Downloadpaket der neuen Version zu kopieren. Dann lief es.

Dann musste ich nur noch herausfinden, dass ich in der .htaccess aufgrund unserer Einstellungen

RewriteBase /

aktivieren muss (ist ja standardmäßig auskommentiert).

Viele Grüße
winnewoerp

Ja genau
RewriteBase /
ist eine Spezialität von 1&1.

Gut, dass es nun geklappt hat.

Hallo, mal kurz dazwischen weils bei mir grad (zur eigenen Überraschung) anders aussieht:
auch shared mit All-inkl (!), Tarif der eben ssh zulässt: auch auf dem Server klappt bei mir "ini_set('memory_limit', '2G');" , wahlweise 2000M ;-) und composer macht brav update oder selfupdate, drush 10 entsprechend. Die momentane D8-Instanz (auch D9-Experimente) ist noch relativ klein, aber Migration mit drush ist ja auch nicht ohne (das allerdings vor allem lokal).

Die Server laufen dort ja unter "kasserver.com". Ich bin auch bei einem weiteren Provider (Suleitec) beteiligt, dort läuft auch der kasserver mit 2G PHP-Speicher.

Kann sein dass man auch wg. mehr Composer-Kunden (das ist ja nicht nur Drupal) umgeschwenkt ist. Ich weiß natürlich nicht ob die 2G auch reichen wenn mal größere "Produktions-Seiten" gebraucht werden, was bei mir eher nicht passiert ..

Servus -- Franz

Hi Franz,
klingt gut.
Das ist vermutlich der gleiche Tarif, den wir auch haben. Bzw. vor kurzem habe ich aufgestockt, weil der für 9 Euro nicht mehr gereicht hat.
Kann schon sein, dass sie jetzt mehr geben.
Vor kurzem haben sie noch sinngemäß gesagt, träum weiter, als ich gesagt habe, so 2GB bräuchte man da auf der Konsole schon. ;-)

Ich habe das PHP mit dem Parameter für unbeschränktes Memory Limit ausgeführt.
Dann probiere ich das auch noch mal und teste mit dem ini_set.