Goneo: Contao-Manager kaputt?

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)

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 ...?

Zitat:

---

Zitat von purzel

... 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.

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 :D. 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.

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.

Zitat:

---

Zitat von purzel

welchen Hoster nimmt man?

---

Einen perfekten (Shared) Hoster kenne ich leider nicht :)

Zitat:

---

Zitat von tab

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.

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.

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!

Zitat:

---

Zitat von 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!

---

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

Also wenn es möglich wäre, die Mail-Vereinskonten ohne großen Aufwand innerhalb von Goneo in ein entsprechend deutlich günstigeres Paket mit weniger oder gar keinem Webhosting zu transferieren, z.B. E-Mail Plus oder Premium, dann wäre das sicher eine gute Lösung. Immerhin wäre man dann sicher, dass die derzeit eingerichteten Konten und Weiterleitungen auch weiterhin zuverlässig funktionieren. Dann blieben noch ca 4,50 bis 5€ für das Webhosting, wenn man die Gesamtkosten nicht erhöhen will. das sollte durchaus machbar sein. Zumindest bei netcup, eventuell aber auch anderswo. Ich kenne auch nicht alle Webhoster aus eigener Contao-Erfahrung ;).

Zitat:

---

Zitat von zoglo

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.

---

Zitat:

---

Zitat von tab

Also wenn es möglich wäre, die Mail-Vereinskonten ohne großen Aufwand innerhalb von Goneo in ein entsprechend deutlich günstigeres Paket mit weniger oder gar keinem Webhosting zu transferieren, z.B. E-Mail Plus oder Premium, dann wäre das sicher eine gute Lösung. Immerhin wäre man dann sicher, dass die derzeit eingerichteten Konten und Weiterleitungen auch weiterhin zuverlässig funktionieren. Dann blieben noch ca 4,50 bis 5€ für das Webhosting, wenn man die Gesamtkosten nicht erhöhen will. das sollte durchaus machbar sein. Zumindest bei netcup, eventuell aber auch anderswo. Ich kenne auch nicht alle Webhoster aus eigener Contao-Erfahrung ;).

---

Grundsätzlich wäre das sicherlich ein gangbarer Weg - zumal auch an anderer Stelle schon erwähnt wurde/wird, dass es nicht die schlechteste Idee ist Mail und Web bei unterschiedlichen Providern zu haben. Ob ICH das praktikabel fände mag ich so "aus dem Bauch heraus" nicht beantworten, das zählt ja aber nicht mehr. Ob meine Nachfolgerin das gut fände will (erstmal noch) nicht erfragen. Am Wochenende ist ein Gespräch mit dem Vorstand geplant.

Doch nun erst noch einmal zurück zum Thema: da ich immer noch nicht ganz davon ab bin, es DOCH "irgendwie" hinzukriegen... denn weiter oben schrieb spooky

Zitat:

---

Zitat von Spooky

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

---

und das habe ich zum Anlass genommen, den "fehlgeschlagenen Teil" nochmal über die Console zu versuchen. Da der Vorschlag, -ddisable_functions= in die composer.json einzufügen anscheinend nicht ausreicht kam ich auf die Idee, -c contao-manager/php.ini in die composer.json einzubauen. Schließlich hatte ich beobachtet, dass das Mitgeben einer php.ini durchaus funktionieren kann und der CM die Parameter aus der composer.json in die erzeugte Kommandozeile einbaut, z.B.

Code:

---

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

---

Anschließend gab ich auf der Console ein vendor/bin/contao-console contao:maintenance-mode enable - das lieferte eine WARNING [php] Warning: Undefined array key "urlKeywords" ["exception" => ErrorException { …}] und im Anschluss [OK] Maintenance mode enabled . So weit so gut.
Im Anschluss gab ich $ composer install - das wollte (wie schon vor einigen Wochen) drei Plugins "genehmigt" haben und lief dann auf ein kleines Problem, was ich auch schon kannte: lcobucci/clock und lcobucci/jwt verlangten nach einer ÄLTEREN Version von PHP. und ich möge doch bitte 'composer update' machen. OK, soll er haben...
DAS dann aufgerufen jammerte zwar ein bisschen rum (Cannot create cache directory ... und etwas später noch Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.) lief aber mit mehreren grünen [OK]-Meldungen durch, inkl. Cache cleared und Cache warmed Erfolgsmeldungen.
Ein erneutes $ composer install lieferte erfreulicherweise auch einen Haufen grüner OK-Meldungen:
[OK] All assets were successfully installed.
[OK] Cache for the "prod" environment (debug=false) was successfully cleared.
[OK] Cache for the "dev" environment (debug=true) was successfully cleared.
[OK] Cache for the "prod" environment (debug=false) was successfully warmed.
Und, das ist jetzt das was ich oben gehofft hatte, mein in die composer.json eingebauter Parameter scheint funktioniert zu haben; sowohl bei 'composer update' als auch bei 'composer install' wurde in die erzeugte Kommandozeile der -c Parameter eingebaut:
> @php -c contao-manager/php.ini -ddisable_functions= vendor/bin/contao-setup
(vermutlich ist -ddisable_functions= an der Stelle gar nicht mehr nötig, weil genau das ja in der verwendeten php.ini drin steht)
Auch ein vorsichtshalber gegebenes $ vendor/bin/contao-console contao:migrate bescherte eine grüne OK Meldung: [OK] All migrations completed.

Muss ich jetzt noch irgendetwas Weiteres in der Console "manuell" machen was sonst der CM tun würde? Oder ist er jetzt fertig?

(und das fast schon obligatorische DICKE SORRY für schon wieder so viel Text :)

Wenn composer install/update auf der Konsole normal durchläuft, musst du nichts weiter machen - außer natürlich die Datenbank aktualisieren (contao:migrate).

Um der Warning auf den Grund zu gehen kannst du

Code:

---

vendor/bin/contao-console contao:maintenance-mode enable -v

---

ausführen, um eine Stack Trace zu bekommen.

Zitat:

---

Zitat von Spooky

