einer von vielen: Conato-Manager bleibt hängen

[purzel]

Hallo zusammen,

wie schon einige andere habe ich (mal wieder) Probleme mit dem Contao-Manager - mein Hoster ist Goneo

Nach langer Zeit (*schäm*) wollte ich endlich mal wieder Updates einspielen, habe den Contao-Manager aufgerufen. Dieser wollte sich aktualisieren, was anscheinend auch geglappt hat: er meldet jetzt Version 1.4.2.
Die ersten vier grünen Haken kommen relativ schnell:
PHP-Webprozess
PHP Version 7.4.16, keine bekannten Probleme gefunden.

Serverkonfiguration
PHP-Binary in /usr/local/bin/php.

?Ändern
PHP Kommandozeilen-Programm
PHP Version 7.4.16, keine bekannten Probleme gefunden.

Updates für den Contao Manager
Du verwendest die aktuelle Version 1.4.2.

Der nächste
Composer-Umgebung
Keine bekannten Probleme gefunden.
braucht schon einige Minuten, meist so 5-10.

Dann aber bleibt es bei
Contao-Installation
Analysiere …
hängen, nach unterschiedlichen Zeiten, bis zu 20 Minuten habe ich abgebrochen und wie schon hier irgendwo empfohlen, F5 gedrückt. Das selbe Spiel wieder. Auch die Verwendung der "Composer Resolver Cloud" habe ich mal deaktiviert - keine Verbesserung. Wie lange "darf" das dauern bzw. was kann ich tun?
Gibt es Erfahrungen mit Goneo die ich in diesem Zusammenhang noch nicht gefunden habe?
Braucht es noch mehr Informationen von mir zur Diagnose?

TIA
purzel

[tab]

Dann aber bleibt es bei
Contao-Installation
Analysiere …
hängen, nach unterschiedlichen Zeiten, bis zu 20 Minuten habe ich abgebrochen und wie schon hier irgendwo empfohlen, F5 gedrückt. Das selbe Spiel wieder. Auch die Verwendung der "Composer Resolver Cloud" habe ich mal deaktiviert - keine Verbesserung. Wie lange "darf" das dauern bzw. was kann ich tun?
Gibt es Erfahrungen mit Goneo die ich in diesem Zusammenhang noch nicht gefunden habe?
Braucht es noch mehr Informationen von mir zur Diagnose?

TIA
purzel

Sollte eigentlich alles eher im Sekundenbereich angesiedelt sein als Minuten. Die Resolver Cloud zu deaktivieren ist an dieser Stelle noch nicht relevant, da sie erst beim Update der Pakete ins Spiel kommt.

[purzel]

Inzwischen habe ich unter https://community.contao.org/de/show...r-1-4-1-Update anscheinend einen "Leidensgenossen" gefunden. Er hat wohl (Teil-)Erfolge mit einer "Rückstufung" von PHP 7.4 auf 7.3 erreichen können - dann läuft auch bei mir die Systemprüfung vom Manager ziemlich zügig durch. Anscheinend ist er nicht so ganz kompatibel mit 7.4 - zumindest im Fall Goneo.
Das dort von Spooky erwähnte "Konsolenausgabe anzeigen/verstecken" fehlt bei mir auch. Außerdem weiß man ja nicht, wie es bei ihm ausgegangen ist
Nun habe ich allerdings Angst, auf "Aktualisieren" zu klicken - was ist wenn die neue Version (4.4.55 gegenüber 4.4.49) mehr schadet als nützt? Ich meine, "früher" gab es einen Button zum Simulieren des Update. Es ist das Produktiv System...

Und was hat es zu bedeuten, wenn bei einer Komponente steht, dass ich sie von 1.6.0.5 auf eine "unbekannte Version" aktualisieren könnte? Da traue ich mich noch viel weniger...

[mlweb]

Ganz grundsätzlich ist der Manager mit PHP 7.4 natürlich kompatibel. Wenn dann liegen die Probleme eher in speziellen Konfigurationen der Provider.
Wenn ich mir unsicher bei einem Update bin, dann mach ich das grundsätzlich nicht in der Live-Version der Website, sondern idealerweise in einer parallel aufgesetzten identischen Installation.
Im Normalfall mache ich vor einem Update ein aktuelles Backup, so dass ich den ursprünglichen Zustand in kürzester Zeit wieder herstellen kann.
Davon abgesehen gibt es die Simulation des Updates ja noch immer. Sobald Du Pakete zum aktualisieren ausgewählt erscheint am unteren Rand eine Leiste mit "Testlauf", Änderungen anwenden" und "Änderungen verwerfen"

