Hat jemand Erfahrungen mit Contao 4.4.x und dem 1&1 Paket Unlimited Pro?
Contao Manager oder Konsole ist egal - nur eins davon muss funktionieren ;-).
Druckbare Version
Hat jemand Erfahrungen mit Contao 4.4.x und dem 1&1 Paket Unlimited Pro?
Contao Manager oder Konsole ist egal - nur eins davon muss funktionieren ;-).
Mit composer install (bzw. der selben Funktion im Contao Manager) funktioniert Contao 4 in jedem 1&1 Paket ;) (außer das Paket ist generell zu alt und erfüllt nicht die prinzipiellen Systemvoraussetzungen). Composer update direkt am Server funktioniert bei Unlimited Pro nicht, soweit ich getestet habe.
Composer update direkt am Server meinte nicht mal via Konsole? Weia :DZitat:
Zitat von Spooky
Leider nicht:Allerdings habe ich gerade gesehen, dass das ein Unlimited Paket ist, kein Unlimited Pro.Code:/usr/bin/php7.1-cli composer.phar update -o --profile
[7.6MB/0.01s] Loading composer repositories with package information
[7.9MB/0.09s] Updating dependencies (including require-dev)
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
Fatal error: Out of memory (allocated 586162176) (tried to allocate 67108872 bytes) in phar:///homepages/17/d532812321/htdocs/WEST.new/composer.phar/src/Composer/DependencyResolver/RuleSet.php on line 83
Danke dir Spooky. Ob das Pro dann diesbezüglich noch mehr RAM in der PHP.INI zulässt und dann tatsächlich auch zur Verfügung stellt, bleibt dann zu testen…
Dann eben runter laden, lokal updaten und wieder zurückspielen (composer.json und composer.lock).
Kunde hat ein 2007er Vertrag und würde auf Pro wechseln, da mehr Leistung für weniger/gleiches Geld. Und da da Outlook-Sycronisation etc. läuft…
Die php.ini hat darauf sowieso keinen Einfluss ;).
Ja wie gesagt, prinzipiell läuft Contao 4 problemlos. Man muss Updates halt lokal machen und dann die composer.json und .lock deployen und ein composer install ausführen (kann man auch über den Contao Manager anstoßen). Vorteil davon ist auch, dass die Downtime während eines Updates (je nach Situation) maßgeblich kürzer ist.
Das noch gefunden:
https://hilfe-center.1und1.de/hostin...a10796053.html
Aber diese …bis zu - Beschreibungen.
Danke dir Spooky. Dann hab ich genug Input dazu.
Wie meinst du das mit der Outlook-Synchronisation? Bucht er das dann zusätzlich dazu? Im Hosting selbst dürfte dazu nichts enthalten sein.Zitat:
Zitat von planepix
Ich denke er meint den Exchange Server.
Ja, denke ich auch. Aber das ist doch kein Bestandteiil des Unlimited Pro?!?:confused: Klar, den gibts natürlich bei 1&1. Aber muss ja jetzt mit dem Webspace nicht unbedingt was zu tun haben.
Ja ich denke das meint der Kunde auch mit Outlook-Sync :D.
Das haben sie und nun wäre die eine Idee gewesen, z. B. bei allinkl ein Hosting zu buchen, da Contao 4 laufen lassen und via DNS-Umleitung das 1&1 Paket weiter laufen zu lassen… Wenns nun nur das Deployment ist (also mein Part, dann können sie da gerne bleiben :D )
Ja hier *handheb*Zitat:
Zitat von planepix
Konnte C4.4 Managed ohne Probleme installieren, ebenso vier oder fünf Erweiterungen mit dem Manager. Irgendwann wurden wohl die Abhängigkeiten bzw. die Auflösungen zu umfangreich und es gab ‘n out of memory.
Seither mache ich die Auflösung lokal wie Spooky unter #6 beschrieb, alles bestens.
Gesendet von iPhone mit Tapatalk Pro
Ich mache das genauso, sogar auf dem kleineren UNLIMITED PLUS Paket - bisher keine Probleme .
Selbst auf den Dedicated Servern mit 8 GB Ram läuft der Composer nicht durch. (out of memory)
Auf unserem Hostingwerk vServer mit ebenfalls 8 GB Ram läuft hingegen alles einwandfrei durch. Ich bin bedient - zumal der Server nicht viel schneller ist. :(
Moin,
ich konnte Contao in einem UNLIMITED PLUS Packet über den Contao Manager installieren.
Da ich beim installieren von mehren Erweiterungen das gleiche Problem wie Stefko hatte, habe ich es ebenfalls lokal gelöst.
Schön das es endlich auch bei diesem Provider funktioniert.
Grüße Marco
Hallo zusammen,
habe ebenfalls gerade ein Projekt bei 1und1 am laufen.
Ich verstehe noch nicht ganz wie ihr es schafft, Erweiterungen für Contao 4.x zu installieren. Erweiterungen von Contao 3.5 bekomme ich problemlos drauf. Benötige ich aber nun z.B. die Erweiterung "do-while/contao-backupdb-bundle". Wie bekomme ich die zum laufen? Kann mir jemand helfen?
Danke :)
Lokal installieren, composer.json & composer.lock auf den Server kopieren, composer install am Server ausführen.
Dank dir für deine schnelle Antwort. Leider verstehe ich es immer noch nicht.
Was genau muss ich Lokal installieren? Muss ich Contao 4 mit xampp auf meinem Rechner aufsetzen und dort die Erweiterungen installieren? Und bei Rest steig ich auch aus. Ich weiß wie man auf dem Server mit composer.phar und Terminal eine Erweiterung installieren könnte, wenn es dann kein Fehler bezüglich dem Speicher geben würde.
<myWay>
Lokale Entwicklungs-Installation mittels MAMP, XAMP ...
Zum testen, updaten, nix kaputtmachen...
Dort werden Updates gemacht oder auch neue Erweiterungen installiert.
Anschließend werden die composer.json und sie composer.lock auf den "Live-Server" geladen und über die Konsole ein composer install aufgerufen - fertig ist die Laube.
</Sinatra>
Ergänzend, wer nicht alle Quellen liest oder kennt:
Das ist eine Kurzanleitung des Contao Stammtisch Bayern, die gestern veröffentlicht wurde:
https://www.contao-bayern.de/newsrea...l-updaten.html
So nun gehts hier weiter … oder auch nicht.
SSH-Zugang ist da, Unlimited Plus Paket.
Wenn ich mich nun via SSH anmelde und composer installieren will, sagt mir das Ergebnis:
Das ich dann später mitCode:curl -sS https://getcomposer.org/installer | php
X-Powered-By: PHP/4.4.9
Content-type: text/html
<br />
<b>Parse error</b>: syntax error, unexpected T_NEW in <b>-</b> on line <b>510</b><br />
curl: (23) Failed writing body (251 != 16384)
also PHP 7.1 ist eingestellt ->Code:/usr/bin/php{major}.{minor}-cli
aufrufen soll (laut Wiki) ist ok.Code:/usr/bin/php71-cli composer install
Wie komme ich aber nun an den Composer bzw. wie rufe ich es auf, damit ich ich ihn in das Contao Verzeichnis installieren kann?
Ergänzt:
Mit dem Aufruf
kommtCode:curl -sS https://getcomposer.org/installer | /usr/bin/php71-cli
als Ergebnis.Code:-bash: /usr/bin/php71-cli: No such file or directory
curl: (23) Failed writing body (0 != 16133)
Mit Aufruf von
wird mir dies ausgegeben:Code:ls -l /usr/bin/php*
Code:lrwxrwxrwx 4 root root 21 Dec 20 12:39 /usr/bin/php -> ../lib/cgi-bin/php4.4-rwxr-xr-x 8 root root 1045 Dec 20 12:39 /usr/bin/php-config4.4
-rwxr-xr-x 8 root root 4420 Feb 1 16:29 /usr/bin/php-config5.2
-rwxr-xr-x 12 root root 3920 Feb 5 15:41 /usr/bin/php-config5.4
-rwxr-xr-x 12 root root 3910 Feb 7 08:28 /usr/bin/php-config5.5
lrwxrwxrwx 4 root root 13 Feb 5 15:41 /usr/bin/php-config6 -> php-config5.4
-rwxr-xr-x 8 root root 3929 Apr 10 13:46 /usr/bin/php-config7.1
lrwxrwxrwx 4 root root 6 Dec 20 12:39 /usr/bin/php4 -> php4.4
lrwxrwxrwx 4 root root 21 Dec 20 12:39 /usr/bin/php4.4 -> ../lib/cgi-bin/php4.4
-rwxr-xr-x 8 root root 4502656 Dec 20 12:39 /usr/bin/php4.4-cli
lrwxrwxrwx 4 root root 6 Feb 1 16:29 /usr/bin/php5 -> php5.2
lrwxrwxrwx 4 root root 21 Feb 1 16:29 /usr/bin/php5.2 -> ../lib/cgi-bin/php5.2
-rwxr-xr-x 8 root root 8307512 Feb 1 16:29 /usr/bin/php5.2-cli
lrwxrwxrwx 4 root root 21 Feb 5 15:41 /usr/bin/php5.4 -> ../lib/cgi-bin/php5.4
-rwxr-xr-x 12 root root 12666480 Feb 5 15:41 /usr/bin/php5.4-cli
lrwxrwxrwx 4 root root 21 Feb 7 08:28 /usr/bin/php5.5 -> ../lib/cgi-bin/php5.5
-rwxr-xr-x 12 root root 13197744 Feb 7 08:28 /usr/bin/php5.5-cli
lrwxrwxrwx 4 root root 21 Feb 5 15:41 /usr/bin/php6 -> ../lib/cgi-bin/php5.4
lrwxrwxrwx 4 root root 21 Apr 10 13:46 /usr/bin/php7.1 -> ../lib/cgi-bin/php7.1
-rwxr-xr-x 8 root root 13890592 Apr 10 13:47 /usr/bin/php7.1-cli
-rwxr-xr-x 8 root root 3989 Dec 20 12:39 /usr/bin/phpize4.4
-rwxr-xr-x 8 root root 4481 Feb 1 16:29 /usr/bin/phpize5.2
-rwxr-xr-x 12 root root 4495 Feb 5 15:41 /usr/bin/phpize5.4
-rwxr-xr-x 12 root root 4495 Feb 7 08:28 /usr/bin/phpize5.5
lrwxrwxrwx 4 root root 9 Feb 5 15:41 /usr/bin/phpize6 -> phpize5.4
-rwxr-xr-x 8 root root 4520 Apr 10 13:46 /usr/bin/phpize7.1
Ich habe einfach die composer.phar ins root Verzeichnis kopiert und dann peraufgerufen. Composer global installieren ging auch nicht.PHP-Code:/usr/bin/php7.1-cli composer.phar
Ich würde mir das Composer Skript so holen:
Anschließend kannst Du die Composer Kommandos wie folgt aufrufen:Code:wget https://getcomposer.org/download/1.6.4/composer.phar
Code:/usr/bin/php7.1-cli composer.phar install -o
Ins Verzeichnis web? Nicht ins Root? Da liegt die composer.phar z.B. bei allinkl.Zitat:
Zitat von Bennie
Im Root Verzeichnis lässt es sich dann aufrufen.
Prima. Danke. Nun noch gucken wie ich das mit dem install der in der composer.json eingetragenen Bundles hinbekomme…
Ja sorry , logisch ins root
habs oben geändert ;):o
da liefert mir die Konsole dann das als Output:Zitat:
Zitat von xchs
Code:-bash: /usr/bin/php71-cli: No such file or directory
Hatte xchs ja schon geschrieben, wenn Du Deine composer.json und composer.lock lokal oder auf einem anderen Server erstellt hastZitat:
Prima. Danke. Nun noch gucken wie ich das mit dem install der in der composer.json eingetragenen Bundles hinbekomme…
ausführenPHP-Code:/usr/bin/php71-cli composer.phar install -o
Oh, sorry, Du hattest oben ja die Verzeichnisauflistung gepostet, da fehlte offenbar ein Punkt in der Versionsangabe: Versuch es mal mit
bzw.Code:/usr/bin/php7.1-cli -v
Im Wiki steht's ja auch richtig: https://github.com/contao/contao-manager/wiki/1und1 :)Code:/usr/bin/php7.1-cli composer.phar
Jupp, die habe ich von einem anderer Server nun in das Root bei 1und1 gelegt.
Und dann den Konsolenbefehl von xchs eingegeben. Wird dann quittiert mit
Code:-bash: /usr/bin/php71-cli: No such file or directory
Prima. Danke euch. Der Punk(t) hat gefehlt.
Hier fehlt Dir ein Punkt. Es ist php7.1-cli (siehe auch Dein Listing mitZitat:
Zitat von planepix
Edit: zu langsam :-(Code:ls -l /usr/bin/php*
Ich hab da noch eine Frage zum Seitenaufruf bei 1und1 in einem Unlimited Plus Paket.
Wenn ich eine Contao-Seite zum ersten Mal aufrufe dauert es bis zu 8 Sekunden bis die Seite erscheint.
Jeder weitere Aufruf klappt "sofort".
Annahme dazu ist, dass der Apache einen DNS Lookup auf die IP-Adresse macht um den Hostnamen bereitzustellen.Da die IP-/Nameserverauflösung nach dem ersten Aufruf bekannt ist und eine gewisse Zeit gespeichert bleibt dauert der zweite und weitere Aufrufe nicht mehr so lang.
Wenn ich dann später (nach ein paar Stunden) die Seite nochmals aufrufe dauert das erste Mal wieder so lang.
Kann das jemand bestätigen?
Ok das klappt jetzt.
Und jetzt habe ich die Installation unter PHP 7.2.1 erstellt, am Live Server nur PHP 7.1.
Also trage ich in die lokale composer.json bei config noch platform: php 7.1 ein? (in der richtigen Schreibweise natürlich )
Genau.
Code:"platform": {
"php": "7.1"
}
Danke euch. Schlimm wenn bei mit 90% Kunden bei allinkl ist :D
Na dann schau doch mal ob die Seite auch so lange braucht beim ersten Laden ...
Mach ich dann gerne Bennie.
Im Moment ist das noch Trockenübung… die gesamte Installation zieh ich dann noch um. Ich wollte jetzt erst mal das Prozedere bei 1und1 verstehen ;).
Das klingt doch eigentlich nach einer Cache-Geschichte. Beim ersten Aufruf oder wenn die Cachezeit abgelaufen ist dauert es lang. Ansonsten kommt die Seite relativ schnell, weil sie ja nicht komplett neu erzeugt wird. Ein DNS-Lookup der 8 Sekunden dauert, das traue ich nicht mal 1&1 zu. ;) 8 Sekunden für den Seitenaufbau sind aber auch nicht gerade sportlich. Kommt aber natürlich auch auf die Seite an.Zitat:
Zitat von Bennie
Es könnte aber auch am PHP-Ausführungsmodus liegen. Wenn PHP als CGI ausgeführt wird, dann kann der erste Aufruf schon mal deutlich länger dauern, als alle folgenden Requests, zumal der PHP Interpreter eventuell erst neu gestartet werden muss. PHP sollte daher vorzugsweise als PHP-FPM ausgeführt werden. Überprüfen kann man das bequem mittels PHP Info.
An den Cache hatte ich auch gedacht als erstes. Aber ich hatte den Servercache schon auf Maximum gestellt, geändert hatte das nichts.
Da sehe ich nichts was man im Kundencenter umstellen könnte…
Vielleicht kann man das auch nicht (selbst) umstellen bzw. PHP läuft schon als FPM. Am besten Du schaust Dir mal die PHP Info Ausgabe an.
Ja, wenn es sich um eine halbe oder meinetwegen eine Sekunde handeln würde, dann wäre das denkbar. Aber 8 (acht!) Sekunden? Ich war lange Zeit bei 1 und 1 und habe immer noch Kunden da. Eine solche Startzeit hatte ich noch nie.Zitat:
Zitat von xchs
Ist das eventuell eine aufwändige Seite, die teilweise oder komplett aus geschützen Inhalten besteht, sich also ändert, je nachdem ob ein Mitglied angemeldet ist oder nicht? In dem Fall bringt der Cache wohl nichts.
Je nach Umfang und Anzahl der Quelldateien kann manchmal auch das Parsen von SCSS Code etwas länger dauern, wenn beispielsweise erst die zusammengefassten CSS-Stylesheets generiert werden müssen.
Daran kann es nach meinen Tests eigentlich nicht liegen. Die Seite ist nicht komplex, ich habe mal testweise css und js rausgenommen - ändert nichts.
Ich kann hier leider keinen Link posten, die Seite ist noch unter einer Subdomain mit Zugangsschutz und mit Bildern bestückt die noch nicht freigegeben sind.
Ich erinnere mich aber, dass das schon nach der Installation von Contao 4 so war als ich lediglich ein paar Seiten angelegt hatte ohne CSS und JS.
Definiere "zum ersten Mal" genauer. Zum ersten Mal einer Session? Das heißt wenn du den Browser schließt, wieder öffnest und dann eine beliebige Seite der Website öffnest, dauert es 8 Sekunden?
Nein dann genau nicht. Wenn ich den Browser schließe (Cache wird gelöscht) dann wieder öffne, die Seite aufrufe ist sie sofort da.
Öffne ich sie dann später, da weiß ich noch nicht wie lange später, aber nach einigen Stunden meine ich, tritt es wieder auf .
Deshalb dachte ich auch an den Servercache von Contao es ist aber egal ob der an- oder ausgeschaltet ist.
Deaktiviere mal den Frontend Cron in den System Einstellungen.
Das habe ich probiert, bringt aber anscheinend auch nichts.
Ich teste nochmal ohne Einbindung von css und js etc. , denke aber dass das auch nichts bringen wird. Wie schon erwähnt fiel mir das schon kurz nach der Installation auf. Da war noch nichts eingebunden außer dem Layoutbuilder.
Browse die Website ab sofort nur mit der app_dev.php. Sobald ein Request diese 8 Sekunden gedauert hat öffne den Profiler um vielleicht herauszufinden zu können, woran es liegt.
So weiter gehts mit einer Installation bei Ionos.
Habe die im Threadverlauf angegebenen Konsolenbefehle mal eingetragen.
Frage ich die PHP-Version mit „php -v” ab, wird „php -vPHP 4.4.9 (cgi-fcgi) (built: Nov 7 2018 13:27:00)” ausgegeben.Code:/usr/bin/php7.2-cli composer.phar update
Wie bekomme ich das nun auf PHP 7.2?
Ins Backend kam ich, im Frontend werden alle asset-Inhalte nicht geladen.
Prod Cache ist mehrfach gelöscht.
Ergänzung:
Bilder werden um Backend nicht angezeigt in der Dateiverwaltung - Syncronisierung ist auch ausgeführt.
Ergänzung 2:
Das hier gefunden: https://www.ionos.de/community/hosti...aketen-nutzen/
Mitklappt es in der Konsole. Schaun wir mal wo es nun hängt, da die Installation mit 7.2 erstellt wurde…Code:/usr/bin/php7.1-cli composer.phar update
Mit diesen Kniffen soll man auch PHP 7.2 und 7.3 als cli Version zum Laufen bekommen:
https://www.mister42.me/de/articles/...nd1+Webhosting
Ionisierung kann ja nicht gesund sein für einen Server, oder ist die Cloud des Spezialisten eine Gewitterwolke? :D
Pulverisieren wärs :D.
So nun ist zu wenig Speicher das Thema. Boah eh :)
Manager läuft. Ins Backend komme ich auch. Nur das Frontend sieht zum Heulen aus :).
PHP Info sagt das memory_limit sei bei -1. Eine php.ini hab ich ins Root Verzeichnis gelegt mit 1G. Reicht wohl nicht…
Und das wird es auch bleiben, solange Du nicht einen anderen Provider hast, der deutlich mehr Speicher zur Verfügung stellt.Zitat:
Zitat von planepix
Ich gehe daher den Weg, die composer.json auf meinen lokalen Rechner zu holen, dort composer update aufzurufen (hier hast Du so viel Speicher, wie Du Dir selbst gibst), dann die so erzeugte composer.lock zurück auf den Server und dort composer install aufrufen.
Eine lokale Contao-Installation braucht es dafür nicht!
Bei Bedarf das Ganze für alle 1&1-Domains noch in ein Skript gepackt und so aktualisiert ein Skript-Aufruf alle Contao-Installationen :-)
Was mich jetzt am meisten irritiert: Warum werden die assets nicht geladen? Kein CSS, keine Bilder. Muss bei 1&1 die Dateirechte anpassen?
In den Seitenlayouts Skripte zusammenfassen deaktivieren liefert jetzt immerhin CSS und JS aus…
Nicht, daß ich wüsste. Hast Du mal nachgeschaut, ob der Symlink web/assets (zeigt auf ../assets) angelegt wurde? Vielleicht ist da etwas schief gegangen.Zitat:
Zitat von planepix
Dann schau dir mal den Symlink von web/assets -> assets an, ob der funktioniert.
Im Ordner web/assets ist aktuell nur .gitignore drin.
Im Ordner assets im Root liegen Bilder in den einzelnen Unterordnern.
Die Systemwartung habe ich mehrfach ausgeführt.Im Syslog steht nicht drin dass das erstellen von Symlinks gescheitert sein.
[14.12.2018 20:38] The symlinks could not be regenerated
Kurioserweise werden jetzt viele Bilder angezeigt, einige Fehler und werden auch dann nicht angezeigt, wenn ich diese neu hochlade und syncronisiere.
Ich gucke jetzt nochmal in vars/log:
Die letzten Zeilen:
Code:2018-12-14 19:12:16] request.INFO: Matched route "contao_catch_all". {"route":"contao_catch_all","route_parameters":{"_scope":"frontend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\FrontendController::indexAction","_url_fragment":"assets/css/1bc8a5b6e29e.css","_route":"contao_catch_all"},"request_uri":"http://domain.de/assets/css/1bc8a5b6e29e.css","method":"HEAD"} []
[2018-12-14 19:12:16] security.INFO: Attempting SimplePreAuthentication. {"key":"frontend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-14 19:12:16] request.INFO: Matched route "contao_catch_all". {"route":"contao_catch_all","route_parameters":{"_scope":"frontend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\FrontendController::indexAction","_url_fragment":"assets/css/1bc8a5b6e29e.css","_route":"contao_catch_all"},"request_uri":"http://domain.de/assets/css/1bc8a5b6e29e.css","method":"GET"} []
[2018-12-14 19:12:16] security.INFO: Attempting SimplePreAuthentication. {"key":"frontend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-14 19:12:16] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "Page not found: http://domain.de/assets/css/1bc8a5b6e29e.css" at /homepages/21/d765435206/htdocs/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php line 112 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException(code: 0): Page not found: http://domain.de/assets/css/1bc8a5b6e29e.css at /homepages/21/d765435206/htdocs/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:112, Contao\\CoreBundle\\Exception\\PageNotFoundException(code: 0): Page not found: http://domain.de/assets/css/1bc8a5b6e29e.css at /homepages/21/d765435206/htdocs/vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:64)"} []
[2018-12-14 19:12:16] request.INFO: Matched route "contao_catch_all". {"route":"contao_catch_all","route_parameters":{"_scope":"frontend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\FrontendController::indexAction","_url_fragment":"assets/js/e570d5065622.js","_route":"contao_catch_all"},"request_uri":"http://domain.de/assets/js/e570d5065622.js","method":"HEAD"} []
[2018-12-14 19:12:16] security.INFO: Attempting SimplePreAuthentication. {"key":"frontend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-14 19:12:16] request.INFO: Matched route "contao_catch_all". {"route":"contao_catch_all","route_parameters":{"_scope":"frontend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\FrontendController::indexAction","_url_fragment":"assets/js/e570d5065622.js","_route":"contao_catch_all"},"request_uri":"http://domain.de/assets/js/e570d5065622.js","method":"GET"} []
[2018-12-14 19:12:16] security.INFO: Attempting SimplePreAuthentication. {"key":"frontend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-14 19:12:16] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "Page not found: http://domain.de/assets/js/e570d5065622.js" at /homepages/21/d765435206/htdocs/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php line 112 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\NotFo
So läuft endlich!!!
Manuelles löschen der fehlerhaften Symlinks und noch mal den Composer Installer aufgerufen.
Danke für eure Tipps!
Wenn Du (per SSH eingeloggt) im Ordner web bist, müsste ls -l in etwa so etwas ergeben
das l am Anfang der Ausgabe zeigt, daß assets ein Symlink ist.Code:lrwxrwxrwx 1 u123456789 ftpusers 9 Mar 29 2018 assets -> ../assets
Wenn Dort d (wie directory) steht, ist es ein Verzeichnis.
Lösche es und versuche erneut die Symlinks zu generieren. Ich denke, das ist gescheitert, weil unter dem Namen des zu erzeugenden Symlinks bereits ein Verzeichnis existiert (warum auch immer).
Edit: wie so oft -- zu langsam.
Alle Tipps und geteiltes Know-how ist hilfreich Andreas.
Kann man dann nächstes Mal nutzen ;).
Und in dem Fall geht ja max. PHP 7.1 via Konsole…