Goneo: Contao-Manager kaputt?

[purzel]

Guten Morgen zusammen!

nach 4 Wochen Pause wollte ich mich noch einmal an das Update, im Idealfall danach Upgrade auf 5.3 wagen.
Die derzeitigen Fakten: Seit den 4 Wochen läuft meine Instanz stabil mit PHP 8.3.15 (sowohl Web als auch CLI), aber immer noch mit Contao 4.13.36 mit nur zwei Erweiterungen von denen eine nicht mehr gepflegt wird. Meine composer.json sieht so aus:

$ cat ../composer.json 
{
    "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.*",
        "craffft/contao-calendar-ical-bundle": "^4.2",
        "srhinow/tinymce-plugins": "^2.0"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "@php vendor/bin/contao-setup"
        ],
        "post-update-cmd": [
            "@php vendor/bin/contao-setup"
        ]
    }
}

und das public Verzeichnis heißt auch public, nicht mehr web wie damals. [EDIT: Fehler korrigiert]
Ich habe den Contao Manager gestartet, der wollte sich zunächst selbst aktualisieren und hat das offenbar auch gemacht. Dann habe ich ganz oben auf "Update Packages" gefolgt von ganz unten "Dry Run" geklickt. Nach einer halben Stunden (!) des Wartens auf Fortschritt - es blieb bereits beim ersten Schritt hängen - habe ich zum Einen die Detailansicht aktiviert und kurz darauf "Cancel". Auch die task.json habe ich wieder löschen müssen, weil auch das Abbrechen nicht klappte.
In der vorgenannten Detailansicht irritierte mich ganz gewaltig, dass da stand
$ /usr/bin/php8.1 ... /contao-manager.phar.php composer update contao ...
Wo zum Geier kommt das 8.1 noch her? Ich habe meine Freunde find und grep los geschickt, es gab eine Stelle, an der mir die Änderung auf 8.3 sinnvoll erschien: composer-update.set.json - doch leider führt(e) auch auch das nicht zum Erfolg.
Anschließend habe ich - ein bisschen widerwillig - diese "Resolver Cloud" aktiviert, die Caches Prod.-Cache, Composer Cache und Opcode Cache gelöscht und einen neuen Versuch des "Update Packages" gefolgt von ganz unten "Dry Run" gewagt. Zumindest der Testlauf/DryRun lief anscheinend fehlerfrei, daraufhin habe ich mich getraut auf "Änderungen anwenden" zu klicken.
Die große Ernüchterung: die ersten beiden Punkte "composer update contao/manager-bundle ..." und "vendor/bin/contao-console contao:maintenance-mode enable" bekamen ihren grünen Haken, der dritte Schritt "composer install" nach 5 von 5 Versuchen ein rotes Kreuzchen
Im Fenster "Pakete werden aktualisiert" stand

