Contao 4.5 unter Strato Power Basic: keine Bilder im Frontend (404)

Hallo zusammen,

ich habe es trotz mangelnder Erfahrung und Kenntnisse (ich bin kein Entwickler) tatsächlich geschafft problemlos Contao 4.5 unter Strato im Power Web Basic Paket über die Konsole zu installieren.


Soweit ist alles super, doch nun bleibt vorerst noch ein Problem: Bilder aus der Dateiverwaltung werden im Frontend nicht geladen. Die Chrome DevTools zeigen 404: image not found. Dabei ist mein Testbild unter /files in einem eigenen Ordner und dieser ist auch explizit auf 'öffentlich' gestellt. Wenn ich den Pfad des Bildes in einem separaten Tab öffne kommt auch ein 404. Per FileZilla und SSH kann ich sehen, dass es auch im richtigen Verzeichnis zu liegen scheint.

Das Aktualisieren der Symlinks über die Systemwartung hat leider auch nicht geholfen, aber nachdem was ich mittlerweile alles über Contao 4 unter Strato und die Bilderproblematik gelesen habe, fürchte ich, dass es mit dem Hosting und/oder den Symlinks zu tun haben könnte.

Der Contao-Check schien aber soweit OK zu sein.

Hat vielleicht jemand eine Idee was ich noch prüfen kann, um eine Lösung zu finden?

Über eine flinke Antwort würde ich mich freuen.

Sieht für mich so aus, dass entweder die SymLinks nicht angelegt werden können oder die entsprechende Apache Option (FollowSymLinks oder SymLinksIfOwnerMatch) nicht eingestellt ist. Ob die SymLinks (insbesondere der SymLink unterhalb /web/files zu deinem freigegebenen Ordner unterhalb von /files ) existieren kannst du ja über die Konsole leicht prüfen.

Zitat:

---

Zitat von tab

Sieht für mich so aus, dass entweder die SymLinks nicht angelegt werden können oder die entsprechende Apache Option (FollowSymLinks oder SymLinksIfOwnerMatch) nicht eingestellt ist. Ob die SymLinks (insbesondere der SymLink unterhalb /web/files zu deinem freigegebenen Ordner unterhalb von /files ) existieren kannst du ja über die Konsole leicht prüfen.

---

Danke für die schnelle Rückmeldung.

Mit welchem Befehl kann ich denn die Apache Optionen und Symlinks in welchem Verzeichnis prüfen?

Bin noch nicht sehr versiert auf der Konsole...

Gibt es vielleicht eine Übersicht über die vorhandenen und häufigen Konsolen-Commands in Bezug auf Contao 4?

Angenommen, dein Ordner mit den Bildern ist ein direkter Unterordner "deinunterordner" von /files. Dann hast di in /files einen Unterordner deinunterordner.
Ist dieser nicht freigegeben/öffentlich, dann solltest du den selben Unterordner auch in web/files finden. Ist er dagegen freigegeben/öffentlich, dann ist hier kein Unterordner, sondern ein SymLink zu finden, der auf deinen Unterordner /files/deinunterordner verlinkt. Wenn du also in der Konsole in den Ordner /web/files wechselst und dort z.B. eingibst "ls -l", dann wird ein SymLink auf deinen "realen" Unterodner /files/deinunterordner dort (in der letzten Spalte) dargestellt als

Code:

---

deinunterordner -> ../../files/deinunterordner

---

Ist es dagegen ein normaler, "realer" Unterordner von /web/files, dann steht da in der letzten Spalte nur

Code:

---

deinunterordner

---

Das war sehr gut erklärt, danke!

Ich stoße allerdings schon vorher auf ein Problem, das zur Lösung beitragen könnte:
Im Ordner /web gibt es keinen Ordner /files, folglich also auch keinen öffentlichen Unterordner mit dem Bild und keinen Symlink. Im Ordner /files gibt es den Pfad aus der Dateiverwaltung jedoch und der lautet auch /files/bilder.

