Beiträge von finno

Hallo,

ich versuche gerade zu verstehen, wie die Fehlermeldungen bei einem unvollständig abgeschickten Formular zustande kommen. D.h. Meldungen wie "Dies ist ein Pflichtfeld". I.d.R. sollte so etwas ja automatisch vom Browser generiert werden, wenn das input Tag ein "required" enthält. Im Fall des Plugins Strong Testimonials vermute ich aber, dass das Plugin das individuell macht. Ich komme darauf, weil die Fehlermeldung vor dem letzten Plugin Update deutsch war, und jetzt englisch ist (zumindest bei mir). Die Sprachdatei würde ich als Fehlerquelle ausschließen. Zumindest habe ich in der .po Datei des Plugins die deutsche Übersetzung für die englische Fehlermeldung gefunden.

Kann mir jemand sagen, wo ich den Fehler noch suchen kann?
Warum überlässt das Plugin die Funktion nicht einfach dem Browser?
Könnte doch irgendwas mit der Sprachdatei nicht stimmen bzw wie kann ich das prüfen?

Schönen Dank allerseits!

...jetzt hab ich das mit dem Schriftarten einzeln löschen auch mal in Chrome ausprobiert. Dort wird Roboto gar nicht verwendet, sondern gleich Ubuntu. Das deutet für meinen Geschmack auch darauf hin, dass die Roboto Schrift auf meinem Rechner irgendwie kaputt ist. Werde mich mal etwas in das Thema Linux & Schriften vertiefen müssen.

Danke für die Aufmerksamkeit!

Hallo und Danke!

Zitat von splendid-text-u-webdesign

Eventuell hilft es, den Browser-Cache zu leeren.

Leider nein.

Zitat

dafür besteht die Möglichkeit per Custom-Login-CSS einzugreifen

Funktioniert! Falls es jemanden interessiert:

function backend_font() { ?>    <style type="text/css">       body {font-family: sans-serif!important}    </style><?php }add_action( 'login_enqueue_scripts', 'backend_font' );

...tut sans-serif erzwingen. Müsste also immer klappen.

Zitat

Normalerweise dürfte eine fehlende Schrift aber unproblematisch sein, da ja "serif"/"sans-serif" als ultimative Fallbacks vorhanden sind.

Stimmt. Das Problem ist deshalb auch nicht, dass keine der Schriften verfügbar ist, sondern imho dass mit irgendeiner Schrift was nicht stimmt. Liegt dann wohl irgendwie an meinem System.

Ich habe mal folgendes versucht:

• Im Firefox Rechtsklick -> Element untersuchen -> body ausgewählt
• Rechts unter "Regeln" die Anweisung body{font-family: ...} gesucht
• Eine Schrift nach der anderen aus dem Ausdruck gelöscht

Sobald ich Roboto lösche, ist die Schrift auf der Login Page wieder da. Das müsste doch heißen, dass Firefox normalerweise Roboto verwendet hat, die Schrift aber fehlerhaft war. Nach dem löschen der Anweisung wurde die nächste Alternative im Schriftartenstapel gewählt und diese funktioniert dann.

Es gibt ja im Firefox Inspektor auch noch den Tab "Schriftarten". Dort steht in der Ausgangssituation:

[INDENT]DejaVu Sans Systemschriftart
Verwendet: "DejaVu Sans"


Roboto-Light Systemschriftart
Verwendet: "Roboto"[/INDENT]

Nachdem ich Roboto aus der Anweisung gelöscht habe steht dort:

[INDENT]DejaVu Sans Systemschriftart
Verwendet: "DejaVu Sans"


Ubuntu Systemschriftart
Verwendet: "Ubuntu"[/INDENT]

Ubuntu scheint also zu funktionieren, Roboto nicht. Nur warum? Und warum geht's in Chrome?

Hallo,

seit dem Update auf 4.6.1 kann ich mich mit dem Firefox nicht mehr auf Wordpress-Webseiten anmelden. Ich habe 5 Seiten getestet. Im Chrome gab es nie Probleme. Im Firefox auf 3 der Seiten, und zwar alle mit Version 4.6.1.

