Contao Manager 1.4.4 - nach Aktualisierung auf 4.4.* -> Installtool Error 500

[pipkin]

Moin,

nach mehreren vergeblichen Versuchen einer 1:1 Kopie einer 4.4er Installation, die jeweils zu diesen Fehlern führten...

-> Installtool lässt sich nicht aufrufen, weiße Seite/ 500er
-> BackEnd lässt sich nicht aufrufen, weiße Seite/ 500er
-> FrontEnd lässt sich nicht aufrufen, weiße Seite/ 500er

... habe ich mal versucht, das Problem runter zu brechen und Schritt für Schritt zu testen, ab wann genau das Installtool nicht (mehr) aufgerufen werden kann.

Vielleicht kann das jemand reproduzieren?

• Installation von Contao 4.9 mit Contao Manager 1.4.4
-> Hier wäre das Installtool noch erreichbar (Lizenztext erscheint)
• Downgrade auf Contao 4.4.*
-> Installtool ist nicht erreichbar (weiße Seite/ 500er).

Da ich heute morgen noch mit dem Contao Manager 1.4.3 erfolgreicher war, wäre mein Tipp, dass sich in der Version 1.4.4 ein Fehler eingeschlichen hat.

[tab]

Ich kann mich dunkel erinnern, dass sich zwischen den beiden Versionen die automatisch installierte .htaccess geändert hat. Vielleicht hängt es damit zusammen. Deine 4.4 hat jetzt vermutlich noch die .htaccess von der zuerst installierten 4.9. Denn soweit ich weiss werden bestehende .htaccess-Dateien beim Up-/Downgrade nicht überschrieben. Ansonsten eventuell mal die Logdatei anschauen, auch die error.log des Servers, ob da was zeitlich passendes drinsteht.

[Nightwing]

Denn soweit ich weiss werden bestehende .htaccess-Dateien beim Up-/Downgrade nicht überschrieben.

Richtig, sonst wären spezifische Änderungen dahin.
Einfach die .htaccess z.B. umbennen, dann wird automagisch eine aktuelle installiert.

ToM

[pipkin]

Vielen Dank.

Es liegt anscheinend aber leider nicht an der htaccess. Ich habe die Original-htaccess aus meiner funktionierenden 4.4er genommen.

(4.4 steht bei der Erstinstallation über den Contao Manager nicht mehr zur Verfügung. Man muss also zwangsweise zuerst die 4.9 installieren und dann downgraden. Wenn die zuvor frisch installierte htaccess hier schon nicht mehr passt und nicht ersetzt wird, fände ich einen Hinweis beim Downgrade sehr sinnvoll, in dem Sinne wie "Htaccess muss manuell ersetzt werden, download hier...")

Einfach die .htaccess z.B. umbennen, dann wird automagisch eine aktuelle installiert.

Obwohl der Austausch mit meiner Original-htaccess nichts bringt, habe ich sie jetzt trotzdem umbenannt. Was muss ich tun, damit eine automatisch generiert wird?

Edit: Ich habe das Contao 4.4.55 Paket aktualisiert und eine neue htaccess wurde automatisch erstellt. Der Fehler besteht weiterhin.

[Spooky]

(4.4 steht bei der Erstinstallation über den Contao Manager nicht mehr zur Verfügung. Man muss also zwangsweise zuerst die 4.9 installieren und dann downgraden.)

Nein, du kannst auch bei der Installation den Expertenmodus benutzen.

[pipkin]

Nein, du kannst auch bei der Installation den Expertenmodus benutzen.

Oh! Den kannte ich noch gar nicht. Hoffe, ich habe das nun richtig gemacht.
Installation in einem neuen, nacktes Verzeichnis, dieses Mal Expertenmodus ausgewählt.

Beim Contao-Paket habe ich 4.4.* eingetragen und dann auf aktualisieren geklickt.
1.jpg

Folgende Fehlermeldung erscheint:
2.jpg