Kann ich da nun händisch die Ordner für web/files/bilder anlegen und einen Symlink dafür erstellen oder wie löse ich das?
Was könnte das Fehlen des Ordners und Symlinks für Ursachen haben?

Hallo,

hast Du die entsprechenden Verzeichnisse auf "öffentlich" gestellt? (Dateiverwaltung im Contao-Backend). Erst dann wird der Symlink angelegt.

Gruß
Hella

Zitat:

---

Zitat von fusch

hast Du die entsprechenden Verzeichnisse auf "öffentlich" gestellt? (Dateiverwaltung im Contao-Backend). Erst dann wird der Symlink angelegt.

---

Hallo Hella, ja ich habe es mit mehreren Ordnern probiert und alle sind in der Dateiverwaltung auf "öffentlich" gestellt. Trotzdem werden keine Symlinks erstellt.

Überprüfe deine Server Umgebung mit dem Contao Check.

Zitat:

---

Zitat von Spooky

Überprüfe deine Server Umgebung mit dem Contao Check.

---

Danke für den Tip, aber das hatte ich schon überprüft und der Contao Check zeigt mir alles grün an...


Jetzt kommt das Verrückteste:
Ich habe nichts weiter gemacht und heute werden mir die Bilder angezeigt. Ich habe keine Ahnung wieso, aber nun funktioniert es.
Sollte ich dahinter kommen, poste ich hier die Lösung. Ansonsten bin ich erstmal froh, dass es nun zu funktionieren scheint, aber seltsam ist es schon.

Bin heute auf das gleiche Problem gestoßen.
4.5.9 bei Strato installiert, ist auch soweit ohne Fehlermeldung durchgelaufen.
Nach einrichten des ersten Inhalts werden auch bei mir die Bilder aus Files nicht angezeigt(Fehler 404).
Im Ordner web fehlt der Symbolic Link auf Files, es existiert nur einer auf assets.
Habe dann über die Dateiverwaltung einen Unterordner angelegt und veröffentlicht.
Fehler im log -> The symlinks could not be regenerated
Systemwartung -> Symlinks neu erstellen ergibt den gleichen Fehler
Contao check sagt alles ok

Danke vorab für die Hilfe

Aktualisiere mal auf Symfony 3.4.12, falls das nicht schon passiert ist.

Wie kann ich die Version prüfen bzw. das Update installieren?

Über den Contao Manager ein Update durchführen.

Ich vermute mal unter Pakete -> Contao Open Source CMS -> Aktualsieren
Hier bekomme ich leider über Aktualisieren eine Fehlermeldung -
Console task terminated
The background task has stopped unexpectedly

Hallo rpnoc,

ist der aktuelle Manager 1.0.1 am Start?
Dann kannst du unter „Serverkonfiguration die Checkbox des „Composer Cloud Resolver” aktivieren (als Standard ist die Checkbox aktiviert). Ggf. geht es damit dann. Und du kannst dann die Option „Dry Run” zunächst verwenden - es wird ein Update simuliert. Anhand der dann möglichen Fehler in der Konsolenausgabe kann man weitersuchen.

Danke
Ja ist Manager 1.0.1, nach der Aktivierung von "Composer Cloud Resolver" lief auch das Update ohne Fehler.
Ändert ab er leider nichts an dem Problem der fehlenden SymLinks auf /files, bzw der Fehlermeldung beim neu anlegen
über den Manger.

Haben gerade das gleiche Problem. Mit dem Power Web Basic lässt sich kein Symlink setzen. Ziehen nun zu einem anderen Provider um.

also bei meinen Testinstallationen auf Power Web Basic bei Strato sind beide aktuellen Versionen 4.5.10 und 4.4.20 fast problemlos.
Die Konsole liefert heute beim Update einer 4.5.10:

Code:

---