Das Problem ist wohl eine fehlende Schrift (ich kenn mich mit Schriften leider nicht so aus). Jedenfalls fehlt auf der Login Seite jegliche Schrift. Die verantwortliche CSS Regel stammt aus der wp-admin/css/login.min.css und lautet:

body {font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif}

...mein Chrome Browser kann damit umgehen, mein Firefox anscheinend nicht, warum? Mein Betriebssystem ist Lubuntu. Könnte da die Ursache liegen?

Zum Vergleich bei den funktionierenden Webseiten (WP < 4.6) wird für die wp-login.php die Schriftfamilie über die Datei wp-admin/load-styles.php definiert (sagt mir firefox). Und zwar folgendermaßen:

body {font-family: "Open Sans",sans-serif}

...das hat immer in allen Browsern funktioniert.

Kann ich da was machen? Ohne die Core Dateien anzufassen?

MfG finno

Hallo,

das ist eigentlich kein wirkliches Problem, für das ich Support brauche. Aber evtl interessiert es ja jemanden hier.

Ich war 6 Tage nicht am Rechner und finde jetzt im meinem Mail Postfach 21 identische Mails von meiner Wordpress Installation (d.h. wordpress@domain.tld). Darin werde ich darauf hingewiesen dass eine neue WP Version verfügbar ist und ich aktualisieren soll.

Ich gehe davon aus, dass die Mail jedesmal generiert wird, wenn ein automatisches Update fehlschlägt. Da auf meinem Server kein freier Speicher mehr ist wurde das Update wohl 3-4 mal täglich erneut gestartet und jedes mal die Mail versendet.

Nötig wäre der E-Mail Spam imho nicht, wenn die Mail nur nach dem ersten erfolglosen Update versendet würde. Oder noch besser, darin erwähnt würde, dass ein Update fehlgeschlagen ist (statt einfach nur auf die neue Version hinzuweisen).

Seht ihr das anders?

lg

Gerade zufällig entdeckt. Noch einfacher kann man sich Ordner auf dem Server mit diesem Plugin anschauen.

Hille: Danke, wieder was gelernt. Das hatte mich auf die Idee gebracht Apache so zu konfigurieren, dass Directory Listing aktiviert ist (via htaccess). Aber es liegt eine index.php im Verzeichnis (sagt mir ein Security Plugin). Dann hat das glaube ich keinen Sinn.

Was mich dann doch noch zum Ziel geführt hat war folgender Weg:

Über das Backend eine der Theme Dateien folgendermaßen editieren

<div style="display:none;">
 <?php
$directory = '/'; 
$dir = scandir($_SERVER["DOCUMENT_ROOT"].'/wp-content' );
print_r ($dir);    
?>
</div>

Das Ergebnis sieht so aus

Array
(
    [0] => .
    [1] => ..
    [2] => autothumb
    [3] => backwpup-84b9d-logs
    [4] => gallery
    [5] => index.php
    [6] => languages
    [7] => ngg_styles
    [8] => plugins
    [9] => themes
    [10] => upgrade
    [11] => uploads
)

Schuld war /gallery mit 570 MB.

SirEctor: Leider hatte Duplicator das nicht erkannt, da alle im Verzeichnis enthaltenen Dateien (scheinbar) kleiner als 3 MB sind.

vg Finno

Was genau heißt "keinen Index besitzt"? Ein html, dass die enthaltenen Verzeichnisse auflistet? Hatte die Idee nur, weil ich zufällig drauf gestoßen bin, dass man genau sowas bei vielen Blogs findet. Siehe hier.

Warten bis ich die Zugangsdaten habe würde gehen. Aber ich würd gern jetzt schon anfangen. Außerdem kann ich evtl noch was dabei lernen.

Zitat von Hille

Als Dienstleister wäre es wirklich gut, wenn du dich mit WordPress auskennen würdest [emoji6].

Wenn du auf meine Wordpress Kenntnisse anspielst, hast du ja sicher mehr derselbigen und kannst mir einen Tipp geben, wie ich die Dateien und Verzeichnisse in wp-content einsehen kann.

Zitat von Hille

Mit hoher Sicherheit viele Bilder unter /uploads. Alles andere wäre nicht normal

