Goneo: Contao-Manager kaputt?

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.