www.?????.de> /opt/RZphp72/bin/php-cli composer.phar update -o
sh: sudo: not found
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 7 updates, 0 removals
  - Updating contao/manager-plugin (2.3.1 => 2.4.0): Loading from cache
  - Updating contao-components/ace (1.2.9 => 1.3.3): Loading from cache
  - Updating contao-components/colorbox (1.6.4 => 1.6.4.1): Loading from cache
  - Updating contao-components/dropzone (5.1.1 => 5.3.1): Downloading (100%)
  - Updating contao-components/mediaelement (4.2.7 => 4.2.9): Loading from cache
  - Updating swiftmailer/swiftmailer (v6.0.2 => v6.1.1): Downloading (100%)
  - Updating paragonie/random_compat (v2.0.15 => v2.0.17): Loading from cache
Writing lock file
Generating optimized autoload files
contao/manager-plugin: Generating plugin class...
contao/manager-plugin: ...done generating plugin class
ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication

 Added/updated the web/app.php file.
 Added/updated the web/app_dev.php file.

 // Clearing the cache for the prod environment with debug
 // false


 [OK] Cache for the "prod" environment (debug=false) was successfully cleared.



 // Warming up the cache for the prod environment with debug
 // false


 [OK] Cache for the "prod" environment (debug=false) was successfully warmed.



 Trying to install assets as relative symbolic links.

 --- ------------------------------- ------------------
      Bundle                          Method / Error
 --- ------------------------------- ------------------
  ?  ContaoCoreBundle                relative symlink
  ?  ContaoFaqBundle                relative symlink
  ?  ContaoNewsBundle                relative symlink
  ?  ContaoNewsletterBundle          relative symlink
  ?  RockSolidColumnsBundle          relative symlink
  ?  RockSolidCustomElementsBundle  relative symlink
  ?  RockSolidFrontendHelperBundle  relative symlink
  ?  RockSolidIconPickerBundle      relative symlink
  ?  RockSolidMegaMenuBundle        relative symlink
  ?  RockSolidSliderBundle          relative symlink
  ?  RockSolidThemeAssistantBundle  relative symlink
  ?  ContaoCalendarBundle            relative symlink
  ?  ContaoCommentsBundle            relative symlink
 --- ------------------------------- ------------------


 [OK] All assets were successfully installed.



 --- ------------------------- -----------------------------------------------------------------
      Symlink                  Target / Error
 --- ------------------------- -----------------------------------------------------------------
  ?  web/files/demo            files/demo
  ?  web/files/tao            files/tao
  ?  system/themes/flexible    vendor/contao/core-bundle/src/Resources/contao/themes/flexible
  ?  web/assets                assets
  ?  web/system/themes        system/themes
  ?  system/logs              var/logs
  ?  system/config/tcpdf.php  vendor/contao/core-bundle/src/Resources/contao/config/tcpdf.php
 --- ------------------------- -----------------------------------------------------------------

---

Ich denke und hoffe, dass die Ausgabe so i.O. ist.Vielleicht kann das ein Experte bestätigen, ich weiß nämlich nicht, was genau die Konsole wiedergeben sollte.
Frontend ist auch völlig i.O., Bilder sind auch sichtbar.

Der Contao-Check 12.0 liefert alles grün bis auf die letzte Abfrage:
File locks
A file lock could not be established.
PHP was unable to get a file lock on an existing file. Please contact your server administrator.

Was das zu bedeuten hat, weiß ich nicht.

Als ein Problem stelle ich bisher nur fest, dass wenn ich kurze Zeit danach nochmal composer.phar install oder composer.phar update starte, kommt nach der Zeile

Code:

---

> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication

---

der bekannte oft zitierte Fehlerabbruch

Code:

---

The command is already running in another process.

---