[purzel]

Ah, danke.
Dann werde ich wohl auf jeden Fall vorher eine Sicherung machen, denn... es geht wohl schief, siehe unten.
DIesen "Testlauf" Button hatte ich wohl "zeitlich" an der falschen Stelle in Erinnerung - er kam natürlich nach Klick auf "Aktualisieren".
Da klickte ich drauf und DANN konnte ich auch wählen "Vollständige Konsole anzeigen". Leider ging's wohl schief:

1 $ /usr/local/phpfarm/inst/php-7.3.27/bin/php -q -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /(entfernt)/htdocs/LIVE/web/contao-manager.phar.php composer update contao/manager-bundle contao/news-bundle contao/calendar-bundle contao/faq-bundle contao/comments-bundle contao/newsletter-bundle contao/listing-bundle contao/conflicts contao/core-bundle contao/installation-bundle --with-dependencies --prefer-dist --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader --dry-run
2
3 The "contao-community-alliance/composer-plugin" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
4 Loading composer repositories with package information
5 Dependency "contao-components/mootools" is also a root requirement. Package has not been listed as an update argument, so keeping locked at old version. Use --with-all-dependencies (-W) to include root dependencies.
6 Updating dependencies
7 Your requirements could not be resolved to an installable set of packages.
8 
9 Problem 1
10  - contao-community-alliance/composer-plugin 3.0.9 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.0.0] but it does not match the constraint.
11  - cliffparnitzky/tiny-mce-bundle-classic 1.2.1 requires contao-community-alliance/composer-plugin ~3.0 -> satisfiable by contao-community-alliance/composer-plugin[3.0.9].
12  - cliffparnitzky/tiny-mce-bundle-classic is locked to version 1.2.1 and an update of this package was not requested.
13
14  You are using Composer 2, which some of your plugins seem to be incompatible with. Make sure you update your plugins or report a plugin-issue to ask them to support Composer 2.
15  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.
16
17 # Process terminated with exit code 2
18 # Result: Misuse of shell builtins

Möglicherweise läufts besser, wenn ich mit dem tiny-mce-bundle beginne - bei DEM läuft der Testlauf fehlerfrei durch. Trotzdem werde ich erstmal sichern. Aber heute wird mir das zu knapp - schade eigentlich...

[mlweb]

In dem Fall auch noch zu beachten https://contao.org/de/news/contao-manager-1-4.html

Dein angezeigter Fehler zeigt, genau das Problem.

Im Übrigen solltest Du nur im absoluten Ausnahmefall Erweiterungen einzeln aktualisieren. Da Dir der Composer ja die Abhängigkeiten auflösen soll, ist ein solches Vorgehen m.E. meist nicht zielführend.

[purzel]

Hallo auch hier,

Da ich - nach endlich dem Upgrade auf 4.9 - ebenfalls den https://community.contao.org/de/show...799#post536799 Fehler habe:

... Also habe ich wieder auf PHP 7.3 zurück gestellt, offenbar ist die Konstellation CM + PHP 7.4 + Goneo ein bisschen, ahäm, "suboptimal"
Das auf https://contao.org/de/news/contao-manager-1-4.html erwähnte "Composer Update ausführen" habe ich übrigens gemacht, bringt aber nix. Alles im CM sagt "neueste Version".

Das zweifelhafte mootools mit "unbekannter Version" habe ich übrigens inzwischen entfernt.

[purzel]

Hallo, guten Morgen und erstmal alles Gute zum neuen Jahr!