Wenn composer install/update auf der Konsole normal durchläuft, musst du nichts weiter machen - außer natürlich die Datenbank aktualisieren (contao:migrate).

---

Sehr erefreulich - danke für die schnelle Antwort. Das mit der DB hatte ich "vorsichtshalber" auch gemacht.

Zitat:

---

Zitat von Spooky

Um der Warning auf den Grund zu gehen kannst du

Code:

---

vendor/bin/contao-console contao:maintenance-mode enable -v

---

ausführen, um eine Stack Trace zu bekommen.

---

Leider kommt nicht mehr als vorher auch schon:
$ vendor/bin/contao-console contao:maintenance-mode enable -v
11:10:08 WARNING [php] Warning: Undefined array key "urlKeywords" ["exception" => ErrorException { …}]
11:10:08 WARNING [php] Warning: Undefined array key "urlKeywords" ["exception" => ErrorException { …}]
(Oder schreibt er das Stack Trace in irgendeine Datei?)
Beim ...disable kommt die Warnung übrigens nicht.

Hm, auch nicht mit

Code:

---

vendor/bin/contao-console contao:maintenance-mode enable -vvv

---

?

Wow! 67 kByte Sermon :D
Die poste ich mal nicht sondern versuche (nachher, die Zeit wird gerade wieder knapp) einen Extrakt.

Nimm einfach einen PrivateBin Service.

Ich denke das wird nicht nötig sein. Nachdem ich in dem erzeugten file nach WARNING gesucht habe gab es nur zwei Stellen, beide scheinen das Selbe zu meinen:

11:23:37 WARNING [php] Warning: Undefined array key "urlKeywords"
[
"exception" => ErrorException {
#message: "Warning: Undefined array key "urlKeywords""
#code: 0
#file: "/htdocs/PLAYGROUND/var/cache/prod/contao/config/config.php"
#line: 221
#severity: E_WARNING
trace: {
/htdocs/PLAYGROUND/var/cache/prod/contao/config/config.php:221 {
include^
› */
› $GLOBALS['TL_CONFIG']['urlKeywords'] .= (\strlen(\trim($GLOBALS['TL_CONFIG']['urlKeywords'])) ? ',' : '') . 'ical';
› $GLOBALS['TL_HOOKS']['removeOldFeeds'][] = array('CalendarExport', 'removeOldSubscriptions');
}

Und das wiederum betrifft nach meinem "Ausgrabungen" (fgrep & Co) die Erweiterung, die ich ohnehin für das Upgrade auf 5.3 eliminieren bzw. durch etwas Neues ersetzen muss: craffft/contao-calendar-ical-bundle

Möchtest Du den ganzen Salat trotzdem noch sehen?

https://github.com/cgoIT/contao-calendar-ical-bundle <--

Cool, danke. Ich hatte schon mal quick'n'dirty via CM nach einer Alternative gesucht - immerhin gibt es ein paar.
Meine andere benötigte Erweiterung srhinow/tinymce-plugins gib's ja offenbar auch für 5+ :cool:
Mehr Erweiterungen habe ich nicht eingebunden. Dann könnt eich ja doch beim nächsten Mal "viel Zeit" ein Upgrade versuchen...

Hallo und guten Morgen allerseits!

Am Wochenende hatte ich zum Einen ein sehr positives Gespräch mit dem Vorstand und zum Zweiten erneut einen Haufen Zeit damit verbra... verschwendet, das Ganze doch bei Goneo lassen zu können.
In der composer.json hatte/habe ich zwar stehen

Code:

---

...
    "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"
        ]
    },
...

---

(was zum Teil funktionierte) und sogar sowas
$ php -c contao-manager/php.ini /usr/bin/composer ...
versucht. Das hatte zwar den positiven Effekt, dass ich fehlerfrei die beiden veralteten Erweiterungen deinstallieren konnte - aber das Upgrade auf 5.3.x lief dann trotzdem gegen die Wand, wohl weil eines der Scripte wieder Console-PHP ausführt OHNE die "lokale" php.ini zu benutzen. Leider habe ich die ganze Console Ausgabe gerade nicht zur Hand (und ehrlich gesagt an DER Stelle keine Lust mehr). Andere hätten vermutlich schon viel eher aufgegeben und den Provider gewechselt...

Wie dem auch sei, so viele "Klimmzüge" und dann klappt's doch nicht - ich werde nun also zunächst versuchen, eine Art "Probe-Account" bei all-inkl und/oder netcup zu bekommen.

Ich wünsche allen einen guten Start in die Woche!

Gruß
purzel

Bist du dir denn überhaupt sicher, dass das Problem beim Update auf Contao 5 überhaupt etwas mit Goneo zu tun hat?

Ziemlich - wegen der für CLI-PHP aktiven Einstellung
disable_function=pcntl_alarm,pcntl_fork,pcntl_wait pid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pc ntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstat us,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcnt l_signal_get_handler,pcntl_signal_dispatch,pcntl_g et_last_error,pcntl_strerror,pcntl_sigprocmask,pcn tl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl _getpriority,pcntl_setpriority,pcntl_async_signals ,pcntl_unshare
Für Web-PHP ist das NICHT der Fall; siehe dazu auch die Tests und Diskussion ab post #43 ff. Und meine letzten Tests haben ja (teilweise) bewiesen, dass wenn ich dem CLI-PHP eine php.ini mit
disable_function=
auf den Weg gebe mehr funktioniert; leider wie gesagt nicht alles zum Upgrade Nötige. Schade dass ich die gestrige Consolen-Ausgabe gerade nicht greifbar habe.

Klarheit könnte der Probe-Account bei all-Inkl liefern, dessen "Beantragung" ist ja super einfach. Damit warte ich aber noch ein paar Tage, damit das Wochenende "mittendrin" ist im Testzeitraum von einer Woche.

Du wirst das ganze nochmal durchführen und die Konsolenausgabe posten müssen.

An die von gestern komme ich wie gesagt gerade nicht 'dran; die hatte ich aber immerhin als textfile gespeichert.
Wenn ich das Ganze nochmal mache... mir ist gerade aufgefallen, dass ich einen kleinen Unterschied habe in meiner composer.json gegenüber https://docs.contao.org/manual/de/mi...o-4-13-auf-5-x nämlich sind dort für manche Versions-Anforderungen ein ^ aufgeführt und für manche nicht. In meiner (alten) composer.json gibt es gar keine ^ ergo habe ich die Neue auch keine getippt. Wozu ist das ^ gut? So richtig verstehe ich die auf der verlinkten Seite stehende Notiz nämlich nicht :( Ich möchte gern 5.3 weil das eine LTS ist.
EDIT: nach mehrmaligem Lesen der Notiz und auch der darin verlinkten Composer Dokumentation sollte ich also wahrscheinlich die ^ überall weglassen. Richtig?

Zitat:

---

Zitat von purzel

Wozu ist das ^ gut?

---

Siehe hier.

In der Default composer.json der contao/managed-edition haben die Contao Bundles by default ^ - mit Ausnahme des contao/manager-bundle. Dadurch musst du nur das Version Requirement des contao/manager-bundles anpassen, um auf eine höhere Contao Version zu aktualisieren.

Wenn du eine Contao Installation über den Contao Manager aufsetzt, ist das dort anders. Der Contao Manager setzt dann bei allen Contao Paketen bspw. 5.3.*, nicht nur nur beim contao/manager-bundle.

Mist, Überschneidung: mein EDIT und Dein Posting.

Ich will ja keine NEUE Conato Instanz aufsetzen sondern eine bestehende 4.13 auf 5.3 "anheben". Über den Manager wäre natürlich sympathisch. Nach meinem Verständnis mache ich also KEINE ^ rein:

Code:

---

  "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.*"
    },

