wordpress - 17.5.2004 - 21.1.2005

WordPress : Tackling Comment Spam ist eine recht vollständige Zusammenstellung der diversen Ansätze gegen Kommentarspam und Trackbackspam in WordPress.

WordPress NoFollow Plugin

The WordPress NoFollow Plugin adds rel="nofollow" to links in comments to remove their Google ranking. While I personally find it a shame that links in comments are generally not followed, thus removing the useful opportunity for smaller blogs to promote their own through active discussion in other blogs. Okay, in the end it's not that bad, but somehow a small piece of the "one link washes the other" mentality of blogs is lost... A small handicap is that the author has directly linked the plugin and unfortunately his server executes the PHP directly. At the moment, you can't download it, you only get an empty HTML page.

Anwärter auf den Preis für das absurdeste WordPress Plugin: ein Code39 Barcode Generator. Naja, vielleicht können dann ja Leute die Webseiten immer ausdrucken damit was anfangen

ChapterZero » IllustRender - man kann das vorige mit LaTeX auch ins Perverse treiben: der hier bindet über Ghostscript dann auch noch Grafiken ein ...

Using LaTeX in WordPress » LatexRender as a plugin - ja, es ist das was man vermutet: eine Einbindung von LaTeX in WordPress. Weird.

Morganically Grown » MiniPosts Plugin for WordPress - ein Plugin für Blogmarks - diese kleinen Titellosen Postings. Ich mach die noch mit einem gepatchten Template und einer eigenen Kategorie.

no status quo » RunPHP WordPress Plugin führt PHP-Code direkt in Postings aus. Damit kriegt man sowas wie < ?php echo "Makros"; ?> in Wordpress.

PHP Markdown - neuere Version als im Wordpress CVS. Ich hab Markdown aber abgeschworen - die Performance war stellenweise absurd hoch.

Blogs - die neue Geldmaschine?

Ein Plugin das ich sicherlich nicht installieren werde:

BlogMine enables content targeted ads in both feeds and web pages, simplifies and increases revenue generation for bloggers. The service provides a universal way to monetize all blog related content, regardless of whether it is published to the web or as an RSS feed.

Caching für PHP Systeme

Es gibt ja grundsätzlich zwei Wege wie man in einem PHP-basierten System caching betreiben kann. Ok, es gibt viel mehr, aber zwei Hauptwege sind deutlich erkennbar. Ich hab mal zusammengeschrieben was in dem Zusammenhang interessant ist - gerade weil im Moment ein paar Kollegen unter hoher Serverlast zu leiden haben. Das ganze ist allgemein gehalten, betrachtet aber aus begreiflichen Gründen auch die speziellen Folgen für WordPress.

• Caching von vorkompilierten PHP Seiten
• Caching von Seitenoutput

Zu beiden Hauptwegen gibt es eine ganze Reihe von Varianten. Die PHP Seiten selber liegen bei Webservern ja als Source vor - unverarbeitet und nicht irgendwie optimiert für den Ladeprozess. Hat man komplexe PHP Systeme laufen, fällt also bei jedem PHP-File das parsen und kompilieren in den internen Code an. Das kann bei Systemen mit vielen Includs und vielen Klassenbibliotheken durchaus beachtlich sein. An diesem Punkt setzt die erste Hauptrichtung des Cachings an: der erzeugte Zwischencode wird einfach weggespeichert. Entweder in shared Memory (Speicherblöcke die vielen Prozessen eines Systems gemeinsam zur Verfügung stehen) oder auf die Festplatte. Hier gibt es eine Reihe von Lösungen - ich selber setze turck-mmcache ein. Der Grund ist hauptsächlich das es nicht im shared Memory cached, sondern auf der Platte (was aber meines Wissens die anderen ähnlichen Lösungen auch tun) und das es für turck-mmcache ein Debian-Paket gibt. Und das ich bisher relativ wenig negative Erfahrungen damit gemacht habe (jedenfalls bei Debian stable - bei Debian testing sieht das anders aus, da fliegt einem die PHP Anwendung um die Ohren). Da WordPress auf einer grösseren Menge von Bibliotheksmodulen mit recht grossem Sourceinhalt basiert, bringt ein solcher Cache eine ganze Menge um die Grundlast von WordPress zu mindern. Da diese Caches in der Regel vollkommen transparent - ohne sichtbare Auswirkungen ausser der Beschleunigung - sind, kann man einen solchen Cache auch generell aktivieren.