Allerdings spätestens am nächsten Tag funktioniert es genau wieder ein Mal. Irgendwie muss man immer bestimmte Zeit warten, bis irgendwas den Prozess nicht mehr blockiert? Nach welcher Zeit man das Update/Install wiederholt fehlerfrei machen kann, habe ich noch nicht herausbekommen. Immer eine bestimmte Zeit zu warten wäre auf Dauer natürlich blöd. Dieses seltsame Verhalten trifft für 4.4.x und 4.5.x zu.
Mit dem vermuteten nichtbeschreibbaren temp-Verzeichnis dürfte es ja wohl nicht zu tun haben, denn der Check wirft keinen Fehler dazu aus?
Im Backend kann man die Symlinks genauso nur einmal erneuern, sonst gibt der System-Log eine Meldung, dass die Symlinks nicht generiert wurden.
Vielleicht kann jemand dieses seltsame Verhalten auch bestätigen. Ich kann mir nicht vorstellen, dass es -zig unterschiedliche Power Web Basic Pakete geben sollte, bei den einen funktioniert es und bei anderen nicht.

Fazit: Ich habe es noch nicht aufgegeben und hoffe dass man auch bald das Kommando composer install oder update wiederholt ausführen kann. Ich könnte ein Ticket auf Github schreiben, bin mir aber nicht sicher, ob das ein Conto-Fehler ist, oder wird da irgendein Prozess nicht richtig sauber beendet?
Deshalb ermutige ich @Dublay, warum sollte es bei dir nicht auch funktionieren?

Ich bestätige. Sudo-Fehler, keine Symlinks usw.
Es gibt dazu einen ähnlichen Thread speziell zu Contao 4 und Strato, wo ich das genauer dokumentiert habe.

Gesendet von meinem L52 mit Tapatalk

Zitat:

---

Zitat von VGT

Der Contao-Check 12.0 liefert alles grün bis auf die letzte Abfrage:
File locks
A file lock could not be established.
PHP was unable to get a file lock on an existing file. Please contact your server administrator.

Was das zu bedeuten hat, weiß ich nicht.

Als ein Problem stelle ich bisher nur fest, dass wenn ich kurze Zeit danach nochmal composer.phar install oder composer.phar update starte, kommt nach der Zeile

Code:

---

> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication

---

der bekannte oft zitierte Fehlerabbruch

Code:

---

The command is already running in another process.

---

Allerdings spätestens am nächsten Tag funktioniert es genau wieder ein Mal. Irgendwie muss man immer bestimmte Zeit warten, bis irgendwas den Prozess nicht mehr blockiert? Nach welcher Zeit man das Update/Install wiederholt fehlerfrei machen kann, habe ich noch nicht herausbekommen. Immer eine bestimmte Zeit zu warten wäre auf Dauer natürlich blöd. Dieses seltsame Verhalten trifft für 4.4.x und 4.5.x zu.
Mit dem vermuteten nichtbeschreibbaren temp-Verzeichnis dürfte es ja wohl nicht zu tun haben, denn der Check wirft keinen Fehler dazu aus?
Im Backend kann man die Symlinks genauso nur einmal erneuern, sonst gibt der System-Log eine Meldung, dass die Symlinks nicht generiert wurden.
Vielleicht kann jemand dieses seltsame Verhalten auch bestätigen. Ich kann mir nicht vorstellen, dass es -zig unterschiedliche Power Web Basic Pakete geben sollte, bei den einen funktioniert es und bei anderen nicht.

Fazit: Ich habe es noch nicht aufgegeben und hoffe dass man auch bald das Kommando composer install oder update wiederholt ausführen kann. Ich könnte ein Ticket auf Github schreiben, bin mir aber nicht sicher, ob das ein Conto-Fehler ist, oder wird da irgendein Prozess nicht richtig sauber beendet?
Deshalb ermutige ich @Dublay, warum sollte es bei dir nicht auch funktionieren?

---

Da muss ich den Contao Check nochmals aktualisieren. Ab Symfony 3.4.12 tritt dieser Fehler nicht mehr auf. Siehe https://github.com/symfony/symfony/pull/27668

Um sicherzustellen, dass du Symfony 3.4.12 bekommst, trage folgendes als conflict in deiner composer.json ein:

Code:

---

"symfony/lock": "<3.4.12"

---

Führe dann erneut ein composer update durch.

// Contao Check wurde aktualisiert.