Nachdem der Thread mit dem anderen Problem (https://community.contao.org/de/show...-Wartungsmodus) etwas abgedriftet ist wollte ich lieber HIER mal zurück zum Thema kommen. Lange habe ich gedacht, irgendwas an meiner Installation sei nicht so ganz OK, weswegen dieses Thema hier überhaupt ins Leben gerufen wurde.

Inzwischen ist die oben erwähnte Installation zwar auf 4.9(.24) angehoben, aber das ebenfalls oben erwähnte Problem bleibt: Mit PHP 7.4 kommen die ersten vier grünen Haken (PHP-Webprozess, Serverkonfiguration, PHP Kommandozeilen-Programm, Updates für den Contao Manager) relativ schnell, der für Composer-Umgebung braucht mindestens 5-10 Minuten und auf den Letzten (Contao-Installation) kann ich bis zum St. Nimmerleinstag warten

Jetzt wird's spannend: ich habe mal unter PHP 7.4 mittels CM eine ganz frische, leere, "nackte" Contao 4.9 Installation gemacht - die lief in "gefühlt vertretbarer" Zeit komplett durch. Dann kam die Ernüchterung: das zuvor beschriebene Problem mit dem Hängenbleiben des CM ist auch mit DER Installation. Es kann also nicht an meiner von 4.4. auf 4.9 hochgezogenen Installation liegen!
Offenbar ist PHP 7.4 bei Goneo mit Contao und/oder dem ContaoManager inkompatibel. Was mache ich nun? Eine Weile könnte ich ja noch bei PHP 7.3 bleiben, aber eigentlich will ich das ja nicht...

[Spooky]

Ansonsten Hoster Wechsel

[tab]

Naja, was das Hosting mit PHP 7.3 erlaubt, sollte Goneo ja auch nicht absichtlich bei PHP 7.4 verschlechtern. Gibt es denn zu den Versuchen mit PHP 7.4 und der frischen Installation keinerlei Fehler in irgendwelchen Logs? Oder das konkrete Problem dem Support mitteilen, wobei natürlich die Gefahr besteht, dass ihnen Contao-Manager + Contao-Installation ein zu komplexes Szenario für die Suche nach dem Fehler ist und sie das dann eben auf Contao schieben, obwohl wahrscheinlich nur die eine oder andere PHP-Einstellung bei 7.4 verrutscht ist. Irgendwelche Caches nicht aktiviert oder was auch immer, das kann ohne weiteres auch auf die spezielle Verwendung von PHP beschränkt sein, die der Contao-Manager an dieser Stelle nutzt. Wie sieht es denn mit PHP 8 aus? Irgendwo hast du zwar geschrieben, dass das wegen irgendeiner Erweiterung nicht klaptt, aber wie sieht es da bei einer frischen Installation aus? Wenn der Contao-Manager da normal funktioniert, hat man schon wieder ein Stückchen Info mehr über das Problem und ein Argument mehr gegenüber dem Goneo-Support, so dass die sich das Problem mit PHP 7.4 vielleicht doch ernsthaft anschauen.

[purzel]

Hoster Wechsel fänd' ich nicht so gut - bin seit Jahren sehr zufrieden.

Ich mache gerade eine ganz blanke, neue Installation inkl. komplett leerer DB. Mal abwarten... Vielleicht habe ich gestern doch noch irgendwas anders gemacht, war ja schon spät.
Ich seh' schon zu, möglichst detailiert alles zu posten in der Hoffnung dass Ihr mir dadurch helfen könnt.

@tab: Die Idee, mich an den Support von Goneo zu wenden, hatte ich auch bereits - nur ohne aussagekräftige Fehlermeldungen oder -beschreibungen ist es halt schwierig. Nach was sollen sie suchen. Ich kann mich erinnern, dass vor Jahren mal ein ähnlich geartetes Problem war welches sie halbwegs zügig beseitigen konnten. Deswegen hoffe ich ja auf zumindest "irgendwas" was ich denen sagen (schreiben) kann.

Mit PHP 8, in der Tat, lief zwar der CM, aber dafür weder FE noch BE - wenn die ICAL Erweiterung von craffft installiert war. Das werde ich
1. später auch nochmal gezielt mit der o.g. frischen Installation (*) testen falls die wieder mit PHP 7.4 fehlschlägt (ich rechne fest damit)
2. dann aber dem Entwickler in einem neuen Thread mitteilen; vielleicht hat er Lust die Erweiterung für PHP 8 tauglich zu machen

{später}
So, die frische Installation ist soweit durch, dass er die Datenbank aktualisieren will. KLicke ich darauf, will er die MySQL Verbindungsdaten haben - und dann bricht es ab. Log:

[2022-01-01 14:02:12] request.INFO: Matched route "contao_install". {"route":"contao_install","route_parameters":{"_route":"contao_install","_scope":"backend","_token_check":true,"_controller":"Contao\\InstallationBundle\\Controller\\InstallationController::installAction"},"request_uri":"https://neu.tld.de/contao/install","method":"GET"} []
[2022-01-01 14:02:12] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\TableNotFoundException: "An exception occurred while executing 'SELECT * FROM tl_user WHERE `username`='root' LIMIT 0,1':  SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist" at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 61 {"exception":"[object] (Doctrine\\DBAL\\Exception\\TableNotFoundException(code: 0): An exception occurred while executing 'SELECT * FROM tl_user WHERE `username`='root' LIMIT 0,1':\n\nSQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:61, Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 42S02): SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php:18, PDOException(code: 42S02): SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:141)"} []

Aber ich hatte die Daten (name, user, passwort) zur DB richtig angegeben und in config/parameters.yml hat der Installer es auch richtig eingetragen.

Bereits in diesem "halbfertigen" Zustand (die DB ist in der Tat noch leer) macht der CM die anfangs und zwischendurch immer wieder erläuterten Zicken (Schritt 5 dauert lange bis hin zu klappt gar nicht, Schritt 6 kriegte er noch nie hin mit PHP 7.4, außer eben VOR der frischen Installation)

{nochmal gute 10 Min. später}
konnte ich das Installtool erneut aufrufen (ging vorher nicht) und dann wollte er auch die Tabellen anlegen usw. (Fast) alles gut. Es gab zwar noch die Warnung mit dem Strict mode, darauf habe ich ihm noch diese config/config.yml gegeben - und musse den cache auf der Kommandozeile (SSH) löschen un neu aufbauen; das geht immerhin.

Nun habe ich also eine frische, nackte 4.9.24 Installation ohne Addons, Inhalte Styles usw. - lediglich mit Admin-Konto ... und der CM zickt. Siehe oben.

Leider habe ich im Moment keine Zeit mehr für den Test mit PHP 8.


(*) Wieso steht da eigentlich was von "managed edition" wenn ich das installiere?

[Spooky]

So, die frische Installation ist soweit durch, dass er die Datenbank aktualisieren will. KLicke ich darauf, will er die MySQL Verbindungsdaten haben - und dann bricht es ab. Log:

[2022-01-01 14:02:12] request.INFO: Matched route "contao_install". {"route":"contao_install","route_parameters":{"_route":"contao_install","_scope":"backend","_token_check":true,"_controller":"Contao\\InstallationBundle\\Controller\\InstallationController::installAction"},"request_uri":"https://neu.tld.de/contao/install","method":"GET"} []
[2022-01-01 14:02:12] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\TableNotFoundException: "An exception occurred while executing 'SELECT * FROM tl_user WHERE `username`='root' LIMIT 0,1':  SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist" at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 61 {"exception":"[object] (Doctrine\\DBAL\\Exception\\TableNotFoundException(code: 0): An exception occurred while executing 'SELECT * FROM tl_user WHERE `username`='root' LIMIT 0,1':\n\nSQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:61, Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 42S02): SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php:18, PDOException(code: 42S02): SQLSTATE[42S02]: Base table or view not found: 1146 Table '****6.tl_user' doesn't exist at /data/****/htdocs/TEST_4.9/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:141)"} []

Nutze den Debug-Modus und poste den Stack Trace zu diesem Fehler.

[purzel]

Nutze den Debug-Modus und poste den Stack Trace zu diesem Fehler.

Wäre der in dem Zustand schon gegangen? Wenn ja wie? Es gab zu dem Zeitpunkt ja noch kein Admin-Konto in der DB. Kommandozeile?
Wie gesagt, das kam während einer kompletten NEUinstallation.

Um das erneut zu bekommen müsste ich ja NOCHMAL neu installieren weil

...
{nochmal gute 10 Min. später}
konnte ich das Installtool erneut aufrufen (ging vorher nicht) und dann wollte er auch die Tabellen anlegen usw. (Fast) alles gut. Es gab zwar noch die Warnung mit dem Strict mode, darauf habe ich ihm noch diese config/config.yml gegeben - und musste den cache auf der Kommandozeile (SSH) löschen und neu aufbauen; das geht immerhin.

Nun habe ich also eine frische, nackte 4.9.24 Installation ohne Addons, Inhalte Styles usw. - lediglich mit Admin-Konto ... und der CM zickt.
...

Ich mein' das absolut nicht böse, bin ja dankbar, dass Du versuchst zu helfen - aber bei manchen Vorschlägen (konkret dies' Mal ein knappes "Nutze den Debug-Modus") fühle ich mich überfordert. Nicht jede*r ist ein wandelndes Contao Lexikon Wie gesagt, nicht bös' gemeint!

