Contao 4.4.24 ist verfügbar. Das Update ist über den Contao Manager oder via Composer möglich.
Siehe auch: Tickets | Versionsvergleich | Changelog
Druckbare Version
Contao 4.4.24 ist verfügbar. Das Update ist über den Contao Manager oder via Composer möglich.
Siehe auch: Tickets | Versionsvergleich | Changelog
Nach einem Manager 'update' ist das Frontend und das Backend nicht mehr erreichbar. Beim Aufruf folgende Fehlermeldung:
Der Terminal im Manager spuckt folgendes aus:Zitat:
Oops! An Error Occurred
The server returned a "500 Internal Server Error".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.
Anhang 21297
Wie weiter? :mad:
Gruss Rolf
Die Fehlermeldung weißt auf einen Fehler von BackupDB hin. Dies würde ich mal deinstallieren und schauen ob es dann funktioniert.Zitat:
Zitat von rwaelty1944
Kannst Du bitte mal versuchen, den Symfony Cache über den Contao Manager neu aufbauen zu lassen.
Falls anschließend der Fehler weiterhin bestehen bleibt, muss vermutlich an der Erweiterung do-while/contao-backupdb-bundle etwas angepasst werden.
Der Fehler bleibt der gleiche und der Terminal zeigt folgendes Problem:
Anhang 21298
Gruss Rolf
Okay, Du könntest die Erweiterung vorerst mal deinstallieren, so wie @webstar das oben bereits vorgeschlagen hatte:
Darüber hinaus sollte der Fehler natürlich auch gemeldet werden: https://github.com/do-while/contao-BackupDB/issuesZitat:
Zitat von webstar
Webstar und vielen Dank. Nach dem Entfernen von BackupDB ist das Front- und Backend wieder erreichbar.
Viele Grüsse :)
Rolf
XCHS ich werde den Fehler melden. Dir auch vielen Dank.
Liebe Grüsse Rolf
Den Fehler habe ich im Repository bereits gemeldet: https://github.com/do-while/contao-BackupDB/issues/13
XCHS vielen Dank.
Gruss Rolf
Ach Menno, wieder so ein Contao Bugfix Update und schon laufen einige Erweiterungen (auch mindestens einer meiner) nicht mehr. :mad:
Und wieder wird es heißen, ist ja keine API Änderung...., stimmt ja auch, trotzdem ärgerlich.
Nein, das ist kein Problem von Contao, sondern von den Erweiterungen, die auf Features von Paketen zurückgreifen ohne diese als Requirement in der composer.json zu definieren. Dies ist fahrlässig.Zitat:
Zitat von BugBuster
Übrigens gibt es mit composer-require-checker ein Tool um solche Fehler zu vermeiden:
https://packagist.org/packages/magln...equire-checker
Stimmt :), beim Update musste ich contao-dlstats-bundle deinstallieren.Zitat:
Zitat von BugBuster
Bisher fand ich es nicht notwendig Dinge zu Requiren, die Contao schon mitbringt. Auch bin ich schon mal reingefallen, weil ich da schomal Contao ausgebremst hatte.Zitat:
Zitat von webstar
Im Endeffekt war es in meinem Fall ein Versäumnis von mir zu schwenken als ich von der Annotation-Variante zur yml Variante gewechselt bin. Das Sensio Framework kann/(konnte?) mehr als das direkte von Symfony.
Habe jetzt das "sensio/framework-extra-bundle" als Abhängigkeit eingetragen.
Die Version 1.3.0 sollte jetzt auch mit Contao ab 4.4.24 laufen.
So, bugbuster/contao-banner-bundle 1.0.4 und bugbuster/contao-dlstats-bundle 1.0.3 sind nun lauffähig in Contao 4.4.24.
Es folgt dann noch bugbuster/contao-visitors-bundlein Kürze(dann die 1.3.3)
Wenn man ein stabiles Paket zur Verfügung stellen möchte, dann geht es halt nur, indem man selbst dafür sorgt, dass alle Abhängigkeiten definiert sind. Man kann sich nicht darauf verlassen, dass ein anderes Projekt nicht seine Abhängigkeiten ändert. Daher ist mein Plädoyer selbst dafür zu sorgen alle verwendeten Komponenten auch als Requirement zu definieren.Zitat:
Zitat von BugBuster
Die jüngste Vergangenheit hat gerade gezeigt, dass es essentiell ist.
Beim Update auf Contao 4.6 versagten viele Erweiterungen, da Contao nicht mehr auf Symfony 3.4 sondern 4 aufsetzte (inzwischen wieder 3.4 kompatibel). Hätte man selbst dafür gesorgt, dass man die entsprechenden Symfony-Komponenten in den unterstützten Versionen required, hätte sich das ganze nicht installieren lassen und ein paar Überraschungen nach dem Update erspart.
Durch das Update wurde das "sensio/framework-extra-bundle" entfernt. Danach gab es nur noch HTTP-Error 500.
Ich habe "sensio/framework-extra-bundle": "^3.0.29" in die package.json eingetragen und nochmal aktualisieren lassen - nun läuft es wieder.
@BugBuster wenn contao das Paket aber nicht mehr benötigt und entfernt, laufen die Erweiterungen (oder die komplette Seite) Zwangsläufig gegen die Wand. Wenn eine Erweiterung ein Paket benötigt, dann sollte es auch durch das Paket selbst required werden. Um das richtige aufdröseln der requirements hat sich der Paketmanager am Ende zu kümmern.
Auch wenn ich diesem System nicht viel abgewinnen kann, alles in kleine Pakete zu packen...
Ich kann ja nicht ahnen, das in einem BugFix Release von Contao solche Änderungen reinkommen.
Und ich verwende auch Dinge wo ich gar nicht weiß wie das Contao intern tut, das will ich ja auch nicht.
Ich ging davon aus, wenn Contao selbst etwas verwendet, dann kann ich das nutzen ohne das ich das selber auch nochmal anfordern muss.
Das Routing Paket ist nun ein Spezialfall, denn es gab bisher zwei von denen, das von Sensio Labs und das von Symfony direkt.
Wer Annotation nicht nutzt und die Routing Informationen komplett in die routing.yml schreibt, der war davon eh nicht betroffen. (habe noch nicht alle Erweiterungen darauf umgestellt)
Auch habe ich echt keine Lust für jede Klasse die mir die Magie von Symfony bereithält rauszufinden, aus welchen Package die stammt um das in den require mit aufzunehmen.
Und in der Changelog ist auch kein Wort darüber zu finden, kein Ticket nichts (nur ne commit Meldung). Auch schwer dann sowas nachzuvollziehen.
Naja, läuft ja wieder alles.
Auch wenn du keine Lust hast, musst du das machen. Du kannst, wie gesagt, bei keinem Paket (egal ob von Contao oder sonstigen Erweiterungen) davon ausgehen, dass sich deren Abhängigkeiten niemals ändern. Wenn du eine Komponente aus einem bestimmten Paket benutzt, egal ob von Symfony, Contao oder sonst wo, musst du diese auch in deinen Abhängigkeiten festhalten.
In der Regel kann man bei Symfony die Packages anhand des Namespaces gut schlussfolgern: 'Symfony\Component\Translation' -> symfony/translation usw. Ist zwar mühsam, aber notwendig, wenn du eine zuverlässig funktionierende Erweiterung zur Verfügung stellen willst und nicht mit solchen Überraschungen leben möchtest.Zitat:
Zitat von BugBuster