Jetzt dann doch: Problem mit Update 4.9 -> 4.13

[purzel]

Hallo und noch alles Gute zum noch einigermaßen neuen Jahr!

Ich habe zwei Instanzen Conato, beide bei Goneo in verschiedenen Accounts. Die Eine habe ich vor ein paar Tagen nahezu problemfrei auf 4.13 aktualisieren können; mein vermeintliches Problem an der Stelle war "hausgemacht" und ich konnte es selbst lösen. Wie es aussieht ist wunschgemäß DER Thread auch gelöscht worden - vielen Dank dafür.

Die zweite Instanz mag sich nicht aktualisieren lassen, auch hier habe ich der Anleitung folgend Datenbank und composer.json/composer.lock gesichert; den ganzen Dateien-Kram vorsichtshalber auch.
Der UNTERSCHIED zu der anderen Instanz ist: bei dieser Zweiten sind zwei zusätzliche Pakete installiert, von denen eines als "verwaist" gekennzeichnet ist ("TinyMCE Bundle classic"), ich weiß im Moment gerade nicht, warum ich das brauch(t)e... Das zweite Zusatzpaket ist "iCal Kalender", damit hatte ich schon vor zwei Jahren Probleme, aber es gibt wohl einen Fork. Da muss ich nochmal https://community.contao.org/de/show...rung-und-PHP-8 ausgraben und verfolgen...

Doch nun endlich zum neuen PROBLEM: Auch der Anleitung folgend habe ich im Manager aus der 4.9.* ein 4.13.* gemacht und "Testlauf mit allen Paketen" angeklickt. Bei dieser zweiten Instanz bricht der Prozess mit folgender Fehlermeldung ab:

composer install --dry-run
$ /usr/local/bin/php -q -dmax_execution_time=0 -dmemory_limit=-1 -ddisplay_errors=0 -ddisplay_startup_errors=0 -derror_reporting=0 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /data/web/1/000/038/826/133535/htdocs/LIVE/web/contao-manager.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader --dry-run
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
- Required package "contao/calendar-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/comments-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/faq-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/listing-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/manager-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/news-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
- Required package "contao/newsletter-bundle" is in the lock file as "4.9.42" but that does not satisfy your constraint "4.13.*".
This usually happens when composer files are incorrectly merged or the composer.json file is manually edited.
Read more about correctly resolving merge conflicts https://getcomposer.org/doc/articles/resolving-merge-conflicts.md
and prefer using the "require" command over editing the composer.json file directly https://getcomposer.org/doc/03-cli.md#require-r
# Process terminated with exit code 4
# Result: Unknown error

Die beiden Schritte (composer require... und composer update...) davor laufen durch. Ich habe niemals (vorsätzlich/wissentlich) das composer.json file editiert. Mir ist jetzt nicht klar, was ich tun muss ohne die Installation zu "zerschießen"; die angegebene Seite ist für mich nicht so richtig hilfreich. Solange nicht sicher ist, dass es daran liegt würde ich ungern die beiden Extra-Pakete eliminieren ;-)

TIA
purzel

[Spooky]

Diese Meldung kannst du ignorieren, siehe https://github.com/contao/contao-manager/issues/788

[purzel]

hua... Fehlermeldungen ignorieren... sowas macht mir Angst...

Aber gut, ich habe eine jeweils "frische" Kopie der Datenbank, der composer.* Files und des ganzen Dateien-Gedöns gemacht und meinen ganzen Mut zusammen genommen: anstatt "Testlauf mit allen Paketen" habe ich "Änderungen anwenden" gemacht.
Das POSITIVE: Alle drei Schritte im CM bekamen ihren grünen Haken.

Dann wollte er ins Install-Tool, dazu musste ich das dazugehörige PW eingeben. (Ich MEINE mich zu erinnern, dass das in der anderen Instanz nicht war - ist aber evtl. unwichtig)
Im Installtool war eine kleine gelbe 4-zeilige Box, die ich als eine Art "das ist gut so" Meldung interpretiert habe (leider vergessen zu kopieren). Darunter ein großer Kasten mit notwendigen (?) Datenbank-Änderungen, die meisten (bis auf ein paar DROP ... Anweisungen) waren vorausgewählt. Mutig habe ich auf (sinngemäß) "mach mal" geklickt.

Sch***!
Das NEGATIVE: Fehlermeldung!
Der Browser zeigte
Es ist ein Fehler aufgetreten
...hinter dieser Meldung verborgen und findet sich in der aktuellen Log-Datei ...
Aha, also das Log:

