Gleiches Problem mit den Themes auch hier. Ich verzweifle dran... Sieht aus als wenn die CSS fehlt und liegt mMn an der Plesk-Installation. Immerhin funktioniert es auf der Uralt-EiWoMiSau wie es soll. (Layer 8 Problem kann ich ausschließen).
Wordpress mit Webhosting 2000
- 143531
- Erledigt
-
-
Eventuell Fehler gefunden. Es wird der falsche Pfad referenziert.
kann da aber auch nichts sinnvolles herauslesen -
Hallo zusammen,
ich bin neu und habe die selben Probleme.
Neue WordPress Installation mit dem Anwendungsmanager installiert und bereits da werden keine Bilder in den Themes geladen.
Manuell hochgeladene Bilder (zB Logo) funktionieren jedoch.
Habe auch bereits (wie in WP Foren gelegentlich erwähnt) die Sample Page und Beitrag gelöscht, nginx an oder nicht. Keine Verbesserung.
Grüße
-
Ich habe folgenden KB Artikel seitens Plesk gefunden.
https://support.plesk.com/hc/e…ist-or-is-not-a-directory
Daraus geht hervor, dass die PHP Config aktualisiert werden muss. Das geht mit folgendem Command:plesk bin php_settings -u
Bei mir half es auch, im Plesk selbst die PHP Config zu modifizieren, also habe ich einmal Error-Anzeigen ein/aus geschaltet. Dadurch wurde die Config neu erstellt und die Dateien anschließend wieder korrekt durch die Scripts referenziert. -
Daraus geht hervor, dass die PHP Config aktualisiert werden muss. Das geht mit folgendem Command:
plesk bin php_settings -u
... nur leider nicht bei einem Webhosting, um das es in diesem Thema geht
-
Dann lies den nachfolgenden Satz. Dadurch konnte ich das Gleiche erreichen.
-
[...]
Bei mir half es auch, im Plesk selbst die PHP Config zu modifizieren, also habe ich einmal Error-Anzeigen ein/aus geschaltet. Dadurch wurde die Config neu erstellt und die Dateien anschließend wieder korrekt durch die Scripts referenziert.
Das habe ich versucht, leider ohne Erfolg. Die Seite ist immer noch ohne CSS.
-
Ok, schade. Was zeigen die Error-Logs?
-
Habe leider ebenfalls das Problem
Ich sehe z.B. auch die Fehlermeldung im Browser:
"Failed to load resource: the server responded with a status of 404 ()"
Gibt es noch neue Fix-Ideen? -
Kleines Update:
Ich habe die Installations-Dateien von Wordpress dann manuell via FTP hochgeladen. Aber selbst der WP Installations Wizard hat schon das gleiche Problem und sieht so aus, als würde das CSS nicht geladen werden...
Von daher...muss es doch eigentlich ein grundsätzliches Problem mit der Hosting-Konfiguration sein, oder? -
Hört sich mir nach einem Reverse Proxy Problem an. Da das dynamische geladen wird aber das Statische nicht.
Hast du mal eine URL das man sich ein Bild davon machen kann. Gerne auch via PM
-
Ich habe folgenden KB Artikel seitens Plesk gefunden.
https://support.plesk.com/hc/e…ist-or-is-not-a-directory
Daraus geht hervor, dass die PHP Config aktualisiert werden muss. Das geht mit folgendem Command:plesk bin php_settings -u
Bei mir half es auch, im Plesk selbst die PHP Config zu modifizieren, also habe ich einmal Error-Anzeigen ein/aus geschaltet. Dadurch wurde die Config neu erstellt und die Dateien anschließend wieder korrekt durch die Scripts referenziert.Abgesehen davon, dass es im Webhosting eh nicht funktioniert trifft der verlinkte KB Artikel von Plesk auch gar nicht zu:
ZitatDomains on PHP-FPM do not work
Momentan gibts im Webhosting meines Wissens kein PHP-FPM, alles nur FastCGI
-
Sehr, sehr seltsam...
Jetzt über Nacht scheint es auf einmal zu gehen -
Sehr, sehr seltsam...
Jetzt über Nacht scheint es auf einmal zu gehenDa waren die Heinzelmännchen am Werk. Typischerweise hat solche Probleme auch nicht nur ein einzelner User auf einem Webhostingserver.
-
Ich habe dasselbe Problem nach der Installation von Wordpress 5.7.1 auf einer neuen Domain in einem Webhosting 8000. Dort wird aktuell ebenfalls kein CSS geladen und beim direkten Aufruf von /wp-includes/css/dist/block-library/style.min.css antwortet der nginx mit einem 404 not found. Das Deaktivieren des nginx habe ich bis jetzt nicht abgewartet und warte einfach auch mal bis morgen
-
Melde es doch dem Support. Irgendjemand auf deinem Webhostingserver muss es halt melden, dann wird es für alle auf dem Server behoben werden. Wenn es keiner meldet, dann ist es in zwei Wochen immer noch so.
-
Wurde schon gemeldet nachdem ich genau das Problem im April 2020 ja auch schon hatte. Ich dachte nur dass würde sich mit dem Workaround bzw. dem Warten erledigen. Ich melde mich wieder falls der Support das lösen konnte. Hier war der alte Thread zum documentroot Durcheinander:
https://forum.netcup.de/anwend…?postID=140389#post140389
Zusammenhängend damit das Problem mit dem nicht ausgelieferten Let's Encrypt Zertifikat das stattdessen mit einem selbst signierten Zertifikat geliefert wird:
https://forum.netcup.de/anwend…-aber-nicht-ausgeliefert/ -
Zitat
Sie besitzen bei uns einen Webhosting-Tarif. Wir stellen Ihnen hierbei die Laufzeitumgebung bereit. Auf Ihre Inhalte haben wir keinen Einfluss und können keinen Support leisten.
Leider habe ich dieses Mal nicht soviel Glück, dass das Problem sofort bearbeitet wird. Mal schauen, ob jemand über den Feiertag / Sonntag auch Dienst schiebt.
-
Dann schieb doch mal alles raus aus dem Dokumentenstamm und lege die netcup-eigene index.html da rein. Dann LE-Zertifikat erstellen und es kann jedenfalls definitiv nicht mehr an deinen Inhalten liegen. Wenn das LE-Zertifikat wieder nicht klappt, eskaliere die Sache (Beschwerdeformular, Link zur Beschwerdestelle in der E-Mail vom Support) Ich mache mir langsam echte Sorgen, was die Qualität des Supports in letzter Zeit betrifft.
-
Nach der Antwort an den Support hat der Hostmaster das gestern abend noch unkompliziert gelöst und die Beeinträchtigung bereinigt.
Ich vermute mal dass der First Level nur von meinem Wordpress Geschwafel sofort zum Satzbaustein gegriffen hat.
Das LE Zertifikat wird seit der Korrektur gestern abend korrekt ausgeliefert und die statischen Dokumente liefert jetzt der nginx auch korrekt aus.