Beim vorgenannten frisch installierte Contao 4.9 kann ich mich im BE anmelden. Das FE liefert mit und ohne Wartungsmodus, egal ob im BE angemeldet oder nicht, einen 404 Fehler (logisch irgendwie - es gibt ja keine Inhalte). Der CM eiert aber schon wieder fast 'ne halbe Stunde beim letzten Schritt ("Contao-Installation Analysiere …") rum. Leider kann man in dem Zustand keine Details sehen - oder doch? Wenn ja, wie??? Im Log ist jedenfalls nichts.

Ich stelle nun mal auf PHP 8 um und melde mich wieder...

[Spooky]

Wie du den Debug-Modus aktivieren kannst, findest du im Handbuch: https://docs.contao.org/manual/de/sy...en-debug-modus

[purzel]

OK... ich habe nun die relevanten Bereiche (Contao > 4.8) überflogen.

Das scheint davon auszugehen, dass man schon eine (halbwegs) funktionierende Installation hat - wenn auch ggf. fehlerhaft.

Die hatte ich aber zu dem Zeitpunkt noch nicht, weil die SQL-Datenbank komplett LEER war, also auch keine Tabellen.

Nach ca. 10 Minuten kam ich dann (ohne den Fehler!) weiter, konnte die Tabellen in der DB erstellen lassen und die Installation läuft - wie gesagt OHNE den Fehler für den ich ein Stack Trace machen soll.

