Schau mal unter Werkzeuge > Website-Zustand, ob dort irgendeine Warnung steht. Gerne auch den Website-Bericht hier posten wie hier beschrieben: https://de.wordpress.org/support/topic/bevor-du-ein-neues-thema-thread-erstellst/
Thread-Starter
onlaie
(@onlaie)
Ja, da steht schon eine, aber nur seit ich vorhin die debug Ausgabe aktiviert habe, ist die Warnung wegen der „öffentlichen“ Fehlerdatei.
Ansonsten nur das übliche:
Sie sollten einen persistenten Objekt-Cache verwenden
Seiten-Cache wurde nicht erkannt, aber die Antwortzeit des Servers ist OK
Hoster ist verständigt, denn auch das testweise probierte Installieren eines Plugins geht nicht: „Installation fehlgeschlagen, Download fehlgeschlagen. Too many Requests“
Ich warte mal die Antwort des Hosters ab. Danke erstmal.
Thread-Starter
onlaie
(@onlaie)
Danke. Bis jetzt fand der Hoster leider keinen Grund und die relevanten Abschnitte der FAQ halfen auch nicht weiter.
Denn zum einen funktioniert ja ansonsten alles andere und der angesprochene Fehler tritt auch nur sehr selten auf.
So blieben kaum Punkte übrig (htaccess gibts keine und alles andere evtl. zutreffende, dort beschriebene wurde ja schon versucht, inkl. Austausch der Core Dateien usw.)
Einzig die komplette Neuinstallation bleibt noch übrig. Aber wenn das Problem beim Hoster (oder doch bei WP? („es scheint etwas bei WordPress.org nicht zu stimmen“)) liegt, wird das nichts bringen.
Jede WordPress-Website hat normalerweise eine .htaccess-Datei. Manchmal muss man solch „versteckte“ Dateien erst im FTP-Programm über Einstellungen sichtbar machen.
Website-Zustandsbericht?
Error.log?
Ansonsten, siehe dort:
https://de.wordpress.org/support/topic/es-scheint-etwas-bei-wordpress-org-oder-mit-dieser-serverkonfiguration-nicht/
Thread-Starter
onlaie
(@onlaie)
Schon, nur die definitiv nicht. Vllt. auch weil auf NGINX.
Das verlinkte Thema ist sehr interessant und deutet schlussendlich mehrheitlich auf ein Hoster Problem hin. Also werde ich das nur auf der Basis weiterverfolgen und denen die Interpretation der Logs usw. überlassen (die kosten mir ja auch was, also sollen die nur machen).
Sollte es mal ein Ergebnis geben, melde ich mich wieder.
Sollte es häufiger auftreten oder sich länger nichts ergeben, kann ich diese Angaben ja immer noch hier posten, sofern das Thema noch offen ist.
Vllt. auch weil auf NGINX.
Wahrscheinlich; wenn es ein reiner Nginx-Server ist. Ich habe schon bei einigen Providern Nginx-Server gelesen/gesehen, die aber letztendlich mit Apache kombiniert waren, siehe hier.
Ein reiner nginx-Server ist mir glücklicherweise noch nicht untergekommen. Weitere Informationen über Nginx + WordPress:
https://developer.wordpress.org/advanced-administration/server/web-server/nginx/
Thread-Starter
onlaie
(@onlaie)
Scheint in dem Fall schon so einer zu sein.
Server-Architektur: Linux 5.4.0-182-generic x86_64
Webserver: nginx/1.18.0
Jedenfalls bildet sich nicht einmal nach dem runderneuern der Permalinks eine hta.
glücklicherweise
?
„glücklicherweise ? “ Siehe den zweiten Link, den ich oben gepostet hatte. Ich erledige vieles über die .htaccess-Datei. Es mag (nur) meine persönliche Präferenz sein, in Nginx pur müsste ich mich erst einarbeiten.
Der nginx müsste im error-Log dazu etwas hinterlassen. Möglich sind hier ganz andere Dinge als bei einem Apache, z.B. der client request body der als Antwort auf eine Anfrage zurückgegeben wird und aus Performance-Gründen eine festgelegte Größe nicht überschreiten darf. Müsste wie gesagt im error.log erkennbar sein. Der Hoster sollte es schnell erkennen.
Thread-Starter
onlaie
(@onlaie)
Stimmt, mit .htaccess ist vieles machbar, wenn man weiß, wie es geht. Dann braucht man kaum den Hoster-Support.
Für Nginx ist es ratsam, einen guten Hoster zu haben, der einem bei der Konfiguration hilft. Sofern man selber kein Serveradmin ist, braucht man eben die Leute dort, denn oft stimmen die Nginx-Tutorials nicht mit den speziellen Regeln überein, die eben genau auf dem Host sind. Aber dann funktioniert es garantiert; Nachteil ist die Zeit, welche die Tickets brauchen.
Müsste wie gesagt im error.log erkennbar sein. Der Hoster sollte es schnell erkennen.
Eben. Daher überlasse ich das denen.
Wollte hier eigentlich auch nur mal schauen, ob das schon mal jemand hatte.
Hab ich schon öfter mal. Alle Entwicklungssysteme bei mir nutzen nginx. Auch einige Hostings werden nur damit betrieben. Kenne daher auch solche Meldungen, aber die Ursache kann so vielseitig sein, dass man nur zu einem Blick ins error.log raten kann (mache ich auch immer).
Melde dich gerne, wenn du eine Rückmeldung dazu hast 🙂 Dann kannst du vielleicht ja auch das Topic auf gelöst setzen.
Thread-Starter
onlaie
(@onlaie)
Gerne markiere ich das ggf als gelöst. Denn ich mag auch keine offenen Baustellen in meiner eigenen Doku …
Doch die Supporter wollen halt auch zuerst den einfacheren Weg gehen und sagen sich „schaun‘ mer mal“ was der Kunde allein rausfindet, hinbekommt.
Hab dort aber mal wieder nachgehakt.