@Spooky, danke für die Hilfe:
- Der Check läuft jetzt fehlerfrei durch und zeigt alles grün an
- Symfony 3.4.12. ist definitv da, steht auch in der /symfony/changelog-3.4.md; hatte auch zusätzlich deinen Eintrag in der composer.json gemacht
- trotzdem tritt der Fehler in 4.4.20 und 4.5.10 beim Update "The command is already running in another process." erneut auf, es ging zwar beim ersten Durchlauf alles gut (weil wahrscheinlich wieder genug Zeit dazwischen war seit gestern Abend), aber ein kurz danach angeschobenes install oder update bringt die Fehlermeldung.

Im Prinzip kann ich damit leben, zwischen den Updates einen halben Tag Zeit zu lasen ..... ? :D Ist im Moment 'eh nur Testversion

Hm, tja komisch, da ist dann anscheinend noch ein Problem versteckt bei Strato.

Danke, ja scheinbar wird da irgendetwas nicht sauber beendet und blokiert die Symlinks anzulegen und wird erst nach einiger Zeit beendet ... Befehl 'kill' kann ich sicherlich als Normaluser nicht anwenden, wüsste auch nicht worauf ... ; ich bleibe weiterhin neugierig

Gut möglich dass gar nichts mehr läuft und stattdessen einfach irgendwelche json-Dateien nicht gelöscht wurden im contao-manager Ordner, weil der Prozess beim letzten Aufruf nicht ordnungsgemäß fertiggelaufen ist. Würde ich mal versuchen zu löschen (background-process.* tenside-tasks.*) Vielleicht läuft es dann wieder.

bei der 4.5.10-Installation hatte ich solche Dateien background-process.* und tenside-tasks.* drin; habe ich gelöscht; bei der 4.4.20 war nichts davon;
hilft aber auch nichts, kommt nach wie vor noch "The command is already running in another process." Wenn ich wieder bis morgen früh warte, dann läuft Update bzw. Install wieder sauber durch bis zum Ende ..., aber wie geschrieben immer nur 1x und dann heißt es wieder einige Stunden warten

Neuer PR für dieses Problem: https://github.com/symfony/symfony/pull/27903

Die dortige Änderung könntest du manuell bei dir einspielen. Danach musst du aber warten, bis dass der Hoster wieder das Temp Verzeichnis geleert hat.

@spooky, danke für die Mühe; eben deinen Thread erst gelesen;
wenn ich das richtig verstanden habe: ich habe in der /LockHandler.php den chmod von 0444 auf 0644 geändert
mal sehen was sich morgen tut - ich werde berichten

Nachtrag: soeben mal auf blauen Dunst auf der Konsole getestet: die 4.4.20 lief jetzt 2x mit composer install und danach mit composer update bis zum Ende durch; die 4.5.10 hat noch abgebrochen mit der Fehlermeldung; also ich warte mal bis morgen

Mit der chmod-Änderung in /LockHandler.php gibt es in der Contao 4.4.20 keine Fehler weder auf der Konsole noch mit Manager, Caches gelöscht, Datenbank aktualisiert; composer install und update laufen mit mehrfacher Wiederholung völlig bis zum Ende durch! Das hört sich sehr gut an. :)

Die Contao 4.5.10 zeigt jedoch bereits während der ersten Wiederholung von composer install oder composer update immer noch diesen Abbruch auf Konsole und im Manager:

Code:

---

> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
The command is already running in another process.
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-install-cmd event terminated with an exception

In ScriptHandler.php line 95:
                                                                         
  An error occurred while executing the "contao:install-web-dir" command: 
  install

---

Ich lese gerade (oberer Link von @spooky) , dass chmod 0666 empfohlen wird - werde ich auch mal testen.

Welche Dateien hast du überhaupt geändert? Du musst verschiedene Dateien ändern je nach Contao Version.

Contao 4.4: https://github.com/symfony/symfony/pull/27904
Contao 4.5: https://github.com/symfony/symfony/pull/27903

Zitat:

---

Zitat von Spooky

Welche Dateien hast du überhaupt geändert? Du musst verschiedene Dateien ändern je nach Contao Version.

