Goneo: Contao-Manager kaputt?

Äh... natürlich hast Du Recht... Ich habe mich unglücklich bzw. unvollständig ausgedrückt.

Mit Weglassen meinte ich schon 5.3.* und eben nicht ^5.3 oder gar ^5.3.* ;)

Da die Sternchen schon in meiner 4.13.* stehen würde ich einfach 5.3.* aus den 4.13.* machen. Geht auch prima mit sed.

... und da die Hoffnung bekanntlich zuletzt stirbt habe ich dem grafischen CM noch eine Chance gegeben das Upgrade zu machen. Leider (wie gewohnt) erfolglos: dry run noch OK, "echtes" Upgrade geht schief. Morgen dann via CLI.

Guten Morgen zusammen!

"Frisch ans Werk" dachte ich mir und habe die composer.json zuerst geändert in:

Code:

---

{
    "type": "project",
    "require": {
        "contao/calendar-bundle": "5.3.*",
        "contao/comments-bundle": "5.3.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "5.3.*",
        "contao/listing-bundle": "5.3.*",
        "contao/manager-bundle": "5.3.*",
        "contao/news-bundle": "5.3.*",
        "contao/newsletter-bundle": "5.3.*"
    },
  ...

---

und versucht, das Upgrade via CLI anzuschubbsen (Wie gesagt: ich will nur die LTS 5.3, keine 5.4 usw.) :

$ 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 --no-install

Das lief relativ schnell auf einen Fehler:

Code:

---

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - contao/calendar-bundle[5.3.0, ..., 5.3.28] require symfony/config ^6.4 -> found symfony/config[v6.4.0, ..., v6.4.14] but the package is fixed to v5.4.46 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires contao/calendar-bundle 5.3.* -> satisfiable by contao/calendar-bundle[5.3.0, ..., 5.3.28].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

---

Also wohl doch was falsch (verstanden) mit dem Caret?

Nochmal alte Beiträge in diesem Thread gelesen und die composer.json erneut geändert, damit es im gelben Bereich https://github.com/contao/managed-ed...er.json#L6-L15 entspricht. Das geht aber genauso schief:

Code:

---

Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - contao/calendar-bundle[5.3.0, ..., 5.3.28] require symfony/config ^6.4 -> found symfony/config[v6.4.0, ..., v6.4.14] but the package is fixed to v5.4.46 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - contao/calendar-bundle[5.4.0, ..., 5.5.3] require friendsofsymfony/http-cache ^3.0 -> found friendsofsymfony/http-cache[3.0.0, 3.1.0] but the package is fixed to 2.16.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires contao/calendar-bundle ^5.3 -> satisfiable by contao/calendar-bundle[5.3.0, ..., 5.5.3].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

---

Nun traue ich mich nicht, dem "Vorschlag" aus der letzten Zeile Folge leisten, weil da was von downgrades und removals steht...

Ich bin der Meinung, auf Basis von https://docs.contao.org/manual/de/migration/ die Zeilen mit ^ oder * richtig gemacht zu haben:

Code:

---

{
    "type": "project",
    "require": {
        "contao/calendar-bundle": "^5.3",
        "contao/comments-bundle": "^5.3",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "^5.3",
        "contao/listing-bundle": "^5.3",
        "contao/manager-bundle": "5.3.*",
        "contao/news-bundle": "^5.3",
        "contao/newsletter-bundle": "^5.3"
    },
  ...

---

Darf ich "gefahrlos" --with-all-dependencies mit an meine $ composer update ... Zeile anhängen?

Zitat:

---

Zitat von purzel

Darf ich "gefahrlos" --with-all-dependencies mit an meine $ composer update ... Zeile anhängen?

---

Ja, musst du auch.

Führe einfach nur composer update -o aus.

DAS hat schonmal geklappt:
$ vendor/bin/contao-console contao:maintenance-mode enable
$ 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-all-dependencies --no-install

(fast alles grün, zwei orange Meldungen, siehe unten)

Er schlägt nun vor "[INFO] Done! Please open the Contao install tool or run the contao:migrate command to make sure the database is up-to-date. " zu machen.
Welche Reihenfolge sollte ich jetzt bei
$ composer install und
$ vendor/bin/contao-console contao:migrate
wählen? Wie geschrieben oder die beiden Befehle tauschen?

Im Anschluss dann wohl
$ rm -rf var/cache/prod
$ vendor/bin/contao-console cache:clear --no-warmup
$ vendor/bin/contao-console cache:warmup
$ vendor/bin/contao-console contao:maintenance-mode disable

Entschuldigt bitte die dummen Fragen... Ich habe bisher immer den GUI-CM benutzt...

Hier noch die oben erwähnten Meldungen, die Erste habe ich schon immer ignoriert:
Cannot create cache directory /.../.cache/composer/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache. See also cache-read-only config if your filesystem is read-only.
Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.

[EDIT]
Sorry Spooky, mal wieder Überschneidung

composer install musst du gar nicht ausführen. Auch nichts von all den anderen Commands. Nach einem (fehlerlosen) composer update ist alles erledigt. Danach kannst du direkt contao:migrate --no-interaction ausführen.

Hm. Ich habe nun
$ composer update -o
gemacht, das hat ganz viel heruntergeladen, aktualisiert und installiert - aber auch Einiges gelöscht. Im Anschluss gab ich Dein
$ vendor/bin/contao-console contao:migrate --no-interaction
hat zuerst ein SQL Backup erstellt:
[INFO] Creating a database dump to "backup__20250311091214.sql.gz" with the default options. Use --no-backup to disable this feature.

ABER: unmittelbar danach
Pending migrations
------------------

* Contao\CoreBundle\Migration\Version500\BasicEntiti esMigration
You cannot access this file directly

"Todesmutig" habe ich trotzdem noch den maintenance mode deaktiviert:
$ vendor/bin/contao-console contao:maintenance-mode disable

und versucht ins Backend zu kommen.
You cannot access this file directly
Das bleibt auch so, wenn ich die vier modifizierten be_* Templates via Umbenennen außer Betrieb setze.
Und nun?

Da ist wahrscheinlich noch eine alte Erweiterung oder eine alte Anpassung mit einem

HTML-Code:

---

if (!defined('TL_ROOT')) die('You cannot access this file directly');

---

Die musst du entfernen bzw. anpassen. Einfach mal die Installation danach durchsuchen.

$ fgrep -r 'You cannot access this file directly' */*
system/modules/mootoolsnav/ModuleMootoolsnav.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/en/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/en/modules.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/de/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/de/modules.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/config/config.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/dca/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
vendor/contao/core-bundle/src/Config/Loader/PhpFileLoader.php: && \in_array($text->value, ['You cannot access this file directly!', 'You can not access this file directly!'], true);

Wo muss das jetzt raus? Überall oder reicht es, die Zeile aus den kursiv markierten Files zu löschen?

Allerdings... ICH VERWENDE MOOTOOLSNAV - da muss also, wenn das nicht mehr geht, ein Ersatz her!

Übrigens @Spooky: was macht der Schalter -o bei "composer update -o"? Weder composer --help noch man composer gibt mir Aufschluss darüber.

Zitat:

---

Zitat von Spooky

Nach einem (fehlerlosen) composer update ist alles erledigt. Danach kannst du direkt contao:migrate --no-interaction ausführen.

---

Ganz fehlerlos ist es (neuer Versuch mit frischer Kopie) nicht, schon das composer update -o endet nach ganz viel grün mit
You cannot access this file directly!
[INFO] Done! Please run the contao:migrate command to make sure the database is up-to-date.

{EDIT} rote Textfarbe

Zitat:

---

Zitat von purzel

$ fgrep -r 'You cannot access this file directly' */*
system/modules/mootoolsnav/ModuleMootoolsnav.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/en/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/en/modules.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/de/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/languages/de/modules.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/config/config.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
system/modules/mootoolsnav/dca/tl_module.php:<?php if (!defined('TL_ROOT')) die('You cannot access this file directly!');
vendor/contao/core-bundle/src/Config/Loader/PhpFileLoader.php: && \in_array($text->value, ['You cannot access this file directly!', 'You can not access this file directly!'], true);

Wo muss das jetzt raus? Überall oder reicht es, die Zeile aus den kursiv markierten Files zu löschen?

---

system/modules/mootoolsnav musst du löschen. Danach musst du manuell var/cache/ löschen (rm -r var/cache/). Danach wieder composer update -o ausführen. Wenn das erfolgreich durchgelaufen ist danach wieder contao:migrate --no-interaction ausführen.

$ rm -r system/modules/mootoolsnav
$ rm -r var/cache
$ composer update -o
-> alles gut (das Meiste grün, einige orange Meldungen wie bereits oben beschrieben)

(magst Du bitte noch kurz was zu dem -o (siehe #169) sagen?)

$ vendor/bin/contao-console contao:migrate --no-interaction
-> ganz viele Migrationen und SQL-Befehle, danach offenbar alles gut

Allerdings meldet der Web-CM kurioserweise immer noch 16 ausstehende Schema-Änderungen bei der DB - was sich als ausschließlich Löschungen entpuppte... die habe ich mal gemacht. (Warum wurden die nicht gleich bei contao:migrate --no-interaction mit erledigt?)

Im Anschluss habe ich den Wartungsmodus ausgeschaltet und ihm wieder die be_* Templates weggenommen; als Folge komme ich immerhin ins Backend. Das FE geht aber nicht; ich fürchte "tonnenweise" Template-Fehler; außerdem fehlt ja jetzt mootoolsnav - was kann ich als Ersatz nehmen?

Nun brauche ich aber erstmal 'ne Pause :D

[EDIT: Satzteil mit mootoolsnav ergänzt]

Zitat:

---

Zitat von purzel

Warum wurden die nicht gleich bei contao:migrate --no-interaction mit erledigt?

---

contao:migrate --no-interaction löscht nichts by default - das wäre ja fatal.

Zitat:

---

Zitat von Spooky

contao:migrate --no-interaction löscht nichts by default - das wäre ja fatal.

---

Stimmt auch wieder - wo er Recht hat er Recht ;)

Zitat:

---

Zitat von purzel

...
(magst Du bitte noch kurz was zu dem -o (siehe #169) sagen?)
...
außerdem fehlt ja jetzt mootoolsnav - was kann ich als Ersatz nehmen?

---

Lass' mich bitte nicht dumm sterben :cool:

Sooo...

Grundsätzlich habe ich mir die Fragen inzwischen selbst beantworten können:

• -o steht für --optimize-autoloader | Optimize autoloader during autoloader dump. - was auch immer das genau bedeutet. Egal jetzt.
• contao:migrate kann man auch mit --with-deletes laufen lassen, dann sind auch die Löschungen via CLI möglich
• mootools-Ersatz habe ich bisher nicht gefunden - aber "irgendwie" muss das auch noch gehen: auch in der 5.3 habe ich, wenn ich ein Seitenlayout bearbeite, den Punkt "MooTools laden" und auf https://packagist.org/packages/conta...nents/mootools stehen keine Versions-Beschränkungen. Also wie (wieder) einbinden???

Vielleicht ist es mit einem Satz gesagt, sonst mache ich einen neuen Thread dafür auf: in der 4.13 habe ich alle CSSs exportiert weil es den internen CSS Editor ja nicht mehr gibt und das auch hier schon mehrfach diskutiert wurde. Wo binde ich die exportierten CSSs jetzt "global" ein? Oder etwa bei JEDEM Seitenlayout einzeln??? (Immerhin funktioniert mein FE "so halbwegs" wieder - sieht aber ohne CSS schrecklich aus :D

Zitat:

---

Zitat von purzel

-o steht für --optimize-autoloader | Optimize autoloader during autoloader dump. - was auch immer das genau bedeutet.

---

Das ist eine Performance Optimierung. In einer Live-Umgebung muss das immer so ausgeführt werden - andernfalls bekommst du nicht die beste Performance.

In einer lokalen Entwicklungsumgebung hingegen führst du die Composer Operationen aber immer ohne --optimize-autoloader (-o) aus, damit der Autoloader neue Klassen automatisch findet.

the neverending story :(

Ich musste ja nun während der Upgrade-Orgie meine beiden Extensions srhinow/tinymce-plugins und craffft/contao-calendar-ical-bundle sowie das Modul mootoolsnav entfernen damit das Upgrade auf 5.3 überhaupt erst möglich wurde.

Nun möchte ich deren Funktionalität natürlich wieder haben und habe im CM über ENTDECKEN gesucht...

Die Suche nach "tinymce" lieferte u.a. srhinow/tinymce-plugins und es wird wird wieder aufgelistet, "Paket hinzufügen" wird angeboten, wohl weil "Unterstützte Contao-Version(en) mit 4.8+, 5.0+ angegeben ist => also klickte ich auf "Paket hinzufügen". Unter "PAKETE" habe ich erstmal wieder auf "Testlauf" geklickt - alle Schritte wurden mit grünem Haken angezeigt. Auf Basis der Erfahrungen der letzten Tage wollte ich die eigentliche Installation dann aber in der Shell machen - aber bereits das composer require srhinow/tinymce-plugins lief auf einen Fehler:

Code:

---

Fatal error: Declaration of Srhinow\TinymcePlugins\SrhinowTinymcePlugins::getContainerExtension() must be compatible with Symfony\Component\HttpKernel\Bundle\Bundle::getContainerExtension(): ?Symfony\Component\DependencyInjection\Extension\ExtensionInterface in /..../htdocs/TEST53/vendor/srhinow/tinymce-plugins/src/SrhinowTinymcePlugins.php on line 42
Script @php -c contao-manager/php.ini vendor/bin/contao-setup handling the post-update-cmd event returned with error code 255

---

Demnach ist die Erweiterung wohl doch nicht für 5.3 geeignet. Immerhin bin ich den Fehlversuch durch Eingabe von composer remove srhinow/tinymce-plugins wieder los geworden. Und nun?
Ich möchte erreichen, dass der MCE wieder Buttons hat für Textmarke, unterstrichener Text, durchgestrichener Text und Emoticons.

Die andere Extension war craffft/contao-calendar-ical-bundle - die wird schon als nicht für 5.3 geeignet aufgelistet. Zwar bekam ich weiter oben (#89) den Vorschlag zu https://github.com/cgoIT/contao-calendar-ical-bundle (was ich auch über die ENTDECKEN-Suche fand), aber erstens finde ich die Masse der Abhängigkeiten erschreckend und zweitens fürchte ich, dass das Ding viel zu "aufgebläht" ist. Ich muss lediglich EINMAL IM JAHR um die 100 detaillose Events importieren. Export brauche ich nicht (!) und ob die Events aus CSV- oder ICS-Dateien kommen ist fast egal. CSV ist natürlich bequemerer.

Und was kann ich als "Ersatz" für das Modul "Navigation (mootools) [Mootools Navigation]" nehmen?

Falls dieses Posting nun zu sehr vom übergeordneten Bereich "Erfahrungen mit Webhostern" abweicht bitte in ein neues Thema in passenderem Bereich schieben. TIA

Zitat:

---

Zitat von purzel

mootools-Ersatz habe ich bisher nicht gefunden - aber "irgendwie" muss das auch noch gehen: auch in der 5.3 habe ich, wenn ich ein Seitenlayout bearbeite, den Punkt "MooTools laden" und auf https://packagist.org/packages/conta...nents/mootools stehen keine Versions-Beschränkungen. Also wie (wieder) einbinden???[/LIST]

---

Ich denke du missverstehst hier etwas. Deine Contao 4.13 Installation nutzt eine alte Extension namens "mootoolsnav". Diese Extension stellt, vermutlich (dem Namen nach), eine JavaScript Navigation zur Verfügung - basierend auf MooTools.

MooTools an sich gibt es auch in Contao 5 noch. Nur diese Extension funktioniert in Contao 5 nicht einfach so.

Zitat:

---

Zitat von purzel

Demnach ist die Erweiterung wohl doch nicht für 5.3 geeignet

---

https://gitlab.com/srhinow/tinymce-plugins/-/issues <-- Machst du Issue auf (GitLab Account notwendig)

Zitat:

---

Zitat von purzel

den Vorschlag zu https://github.com/cgoIT/contao-calendar-ical-bundle (was ich auch über die ENTDECKEN-Suche fand), aber erstens finde ich die Masse der Abhängigkeiten erschreckend und zweitens fürchte ich, dass das Ding viel zu "aufgebläht" ist. Ich muss lediglich EINMAL IM JAHR um die 100 detaillose Events importieren. Export brauche ich nicht (!) und ob die Events aus CSV- oder ICS-Dateien kommen ist fast egal. CSV ist natürlich bequemerer.

---

Dann installiere dir die Erweiterung, importiere die Sachen, deinstalliere sie wieder.
Wenn die alte Erweiterung nicht für Contao 5 funktioniert, kannst du hier sicherlich einen Fork machen oder jemanden finanziell beauftragen, dass dieser dir über einen Fork eine Contao 5 - Kompatibilität herstellt.

Zitat:

---

Zitat von purzel

Und was kann ich als "Ersatz" für das Modul "Navigation (mootools) [Mootools Navigation]" nehmen?

---

Das kann ich dir nicht sagen. Was hat diese Mootools Navigation denn gemacht? Kannst du nicht auf mmenu gehen oder es via JavaScript lösen?
Es ist wohl ein Contao 3 Modul - Hier hast du also mindestens 8 Jahre Zeit gehabt eine Alternative zu suchen.

Zitat:

---

Zitat von purzel

Falls dieses Posting nun zu sehr vom übergeordneten Bereich "Erfahrungen mit Webhostern" abweicht bitte in ein neues Thema in passenderem Bereich schieben. TIA

---

[/QUOTE]
@Moderation <3

Zitat:

---

Zitat von Spooky

Ich denke du missverstehst hier etwas. Deine Contao 4.13 Installation nutzt eine alte Extension namens "mootoolsnav". Diese Extension stellt, vermutlich (dem Namen nach), eine JavaScript Navigation zur Verfügung - basierend auf MooTools.

---

Ob es eine Extension in dem Stil ist oder war wie ich sie bisher kennengelernt habe (nämlich bewusst als Erweiterung installierbar, hauptsächlich über "ENTDECKEN" im CM, früher (vor CM) über ... äh ... vielleicht entpacken eines *.tgz (?)) weiß ich nicht (mehr). Ich habe das AFAIR "schon immer", ich meine sogar seit TYPOLIGHT mit dem damals mitinstallierten standard music academy Design (welches ich natürlich nicht mehr nutze - diente nur seinerzeit als eine Art Grundlage).

Zitat:

---

Zitat von zoglo

https://gitlab.com/srhinow/tinymce-plugins/-/issues <-- Machst du Issue auf (GitLab Account notwendig)

---

Ich habe einen Account - und bin sogar rein gekommen (dank "forgot password" Funktion). Aber ich finde das Ding nicht. Außerdem: wie macht man so ein Issue?
EDIT: sorry, ich war zu "betriebsblind" einfach auf Deinen Link zu klicken - aber anscheinend ist GitLab != GitHub - den GitHub Account habe ich nur, weil vor Jahren jemand von mir wollte dass ich ein "PR" mache - was man mir auch erst erklären musste. Extra einen Account auf GitLab für einmaligen Gebrauch? Ich weiß nicht...

Zitat:

---

Zitat von zoglo

Dann installiere dir die Erweiterung, importiere die Sachen, deinstalliere sie wieder.

---

Ich bin mir nicht sicher, ob ich diesen Weg praktikabel genug finde um es JEDES Jahr zu machen ...

Zitat:

---

Zitat von zoglo

Wenn die alte Erweiterung nicht für Contao 5 funktioniert, kannst du hier sicherlich einen Fork machen oder jemanden finanziell beauftragen, dass dieser dir über einen Fork eine Contao 5 - Kompatibilität herstellt.

---

So wie ich das verstehe, IST doch cgoit/contao-calendar-ical-bundle ein entsprechender Fork - bei dem ich... siehe oben ;)
Sorry, finanzielle Aufträge widersprechen dem bereits anfangs diskutierten "ehrenamtlich für den Verein".

Zitat:

---

Zitat von zoglo

Das kann ich dir nicht sagen. Was hat diese Mootools Navigation denn gemacht? Kannst du nicht auf mmenu gehen oder es via JavaScript lösen?

---

Wie soll ich das beschreiben... es hat dafür gesorgt, dass beim Mouseover die jeweiligen (Haupt-)Menüpunkte automatisch auseinander geklappt sind und beim Mouseout wieder zusammenfuhren; das Ganze "schön weich". Sehr ähnliches machen heute viele Webseiten vermutlich mit CSS - da fehlen mir aber die Kenntnisse (und die Zeit!), so etwas umzusetzen.
Wenn ich die ganzen anderen Probleme die sich bei dem Upgrade ergeben haben gelöst habe kann ich mich vielleicht dazu entschließen, diese "softe" Navigation ersatzlos zu streichen, schaumermal.

Zitat:

---

Zitat von purzel

Ich habe das AFAIR "schon immer"

---

Wird so sein, ja - weil halt extrem veraltet.

Zitat:

---

Zitat von purzel

... aber anscheinend ist GitLab != GitHub - den GitHub Account habe ich nur, weil vor Jahren jemand von mir wollte dass ich ein "PR" mache - was man mir auch erst erklären musste. Extra einen Account auf GitLab für einmaligen Gebrauch?

---

Ich konnte GitLab und GitHub sozusagen verknüpfen und habe ein Issue erstellt. Ob's was bringt werden wir sehen...

Zitat:

---

Zitat von purzel

... Vorschlag zu https://github.com/cgoIT/contao-calendar-ical-bundle (was ich auch über die ENTDECKEN-Suche fand), aber erstens finde ich die Masse der Abhängigkeiten erschreckend und zweitens fürchte ich, dass das Ding viel zu "aufgebläht" ist. Ich muss lediglich EINMAL IM JAHR um die 100 detaillose Events importieren. Export brauche ich nicht (!) und ob die Events aus CSV- oder ICS-Dateien kommen ist fast egal. CSV ist natürlich bequemerer. ...

---

Anscheinend waren meine Sorgen (Abhängigkeiten und aufgebläht) übertrieben. Die Installation via CLI lief erstaunlich schnell ab, hat nur 2 Sachen (nämlich das cgoit/contao-calendar-ical-bundle sowieso und kigkonsult/icalcreator zusätzlich) geladen. Aufgebläht scheint es auch nicht zu sein; es sieht genau so aus wie vorher das craffft/contao-calendar-ical-bundle. Test steht aber noch aus, der erfolgt dann morgen.

Zitat:

---

Zitat von purzel

So wie ich das verstehe, IST doch cgoit/contao-calendar-ical-bundle ein entsprechender Fork - bei dem ich... siehe oben ;)
Sorry, finanzielle Aufträge widersprechen dem bereits anfangs diskutierten "ehrenamtlich für den Verein".

---

Für verwaiste und veraltete Plugins könntest du ehrenamtlich deine eigene Zeit opfern und hierbei Programmierkenntnisse erlangen. Ein PR von dir hilft doch sicherlich auch, wenn er einen Fehler behebt.
Man muss auch mal zurückgeben. Die Plugin-Hersteller sind niemandem geschuldet, dass ihre frei verfügbare Software fehlerfrei funktionieren muss und auch nicht über einen Zeitraum von "lebenslänglich" ;)

Wenn es an den zwei Plugins (Contao 5 Kompatibilität und Navigation) scheitert, dann einfach PHP, JavaScript und CSS lernen und es selber machen. Dann bist du auch nicht auf Plugins oder kostenlose Lösungen angewiesen.

Hallo zusammen,

heute kam wieder ein Update des CM mit (vermutlich) der gleichen Fehlermeldung wie https://community.contao.org/de/show...l=1#post593212 (ich hab's jetzt nicht exakt vergleichen) und im Lag des CM steht dies:

Code:

---

[17-Mar-2025 12:48:09 UTC] PHP Parse error:  syntax error, unexpected identifier "version" in phar:///...../htdocs/TEST53/public/contao-manager.phar.php/api/HttpKernel/ApiProblemResponse.php on line 30
[17-Mar-2025 12:48:09 UTC] PHP Fatal error:  Uncaught Error: Class "_ContaoManager\Symfony\Component\ErrorHandler\ThrowableUtils" not found in phar:///...../htdocs/TEST53/public/contao-manager.phar.php/vendor/symfony/error-handler/ErrorHandler.php:420
Stack trace:
#0 [internal function]: _ContaoManager\Symfony\Component\ErrorHandler\ErrorHandler->handleException()
#1 {main}
  thrown in phar:///...../htdocs/TEST53/public/contao-manager.phar.php/vendor/symfony/error-handler/ErrorHandler.php on line 420

---

Anhang 27767