Schlagwortarchiv für: mod-rewrite

Seit heute Abend lassen wir das Plugin WP-Cache 2 laufen. In der vorigen Woche bekamen wir intensive Probleme mit dem Plugin, da während des Cachings selbst der Output irgendwie hängen blieb. Zuerst dachte ich an ein Problem mit unserem mod_rewrite. Doch mit zahlreichen echo „error1“; Bastelaktionen kam ich dem Geheimnis hinter. Nun habe ich mich durch all die Funktionen geforscht und stellte fest, dass eine kleine Inkompabilität im Programm mit höchstwahrscheinlich der auf unserem Server eingesetzten PHP Version 5.1.2 und Apache/2.0.52 Version zusammenhängt.

Genau kann ich das natürlich nicht behaupten, jedoch half es in Zeile 219 der Datei wp-cache-phase2.php folgendes zu ändern:

Zeile 219: ob_end_clean();
ändern in
Zeile 219: // ob_end_clean();

Einfügen in Zeile 232: ob_end_flush(); // unsere Modifikation

Das ursprüngliche flush() Kommando, was ich vorsorglich in dem Script belassen habe, verhält sich sogar laut php.net ein bisschen irreführend:

Server modules for Apache like mod_gzip may do buffering of their own that will cause flush() to not result in data being sent immediately to the client.

Sei’s drum, nun haben wir das ganze mit dem ob_end_flush() gelöst. Schön anzusehen ist dabei, dass die meisten Caches nur ausgespuckt werden, wenn das Original mit den Datenbankabfragen nicht innerhalb von 1 Sekunde geladen wird… hmmm!

Problem: Siehe die Kommentare. Es wird so anscheinend nichts mehr im Cache gespeichert. Sofern noch etwas altes im Cache drin ist, wird das zwar ausgegeben, doch keine neuen Dateien werden im Cache erzeugt.

Nachtrag: Mir fiel ebenfalls auf, dass das durch WordPress initierte GZIP-Encoding (Admin -> Options -> Reading -> WordPress should compress articles (gzip) if browsers ask for them) den gesamten Seitenaufbau verlangsamt hat, bevor ich WP-Cache 2 aktiviert habe. Gewiss, eine kleine Funktion zum Zippen muss vom Webserver bei jedem Seitenaufruf gestartet werden, aber anscheinend nahm es Ausmaße von über 1 Sekunde pro Seite an. Jetzt ist die Ladezeit recht gering… ok, ich sollte Feierabend machen! ;)

Hier unser knapper Bericht zur aktuellen Lage: In der Woche gab es ca. 500 Spameinträge, die dank Spamkarma2 in der Moderationsqueue gefangen wurden.

Vielleicht sind sie auch bei euch tätig, liebe Leser, denn bestimmt sind eure eigenen Blogs zumindest in der Moderationsqueue durch „diazepam“ oder „online pharmacy“ verseucht. Seitdem ich nach unserer Rückkehr aus dem Urlaub die folgenden Änderungen an der .htaccess Datei für das mod_rewrite gemacht habe, wurde die Spamflut (teilweise im 2-Minuten-Takt) vorerst aufgehalten. Und folgende IP Adressenräume wurden dementsprechend gesperrt:


RewriteCond %{REMOTE_ADDR} ^195\.225\.177\..*$
RewriteRule ^.* – [F]

RewriteCond %{REMOTE_ADDR} ^72\.232\.67\..*$
RewriteRule ^.* – [F]

RewriteCond %{REMOTE_ADDR} ^150\.101\.105\..*$
RewriteRule ^.* – [F]

RewriteCond %{REMOTE_ADDR} ^150\.101\.110\..*$
RewriteRule ^.* – [F]

RewriteCond %{REMOTE_ADDR} ^70\.87\.46\..*$
RewriteRule ^.* – [F]

RewriteCond %{REMOTE_ADDR} ^72\.14\.203\..*$
RewriteRule ^.* – [F]