Beiträge

Gestern habe ich testweise das Ratings Plugin auf unserem neuen Baby getestet. Das Ergebnis war recht desaströs… Dieses Plugin ist so grottenschlecht programmiert, zumal ich nirgends in meiner WordPress 2.0.3 (de) einen Link zur Administration oder sonstigem gefunden habe, mit dem sich das Rating für einen Artikel jeweils konfigurieren lässt. In der One-Click Installation wird das Rating nach dem Zusatz des Custom Fields namens „rating“ schon hässlich aktiviert und zumindest bei mir lief danach gar nichts mit dem Rating. Sofern man nicht irgendwelchen PHP Code per Hand in der Plugin-Datei deaktiviert, und alles mit dem direkten Aufruf der Funktionen steuert, sieht es schon von vorn herein dämlich aus.

Aber auch mit den Funktionen und dem recht rudimentären Ansatz einer Dokumentation ist dieses Plugin das allerletzte, was man einsetzen kann. Wie kann man ein Rating in WordPress auf eine saubere Art einsetzen? Hat da jemand Erfahrung mit? Ich bräuchte ein paar gedankliche Ansätze… ;)

Angeregt durch die Diskussion im RA Blog wundere ich mich, was ihr alle so einsetzt.

  1. Das Urgestein – Bad Behavior
  2. Die Killerapplikation – Spam Karma 2
  3. Der Hausmeister – Akismet
  4. oder das Plugin vom Hausmeister für die Killerapplikation
  5. oder die individuelle Kombinationen der obigen Plugins?

Ich selbst habe den dritten Fall gewählt: Spam Karma 2 mit dem SK2 Akismet Plugin. Es erleichtert mir einfach die Arbeit, es ist nur ein Plugin (mit Sub-Plugin – wie auch immer) und so weniger Klicks zum administrativen Aufwand! ;) Wie schauts also bei euch aus, liebe Leser?

Ich hoffe ja, dass zumindest einer von euch treuen Lesern Ahnung davon hat, ob es irgendwie möglich ist, dass man WordPress einen eigenen User-Agent zum Setzen von Trackbacks oder Pingbacks zuweist? Bisher musste ich feststellen, dass WordPress anscheinend mit einem leeren Wert für den User-Agent hantiert.

Das nervt mich ein wenig, und schön wäre ja soetwas wie ein User-Agent im Stil von „WordPress ##VERSION## ##URL##“ als standardisierte Angabe. Gibt es soetwas? Oder vielleicht nur einfach ein Plugin, dass überhaupt einen User-Agent generiert bzw. zuweisen kann? Habt ihr irgendwelche Erfahrungen damit gemacht?

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!

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… ;)

Endlich. Ich habe die Fehler im Bereich der „Flickr Alben“ mit einigen kleinen CSS-Tweaks bereinigen können. Ganze zwei Tage hatte ich deswegen Kopfschmerzen, und es lag nur daran, dass ich eine CSS Datei komplett mit einem falschen Inhalt überschrieben hatte. Na super… es lag also nicht am WordPress Plugin FAlbum, sondern an meiner Wenigkeit! ;)

Also liebe Leser, falls irgendwas bei dem jetzigen Layout mit den zwei „Sidebars“ nicht pfunzen sollte, bitten wir um fleissiges Kommentieren.

Der Podcast kommt. Nur nicht heute. Ich muss 39 Euro aufbringen und dann nur noch das Griffin iTalk – iPod Aufzeichnungsgerät bestellen – sowas liebe ich ;)