Die Zweite Hauptrichtung für das Caching ist das Zwischenspeichern von Seiteninhalten. Hier kommt als Spezialität hinzu, das Seiten ja oft dynamisch abhängig von Parametern erstellt werden - und daher eine Seite nicht immer den gleichen Output erzeugt. Man denke nur an so banale Sachen wie die Anzeige des Benutzernamens wenn ein Benutzer angemeldet ist (und einen Cookie dafür gespeichert ist). Auch aufgrund von HTTP Basic Authentication (die Anmeldetechnik bei der das Popup-Fensterchen für Benutzer und Passwort kommt) können Seiteninhalte unterschiedlich sein. Und POST-Requests (Formulare die ihre Inhalte nicht über die URL mitschicken) produzieren auch wieder Output der von diesen Daten abhängig ist.

Grundsätzlich muss also ein Output-Cache diese ganzen Eingangsparameter berücksichtigen. Eine gute Strategie ist oft die POST-Ergebnisse garnicht zu cachen - denn dort würden auch Fehlermeldungen etc. auftauchen, die abhängig von externen Quellen (Datenbanken) sind und daher sogar bei identischen Eingabewerten unterschiedliche Ausgaben produzieren könnten. Man kann also eigentlich nur GET-Anfragen (URLS mit Parametern direkt in der URL) sinnvoll cachen. Hierbei muss man aber sowohl die gesendeten Cookies als auch die gesendeten Parameter in der URL berücksichtigen. Sofern das eigene System mit basic-Authentication arbeitet, muss auch das mit einfliessen in den Cache-Begriff.

Ein zweites Problem ist, das Seiten selten rein statisch sind - auch statische Seiten enthalten durchaus Elemente die man eigentlich lieber dynamisch haben möchte. Hier muss man also eine wesentliche Entscheidung treffen: reicht rein statischer Output, oder muss ein Mix kommen? Desweiteren muss man noch die Entscheidung treffen, wie sich Seitenaktualisierungen auswirken sollen - wie merkt der Cache, das etwas geändert wurde?

Ein Ansatz den man verfolgen kann ist ein sogenannter reverse-Proxy. Man packt einfach einen normalen Web-Proxy so vor den Webserver, das jeglicher Zugriff auf den Webserver selber technisch durch diesen Webproxy gezogen wird. Der Proxy steht direkt vor dem Webserver und ist somit für alle Benutzer verbindlich. Da Webproxies das Problem der Benutzerauthentifizierung, der Parameter und der POST/GET-Unterscheidung schon gut beherrschen sollten (in der normalen Anwendungssituation für Proxies sind die Probleme ja die gleichen), ist das eine sehr pragmatische Lösung. Auch die Aktualisierung wird von solchen Proxies meist recht gut gelöst - und im Notfall kann der Benutzer durch einen erzwungenen Reload den Proxy ja überreden die Inhalte neu zu ziehen. Leider geht diese Lösung nur dann, wenn man den Server selber unter Kontrolle hat - und der Proxy zieht noch weitere Resourcen, weshalb unter Umständen dafür kein Platz auf dem Server ist. Auch ist es stark von der Anwendung abhängig wie gut sie mit Proxies klar kommt - wobei Probleme zwischen Proxy und Anwendung auch bei normalen Benutzern aufstossen würden und deshalb sowieso gelöst werden müssen.

Der zweite Ansatz ist die Software selber - letzten Endes kann die Software ja genau wissen wann Inhalte neu erstellt werden und was für das Caching berücksichtig werden muss. Hier gibt es wieder zwei Richtungen der Implementierung. MoveableType, PyDS, Radio Userland, Frontier - diese erzeugen alle statische HTML Seiten und haben deshalb das Problem mit der Serverlast bei Seitenzugriffen nicht. Der Nachteil liegt auf der Hand: Datenänderungen erzwingen ein Neuerstellen der Seiten, was bei grossen Sites nervig werden kann (und dazu geführt hat das ich von PyDS auf WordPress gewechselt habe).

