Weil mich der Pepino gerade danach fragte hab ich mal mein Deep Link Finder Script online gestellt. Es ist ein einfaches Python Script. Sollte ab Python 2.2 laufen, möglicherweise sogar mit Python 2.1 (ist aber nicht getestet). Das Script wird im Source konfiguriert (ich hab Kommentare dazu geschrieben) und dann einfach mit mehreren Logfiles als Parameter aufgerufen. Es sammelt aus Apache Combined Logs raus welche Sites wie oft auf angegebene Dateitypen (konfigurierbar, eingestellt sind einige Bildertypen) deep linked. Es spuckt dazu ein HTML Fragment raus das man mit Header und Footer garnieren kann um es online zu stellen - zum Beispiel entstehen so meine Zeitgeist-Seite für Deep Links. Die anderen Seiten haben ähnlich aufgebaute Scripte, nur das halt Suchbegriffe und generelle Referrer eingesammelt werden.
Ich guck mir ab und an die Deep Linker Liste an und wenn dann da jemand auftaucht der recht viel deep linkt und kein Aggregator oder News-Service ist, dann kriegt derjenige ein entsprechendes Austauschbild vorgesetzt. Aber eben auch wirklich nur diese Sites. Mich stört das nämlich auch immer wenn mir in meinem Feedreader unterstellt wird ich sei ein Bilderdieb oder Traffic-Räuber
Hotel Falckenstein: Mach mir den Ackermann - und womit? Mit Recht! Diese Oberabzocker auch noch zum Honorarprofessor für Wirtschaftswissenschaften an der Frankfurter Goethe-Universität zu machen ist einfach nur eine Frechheit.
Was mir bei meinen Spielereien mit Drupal noch aufgefallen ist: im Unterschied zu WordPress ist das Datenbankmodell recht komplex. WordPress ist ziemlich stumpf - einfach ein paar Tabellen mit Daten drin, das meiste recht straight forward. Wenn man was ändern will kann man jederzeit auf SQL Ebene damit rumwurschteln und z.B. Importscripte, Reparaturscripte etc. schreiben. Alles wird immer on the fly ermittelt - Zähler, Listen etc.
Drupal hingegen benutzt recht aufwändige Caching-Mechanismen in der Datenbank. Auch Sachen aus dem Filesystem werden gecached. Dadurch hat man mit kleinen Scripten höheren Aufwand, da man wesentlich mehr Stellen berücksichtigen muss - mindestens den Cache beseitigen, damit er rekonstruiert wird. Auch ist das Datenmodell wesentlich stärker ausnormalisiert. Das ist natürlich gut vom Design her - aber für kleine Scripte natürlich aufwändiger, da man an mehr Stellen anpacken muss.
Das ist jetzt keine Wertung, nur eine Beobachtung - beides hat Vor- und Nachteile. Die Vorteile des Drupal-Ansatzes scheinen sich in der Performance zu zeigen, die nicht nur wegen der etwas aufgeräumteren PHP-Struktur etwas besser als die von WordPress scheint (wobei ich da keine harten Zahlen habe - erst brauche ich ein brauchbares Import-Script für meine Postings um mit gleichen Ansätzen zu arbeiten).
Was mir noch aufgefallen ist: die PostgreSQL-Unterstützung (ja, ich habs jetzt endlich laufen!) in Drupal ist definitiv hinter der von MySQL zurück. Zum Teil gibts mit PostgreSQL Fehlermeldungen die mit MySQL nicht auftreten. Zum Beispiel beim Passwort-Wechsel gabs Probleme weil ein nicht existentes Feld angesprochen wurde. Oder bei der Übersicht der im Newsreader abonnierten Quellen gabs ne Meldung weil ein nicht-aggregiertes Feld eines komplexen SELECTs nicht als Gruppierungsfeld aufgeführt wurde. Oder beim ersten Zugriff, wo für das Feld uid in der Tabelle sessions kein Wert angegeben wurde, obwohl es als NOT NULL deklariert ist. PostgreSQL ist halt deutlich pingeliger als der Karteikasten. Mit PostgreSQL wird man definitiv Hand an den PHP-Code legen müssen. Mal schauen, wenn ich fertig bin mache ich vielleicht mal einen Patch fertig, der diese Probleme behebt. Bis jetzt sinds nur Kleinigkeiten, die aber für Nicht-Programmierer durchaus eine Hürde darstellen können. Zum Teil basieren die aber sicherlich auch auf den etwas älteren Versionen aus der Debian Stable (z.B. ist das PgSQL API in PHP in neueren Versionen deutlich anders benannt als in der 4.1.2).
Wordpress file loading beschreibt in welcher Reihenfolge welche PHP-Files von WordPress geladen werden um eine Blogseite zu produzieren. Ganz interessant wenn man plant was zu verändern an Dateien - es gibt eine erste Orientierung wo man was finden könnte. Was allerdings auch auffällt: dafür das WordPress eigentlich recht schlanke Seiten produziert hat WordPress selber schon ganz schön Speck auf den Hüften
Wordpress to Drupal Migration Script - kann aber im Moment wohl nur von Karteikasten nach Karteikasten migrieren - eine richtige Datenbank als Ziel muss man ihm unter Umständen erst beipulen.
Update: naja, das Script macht wirklich nur die Übertragung der Postings. Keine Post-Slugs (also kein Erhalt der URLs), keine Kategorien, nix. Kann man vielleicht benutzen wenn man nur ein sehr einfaches WP-Blog hatte, aber ansonsten ist es doch arg mager. Und bei grossen Blogs fliegt es einem nach einer Weile mit einem Fehler um die Ohren - der erlaubte Speicher ist erschöpft. Denn PHP benutzt von der Kommandozeile die Einstellungen für das CGI - und auch da ist der Speicherbedarf begrenzt. Dazu kommt dann noch, das es keinerlei Duplikateerkennung hat und deshalb lustig beim zweiten Lauf alles nochmal importiert.
Klingt so als ob ich mir da wohl doch was eigenes schreiben müsste, wenn ich das ganze mal ernsthaft ausprobieren wollte.
wp-style-switcher ist ein simpler CSS-Switcher für WordPress der ohne JavaScript oder ähnliches auskommt.