---

Der CM zeigt im orangenen Button dann auch "5.3.*" und das Zahnrad an.
Testlauf klappt übrigens, Änderungen übernehmen jedoch wie inzwischen gewohnt nicht. composer update ... klappt noch mit grünem Haken, maintenance sowieso aber composer install kackt wieder ab:

Code:

---

$ /usr/bin/php8.3 -q -c /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 /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
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
112 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> @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 /htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/TEST53/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()
#2 /htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
09:19:51 CRITICAL  [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console skeleton:install public --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/TEST53/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()
#2 /htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /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 /htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console skeleton:install public --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n  Stack trace:\n  #0 /htdocs/TEST53/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n  #1 /htdocs/TEST53/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()\n  #2 /htdocs/TEST53/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n  #3 /htdocs/TEST53/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n  #4 {main}\n    thrown in /htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21\n  """]
In ContaoSetupCommand.php line 142:
                                                                             
  An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 
  /htdocs/TEST53/vendor/contao/manager-bundle/bin 
  /contao-console skeleton:install 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/038/826/133 
  535/htdocs/TEST53/vendor/symfony/console/SignalRegistry/SignalRegistry.php: 
  21                                                                         
  Stack trace:                                                               
  #0 /htdocs/TEST53/vendor/symfony/console/Appl 
  ication.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry-> 
  __construct()                                                               
  #1 /htdocs/TEST53/vendor/symfony/framework-bu 
  ndle/Console/Application.php(42): Symfony\Component\Console\Application->__ 
  construct()                                                                 
  #2 /htdocs/TEST53/vendor/contao/manager-bundl 
  e/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Con 
  sole\Application->__construct()                                             
  #3 /htdocs/TEST53/vendor/contao/manager-bundl 
  e/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->_ 
  _construct()                                                               
  #4 {main}                                                                   
    thrown in /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

---

Im Grunde wiederholt sich jetzt alles von letzter Woche, daher vermute ich, dass ich an der Stelle nicht mehr weiter komme. Leider bekomme ich nicht mehr nachvollzogen, was ich gestern anders gemacht habe.

Zitat:

---

Zitat von purzel

Nach meinem Verständnis mache ich also KEINE ^ rein:

---

Doch, du könntest folgendes machen: https://github.com/contao/managed-ed...er.json#L6-L15

Die Pakete, die du nicht brauchst, natürlich entfernen.

Zitat:

---

Zitat von Spooky

Doch, du könntest folgendes machen: https://github.com/contao/managed-ed...er.json#L6-L15

---

Das heißt, DOCH ÜBERALL das caret ^ einbauen? Würde dann nicht irgendwann z.B. 5.4 installiert werden auch wenn ich ^5.3.* eintrage? Ich will nur LTS Versionen. Offenbar habe ich das doch noch nicht verstanden :o

Zitat:

---

Zitat von Spooky

Die Pakete, die du nicht brauchst, natürlich entfernen.

---

Auch core Pakete? FAQ benutze ich nicht (bisher jedenfalls, stört aber auch nicht) und Nachrichten steht momentan auf dem Abstellgleis - war mal, könnte aber vielleicht wiederkommen. Alles Andere wird benutzt.

Zitat:

---

Zitat von purzel

Das heißt, DOCH ÜBERALL das caret ^ einbauen? Würde dann nicht irgendwann z.B. 5.4 installiert werden

---

Kommt darauf an, was genau du nun eingetragen hast. Wenn du es wie beschrieben gemacht hast, dann wird dir nur Contao 5.3 installiert - weil eben das contao/manager-bundle auf 5.3.* steht.

Zitat:

---

Zitat von purzel

Auch core Pakete? FAQ benutze ich nicht (bisher jedenfalls, stört aber auch nicht) und Nachrichten steht momentan auf dem Abstellgleis - war mal, könnte aber vielleicht wiederkommen. Alles Andere wird benutzt.

---

Alles, was du nicht benutzt, kannst du entfernen.

Zitat:

---

Zitat von Spooky

Kommt darauf an, was genau du nun eingetragen hast. Wenn du es wie beschrieben gemacht hast, dann wird dir nur Contao 5.3 installiert - weil eben das contao/manager-bundle auf 5.3.* steht.

---

Stimmt, beim manager-bundle ist kein caret. Dann werde ich in den nächsten Tagen im Probe-Account bei All-Inkl mal genau das versuchen. Im derzeitigen Goneo Hosting trete ich ja inzwischen auf der Stelle. Ob ich das faq-bundle raus lösche kann ich mir ja noch überlegen. Nachrichten lasse ich vorsichtshalber drin, vielleicht muss das irgendwann reaktiviert werden.

Gestatte mir bitte noch - falls das mit einem Satz beantwortbar ist - eine kleine off topic Frage: warum wurde in der 5.x der CSS Editor eliminiert? Ich fand den ganz praktisch. (Gut, dass ich das noch gesehen habe)

Zitat:

---

Zitat von purzel

Gestatte mir bitte noch - falls das mit einem Satz beantwortbar ist - eine kleine off topic Frage: warum wurde in der 5.x der CSS Editor eliminiert? Ich fand den ganz praktisch. (Gut, dass ich das noch gesehen habe)

---

Hat sich erledigt. Ich habe https://community.contao.org/de/show...NTAO-5-und-CSS gefunden.

Hallo Spezialisten!

Inzwischen glaube ich, das derzeitige Hosting-Paket bei Goneo ist wirklich ungeeignet für Contao 5.3.x (wobei die Probleme ja schon beim Update von 4.13.36 auf 4.13.52 erkennbar waren)

Ich habe versucht, eine "blanko" Installation Contao 5.3 Managed Edition zu machen, habe mich dazu an diese Anleitung gehalten. Selbst das geht schief, im Grunde kennen wir die Fehler(meldungen):

Code:

---

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/NEW/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
112 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/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/NEW/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/NEW/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()
#2 /htdocs/NEW/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/NEW/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /htdocs/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21
13:14:37 CRITICAL  [console] An error occurred while using the console. Message: "An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 /htdocs/NEW/vendor/contao/manager-bundle/bin/contao-console skeleton:install public --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21
Stack trace:
#0 /htdocs/NEW/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()
#1 /htdocs/NEW/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()
#2 /htdocs/NEW/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()
#3 /htdocs/NEW/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()
#4 {main}
  thrown in /htdocs/NEW/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/NEW/vendor/contao/manager-bundle/bin/contao-console skeleton:install public --env=prod --no-ansi" command: PHP Fatal error:  Uncaught Error: Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals() in /htdocs/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21\n  Stack trace:\n  #0 /htdocs/NEW/vendor/symfony/console/Application.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__construct()\n  #1 /htdocs/NEW/vendor/symfony/framework-bundle/Console/Application.php(42): Symfony\Component\Console\Application->__construct()\n  #2 /htdocs/NEW/vendor/contao/manager-bundle/src/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Console\Application->__construct()\n  #3 /htdocs/NEW/vendor/contao/manager-bundle/bin/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__construct()\n  #4 {main}\n    thrown in /htdocs/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php on line 21\n  """]