Soll ich also, nur um den Fehler zu reproduzieren, NOCHMAL neu installieren? Bringt (mir) das was? Außerdem müsste ich dann womöglich schnell sein: siehe oben, "ca. 10 Minuten".

Das ist meiner Meinung nach die völlig falsche Stelle: die Neu-Installation habe ich doch nur gemacht, um zu testen ob der CM mit PHP 7.4 auch in einer "jungfräulichen" Installation hängen bleibt. Und das tut er

Mir ist viieel mehr daran gelegen, die bestehende Instanz zum Laufen zu kriegen - "notfalls" mit PHP 8.

Damit hängt der CM nicht, auch die Installation meiner beiden Erweiterungen (ja, beide! (*)) "überleben" PHP 8. Ich habe keine Ahnung, was ich gestern anders gemacht habe.

Leider kriege ich es nicht hin, "mal eben auf die Schnelle" eine simple Hello-World-Seite im BE der frisch installierten Instanz zu bauen damit der 404 Fehler verschwindet.
Dazu müsste ich wahrscheinlich wieder tonnenweise Doku lesen - was IMHO am Problem vorbei ist: Ich HABE eine Seite, die (mit PHP 7.3 und Contao 4.4) prima läuft. Die soll einfach nur auf modernere Versionen aktualisiert werden.





(*) "TinyMCE Bundle classic" und "iCal Kalender"

[Spooky]

Das scheint davon auszugehen, dass man schon eine (halbwegs) funktionierende Installation hat - wenn auch ggf. fehlerhaft.

Die hatte ich aber zu dem Zeitpunkt noch nicht, weil die SQL-Datenbank komplett LEER war, also auch keine Tabellen.

Nein, auch zu diesem Zeitpunkt kannst du den Debug-Modus bereits aktivieren.

[purzel]

Gut, dann weiß ich das jetzt - falls ich wider Erwarten doch nochmal neu installieren sollte und der Fehler erneut kommt und NICHT von allein verschwindet.

Da der Fehler aber nur einmal kurz aufgetreten ist und seit dem nie wieder halte ich es momentan für sinnarm, ihm nachzujagen - zumal die Meldung im Log doch m.E. hinreichend aussagekräftig ist: "An exception occurred while executing 'SELECT * FROM tl_user WHERE `username`='root'..."
Für meine Begriffe versucht der Installer da erstens mit falschen Credentials auf eine zweitens nicht existierende Tabelle in der DB zuzugreifen.

Wie gesagt, nach den besagten ca. 10 Minuten hat es doch geklappt.

Ich überlege jetzt wie ich weiter vorgehe. Mir fallen zwei Dinge ein:
a) der frischen, noch "nackten" Installation meine (Kopie der) DB aus der bestehenden Installation unterzuschieben
b) die mit PHP 7.3 funktionierende (Kopie der) Contao Installation 4.4 erst auf PHP 8 umzustellen und dann alle Pakete zu aktualisieren

Vielleicht kann ich mir ja eines (oder bedes? *schauder*) sparen weil es sowieso zum Scheitern verurteilt ist...

[mlweb]