Was bedeutet das und was mache ich falsch?




Edit:
Fortsetzung...

Im Anschluss daran forderte mich der Contao Manager auf, die Composer Abhängigkeiten zu installieren. Dies scheiterte und führte zu folgenden Fehlermeldungen in der Konsole:

> Resolving dependencies using Composer Cloud v3.1.1
!!! Current server is sponsored by: Contao Association !!!


[3.4MiB/0.14s] Loading composer repositories with package information
[47.7MiB/1.08s] Updating dependencies
[1004.1MiB/6.90s] Your requirements could not be resolved to an installable set of packages.
[1004.1MiB/6.90s] 
  Problem 1
    - contao/manager-bundle[4.11.0, ..., 4.11.2] require php ^7.3 || ^8.0 -> your php version (7.2.23.0) does not satisfy that requirement.
    - Root composer.json requires contao/manager-bundle 4.11.* -> satisfiable by contao/manager-bundle[4.11.0, 4.11.1, 4.11.2].

[1004.1MiB/6.90s] Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
[40.5MiB/7.75s] Memory usage: 40.47MB (peak: 1004.5MB), time: 7.76s.
[40.5MiB/7.75s] Finished Composer Cloud resolving.


# Cloud Job ID iWTjKOoQiYWpHrR3d8zrkouL8useRbPuWreJi1AjmwVBfxzVDJYcfjQjAhz87gOFha0nupwLza6noUwWqpliYCZJmYlohhV8XMH2diKEOCm8I8NjI2xXSR0m2iJ failed

Hier werden jetzt PHP 7.3 und Contao 4.11 vorausgesetzt.
Ich nix mehr verstehen......

[mlweb]

Wie sieht im Moment Deine composer.json aus?

Gibt es bei Dir auch eine composer.lock von Deinen Installationsversuchen?

[pipkin]

Wie sieht im Moment Deine composer.json aus?