In ContaoSetupCommand.php line 142:
                                                                             
  An error occurred while executing the "/usr/bin/php8.3 -dmemory_limit=-1 
  /htdocs/NEW/vendor/contao/manager-bundle/bin/co 
  ntao-console skeleton:install public --env=prod --no-ansi" command: PHP Fat 
  al error:  Uncaught Error: Call to undefined function Symfony\Component\Con 
  sole\SignalRegistry\pcntl_async_signals() in 
  /htdocs/NEW/vendor/symfony/console/SignalRegistry/SignalRegistry.php:21     
  Stack trace:                                                               
  #0 /htdocs/NEW/vendor/symfony/console/Applica 
  tion.php(101): Symfony\Component\Console\SignalRegistry\SignalRegistry->__c 
  onstruct()                                                                 
  #1 /htdocs/NEW/vendor/symfony/framework-bundl 
  e/Console/Application.php(42): Symfony\Component\Console\Application->__con 
  struct()                                                                   
  #2 /htdocs/NEW/vendor/contao/manager-bundle/s 
  rc/Console/ContaoApplication.php(26): Symfony\Bundle\FrameworkBundle\Consol 
  e\Application->__construct()                                               
  #3 /htdocs/NEW/vendor/contao/manager-bundle/b 
  in/contao-console(39): Contao\ManagerBundle\Console\ContaoApplication->__co 
  nstruct()                                                                   
  #4 {main}                                                                   
    thrown in /htdocs/NEW/vendor/symfony/consol 
  e/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

---

Nachdem ich dann den CM erneut gestartet hatte wollte er die DB Verbindung einrichten was ich auch gemacht habe. Danach noch die ganzen Tabellen anlegen und alles sah vermeintlich gut aus (konnte es ja aber nicht sein...). Erwartungsgemäß liefert das Aufrufen der neuen Installation und auch deren Backend nur Fehlermeldungen (FE 403, BE 404). Für mich ist das eigentlich "Beweis" genug, dass das Hosting nicht für Contao 5 geeignet ist - was ja schon an anderen Stellen vermutet wurde.

Vielleicht sollte man in die Systemvoraussetzungen mit aufnehmen, dass in der php.ini für's CLI (!) bestimmte (nur pcntl_async_signals oder mehr oder gar alle?) Funktionen NICHT unter disable_funktions aufgelistet sein dürfen? (Weil der "erzeugte" Codeteil "-ddisable_functions" (zweite Zeile oben im Code-Block) anscheinend nicht immer (?) funktioniert.

Tadaa!

"Mühsam ernährt sich das Eichhörnchen" :)

in der Test-Installation "nackte 5.3" habe ich den scripts-Teil der composer.json wieder um das "halbwegs bewährte" -c php.ini ergänzt:

Code:

---

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

---

und eine php.ini mit dem einzigen Inhalt
disable_functions=
daneben gelegt.

Anschließend gab ich ein `composer install` - was abgesehen von ein paar (bekannten) Banalitäten (3x plugin erlauben und package php-http/message-factory is abandoned) - fehlerfrei durchlief. Schau an.

Das angeforderte contao:migrate machte ich im CM, da war aber nichts mehr zu tun. Ich komme nun ins Backend und das Frontend bringt einen 404 - wohl weil es noch keine Seiten(-Inhalte) gibt.