Die zweite Richtung ist das Caching aus der dynamischen Anwendung selber: beim ersten Zugriff wird der Output unter einem Cache-Key gespeichert. Beim nächsten Zugriff auf den Cache-Key wird einfach geguckt ob der Output schon vorliegt, wenn ja wird er ausgeliefert. Der Cache-Key setzt sich aus den GET-Parametern und den Cookies zusammen. Wenn Datenbankinhalte geändert werden, werden die entsprechenden Einträge im Cache gelöscht und damit die Seiten beim nächsten Zugriff neu erstellt.

WordPress selber hat mit Staticize ein sehr praktisches Plugin für diesen Einsatzzweck. In der aktuellen Beta ist es schon im Standardumfang mit drin. Dieses Plugin erzeugt wie oben beschrieben für Seiten einen Cache-Eintrag. Und berücksichtigt dabei die Parameter und Cookies - basic Authentication wird bei WordPress ja nicht benutzt. Der Clou ist aber, das Staticize die Seiten als PHP speichert. Die Cache-Seiten sind also selber wieder dynamisch. Diese Dynamik kann jetzt dazu benutzt werden um Teile der Seite mit speziellen Kommentaren zu markieren - wodurch für diese Teile der Seite dann wieder dynamische Funktionsaufrufe eingesetzt werden. Der Vorteil liegt auf der Hand: wärend die grossen Aufwände für die Seitenerstellung wie das Zuladen der diversen Bibliotheksmodule und das Lesen der Datenbank komplett erledigt sind können einzelne Teilbereiche der Site weiterhin dynamisch bleiben. Natürlich müssen die Funktionen dafür dann so aufgebaut sein das sie nicht das ganze Bibliothekswerk von WordPress brauchen - aber zum Beispiel dynamische Counter oder Anzeigen der gerade aktiven Benutzer oder ähnliche Spielereien lassen sich auch in den Cacheseiten somit weiter dynamisch halten. Matt Mullenweg benutzt es zum Beispiel um auch auf Seiten aus dem Cache ein Zufallsbild aus seiner Bibliothek anzuzeigen. Staticize löscht bei Erstellung oder Änderung eines Beitrags einfach den ganzen Cache - sehr primitiv und bei vielen Files im Cache kann das dann schon mal etwas länger dauern, aber dafür sehr wirksam und pragmatisch.

Welche Caches setzt man sinvollerweise jetzt wie ein? Ich würde bei komplexeren Systemen immer gucken ob ich nicht einen PHP Codecache einsetzen kann - also turck mMCache oder Zend Optimizer oder phpAccelerator oder was es sonst noch so gibt.

Den Anwendungscache selber würde ich persönlich nur dann aktivieren wenn er auch wirklich nötig wird durch die Last - bei WordPress kann man ja ein Plugin vorhalten und nur bei Bedarf aktivieren. Denn Caches mit statischer Seitenerstellung haben nunmal so ihre Probleme - Layoutänderungen sind erst nach Löschung des Cache aktiv etc.

Wenn man einen Reverse-Proxy einsetzen kann und die Resourcen auf der Maschine dafür auch ausreichen ist er sicherlich immer zu empfehlen. Alleine schon weil man so selber die Probleme mitbekommt, die in der eigenen Anwendung eventuell bezüglich Proxies drin sind - und die jedem Benutzer hinter einem Webproxy auch Ärger machen würden. Gerade wenn man zum Beispiel Zope benutzt gibt es sehr gute Möglichkeiten in Zope die Kommunikation mit dem Reverse Proxy zu verbessern - dazu ist ein Cache Manager in Zope verfügbar. Auch andere Systeme bieten dafür gute Grundlagen - aber im Endeffekt sollte jedes System das saubere ETag und Last-modified Header produziert und korrekt conditional GET (bedingte Zugriffe die mitschicken welche Version lokal schon vorliegt und dann nur aktualisierte Inhalte sehen wollen) behandeln geeignet sein.

Glossary für WordPress