Ich muss ehrlich sagen, dass ich bei den vielen unterschiedlichen Versuchen mit x verschiedenen Fehlerbildern und nie zu Ende geführter Fehleranalyse langsam nicht mehr durchsehe.
Wie schon von @Spooky vorgeschlagen, wäre es sehr hilfreich einem Fehler konsequent und ohne Veränderung irgendwelcher Parameter nachzugehen.

Wenn ich es noch richtig im Gedächtnis habe, läuft Dein Contao Manager mit PHP 7.4 nicht korrekt. Da die von Dir benötigten Erweiterungen (noch) nicht alle mit PHP 8 kompatibel sind, sollte damit die Wahl der PHP Version schon mal klar sein - PHP 7.4 und damit ist dann auch klar, dass Du das Problem mit dem Manager und PHP 7.4 lösen musst.
Du hast jetzt eine neue leere Installation mit PHP 7.4, bei der Du auch ins Backend kommst, richtig?
Wenn das so ist, dann rufe das Backend auf, stelle den Debug-Modus ein, führe den Contao Manager aus und poste den Stack-Trace hier.
Gleichzeitig schau Dir das Error-Log Deines Hostings und poste ggf. die Fehlermeldung hier.

Da der Contao Manager mit PHP 7.3 und PHP 8 funktioniert, aber nicht mit PHP 7.4 wäre das schon mal eine Info zur Fehleranalyse beim Hoster (wurde glaube ich von @tab schon so vorgeschlagen).

[purzel]

In der Tat läuft bei mir der CM mit PHP 7.4 nicht korrekt, bleibt beim letzten Schritt "Contao-Installation Analysiere …" hängen. Das ist genau Kern dieses Threads.

Die vielleicht nicht zu PHP8 kompatible Erweiterung konnte ich anscheinend dementieren, siehe #15. Ob sie auch wirklich funktioniert kann ich im Moment nicht testen, weil die "jungfräuliche" Installation keine Inhalte hat.

Und ja, ich habe eine (fast) leere Installation die mit PHP 7.4 läuft und (inzwischen) eine Kopie davon die mit PHP 8 läuft.
In letzterer habe ich alle Pakete aktualisiert, weil da ja der CM funktioniert.
In der 7.4er habe ich das natürlich nicht gemacht, weil ich erstens davon ausgehe dass bei einer frischen Installation via CM schon die aktuellsten Sachen geladen werden und zweitens bleibt ja der CM beim letzten Schritt hängen. Per Kommandozeile müsste das das Aktualisieren aller Pakete doch auch gehen? Wie?

Beide haben Zugriff auf dieselbe DB konfiguriert, das sollte ich noch ändern (DB kopieren).

Weiterhin komme ich bei beiden ins Backend, ja. Frontend kann ich nicht testen weil ja keine Inhalte da sind.

Mit Deiner Anweisung

Wenn das so ist, dann rufe das Backend auf, stelle den Debug-Modus ein, führe den Contao Manager aus und poste den Stack-Trace hier.

stehe ich allerdings ein bisschen auf dem Schlauch. Ich bekomme im BE den Debugmode aktiviert, kein Problem - am unteren Rand erscheint dann diese Zeile.
Wenn ich dann links im Menü den Contao Manager anklicke gibt es ja zwei Möglichkeiten:
- im SELBEN Fenster/Tab: dann verschwindet diese Symfony-Zeile
- im NEUEN Fenster/Tab: dann bleibt die Zeile zwar, es passiert aber nix da drin (warum sollte sie sich auch um ein anderes Fenster kümmern)
Ergo brauche ich hier etwas genauere Anweisungen, offenbar mache ich hierbei schon irgendwas falsch.

Die Logs vom Hoster könnten noch was bringen, gute Idee. Die bekomme ich allerdings immer nur einmal täglich in der Nacht und ich sollte dann vermeiden, so viel zu experimentieren damit sie nicht so vollgespamt werden.
Eine kurze Sichtung der bestehenden Files bescherte allerdings: es sind nur die access Logs, nicht die error Logs - hilft uns das?