{später}
Zu Testzwecken habe ich eine Seite angelegt - aber einen Artikel da drauf packen kriege ich (momentan noch) nicht hin. Irgendwas fehlt wohl...

Meine Idee ist jetzt aber, DIESER INSTALLATION die DB (natürlich eine Kopie) der bisherigen 4.13 zu geben. Was sollte ich dazu tun? Wo steht denn jetzt die Datenbank-Konfiguration? (*)
Danach würde ich bestimmt wieder contao:migrate machen müssen und ... was dann?

TIA
purzel (der leider wieder erstmal aufhören muss)

(*) `fgrep -r DATENBANKNAME *` findet nichts (außer Einträge in Logs) :eek:

Zitat:

---

Zitat von purzel

Zu Testzwecken habe ich eine Seite angelegt - aber einen Artikel da drauf packen kriege ich (momentan noch) nicht hin. Irgendwas fehlt wohl...

---

Du musst zuerst ein Layout anlegen und zuweisen. Siehe https://docs.contao.org/manual/de/an...te-startseite/

Zitat:

---

Zitat von Spooky

Du musst zuerst ein Layout anlegen und zuweisen. Siehe https://docs.contao.org/manual/de/an...te-startseite/

---

Vielen Dank - erwartungsgemäß hat es so geklappt.

Allerdings...

Zitat:

---

Zitat von purzel

Zu Testzwecken habe ich eine Seite angelegt - aber einen Artikel da drauf packen kriege ich (momentan noch) nicht hin. Irgendwas fehlt wohl...

---

war das Anlegen der Seite ja nur zu Testzwecken ;)

Eigentlich und ursprünglich wollte ich

Zitat:

---

Zitat von purzel

Meine Idee ist jetzt aber, DIESER INSTALLATION die DB (natürlich eine Kopie) der bisherigen 4.13 zu geben. Was sollte ich dazu tun? Wo steht denn jetzt die Datenbank-Konfiguration?
Danach würde ich bestimmt wieder contao:migrate machen müssen und ... was dann?

---

Ich (bzw. grep) finde(t) einfach keine Datei, in der die DB konfiguriert ist. in der 4.13 gab es
config/parameters.yml: database_name: xxxxxx
Das finde ich für die 5.3 leider nicht.

Im Grunde ist das aber alles fast nur Zeitvertreib - ich will ja im Idealfall die funktionierende 4.13.52 Instanz auf 5.3.x "anheben"; was ja auf dem Goneo-Account nicht klappt. Die komplette Instanz in der "frischen" Installation nachbauen ist eine eher weniger akzeptable Option...

Zitat:

---

Zitat von purzel

Ich (bzw. grep) finde(t) einfach keine Datei, in der die DB konfiguriert ist. in der 4.13 gab es
config/parameters.yml: database_name: xxxxxx
Das finde ich für die 5.3 leider nicht.

---

Das ist nun in der .env als DATABASE_URL

.env.local aber ;)

Ah! Eine VERSTECKTE Datei - die findet fgrep mit Dateimuster * natürlich nicht. Vielen Dank!

Mit dieser Erkenntnis habe ich der Testinstallation 5.3 (war zuvor mit "frischer", leerer DB installiert) eine Kopie der DB meiner "offiziellen" Instanz untergeschoben und anschließend den CM laufen lassen. Der wollte (nach einem self-update) erwartungsgemäß die DB prüfen und hat einen Haufen Änderung darin gemacht, alles sah gut aus. Vorsichtshalber habe ich (nochmal?) den Prod.-Cache erneuert.
Im Backend dann sah zunächst fast alles gut aus; ich wunderte mich aber über das Fehlen einer Zeile, die ich in der 4.13 im Template be_welcome eingebaut hatte. Erstes großes Problem: ALLE selbst modifizierten Templates sind offenbar weg. Seiten und Artikel jedoch scheinen da zu sein, das sieht gut aus... Doch leider die Ernüchterung: das Frontend läuft nicht, Fehlermeldung. Im Log finde ich dann auch diverse Dinge, mit denen er jetzt unglücklich ist: fehlende Templates, fehlendes Modul. Die veralteten Erweiterungen hatte ich ja schon vor einigen Tagen entfernt.

Also ist anscheinend DIE Vorgehensweise zum Upgrade untauglich; es war ja nur ein Versuch.

Ich werde also in den nächsten Tagen einen Probe-Account bei All-Inkl machen, die Live-Instanz da hin kopieren und nochmals ein Upgrade auf 5.3 versuchen. Einerseits bin ich ein bisschen guter Dinge, dass das dort klappen könnte aufgrund der hoffentlich nicht vorhandenen Restriktionen wie bei Goneo - andererseits habe ich Bedenken, dass wieder mal "so Einiges" nicht (mehr) funktioniert. Das war eigentlich immer so beim Upgrade des Major-Release und hat für einen Haufen Nacharbeit gesorgt. Man wird sehen...

{etwas später}
Eine Idee hatte ich noch: in der Live das theme exportieren und Selbiges in die Test importieren. Der Import scheitert aber auch wegen fehlender Tabellen und Felder; trotz o.g. DB-Änderungen. Schade. Hoffentlich habe ich DAS Symptom nicht auch wenn ich ein "echtes" Upgrade über den Manager mache...

Zitat:

---

Zitat von purzel

Erstes großes Problem: ALLE selbst modifizierten Templates sind offenbar weg.

---

Hattest du sie denn überhaupt kopiert?

Öhm.... Jetzt wo Du es sagst... natürlich nicht *vornkopphau*

Bei meinen bisherigen Versuchen hatte ich immer (sinngemäß)
$ cp -av htdocs/Live-Instanz htdocs/Neue_Instanz
gemacht - da kommen die Templates natürlich mit.
Der letzte Versuch war ja eine "frische" Installation der 5.3 - woher sollen da meine Templates kommen.

Nachdem ich die Templates stumpf alle kopiert hatte kam ich immer noch nicht 'rein - das Template be_login habe ich wohl auch modifiziert - ich weiß aber gerade nicht mehr warum. Das ist jedoch momentan zweitrangig.

