Kann Speicher dafür verantwortlich sein?
phpinfo() im Browser liefert für memory_limit 128MB, im CLI immerhin 192MB.
Bei den Contao Systemvoraussetzungen sind ja höhere Werte angegeben:
memory_limit für Web Minimum 256M und für CLI -1 (unbegrenzt)
Druckbare Version
Kann Speicher dafür verantwortlich sein?
phpinfo() im Browser liefert für memory_limit 128MB, im CLI immerhin 192MB.
Bei den Contao Systemvoraussetzungen sind ja höhere Werte angegeben:
memory_limit für Web Minimum 256M und für CLI -1 (unbegrenzt)
Nein, das memory_limit hat mit dem in diesem Thread beschriebenem Problem bei Goneo nichts zu tun.
Ist bei mir genauso (bin auch Goneo Kunde, mit Altvertrag)Zitat:
Zitat von purzel
Aber bei einem Contao Update 4.13.52 auf .53 mit Contao Manager hatte ich keine Probleme.
Unser Vertrag ist auch relativ alt: Vertrag 2008, in dem Tarif seit 2016.Zitat:
Zitat von BugBuster
Zum Thema:
Das Update 4.13.36 -> 4.13.52 hatte vor Kurzem mit diversen Schwierigkeiten (genau deswegen gibt es diesen Thread) begonnen, über die Kommandozeile hat's dann irgendwann auch geklappt. Jetzt wollte ich gerade das Update .52 -> .53 machen, da kam mir zunächst ein self-update des CM mit einer Fehlermeldung dazwischen (leider war ich zu langsam, diese zu kopieren um sie hier zu posten, sie verschwand von alleine). Dennoch hat anscheinend das self-update geklappt.
Das danach angeschubbste Update .52 -> .53 lief trotzdem der CM jetzt wohl "-c path/to/php.ini" benutzt in der GUI auf den bekannten Fehler (... undefinded funtion pcntl_async_signals ...). Dennoch behauptete der CM danach die Version 4.13.53
(Im Grunde "endlich") habe ich im Anschluss auch die veraltete Erweiterung craffft/contao-calendar-ical-bundle via CLI aus meiner LIVE Instanz entfernt um zumindest das Ding betreffende Fehler und Warnungen (s.o.) nicht mehr zu haben. Nun meldet der GUI-CM auch wieder 4.13.52 - verwirrend (oder auch nicht, das o.g. Update lieferte ja wie gesagt den bekannten Fehler)
Als (zunächst) Letztes habe ich (natürlich mit jeweiligem Warten bis er "grün" fertig) ist im CLI gemacht:in der Erwartung, jetzt wirklich auf 4.13.53 zu sein.Code:$ composer update contao/manager-bundle srhinow/tinymce-plugins 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
$ vendor/bin/contao-console contao:maintenance-mode enable
$ composer install
php -c contao-manager/php.ini vendor/bin/contao-console contao:migrate
$ vendor/bin/contao-console contao:maintenance-mode disable
Leider meldete der GUI-CM immer noch 4.13.52 - aber nach Prod.Cache löschen dann endlich 4.13.53
Dummerweise habe ich im Moment nicht mehr die Zeit, tatsächlich nochmal via CLI ein Upgrade auf 5.3.x zu probieren...
Ich wollte gerade zum Testen des Upgrade auf 5.3 einer meiner Test-Instanzen vorbereiten, die hat(te) noch den CM 1.9.0 und wollte natürlich auch das Self-Update - dies' Mal war ich schnell genug, die Fehlermeldung zu kopieren:Zitat:
Zitat von purzel
Und das Log des CM:Code:ERROR 500
HTTP-Anfrage für "GET api/task" fehlgeschlagen.
Es scheint ein unbekannter Fehler aufgetreten zu sein. Prüfe die Log-Dateien deines Webservers (Apache/Nginx) und des Contao Managers im Ordner "contao-manager/logs".
### diverser Binär-Kram, siehe ZIP ### }
}
// To read method annotations
$doc = $this->parsePhpDoc($method);
if (($classIsTemplate || isset($doc['template']) || isset($doc['template-covariant'])) && $method->hasReturnType()) {
unset($doc['return']);
}
if (isset(self::$annotatedParameters[$class][$method->name])) {
$definedParameters = [];
foreach ($method->getParameters() as $parameter) {
$definedParameters[$parameter->name] = \true;
}
foreach (self::$annotatedParameters[$class][$method->name] as $parameterName => $deprecation) {
if (!isset($definedParameters[$parameterName]) && !isset($doc['param'][$parameterName])) {
$deprecations[] = \sprintf($deprecation, $className);
}
}
}
$forcePatchTypes = $this->patchTypes['force'];
if ($canAddReturnType = null !== $forcePatchTypes && !\str_contains($method->getFileName(), \DIRECTORY_SEPARATOR . 'vendor' . \DIRECTORY_SEPARATOR)) {
if ('void' !== (self::MAGIC_METHODS[$method->name] ?? 'void')) {
$this->patchTypes['force'] = $forcePatchTypes ?: 'docblock';
}
$canAddReturnType = 2 === (int) $forcePatchTypes || \false !== \stripos($method->getFileName(), \DIRECTORY_SEPARATOR . 'Tests' . \DIRECTORY_SEPARATOR) || $refl->isFinal() || $method->isFinal() || $method->isPrivate() || '.' === (self::$internal[$class] ?? null) && !$refl->isAbstract() || '.' === (self::$final[$class] ?? null) || '' === ($doc['final'][0] ?? null) || '' === ($doc['internal'][0] ?? null);
}
if (null !== ($returnType = self::$returnTypes[$class][$method->name] ?? null) && 'docblock' === $this->patchTypes['force'] && !$method->hasReturnType() && isset(TentativeTypes::RETURN_TYPES[$returnType[2]][$method->name])) {
$this->patchReturnTypeWillChange($method);
}
if (null !== ($returnType ??= self::MAGIC_METHODS[$method->name] ?? null) && !$method->hasReturnType() && !isset($doc['return'])) {
[$normalizedType, $returnType, $declaringClass, $declaringFile] = \is_string($returnType) ? [$returnType, $returnType, '', ''] : $returnType;
if ($canAddReturnType && 'docblock' !== $this->patchTypes['force']) {
$this->patchMethod($method, $returnType, $declaringFile, $normalizedType);
}
if (!isset($doc['deprecated']) && \strncmp($ns, $declaringClass, $len)) {
if ('docblock' === $this->patchTypes['force']) {
$this->pa $returnType = \explode('|', $returnType);
foreach ($returnType as $i => $t) {
if ('?' !== $t && !isset(self::BUILTIN_RETURN_TYPES[$t])) {
$returnType[$i] = '\\' . $t;
}
}
$returnType = \implode('|', $returnType);
self::$returnTypes[$class] += [$method => [$returnType, \str_starts_with($returnType, '?') ? \substr($returnType, 1) . '|null' : $returnType, $use, '']];
}
}
}
foreach ($refl->getMethods() as $method) {
if ($method->class !== $class) {
continue;
}
if (null === ($ns = self::$methodTraits[$method->getFileName()][$method->getStartLine()] ?? null)) {
$ns = $vendor;
$len = $vendorLen;
Contao Support
Hintergrund-Prozess
Bitte warte, während der Contao Manager die nötigen Operationen im Hintergrund ausführt.
Aktualisiere Contao Manager
contao-manager.phar.php self-update
Aktualisiere von 1.9.0 nach 1.9.2
Contao Manager 1.9.0
HilfeProbleme melden
Vielleicht kann es ja eine(r) der Entwickler(innen) gebrauchen. Das Server-Log könnte ich auf Wunsch erst morgen posten; ich bekomme die immer mit einem Tag Versatz von Goneo.Code:$ cat error-2025-02-26.log
[26-Feb-2025 06:40:53 UTC] PHP Fatal error: Uncaught Error: Class "_ContaoManager\Contao\ManagerApi\HttpKernel\ApiProblemResponse" not found in phar:///.../htdocs/NEW/public/contao-manager.phar.php/dist/api.php:25
Stack trace:
#0 /data/web/1/000/038/826/133535/htdocs/NEW/public/contao-manager.phar.php(69): Phar::webPhar()
#1 {main}
thrown in phar:///.../htdocs/NEW/public/contao-manager.phar.php/dist/api.php on line 25
[26-Feb-2025 06:40:53 UTC] PHP Fatal error: Uncaught Error: Class "_ContaoManager\Symfony\Component\ErrorHandler\ThrowableUtils" not found in phar:///.../htdocs/NEW/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/NEW/public/contao-manager.phar.php/vendor/symfony/error-handler/ErrorHandler.php on line 420
(Was ich leider vergessen hatte: beide Test-Instanzen sind durch meine Experimente vorige Woche unterschiedlich schlimm kaputt - ich mache also erstmal neue Kopien von der LIVE Instanz. Hier und heute ging es mir ja "nur" um die Fehlermeldung beim Self-Update des CM)
Aktualisiere manuell auf den Contao Manager 1.9.2.
Nicht notwendig, auch vorhin verschwand die Fehlermeldung von selbst und das CM-self-Update hat wohl geklappt. Das mit dem manuellen Update hatte ich beim letzten Mal schon als "nicht notwendig" geprüft (manuell geladen und md5sum verglichen)Zitat:
Zitat von purzel
Ich hoffe, morgen (genügend) Zeit für einen erneuten Versuch "Upgrade Contao 4.13 -> 5.3" zu haben.
Habe eben nochmal den Update-Prozess gestartet, zunächst den des Contao-Managers.
Darauf hin erschien ein "Error 200", wie oben auch schon beschrieben.
Zitat:
HTTP-Anfrage für "GET api/task" fehlgeschlagen.
Der Server hat eine Antwort mit Status-Code 200 gesendet.
Hier mal der komplette Report:
https://pastebin.com/8G4vePqP
Habe es mehrmals neu probiert, die Version des Contao Manager ist nun bei 1.9.2, aber ab dem Fehler hängt es nun fest.
Die Zusammenfassung der möglichen Ursachen von DeepSeek zu diesem Report war übrigens:
- Ungültige oder unvollständige API-Antwort: Die API gibt möglicherweise eine unerwartete Antwort zurück, obwohl der Statuscode 200 ist.
- Client-seitige Fehler: Die Anwendung könnte die Antwort falsch interpretieren oder verarbeiten.
- Konfigurationsprobleme: Es könnte Probleme mit der Server- oder API-Konfiguration geben, die zu einer unerwarteten Antwort führen.
PS: Von Goneo habe ich bis heute übrigens keine Antwort erhalten...
Das kommt vermutlich nur vom CM Update auf 1.9.2, am Besten mal Browser-Cache leeren.
Vielen Dank, daran lag es!
Leider hängt er beim Update von Contao danach auch weiterhin beim "composer install" fest:
Ich habe hier einfach nochmal den aktuellen Report hinterlegt:
PS: Unter "Contao" steht allerdings nun "Version 4.13.53", als neueste VersionCode:$ /usr/bin/php8.2 -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=UTC /data/web/1/000/063/713/260436/htdocs/Website-2023/public/contao-manager.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader
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>`.
Nothing to install, update or remove
Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.
Generating optimized autoload files
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
118 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> @php vendor/bin/contao-setup
Deprecated: Return type of Netzmacht\Contao\Leaflet\Frontend\Assets\LibrariesConfiguration::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/netzmacht/contao-leaflet-maps/src/Frontend/Assets/LibrariesConfiguration.php on line 74
PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
thrown in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
PHP Deprecated: Return type of Netzmacht\Contao\Leaflet\Frontend\Assets\LibrariesConfiguration::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/netzmacht/contao-leaflet-maps/src/Frontend/Assets/LibrariesConfiguration.php on line 74
13:30:04 CRITICAL [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.2 -dmemory_limit=-1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir public --env=prod --no-ansi" command: PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
thrown in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
" ["exception" => RuntimeException { …},"message" => """ An error occurred while executing the "/usr/bin/php8.2 -dmemory_limit=-1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir public --env=prod --no-ansi" command: PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n Stack trace:\n #0 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n #1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()\n #2 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n #3 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n #4 {main}\n thrown in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21\n """]
In ContaoSetupCommand.php line 146:
An error occurred while executing the "/usr/bin/php8.2 -dmemory_limit=-1 /d
ata/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager-bund
le/bin/contao-console contao:install-web-dir public --env=prod --no-ansi" c
ommand: PHP Fatal error: Uncaught Error: Call to undefined function Symfon
y\Component\Console\SignalRegistry\pcntl_async_signals() in /data/web/1/000
/063/713/260436/htdocs/Website-2023/vendor/symfony/console/SignalRegistry/S
ignalRegistry.php:21
Stack trace:
#0 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/consol
e/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegis
try->__construct()
#1 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfony/framew
ork-bundle/Console/Application.php(40): Symfony\Component\Console\Applicati
on->__construct()
#2 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager
-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBund
le\Console\Application->__construct()
#3 /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/contao/manager
-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplicat
ion->__construct()
#4 {main}
thrown in /data/web/1/000/063/713/260436/htdocs/Website-2023/vendor/symfo
ny/console/SignalRegistry/SignalRegistry.php on line 21
contao:setup
Script @php vendor/bin/contao-setup handling the post-install-cmd event returned with error code 1
# Process terminated with exit code 1
# Result: General error
PPS: Jetzt wieder "Version 4.13.50"
Manchmal ist es wie verhext, man kommt zu gar nichts... Seufz.
Endlich habe ich wieder etwas Zeit - und mir eine "frische" Kopie meiner Instanz nebst Datenbank angelegt. Die läuft noch artig mit Contao 4.13 und hat ohne Fehlermeldung den CM von 1.9.1 auf 1.9.2 aktualisiert.
Bevor ich mir nun erneut "ins Knie schieße": ich habe eine Erweiterung installiert, bei der steht unter Details "Unterstützte Contao-Version(en): 4.8+, 5.0+" - heißt "5.0+", dass das Ding auch mit 5.3 funktionieren müsste oder sollte ich die Erweiterung vor dem Upgrade-Versuch entfernen?
TIA
purzel
Grundsätzlich ja.Zitat:
Zitat von purzel
"Grundsätzlich" ist ein genauso mutiger Begriff wie "sollte" :D
Es hat natürlich zunächst NICHT geklappt; d.h. Testlauf/dry run lief fehlerfrei durch, "echtes" Aktualisieren jedoch nicht. Immerhin gab's dies' Mal was Sinnvolles in der Fehlermeldung:
...
Fatal error: Declaration of Srhinow\TinymcePlugins\SrhinowTinymcePlugins::getC ontainerExtension() must be compatible with Symfony\Component\HttpKernel\Bundle\Bundle::getCon tainerExtension(): ?Symfony\Component\DependencyInjection\Extension\E xtensionInterface in htdocs/TEST53/vendor/srhinow/tinymce-plugins/src/SrhinowTinymcePlugins.php on line 42
...
Aha: also doch die Erweiterung erstmal wegschmeißen... Was aber leider auch schief geht:
Nach Klicken auf "Bestätigen und Schließen" hängt's jetzt :(Code:composer remove srhinow/tinymce-plugins
$ /usr/bin/php8.3 -q -c /data/htdocs/TEST53/contao-manager/php.ini -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=UTC /data/htdocs/TEST53/public/contao-manager.phar.php composer remove srhinow/tinymce-plugins --no-update --no-scripts --no-ansi --no-interaction
/data/htdocs/TEST53/composer.json has been updated
# Process terminated with exit code 0
# Result: OK
composer update srhinow/tinymce-plugins contao/conflicts --no-install
Erfolgreich nach 1741612175 Sekunden. RAM-Verbrauch: 8.58MB (Spitze: 85.23MB), Dauer: 0.73s.
> Resolving dependencies using Composer Cloud v3.8.1
[6.8MiB/0.20s] Loading composer repositories with package information
[7.3MiB/0.27s] Updating dependencies
[7.4MiB/0.30s] Lock file operations: 0 installs, 1 update, 1 removal
[7.4MiB/0.30s] - Removing srhinow/tinymce-plugins (2.0.4)
[7.4MiB/0.30s] - Upgrading contao/conflicts (dev-main 7591089 => dev-main 7b02132)
[6.7MiB/0.31s] Writing lock file
[9.5MiB/0.33s] <warning>Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.</warning>
[8.1MiB/0.72s] No security vulnerability advisories found.
[8.6MiB/0.72s] Memory usage: 8.58MB (peak: 85.23MB), time: 0.73s.
[8.6MiB/0.73s] Finished Composer Cloud resolving.
# Job ID GgX0ZTMM6L9YQh3OijfX1invMLs4BhMn3LosrPR7TzvebEJHZt1RFUrsQWHWaEzCO07kpb315icmJt9C0a26icHpQha33e completed in 1741612175 seconds
# Memory usage: 8.58MB (peak: 85.23MB), time: 0.73s.
vendor/bin/contao-console contao:maintenance-mode enable
composer install
$ /usr/bin/php8.3 -q -c /data/htdocs/TEST53/contao-manager/php.ini -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=UTC /data/htdocs/TEST53/public/contao-manager.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.
Generating optimized autoload files
105 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
> @php -c contao-manager/php.ini vendor/bin/contao-setup
PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /data/htdocs/TEST53/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /data/htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /data/htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /data/htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
thrown in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
13:10:12 CRITICAL [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /data/htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir public --env=prod --no-ansi" command: PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /data/htdocs/TEST53/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /data/htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /data/htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /data/htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
thrown in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
" ["exception" => RuntimeException { …},"message" => """ An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /data/htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir public --env=prod --no-ansi" command: PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n Stack trace:\n #0 /data/htdocs/TEST53/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n #1 /data/htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()\n #2 /data/htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n #3 /data/htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n #4 {main}\n thrown in /data/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21\n """]
In ContaoSetupCommand.php line 146:
An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /d
ata/htdocs/TEST53/vendor/contao/manager-bundle/bin
/contao-console contao:install-web-dir public --env=prod --no-ansi" command
: PHP Fatal error: Uncaught Error: Call to undefined function Symfony\Comp
onent\Console\SignalRegistry\pcntl_async_signals() in /data/
htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistr
y.php:21
Stack trace:
#0 /data/htdocs/TEST53/vendor/symfony/console/Appl
ication.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->_
_construct()
#1 /data/htdocs/TEST53/vendor/symfony/framework-bu
ndle/Console/Application.php(40): Symfony\Component\Console\Application->__
construct()
#2 /data/htdocs/TEST53/vendor/contao/manager-bundl
e/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Con
sole\Application->__construct()
#3 /data/htdocs/TEST53/vendor/contao/manager-bundl
e/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->_
_construct()
#4 {main}
thrown in /data/htdocs/TEST53/vendor/symfony/con
sole/SignalRegistry/SignalRegistry.php on line 21
contao:setup
Script @php -c contao-manager/php.ini vendor/bin/contao-setup handling the post-install-cmd event returned with error code 1
# Process terminated with exit code 1
# Result: General error
vendor/bin/contao-console contao:maintenance-mode disable
{EDIT}
Nach mehrfachem Neustarten des CM hängt's nicht mehr, die Erweiterung srhinow/tinymce-plugins ist noch da.
Ich denke du wirst bei Goneo aktuell nicht drum rum kommen die Dinge nur auf der Konsole auszuführen.
Das fürchte ich auch - ich bin nun aber irritiert... In der Console habe ich
$ composer remove srhinow/tinymce-plugins
$ vendor/bin/contao-console contao:maintenance-mode enable
$ composer update srhinow/tinymce-plugins contao/conflicts --no-install
$ composer install
$ vendor/bin/contao-console contao:maintenance-mode disable
ausgeführt; alles grün. Vorsichtshalber im grafischen CM nochmal den Prod.-Cache erneuert (*)
Trotzdem war vermeintlich srhinow/tinymce-plugins immer noch da.
Erst nach erneutem Ab- und Anmelden im CM war das Ding weg.
So, wenn ich nun die 4.13(.53) Instanz, die jetzt keine Erweiterungen mehr enthält (jedenfalls laut grafischem CM) via Console auf 5.3.x anheben möchte, was muss dann in die composer.json? Ich habe nämlich das mit dem Caret ^ immer noch nicht verstanden - obwohl Du mir mal https://github.com/contao/managed-ed...er.json#L6-L15 verlinkt hast :o
Im Moment sieht die composer.json so aus:Also GAR KEINE Carets. Wann macht man ein ^ hin und wann nicht? Sorry, an der Stelle bin ich wohl zu blöd...Code:{
"type": "project",
"require": {
"contao/calendar-bundle": "4.13.*",
"contao/comments-bundle": "4.13.*",
"contao/conflicts": "*@dev",
"contao/faq-bundle": "4.13.*",
"contao/listing-bundle": "4.13.*",
"contao/manager-bundle": "4.13.*",
"contao/news-bundle": "4.13.*",
"contao/newsletter-bundle": "4.13.*"
},
"extra": {
"contao-component-dir": "assets"
},
"scripts": {
"post-install-cmd": [
"@php -c contao-manager/php.ini vendor/bin/contao-setup"
],
"post-update-cmd": [
"@php -c contao-manager/php.ini vendor/bin/contao-setup"
]
},
"config": {
"allow-plugins": {
"contao-components/installer": true,
"php-http/discovery": true,
"contao/manager-plugin": true
}
}
}
(*) ich hatte die Befehle dazu nicht im Kopf; vielleicht sollte ich mir eine Art Shell-Script o.ä. schreiben...
Müsstest du etwas umdrehen. Idealerweise willst du den Maintenace Mode aktivieren bevor du irgendwas ausführst (wie zB eine Extension hinzufügen oder entfernen):Zitat:
Zitat von purzel
Code:vendor/bin/contao-console contao:maintenance-mode enable
composer remove srhinow/tinymce-plugins
vendor/bin/contao-console contao:maintenance-mode disable
Einleuchtend...Zitat:
Zitat von Spooky
Das war bestimmt ein copy & paste Fehler; in meiner "Notizen Datei" ist es noch in der richtigen Reihenfolge :eek:
Was mache ich nun mit (oder ohne?) dem Caret?
{später}
Hiernach würde ich das Caret überall WEGLASSEN (wollen)... weil ich ja nur LTS Versionen haben möchte.
Dann musst du https://getcomposer.org/doc/articles/versions.md studieren ;)Zitat:
Zitat von purzel
^4.13 erlaubt auch 4.99 (falls es das gäbe)
4.13.* erlaubt nur 4.13
Hier kannst du dir sowas illustrieren lassen: https://semver.madewithlove.com/, z.B.:
Vielen Dank, dieses "Illustrations-Ding" hat mir geholfen.
Demnach (und auch nach meinem Link in #157) lasse ich das Caret überall weg, weil ich ja nur 5.3 LTS und eben nicht die "kurzlebigen" non-LTS Versionen haben möchte.
Folglich wäre meine composer.json dann so: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.*"
},
"extra": {
"contao-component-dir": "assets"
},
"scripts": {
"post-install-cmd": [
"@php -c contao-manager/php.ini vendor/bin/contao-setup"
],
"post-update-cmd": [
"@php -c contao-manager/php.ini vendor/bin/contao-setup"
]
},
"config": {
"allow-plugins": {
"contao-components/installer": true,
"php-http/discovery": true,
"contao/manager-plugin": true
}
}
}
Du schreibst immer "weglassen". Es geht nicht um das Caret weglassen oder nicht, sondern welche Variante du nimmst (ein ^5.3.* wäre ja bspw. falsch).Zitat:
Zitat von purzel
Ä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:und versucht, das Upgrade via CLI anzuschubbsen (Wie gesagt: ich will nur die LTS 5.3, keine 5.4 usw.) :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.*"
},
...
$ 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:Also wohl doch was falsch (verstanden) mit dem Caret?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.
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:Nun traue ich mich nicht, dem "Vorschlag" aus der letzten Zeile Folge leisten, weil da was von downgrades und removals steht...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.
Ich bin der Meinung, auf Basis von https://docs.contao.org/manual/de/migration/ die Zeilen mit ^ oder * richtig gemacht zu haben:Darf ich "gefahrlos" --with-all-dependencies mit an meine $ composer update ... Zeile anhängen?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"
},
...
Ja, musst du auch.Zitat:
Zitat von purzel
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
Die musst du entfernen bzw. anpassen. Einfach mal die Installation danach durchsuchen.HTML-Code:if (!defined('TL_ROOT')) die('You cannot access this file directly');
$ 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.
Ganz fehlerlos ist es (neuer Versuch mit frischer Kopie) nicht, schon das composer update -o endet nach ganz viel grün mitZitat:
Zitat von Spooky
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
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.Zitat:
Zitat von purzel
$ 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]
contao:migrate --no-interaction löscht nichts by default - das wäre ja fatal.Zitat:
Zitat von purzel
Stimmt auch wieder - wo er Recht hat er Recht ;)Zitat:
Zitat von Spooky
Lass' mich bitte nicht dumm sterben :cool:Zitat:
Zitat von purzel
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
Das ist eine Performance Optimierung. In einer Live-Umgebung muss das immer so ausgeführt werden - andernfalls bekommst du nicht die beste Performance.Zitat:
Zitat von purzel
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: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?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
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
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.Zitat:
Zitat von purzel
MooTools an sich gibt es auch in Contao 5 noch. Nur diese Extension funktioniert in Contao 5 nicht einfach so.
https://gitlab.com/srhinow/tinymce-plugins/-/issues <-- Machst du Issue auf (GitLab Account notwendig)Zitat:
Zitat von purzel
Dann installiere dir die Erweiterung, importiere die Sachen, deinstalliere sie wieder.Zitat:
Zitat von purzel
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.
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?Zitat:
Zitat von purzel
Es ist wohl ein Contao 3 Modul - Hier hast du also mindestens 8 Jahre Zeit gehabt eine Alternative zu suchen.
[/QUOTE]Zitat:
Zitat von purzel
@Moderation <3
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 Spooky
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?Zitat:
Zitat von zoglo
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...
Ich bin mir nicht sicher, ob ich diesen Weg praktikabel genug finde um es JEDES Jahr zu machen ...Zitat:
Zitat von zoglo
So wie ich das verstehe, IST doch cgoit/contao-calendar-ical-bundle ein entsprechender Fork - bei dem ich... siehe oben ;)Zitat:
Zitat von zoglo
Sorry, finanzielle Aufträge widersprechen dem bereits anfangs diskutierten "ehrenamtlich für den Verein".
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.Zitat:
Zitat von zoglo
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.
Wird so sein, ja - weil halt extrem veraltet.Zitat:
Zitat von purzel
Ich konnte GitLab und GitHub sozusagen verknüpfen und habe ein Issue erstellt. Ob's was bringt werden wir sehen...Zitat:
Zitat von purzel
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
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.Zitat:
Zitat von purzel
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:
Anhang 27767Code:[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