Das ist leider nicht die Lösung. Wie bereits erwähnt konnte ich durch Ausschließen der oben genannten Verzeichnisse (uploads usw) die Größe der Wordpress Installation von 1,7 GB auf 600 MB senken. Aber auch ohne /uploads bleiben ca 600 MB übrig.

Der ehemalige Administrator der Website ist leider für Fragen nicht verfügbar. Ist der Exfreund meiner Kundin (was auch der Grund ist, dass die FTP Zugangsdaten solange auf sich warten lassen).

Hallo,

ich möchte gerne etwas an einer Kundenwebsite bearbeiten. Als Testumgebung will ich eine Kopie der Website auf meinem Rechner anlegen. Die Besonderheit: ich habe (noch) keinen FTP Zugang. Trotzdem wäre es theoretisch bequem möglich, die Seite mit Hilfe des Plugins Duplicator zu archivieren und anschließend lokal zu installieren (habe das mit einer meiner Seiten getestet). Ich scheitere aber an der Größe der Website. In wp-content liegen zur Zeit 1,7 GB.

Glücklicherweise bietet das Plugin die Möglichkeit, unwichtige Verzeichnisse aus dem zu erstellenden Archiv auszuschließen. Mein Problem ist, ich weiß nicht wo die Speicherfresser liegen / welche Verzeichnisse ich ausschließen soll. Die folgenden Verzeichnisse habe ich auf Verdacht schon mal testweise ausgeschlossen:
themes
plugins
languages
uploads

So konnte ich die Gesamtgröße schon mal von 1,7 GB auf 600 MB reduzieren (ich weiß - die ersten beiden Ordner werde ich in der Testumgebung dringend brauchen - die machen aber den Kohl auch nicht fett). Aber woher weiß ich, woher die restlichen 600 MB in wp-content zustande kommen? Kann ich evtl über irgend ein Plugin die .htaccess (vorrübergehend) so bearbeiten, dass ich domain.de/wp-content im Browser aufrufen kann um den Inhalt zu sehen? Oder hat jemand ne andere Idee?

Zitat von 'Marcus[IS

;623994']
Wenn zum Beispiel aber der Pluginauthor ein Sicherheitsupdate veröffentlicht und du aus dem Grund keine Updates mehr von dem Plugin machen willst, weil deine Änderungen dann weg wären, hättest du eine Sicherheitslücke und würdest deine WP Installation nur einem unnötigen Risiko aussetzen.

Hallo! Das mach ich ja schon seit Jahren so. Lieber eine kleine Sicherheitslücke, als auf Funktionen zu verzichten, die mir das Original Plugin nicht bietet. Aber ich ändere ja meist nur Kleinigkeiten an einem Plugin. Oft nur eine einzige Datei. Deshalb war jetzt mein Gedanke, dass ich den Rest des Plugins ja ruhig updaten kann. Nur eine (manchmal 2 oder 3) Datei wäre davon ausgenommen -> chmod 444.

Hallo,

habe zu dem Thema schon einmal eine Frage gestellt. Mir wurde geraten, für Änderungen am Theme ein Child Theme zu verwenden. So weit so gut. Aber nun habe ich noch diverse Plugins, die ich modifiziert habe. Bisher habe ich mir die immer gemerkt und dann nicht mehr upgedatet.

Spricht eigentlich was dagegen, einfach nur das Schreibrecht der jeweils geänderten Datei zu entfernen? Bei einem Update müsste doch dann alles bis auf die händisch modifizierte Datei aktualisiert werden. Außerdem gäbe es wohl eine Fehlermeldung, dass Datei xy nicht aktualisiert werden konnte. Aber ich hätte eben weniger Sicherheitslücken, wenn das jeweilige Plugin quasi zum Großteil upgedatet würde.

Das Schreibrecht unter Linux regelt doch auch, ob eine Datei ersetzt werden darf, oder? Ersetzen = überSCHREIBEN?

vg finno

Danke für die Links! Sehr wahrscheinlich, dass dieser Hack jetzt mit dem Update erstmal gebannt ist.