Nachdem das erstmal eliminiert ist geht immerhin das BE wieder; das FE immer noch nicht - wohl weil das Modul mootoolsnav fehlt. So kommt immer eins zum Anderen...

Weil hier Goneo angesprochen wurde als Grund für diesen Ärger:
Ich bin auch dort und bei mir gibt es exakt die selbe Fehlermeldung beim Update auf Version 4.13.53 (von einer anderen 4.13.x Version):

Code:

---

"Call to undefined function Symfony\Component\Console\SignalRegistry\pcntl_async_signals()"

---

Mich wundert, dass es nach einem so kleinen Versionsschritt dazu kommen kann. PHP ist auf 8.2 – unangetastet seit Wochen.

Interessanterweise zeigt er mir im Manager aber nun an, dass alle Pakete (scheinbar) auf der neuesten Version angekommen sind.
Notwendigkeit einer DB-Update wurde mir danach auch angezeigt und habe ich durhgeführt.

Macht meine Angst für zukünftige Contao-Updates nicht geringer....
Umsteigen ist einiges an Arbeit, zumal noch eine WordPress-Website parallel im Paket ist, bei der alles rundläuft. Das ist ist echt schade, dass Contao durch Symphony so komplex geworden ist.
Ich würde für eine einfache Vereinswebsite tatsächlich WordPress empfehlen, Updates dauern dort max. 10 Sekunden.
Sicherlich hat Contao bei komplexen Websites seine Berechtigung, aber man muss nicht mit Kanonen auf Spatzen schießen. Nur um klarzustellen, dass ich Contao hier nicht schlechtreden möchte!

Trotzdem ist es m.E. nicht fair Contao "schuldig" zu sprechen, wenn der Hoster nicht oder nicht optimal geeignet ist für das CMS. Die Anforderungen sind ja nun nicht so exotisch, dass es bei allen anderen Hostern auch nicht läuft.

Ich ahnte, dass meine Aussage diese Reaktion hervorrufen würde... aber von "Schuld" habe ich doch gar nicht gesprochen.
Contao ist ganz klar nach dem Umstieg auf Symphony komplexer geworden. Aber dieses Framework hat natürlich seine Berechtigung, weil man rasch viel damit umsetzen kann und es eine gemeinsame, sehr bekannte Basis für Entwickler gibt.
Man muss sich aber schon sehr in die Materie einarbeiten, um die ganze komplexen Zusammenhänge nachvollziehen zu können.
Ich meine auch hier gelesen zu haben, dass Contao sich ganz klar auf den prof. Markt konzentrieren möchte, was völlig ok ist.

Meine Aussage bezog sich also eher auf die jetzige Lage von Purzel und dem gemeinnützigen Verein, den finanziellen Mitteln / Umständen und einem neuen Webmaster, der dies scheinbar auch nebenberuflich macht.

Zitat:

---

Zitat von Jogibär

Interessanterweise zeigt er mir im Manager aber nun an, dass alle Pakete (scheinbar) auf der neuesten Version angekommen sind.

---

Wie schon vorher in diesem Thread erwähnt: der Fehler passiert nach der Aktualisierung der Pakete (während der Cache neu aufgebaut wird etc.).

@Jogibär @purzel führt bei Goneo auf der Konsole mal folgendes aus und postet die Ausgabe:

Code:

---

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

---

Moderation: Thread in das "Erfahrungen mit Webhostern" Unterforum verschoben und Titel etwas editiert, da es sich um ein Hoster-spezifisches Problem handelt.

Ich denke aber es sollte lösbar sein - bzw. ich denke es sollte eine Lösung gefunden werden können, die auch für den Hoster Goneo passt.

Zitat:

---

Zitat von Spooky

@Jogibär @purzel führt bei Goneo auf der Konsole mal folgendes aus und postet die Ausgabe:

Code:

---

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

---

---

Das war einfach und schnell gemacht:

Code:

---

~$ /usr/bin/php8.3 -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(false)
string(398) "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,"

---

Zitat:

---

Zitat von Spooky

Ich denke aber es sollte lösbar sein - bzw. ich denke es sollte eine Lösung gefunden werden können, die auch für den Hoster Goneo passt.

---

Das wäre ja durchaus schön - dann hätte ich den Aufwand des Umzugs nicht. (Der auch überschaubar aber ein Stück weit nervig/stressig wäre)

In der Tat habe ich die Web-Präsenz des Vereins fast 18 Jahre ehrenamtlich gemacht; als ich das damals übernahm waren einige wenige statische HTML Seiten. Relativ schnell habe ich seinerzeit Contao (damals noch TYPOLIGHT!) da etabliert. Jetzt habe ich für die Inhalte eine Nachfolgerin; "Systemkram" wird wohl weiterhin "an mir hängen bleiben". Niemand von uns macht(e) das je beruflich.

Zitat:

---

Zitat von purzel

Das war einfach und schnell gemacht:

Code:

---

~$ /usr/bin/php8.3 -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(false)
string(398) "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,"

---

---

Hm, sehr seltsam. Bei dir wird dieser Code ausgeführt, obwohl \function_exists('pcntl_async_signals') eigentlich false zurück gibt. Das müsste man auf Goneo näher debuggen.

Nur um es nochmal zu bestätigen - der Fehler tritt auch auf, wenn du auf der Konsole

Code:

---

/usr/bin/php8.3 vendor/bin/contao-setup

---

ausführst?

Bei mir genauso (für PHP 8.2):

Code:

---

/usr/bin/php8.2 -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(false)

---

EDIT: Nach Eingabe von /usr/bin/php8.2 vendor/bin/contao-setup wird alles mit grün ausgeführt.
Am Ende steht:

Code:

---

[INFO] Done! Please open the Contao install tool or run the contao:migrate command to make sure the database is       
        up-to-date.

---

Zitat:

---

Zitat von Jogibär

Bei mir genauso (für PHP 8.2):
bool(false)

---