Contao 4.4: https://github.com/symfony/symfony/pull/27904
Contao 4.5: https://github.com/symfony/symfony/pull/27903

---

oh, ja ich Dussel ... glatt übersehen, dass es unterschiedliche Dateien sind

4.4 symfony/ src/Symfony/Component/Filesystem/LockHandler.php geändert auf chmod 0644
4.5 symfony/src/Symfony/Component/Lock/Store/FlockStore.php geändert auf chmod 0666

Hallo @Spooky, das war die Lösung, in beiden Dateien chmod geändert und bisher auf Konsole, mit Manager und im Backend keine Fehlermeldungen mehr auch nach mehrmaligem Aktualisieren - hoffentlich bleibt es so --> Tausend Dank

Hallo zusammen,

hab bei Strato das gleiche Problem mit meiner Contao 4.4.20 Installation. Heißt: Das erste composer update ging problemlos durch, das composer require danach scheitert mit der Meldung "The command is already running in another process.". Seit dem jedes composer update ebenso.

Ich habe den Fix mit dem chmod wie hier auf 0644 gesetzt. Die geänderte Datei sitzt unter vendor/symfony/symfony/src/Symfony/Component/Filesystem/LockHandler.php oder hab ich die falsche bearbeitet?

Diverse Caches geleert, aber es ändert sich nichts. Gibt es einen speziellen der dafür geleert werden muss?

Muss ich jetzt est mal wie VGT erwähnt hat bis morgen warten?

LG
Nicole

Ändere es mal auf 0666.

Auf 666 geändert, gespeichert, composer update ausgeführt, an error occured...

Ich hab jetzt mal etwas required, selber Fehler. Aber anscheinend lassen sich Erweiterungen installieren, Contao Manager lässt sich aufrufen, Backend auch... Kann ich den Fehler ignorieren? Wollte heute mit dem Theme anfangen, daher ist im Frontend noch nichts los.

Ich poste mal die letzte Ausgabe:

Code:

---

bash-4.2$ php contao-manager.phar.php composer require jrgregory/m17-sticky-backend-footer
sh: sudo: not found
Using version ^2.0 for jrgregory/m17-sticky-backend-footer
/mnt/web321/a2/38/59143338/htdocs/contao/composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing contao-community-alliance/composer-plugin (3.0.8): Downloading (100%)       
  - Installing jrgregory/m17-sticky-backend-footer (2.0.9): Downloading (100%)       
Writing lock file
Generating autoload files
contao/manager-plugin: Generating plugin class...
contao/manager-plugin: ...done generating plugin class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
The command is already running in another process.
X-Powered-By: PHP/7.1.19
Content-type: text/html; charset=UTF-8

Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception

In ScriptHandler.php line 113:
                                                                         
  An error occurred while executing the "contao:install-web-dir" command: 
                                                                         

require [--dev] [--prefer-source] [--prefer-dist] [--no-progress] [--no-suggest] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--update-with-all-dependencies] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--] [<packages>]...

X-Powered-By: PHP/7.1.19
Content-type: text/html; charset=UTF-8

---

Der korrekte Pfad zum PHP CLI lautet

Code:

---

/opt/RZphp{major}{minor}/bin/php-cli

---

{major} und {minor} musst du mit der passenden PHP Version ersetzen. Du hattest einfach nur "php" benutzt.

Zitat:

---

Zitat von Spooky

Der korrekte Pfad zum PHP CLI lautet

Code:

---

/opt/RZphp{major}{minor}/bin/php-cli

---

{major} und {minor} musst du mit der passenden PHP Version ersetzen. Du hattest einfach nur "php" benutzt.

---

Ja, hab ich bisher immer sofern es funktioniert hat. Nur wenn die eingestellte PHP-Version nicht gepasst hat, hab ich den Pfad direkt angegeben. Ist es besser den Pfad einfach immer anzugeben?

Leider ändert sich auch mit der cli-Version von PHP 7.2 nichts.

Code:

---