$ /usr/bin/php8.3 -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 /.../htdocs/LIVE/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
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
105 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> @php vendor/bin/contao-setup
PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /.../htdocs/LIVE/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /.../htdocs/LIVE/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /.../htdocs/LIVE/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /.../htdocs/LIVE/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /.../htdocs/LIVE/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /.../htdocs/LIVE/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
10:34:47 CRITICAL  [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /.../htdocs/LIVE/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 /.../htdocs/LIVE/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /.../htdocs/LIVE/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /.../htdocs/LIVE/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /.../htdocs/LIVE/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /.../htdocs/LIVE/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /.../htdocs/LIVE/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 /.../htdocs/LIVE/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 /.../htdocs/LIVE/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n  Stack trace:\n  #0 /.../htdocs/LIVE/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n  #1 /.../htdocs/LIVE/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()\n  #2 /.../htdocs/LIVE/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n  #3 /.../htdocs/LIVE/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n  #4 {main}\n    thrown in /.../htdocs/LIVE/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 /  
  .../htdocs/LIVE/vendor/contao/manager-bundle/bin/c  
  ontao-console contao:install-web-dir public --env=prod --no-ansi" command:   
  PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Compon  
  ent\Console\SignalRegistry\pcntl_async_signals() in /.../  
  /htdocs/LIVE/vendor/symfony/console/SignalRegistry/SignalRegistry.ph  
  p:21                                                                         
  Stack trace:                                                                 
  #0 /.../htdocs/LIVE/vendor/symfony/console/Applic  
  ation.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__c  
  onstruct()                                                                   
  #1 /.../htdocs/LIVE/vendor/symfony/framework-bund  
  le/Console/Application.php(40): Symfony\Component\Console\Application->__co  
  nstruct()                                                                    
  #2 /.../htdocs/LIVE/vendor/contao/manager-bundle/  
  src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Conso  
  le\Application->__construct()                                                
  #3 /.../htdocs/LIVE/vendor/contao/manager-bundle/  
  bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__c  
  onstruct()                                                                   
  #4 {main}                                                                    
    thrown in /.../htdocs/LIVE/vendor/symfony/conso  
  le/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

Interessanterweise steht nun TROTZDEM unter "Pakete" im CM, ich hätte Contao 4.13.52 - was ist denn nun richtig? Ich habe nochmals den Prod.-Cache gelöscht, die Datenbank geprüft un die geforderte Änderung gemacht; zu guter Letzt den Wartungsmodus deaktiviert. Das Backend zeit auch Version 4.13.52 an und das Frontend scheint zu laufen. Dennoch bin ich verunsichert wegen der o.g. Fehlermeldung. Zu was könnt Ihr mir raten (außer Hosterwechsel )

TIA
purzel

[zoglo]

Interessanterweise steht nun TROTZDEM unter "Pakete" im CM, ich hätte Contao 4.13.52 - was ist denn nun richtig? Ich habe nochmals den Prod.-Cache gelöscht, die Datenbank geprüft un die geforderte Änderung gemacht; zu guter Letzt den Wartungsmodus deaktiviert. Das Backend zeit auch Version 4.13.52 an und das Frontend scheint zu laufen. Dennoch bin ich verunsichert wegen der o.g. Fehlermeldung. Zu was könnt Ihr mir raten (außer Hosterwechsel )

TIA
purzel

Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove

Es gibt nichts zu installieren

Hast du die PHP Module auch aktiviert wie in der Doku beschrieben? Es kann sein, dass es nun mit PHP 8.3 gewisse Module nicht gibt?
https://docs.contao.org/manual/de/in...raussetzungen/

[lbableck]

In deiner php.ini ist unter disable_functions wahrscheinlich pcntl_async_signals aufgeführt, das musst du entfernen (lassen), eventuell auch noch weitere Funktionen.

[purzel]

Zumindest phpinfo() liefert mir unter Core:

Directive Local Value Master Value
...
disable_functions no value no value
...

Meintet Ihr das?

[purzel]

Hallo nochmal,
ich habe mich durch die Liste der Systemvoraussetzungen gequält und folgendes gefunden, was NICHT den aufgelisteten Erfordernissen entspricht:
memory_limit ist nur 128M
opcache.enable_cli ist 1
Das mit dem Speicher könnte ja erklären, warum diese Updates immer hängen bleiben; ist das opcache.enable_cli=on ein Problem?

Woher bekomme ich Info, ob die MySQL Anforderungen erfüllt sind? Oder "müsste" das erfüllt sein, da ja anscheinend alles funktioniert was die DB betrifft?

[Spooky]

Zumindest phpinfo() liefert mir unter Core:

Directive Local Value Master Value
...
disable_functions no value no value
...

Meintet Ihr das?

Du müsstest wenn dann eher die CLI Config prüfen.

[purzel]

Ich fürchte, ich brauche etwas mehr Unterstützung.

/etc/php/8.3/cli/conf.d$ fgrep pcntl *
/etc/php/8.3/cli/conf.d$ fgrep disable *
/etc/php/8.3/cli/conf.d$ fgrep off *

findet nichts.

Das Beispielscript auf https://www.php.net/manual/de/function.pcntl-signal.php liefert im Browser
Richte Signalverarbeitung ein... Erzeuge signal SIGTERM an mich selbst... SIGUSR1 abgefangen... Fertig
und im CLI
Richte Signalverarbeitung ein...
PHP Fatal error: Uncaught Error: Call to undefined function pcntl_signal() in /.../htdocs/LIVE/public/st.php:29

Das hatte ich sozusagen als Basis versucht um herauszufinden, warum https://github.com/iansltx/pcntl-dem...nals/async.php nicht funktioniert.

Wie finde ich nun also heraus, ob irgendeine Konfiguration nicht passt und/oder irgendwas dem Upgrade von Contao auf 5.x entgegen steht?

Ich kann zwar relativ gut mit der Shell und auch ein paar wenige Basics mit PHP - aber diese ganzen "speziellen" Dinge ... da bin ich 'raus.

[Spooky]

/usr/bin/php8.3 -r "var_dump(ini_get('disable_functions'));"

[lbableck]

/etc/php/8.3/cli/conf.d$ fgrep pcntl *
/etc/php/8.3/cli/conf.d$ fgrep disable *
/etc/php/8.3/cli/conf.d$ fgrep off *

findet nichts.

Das steht eher in /etc/php/8.3/cli/php.ini, nicht im conf.d Unterverzeichnis.

[purzel]

Ah, OK, danke.

Leider ist wirklich

In deiner php.ini ist unter disable_functions wahrscheinlich pcntl_async_signals aufgeführt, das musst du entfernen (lassen), eventuell auch noch weitere Funktionen.

dabei:

$ fgrep disable_functions /etc/php/8.3/cli/php.ini
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,

Was davon braucht Contao bzw. die "Updaterei"?
Muss das zwingend der Hoster 'raus nehmen oder kann ich evtl. irgendwas "Schlaues" in eine eigene php.ini (wo muss die liegen?) schreiben - zumindest versuchen ob es klappt?

Kann ich DANN irgendwie testen, ob die "eigene" php.ini "wirksam" ist oder die Globale?

Ich habe übrigens "nur" ein einfaches Webhosting (immerhin mit Shell), keinen Root Server.

[Spooky]

Was davon braucht Contao

Nicht so einfach rauszufinden - da es ja auch nicht Contao selbst ist, dass das braucht, sondern eine Komponente von Symfony. Du könntest entweder alles entfernen (was meiner Meinung nach voll ok ist), oder die Dinge nacheinander entfernen (lassen) und prüfen ob es zu Fehlern kommt.

[tab]

Ich denke nicht, dass du das selbst erfolgreich ändern kannst.

Edit: Zur Antwort von @Spooky
Ich denke auch nicht, dass es schlimm wäre alles rauszunehmen. Wenn ich mir das z.B. beim netcup-Webhosting anschaue, dann ist da beim PHP-CLI gar nichts disabled. Dagegen sieht die Liste für PHP im Webprozess zumindest ähnlich aus wie bei dir die für PHP-CLI. Die machen das also genau andersrum, wieso auch immer.

[lbableck]

Man kann anscheinend im Contao Manager Ordner eine php.ini ablegen, die dann genutzt werden sollte. Hab ich aber auch noch nie gemacht, weiß also nicht ob das in dem Fall funktioniert, denn eigentlich setzt der CM eh -ddisable_functions=
Aber das greift wohl nicht.
https://github.com/contao/contao-man...ctory.php#L242

[Spooky]

denn eigentlich setzt der CM eh -ddisable_functions=
Aber das greift wohl nicht.
https://github.com/contao/contao-man...ctory.php#L242

Hm, evt. gilt das dann nicht mehr für den @php vendor/bin/contao-setup Subprozess, den Composer dann ausführt.

[purzel]

Hm, das wird jetzt aber schwierig (und off topic).

Als Test habe ich eine php.ini in meinem htdocs/LIVE/public angelegt mit
disable_functions=
Dort liegt auch o.g. Test von https://www.php.net/manual/de/function.pcntl-signal.php
Bei NUR einem
/htdocs/LIVE/public$ php st.php
gibt das wieder die Fehlermeldung
PHP Fatal error: Uncaught Error: Call to undefined function pcntl_signal() in /htdocs/LIVE/public/st.php:29

ABER: Wenn ich probiere
/htdocs/LIVE/public$ php -c ./php.ini st.php
DANN ist die Ausgabe wie im Web, also Richte Signalverarbeitung ein... Erzeuge signal SIGTERM an mich selbst... SIGUSR1 abgefangen... Fertig

Die Admins von Goneo werden sich bestimmt schwer tun wenn ich darum bitte ALLES aus disable_functions 'rauszunehmen auf Basis von Spekulationen; versuchen kann ich es natürlich. Im Web ist anscheinend GAR NICHTS disabled:
echo ini_get('disable_functions');
listet im CLI alles o.g. auf, im Browser bleibt die Ausgabe leer.

[Spooky]

Wenn sie's im Web erlauben, können sie's auch genausogut auf dem CLI erlauben

[mlweb]

Zu was könnt Ihr mir raten (außer Hosterwechsel )

Warum lehnst Du bei den Schwierigkeiten einen Hosterwechsel so vehement ab?

[purzel]

Wenn sie's im Web erlauben, können sie's auch genausogut auf dem CLI erlauben

Ich versuch's einfach mal...

Warum lehnst Du bei den Schwierigkeiten einen Hosterwechsel so vehement ab?

Weil ich das Ehrenamt der Webseite(npflege) im Verein "eigentlich" seit dem Jahreswechsel nicht mehr mache, helfe jetzt für eine gewisse Übergangs- und Einarbeitungszeit nur noch aus.

[mlweb]

Weil ich das Ehrenamt der Webseite(npflege) im Verein "eigentlich" seit dem Jahreswechsel nicht mehr mache, helfe jetzt für eine gewisse Übergangs- und Einarbeitungszeit nur noch aus.

Die Begründung muss ich jetzt nicht verstehen. In der Zeit, die Du im Moment investiert ist doch ein Umzug erledigt.

[purzel]

Sorry, das wird jetzt OffTopic...

Natürlich bin ich dankbar für die vielen Tipps und fundierte Hilfe die man hier meist bekommt. Ich will dennoch versuchen zu erklären, warum ich möglichst auf einen Hoster-Wechsel verzichten möchte...

• ich habe anfangs überhaupt nicht absehen können, dass sich das Problem so lange hinzieht - zumal die Ursache ja offenbar erst jetzt gefunden ist
• es ist bekanntlich nicht damit getan, ein paar Megabyte Daten durch die Gegend zu kopieren, dazu kommen noch
• Formalien (Domainumzug, Kündigung), Wartezeiten darauf und Vertragslaufzeiten - die Aufwand machen und beachtet werden wollen - ergo Zeit kosten
• es abgesehen davon zusätzlich einen Haufen Zeit kosten kann, einen "passenden" Hoster (Leistungsumfang, Contao-Tauglichkeit, monatliche KOSTEN) zu finden
• ich habe etliche Mail-Konten und -weiterleitungen die ebenfalls migriert werden müssten; auch DAS kostet Zeit
• wie gesagt mache ich den Job "ehrenamtlicher Webmaster" im Verein nach fast 18 Jahren nun nicht mehr, arbeite im Grunde nur noch meine Nachfolgerin ein
• ich bin (bzw. war) im Verein weder für Finanzen zuständig/befugt noch im Vorstand, ergo keine "Entscheidungsgewalt". Den Zuständigen/Verantwortichen den Bedarf und die Gründe für den Wechel zu erklären braucht auch nicht wenig Zeit
• genauer bin ich noch nicht einmal mehr Vereinsmitglied, wollte einfach nur "keinen Scherbenhaufen hinterlassen" (zumal oder gerade weil ich mit den Leuten immer noch super klar komme)
• nicht nur diesbezüglich: ich bin allgemein nicht so der Freund von "contract hopping" (wenn es vermeidbar ist)

Zurück zum Thema: gestern Abend habe ich Goneo angeschrieben, habe aber noch keine Antwort.
Wenn sie sich nun weigern sollten, das CLI-PHP dem "Web-PHP" "anzugleichen" - habe ich denn keine andere Möglichkeit als Hosterwechsel wenn ich zu Conato 5 will?
Man könnte natürlich (auch DAS kostet Zeit, ich weiß) einfach mal eine "frische", leere Contao 5 Installation ausprobieren... Könnte die dann in einem zweiten Schritt Daten der 4.13 sozusagen importieren?

[Spooky]

Wenn sie sich nun weigern sollten, das CLI-PHP dem "Web-PHP" "anzugleichen" - habe ich denn keine andere Möglichkeit als Hosterwechsel wenn ich zu Conato 5 will?

Versuche mal den "script" Teil deiner composer.json auf folgendes zu ändern:

    "scripts": {
        "post-install-cmd": [
            "@php -ddisable_functions= vendor/bin/contao-setup"
        ],
        "post-update-cmd": [
            "@php -ddisable_functions= vendor/bin/contao-setup"
        ]
    },

[purzel]

Moin.
Ich habe zum Glück eine Zweit-Installation zum "Üben"...

ERSTENS habe ich in der zweiten Instanz

1. auch endlich auf PHP 8.3 umgestellt
2. die Änderung in die composer.json eingefügt
3. via CM alle Caches gelöscht
4. Pakete aktualisieren (oben) geklickt
5. a. Dry run (unten) geklickt
   b. Änderungen übernehmen geklickt

Bis einschließlich 5a (eigentlich erwartungsgemäß) alles gut.
Beim letzten Schritt leider wieder nur Teilerfolge:

composer update contao/manager-bundle craffft/contao-calendar-ical-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

Erfolgreich nach 12 Sekunden. RAM-Verbrauch: 16.89MB (Spitze: 213.51MB), Dauer: 14.48s.
> Resolving dependencies using Composer Cloud v3.8.1
[6.8MiB/0.18s] Loading composer repositories with package information
[92.6MiB/12.67s] Updating dependencies
[30.3MiB/14.05s] Lock file operations: 1 install, 132 updates, 1 removal
[30.3MiB/14.05s]   - Removing stella-maris/clock (0.1.7)
[30.3MiB/14.05s]   - Upgrading beberlei/assert (v3.3.2 => v3.3.3)
[30.3MiB/14.05s]   - Upgrading composer/ca-bundle (1.4.0 => 1.5.5)
[30.3MiB/14.05s]   - Upgrading contao-components/ace (1.32.6 => 1.37.5)
[30.3MiB/14.06s]   - Downgrading contao-components/colorbox (1.6.6 => 1.6.4.2)
[30.3MiB/14.06s]   - Upgrading contao-components/contao (9.3.4 => 9.4.0)
[30.3MiB/14.06s]   - Downgrading contao-components/mediabox (1.5.5 => 1.5.4.3)
[30.3MiB/14.06s]   - Upgrading contao-components/mootools (1.6.0.7 => 1.6.0.9)
[30.3MiB/14.06s]   - Upgrading contao-components/swipe (2.2.1 => 2.2.2)
[30.3MiB/14.06s]   - Upgrading contao-components/tablesort (4.0.1 => 4.0.2)
[30.3MiB/14.06s]   - Upgrading contao-components/tablesorter (2.31.3 => 2.31.3.1)
[30.3MiB/14.06s]   - Upgrading contao/calendar-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.06s]   - Upgrading contao/comments-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.06s]   - Upgrading contao/conflicts (dev-main 8d5342f => dev-main cd5835f)
[30.3MiB/14.06s]   - Upgrading contao/core-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.06s]   - Upgrading contao/faq-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.06s]   - Upgrading contao/image (1.2.0 => 1.2.2)
[30.3MiB/14.06s]   - Upgrading contao/imagine-svg (1.0.3 => 1.0.4)
[30.3MiB/14.07s]   - Upgrading contao/installation-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.07s]   - Upgrading contao/listing-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.07s]   - Upgrading contao/manager-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.07s]   - Upgrading contao/manager-plugin (2.13.1 => 2.13.3)
[30.3MiB/14.07s]   - Upgrading contao/news-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.07s]   - Upgrading contao/newsletter-bundle (4.13.36 => 4.13.52)
[30.3MiB/14.07s]   - Upgrading dasprid/enum (1.0.5 => 1.0.6)
[30.3MiB/14.07s]   - Upgrading dflydev/dot-access-data (v3.0.2 => v3.0.3)
[30.3MiB/14.07s]   - Upgrading doctrine/annotations (2.0.1 => 2.0.2)
[30.3MiB/14.07s]   - Upgrading doctrine/common (3.4.3 => 3.5.0)
[30.3MiB/14.07s]   - Upgrading doctrine/dbal (3.8.1 => 3.9.4)
[30.3MiB/14.07s]   - Upgrading doctrine/deprecations (1.1.3 => 1.1.4)
[30.3MiB/14.07s]   - Upgrading doctrine/doctrine-bundle (2.11.2 => 2.13.2)
[30.3MiB/14.07s]   - Upgrading doctrine/inflector (2.0.9 => 2.0.10)
[30.3MiB/14.07s]   - Upgrading doctrine/orm (2.18.0 => 2.20.2)
[30.3MiB/14.08s]   - Upgrading doctrine/sql-formatter (1.1.3 => 1.5.2)
[30.3MiB/14.08s]   - Upgrading egulias/email-validator (4.0.2 => 4.0.3)
[30.3MiB/14.08s]   - Upgrading friendsofsymfony/http-cache (2.15.3 => 2.16.2)
[30.3MiB/14.08s]   - Upgrading friendsofsymfony/http-cache-bundle (2.17.0 => 2.17.1)
[30.3MiB/14.08s]   - Upgrading imagine/imagine (1.3.5 => 1.5.0)
[30.3MiB/14.08s]   - Upgrading knplabs/knp-menu (v3.4.0 => v3.6.0)
[30.3MiB/14.08s]   - Upgrading knplabs/knp-menu-bundle (v3.3.0 => v3.5.0)
[30.3MiB/14.08s]   - Upgrading lcobucci/clock (2.3.0 => 3.3.1)
[30.3MiB/14.08s]   - Upgrading lcobucci/jwt (4.1.5 => 4.3.0)
[30.3MiB/14.08s]   - Upgrading league/commonmark (2.4.2 => 2.6.1)
[30.3MiB/14.08s]   - Upgrading league/flysystem (3.24.0 => 3.29.1)
[30.3MiB/14.08s]   - Upgrading league/flysystem-bundle (3.3.2 => 3.4.0)
[30.3MiB/14.08s]   - Upgrading league/flysystem-local (3.23.1 => 3.29.0)
[30.3MiB/14.08s]   - Upgrading league/mime-type-detection (1.15.0 => 1.16.0)
[30.3MiB/14.09s]   - Upgrading matthiasmullie/minify (1.3.71 => 1.3.73)
[30.3MiB/14.09s]   - Upgrading monolog/monolog (2.9.2 => 2.10.0)
[30.3MiB/14.09s]   - Upgrading nelmio/cors-bundle (2.4.0 => 2.5.0)
[30.3MiB/14.09s]   - Upgrading nette/schema (v1.3.0 => v1.3.2)
[30.3MiB/14.09s]   - Upgrading nette/utils (v4.0.4 => v4.0.5)
[30.3MiB/14.09s]   - Upgrading nikic/php-parser (v4.18.0 => v4.19.4)
[30.3MiB/14.09s]   - Upgrading nyholm/psr7 (1.8.1 => 1.8.2)
[30.3MiB/14.09s]   - Upgrading paragonie/constant_time_encoding (v2.6.3 => v2.7.0)
[30.3MiB/14.09s]   - Upgrading php-http/client-common (2.7.1 => 2.7.2)
[30.3MiB/14.09s]   - Upgrading php-http/discovery (1.19.2 => 1.20.0)
[30.3MiB/14.09s]   - Upgrading php-http/httplug (2.4.0 => 2.4.1)
[30.3MiB/14.10s]   - Upgrading php-http/message (1.16.0 => 1.16.2)
[30.3MiB/14.10s]   - Upgrading php-http/promise (1.3.0 => 1.3.1)
[30.3MiB/14.10s]   - Upgrading psr/http-factory (1.0.2 => 1.1.0)
[30.3MiB/14.10s]   - Upgrading scssphp/scssphp (v1.12.1 => v1.13.0)
[30.3MiB/14.10s]   - Upgrading sensiolabs/ansi-to-html (v1.2.1 => v1.3.0)
[30.3MiB/14.10s]   - Upgrading simplepie/simplepie (1.8.0 => 1.8.1)
[30.3MiB/14.10s]   - Upgrading spatie/schema-org (3.23.0 => 3.23.1)
[30.3MiB/14.10s]   - Upgrading srhinow/tinymce-plugins (2.0.1 => 2.0.4)
[30.3MiB/14.10s]   - Upgrading symfony/asset (v5.4.35 => v5.4.45)
[30.3MiB/14.10s]   - Upgrading symfony/cache (v5.4.35 => v5.4.46)
[30.3MiB/14.10s]   - Upgrading symfony/cache-contracts (v2.5.2 => v2.5.4)
[30.3MiB/14.11s]   - Upgrading symfony/clock (v6.4.3 => v7.2.0)
[30.3MiB/14.11s]   - Upgrading symfony/config (v5.4.35 => v5.4.46)
[30.3MiB/14.11s]   - Upgrading symfony/console (v5.4.35 => v5.4.47)
[30.3MiB/14.11s]   - Upgrading symfony/debug-bundle (v5.4.35 => v5.4.45)
[30.3MiB/14.11s]   - Upgrading symfony/dependency-injection (v5.4.35 => v5.4.48)
[30.3MiB/14.11s]   - Upgrading symfony/deprecation-contracts (v3.4.0 => v3.5.1)
[30.3MiB/14.11s]   - Upgrading symfony/doctrine-bridge (v5.4.35 => v5.4.48)
[30.3MiB/14.11s]   - Upgrading symfony/dom-crawler (v5.4.35 => v5.4.48)
[30.3MiB/14.11s]   - Upgrading symfony/dotenv (v5.4.35 => v5.4.48)
[30.3MiB/14.11s]   - Upgrading symfony/error-handler (v5.4.35 => v5.4.46)
[30.3MiB/14.11s]   - Upgrading symfony/event-dispatcher (v5.4.35 => v5.4.45)
[30.3MiB/14.11s]   - Upgrading symfony/event-dispatcher-contracts (v3.4.0 => v3.5.1)
[30.3MiB/14.12s]   - Upgrading symfony/expression-language (v5.4.35 => v5.4.45)
[30.3MiB/14.12s]   - Upgrading symfony/filesystem (v5.4.35 => v5.4.45)
[30.3MiB/14.12s]   - Upgrading symfony/finder (v5.4.35 => v5.4.45)
[30.3MiB/14.12s]   - Upgrading symfony/framework-bundle (v5.4.35 => v5.4.45)
[30.3MiB/14.12s]   - Upgrading symfony/http-client (v5.4.35 => v5.4.49)
[30.3MiB/14.12s]   - Upgrading symfony/http-client-contracts (v2.5.2 => v2.5.5)
[30.3MiB/14.12s]   - Upgrading symfony/http-foundation (v5.4.35 => v5.4.48)
[30.3MiB/14.12s]   - Upgrading symfony/http-kernel (v5.4.35 => v5.4.48)
[30.3MiB/14.12s]   - Upgrading symfony/intl (v5.4.35 => v5.4.47)
[30.3MiB/14.12s]   - Upgrading symfony/lock (v5.4.35 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/mailer (v5.4.35 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/mime (v5.4.35 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/monolog-bridge (v5.4.35 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/options-resolver (v5.4.21 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/password-hasher (v5.4.35 => v5.4.45)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-ctype (v1.29.0 => v1.31.0)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-intl-grapheme (v1.29.0 => v1.31.0)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-intl-idn (v1.29.0 => v1.31.0)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-intl-normalizer (v1.29.0 => v1.31.0)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-mbstring (v1.29.0 => v1.31.0)
[30.3MiB/14.13s]   - Upgrading symfony/polyfill-php72 (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/polyfill-php73 (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/polyfill-php80 (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/polyfill-php81 (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/polyfill-php83 (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/polyfill-uuid (v1.29.0 => v1.31.0)
[30.3MiB/14.14s]   - Upgrading symfony/process (v5.4.35 => v5.4.47)
[30.3MiB/14.14s]   - Upgrading symfony/property-access (v5.4.35 => v5.4.45)
[30.3MiB/14.14s]   - Upgrading symfony/property-info (v6.4.3 => v6.4.18)
[30.3MiB/14.14s]   - Locking symfony/rate-limiter (v5.4.47)
[30.3MiB/14.14s]   - Upgrading symfony/routing (v5.4.35 => v5.4.48)
[30.3MiB/14.14s]   - Upgrading symfony/security-bundle (v5.4.35 => v5.4.45)
[30.3MiB/14.14s]   - Upgrading symfony/security-core (v5.4.35 => v5.4.48)
[30.3MiB/14.15s]   - Upgrading symfony/security-csrf (v5.4.35 => v5.4.45)
[30.3MiB/14.15s]   - Upgrading symfony/security-guard (v5.4.35 => v5.4.45)
[30.3MiB/14.15s]   - Upgrading symfony/security-http (v5.4.35 => v5.4.47)
[30.3MiB/14.15s]   - Upgrading symfony/service-contracts (v2.5.2 => v2.5.4)
[30.3MiB/14.15s]   - Upgrading symfony/stopwatch (v5.4.35 => v5.4.45)
[30.3MiB/14.15s]   - Upgrading symfony/string (v5.4.35 => v5.4.47)
[30.3MiB/14.15s]   - Upgrading symfony/templating (v6.4.3 => v6.4.13)
[30.3MiB/14.15s]   - Upgrading symfony/translation (v5.4.35 => v5.4.45)
[30.3MiB/14.15s]   - Upgrading symfony/translation-contracts (v2.5.2 => v2.5.4)
[30.3MiB/14.15s]   - Upgrading symfony/twig-bridge (v5.4.35 => v5.4.48)
[30.3MiB/14.16s]   - Upgrading symfony/twig-bundle (v5.4.35 => v5.4.45)
[30.3MiB/14.16s]   - Upgrading symfony/uid (v5.4.35 => v5.4.45)
[30.3MiB/14.16s]   - Upgrading symfony/var-dumper (v5.4.35 => v5.4.48)
[30.3MiB/14.16s]   - Upgrading symfony/var-exporter (v6.4.3 => v6.4.13)
[30.3MiB/14.16s]   - Upgrading symfony/web-profiler-bundle (v5.4.35 => v5.4.48)
[30.3MiB/14.16s]   - Upgrading symfony/yaml (v5.4.35 => v5.4.45)
[30.3MiB/14.16s]   - Upgrading terminal42/escargot (1.6.1 => 1.6.2)
[30.3MiB/14.16s]   - Upgrading terminal42/service-annotation-bundle (1.1.5 => 1.2.1)
[30.3MiB/14.16s]   - Upgrading twig/extra-bundle (v3.8.0 => v3.19.0)
[30.3MiB/14.16s]   - Upgrading twig/twig (v3.8.0 => v3.19.0)
[29.6MiB/14.17s] Writing lock file
[16.1MiB/14.20s] <warning>Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.</warning>
[16.4MiB/14.47s] No security vulnerability advisories found.
[16.9MiB/14.47s] Memory usage: 16.89MB (peak: 213.51MB), time: 14.48s.
[16.9MiB/14.48s] Finished Composer Cloud resolving.
# Job ID l6RKyh4tNGki9bx0Bu7aZGZxIq7pV49ztqiIOuELWMOYDjoVKc7cBZNCAp40sqz71XogkriE0chWobmoIEi817vJ1SH0R88KLLG9r5x61 completed in 12 seconds
# Memory usage: 16.89MB (peak: 213.51MB), time: 14.48s.
vendor/bin/contao-console contao:maintenance-mode enable
composer install
$ /usr/bin/php8.3 -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 /htdocs/PLAYGROUND/web/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
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
105 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> @php -ddisable_functions= vendor/bin/contao-setup
PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/PLAYGROUND/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/PLAYGROUND/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/PLAYGROUND/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /htdocs/PLAYGROUND/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
08:01:45 CRITICAL  [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir web --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/PLAYGROUND/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/PLAYGROUND/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/PLAYGROUND/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()
#2 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /htdocs/PLAYGROUND/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 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir web --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/PLAYGROUND/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n  Stack trace:\n  #0 /htdocs/PLAYGROUND/vendor/symfony/console/Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n  #1 /htdocs/PLAYGROUND/vendor/symfony/framework-bundle/Console/Application.php(40): Symfony\Component\Console\Application->__construct()\n  #2 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n  #3 /htdocs/PLAYGROUND/vendor/contao/manager-bundle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n  #4 {main}\n    thrown in /htdocs/PLAYGROUND/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 
  /htdocs/PLAYGROUND/vendor/contao/manager-bundle  
  /bin/contao-console contao:install-web-dir web --env=prod --no-ansi" comman  
  d: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Com  
  ponent\Console\SignalRegistry\pcntl_async_signals() in /htdocs/PLAYGROUND/
  vendor/symfony/console/SignalRegistry/SignalRegistry.php:21                                                                
  Stack trace:                                                                 
  #0 /htdocs/PLAYGROUND/vendor/symfony/console/  
  Application.php(98): Symfony\Component\Console\SignalRegistry\SignalRegistr  
  y->__construct()                                                             
  #1 /htdocs/PLAYGROUND/vendor/symfony/framewor  
  k-bundle/Console/Application.php(40): Symfony\Component\Console\Application  
  ->__construct()                                                              
  #2 /htdocs/PLAYGROUND/vendor/contao/manager-b  
  undle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle  
  \Console\Application->__construct()                                          
  #3 /htdocs/PLAYGROUND/vendor/contao/manager-b  
  undle/bin/contao-console(37): Contao\ManagerBundle\Console\ContaoApplicatio  
  n->__construct()                                                             
  #4 {main}                                                                    
    thrown in /htdocs/PLAYGROUND/vendor/symfony  
  /console/SignalRegistry/SignalRegistry.php on line 21                        
                                                                               
contao:setup
Script @php -ddisable_functions= 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

Ich interpretiere das so, dass der Vorschlag mit dem -ddisable_functions= nicht den gewünschten Effekt gehabt hat.
Trotzdem meldet der CM auch hier jetzt die Version 4.13.52 für Contao.

ZWEITENS habe ich eine Antwort von Goneo bekommen:
diese Funktionen dienen der Prozesssteuerung auf Systemebene und die Deaktivierung hat keinen Einfluss auf Ihre Webseite.
Auch aus Sicherheitsgründen werden diese Funktionen für die CLI nicht aktiviert.

Schade. Also doch Hoster wechseln? Eigentlich will ich das nicht (mehr), denn ... siehe oben, #60. Hm, schwierig.

Kann man nicht "irgendwie" erreichen, dass das mit der "lokalen" php.ini was ich oben in post #55 beschriben habe auch für den CM funktioniert? Beispielsweise, dass der CM schaut, ob es eine lokale php.ini gibt und diese dann verwendet?

[Spooky]

Beispielsweise, dass der CM schaut, ob es eine lokale php.ini gibt und diese dann verwendet?

Das tut er bereits. Die php.ini muss sich dazu afaik im contao-manager/ Verzeichnis der Installation befinden. Es kann aber sein, dass das keine Auswirkung auf contao-setup hat.

[zoglo]

Schade. Also doch Hoster wechseln?

Ich bin 2021 mit einem Kunden weggerannt, da Goneo vieles nicht erlaubt und vieles nicht möglich ist.
Man sagt ja bekantlich, dass diese altbackenen UIs bei Hostern immer das beste Zeichen für einen guten Hoster sind, bei Goneo ist es aber altbacken, weil dort auch seit Jahren nichts mehr geupdated wird .

Ich würde vorschlagen, dass du das Update und den Umzug nun in die Hände deiner Nachfolgerin legst.

[purzel]

Das tut er bereits. Die php.ini muss sich dazu afaik im contao-manager/ Verzeichnis der Installation befinden. Es kann aber sein, dass das keine Auswirkung auf contao-setup hat.

Ich hab's mal eben ausprobiert: leider hast Du anscheinend Recht: composer update ... und ... maintenance-mode enable laufen mit grünem Haken, composer install und ... maintenance-mode disable bekommen wieder das rote Kreuzchen; das Fenster mit den Fehlern scheint gleich zu sein - ich verzichte deswegen auf erneutes Posten Desselben.

Seltsam finde ich - wie bei dem Versuch mit der "live"-Instanz, dass TROTZ DES FEHLERS der CM nun die aktualisierte Version (4.13.52) anstatt der alten 4.13.36 anzeigt. Was stimmt denn nun bzw. ist jetzt die Installation (so halb) kaputt??? Ich hatte ja gestern, nachdem laut DRY RUN vermeintlich alles gut war mutig auf "Änderungen anwenden" geklickt.

Ich würde vorschlagen, dass du das Update und den Umzug nun in die Hände deiner Nachfolgerin legst.

Das wäre ein bisschen gemein glaub' ich - sie ist noch einigermaßen Anfängerin in Sachen Web, lernt gerade Contao (mit Riesenschritten und gutem Erfolg) - aber so "Serverkram", PHP & Co... Ich frag' sie.

Außerdem - welchen Hoster nimmt man? Die beiden Sachen die ich mir dazu angesehen habe (Wiki-Artikel http://de.contaowiki.org/Composer/Hosting und im Forum "Webhoster und Contao - Hostervergleich" sind etwas ... äh ... "angealtert". Ich denke nicht, dass es nennenswert teurer werden darf... (z.Zt. 5,99 €/Monat)

[Spooky]

Seltsam finde ich - wie bei dem Versuch mit der "live"-Instanz, dass TROTZ DES FEHLERS der CM nun die aktualisierte Version (4.13.52) anstatt der alten 4.13.36 anzeigt. Was stimmt denn nun

Das Update der Pakete schlägt ja nicht fehl. Nur das automatisch ausgeführte post-update-cmd.

[purzel]

Das Update der Pakete schlägt ja nicht fehl. Nur das automatisch ausgeführte post-update-cmd.

Und das bedeutet für mich... was genau? (Sorry für die vielleicht doofe Frage)

[Spooky]

Wenn du eine Paketaktualisierung durchführst, werden zuerst die Pakete an sich aktualisiert, dann werden die Contao Manager Plugins erzeugt, dann werden die PHP Autoload Informationen von Composer erzeugt - und dann führt Composer die Scripts aus, die in post-update-cmd drin stehen.

Bei der Contao Managed Edition steht dort vendor/bin/contao-setup - und contao-setup führt diverse Commands aus, die für den Betrieb bzw. nach einem Update wichtig sind. Das sind folgende Kommands:

1. skeleton:install
2. assets:install
3. contao:install
4. contao:symlinks
5. cache:clear (dev)
6. cache:clear (prod)
7. cache:warmup (prod)

Das würde aktuell bei dir dann fehlen.

[mlweb]

Außerdem - welchen Hoster nimmt man? ...Ich denke nicht, dass es nennenswert teurer werden darf... (z.Zt. 5,99 €/Monat)

Mein Favorit für alle Installationen ohne spezielle Ansprüche ist nach wie vor All-Inkl. Paket Premium https://all-inkl.com/
Alles darunter lehne ich ab, weil da kein ssh-Zugang verfügbar ist.
Billiger klappt es wahrscheinlich bei Netcup. Die Oberfläche ist nicht so angestaubt, wie bei All-Inkl. Dafür war sie für meinen Geschmack immer etwas unübersichtlich und auch Netcup soll nachgelassen haben. Ich habe derzeit dort keinen Kunden.

Aber billig kann eben auch teuer sein, weil der Aufwand für Installation und Pflege höher wird.

Kleiner Nachtrag noch: All-Inkl. hat auch noch einen Pluspunkt bei den Mail-Accounts. Man kann den Inhalt von Imap-Konten zu All-Inkl. umziehen. Ist zwar trotzdem Aufwand, aber deutlich weniger, als wenn man externe Tools nutzen muss. Da ich mit den Mails meiner Kunden in der Regel schon aus Datenschutzgründen nichts zu tun haben möchte, habe ich in der Vergangenheit die Kunden gebeten, den Umzug selbst durchzuführen (natürlich mit Unterstützungsangebot). Die meisten Kunden haben es ohne Rückfragen selbst durchführen können.

[tab]

Bei netcup könnte ich ein fast neuwertiges Webhosting 2000 Plus abgeben. Das "Plus" bedeutet im Wesentlichen doppelt soviel Inklusivdomains (6 de), externe Domains (6), Web- und Mailspace wie das "normale" Webhosting 2000. Eine Inklusivdomain ist aber schon von mir verbraucht, dafür kostet es aber auch nur 2,17€ / Monat.

Netcup hat aber auch immer mal wieder Aktionsangebote, wo man auch ein Webhosting 4000 bestimmt für deutlich weniger als 5,99/Monat abstauben kann (letztes Aktionsangebot Ende Januar: 3,76€/Monat, allerspätestens zu Ostern wird es sicher wieder ein vergleichbares Angebot geben). Die Aktionspreise gelten da im Unterschied zu manch anderen Hostern dauerhaft, nicht nur ein paar Monate oder ein Jahr.

Ich kenne eure Vereinswebsite natürlich nicht, habe aber wenig Zweifel, dass die da (im Webhosting 2000 Plus, im Webhosting 4000 sowieso) problemlos laufen könnte. Ich hatte da auch schon mal eine Nextcloud am laufen und diverse eigene Contao-Websites. Das Schnäppchen würde ich zwar gern behalten, habe aber derzeit immer noch deutliche Überkapazitäten. Für einen Verein (mit einem hoffentlich positiven Zweck) gebe ich es also ggf auch ab. Wenn es nicht oder kaum genutzt wird, bringt mir auch das beste Schnäppchen nichts.
Ansonsten werde ich das Webhosting wohl ab Anfang April zum Transfer anbieten für andere Bestandskunden. Denke nicht, dass es länger als einen Tag dauern wird, bis es weg ist. Selbst das normale Webhosting 2000 liegt in letzter Zeit auch bei den Aktionsangeboten preislich höher.

@mlweb hat aber zumindest teilweise Recht. Netcup ist letztens aus meiner Außensicht etwas zu schnell gewachsen, die Support-Reaktionszeiten waren spätestens seit der Black Week teilweise indiskutabel. Aber man scheint daran zu arbeiten, ebenso am anderen Schwachpunkt, den DNS-Servern, da nehme ich gerade an einem Betatest teil, es wird also zumindest definitiv dran gearbeitet. Auch an der notwendigen Aufstockung des Personals. Wäre schön, wenn das nach Jahren endlich besser würde. Ok, solange man DNSSEC nicht aktiviert für die Domain klappt es auch bisher bei mir durchaus sehr passabel. Andere haben aber auch schon anderes berichtet.

Falls netcup für euch potentiell interessant wäre, würde ich auch das Update eurer Website im Webhosting 2000 Plus mal als Versuchsballon unter einer Subdomain von mir durchzuführen versuchen, sofern ihr mir die dazu notwendigen Daten (wie für einen Umzug eben) zur Verfügung stellt. Dann sieht man auch gleich, ob und wie das Update läuft und wie die Website danach läuft. Alles natürlich unverbindlich und kostenfrei, völlig unabhängig von einer eventuellen, späteren Übernahme des Webhostingpakets. Wenn ihr euch dann doch für AllInkl entscheidet oder für Hostingwerk(!), meinen Segen habt ihr dazu allemal und ich gehe auch davon aus, dass es auch dort keine unlösbaren Probleme geben wird.

[purzel]

Herzlichen Dank Euch beiden.

@spooky: ich muss mir nochmal die Seite mit dem "Update via Console" 'raussuchen und da probieren, ob die von Dir genannten Punkte zum Erfolg führen. Möglicherweise kann ich ja da irgendwas mit `php -c pfad_zur_ini ...` erreichen. Im Moment aber habe ich dazu zu wenig Ruhe.

@mlweb: auch wenn All-Inkl sehr gut aussieht - es _könnte_ dem Verein/Vorstand zu teuer sein, kann ich aber schlecht abschätzen. Beim bloßen Überfliegen der specs des kleinsten (!) Hosting Pakets von Netcup bin ich angenehm überrascht, selbst das könnte gerade so reichen bei nur gut einem Drittel der Kosten. Da würde man natürlich ein größeres Paket nehmen weil das Kleine nur _eine_ DB hat. Gut finde ich bei denen auch die "Zufriedenheitsgarantie". Auch das muss ich mir nochmal in Ruhe anschauen.

Hat jemand einen leicht praktikablen Vorschlag, wie ich das potentielle neue Hosting testen kann OHNE schon gleich die Domain umzuziehen? Mein letzter Server-/Providerwechsel (damals MIT Domainumzug) ist über 15 Jahre her...
Trotzdem oder gerade deswegen graut es mir natürlich vor dem Aufwand der Migration, besonders die ganzen Mail-Konten und -Weiterleitungen sowie die Bürokratie des Domain-Umzugs (und ZWEI Provider (Web + Mail) dürfte ausscheiden weil das ja mal eben (fast) doppelte Kosten werden können)

[mlweb]

Bei All-Inkl. bekommst Du eine vorläufige Domain in der Regel mit unaussprechlicher Hyroglyphen-Domain. Vertrag ist ja bei denen monatsweise kündbar, ob sie auch Testaccounts anbieten, da bin ich nicht auf dem Laufenden. Einfach fragen. Die Antworten nach meiner Erfahrung zügig.
Bei Netcup hast Du ja das Angebot zum Testen von @tab. Ob die auch offiziell Testaccounts haben, weiß ich nicht. Früher war das mal so, aber inzwischen ...?

[mlweb]

... besonders die ganzen Mail-Konten und -Weiterleitungen sowie die Bürokratie des Domain-Umzugs

Die Bürokratie eines Domainumzuges ist eigentlich wirklich überschaubar.
Bei den Mailaccounts - von wieviel Mailaccounts reden wir denn?
Der weit aus größere Aufwand liegt nach meiner Erfahrung bei den Kunden, die Ihre Mailprogramme neu konfigurieren müssen und da häufig allein nicht in der Lage zu sind oder eben auch Kunden die Exchange-Server nutzen und keinen dauerhaften Betreuer für die Systeme haben. Ich vermute aber nicht, dass Letzteres beim Verein der Fall ist.

[tab]

Typischerweise hat ja nicht jedes Vereinsmitglied einen Vereinsaccount, sondern nur die Funktonäre. Jeder von denen wird irgendwann mal seinen Mail-Account eibgerichtet haben. Oder kommt da der Betreuer vom Verein bei jedem zuhause vorbei um die Mail einzurichten auf dem Desktop, dem Tablet und dem Android oder iPhone? Dann trete ich da auch bei . Was die Funktionäre einmal geschafft haben, sollte doch auch zweimal klappen.

Edit: Trotzdem bin ich da bei euch, E-Mail ist der wesentlich aufwändigere Teil des Umzugs. Die Vereins-Website sollte eigentlich nicht mehr als eine Stunde Arbeitsaufwand sein, inklusive Update. Klar, man wird wegen DNS eventuell Wartezeiten zwischendrin haben und es wird somit eventuell länger dauern.

[mlweb]

Bei einem gemeinnützigen Verein wäre ich auch bereit den Umzug zu All-Inkl. kostenfrei zu unterstützen. Kannst Dich bei Interesse des Vereins per PN bei mir melden.

[Spooky]

welchen Hoster nimmt man?

Einen perfekten (Shared) Hoster kenne ich leider nicht

[mlweb]

Was die Funktionäre einmal geschafft haben, sollte doch auch zweimal klappen.

Witzbold. Was meinst Du was ich diesbezüglich schon bei Kunden erlebt habe - das kann man sich gar nicht ausdenken.

[tab]

Also da muss man nur klar und deutlich genug kommunizieren. Natürlich würde jeder am liebsten keinen eigenen Finger krumm machen, aber darauf darf man sich eben nicht einlassen. Jeder von denen hat wahrscheinlich zig eigene E-Mail-Adressen, die hat ihnen auch niemand eingerichtet. Mit einem entsprechenden Kostenvoranschlag ist das bei Vereinen ganz schnell vom Tisch.

[purzel]

Vielen Dank Euch - muss mir das alles nochmal in Ruhe durchlesen - doch leider wird die Zeit knapp.

Bei den Mail-Accounts hatte ich Falsches in Erinnerung; echte Accounts sind nur wenige - das Meiste sind "nur" Weiterleitungen (die z.T. aber "gruppiert": mehrere Leute, die eine Mail an xyz@tld.de bekommen), also zeitraubende Klickerei mit copy&paste.

Den Umzug der Daten (Contao, PDFs & Co, Datenbank(en) sehe ich als sehr überschaubaren Teil.

Ich werde am WE mal mit Vorstand und meiner Nachfolgerin reden; wie gesagt, offiziell bin ich eigentlich 'raus.

Shit, so spät... Bis vermutlich morgen!

[zoglo]

Vielen Dank Euch - muss mir das alles nochmal in Ruhe durchlesen - doch leider wird die Zeit knapp.

Bei den Mail-Accounts hatte ich Falsches in Erinnerung; echte Accounts sind nur wenige - das Meiste sind "nur" Weiterleitungen (die z.T. aber "gruppiert": mehrere Leute, die eine Mail an xyz@tld.de bekommen), also zeitraubende Klickerei mit copy&paste.

Den Umzug der Daten (Contao, PDFs & Co, Datenbank(en) sehe ich als sehr überschaubaren Teil.

Ich werde am WE mal mit Vorstand und meiner Nachfolgerin reden; wie gesagt, offiziell bin ich eigentlich 'raus.

Shit, so spät... Bis vermutlich morgen!

Ihr könnt die Mails doch weiterhin bei Goneo hosten und erstmal nur die Website umziehen und entsprechend den A-Record umstellen. Alles bei verschiedenen Hostern ist ja erstmal nicht schlecht.

Platz 1 für E-Mail-Hosting beim Hosttest.de
Goneo: With every Click gotta redefine.
Goneo take me high, with your tools I'll reach the sky
https://www.youtube.com/watch?v=YBaAG8FE8E0