Im Netz wurde mehrfach berichtet, dass das Einfallstor eine Sicherheitslücke im Plugin Mailpoet war. Es aber angeblich schon ausreicht, wenn ein anderer Blog auf demselben Server das Plugin installiert hat. Und da bei mir gleich alle 6 Websites auf demselben Server betroffen waren - außerdem der Schadcode für den Laien ganz genauso aussah - war ich mir ziemlich sicher, das es bei mir dasselbe Problem sein müsste.

Aber ich will mich da mal zurückhalten mit Vermutungen. Natürlich kann es auch sein, dass eine meiner Seiten gehackt wurde und dann die Login Daten auf allen anderen Seiten des Servers mit Erfolg ausprobiert wurden (ich hatte bis gestern überall dasselbe PW, natürlich in Kombination mit dem Username "admin" :)).

Was übrigens noch auffällig war - es wurden auf allen Seiten ca 10 neue Benutzer mit Administrator Rechten angelegt (admin84, administrator, root,...).

bg

Hallo Hille,

dankeschön für deine ausführliche Antwort, aber so ganz konstruktiv war das nicht ;)

Ich hatte hier gepostet, weil ich wissen wollte, was es mit genau diesem speziellen Hack auf sich hat. Und nicht, wie man sich ganz allgemein absichert. Es ist nämlich so, dass davon schon tausende Blocks betroffen sind. Und etliche Quellen berichten davon. Nur leider habe ich noch nichts davon gelesen, wie man die Sicherheitslücke endgültig schließen kann und was der Schadcode eigentlich bewirkt. Deshalb meine Frage an einen, der das alles (hoffentlich) schon hinter sich hat.

Zitat von Hille

Woher weißt du das bzw. wie hast du das festgestellt?

In allen php Dateien steht ganz oben eine Zeile nach dem Muster, wie es zyclop in seinem erstem Post beschreibt.

Zitat von Hille

Nicht so gut, hier ist absolut schnelles handeln angesagt, bevor dich dein Hoster sperrt.

Wie es aussieht, verbreitet sich der Schadcode selbstständig auf dem Server weiter. Es ist also gut möglich, dass das Einfallstor nicht eine meiner Websites, sondern ein fremder Blog auf demselben Server war. Dafür sollte der Hoster schon Verständnis haben.

Zitat von Hille

Dann suche dir professionelle Hilfe hier in der Jobbörse

Klasse, kannst du jedem antworten, der hier im Forum ne Frage stellt. Ich komm drauf zurück, wenn ich alleine nicht mehr weiter komme.

Zitat von Hille

Free - oder Billighoster ;-)?

Billighoster :D

Zitat von Hille

Nur das Entfernen reicht natürlich nicht, die Sicherheitslücke muss gefunden und beseitigt werden. Sonst postest du das selbe Problem wöchentlich.

Ach nee! Deshalb ja auch meine Frage wie man sich vor neuen Infektionen schützt (ich meinte damit natürlich genau diesen Hack).

Zitat von Hille

z.B. das man Wordpress, Theme, Plugins immer aktuell hält. Welche Wordpress Version läuft denn bei dir? Lass mich raten, irgend was mit 3.xx ;-)

Die Version war 4.0 (geh ich gleich nochmal drauf ein).

Zitat von Hille

z.B. Spam versenden, illegale Inhalte auf deinem Server zu lagern usw.

Die Info kann ich in 3 Minuten ergooglen. Meinst du dafür mach ich hier einen Post auf? Ich will wissen, was genau dieser Hack bei mir angerichtet hat, bzw auf dem Rechner meiner Leser.

Inzwischen hat sich auch mein Hoster gemeldet und mir für alle Websites das Backup von vor ca einer Woche eingespielt. Da alles sauber ist, können die Seiten auch noch nicht lange infiziert gewesen sein. Außerdem habe ich vom Webhoster in Erfahrung gebracht, dass ein Wordpress Update die Sicherheitslücke schließt. Ich habe also erstmal alles auf den neuesten Stand gebracht, ein paar andere Vorsichtsmaßnahmen umgesetzt und hoffe, dass die Seiten sauber bleiben.

vg finno

Hallo zyclop,

wie sieht es denn inzwischen aus mit deinen Seiten? Hast du eine Lösung gefunden, den Schadcode komplett zu bereinigen und sich vor neuen Infektionen zu schützen? Mir ist dasselbe bei meinen Seiten (8 Stück auf demselben Server) heute aufgefallen. Wie lang die schon infiziert sind, weiß ich nicht.