Ich habe ein kleines Wordpress Plugin geschrieben das ein Glossary ähnlich wie bei Radio Userland oder PyDS implementiert. Mit dem Glossary werden einfach Texte die durch | (Pipe) Symbole begrenzt werden durch einen Ersatztext (der auch XHTML Markup enthalten kann) ersetzt. Spart Tipperei ...

Das Plugin installiert eine kleine Managementseite im Wordpress-Backend, das ganze funktioniert also nur mit Wordpress 1.5 (oder evtl. 1.3). Die nötige Datenbanktabelle wird nach Aktivierung des Plugins automatisch erstellt beim ersten Zugriff auf die Managementseite.

Kommentarspam

Da Kommentarspam auch bei Wordpress-Blogs in letzter Zeit vermehrt auftritt und ich nicht erst in den Spamtopf fallen muss um zu reagieren, habe ich mal vorsorglich Spam-Karma installiert. Das ist ein ziemlich mächtiges Tool bei dem man zum Glück einen Haufen Optionen auch abschalten kann. Ich hoffe das damit ein sicherlich irgendwann anstehender Sturm auf meine Kommentarfunktion abgewendet wird.

Natürlich hat so ein Tool immer auch potentielle negative Auswirkungen. Wer also keinen Kommentar los wird, es gibt immer noch das normale Feedback-Formular das dann eine ganz normale - und ungefilterte - Mail an mich absetzt. Sofern diese dann durch meinen Mail-Spamfilter durchkommt, weiss ich bescheid was los ist (bei 300-400 Spams am Tag alleine zu Hause kann ich nicht garantieren das ich eine fälschlich als Spam erkannte Mail bemerke - allerdings geht mir scheinbar recht wenig dabei verloren, statistische Spamfilter regeln halt).

Irgendwie schon strange wie wir unsere Kommunikationsmittel künstlich kastrieren müssen, nur weil Menschen grundsätzlich alles was auszunutzen ist auch irgendwann ausnutzen ...

Update: nachdem es einen Trackback vom Schockwellenreiter gefressen hat, hab ich es erstmal abgeschaltet. Das Hauptproblem dabei war, das der Trackback mit einer Meldung gefressen wurde, die angeblich in genau der von mir eingesetzten Version behoben sein soll.

Canned !! -- my Atropine » iG:Syntax Hiliter - und hier gleich noch ein Plugin für Wordpress das Geshi benutzt.

kasia in a nutshell: Spam breeds more spam

Kasia macht ein faszinierendes Experiment: sie lässt einfach mal zwei Kommentarspameinträge stehen und wartet das Google sie indiziert hat. Keine 24 Stunden später wurde dieser Eintrag bombardiert mit Spam - mehrere hundert Stück.

Man kann also daraus folgern das die Spambots zumindestens teilweise zweistufig arbeiten und das es wirklich um das Googleranking geht. Der erste Eintrag ist sozusagen ein Testeintrag. Bleibt er stehen so das er über Google wiedergefunden werden kann, ist es ein Eintrag wo man gut spammen kann - er ist unbeaufsichtigt und wird von Google schnell indiziert. Ideales Futter für Spammer.

Google ist also integrales Werkzeug und Ziel gleichzeitig für die Spammer. Man kann auf jeden Fall durch technische Abtrennung der eigenen Kommentare (so wie es mein altes Weblog hatte wo die Kommentare nicht nur auf einer eigenen Seite hinter einem Popup-Link waren, sondern zusätzlich auch noch auf einem ganz anderen Webserver) und durch Indizierungsverbot für diese Kommentaradressen den Spammern den Wind aus den Segeln nehmen. Man würde zwar von den Testproben noch erwischt, aber der gigantische Schwung hinterher sollte ausbleiben.

Das könnte unter Umständen auch die Probleme des Schockwellenreiters begründen: aufgrund seiner exponierten Stellung dürfte Google ihn sehr oft besuchen und wenn erstmal ein Spamkommentar länger stehen bleibt und indiziert werden konnte (kann ja auch nur durch Glück des Spammers passieren, der einfach kurz vor Googles Besuch gespammed hat) hat sich der Spammer den Server in die Spamlisten eingetragen. Im Prinzip muss er ja nur einmal den Schockwellenreiter über Google bezüglich seiner Testspams gefunden haben.

