Grundsätzlich seit 2.1.0.Zitat:
Zitat von tab
Das Problem tritt ja nur über den Web Prozess auf. Und Composer wird ja normalerweise nicht über den Web Prozess aufgerufen. Außer eben im Contao Manager.Zitat:
Zitat von tab
Grundsätzlich seit 2.1.0.Zitat:
Zitat von tab
Das Problem tritt ja nur über den Web Prozess auf. Und Composer wird ja normalerweise nicht über den Web Prozess aufgerufen. Außer eben im Contao Manager.Zitat:
Zitat von tab
Genau, der Composer funktioniert, wenn er - wie es eben üblich ist - direkt aus der Konsole aufgerufen wird. Insofern könnte man zwar an die Entwickler herantreten und um eine Anpassung bitten. Aber ein Bug in Composer ist es jedenfalls nicht, es wäre eher ein Feature, dass er eben auch anders gestartet werden kann und trotzdem keine Fehler wirft. Das stünde dann freilich im Ermessen der Composer-Entwickler. Zumal jedenfalls ich auch nicht wüsste, wie man die hier benötigte(?) Information auf andere Weise sicher gewinnen könnte. Mit try ... catch? Das Fragezeichen bei "benötigte" setze ich, weil die Info ja auch nicht gewonnen werden kann, wenn von vornherein die Datei nicht lesbar ist oder open_basedir das verhindert. Trotzdem mag es nützlich sein, die Information falls möglich zu haben, deswegen kann man wenig dagegen einwenden.Zitat:
Zitat von Spooky
Trotzdem wurde Composer vom Manager auch bisher schon über den Webprozess gestartet. Wenn er der im Manager enthaltene Composer den Code schon ausgeführt hätte, dann hätte er eigentlich auch da schon den Fehler werfen müssen. Oder war Composer 2.1 da noch nicht im Manager drin?
Alfahosting schreibt: da es keine Änderung bei uns gegeben hat, liegt die Ursache in der aktuellen Contao-Manager Version. Wir haben aktuell leider noch keinen Ansatz wo die konkrete Ursache liegt, und prüfen dies noch.
Ja, ich denke schon, dass es Sinn macht, zumindest ein Ticket zu öffnen. Dann kann man dort diskutieren, ob man da nicht doch noch ein zusätzliches hardening einbauen kann. zB silence operator für file_get_contentsZitat:
Zitat von tab
Hast du ihnen das Test Script gezeigt?Zitat:
Zitat von Alok
Na immerhin, sie prüfen noch.
Aber, ich sehe gerade, es gibt einen Contao-Manager 1.4.6, also erst nochmal probieren, vielleicht wurde ja eine Möglichkeit gefunden das Problem zu lösen/umgehen.
Ich hab's mal als PR zur Diskussion gebracht: https://github.com/composer/composer/pull/10080
@spooky
Ich habe den alfahosting-support mehrmals in unserer Konversation auf diesen Thread verwiesen, mit Link. Weiß aber nicht in wieweit er sich die Einzelheiten (Code) dazu ansieht....
Vermutlich nichts … ;). Du kannst ihnen auch noch den Link zum Composer Pull Request schicken, vielleicht können die dann mehr damit anfangen, um das Problem besser zu verstehen.Zitat:
Zitat von Alok
Jup, habe ich dem Support gemeldet. Zu einer Lösung sind wir aber noch nicht gekommen.Zitat:
Zitat von Spooky
Den Link zum Pull Request habe ich Ihnen auch zur Kenntnis übermittelt. Danke für den PR!Zitat:
Zitat von Spooky
Das Allereinfachste wird wohl sein, sie geben /proc/version für alle zum Lesen frei, also 444, was ja wohl eigentlich auch Default ist. So geheim wird der da drinstehende Versionsstring ja wohl auch wieder nicht sein.
Was ist die Ausgabe von ls -la /proc/version auf diesen Alfahosting Systemen via SSH?
Feedback von alfahosting:
ich habe den Forenbeitrag gesehen. Wie dort herausgearbeitet, ist das Problem der Zugriff während der Installlation über die Weboberfläche auf den Serverpfand /proc/version, den wir aus Sicherheitsgründen sperren. Das ist aber bereits länger unverändert so, und hat bisher keinerlei Probleme verursacht. Wir prüfen gerade intern ob wir den Zugriff freigeben können, oder ob es doch andere Optionen gibt.
gibt es Erfahrungen mit dem Contao-Manager 1.4.6 in Zusammenhang mit diesem Problem?
Es ist erst seit Composer 2.1 ein Problem, bzw. seit der Contao Manager Version 2.1 des Composers nutzt.Zitat:
Zitat von Alok
Es muss nicht unbedingt freigegebenen werden. Es muss nur sichergestellt werden, dass is_readable('/proc/version') korrekterweise dann false zurück liefert.Zitat:
Zitat von Alok
Hi, ich hab das gleiche Problem bei Alfahosting. Die Seite war ein Update von 3.5. auf 4.11. was auch ziemlich problemfrei geklappt hat. Sie lief unter einer Subdomain (http) schon eine ganze Weile, während ich daran gearbeitet habe und die Hauptdomain (mit https) hab ich heute auf das /web Verzeichnis umgestellt. Das hat leider gar nicht funktioniert und führt erst zu endlosen Redirects und als es dann endlich funktionierte, bekomme ich plötzlich die Fehlerseite von Contao angezeigt. Debugmodus sagt, dass assets/colorbox fehlt und wenn ich im Backend ein Layout aufrufen will, bekomme ich diese Fehlermeldung: https://github.com/contao/managed-edition/issues/30 obwohl es sich um contao 4.11. handelt.
Ich vermute jetzt mal, dass sich das durch eine komplette Paketinstallation beheben ließe. Aber das geht ja leider wegen dem Problem bei Alfahosting gerade nicht.:rolleyes: Ich habe leider NULL Ahnung von composer, aber bevor ich mich jetzt hinsetze und mich da reinlese und es ausprobiere, wollte ich mal fragen, ob es da nicht doch noch eine alternativen Lösungsvorschlag gibt. Symlinks neu erstellt und Cache geleert habe ich bereits. Ich glaube, das hat Problem Nr. 2 erst hervorgebracht.
Logs sagen übrigens dies:
request.CRITICAL: Uncaught PHP Exception Symfony\Component\Asset\Exception\InvalidArgumentE xception: "There is no "contao-components/colorbox" asset package." at var/www/xxxx/html/contao4/vendor/symfony/asset/Packages.php line 71 {"exception":"[object] (Symfony\\Component\\Asset\\Exception\\InvalidArgu mentException(code: 0): There is no "contao-components/colorbox" asset package. at /var/www/xxxx/html/contao4/vendor/symfony/asset/Packages.php:71)"} []
Ich denke im Moment klappt das wirklich nur per SSH in der Konsole. Bzw der Update Teil klappt ja auch im Manager. Es muss also nur der Install Teil dann noch in der Konsole ausgeführt werden, wenn der Contao-Manager mit seinem Konsolentask fertig ist (bzw mit Fehlermeldung sich beendet hat). Hier kann man den Befehl, der im Manager im Konsolenfenster bei Composer Install angezeigt wird, im Contao-Installationsverzeichnis - also oberhalb des web-Verzeichnisses, da wo die composer.json und composer.lock drin liegen - eingeben bzw mit Copy & Paste (Im SSH-Konsolenfenster geht Paste mit einem Rechtsklick) ins SSH-Konsolenfenster reinkopieren und ausführen. Falls /var/www/... in der Konsole z.B. wegen chroot-Umgebung nicht klappt, kann man den Pfad zum Contao-Manager auch einfach durch "web/contao-manager.phar.php" ersetzen. Wichtig ist halt nur, dass man zuerst mit cd in der Konsole in das richtige Verzeichnis wechselt, in das mit composer.json und composer.lock.
Mit der Umstellung von PHP 7.4 auf 8.0 hat das Update nicht gefunzt, im Gegenteil, die 4.11.8 Version von Contao lief nicht mehr.
Ich habe weiter oben gelesen, dass man das Update mit SSH hin bekommt. Wie mache ich das über den Contao-Manager? Der neue Manager 1.4.6 hat auch nicht geholfen.
Hi, vielen Dank für die Anleitung. Der Befehl, den ich kopieren muss, ist dann qausi nur was in Zeile 1 der Fehlermeldung steht, richtig?Zitat:
Zitat von tab
Anhang 24866
Ja. Wie bereits geschrieben, falls du direkt von der Konsole nicht auf /var/www/... zugreifen kannst, einfach durch den relativen Pfad web/contao-manager.phar.php ersetzen. Oder durch den Pfad, den dir "pwd" anzeigt, wenn du im Verzeichnis mit der contao-manager.phar.php bist.
Danke! Hat geklappt, Seite läuft wieder.Zitat:
Zitat von tab
Falls Alfahosting das nicht bei sich behebt: wenn eine neue Composer Version veröffentlicht, diese in den Contao Manager integriert und dann diese Contao Manager Version veröffentlicht wurde, wird dieses Problem nicht mehr auftreten.
Prima dass das in Composer abgesichert wird. Das ist auch sicher die beste Lösung, jedenfalls für den Contao-Manager. Und Composer tut es zumindest nicht weh. Letztlich hat Alfahosting auch nicht unbedingt etwas falsch gemacht. Die Funktion is_readable funktioniert nun mal so. Die Problematik scheint den PHP-Entwicklern ja bewusst zu sein. Vielleicht hat es ja irgendeinen tieferen Sinn :rolleyes:. Ich gehe davon aus, dass auf /proc/version auch in den anderen Aufrufvarianten bei Alfahosting nicht zugegriffen werden kann und eben nur is_readable() da false zurückgibt. Und selbst wenn die da jetzt irgendwas tricksen würden - die grundlegende Serverkonfiguration im shared Hosting werden sie ja deshalb sicher nicht ändern wollen - mag es noch andere Hoster da draussen geben, bei denen das ähnlich aussieht. Und ob man die alle würde überzeugen können ... So ist es jetzt in Composer jedenfalls gefixt, egal ob da bei den Hostern was geändert wird oder nicht. Und der Contao-Manager muss ja auch nicht die einzige Software bleiben, die Composer auf diese Art und Weise verwendet.
Ich denke schon, dass Alfahosting prüfen muss, warum in deren Umgebung diese Funktion true zurück gibt, die jeweilige Datei aber dann dennoch nicht gelesen werden kann.
contao update über konsole, habe ich noch nicht gemacht. Gibt es da eine gute Anleitung?
Ich gehe mal davon aus, das der Fehler, sei es bei Contao oder Alfahosting so schnell nicht behoben wird.
In der Doku gibt es eine Anleitung dazu: https://docs.contao.org/manual/de/in...aktualisieren/Zitat:
Zitat von Norbert001
Aber: Das wird wahrscheinlich wegen fehlendem RAM nicht immer und überall funktionieren, weil hierbei der Cloud-Resolver nicht benutzt werden kann.
Eine Möglichkeit für Benutzer, die sich auf der Kommandozeile nicht so wohlfühlen, Composer nicht installieren wollen oder bei denen das wegen zu wenig RAM ohnehin nicht klappt, habe ich z.B. hier gezeigt:
https://community.contao.org/de/show...l=1#post548624
Der Fehler wird mit der nächsten Composer-Version, bzw der nächsten Contao-Manager-Version, die diese Composer-Version mitbringt, nicht mehr auftreten. Wann das sein wird kann ich dir aber auch nicht sagen.
Wenn ich das richtig sehe, tritt der Fehler bei Alfahosting erst auf, wenn die composer.lock bereits fertig erstellt ist.
Dann sollte anschließend das Install doch über ssh ohne Probleme funktionieren, oder wird dazu auch soviel Speicher benötigt?
Ja, du kannst die composer.lock mit Hilfe des Contao-Managers erzeugen und danach ein "composer install" per ssh ausführen, das wesentlich weniger RAM braucht als ein "composer update". Ob du das composer install mit einer "echten" composer.phar ausführst oder mit Hilfe der contao-manager.phar.php sollte dabei keine besondere Rolle spielen.
Fehlermeldung vom Composer:
Contao-Manager 1.4.6, Systemwartung durchgeführtCode:composer install
$ /usr/bin/php7.3 -q -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /var/www/web23953849/html/contao4/web/contao-manager.phar.php composer install --prefer-dist --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader
Using config.component-dir has been deprecated. Please use extra.contao-component-dir instead.
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 4 installs, 81 updates, 1 removal
- Downloading twig/twig (v3.3.2)
- Downloading symfony/http-foundation (v5.3.7)
- Downloading symfony/var-dumper (v5.3.7)
- Downloading symfony/http-kernel (v4.4.30)
- Downloading symfony/dependency-injection (v5.3.7)
- Downloading symfony/http-client (v5.3.7)
- Downloading symfony/dom-crawler (v5.3.7)
- Downloading symfony/yaml (v5.3.6)
- Downloading symfony/security-csrf (v5.3.4)
- Downloading symfony/filesystem (v5.3.4)
- Downloading symfony/config (v5.3.4)
- Downloading symfony/process (v5.3.7)
- Downloading symfony/mailer (v5.3.4)
- Downloading symfony/lock (v5.3.4)
- Downloading symfony/intl (v5.3.7)
- Downloading symfony/finder (v5.3.7)
- Downloading symfony/cache (v5.3.7)
- Downloading symfony/expression-language (v5.3.7)
- Downloading symfony/asset (v5.3.4)
- Downloading spatie/schema-org (3.4.0)
- Downloading league/commonmark (1.6.6)
- Downloading contao/core-bundle (4.12.1)
- Downloading contao/calendar-bundle (4.12.1)
- Downloading twig/extra-bundle (v3.3.1)
- Downloading symfony/stopwatch (v5.3.4)
- Downloading symfony/dotenv (v5.3.7)
- Downloading symfony/debug-bundle (v5.3.4)
- Downloading contao/installation-bundle (4.12.1)
- Downloading contao/manager-bundle (4.12.1)
- Removing michelf/php-markdown (1.9.0)
- Upgrading composer/package-versions-deprecated (1.11.99.2 => 1.11.99.3): Extracting archive
- Upgrading symfony/polyfill-mbstring (v1.23.0 => v1.23.1): Extracting archive
- Upgrading twig/twig (v2.14.6 => v3.3.2): Extracting archive
- Upgrading symfony/polyfill-php80 (v1.23.0 => v1.23.1): Extracting archive
- Upgrading symfony/http-foundation (v5.2.11 => v5.3.7): Extracting archive
- Upgrading symfony/event-dispatcher (v4.4.25 => v4.4.30): Extracting archive
- Upgrading symfony/var-dumper (v5.2.11 => v5.3.7): Extracting archive
- Upgrading symfony/debug (v4.4.25 => v4.4.27): Extracting archive
- Upgrading symfony/error-handler (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/http-kernel (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/dependency-injection (v5.2.11 => v5.3.7): Extracting archive
- Upgrading doctrine/annotations (1.13.1 => 1.13.2): Extracting archive
- Upgrading symfony/http-client (v5.2.11 => v5.3.7): Extracting archive
- Upgrading symfony/dom-crawler (v5.2.10 => v5.3.7): Extracting archive
- Upgrading nyholm/psr7 (1.4.0 => 1.4.1): Extracting archive
- Upgrading terminal42/escargot (1.1.0 => 1.2.0): Extracting archive
- Upgrading symfony/yaml (v5.2.14 => v5.3.6): Extracting archive
- Upgrading symfony/twig-bridge (v4.4.26 => v4.4.27): Extracting archive
- Upgrading symfony/twig-bundle (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/translation (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/security-core (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/polyfill-intl-grapheme (v1.23.0 => v1.23.1): Extracting archive
- Upgrading symfony/string (v5.3.3 => v5.3.7): Extracting archive
- Upgrading symfony/property-info (v5.3.1 => v5.3.7): Extracting archive
- Upgrading symfony/property-access (v5.3.0 => v5.3.7): Extracting archive
- Upgrading symfony/security-http (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/security-guard (v4.4.26 => v4.4.27): Extracting archive
- Upgrading symfony/security-csrf (v5.2.10 => v5.3.4): Extracting archive
- Upgrading symfony/filesystem (v5.2.11 => v5.3.4): Extracting archive
- Upgrading symfony/config (v5.2.11 => v5.3.4): Extracting archive
- Upgrading symfony/security-bundle (v4.4.26 => v4.4.27): Extracting archive
- Upgrading symfony/routing (v4.4.25 => v4.4.30): Extracting archive
- Upgrading symfony/process (v5.2.11 => v5.3.7): Extracting archive
- Upgrading monolog/monolog (2.2.0 => 2.3.2): Extracting archive
- Upgrading symfony/monolog-bridge (v5.2.11 => v5.2.12): Extracting archive
- Upgrading symfony/mime (v5.3.2 => v5.3.7): Extracting archive
- Upgrading symfony/mailer (v5.2.11 => v5.3.4): Extracting archive
- Upgrading symfony/lock (v5.2.11 => v5.3.4): Extracting archive
- Installing symfony/intl (v5.3.7): Extracting archive
- Upgrading symfony/finder (v5.2.10 => v5.3.7): Extracting archive
- Upgrading symfony/var-exporter (v5.3.3 => v5.3.7): Extracting archive
- Upgrading symfony/cache (v5.2.11 => v5.3.7): Extracting archive
- Upgrading symfony/framework-bundle (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/expression-language (v5.2.10 => v5.3.7): Extracting archive
- Upgrading symfony/console (v4.4.26 => v4.4.30): Extracting archive
- Upgrading symfony/asset (v5.2.10 => v5.3.4): Extracting archive
- Installing spatie/schema-org (3.4.0): Extracting archive
- Upgrading scssphp/scssphp (v1.5.2 => v1.6.0): Extracting archive
- Upgrading scrivo/highlight.php (v9.18.1.6 => v9.18.1.7): Extracting archive
- Upgrading scheb/2fa-bundle (v5.10.1 => v5.11.0): Extracting archive
- Upgrading scheb/2fa-trusted-device (v5.10.1 => v5.11.0): Extracting archive
- Upgrading scheb/2fa-backup-code (v5.10.1 => v5.11.0): Extracting archive
- Upgrading paragonie/random_compat (v9.99.99 => v9.99.100): Extracting archive
- Upgrading ramsey/uuid (3.9.3 => 3.9.4): Extracting archive
- Upgrading nikic/php-parser (v4.10.5 => v4.12.0): Extracting archive
- Installing league/commonmark (1.6.6): Extracting archive
- Upgrading knplabs/knp-time-bundle (v1.16.0 => v1.16.1): Extracting archive
- Upgrading symfony/options-resolver (v5.3.0 => v5.3.7): Extracting archive
- Upgrading php-http/message (1.11.1 => 1.12.0): Extracting archive
- Upgrading php-http/client-common (2.3.0 => 2.4.0): Extracting archive
- Upgrading doctrine/collections (1.6.7 => 1.6.8): Extracting archive
- Upgrading doctrine/cache (2.0.3 => 2.1.1): Extracting archive
- Upgrading doctrine/persistence (2.2.1 => 2.2.2): Extracting archive
- Upgrading doctrine/orm (2.9.3 => 2.9.5): Extracting archive
- Upgrading symfony/doctrine-bridge (v4.4.25 => v4.4.30): Extracting archive
- Upgrading contao/imagine-svg (1.0.2 => 1.0.3): Extracting archive
- Upgrading contao/image (1.1.0 => 1.1.1): Extracting archive
- Upgrading contao-components/tinymce4 (5.8.2 => 5.9.1): Extracting archive
- Upgrading contao/core-bundle (4.11.5 => 4.12.1): Extracting archive
- Upgrading contao/calendar-bundle (4.11.5 => 4.12.1): Extracting archive
- Upgrading codefog/contao-haste (4.24.17 => 4.25.0): Extracting archive
- Upgrading terminal42/dcawizard (2.4.7 => 2.4.8): Extracting archive
- Upgrading contao/conflicts (dev-main e522208 => dev-main 1a8d4ba)
- Installing twig/extra-bundle (v3.3.1): Extracting archive
- Upgrading symfony/web-profiler-bundle (v4.4.26 => v4.4.28): Extracting archive
- Upgrading symfony/stopwatch (v5.2.10 => v5.3.4): Extracting archive
- Upgrading symfony/proxy-manager-bridge (v5.2.10 => v5.3.4): Extracting archive
- Upgrading symfony/dotenv (v5.2.10 => v5.3.7): Extracting archive
- Upgrading symfony/debug-bundle (v5.2.4 => v5.3.4): Extracting archive
- Upgrading contao/installation-bundle (4.11.5 => 4.12.1): Extracting archive
- Upgrading contao/manager-bundle (4.11.5 => 4.12.1): Extracting archive
- Upgrading madeyourday/contao-rocksolid-custom-elements (v2.3.4 => v2.3.6): Extracting archive
- Upgrading madeyourday/contao-rocksolid-slider (v2.1.1 => v2.1.3): Extracting archive
- Upgrading madeyourday/contao-rocksolid-theme-assistant (v2.0.4 => v2.0.5): Extracting archive
- Upgrading numero2/contao-marketing-suite (1.0.32 => 1.0.33): Extracting archive
Update of symfony/var-dumper failed
In Platform.php line 111:
file_get_contents(/proc/version): failed to open stream: Permission denied
install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-scripts] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>...]
# Process terminated with exit code 1
# Result: General error
Contao-Version derzeit 4.11.5, Problem entsteht bei Update auf 4.12.*
Was tun?!
//Moderation: Beitrag in existierendes Thema verschoben.
Siehe die letzten Kommentare oben.
Info von alfahosting:
wir haben den Fehler erkannt, und prüfen ob eine Änderung der Serverkonfiguration aus Sicherheitsaspekten möglich ist. Parallel wurde ja auch ein Bug-Report für die Ursache im Composer eröffnet (https://github.com/composer/composer/pull/10080) und gefixt, daher wird sich das Problem mit der nächsten Composer Version erledigen. Die Prüfung auf unserer Seite läuft, da wir aber Aufgrund der ISO Zertifizierung nicht ohne weiteres Sicherheitseinstellungen serverweit anpassen können, wird dies noch einige Tage in Anspruch nehmen. Es kommt daher jetzt im Prinzip nur darauf an welche Lösung früher eintritt.
Tut mir leid für die dumme Frage, aber ist schon bekannt wann das Composer Update ausgerollt wird?
Der Bug ist laut Github zumindest schon behoben: https://github.com/composer/composer/pull/10080
PS. Problem besteht ebenfalls bei Hostnet, wenn über den Contao Manager installiert wird.
Viele Grüße aus München
Andi
Es gibt keine dummen Fragen.Zitat:
Zitat von ke-an
Hallo Zusammen,
ich komme leider auch nicht weiter - ich check ehrlich gesagt auch nicht wie ich es über ssh anstoße (installation)
Viele Grüße
Alex
Du kannst bzw. ihr könnt an Alfahosting bzw. Hostnet schreiben, dass es nicht notwendig ist die Sicherheitseinstellungen anzupassen. Es ist ok keine Leserechte für /proc/version zu vergeben. Allerdings muss gewährleistet sein, dassZitat:
Zitat von Alok
über den Web Prozess dann auch wirklich false zurück gibt. Andernfalls kann das auch in anderen Applikationen zu Problemen führen. Die Hoster müssen ja einsehen, dass es nicht korrekt sein kann, wenn dieser Aufruf true zurück gibt.PHP-Code:is_readable('/proc/version')
ich habe heute ein Update bei Alfahosting gemacht... waren einige Umwege notwendigZitat:
Zitat von spacefront
Wenn per SSH auf Konsole verbunden, dann per "cd verzeichnis" zu Deinem Contao-Projektverzeichnis wechseln...
gehen davon aus, PHP 7.4 ist aktiv mit "php -v" testen
Update:
Versuch 1
/usr/bin/php7.4 -d memory_limit=-1 -d max_execution_time=900 web/contao-manager.phar.php composer update -v
ist bei mir abgebrochen
Versuch 2
erst
wget https://getcomposer.org/composer.phar
dann
/usr/bin/php7.4 -d memory_limit=-1 -d max_execution_time=900 composer.phar update -v
ist bei mir abgebrochen
Versuch 3
composer.json local gezogen und composer update gemacht - die neue composer.lock auf Server einspielen
dann
/usr/bin/php7.4 -d memory_limit=-1 -d max_execution_time=900 composer.phar install -v
gab einige Errors ... nach ca. 5 Versuchen lief es durch
DB Update
Versuch 1
/usr/bin/php7.4 vendor/bin/contao-console contao:migrate
ist bei mir abgebrochen - DB error bzw. nicht erreichbar
Versuch 2
install.php aufgerufen
nach drei bis vier mal Aufruf dann alles ok.
uff ... ^^
Du kannst die composer.lock auch einfach von Contao-Manager erzeugen lassen und danach einfach das composer install aus der Konsole starten, egal ob mit der contao-manager.phar.php oder einer "echten" composer.phar. Musst du nicht mal was hin- und herkopieren, außer vielleicht den Befehl aus dem contao-manager raus auf die Kommandozeile. ;)
Dass die is_readable true zurückgibt ist zwar blöd und sollte man besser vermeiden, es ist aber durchaus bekannt, dass die Funktion offenbar ihren eigenen Kopf hat und nicht immer das zurückgibt, was man erwarten würde. Da gabs auch schon mal Probleme wenn Zugriffsrechte über ACL geändert wurden, hat wohl jahrzehntelange Tradition. Allerdings war da das Problem wohl anders rum, was hier jetzt keinen Fehler erzeugt hätte. Die Datei war also lesbar, obwohl is_readable false zurückgegeben hat. Das wäre in unserem Fall hier gar nicht aufgefallen :);)
Ich muss einige Webseiten die bei alfahosting habe updaten und hab das gleiche Problem mit dem composer. Weiß jemand wie lange voraussichtlich so ein update von dem Composer dauern kann? Danke für eine Antwort im Voraus
Dafür gibt es keinen Zeithorizont. Kontaktiere Alfahosting: https://community.contao.org/de/show...l=1#post549157Zitat:
Zitat von madmoses
Ich habe den Support von alfahosting deinen Link geschickt.Zitat:
Zitat von Spooky
Folgende Antwort kam zurück (Sehr geehrter Herr Moser,vielen Dank für Ihre Anfrage. Am Ende ist es ein bekannter Fehler im Composer
https://github.com/composer/composer/pull/10080
Solange dazu kein Update eingespielt wird, müssten Sie wohl wie folgt vorgehen:
Dann habe ich nochmal auf deinen Link hingewiesen mit dem zusätzlichen Hinweis, dass es ja auf einem aktuellen Paket funktioniert und dann bekam ich diese Antwort: (Sehr geehrter Herr Moser,
die neue Tarifgeneration basiert auf einer komplett anderen technischen Infrastruktur, weshalb es dort ggfs. nicht zu den Problemen kommt.)
Aber trotzdem danke für die Antwort Spooky