Im Log vom CM fand ich immerhin gerade:
[01-Jan-2022 23:58:25 Europe/Berlin] [2022-01-01 23:58:25] app.ERROR: The process "'/usr/local/bin/php' '-q' '/data/****/htdocs/TEST_4.9_PHP74/web/contao-manager.phar.php' 'test'" exceeded the timeout of 60 seconds. {"exception":"[object] (Symfony\\Component\\Process\\Exception\\ProcessTi medOutException(code: 0): The process "'/usr/local/bin/php' '-q' '/data/****/htdocs/TEST_4.9_PHP74/web/contao-manager.phar.php' 'test'" exceeded the timeout of 60 seconds. at phar:///data/****/htdocs/TEST_4.9_PHP74/web/contao-manager.phar.php/vendor/symfony/process/Process.php:1267)"} []

[mlweb]

Ok mein Fehler. Im Manager gibt es tatsächlich keinen Stack Trace nur im Installtool, Backend und Frontend.
Aber der Log des Managers bringt Dich ja schon weiter.
Sieht so als ob die max_execution_time von 60s nicht ausreicht. Ich denke die sollte man erhöhen.
Du kannst über phpinfo()auch die Einstellungen bei php 7.4 mit denen bei PHP 7.3 und PHP 8 vergleichen.
Das Problem tritt bei Dir doch schon bei der Systemüberprüfung auf, oder? Also ohne, dass Du versuchst zu Aktualisieren etc.

Nur zur Sicherheit - welche Version hat Dein Contao-Manager?
Eigentlich sollte der sich ja immer selbst updaten und damit auch immer aktuell sein, aber man weiß ja nie...

[purzel]

Tagchen

Bzgl. Stack Trace dachte ich schon ich sei mal wieder zu blöd (oder hektisch)

Die max_execution_time ist laut phpinfo(); bei allen 3 bei Goneo (derzeit) zur Verfügung stehenden PHP Versionen (7.3.27 / 7.4.24 / 8.0.10) gleich: 240s. Passt m.E. nicht so ganz zur Fehlermeldung. Sind die 60 Sek. irgendwo im CM "verankert"?

Und ja, der Fehler (hängenbleiben) tritt schon bei der Systemüberprüfung - zur Erinnerung: siehe Posting #1 - auf. Aber nur bei Nutzung von PHP 7.4

Der CM hat die Version 1.4.10 und hat sich in der Tat immer mal wieder selbst aktualisiert.

--------------------------

Auch wenn Ihr es vielleicht nicht ganz so gern seht: parallel habe ich tatsächlich auch mal

a) der frischen, noch "nackten" Installation meine (Kopie der) DB aus der bestehenden Installation unterzuschieben

probiert, hier die auf PHP 8 basierende Variante genommen. Denn

... die bestehende Instanz zum Laufen zu kriegen - "notfalls" mit PHP 8.
Damit hängt der CM nicht, auch die Installation meiner beiden Erweiterungen (ja, beide! ("TinyMCE Bundle classic" und "iCal Kalender")) "überleben" PHP 8.

Nachdem ich artig "alle Nas lang" via CM den Cache erneuert habe (scheint elementar zu sein) funktioniert schon vieles:
- BE geht
- der Fehler des anderen Threads https://community.contao.org/de/show...-Wartungsmodus scheint weg zu sein
- das FE zeigt Inhalte, auch wenn ich NICHT im BE angemeldet bin und der Wartungsmodus aus ist
ABER:
- leider ist die Erweiterung "iCal Kalender" doch noch nicht PHP 8 kompatibel (*)
- weder im Frontend (**) noch im Backend (***) werden meine CSS Dateien benutzt - warum?

Sollten wir lieber diesen Weg weiter gehen?