Jetzt müsste ich nur noch eine gute Idee bekommen wie ich das ganze für Wordpress umsetzen kann. Popupkommentare gibts schon, aber ich müsste das ja auch noch auf eine andere virtuelle Adresse legen und dort per robots.txt die Suchmaschinen ausschliessen.

sYp » Syntax Highlighting with Enscript in WordPress ist ein weiteres Plugin für Wordpress, das hier benutzt enscript zur Formatierung.

Validierung von Wordpress Postings und Kommentare - könnte ich mir mal angucken. Wenn man schon ein validierendes Weblog hat, sollte es ja besser auch so bleiben ...

Plugins/Staticize « WordPress Codex - Minianleitung zum Staticize. Nur geblogmarkt damit ich das mit dem mfunc wiederfinde.

Was ist denn hier passiert?

Tja, dem einen oder anderen wird es aufgefallen sein: hier hat sich was geändert. Und zwar habe ich mein Weblog von meiner eigenen Software - PyDS - auf WordPress umgestellt. Warum? Nunja, es gibt viele Gründe. Der nicht mal schlechteste ist: weil ich es kann. Die mehr technischen sind dann allerdings etwas komplizierter:

Es fängt an mit der Datenbank. PyDS benutzt eine recht eigenartige Datenbank, nämlich Metakit. Metakit ist nett wenn man kleine und kompakte Datenbestände hat, aber nicht so nett wenn diese wachsen. Irgendwann fängt es dann an sich seltsam zu verhalten. Unter Umständen schreddert es die Daten. Zwar bin ich mit meinen noch nicht ganz 4000 Artikeln da noch weit von entfernt, aber man muss es ja nicht herausfordern und auf den letzten Drücker an gehen, oder?

Dann ist da das Konzept von PyDS alle Artikel als statischen Content zu rendern. Das ist auch ganz klasse, weil die Dateien natürlich wesentlich schneller ausgeliefert werden als wenn sie aus einer Datenbank kommen. Dummerweise muss man bei knapp 4000 Beiträgen schon eine ganze Weile warten bis alles generiert ist, wenn man mal eine Layoutänderung macht. Ich hab aus dem Grund schon einen Cronjob der jede Nacht alles durchgeneriert. Aber irgendwie ist das trotzdem ziemlich gaga, also wech damit.

Ausserdem will ich mal irgendwann natürlich wieder auf eine eigene Software wechseln - aber dafür müsste ich so oder so die Daten migrieren. Jetzt habe ich sie nicht mehr in dem etwas wackeligen Metakit, sondern in MySQL. Ja, ich weiss, MySQL saugt tote Hamster durch verstopfte Strohhalme. Sag ich ja selber immer. Egal, es ist immer noch deutlich besser als Metakit. Und meine neue Software ist im Moment noch ein reines Hirngespinst. Ich weiss ja nicht einmal ob ich wirklich Lust haben werde das zu schreiben ...

Zusätzlich hat WordPress eine Reihe von netten Eigenschaften und PyDS wurde in der letzten Zeit doch ein bischen Barock in der internen Struktur - z.B. kann PyDS keine hierarchsichen Kategorien und die Kategorien von Blogmarks und Weblog überlappen sich. Jetzt ist alles in einem gemeinsamen Topf und gut ist.

Ansonsten habe ich WordPress ja schon länger im Einsatz gehabt und war mit der 1.2 sehr gut zufrieden - allerdings war sie noch von den Funktionen sehr spartanisch. Die 1.5 ist jetzt aber ein ziemlicher Hammer. Ok, noch ist es eine reine Beta, aber die ist schon gut genug für den normalen Einsatz. Ein paar kleine Bugs habe ich bisher bemerkt, nichts ernstes oder kritisches.

Schaun mer mal was passiert. Ich müsste alles mögliche aus dem alten Zeug umgeleitet haben auf das neue Zeug. Von daher sollten RSS Feeds weiter funktionieren und Links zu alten Postings sollten auch ordentlich umgeleitet werden. Wenn jemandem was auffällt das nicht tut und doch tun sollte oder sonstwas an Kommentaren fällig ist: ihr wisst wo ihr hier die Kommentarfunktion findet