{
    "type": "project",
    "require": {
        "contao/calendar-bundle": "4.4.*",
        "contao/comments-bundle": "4.4.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "4.4.*",
        "contao/listing-bundle": "4.4.*",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "4.4.*",
        "contao/newsletter-bundle": "4.4.*"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

Gibt es bei Dir auch eine composer.lock von Deinen Installationsversuchen?

Ja, da ich heute schon 5 neue/ frische Ansätze gemacht habe, steht da wohl nur der neueste Versuch drin. Soll ich die hier posten?

Ich habe heute mit verschiedenen Versionen experimentiert, 4.4.0, 4.4.40, 4.4.55. Ob ich es über den Expertenmodus versuche oder über 4.9 -> 4.4 machte am Ende keinen Unterschied.

Der letzte Versuch lief so:

1. Installation Expertenmodus, oben im Pulldown 4.9 ausgewählt (das macht in den nächsten Schritten einen Unterschied, wie ich gemerkt habe...)
2. Prozess läuft durch, bei den Paketen stehen erwartungsgemäß die noch nicht installierten Pakete für 4.9 bereit. Ich ändere auf 4.4.* und klicke auf Aktualisieren.
3. Fehlermeldung in der Konsole
fehler.jpg
4. Aufforderung, Composer-Abhängigkeiten zu installieren. Klicke auf "installieren".
5. Grünes Häkchen in der Konsole (Composer-Abhängigkeiten)
6. Im Contao Manager wird mir ein erfolgreich installiertes Contao Paket angezeigt: 4.9.13 !!!

(-> bis hierher kann man also festhalten, dass das direkte Installieren von 4.4 über den Expertenmodus nicht klappt, daher hätte ich am Anfang wohl gleich die 4.9 auswählen und intallieren können.)

7. Also Downgrade-Versuch auf 4.4.* -> Aktualisieren
8. Prozess läuft ohne Fehler durch, 4.4.55 ist installiert.
9. Install/ FronEnd/ BackEnd lassen sich nicht aufrufen, auch nicht nach ersetzter oder neu erzeugter htaccess.

[mlweb]

9. Install/ FronEnd/ BackEnd lassen sich nicht aufrufen, auch nicht nach ersetzter oder neu erzeugter htaccess.

Das muss dann m.E. eher andere Ursachen haben. Ich habe heute testweise mehrfach sowohl Contao 4.4 als auch Contao 4.9 installiert. Immer ohne jegliche Probleme.

Edit: Hast Du mal versucht direkt mit einer composer.json zu starten https://community.contao.org/de/show...l=1#post543978

Zum Problem im Expertenmodus hat @Spooky ein Ticket auf Github aufgemacht. https://github.com/contao/contao-manager/issues/649

Wenn Du Dir das zweite Video im Ticket anschaust, siehst Du wie Du Dein Problem schon jetzt umgehen könntest, wenn Du lieber mit dem Expertenmodus arbeiten möchtest.

[pipkin]

Das muss dann m.E. eher andere Ursachen haben. Ich habe heute testweise mehrfach sowohl Contao 4.4 als auch Contao 4.9 installiert. Immer ohne jegliche Probleme.

Das ist jetzt echt interessant... Machst Du denn etwas generell anders als ich?

[mlweb]

Das ist jetzt echt interessant... Machst Du denn etwas generell anders als ich?

Das weiß ich nicht.
Wenn man bestimmte Dinge häufiger macht, merkt man sicher manchmal gar nicht, wie man vollkommen automatisch bestimmte Klippen umschifft.

Ich habe zu meinem letzten Beitrag noch ein Nachtrag gemacht. Vielleicht hilft Dir das weiter.

[pipkin]

Edit: Hast Du mal versucht direkt mit einer composer.json zu starten

Noch nicht. Aber da es nach einem praktischen Verfahren klingt, werde ich das genau so auch probieren.
Zu welchem Zeitpunkt legst Du denn die composer.json ins Verzeichnis? Noch vor dem 1. Aufruf des Managers?

Die Klippe, auf die ich aufgelaufen bin, hast Du dann wahrscheinlich umschifft :-)

Ich gehöre zu denen, für die der Contao Manager ein eher abstrakter Zauberkasten ist und die froh sind, wenn sie beim blinden und stumpfen Befolgen einer Umzugs-Anleitung ein Erfolgserlebnis haben. Wenn da steht "erstmal installieren" und im zweiten Schritt "die neue composer.json durch die alte ersetzen", keimt zwar der Verdacht auf, dass diese Datei dem Manager eine Art To Do Liste mitgibt, aber einfach die Reihenfolge umzudrehen ... wäre mir nie eingefallen.

Zum Problem im Expertenmodus hat @Spooky ein Ticket auf Github aufgemacht. https://github.com/contao/contao-manager/issues/649

Wenn Du Dir das zweite Video im Ticket anschaust, siehst Du wie Du Dein Problem schon jetzt umgehen könntest, wenn Du lieber mit dem Expertenmodus arbeiten möchtest.

Wow!!! Ehrlich gesagt habe ich auch nie wahrgenommen, dass man da noch unterschiedliche Aktionen auswählen kann. Zudem hätte ich gedacht, dass "alle Pakete aktualisieren" dieselbe Funktion hat wie "Aktualisieren".

Ich bin für jeden Workaround auf jeden Fall dankbar!!! Nach 1,5 Tagen Panik :-)

Ich gebe Dir Recht, dass man die 4.4er nicht mehr installieren sollte - und dass man, wenn man das mit der composer.json weiß, nicht auf den Expertenmodus angewiesen ist. Allerdings - wenn es diese Funktion gibt, tappen da eben viele in dieselbe Falle wie ich. Und da die Updatewelle gewöhnlich erst mit oder sogar nach Ende des Supportzeitraums ins Rollen kommt, ist es glaube ich gut, wenn der Zauberkasten bis dahin wieder funktioniert. Für die doofen wie mich :-)