Immer die gesamte Ausgabe inkl. Aufruf posten.

Zitat:

---

Zitat von Jogibär

Bei mir genauso (für PHP 8.2):

Code:

---

/usr/bin/php8.2 -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(false)

---

---

Ist das wirklich die gesamte Ausgabe? Da fehlt nämlich die Ausgabe von var_dump(ini_get('disable_functions'));

Zitat:

---

Zitat von Jogibär

EDIT: Nach Eingabe von /usr/bin/php8.2 vendor/bin/contao-setup wird alles mit grün ausgeführt.
Am Ende steht:

Code:

---

[INFO] Done! Please open the Contao install tool or run the contao:migrate command to make sure the database is       
        up-to-date.

---

---

Und wenn du nun folgendes ausführst:

Code:

---

/usr/bin/php8.2 public/contao-manager.phar.php composer install -o

---

(public/ ggf. mit web/ ersetzen)

Sorry, du hast Recht, Spooky, hier die vollständige Eingabe + Ausgabe:

Code:

---

/usr/bin/php8.2 -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(false)
string(398) "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,"

---

Bei Eingabe von "/usr/bin/php8.2 public/contao-manager.phar.php install -o" erhalte ich folgende Meldung:

Code:

---

  Command "install" is not defined.

---

Sorry, hab das Command oben nochmal editiert, da hat "composer" gefehlt.

Ok, jetzt wurde es ausgeführt!

Insgesamt auch alles in grün, aber anfangs steht etwas von "downgrading":

Code:

---


