Webhoster Installation von D8 zu D9 Upgraden - Fragen...

Hallo Cloud77,
Ja, bei dem Upgrade auf D9 und die künftige Pflege wirst Du nicht um Composer drum rum kommen.

Voraussetzung ist erst mal, die D8 Installation composerfähig zu machen.
Wenn Du das bisher per FTP gemacht hast, dann hast Du vermutlich eine andere Dateistruktur, d.h. es gibt in der Drupal-Root kein Verzeichnis web und die Verzeichnise sites,themes, modules ect. liegen alle in der root.

Ich habe dazu mal einen Blog geschrieben. Manches davon könnte man sicher auch eleganter lösen.
Die Problematik wird jedenfalls klar:
https://www.montviso.de/blog/drupal-update-von-8613-zu-893-unter-compose...

Das wäre also Vorraussetzung.
Dann kann man mit Composer auf aktuelles D8 aktualisieren, falls nicht schon passiert.

Zum Composer:
Inzwischen gibt es Composer 2.x und das läuft wesentlich performanter, als Composer 1.
Deshalb muss man nicht bei allen Hostern das Upgrade lokal machen.
Mit 1&1 und all-inkl habe ich diesbezüglich gute Erfahrungen.
Wie es bei Deinem Hoster ist, das klärst Du am Besten mit dem.

Du brauchst ja auf jeden Fall SSH Konsolen-Zugriff.

Dann musst Du Dir eine Anleitung zum Installieren von Composer suchen.

Hat das geklappt, kannst Du mit Composer auch Drush installieren.
Das passiert dann nicht global, sondern projekt bezogen.
Drush wird dann im vendor-Verzeichnis abgelegt.

Wenn man beides installiert hat und soweit fehlerfreie, saubere Installation hat, dann laufen Updates, Modulinstallationen, Deinstallationen sehr smart und schnell.

Ich gehe mal davon aus, Du hast ein Testsystem angelegt als Kopie von Deinem Live-System?
Das wäre zusätzlich zu den Backups eine gute Strategie.

Und noch ein Tipp: Jeden Update-Schritt ausführen, also keine Versionen überspringen.
D.h. erst D9.0.0 dann D9.1.x und so weiter....
Das kann auch viel Ärger ersparen.

Ich danke dir für die ausführlichen Ausführungen und Links. SSH habe ich beantragt und freigeschaltet bekommen, aber bisher für die Seite doch noch nicht gebraucht.
Ich werde mich wohl drum kümmern müssen... Ist aber ehrlich gesagt etwas doof, dass man nun als nicht ITler von seiner gewohnten Weise abrücken muss, um zukunftsfähig zu sein.

Ja doof schon. Aber man kann halt auch nicht wegen den Nicht-IT-lern auf Performance und Sicherheit und Weiterentwicklung verzichten.
Wenn es Dir ein Trost ist: Ich bin seit 22 Jahren in der IT und für mich war das mit dem Composer auch ein harter Brocken.
So ist es halt. Die Welt steht nicht still.

weil es thematisch gut passt, hänge ich mich mal mit dran.

Ich würde gerne das aktuelle Sicherheitsupdate für Drupal 9 installieren.
Die Seite ist mit Composer installiert.
Allerdings frage ich mich, was die beste Strategie ist.

direkt auf dem Server composer update machen?

oder

ein lokales Backup updateten und dann komplett auf den Server schieben?

oder

das lokale Backup updaten und nur compser.json und composer.lock hochladen und auf dem Server composer install ausführen?

Mir ist bei einem lokalen Test schon aufgefallen, dass composer .htaccess und robots.txt überschreibt.

Wie löst man das am geschicktesten, wenn man GIT nicht verwendet?

bin gespannt auf Eure Strategien!

Gruß
jjjj

Ich mache die Updates immer erst lokal, um sicher zu stellen, daß es die Seite nicht zerschießt. Nach dem Testen lokal führe ich dann auf dem Server auch den Update normal mittels composer durch. Das Überschreiben wichtiger Dateien (.htaccess und robots.txt) läßt sich verhindern. Dazu fügst Du im composer,json im Bereich extra ein paar Zeilen ein. Bei mir sieht das so aus:

Damit habe ich auch verhindert, daß der composer abbricht, weil eine Datei auf read-only steht, die er normal überschreiben will (default.services.yml).

Vielen Dank!
ich hatte dem Server einmal das Problem, dass ich einen Timeout Fehler beim Ausführen von Composer Update bekam.
Je nach Hoster, sind da leider Limits vorhanden.
wäre es in solchen Fällen ein gangbarer Weg, den composer update lokal zu machen und die composer.json/composer.lock hochzuladen und auf dem Server nur composer install zu machen?
Aktuell bin ich auf Drupal 9.2.7. Montvisio empfiehlt ja, jeden Release nacheinander zu machen. sollte ich auch erst auf 9.2.8 gehen, bevor ich auf 9.2.9 gehe?

Mit composer 2 ist das PHP-Memory nicht mehr das ganz große Problem. Mir genügen 512M in meiner Installation für composer. Solltest Du das nicht können, so ist immer die Übertragung der Software von der lokalen Installation über einen Tar-File eine Option. Ich habe beim Überspringen einer Punktrelease bisher noch keine Probleme gehabt und den von Dir geplanten Update genau so auch kürzlich durchgeführt.