Juchu...!! Ich kann jetzt wieder die Install sehen :-)

Danke danke danke!

[tab]

So, hier die Lösung, schwere Geburt...

Nachdem der Downgrade auf 4.4 fertig ist, sind vier Dateien zu löschen, weil sie noch aus der zuvor installierten Version (4.9/4.11) stammen!

1. .htaccess
2. index.php
3. app.php
4. preview.php

Dann nochmal in den Wartungsmodus, dort
Composer-Abhängigkeiten -> Installer ausführen

Im Ergebnis hat man eine neue "alte" app.php (die eben nicht nur die index.php required), die index.php und preview.php sind weg, in der neu erstellten 4.4 .htaccess passiert die Weiterleitung auf die app.php, nicht auf die index.php wie in 4.9/4.11. Die preview.php würde eventuell nicht weiter stören, gehört aber auch nicht in eine 4.4 Installation.

Danach hat bei mir der Aufruf des Installtools funktioniert. Ich hatte vorsichtshalber auch noch die app_dev.php gelöscht und erneuern lassen, das sollte aber nicht notwendig sein, weil die erstens für den Aufruf des Installtool nicht gebraucht wird und zweitens in der 4.9/4.11 nicht mehr existiert, also eh schon beim Downgrade auf 4.4 erzeugt wurde.

[mlweb]

Wenn da steht "erstmal installieren" und im zweiten Schritt "die neue composer.json durch die alte ersetzen", keimt zwar der Verdacht auf, dass diese Datei dem Manager eine Art To Do Liste mitgibt, aber einfach die Reihenfolge umzudrehen ... wäre mir nie eingefallen.

Kann man ohne weiteres so machen. Mache ich eigentlich immer so. In der composer.json steht im Prinzip drin, was installiert werden soll.

Wow!!! Ehrlich gesagt habe ich auch nie wahrgenommen, dass man da noch unterschiedliche Aktionen auswählen kann.

Das wundert mich nicht. Dieses Feature ist erst kürzlich in der Version 1.4.3 hinzugekommen.

Dieser untere Button ist vor allem zur leichteren Bedienbarkeit dazu gekommen, wenn man bei einer Installation eine Erweiterung zusätzlich installieren möchte und eben auch alle Pakete aktualisieren sollte/möchte.
Vorher musste man entweder alle Pakete einzeln auswählen oder zuerst alle Pakete aktualisieren klicken und erst dann die Erweiterung hinzufügen.

Zudem hätte ich gedacht, dass "alle Pakete aktualisieren" dieselbe Funktion hat wie "Aktualisieren".

Sollte es eigentlich auch. Tut es aber im Expertenmodus bei Änderung auf die Version 4.4 offensichtlich nicht. Deswegen auch die Fehlermeldung von @Spooky auf Github.

[mlweb]

@tab
Den Downgrade halte ich ehrlich gesagt für ein Workflow von hinten durch die Brust ins Auge.

Eine composer.json ist deutlich schneller erstellt. Danach läuft die Installation von contao 4.4
Im Expertenmodus geht es auch einfacher, siehe das 2.Video von Spooky https://github.com/contao/contao-manager/issues/649
Der jetzt noch vorhandene Fehler (1. Video) ist als Bug erkannt und wird sicher schnell behoben.

[tab]

Ah, Spooky hat schon Videos gedreht , spooky!
Ja, composer.json zu benutzen halte ich auch für zielführender als ein Downgrade. Mir ging es eher darum herauszufinden, warum das Downgrade nicht funktioniert. Im Nachhinein wie immer sonnenklar, da hätte ich auch gleich drauf kommen können.

[pipkin]

So, hier die Lösung, schwere Geburt...

Hey, dann haben wir jetzt einen Workaround für beide Verfahren: Downgrade UND Expertenmodus...

Ihr seid klasse.

