Nach Update von 4.7.x auf aktuelle 4.8.4 Bildercache "defekt" --> assets/images/...

Hallo,

ich habe gerade meine Seiten (z. B. www.buntereisebilder) von 4.7.6 auf 4.8.4 geupdatet.

Seitdem werden alle Bilder, die von Contao erzeugt werden (und im Ordner assets/images zu finden sind), nicht angezeigt bzw. nicht erzeugt (mit 4.7.6 war noch alles ok). Die Originalbilder werden korrekt angezeigt (z. B. bei Klick auf Rahmen, wo das Bild sein sollte, erscheint in der Lightbox das Foto.

Die Originalbilder sind alle noch verhanden und werden in der Einzelansicht in der Dateiverwaltung korrekt angezeigt. Allerdings werden auch nicht die kleinen Ansichten im Backend in der Übersicht der Dateiverwaltung angezeigt.

Im Ordner assets/images/ sind zwar einige images enthalten, aber wohl nicht alle (bzw. nicht die richtigen).

Das leeren des Bildercache in der Systemwartung bringt keinen Erfolg. Auch ein erneutes synchronisieren in der Dateiverwaltung nicht.

Es fehlt z. B.:
https://www.buntereisebilder.de/asse...1-20831683.jpg

Das Original ist aber vorhanden (und z.B. per Lightbox richtig verlinkt):
https://www.buntereisebilder.de/file...-144932-01.jpg



Das ganze läuft bei all-inkl.de unter php 7.2.

Hat da jemand eine Idee?

Ab Contao 4.8 kommt Deferred Image Resizing zum Einsatz. Das heißt, das Bild wird erst erzeugt, wenn ein Request auf den assets/images/... Pfad des Bildes gemacht wird.

Vermutlich ist deine Server Konfiguration hier das Problem. Du musst sicherstellen, dass alle Requests, die nicht auf eine physisch vorhandene Ressource gehen, vom PHP Script der Contao Installation verarbeitet wird.

Zitat:

---

Zitat von Spooky

Ab Contao 4.8 kommt Deferred Image Resizing zum Einsatz. Das heißt, das Bild wird erst erzeugt, wenn ein Request auf den assets/images/... Pfad des Bildes gemacht wird.

Vermutlich ist deine Server Konfiguration hier das Problem. Du musst sicherstellen, dass alle Requests, die nicht auf eine physisch vorhandene Ressource gehen, vom PHP Script der Contao Installation verarbeitet wird.

---

Was muss ich dazu tun?

Wenn du Apache hast, reicht die default .htaccess. Ansonsten hängt es von deiner Server Umgebung ab, die wir ja nicht kennen.

Ich hab nochmal genauer geschaut. zumal ich wohl auch falsch geschaut hatte der Filezilla. Ich hatte in den (noch vorhandenen) Ordnern der 3.x-Installation geschaut und nicht im "webc4"-Ordner, wo jetzt die 4er Contaoinstallation hängt.

Die Ordner assets/Images/... sind jetzt leer (hatte ja den Bilderchache gelöscht. Dazu gibt es (mit 4.8?) ein Verzeichnis "assets/images/deferred/...". Dort sind .json Dateien, die den Bildernamen entsprechen. Dort verlinkt scheinen die Originalbilder zu sein, mit Hinweisen zu den gewünschtne Größen.

Sollten diese .json-Dateien eigentlich dafür zuständig sein, dass ein Image erzeugt wird?

Eine .htaccess gibt es nur im Root-Verzeichnis, nicht im web4c-Verzeichnis (in der die 4er Contaoinstallation hängt).

Die .htaccess im web/ Ordner ist gemeint, ja.

Wie gesagt, du musst dafür sorgen, dass alle Requests, die nicht auf eine physisch vorhandene Ressource gehen, von PHP verarbeitet wird.

Zitat:

---

Zitat von Spooky

Die .htaccess im web/ Ordner ist gemeint, ja.

Wie gesagt, du musst dafür sorgen, dass alle Requests, die nicht auf eine physisch vorhandene Ressource gehen, von PHP verarbeitet wird.

---

Im web/ Ordner (also bei mir unter webc4/web/) ist eine .htaccess vorhanden (und war es auch schon vorher).

Vergleiche sie mit dem Original aus contao 4.8. Das hat sich etwas geändert.
Wenn Du in Contao 4.7 keine Anpassungen an der .htacces vorgenommen hast, kannst du einfach das Original aus Contao 4.8 verwenden. Ansonsten musst Du Deine Anpassungen übertragen.

Zitat:

---

Zitat von mlweb

Vergleiche sie mit dem Original aus contao 4.8. Das hat sich etwas geändert.
Wenn Du in Contao 4.7 keine Anpassungen an der .htacces vorgenommen hast, kannst du einfach das Original aus Contao 4.8 verwenden. Ansonsten musst Du Deine Anpassungen übertragen.

---

Eigentlich hätte ich erwartet, dass über das Update auf 4.8.x eine neue .htaccess mit rüber gespielt wird (aber nicht unbedingt ersetzt wird). Nur das scheint nicht der Fall zu sein.
Wie bekomme ich aus der contao-manager.phar die .htaccess extrahiert (bzw. woher bekomme ich die 4.8er .htaccess)?

Einfach die .htaccess löschen und wieder Abhängigkeiten installieren lassen.

Zitat:

---

Zitat von Spooky

Einfach die .htaccess löschen und wieder Abhängigkeiten installieren lassen.

---

Das habe ich getan, bzw. die vorhandene .htaccess umbenannt. Im CM habe ich dann aktualisieren ausgeführt. Eine neue .htaccess wurde installiert. Die Änderungen (mittels Compare von Notepad) sind nicht groß. Aus "app" wurde "index".

Allerdings brachte das nicht den gewünschten Effekt. Weiterhin sind die von Contao erzeugten Images nicht vorhanden, bzw. werden nicht erzeugt. :(

Du solltest vielleicht mal Informationen zu deiner Server Umgebung liefern ;). Mehr können wir dir nicht sagen.

Zitat:

---

Zitat von Spooky

Du solltest vielleicht mal Informationen zu deiner Server Umgebung liefern ;). Mehr können wir dir nicht sagen.

---

Soweit ich weiß, sollte All-Inkl eigentlich unter Apache arbeiten. Die phpinfo per Contao Manager enthält aber keinen Hinweis zu Apache.

Das hier lässt sich erkennen --> Server API FPM/FastCGI

Code:

---

PHP Version 7.2.24-nmm1
System        Linux dd27422 4.4.0-166-generic #195-Ubuntu SMP Tue Oct 1 09:35:25 UTC 2019 x86_64
Build Date        Nov 11 2019 12:05:56
Server API        FPM/FastCGI
Virtual Directory Support        disabled
Configuration File (php.ini) Path        /etc/php72/fpm
Loaded Configuration File        /etc/php72/fpm/php.ini
Scan this dir for additional .ini files        /etc/php72/cgi/conf.d
Additional .ini files parsed        /etc/php72/cgi/conf.d/01_ioncube.ini, /etc/php72/cgi/conf.d/04propro.ini, /etc/php72/cgi/conf.d/04raphf.ini, /etc/php72/cgi/conf.d/05http.ini, /etc/php72/cgi/conf.d/10mysqlnd.ini, /etc/php72/cgi/conf.d/10pdo.ini, /etc/php72/cgi/conf.d/curl.ini, /etc/php72/cgi/conf.d/dba.ini, /etc/php72/cgi/conf.d/fileinfo.ini, /etc/php72/cgi/conf.d/gd.ini, /etc/php72/cgi/conf.d/gender.ini, /etc/php72/cgi/conf.d/gmp.ini, /etc/php72/cgi/conf.d/htscanner.ini, /etc/php72/cgi/conf.d/imagick.ini, /etc/php72/cgi/conf.d/imap.ini, /etc/php72/cgi/conf.d/interbase.ini, /etc/php72/cgi/conf.d/intl.ini, /etc/php72/cgi/conf.d/kas_memory_limit.ini, /etc/php72/cgi/conf.d/ldap.ini, /etc/php72/cgi/conf.d/mailparse.ini, /etc/php72/cgi/conf.d/mongodb.ini, /etc/php72/cgi/conf.d/mysqli.ini, /etc/php72/cgi/conf.d/nmmconfig.ini, /etc/php72/cgi/conf.d/oauth.ini, /etc/php72/cgi/conf.d/odbc.ini, /etc/php72/cgi/conf.d/pdo_dblib.ini, /etc/php72/cgi/conf.d/pdo_firebird.ini, /etc/php72/cgi/conf.d/pdo_mysql.ini, /etc/php72/cgi/conf.d/pdo_odbc.ini, /etc/php72/cgi/conf.d/pdo_pgsql.ini, /etc/php72/cgi/conf.d/pdo_sqlite.ini, /etc/php72/cgi/conf.d/pgsql.ini, /etc/php72/cgi/conf.d/phar.ini, /etc/php72/cgi/conf.d/pspell.ini, /etc/php72/cgi/conf.d/recode.ini, /etc/php72/cgi/conf.d/sodium.ini, /etc/php72/cgi/conf.d/sourceguardian.ini, /etc/php72/cgi/conf.d/sqlite3.ini, /etc/php72/cgi/conf.d/tidy.ini, /etc/php72/cgi/conf.d/xsl.ini
PHP API        20170718
PHP Extension        20170718
Zend Extension        320170718
Zend Extension Build        API320170718,NTS
PHP Extension Build        API20170718,NTS
Debug Build        no
Thread Safety        disabled
Zend Signal Handling        enabled
Zend Memory Manager        enabled
Zend Multibyte Support        provided by mbstring
IPv6 Support        enabled
DTrace Support        disabled
Registered PHP Streams        https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, zip, phar
Registered Stream Socket Transports        tcp, udp, unix, udg, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters        zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, http.*

---

Es könnte zB sein, dass du nginx als Reverse Proxy hast, welcher eigene Regeln für Bild URLs hat. Die kommen dann evt. nie bei PHP an. Das kannst du überprüfen, in dem du die Bild URL eines Bildes, welches nicht funktioniert, direkt im Browser öffnest. Poste mal eine solche URL hier.

// achso, das hast du ja eh schon im ersten Post, hmm.

Zitat:

---

Zitat von Spooky

Es könnte zB sein, dass du nginx als Reverse Proxy hast, welcher eigene Regeln für Bild URLs hat. Die kommen dann evt. nie bei PHP an. Das kannst du überprüfen, in dem du die Bild URL eines Bildes, welches nicht funktioniert, direkt im Browser öffnest. Poste mal eine solche URL hier.

// achso, das hast du ja eh schon im ersten Post, hmm.

---

Wie schon beschrieben, im Verzeichnis "assets/images/..." sind keinerlei Images. Leidiglich der Ordner "assets/images/deferred/..." enthält json-Dateien, die wie die benötigten Bilder benamt sind.

z. B.
/webc4/assets/images/deferred/2/2014-04-26-144932-01-20831683.jpg.json

Code:

---

{"path":"..\/..\/files\/brb\/angeknipst\/tragschrauberflug\/2014-04-26-144932-01.jpg","coordinates":{"size":{"width":260,"height":173},"crop":{"x":0,"y":0,"width":260,"height":173}},"options":{"imagine_options":{"jpeg_quality":80,"jpeg_sampling_factors":[2,1,1],"interlace":"plane","format":"jpg"}}}

---

Ich denke, wenn alles rechtens funktionieren würde, müsste doch im Verzeichnis "assets/images/2/" die erzeugte Bilddatei sein - oder? Ist aber nicht so :(.

Zitat:

---

nginx als Reverse Proxy

---

Das sagt mir leider nichts. In der infophp gibt es dazu keine Hinweise.

Zitat:

---

Zitat von RainerG

Wie schon beschrieben, im Verzeichnis "assets/images/..." sind keinerlei Images.

---

Das ist, wie schon gesagt, normal. Das Bild wird erst von Contao erzeugt, wenn es angefordert wurde. Und dazu muss der Request an das PHP Script weiter gegeben werden, was bei dir aktuell nicht der Fall ist.

Ich vermute, dass All-Inkl vielleicht eine weitere Apache Regel, für URLs die auf Bild-Extensions enden, eingebaut hat.

Hast Du in Deinem Theme in den Bildgrößeneinstellungen die Konvertierung in WebP aktiviert?

Du könntest mal in Deiner config/config.yml einen Bildservice festlegen, z. B.

Code:

---

contao:
    image:
      imagine_service: contao.image.imagine.gd

---

(oder auch eine andere der verfügbaren Optionen, siehe dazu https://docs.contao.org/manual/de/sy...en/#config-yml)

Zitat:

---

Zitat von xchs

Hast Du in Deinem Theme in den Bildgrößeneinstellungen die Konvertierung in WebP aktiviert?

Du könntest mal in Deiner config/config.yml einen Bildservice festlegen, z. B.

Code:

---

contao:
    image:
      imagine_service: contao.image.imagine.gd

---

(oder auch eine andere der verfügbaren Optionen, siehe dazu https://docs.contao.org/manual/de/sy...en/#config-yml)

---

Meintest Du das Verzeichnis app/config/?
Dort gibt es keine config.yml. Allerdings eine parameters.yml

Ich ich habe eine config.yml angelegt und obiges eingetragen. Klappte nicht :(.
In die parameters.yml eingetragen, klappte auch nicht :(.

Sollte das ganze mit dem Update auf 4.8.x nicht automatisch 'konfiguriert' werden? Oder haben nur wenige dieses Problem?

Kann man das "Deferred Image Resizing" ausschalten, so dass alles wieder 'normal' funktioniert?

Hast du All-Inkl schon kontaktiert?

Zitat:

---

Zitat von Spooky

Hast du All-Inkl schon kontaktiert?

---

Nein, noch nicht.

Wobei hier die Frage ist, wonach ich nachhaken sollte.

Du musst nachfragen, warum der Request auf bspw. https://www.buntereisebilder.de/asse...1-20831683.jpg trotz deiner .htaccess nicht vom PHP Script prozessiert wird und statt dessen mit einem 404 des Web Servers beantwortet wird.

Zitat:

---

Zitat von Spooky

Du musst nachfragen, warum der Request auf bspw. https://www.buntereisebilder.de/asse...1-20831683.jpg trotz deiner .htaccess nicht vom PHP Script prozessiert wird und statt dessen mit einem 404 des Web Servers beantwortet wird.

---

Wobei dann die Frage wäre, ob die folgende .htaccess passend ist:

Code:

---

<IfModule mod_rewrite.c>
    RewriteEngine On

    <IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #  following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

---

Ja, die ist passend. Du hast ja bereits bestätigt, dass du die default .htaccess verwendest.

Vielleicht ein (nginx) Proxy, der sich alle Requests auf statische Dateien wie Bilder schnappt und "bearbeitet", in dem Fall des (noch) nicht existierenden Bilds eben mit einem 404?

Zitat:

---

Zitat von tab

Vielleicht ein (nginx) Proxy, der sich alle Requests auf statische Dateien wie Bilder schnappt und "bearbeitet", in dem Fall des (noch) nicht existierenden Bilds eben mit einem 404?

---

Laut dem Response nicht:

Code:

---

HTTP/2.0 404 Not Found
date: Tue, 03 Dec 2019 12:32:41 GMT
server: Apache
content-length: 196
content-type: text/html; charset=iso-8859-1
X-Firefox-Spdy: h2

---

Ah ja, es gibt ja eine URL, dann muss wohl wirklich der Support ran.

Zitat:

---

Vielleicht ein (nginx) Proxy, der sich alle Requests auf statische Dateien wie Bilder schnappt und "bearbeitet", in dem Fall des (noch) nicht existierenden Bilds eben mit einem 404?

---

das war bei mir z.B. der Fall mit den selben Symptomen. Hab den reverse-proxy deaktiviert und lass nun alles vom Apache machen. Bin nicht sehr glücklich damit...

In der Doku sollte denke ich auch eine sichere Basiskonfiguration für nginx mit einfließen..

Erstmal großes DANKE an alle, die mir hier geantwortet haben :-).

Ich habe gerade eine Mail an den All-Inkl-Support geschickt. Mal sehen, ob ich von dort den entscheidenden Hinweis bekomme.

Hier sind doch sicher noch andere mit einer All-Inkl-Domain. Bin ich denn der einzige, der der dieses Problem mit der 4.8er unter All-inkl hat?

Ich habe einige Kunden bei All-Inkl. Aber bisher keine Probleme. Meine Kunden sind allerdings häufig noch auf der aktuellen LTS.
Heute Nachmittag mache ich einen Umzug zu All-Inkl. für einen Kunden. Dort läuft Contao 4.8. Da werde ich explizit auf dieses Thema achten.
Sehe ich es richtig, dass das Problem bei Dir nur bei den Galerien auftritt? Ist da eventuell noch eine Erweiterung am Start?


Edit: Ich habe meinen Umzug abgeschlossen.
Es gibt keinerlei Probleme bei den Bildern. Im Einsatz sind bei meiner Installation nur die Standardgalerien von Contao.

Zitat:

---

Zitat von mlweb

Ich habe einige Kunden bei All-Inkl. Aber bisher keine Probleme. Meine Kunden sind allerdings häufig noch auf der aktuellen LTS.
Heute Nachmittag mache ich einen Umzug zu All-Inkl. für einen Kunden. Dort läuft Contao 4.8. Da werde ich explizit auf dieses Thema achten.
Sehe ich es richtig, dass das Problem bei Dir nur bei den Galerien auftritt? Ist da eventuell noch eine Erweiterung am Start?


Edit: Ich habe meinen Umzug abgeschlossen.
Es gibt keinerlei Probleme bei den Bildern. Im Einsatz sind bei meiner Installation nur die Standardgalerien von Contao.

---

im Prinzip geht es um alle Images die eine Größenänderung erhalten. Das gilt z. B. auch im Backend für die kleinen Abbilder in der Dateiverwaltung.

Bei mir gibt es ganz klar keinerlei Probleme. Weder Backend noch Frontend.

Das Problem ist gelöst.

Ich hatte noch die .htaccess im Root von der 3.xer Version im Root. Nach der Umbenennung, klappt jetzt alles wie gewünscht.

Die Antwort vom All-Inkl-Support kam nach nur knapp über einer Stunde! :-)

Hallo Leute,

ich hänge mich mal hier dazu anstelle neuen Thread zu öffnen.

Ich habe das Problem, dass assets/images/... nicht erstellt werden.

Contao: v4.8.7
PHP: v7.2.10
Provider: Mittwald (Webspace)
Bildbearbeitung: ImageMagick

Contao Manager läuft einwandfrei durch.
Frontend und Backend funktioniert.

Wenn ich die Frontend aufrufe, bekomme ich in der Browser-Console 404 für alle Bilder, die in assets/images/... erzeugt werden. Ebenefalls in Backend werden die Thumbnails im Element und in der Dateisystem nicht angezeigt, weil diese nicht existieren bzw. erzeugt werden können.

Beispielpfad für Thumbnail: b/contentbild-ueber-uns-wiesbaden2-1790b2bc.jpg

Wenn ich den Pfad von dem erzeugten Bild direkt in Browser eingebe bekomme ich folgenden Fehler:

Code:

---

Unable to open image /html/contao/files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg
in Imagine.php line 77

at Imagine->open('/html/contao/files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg')
in Resizer.php line 93

---

Führe ich aber das Befehl über Console werden die Bilder die im Request beinhalten sind in assets/images/... erzeugt.

Code:

---

/usr/local/bin/php_cli vendor/bin/contao-console contao:resize-images

---

Dann werden die Bilder in Frontend und auch in Backend angezeigt.

Habe die config/config.yml angelegt und angepasst, das anstelle contao.image.imagine.gd die contao.image.imagine.imagick verwendet wird. Hat aber nichts gebracht.

Ich komme hier einfach nicht mehr weiter.

Was mache ich falsch, ist es Contaofehler oder Configurationsfehler vom Mittwald?

Update: Screenshot vom Symfonyprofiler angehängt.

Der Web Prozess scheint keinen Zugriff auf /files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg zu haben. Überprüfe die Rechte.

Zitat:

---

Zitat von Spooky

Der Web Prozess scheint keinen Zugriff auf /files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg zu haben. Überprüfe die Rechte.

---

Das habe ich als erstes getestet files/ und assets/ und die Verzeichnisse kontrolliert, ob diese veröffentlich sind.

Die Berechtigungen und Gruppe/Besitzer sind korrekt. Alle Ordner haben 755 und alle Dateien 644

Zudem können ja die JS- und CSS-Dateien generiert werden, nur die images nicht.

Läuft PHP mit dem selben User, der Besitzer der Ordner und Dateien ist?

Zitat:

---

Zitat von theMatrix

Das habe ich als erstes getestet files/ und assets/ und die Verzeichnisse kontrolliert, ob diese veröffentlich sind.

Die Berechtigungen und Gruppe/Besitzer sind korrekt. Alle Ordner haben 755 und alle Dateien 644

Zudem können ja die JS- und CSS-Dateien generiert werden, nur die images nicht.

---

Hast du geprüft, ob Du im Root noch eine alte .htaccess (von C3.5) hast?
Die dürfte im (echten) Root deiner Domäne liegen.

Siehe meinen Hinweis weiter oben.

Zitat:

---

Zitat von tab

Läuft PHP mit dem selben User, der Besitzer der Ordner und Dateien ist?

---

PHP kann die Dateien erzeugen, hat also den selben Benutzer.

Zitat:

---

Zitat von RainerG

Hast du geprüft, ob Du im Root noch eine alte .htaccess (von C3.5) hast?
Die dürfte im (echten) Root deiner Domäne liegen.

---

Die installation ist Clean-Install, also kein Update. lediglich die Verzeichnisse und Dateien darin wurden kopiert.

Kopierte Verzeichnisse:

• files
• templates
• config

Kopierte Dateien:

• composer.json

Es liegt kein weitere htaccess-Datei im Root oder die aus dem web-Verzeichnis wurde manipuliert.

Ich denke, dass das Problem am imagine liegt, da die Datei vom imagine nicht geöffnet werden kann. An dem Screenshot steht unable to open image /html/.....

Ich weiß nur nicht was da alles passiert in dem Resizer.php

Zitat:

---

Zitat von theMatrix

PHP kann die Dateien erzeugen, hat also den selben Benutzer.

---

Kann der Web Prozess über PHP im Ordner /files/userFiles/images/content/about-us/ Dateien lesen & schreiben?

HTML-Code:

---

'/html/contao/files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg'

---

Und der Großbuchstabe macht auch keine Probleme?

Bei Linuxsystemen sind ja:

HTML-Code:

---

'/html/contao/files/userFiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg'

---

und

HTML-Code:

---

'/html/contao/files/userfiles/images/content/about-us/contentbild-ueber-uns-wiesbaden2.jpg'

---

unterschiedliche Verzeichnisse.