(*) (mindestens) weil in der PHP Funktion implode() beim "Upgrade" von PHP 7.4 auf PHP 8 die Parameter getauscht wurden. Das habe ich in der im Log erwähnten php Datei mal geändert (ist nicht Update safe, weiß ich). Ob noch mehr im Argen ist werde ich (vielleicht) sehen... Dies ist jedenfalls was für den Erweiterungen-Bereich oder direkt den Entwickler. Das wäre im Moment sogar zu verschmerzen, denn die Erweiterung benutze ich immer nur einmal im Jahr im November zum Import einer größeren *.ics Datei für die Events.
(**) In Themes -> Stylesheets ist eine Infobox: Der interne CSS-Editor ist veraltet und wird in Contao 5.0 entfernt! Bitte erwägen Sie, Ihre bestehenden Stylesheets zu exportieren und sie als externe Stylesheets im Seitenlayout einzubinden.
Darunter sind meine Stylesheets aufgelistet. Muss ich mit denen noch zusätzlich was machen was in der 4.4 noch nicht nötig war?
(***) abgelegt in files/backend/*.css - die 4.4er Installation benutzt diese Stylesheets artig

[Spooky]

Hast du den Ordner "backend" im Dateimanager veröffentlicht?

[purzel]

Ja, "Öffentlich" ist angehakt wenn Du das meinst.

[purzel]

Waahhh!
Ich bin so blöd: das Verzeichnis files lag an der falschen Stelle:
in der alten (noch aktiven) Instanz ist "oberhalb" von /web ein Verzeichnis files, da ist so ziemlich alles drin. "innerhalb" von /web gibt es ein files, da sind nur drei Symlinks. Ich hatte das gesamte files in /web liegen.

Jetzt fehlt anscheinend "nur" noch das (Mootools) Hauptmenü und die NUtzung meiner Styles (FE und BE).

Sowohl Contaos Prod.-Cache als auch meinen Browser Cache habe ich schon gelöscht/erneuert.

[purzel]

Neuer Zwischenstand:

...
- weder im Frontend (**) noch im Backend (***) werden meine CSS Dateien benutzt - warum?
...
(***) abgelegt in files/backend/*.css - die 4.4er Installation benutzt diese Stylesheets artig

Erster Erfolg: Im Backend geht's wieder. In der alten (4.4) Installation gab es app/Resources/contao/config/config.php mit Inhalt

<?php
if (TL_MODE == 'BE')
{
  $GLOBALS['TL_CSS'][] = 'files/backend/be_styles.css';
}

Die Datei muss jetzt (4.9) wohl in system/config/ stehen und initconfig.php heißen.

{später}
Das ist ja eigenartig: in der alten Instanz liegt - archaisch bedingt - noch das CSS "music_academy" aus Typolight (!) Zeiten rum, ich habe es nie gelöscht. Es ist jedoch in keinem Layout angekreuzt. Da das in der neuen Instanz ja nicht mehr da ist (weil "leer" installiert) habe ich einfach mal - trial'n'error - das antike Ding in der 4.4 exportiert und in die 4.9 importiert. Auch hier wieder nirgends angekreuzt.
Zweiter Erfolg: Trotzdem ist das Design jetzt anscheinend richtig.

Allerdings fehlt noch das Hauptmenü, das war als Mootools-Accordion (auf PC, am Händi nicht - das soll so). Dazu habe ich in den Frontend-Modulen bisher (4.4) ein Modul im Einsatz, welches da heißt "Navigation (mootools)" und als Modultyp ist ausgewählt "Mootools Navigation" (wer hätte das gedacht ). In der 4.9 ist die Option "mootoolsnav" nicht vorhanden, dort steht "Unbekannte Option: mootoolsnav". Im Seitenlayout sind die Haken bei "MooTools laden" und den Mootools Templates gesetzt. Unter "Templates" gibt es aber mod_mootoolsnav nicht mehr!
Als Behelfslösung habe ich nun erstmal eine Navigation ohne Accordion, aber das dürfte die meisten meiner Besucher*innen verwirren...
Hier fehlt mir leider zur Zeit jegliche Idee.


Falls eine/r der Admins die letzten Postings in einem separaten Thread besser aufgehoben sieht: bitte verschieben.

[purzel]

Allerdings fehlt noch das Hauptmenü, das war als Mootools-Accordion ... gibt es aber mod_mootoolsnav nicht mehr!

Erfolgsmeldung:
Ich habe das Modul "mootoolsnav" aus der 4.4 in die neue 4.9 nach system/modules kopiert und noch einen Symlink in web/system/modules/mootoolsnav/ angelegt (und natürlich den Prod.-Cache erneuert wie immer) - und die Accordion-Navigation funktioniert wieder. Mein "Versuchskaninchen" hat (wie ich auch) keine Macken in der Instanz mehr gefunden.

Für mich scheint das Problem nun also durch den Einsatz von PHP 8 behoben - 7.3 zu benutzen war ja nur ein Notbehelf.

@mlweb: Sollte man das mit PHP 7.4 aus den Postings #20 und erster Hälfte #21 (execution time) noch mal testen/weiterverfolgen?

Unabhängig davon: auf jeden Fall herzlichen Dank allen Beteiligten für die Versuche zu helfen!

[mlweb]

Wenn alles wie gewünscht mit PHP 8 läuft, würde ich da keine weitere Energie reinstecken. Nur im Hinterkopf behalten, wenn Du bei dem Provider mit PHP 7.4 noch einmal Probleme haben solltest.