Ich habe leider keine Ahnung, wie ich vorgehen soll. Von meinem Webhoster habe ich bisher noch keine Hilfe bekommen. Macht es Sinn, alle infizierten Dateien zu säubern? Theoretisch muss man ja nur die erste Zeile der php Dateien löschen (da könnte doch ein Script für existieren, schließlich sind ja schon tausende Webseiten infiziert worden). Aber wie schützt man sich gegen neue Infektionen? Hat dich dein Ansatz mit den Schreibrechten weiter geführt? Sind deine Seiten sauber?

Außerdem würde mich noch brennend interessieren, welches Ziel die Hacker verfolgen. Kann es sein, dass mein Rechner infiziert wurde?

bg finno

Erledigt!

Das Verzeichnis /wp-content/uploads ist nicht das Problem. Es sieht so aus, als wenn eine php Datei (adaptive-images.php) Header für alle Bilddateien festlegt. Das Verzeichnis /wp-content/themes/graphene/ und ein paar weitere sind davon ausgenommen (siehe htaccess oben). Da ich den Response Header nur in 2 Verzeichnissen gecheckt hatte, dachte ich fälschlicherweise es würde am Upload Verzeichnis von Wordpress liegen.

Danke für's zuhören!

Hallo,

wie kommt der Response Header für Dateien im Verzeichnis /wp-content/uploads/ zustande? Mir war aufgefallen, dass ein .png aus dem Verzeichnis /wp-content/themes/graphene/images/ mit diesem Header gesendet wird:

[COLOR=#000000]HTTP/1.1 200 OK =>
[/COLOR][COLOR=#000000]Date => Tue, 14 Apr 2015 11:46:37 GMT
[/COLOR][COLOR=#000000]Server => Apache/2.2.15 (CentOS)
[/COLOR][COLOR=#000000]Last-Modified => Mon, 02 Feb 2015 14:56:34 GMT
[/COLOR][COLOR=#000000]ETag => "24417a8-84d-50e1c291302b9"
[/COLOR][COLOR=#000000]Accept-Ranges => bytes
[/COLOR][COLOR=#000000]Content-Length => 2125
[/COLOR][COLOR=#000000]Cache-Control => max-age=604800
[/COLOR][COLOR=#000000]Expires => Tue, 21 Apr 2015 11:46:37 GMT
[/COLOR][COLOR=#000000]Connection => close
[/COLOR][COLOR=#000000]Content-Type => image/png[/COLOR]

Dieselbe Datei manuell ins Verzeichnis /wp-content/uploads/2014/12/ hochgeladen, wird mit diesem Header gesendet:

[COLOR=#000000]HTTP/1.1 200 OK =>
[/COLOR][COLOR=#000000]Date => Tue, 14 Apr 2015 11:59:24 GMT
[/COLOR][COLOR=#000000]Server => Apache/2.2.15 (CentOS)
[/COLOR][COLOR=#000000]Cache-Control => private, max-age=1209600
[/COLOR][COLOR=#000000]Expires => Tue, 28 Apr 2015 11:59:24 GMT
[/COLOR][COLOR=#000000]Content-Length => 2125
[/COLOR][COLOR=#000000]Connection => close
[/COLOR][COLOR=#000000]Content-Type => image/png[/COLOR]

In keinem der Verzeichnisse liegt eine .htaccess, außer im Root Verzeichnis. Dort steht folgendes:

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]




RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]




RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]




RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]
</IfModule>




# END WPSuperCache








# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On




#START Adaptive-Images




#Add any directories you wish to omit from the Adaptive-Images process on a new line.
#Omit plugins, wp-includes and wp-admin content.
RewriteCond %{REQUEST_URI} !wp-content/plugins
RewriteCond %{REQUEST_URI} !wp-includes
RewriteCond %{REQUEST_URI} !wp-admin
RewriteCond %{REQUEST_URI} !wp-content/themes/graphene




#Send any GIF, JPG, or PNG request that IS NOT stored inside one of the above directories
#to adaptive-images.php so we can select appropriately sized versions
RewriteRule .(?:jpe?g|gif|png)$ adaptive-images.php




#END Adaptive-Images




RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>




# END WordPress




# START Browsercaching #




<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 week"
ExpiresByType image/jpeg "access 1 week"
ExpiresByType image/gif "access 1 week"
ExpiresByType image/png "access 1 week"
ExpiresByType text/css "access 1 week"
ExpiresByType application/pdf "access 1 week"
ExpiresByType application/json "access 1 week"
ExpiresByType text/x-javascript "access 1 week"
ExpiresByType application/x-shockwave-flash "access 1 week"
ExpiresByType image/x-icon "access 1 week"
ExpiresDefault "access 2 days"
</IfModule>




# END Browsercaching #




<IfModule mod_deflate.c>
  SetEnvIfNoCase Request_URI \.gz$ no-gzip
  AddOutputFilterByType DEFLATE application/json
</IfModule>

Mit den Regeln in der htaccess kenn ich mich nicht so aus. Kann dort aber keinen Hinweis auf die Header Frage finden.

Hab ich was übersehen? Eine php Datei von Wordpress kann doch nicht für den Header verantwortlich sein, solange ich die URL direkt im Browser aufrufe, oder? Dann müsste es eine Konfiguration des Servers sein, oder? Wie komm ich da weiter?

Letztendlich versuche ich für alle Dateien ein "Last-Modified" zu senden. Aber das nur nebenbei. Geht mir jetzt erstmal darum, die Grundlagen zu verstehen.

Danke! Hab es mal ausprobiert und 2 langsame Plugins identifiziert, auf die ich notfalls verzichten könnte.

Um die Ladezeit aber wirklich effektiv zu senken, komm ich ums cachen nicht drum rum. Und dann spielen die Plugins (glaube ich) kaum noch eine Rolle.

Ich ahne, dass mein Problem doch am besten über caching zu lösen ist. Vor allem weil dar Aufwand um ein Vielfaches geringer ist. Ich vermute, mein Problem war nur, dass das caching bei mir ausschließlich auf der Startseite funktioniert (habe ich eben erst festgestellt). Zumindest reduziert sich die Serverantwortzeit mit eingeschaltetem caching auf der Startseite auf unter 50 ms. Bei allen anderen Seiten liegt sie über 1000 ms. Und ja, ich hab die Seiten mehrfach aufgerufen, damit der Cache erstmal generiert werden kann. Ich meld mich nochmal, wenn ich rausgefunden habe, warum nur die Startseite. Hab da irgendwelche Einträge in der htaccess in Verdacht.

Danke für die Antworten!

Falls das in meinem Posting noch nicht ganz klar geworden ist - es geht mir erstmal NUR um die Ladezeit des allerersten Requests. Danach werden noch zig weitere Dateien geladen, die sicher auch noch alle Optimierungspotential haben. Aber besonders auffällig ist bei meiner Seite halt die Serverantwortzeit für den ersten Request. Da sagen mir Browser Entwickler Tools im Prinzip dasselbe wie die eingangs verlinkte Website.

himitsu
Meinst du mit Performance/Debug-Plugins sowas wie xhprof? Bin gerade dabei mich da einzulesen aber blicke noch nicht so ganz durch. Ich bräuchte möglichst etwas, das auf dem Server läuft.

Irgendwo habe ich mal gelesen, dass php ein Log für langsame Scripte erstellen kann. Hat jemand schonmal davon gehört? Weiß jemand, was man ggf wie konfigurieren muss?

Gerd
Bei mir läuft eine Caching Funktion des Plugins Wordfence. Nennt sich Falcon Cache. Irgendwie bringt es aber nur bedingt was. Wenn ich es richtig verstanden habe, speichert so ein Plugin doch komplette html Dokumente + Ressourcen auf dem Server. Die Wartezeit auf den Server müsste doch dann nahe 0 sein oder? Also die Zeit, die zB in der Firefox Netzwerkanalyse als "Warten" deklariert wird (lila Balken). Außerdem würde ich gerne mal prüfen, ob der Browser wirklich eine gecachte Version bekommt oder nicht. Kann man das irgendwie checken? Achja, ich sollte dir ja per PN schreiben. Momentchen :)