Installing dependencies from lock file (including require-dev)
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>`.
Package operations: 0 installs, 21 updates, 0 removals
  - Downloading spatie/schema-org (3.23.0)
  - Downloading league/flysystem-bundle (3.3.5)
  - Downgrading twig/twig (v3.20.0 => v3.18.0): Extracting archive
  - Downgrading symfony/property-info (v6.4.18 => v6.4.17): Extracting archive
  - Downgrading spatie/schema-org (3.23.1 => 3.23.0): Extracting archive
  - Downgrading league/flysystem-bundle (3.4.0 => 3.3.5): Extracting archive
  - Downgrading doctrine/dbal (3.9.4 => 3.9.3): Extracting archive
  - Downgrading doctrine/orm (2.20.2 => 2.20.1): Extracting archive
  - Downgrading doctrine/sql-formatter (1.5.2 => 1.5.1): Extracting archive
  - Downgrading doctrine/doctrine-bundle (2.13.2 => 2.13.1): Extracting archive
  - Downgrading contao/image (1.2.3 => 1.2.2): Extracting archive
  - Downgrading contao-components/ace (1.38.0 => 1.37.4): Extracting archive
  - Downgrading contao/core-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/comments-bundle (4.13.53 => 4.13.50): Extracting archive
  - Upgrading contao/conflicts (dev-main 7591089 => dev-main 3d8f465)
  - Downgrading contao/faq-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/listing-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading twig/extra-bundle (v3.20.0 => v3.18.0): Extracting archive
  - Downgrading contao/installation-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/manager-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/newsletter-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/news-bundle (4.13.53 => 4.13.50): Extracting archive
  - Downgrading contao/calendar-bundle (4.13.53 => 4.13.50): Extracting archive

Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.
Generating optimized autoload files
118 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 vendor/bin/contao-setup
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

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
Added the /data/web/1/000/063/713/260436/htdocs/Website-2023/public/index.php file.
Added the /data/web/1/000/063/713/260436/htdocs/Website-2023/public/app.php file.
Added the /data/web/1/000/063/713/260436/htdocs/Website-2023/public/preview.php file.

 Trying to install assets as relative symbolic links.

---

Danach folgende dann wie zuvor die einzenen "grünen" Bereiche für "Bundle", "Symlink", Clearing des Caches etc.

EDIT: Meine letzte Aktion im Contao-Manager war das Updaten aller Pakete (mit der erwähnten Fehlermeldung)

EDIT 2: Beim DB-Update gibt es nun folgende Änderungen:

Code:

---

Feld tl_user.session ändern

BLOB DEFAULT NULL
ALTER TABLE tl_user CHANGE session session BLOB DEFAULT NULL

---

Ok - meine Vermutung ist, dass das Problem am Contao Manager selbst liegt - also insbesondere, dass der Contao Manager die disable_functions leert. Das Setup bei Goneo ist dann aber trotzdem seltsam - denn offensichtlich scheint dann zwar \function_exists('pcntl_async_signals') true zurückzugeben (weil nicht mehr in disable_functions) - der Aufruf pcntl_async_signals() führt dann aber trotzdem zu einem Fehler, weil die Funktion in Wirklichkeit doch nicht existiert bei Goneo.

@Jogibär @purzel führt bei Goneo auf der Konsole mal folgendes aus und postet die Ausgabe:

Code:

---

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

---

Bei mir:

Code:

---

/usr/bin/php8.2 -ddisable_functions= -r "var_dump(function_exists('pcntl_async_signals')); var_dump(ini_get('disable_functions'));"
bool(true)
string(0) ""

---

Damit könnt ihr nun an den Hoster herantreten. Also folgendes passiert bei euch:

Code:

---

/usr/bin/php8.2 -ddisable_functions= -r "var_dump(function_exists('pcntl_async_signals'));"
bool(true)

---

Es muss aber so sein:

Code:

---

/usr/bin/php8.2 -ddisable_functions= -r "var_dump(function_exists('pcntl_async_signals'));"
bool(false)

---

Der Hoster muss prüfen, warum das so ist.

Bzw. bevor ihr das macht, ein Test noch:

Code:

---

/usr/bin/php8.2 -ddisable_functions= -r "var_dump(function_exists('pcntl_async_signals')); pcntl_async_signals(true);"

---

Was ist da die Ausgabe?

Bei mir nun:

Code:

---

/usr/bin/php8.2 -ddisable_functions= -r "var_dump(function_exists('pcntl_async_signals')); pcntl_async_signals(true);"
bool(true)

---

EDIT: Danke für deine Mühe, Spooky!
Ich werden nun Goneo mal anschreiben!

Hm, naja beim letzten Test kam es aber zu keinem Fehler.

Versuche es nochmal mit

Code:

---

/usr/bin/php8.2 -ddisplay_errors=1 -ddisable_functions= -r "error_reporting(-1); var_dump(function_exists('pcntl_async_signals')); pcntl_async_signals(true);"

---

Resultat hier:

Code:

---

/usr/bin/php8.2 -ddisplay_errors=1 -ddisable_functions= -r "error_reporting(-1); var_dump(function_exists('pcntl_async_signals')); pcntl_async_signals(true);"
bool(true)

---

Ich finde es merkwürdig, dass das Contao-Update davor ja immer funktioniert hat.

Zitat:

---

Zitat von Jogibär

Resultat hier:

Code:

---

/usr/bin/php8.2 -ddisplay_errors=1 -ddisable_functions= -r "error_reporting(-1); var_dump(function_exists('pcntl_async_signals')); pcntl_async_signals(true);"
bool(true)

---

Ich finde es merkwürdig, dass das Contao-Update davor ja immer funktioniert hat.

---

Evt. hat Goneo das kürzlich geändert.

Zitat:

---

Zitat von Spooky

Hm, sehr seltsam. Bei dir wird dieser Code ausgeführt, obwohl \function_exists('pcntl_async_signals') eigentlich false zurück gibt. Das müsste man auf Goneo näher debuggen.

---

Debuggen... Sag' wie - ich bin "zu vielen Schandtaten bereit" :)

Zitat:

---

Zitat von Spooky

Nur um es nochmal zu bestätigen - der Fehler tritt auch auf, wenn du auf der Konsole

Code:

---

/usr/bin/php8.3 vendor/bin/contao-setup

---

ausführst?

---

Bei (fast) aktuellem System (4.13.52 anstatt 4.13.53) alles grün (mit Ausnahme der beiden oben diskutierten Warnungen die veraltete Erweiterung betreffend)

Wenn ich übrigens

PHP-Code:

---

var_dump(function_exists('pcntl_async_signals')); 
var_dump(ini_get('disable_functions')); 


---

in eine Datei packe und vom Browser aufrufe (also Web-PHP benutzt wird)) kommt bool(true) string(0) ""

MIt CLI PHP 8.2 sind die Consolen-Ausgaben übrigens identisch; Downgrade-Meldungen wie bei Jogibär hatte ich bisher jedoch nicht, jedenfalls nicht in der LIVE-Instanz; bei irgendeinem missglückten Upgrade Versuch irgendeiner Test-Kopie aber glaube ich schon.

Zitat:

---

Zitat von Spooky

Ok - meine Vermutung ist, dass das Problem am Contao Manager selbst liegt - also insbesondere, dass der Contao Manager die disable_functions leert. Das Setup bei Goneo ist dann aber trotzdem seltsam - denn offensichtlich scheint dann zwar \function_exists('pcntl_async_signals') true zurückzugeben (weil nicht mehr in disable_functions) - der Aufruf pcntl_async_signals() führt dann aber trotzdem zu einem Fehler, weil die Funktion in Wirklichkeit doch nicht existiert bei Goneo.

---

Meine Beobachtung war ja z.T. auch sehr eigenartig, abhängig von benutztem "-c path/to/php.ini" in den jeweiligen Befehlen und als einzige Zeile in der selbstgemachten php.ini
disable_functions=

Meine eher bescheidenen Kenntnisse hatten ja auch zutage gefördert, daß mit dem irgendwo im Web gefundene Code

PHP-Code:

---

<?php
// Verwendung von Ticks benötigt
declare(ticks = 1);

// Signalverarbeitungsfunktion
function sig_handler($signo)
{

     switch ($signo) {
         case SIGTERM:
             // Aufgaben zum Beenden bearbeiten
             exit;
             break;
         case SIGHUP:
             // Aufgaben zum Neustart bearbeiten
             break;
         case SIGUSR1:
             echo "SIGUSR1 abgefangen...\n";
             break;
         default:
             // Alle anderen Signale verarbeiten
     }

}

echo "Richte Signalverarbeitung ein...\n";

// Signalverarbeitung einrichten
pcntl_signal(SIGTERM, "sig_handler");
pcntl_signal(SIGHUP,  "sig_handler");
pcntl_signal(SIGUSR1, "sig_handler");

// oder ein Objekt verwenden
// pcntl_signal(SIGUSR1, array($obj, "do_something"));

echo "Erzeuge signal SIGTERM an mich selbst...\n";

// sende SIGUSR1 an die aktuelle Prozess-ID
// Für posix_*-Funktionen wird die Posix-Erweiterung benötigt
posix_kill(posix_getpid(), SIGUSR1);

echo "Fertig\n"

?>

---

im Browser alles gut ist:
Richte Signalverarbeitung ein... Erzeuge signal SIGTERM an mich selbst... SIGUSR1 abgefangen... Fertig
und im CLI nicht:
$ php st.php
Richte Signalverarbeitung ein...
PHP Fatal error: Uncaught Error: Call to undefined function pcntl_signal() in /.../htdocs/LIVE/public/TESTS/st.php:31
Stack trace:
#0 {main}
thrown in /.../htdocs/LIVE/public/TESTS/st.php on line 31

Zitat:

---

Zitat von Jogibär

Ich werden nun Goneo mal anschreiben!

---

Die Mühe, sie mögen doch bitte disable_functions auf "nichts" setzen wie es für Web-PHP der Fall ist, kannst Du Dir sparen, das habe ich schon erfolglos hinter mir:

> ...
> Dürfte ich freundlich darum bitten die disable_functions Liste für CLI-PHP ebenfalls zu leeren? Das würde dem weiteren Betrieb von Contao bei Ihnen den Weg ebnen.
> ...

Antwort:
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.

:(

Grundsätzlich ist das ja auch ok. Die pcntl_* Funktionen sind optional - nur macht anscheinend die Kombination mit dem Contao Manager (wo disable_functions auf Leer gesetzt wird) Probleme.