prod-2024-01-06.log...skipping...
[2024-01-06T14:45:27.175106+01:00] php.WARNING: Warning: Undefined array key "urlKeywords" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"urlKeywords\" at SERVERPFAD/var/cache/prod/contao/config/config.php:446)"} []
[2024-01-06T14:45:27.175183+01:00] php.WARNING: Warning: Undefined array key "urlKeywords" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"urlKeywords\" at SERVERPFAD/var/cache/prod/contao/config/config.php:446)"} []
[2024-01-06T14:45:27.328042+01:00] php.WARNING: Warning: Undefined array key "groups" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"groups\" at SERVERPFAD/vendor/contao/core-bundle/src/Resources/contao/classes/BackendUser.php:167)"} []
[2024-01-06T14:45:27.328100+01:00] php.WARNING: Warning: Undefined array key "groups" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"groups\" at SERVERPFAD/vendor/contao/core-bundle/src/Resources/contao/classes/BackendUser.php:167)"} []
[2024-01-06T14:45:27.329178+01:00] php.WARNING: Warning: Undefined array key "groups" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"groups\" at SERVERPFAD/vendor/contao/core-bundle/src/Resources/contao/classes/BackendUser.php:167)"} []
[2024-01-06T14:45:27.329240+01:00] php.WARNING: Warning: Undefined array key "groups" {"exception":"[object] (ErrorException(code: 0): Warning: Undefined array key \"groups\" at SERVERPFAD/vendor/contao/core-bundle/src/Resources/contao/classes/BackendUser.php:167)"} []
[2024-01-06T14:45:27.567932+01:00] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occurred while executing 'ALTER TABLE tl_content CHANGE imageUrl imageUrl VARCHAR(255) DEFAULT '' NOT NULL':  SQLSTATE[01000]: Warning: 1265 Data truncated for column 'imageUrl' at row 144" at SERVERPFAD/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 128 {"exception":"[object] (Doctrine\\DBAL\\Exception\\DriverException(code: 0): An exception occurred while executing 'ALTER TABLE tl_content CHANGE imageUrl imageUrl VARCHAR(255) DEFAULT '' NOT NULL':\n\nSQLSTATE[01000]: Warning: 1265 Data truncated for column 'imageUrl' at row 144 at SERVERPFAD/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:128)\n[previous exception] [object] (Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 01000): SQLSTATE[01000]: Warning: 1265 Data truncated for column 'imageUrl' at row 144 at SERVERPFAD/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php:18)\n[previous exception] [object] (PDOException(code: 01000): SQLSTATE[01000]: Warning: 1265 Data truncated for column 'imageUrl' at row 144 at SERVERPFAD/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:55)"} []