bash-4.2$ /opt/RZphp72/bin/php-cli contao-manager.phar.php composer update
sh: sudo: not found
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
contao/manager-plugin: Generating plugin class...
contao/manager-plugin: ...done generating plugin class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
The command is already running in another process.
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception

In ScriptHandler.php line 113:
                                                                         
  An error occurred while executing the "contao:install-web-dir" command: 
                                                                         

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

---

Zitat:

---

Zitat von Webstylerin

Ist es besser den Pfad einfach immer anzugeben?

---

Solltest du immer machen, ja. Und auch immer die richtige PHP Version verwenden.

Zum Fehler: evt. musst du 24 Stunden warten.

Zitat:

---

Zitat von Webstylerin

Ja, hab ich bisher immer sofern es funktioniert hat.

---

also bei mir läuft sowohl update als auch install jetzt völlig sauber durch, warten musste ich keine Zeit, es ging bei mir sofort nach der chmod-Umstellung.
Starten tue ich auf der Konsole

Code:

---

/opt/RZphp72/bin/php-cli composer.phar update -o
oder
/opt/RZphp72/bin/php-cli composer.phar install

---

stimmen da bei Dir die php-Versionen nicht? Ich lese bei Dir PHP/7.1.19 und RZphp72. Ich habe im Strato Kunden-Login php 7.2 eingestellt. Die Einstellung greift dann auf den gesamten Webspace. Stell doch erst mal global auf 7.2 ein.
Unterschiedliche php-Versionen kann man bei Strato nicht im Kunden-Login umstellen sondern da gibt es eine Anleitung über die .htaccess-Datei. Und wir reden hier tatsächlich bei Dir auch vom Paket "PowerWeb Basic" ?

Hallo VGT,

vielen Dank für deine Antwort.

Zeit heilt sicher nicht alle Wunden, diese hier aber schon. :D Hab gerade noch mal getestet und das composer update läuft jetzt fehlerfrei durch.

Habe zwischenzeitlich auch die PHP-Version der Webseite auf 7.2 gestellt und ja, auch hier handelt es sich um PowerWeb Basic von Strato.

Werde Bessererung geloben und ab jetzt immer den PHP-Pfad angeben und auf gleiche Versionen achten. :)

LG
Nicole

Ich nehme das Thema hier nochmal auf, da ich gerade vor dem gleichen Problem stehe.

Installiert ist Contao 4.4.20 in einem Strato PowerWeb Plus mit globaler PHP7.2-Einstellung.
Die Installation gelang ohne Probleme mit dem Contao-Manager. Allerdings bekomme ich jetzt im laufenden Betrieb beim Installieren/Deinstallieren von Erweiterungen die bereits bekannte Ausgabe (hier am Beispiel der Deinstallation einer Erweiterung):

Code:

---

Installing dependencies from lock file
Package operations: 0 installs, 0 updates, 1 removal
  - Removing jrgregory/m17-sticky-backend-footer (2.0.9)
Generating optimized autoload files
contao/manager-plugin: Generating plugin class...
contao/manager-plugin: ...done generating plugin class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
The command is already running in another process.
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-install-cmd event terminated with an exception

In ScriptHandler.php line 113:
                                                                         
  An error occurred while executing the "contao:install-web-dir" command: 
                                                                         

install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...


# Process terminated with exit code 1
# Result: General error

---

Ich habe dann den PHP-Pfad für den Contao-Manager von der Voreinstellung „Strato AG“ manuell auf /opt/RZphp72/bin/php-cli umgestellt, außerdem wie hier im Thread beschrieben auch die Dateirechte der LockHandler-Datei (symfony/src/Symfony/Component/Filesystem/LockHandler.php) auf 666 gestellt.
Und zum guten Abschluss habe ich in der /web/app.php die Pfade fürs /tmp-Verzeichnis vorgegeben (Pfad ist hier anonymisiert):

Code:

---

putenv('TMP=/home/strato/www/do/www.domain.de/htdocs/contao/system/tmp');
putenv('TEMP=/home/strato/www/do/www.domain.de/htdocs/contao/system/tmp');
putenv('TMPDIR=/home/strato/www/do/www.domain.de/htdocs/contao/system/tmp');

