Dank dem Hinweis von Stefan bin ich auf eine Erweiterung für Spam Karma 2 gestoßen: Das Plugin „Spam Karma 2 Akismet Plugin“ wird einfach in das SK2 Plugin Verzeichnis kopiert und übernimmt die kompletten Arbeiten vom üblichen Akismet Plugin für WordPress. Das ist sehr praktisch und hilfreich und scheint auch ein wenig den Server zu schonen. Ich wußte gar nicht, dass soetwas für SK2 im Einsatz ist. Daher also wie immer – Fight the Spam!
Schlagwortarchiv für: Plugin
Wer kennt es nicht, dass gut und gerne über 150 Queries beim Seitenaufbau in WordPress stattfinden? Wir hatten bei uns immer um die 125 Queries gehabt, jedoch seit heute Abend sind es nur magere 55 queries. Keine statischen Inhalte, keine Auslieferung von gecacheten Daten – sondern ein kleines Geheimnis der Kunst: Endlich mal das /wp-content/plugins Verzeichnis entrümpelt.
Nachdem die Plugins Adhesive 3.2, German Permalinks 1.31, WP lightbox JS 0.5, Ultimate Tag Warrior: Tag Archive 1.0 und Ultimate Tag Warrior 1.3 Legacy komplett vom Server gelöscht waren, ist die Load auf dem Server schneller geworden und dementsprechend der Speed hochgegangen. Ein Wunder? Nein… aber wer weiß woran es wirklich liegt. Wir werden uns jedenfalls die Mühe machen und in Zukunft die Plugins sauber pflegen. ;)
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! ;)
Heute steht eine weitere „Gefühlsfrage“ zu diesem grünen Layout an unsere Leserschaft an: Die Campuszeitung Flensburg wird in den kommenden Tagen (Wochen) einen Relaunch erleben. Endlich weg vom starren, teilweise nicht existenten Auftritt, zu einem „powered by Blog“ Content-Management-System. Wir setzen WordPress in seiner aktuellen Version mit diversen Plugins ein.
Das Layout wird sich farblich zu jeder Print-Ausgabe anpassen, und im Moment dominiert natürlich aufgrund der Ausgabe im März der strake Grünton. Daher werden farbliche Variationen alle paar Monate an der Tagesordnung sein, aber das Layout bleibt in seinem Stil und der Formgebung erhalten. Das schöne am eingesetzten WP Plugin Adhesive ist, dass sich ähnlich wie auf diversen Webboards einer oder mehrere Artikel als „Sticky“ darstellen lassen – so kommt der hellgrüne Artikel als „Top Thema“ immer wieder zum Einsatz, auch wenn jemand eine neuere Meldung in WordPress einspeist.
Daher unsere kleine Leserumfrage: Was denkt ihr über dieses Layout, liebe Leser? Habt ihr vielleicht ein paar Ideen für uns? Persönlich glaube ich, dass gerade WordPress genügend Kapazitäten aufweist, um sich neben vielen kommerziellen Systemen als CMS behaupten zu können. Ob wir diese konstruktiven Vorschläge und Ideen natürlich umsetzen, kann ich natürlich nicht garantieren – aber wir sind für jede Hilfe dankbar.
Soeben stieß ich auf einen Eintrag bei Jörg: Kommentieren im Weblog nach Anmeldung. Im Prinzip dreht es sich um diejenigen Blog Autoren, die die Diskussion in ihren Blogs nur für angemeldete User freigeben.
Wir haben uns mittlerweile dafür entschieden, eine „Doppellösung“ zum Diskutieren bei uns anzubieten. Wie bisher kann man ohne weitere Registrierung bei uns kommentieren, jedoch setzen wir hier unter WordPress das Plugin Spam Karma 2 ein. Dabei kann es auch echten Usern passieren, dass sie geblockt werden (bei z.B. bei Verwendung von blogspot.com URLs).
Meistens erhalten sie in einem von SK2 erwählten Spielraum eine Möglichkeit, sich per Captcha-Check zu verifizieren. Sollte dies nicht möglich sein, wird der Kommentar in der SK2-Moderationsqueue dargestellt.
Um dem Treiben vorzubeugen bieten wir es ebenfalls an, dass sich „echte Menschen“ auch bei uns als WordPress-User (nahezu ohne Rechte) registrieren dürfen. Eine „Handvoll“ unserer Stammleser tut dies bereits, und so sind auch Captcha-Probleme oder Moderationsqueues kein Problem mehr.
Daher denke ich, dass die nur Kombination von guten Spam-Abwehrmaßnahmen und einer optionalen Registrierung mit daraus resultierenden Boni bzw. Privilegien die richtige Variante ist, um die Diskussionsgrundlage im Blog zu schaffen.
Seit kurzem nutzen wir Ultimate Tag Warrior zur Darstellung aller Tags (Keywords, Suchbegriffe) auf unserer Seite. Das schöne daran ist, dass man auch die sogenannte Tag Cloud in vielfachen Darstellungsmöglichkeiten nutzen kann. Dennoch fiel mir auf, dass unsere Tag Cloud viel zu groß dargestellt wurde. Aber nach einer kurzen Suche fand ich auch den entsprechenden Wert, den man im Funktionsaufruf ändern sollte, sofern man die Code Snipplets aus den „Examples: tags.php“ einsetzt (hier: mit eingebautem Zeilenumbruch):
UTW_ShowWeightedTagSetAlphabetical
("coloredsizedtagcloud","",0);
Wir haben weit mehr als ein 1100 verschiedene Tags, und diese wurden ursprünglich auf der Seite komplett angezeigt! Die entsprechende Load für die Datenbank war recht gewaltig, und der Server brauchte im Schnitt bis zu 20 Sekunden um die Seite zu laden. Also entschloss ich mich lieber nur bis ca. 150 verschiedene Tags darstellen. Zum Glück ist UTW in der Hinsicht so intelligent aufgebaut, dass es die am meisten verwendeten Tags nimmt, anstatt die ersten 150 Tags in die Liste zu packen. Und wenn man den Wert „0“ weglässt, würde der default-Wert mit 150 sowieso schon durch das Script verwendet werden… ;)
Seitdem ich auf den neuen Server bei HostEurope umgezogen bin, ist zwar alles schneller und auch die erhöhten Zugriffe wegen der nervigen Tammy-Sache machen mir auch keine großen Sorgen mehr… dennoch stellt sich eines heraus: Massive Spamangriffe mittels der Trackback-Schnittstelle kommen mit Splogs auf Blogspot.com daher!
Geht es nur mir so, oder versuchen die Damen und Herren von und zu Spam sich dadurch an SpamKarma2 vorbeizumogeln, in dem sie nachschauen, ob schon gewisse Kommentare von „echten“ Blogspot-Usern im Blog sind? So kann der sogenannte Granularity Check von SK2 dazu führen? Hier einmal ein Beispiel:
- -19.36: 3 blacklist matches. (834 = blogspot.com [x3])
- 38.8: Commenter granularity (based on URL): 58 old comment(s) (karma avg: 8.030000), 1 recent comment(s) (karma avg: -62.450000).
Die anderen 58 alten Kommentare waren schon vor etlichen Wochen von validen Usern im Blog. Meine Lösung, damit die Spam Kommentare nicht wegen allzu hoher positiver Karma-Bewertung validiert werden, ist folgende:
In SpamKarma2 habe ich die Severity auf Total Beeatch gesetzt, und den Alarm des Link Counter schon bei mehr als einer Link in den Kommentaren anspringen lassen. So sieht das ganze dann aus:
- -3.99: Comment contains: 0 linked URLs and 2 unlinked URLs: total link coef: 1 >= threshold (1). Non-URL text size: 104 chars.
- -63.36: 4 blacklist matches. (843 = 202.88.129.254 [x1], 834 = blogspot.com [x3])
- -2: Severity settings adjustment.
Dadurch sind anscheinend die blöden Blogspot.com Spams in der Moderationsqueue bzw. der Recent Spam Harvest Liste gebannt und nicht veröffentlicht. Vorerst! Mal sehen, was so alles passieren wird…
Recently, I’ve installed and activated the new set of plugins „Structured Blogging“ for WordPress. At the moment, I’m not sure on how much I will use the features, but within a short time I’ll surely test and try out the new kind of articles found in the administration interface. Perhaps we’ll post reviews, event information, or just keep this blog up to date with a fancy podcast…? ;)
I have installed the Spam Karma 2.0 plugin instead of Bad Behavior now and am enjoying its amazing customizability. Bad Behavior sadly disallowed too many external webtools and it excluded some readers. This is not acceptable for me… especially since only one manual spammer ended up in my moderation queue in the last 24 hours with Bad Behavior being disabled! :(