Dass der Downgrade funktioniert könnte ja auch noch wichtig sein. Szenario: man macht ein Update auf 4.9 und erkennt erst nach Einpflege von Inhalten, Arbeiten an Layouts etc., dass irgendwas nicht funktioniert und muss kurzfristig wieder doch wieder auf die 4.4er zurück. Da wäre es sinnvoll, auf diese Funktion zurück greifen zu können.

[tab]

Hey, dann haben wir jetzt einen Workaround für beide Verfahren: Downgrade UND Expertenmodus...

Ihr seid klasse.

Dass der Downgrade funktioniert könnte ja auch noch wichtig sein. Szenario: man macht ein Update auf 4.9 und erkennt erst nach Einpflege von Inhalten, Arbeiten an Layouts etc., dass irgendwas nicht funktioniert und muss kurzfristig wieder doch wieder auf die 4.4er zurück. Da wäre es sinnvoll, auf diese Funktion zurück greifen zu können.

Da würde ich mich nicht drauf verlassen. Bei einem Update von etwa 4.4 auf 4.9 werden vom Installtool wahrscheinlich Anpassungen an der Datenbank vorgenommen, die über einfache zusätzliche Spalten und Tabellen rausgehen. Also eine echte Migration von Daten, die über die reine Anpassung des Datenbankschemas an die neuen Erfordernisse hinausgeht. War bei den 3.x Versionen auch schon so. Dafür gibt es spezielle Migrationsskripte, die beim Update im Installtool ausgeführt werden. Bei einem Downgrade gibt es solche Skripte nicht. Hier wird nur das Datenbankschema angepasst. Manche Änderungen in den Daten können auch einfach gar nicht rückgängig gemacht werden. Z.B. wenn die höhere Version eine Spalte der Tabelle nicht mehr braucht, dann wird sie eben gelöscht. Wenn du dann zurückgehen willst, hast du aber die ursprünglichen Werte nicht mehr. Man muss also zumindest damit rechnen, dass nach einem Update mit anschliessendem Downgrade die Datenbank nicht mehr identisch zur ursprünglichen Datenbank ist. Das muss nicht sein, ist aber immer möglich. Also besser vorher ein Datenbank-Backup machen, dann kann man den Originalzustand notfalls wieder herstellen. ALso bei so einem Versionssprung besser vorher Datenbank sowie composer.json, composer.lock und Konfigurationsdateien sichern. Sonst kann es hinterher bitter werden. Am besten natürlich ein solches Update an einer Kopie der Installation mit einer anderen Datenbank durchführen, Dann hast du das unveränderte Original notfalls noch.

[pipkin]

Also eine echte Migration von Daten, die über die reine Anpassung des Datenbankschemas an die neuen Erfordernisse hinausgeht. War bei den 3.x Versionen auch schon so.

Danke für den Hinweis, ich hielt Minor-Updates für weniger kritisch, aber ich hab das wohl unterschätzt...

Also besser vorher ein Datenbank-Backup machen

Das mach ich sowieso immer.. mehr noch: ich vergewissere mich, dass das Backup auch funktioniert (hatte leider schon die Erfahrung gemacht, dass Datenbank-Dumps vermurkst waren). Deswegen erstelle ich bei solchen Sachen immer erstmal eine 1:1 Kopie. Womit der Thread hier seinen Anfang nahm :-)

[mlweb]

. Deswegen erstelle ich bei solchen Sachen immer erstmal eine 1:1 Kopie.

Bei Minor-Updates teste ich das Update eigentlich immer in einer Parallelinstallation. Nur Bugfixes- und Security-Updates spiele ich in der Live-Version direkt ein (natürlich mit vorhandenem Backup).
Da ich bei allen Installationen bei denen das möglich ist auch eine tägliche Sicherung der Datenbank und der spezifischen Daten laufen habe, kontrolliere ich dort das manuelle Backup allerdings nicht noch mal extra. Es sind dann inkl. der Backups beim Provider wirklich genügend Rückfallebenen vorhanden.