---

Leider lande ich wieder im gleichen Fehler. Und z. B. Symlinks neu generieren landet als Fehler im Contao-Log.

Hat noch jemand eine Idee?
Konsolenzugriff ist möglich, hier fehlt mir aber schlichtweg das Wissen bzgl. möglicher Befehle.

Warte eine Stunde. Symonfy 3.4.13 wird vermutlich heute released. Führe dann nochmal ein composer update aus (stelle sicher, dass auf Symfony 3.4.13 aktualisiert wurde). Danach musst du evt. nochmal 24 Stunden warten. Dann sollte es funktionieren.

OK, dann warte ich mal.
Aber kann ich denn überhaupt was neues installieren, wenn ich momentan in den Fehler laufe?

Ein composer update auf der Konsole läuft ja auch in den Fehler.

Code:

---

/opt/RZphp72/bin/php-cli contao-manager.phar.php composer update

sh: sudo: not found
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
contao/manager-plugin: Generating plugin class...
contao/manager-plugin: ...done generating plugin class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
The command is already running in another process.
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception

In ScriptHandler.php line 113:

  An error occurred while executing the "contao:install-web-dir" command:


update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

---

Der Fehler passiert bei den post-update-cmd Events. Also nachdem die composer update Operation bereits erfolgreich durchgelaufen ist.

Ok, danke. Das klingt logisch :rolleyes:

Wenn das Symfony-Update durch ist, bleiben dann die CHMOD-Rechte der LockHandler-Datei auf 666 oder kann ich das wider zurückstellen?
Und was ist mit den tmp-Pfaden in der app.php?
Sorry, dass ich so genau nachfrage, aber ich möchte jetzt nicht irgendwas unnötigerweise erhalten, was von der Norm abweicht, und dann fliegt es mir vielleicht in 2-3 Monaten um die Ohren – warum auch immer.

Zitat:

---

Zitat von JamesdK

Wenn das Symfony-Update durch ist, bleiben dann die CHMOD-Rechte der LockHandler-Datei auf 666 oder kann ich das wider zurückstellen?

---

Du meinst 0444. Ja, die bleiben auf 0444, daher musst du auch warten, bis der Hoster auf seinem Server die temporären Dateien wieder gelöscht hat.

Zitat:

---

Zitat von JamesdK

Und was ist mit den tmp-Pfaden in der app.php?

---

Da brauchst du nichts machen ;).

Nein, ich meine Rechte 0666. Das habe ich aufgrund dieses Postings und deiner folgenden Antwort darauf gemacht.

EDIT: wahrscheinlich erledigt sich das durch das Symfony-Update von selbst, oder?

Die 0666 Rechte hat die Datei erst, nachdem du auf Symfony 3.4.13 aktualisiert hast und dann auch erst dann, wenn die Datei neu angelegt wird.

Spooky, nach dem Symfony Update auf die 3.4.13 läuft alles jetzt wunderbar durch und ich kann neue Erweiterungen ohne Fehlermeldung installieren.
Danke!

Nach dem Update von
- Updating contao-components/installer (1.2.7 => 1.3.0): Downloading (100%)
- Updating symfony/symfony (v3.4.12 => v3.4.13): Downloading (100%)
- Updating contao/manager-plugin (2.4.1 => 2.5.0): Downloading (100%)

gib es nur beim Composer install folgende Warnmeldung, mit der nichts anfangen kann.
Composer version 1.6.5 2018-05-04 11:44:59

Code:

---

/opt/RZphp72/bin/php-cli composer.phar install
Using config.component-dir has been deprecated. Please use extra.contao-component-dir instead.
...

---

Der Installer läuft aber trotzdem fehlerfrei weiter durch bis zum Ende.
Composer update zeigt diese Meldung nicht.
Muss man da irgendwo was aktualisieren?

Nein, das ist nur eine deprecation Meldung, kein Fehler.

https://github.com/contao/managed-edition/issues/37