nochmals vielen Dank!
bei 256M war es schon mal zu wenig.
Ich nehme mal an, Du packst dann dann die gesamte D9 Installation und entpackt sie auf dem Server.

Ja, aber ohne das sites Verzeichnis (web/sites) und im Verzeichnis ausgeführt in dem der composer.json File liegt. Den Tar-Befehl mußt Du nur einmal ausknobeln:
tar -cf dr[version] com* vendor web/.c* web/.e* web/.h* web/au* web/co* web/in* web/li* web/mo* web/pr* web/th* web/up* web/we*
Als fauler Mensch schreibe ich nicht gern die ganzen Namen aus :-).
Wenn Du das im entsprechenden Verzeichnis auspackst, überschreibst Du bestehende Dateien. Es empfiehlt sich, vor dem Auspacken die ordner vendor und core zu löschen, denn falls in einem Verzeichnis Dateien beim Update mit composer wegfallen, bleiben die beim Aufspielen des tar-Files erhalten und das kann merkwürdige Fehlermeldungen geben.

genial!
damit kann ich das tar vorbereiten und erstmal composer update auf dem Server ausführen.
Falls das nicht durchläuft, kann ich immer noch das tar auspacken.

Ich komme bei meinen Hostern all-inkl und 1&1 (Kundenprojekte) inzwischen mit composer 2 auch ganz gut klar.
Natürlich mache ich vorher ein Komplett-Backup von Dateien und Datenbank.
Da kann ich .htaccess ect wieder einspielen.
Oder eben die Lösung in der composer.json

Wenn ich Projekte neu einrichte, dann mache ich das erst in Ruhe lokal und schiebe erst auf den Server, wenn ich erstes Kunden-Feedback brauche.

Das läuft jetzt alles recht entspannt ab - verglichen mit den ersten D8-Projekten, die noch nicht unter composer-Kontrolle waren.

Was das memory limit angeht,so ist ja nicht entscheidend, womit das PHP für Frontend läuft, sondern das Konsolen-PHP.
Ich führe drush z.B. so aus
/usr/bin/php7.3-cli -d memory_limit=-1 vendor/drush/drush/drush updb
Dann wird das maximal mögliche verwendet.

wow. so viel wertvoller Input in kurzer Zeit!
muss ich direkt mal testen, ob der Hoster da einen Unterschied bei den Limits macht.
Viele lehrreiche Tipps hier.
Danke!

gibt es bei D9 die Hinweise, ob diese Dateien im neuen Release geändert wurden nicht mehr?

Ja klar.
Du rufst ein Modul auf, z.B.
https://www.drupal.org/project/address

Ganz unten ist Link auf releases:
https://www.drupal.org/project/address/releases

Dann z.B. bei https://www.drupal.org/project/address/releases/8.x-1.0-rc1
Dort der Hinweis auf notwendige Updates.

Genauso findest Du hinweise auf geänderte settings.php.
Ich finde gerade kein Beispiel.

Danke Dir.
ich meinte den Core.
Bei D7 stand das immer dabei, ob die htaccess usw. geändert wurden.
https://www.drupal.org/project/drupal/releases/7.83
wenn man D9 mit Composer updated, werden htaccess, robots.txt automatisch überschrieben.
Was doof ist, wenn man man da Anpassungen hat.
Wenn da, wie bei D7, stehen würde, dass nichts geändert wurde, brauch ich mich nicht kümmern.
Wenn doch, schau ich mir es genauer an. so muss ich die Dateien jedes mal vergleichen, um zu sehen ob was geändert wurde.

Ich habe doch weiter oben aufgeführt, wie man den composer.json modifiziert, damit diese Dateien (und weitere) nicht mehr überschrieben werden. Mich hat etwa immer die Fehlermeldung gestört, daß er eine schreibgeschützte Datei nicht löschen konnte. Also habe ich verhindert, daß diese Datei angefaßt wird.

ja, genau das habe ich auch gemacht.
Aber wenn es denn doch eine relevante Änderung in einer Dateien geben sollte, dann verpasse ich die.
Bei D7 hat der Hinweis eben geholfen, ob man sich die Sache zumindest anschauen sollte...

Hallo Werner

ist diese Methode immer noch aktuell bzw. zu empfehlen ?
Ich habe eben lokal von Drapal 9.4.7 ein Update auf gemacht und bekomme :

obwohl ich in der composer.json das stehen habe:

ich bin verwirrt

Wieso bist Du verwirrt? Es wird doch genau das gemacht, was Du verlangt hast. Die auf False gesetzten Dateien werden geskipped, also belassen, wie sie sind und die nicht aufgeführten kopiert. Also Alles im grünen Bereich.

ich bin/war verwirrt, weil mich nicht erinnern konnte, je die copy Hinweise bekommen zu haben:

gitattributes
web.config
example.settings.local.php

example.settings.local.php und gitattributes
kann man vermutlich einfach ignorieren.
bei web.config bin ich mir da nicht so sicher.

Die Datei web.config wird nur dann benötigt, wenn der Server, auf dem Drupal läuft, ein Windows Betriebssystem hat. Bei den meisten Providern läuft Linux. Und bei mir lokal läuft auch kein Windows.

Danke für die Erläuterung.
mir sind die beiden kopierten Dateien einfach bisher nicht aufgefallen.