Abgesehen davon hab ich ja PyDS schon seit fast 2 Jahren in Existenz. Da wirds Zeit das sich mal wieder was tut - PyDS selber wird natürlich weiterentwickelt. Und ist natürlich auch weiterhin verfügbar, daran ändert sich nix. Ich habe es ja noch bei diversen anderen Sites im Einsatz. Nur dieses Weblog-Monster hier ist einfach dem System entwachsen.

Deutsche WordPress Community

Zu Wordpress gibts eine deutsche Community Website mit Dokumentationen, Tipps und Tricks. Vielleicht für den einen oder anderen ganz interessant - ich krieg zwar immer noch von PHP Pickel, aber wenns schon PHP und dieser glorifizierte Index-File-Handler namens MySQL sein muss, dann doch bitte sowas wie Wordpress Hier gibts den Originalartikel.

Photo Matt - Bizarre Windows Behavior

Matt Mullenweg hat richtig Spaß an Windows: ein automatischer Security Update hat mal eben seine Rechner durchgebootet und seine Arbeit von ein paar Stunden gefressen. Irgendwie weiss ich, warum ich die Methode von Apple deutlich vorziehe, das mir nur gesagt wird das etwas da ist und nicht automatisch auf die Platte geschoben wird. Vor allem ist es absolut idiotisch, das ein automatischer Update an allen Anwendungsdialogen zur Speicherung offener Dateien vorbeirennt. Aber die ganzen Windows-Verfechter werden jetzt sicherlich wieder tausend Gründe liefern, warum das alles nur Schuld des Anwenders war. Matt ist übrigens kein DAU oder sowas - er ist der Programmierer von WordPress und normalerweise kann man bei ihm von einigermaßen Computer-Kompetenz ausgehen. Wenn selbst ihm das System mal eben die Daten frisst, wird das Feature wohl nicht so einfach oder offensichtlich abzustellen bzw. dokumentiert sein. Hier gibts den Originalartikel.

::jamesoff:: » Check RBL for WordPress 0.1 - Zugriffe auf Kommentare über RBLs prüfen - möglicherweise interessant, um von vornherein Zugriffe von Spammern zu filtern?

Internationale Domains und Wordpress

Weil Textpattern und die Browser so Probleme gemacht haben als ich auf einer internationalen Domain (son Teil mit Umlaut) TXP ausprobieren wollte, hab ich mal Wordpress benutzt. Mit dem habe ich ja schon einiges an Erfahrungen. Allerdings bisher nicht mit UTF-8 Zeichensatz und auch nicht mit internationalen Domains.

Ergebnis: der gleiche Fehler wie im TXP Admin - der Apache Header wird nicht gesetzt. Ziemlich blöd, da ja die Browser neuerdings - korrekt - dem Apache-Header den Vorzug vor dem Meta-Tag geben. Und wenn man in den Optionen die URL von der automatisch eingefüllten technischen Adresse (dieser xn-- Kram) auf die richtige internationale Adresse (also die mit Umlauten) umstellen will, gibts Probleme. Der Server macht einen Redirect, der nicht funktioniert. Korrigiert man diesen, tuts das ganze immer noch nicht - es wird einfach nicht gespeichert.

Übrigens funktioniert Wordpress mit Opera - dem einzigen Browser der korrekt mit internationalen Domains umgeht - nur sehr eingeschränkt. Sowohl das Layout macht Zicken als auch das oben beschriebene Problem ist auch bei Opera da.

Irgendwie hab ich das Gefühl, das man auf internationalen Domains besser kein CMS betreibt, sondern diese internationalen Domains nur als Redirector für die eigentliche Hauptdomain benutzt. Denn viel mehr funktioniert mit diesen doofen Dingern nicht verlässlich ...

Erste Eindrücke von Textpattern

Abgesehen davon, das ich erst das UTF-8 Handling in Textpattern reparieren musste und internationale URLs nicht vernünftig tun, so richtig beeindruckt bin ich von Textpattern nicht. Sorry. Aber irgendwie wirkt es auf mich recht unfertig. Klar, es ist ein CMS und nur nebenbei fürs Bloggen gedacht - aber wo ist ein Kalender? Wo ist eine zeitbasierte Navigation? Auch die dafür verfügbaren Plugins begeistern mich nicht sonderlich.