(Anstatt SERVERPFAD steht da natürlich was Anderes und die ganzen php.INFO: User Deprecated: u.ä. hab' ich mal ausgefiltert - sollten die wichtig sein liefere ich sie nach)

Frontend und Backend funktionieren aber anscheinend, das BE meldet "Version 4.12.7".

Was sollte ich nun tun?

[mlweb]

Poste die composer.json.

[purzel]

So sieht die jetzt aus:

$ cat composer.json 
{
    "type": "project",
    "require": {
        "cliffparnitzky/tiny-mce-bundle-classic": "^1.2",
        "contao/calendar-bundle": "4.12.*",
        "contao/comments-bundle": "4.12.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "4.12.*",
        "contao/listing-bundle": "4.12.*",
        "contao/manager-bundle": "4.12.*",
        "contao/news-bundle": "4.12.*",
        "contao/newsletter-bundle": "4.12.*",
        "craffft/contao-calendar-ical-bundle": "^4.2"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

Nach dem vorhin genannten Fehler habe ich genau nichts mehr gemacht.

(Oder war die composer.json von VOR dem Update gemeint?)

[mlweb]

Du wolltest doch auf 4.13 updaten. Bei Dir steht in der composer.json aber 4.12.
Du musst auf Contao 4.13 updaten.

[purzel]

Oh... tatsächlich.
Echt nicht schlecht das gute alte 4-Augen-Prinzip :-)
Ich danke Dir!

Warum das passiert ist... ich weiß es nicht - vermutlich ein ganz banaler Tippfehler.

Das Update 4.12 -> 4.13 als solches via CM machte zwar wieder beim dry-run den bekannten Fehler, lief dann aber (ohne dry-run) bis zu den 4 grünen Haken (oder waren's 5?) durch.

Dann wollte er wieder die DB aktualisieren ... das Browserfenster blieb eine gefühlte Ewigkeit beim Überprüfen der DB um festzustellen dass eine "AlwasForwardMigration" und eine "RelLightboxMigration" gemacht werden müssen. Aha. "Ausführen" und wieder eine halbe Ewigkeit ( > Viertelstunde jetzt) warten... Was macht der da? Darf man einfach "Aktualisieren" klicken oder den CM neu aufrufen oder... Ich hab schon wieder ein bisschen Angst...

[purzel]

Nachdem ich mir vorhin dachte "ich lasse ihn einfach mal in Ruhe machen" - die Zeit habe ich dann zum Abendessen genutzt - ist er anscheinend "so halb" fertig geworden:
Ich musste mich erneut beim CM einloggen, am Menüpunkt "Systemwartung" ist dann eine 1. Darauf geklickt offenbart es eine ausstehende Datenbank-Migration. Na immerhin.
An der Stelle habe ich dann erstmal von dem "Angebot" (Button) Gebrauch gemacht, ein (DB-) Backup zu erstellen. Das hat offenbar geklappt - aber wo wird das hin geschrieben? Normal mache ich meine Datenbank-Sicherung immer "zu Fuß" mit mysqldump - da weiß ich wo das hin geschrieben wird.
Anschließend klickte ich auf "Datenbank überprüfen" , das bescherte ziemlich zügig wieder die Notwendigkeit von "AlwaysForwardMigration" und "RelLightboxMigration".
Dies' Mal folgten einigermaßen schnell erst eine Liste mit Details was gemacht werden soll, nach Bestätigung derselben auch relativ schnell die Erfolgsmeldungen (tütenweise grüne Häkchen). Warum war das vorhin so langwierig?
Dann aber, nach "Weiter" wieder Grauen in Form von "Bitte warten, die Datenbank wird überprüft …" aber es klappte dieses Mal offenbar schon nach ein paar Minuten. Nur ohne die vorgeschlagenen Löschungen darf es anscheinend nicht weiter gehen, Endlosschleife... Na gut, dann lösch' halt.
Was lange währt wird aber endlich gut: FE und BE funktioneren, ich bekomme nun Version 4.13.35 gemeldet. Und alles ohne - ich hab's total vergessen - ohne am Anfang den Wartungsmodus zu aktivieren. Endlich!

Wäre es an dieser Stelle nötig gewesen - ich hab's mal gemacht - den Anwendungs-Cache (Symfony) neu zu erstellen?

Liegt das eigentlich an der Komplexität von Contao, dem Contao-Manager oder am Hoster (Goneo in meinem Fall) dass das z.T. so arg lange dauert?

Sorry für so viel Blah, aber möglicherweise sind für die Entwickler/innen derartige Rückmeldungen von Nutzen.

Beste Grüße und nochmals vielen Dank @mlweb

Purzel

[SenaX]

Vielen Dank für dieses Update!

[Spooky]

Bei entsprechender Größe der Datenbank könnten Migrationen durchaus lange dauern. Schneller geht es vielleicht, wenn du das alles direkt über SSH machst, statt über den Contao Manager.

[mlweb]

aber wo wird das hin geschrieben?

Die automatischen Sicherungen der DB bei einer Migration (ab Contao 4.13) werden im Ordner /var/backups gespeichert.
Ich mache aber auch fast immer ein manuelles Backup. Habe ich mir einfach so angewöhnt. Aber wenn es mal sehr schnell gehen muss kann ich einfach drauf verzichten oder wenn ich aus welchem Grund auch immer keinen Zugang zur DB habe, dann kann ich mit diesen Sicherungen arbeiten.

Warum war das vorhin so langwierig?
Dann aber, nach "Weiter" wieder Grauen in Form von "Bitte warten, die Datenbank wird überprüft …" aber es klappte dieses Mal offenbar schon nach ein paar Minuten.

Ergänzend zu dem was @Spooky schon geschrieben hat: Manchmal sind auch mehrere Aktualisierungsläufe nacheinander notwendig. Es ist normal, dass die unterschiedlich lange dauern.

Nur ohne die vorgeschlagenen Löschungen darf es anscheinend nicht weiter gehen, Endlosschleife... Na gut, dann lösch' halt.

Es geht schon, dass man ohne Löschungen weiter machen kann. Das kann auch manchmal notwendig sein, z.B. wenn man mal testen möchte, ob eine bestimmte Erweiterung ein Problem verursacht und diese testweise deinstalliert. In dem Fall möchte man die Daten der Erweiterung in DB ja nicht löschen. Man kann in einem solchen Fall einfach abbrechen und bewusst auf diese Aktualisierungen verzichten.

Wäre es an dieser Stelle nötig gewesen - ich hab's mal gemacht - den Anwendungs-Cache (Symfony) neu zu erstellen?

Während der Aktualisierung wird der Symfony Cache automatisch mit gelöscht. War also nicht erforderlich, schadet aber auch nicht.

Liegt das eigentlich an der Komplexität von Contao, dem Contao-Manager oder am Hoster (Goneo in meinem Fall) dass das z.T. so arg lange dauert?

Liegt wahrscheinlich an der Größe der DB, aber auch der Hoster selbst spielt eine Rolle.

[purzel]

Moin.
Vielen Dank für die neuen Rückmeldungen!
Ich verzichte mal auf Zitate...

Meine DB ist selbst unkomprimiert (gz) noch unter 10 MB groß, daher vermute ich das "Trödel"-Problem inzwischen wohl eher beim Hoster.
Ich hatte die DB-Backups nicht gefunden weil ich find auf *.sql losgeschickt hatte, nicht auf *.sql.gz oder womöglich nur *.gz - manchmal sieht man den Wald vor lauter Bäumen nicht.

Spooky spricht mir im Grunde aus der Seele, lieber alles via SSH zu machen... Dazu müsste ich mich aber vielleicht mal einlesen wie man die Dinge die der CM macht per Kommandozeile erledigen kann (jaja, die liebe Faulheit *gg*). "Normale" Shell-Befehle kenne ich. Was mir im CM aber ziemlich gut gefällt ist die Suche nach "fremden" Paketen - ich brauche ja vermutlich mittelfristig einen Ersatz für das verwaiste Paket.

Löschungen bei Bedarf unterlassen - gut zu wissen.

Also nochmals dankeschön für die Unterstützung und die Erläuterungen - sowie einen schönen Sonntag!

Gruß
Purzel

[purzel]

So'n Schiet!

Gestern Abend schrieb ich ja, FE und BE würden funktionieren - das war leider nur die halbe Wahrheit. Im FE habe ich (noch) keine Fehler entdeckt, aber im BE hatte ich nur geschaut ob es sich aufrufen lässt, ob alles auf den ersten Blick da ist und in etwa gewohnt aussieht. Das war (und ist) anscheinend der Fall.

ABER... der Editor funktioniert nicht, die Stelle wo er erscheinen müsste bleibt frei. Ich vermute, das liegt an meiner verwaisten Erweiterung "TinyMCE Bundle classic".

Nun will ich erstmal nicht wie wild installieren und deinstallieren, jedenfalls nicht im "Produktiv-System" und habe mir gedacht ich lege eine Kopie an. Dazu habe ich den ganzen Dateibaum (nennen wir ihn mal htdocs/produktiv/ ) kopiert nach htdocs/test/ und wollte eben dieser Kopie natürlich auch eine Kopie der DB geben. Dazu ein SQL-Dump angefertigt und in eine freie wieder eingelesen. Alles kein Problem.

UND NUN? Es reicht offenbar nicht, in htdocs/test/config/parameters.yml die Zugangsdaten der neuen DB einzutragen, es wird trotzdem die originale DB benutzt.

Was muss ich tun, damit von der Kopie auch die frische Datenbank-Kopie benutzt wird?

TIA
Purzel

[fiedsch]

Was muss ich tun, damit von der Kopie auch die frische Datenbank-Kopie benutzt wird?

Die Einstellungen zur Datenbank und anderes werden gecacht. Bei Deinem „kompletten Seitenbaum kopieren“ hast Du wohl auch den Cache mit kopiert. Nach der Änderung der Einstellungen muss der Cache geleert werden. Das machst Du entweder im Contao-Manager oder auf der Konsole.

[purzel]

Ich habe nicht den Seitenbaum (im BE) kopiert sondern das komplette Server-Verzeichnis auf Dateiebene - das nimmt "natürlich" auch den Cache mit. Selbigen löschen hat geholfen. Vielen Dank!

Leider

...
ABER... der Editor funktioniert nicht, die Stelle wo er erscheinen müsste bleibt frei. Ich vermute, das liegt an meiner verwaisten Erweiterung "TinyMCE Bundle classic".
...

funktionierte dann trotz Entfernen des verwaisten Pakets "TinyMCE Bundle classic" und nochmaligem Cache löschen der Editor nicht wieder.

Erst das "Deaktivieren" meines eigenen Template be_tinyMCE.html5 brachte den Editor zurück. Ich schrieb ja weiter oben schon, dass ich mich gerade nicht erinnern kann warum ich die besagte Erweiterung brauchte... Auf jeden Fall sieht der Editor jetzt "irgendwie" anders aus als vor dem Update 4.9 -> 4.13
Da ich ja jetzt weiß wie das funktioniert mit dem Anlegen einer funktionierenden Kopie mache ich mir wohl noch eine Testumgebung mit der alten 4.9 ;-)

Beste Grüße und einen schönen Abend,
Purzel

[purzel]

Die Erinnerung ist ohne Reaktivierung der alten 4.9 zurück gekommen. Ich habe - zuerst in meiner Test-Instanz 4.13 und erst später in der "Richtigen" - die Erweiterung srhinow/tinymce-plugins installiert, weil die vorher benutzten MCE Plugins von cliffparnitzky wohl nicht mehr zur 4.13 kompatibel sind. Nun geht anscheinend wieder alles wie ich es gewohnt bin.
Herzlichen nochmals allen und ein schönes Wochenende
Purzel