Images kann man hochladen - das ist ja das mindeste. Aber die Dateiextensions werden case-sensitiv geprüft. Und im Ergebnis kann man dann Bilder direkt von der Kamera nicht hochladen - unter OS X werden die nämlich in der Regel mit Grossbuchstaben in der Erweiterung kopiert. Ausserdem fehlt für Images auch nur das rudimentärste Handling - Thumbnails erstellen nach Vorgabe, Ordnerverwaltung etc. Das es Übersetzungen gibt, ist nett - aber warum sind die dann nur 90% vollständig? Hilfe gibt es auch - aber nicht an jedem Element. Klar, Hilfetexte sind aufwand zu schreiben. Aber wenn man Eingabefelder wie closet und cupboard in den erweiterten Optionen eines Beitrages hat, darf man sich über Fragen der Benutzer nicht wundern Dokumentation gibts fast keine - jedenfalls keine die ich hätte finden können. Ich meine so simple Sachen wie zu erklären was genau mit Sections und mit Categories erzielt werden soll.

Up-to-the-minute Hitlogs und Referrerlogs sind ja auch ganz nett - aber wieso zum Geier werden diese einfach nur roh präsentiert? Das hab ich schon in meinen Webserver-Logs. Wenn ich die Hits schon speicher, würde ich erwarten das sie intelligent gefiltert werden - z.B. Artikelverbindungen aufgelöst werden und Summen und Übersichten erzeugt werden. Sonst bringts nix.

Das Bookmarklet, was es für one-click-adding von Links da sein soll, hab ich nirgends gefunden. Ich find es praktischer wenn sowas als Link für Drag-and-Drop verfügbar ist. Wenn ich das erst irgendwo suchen muss, ist es irgendwie umständlich. Zumal man auf der textpattern Hauptseite nicht suchen kann. Und die Dokumentation eh nicht existiert, was das Suche in derselben natürlich erschwert ...

Und unter browser-based Plugin installation würde ich doch als Minimum erwarten, das ich nicht nur eine Datei angeben kann, sondern auch eine URL. Denn wozu soll ich ein Plugin, das ich aus dem Web auf einer anderen Website installieren soll erst auf meine Platte laden?

Die eingebaute Suchmaschine ist zwar ganz nett für den Besucher, aber sie sucht scheinbar nicht im Betreff. Warum nicht? Der Betreff ist doch prädestiniert für die Suche.

Alles in allem macht Textpattern einen sehr seltsam unfertigen Eindruck auf mich. Viele interessante Ansätze, aber im Gegenteil zu zum Beispiel Wordpress alle irgendwie nicht voll durchdacht. Nur angerissen. Schade, eigentlich - denn optisch macht Textpattern eine Menge her. Wordpress wird dagegen regelrecht prüde

New image gallery plugin - needs testers - Wordpress Plugin für Bilder an Postings

WordPress 1.2

Die finale ist draussen. Allerdings tuts das Trackbacken immer noch nicht so ganz richtig - jedenfalls wenn das Ziel ein Topic bei TopicExchange ist. Bei WordPress WordBlog gibts den Originalartikel.

WordPress Spielereien

Da ich ja im Moment mit Blog-Utilities und CMSen spiele, meine derzeitige WordPress Installation hat schon ein bischen Inhalt und Layout verpasst bekommen. Von den ganzen Alternativen für kleine Sites gefällt es mir noch am besten. Für drupal (mein momentaner Favorit für grössere Sites) find ich vielleicht auch noch einen Anwendungszweck.

Ich hab zu viel Domains und Sites? Ach watt.

Update: da ich mitlerweile dieses Blog mit WordPress betreibe und das andere veraltet war, hab ich das andere einfach eingestampft. Eine Site weniger zu pflegen ...

WordPress Support %u203A Static "like" pages - Diskussion über die Erstellung pseudostatischer Seiten (z.B. Impressum) in WordPress

WordPress Wiki - Comment Moderation Plugin - Kommentarbestätigung per eMail - könnte für TIMMY interessant sein

WordPress Wiki - WP Plugins - WordPress Plugins für das neue 1.2 Plugin Interface