Viel älter als dieses Blog und sogar noch etwas älter als die Domain wazong.de ist quad-damage.de. Quad Damage gehört ta und seinen Brüdern ca und ja. In einem selbstgeschriebenen CMS entstanden dort ab Dezember 1999 mit der Zeit 44 Artikel über Computerspiele, Witze und Zeug. Außerdem gab es ein “Gästebuch”, das im November 2000 sogar lernte, Antworten hierarchisch darzustellen.

Quad Damage lebte zuerst auf einem Root-Server bei Strato, aber das war wohl nicht so der Hit. ta war zu der Zeit mein Kollege, und wir legten deshalb ein wenig Hardware zusammen und bastelten uns im Serverraum unseres Arbeitgebers so eine Art Rootserver. Später zog der komplette Inhalt dieses Servers zu Hetzner um, deshalb hat Wazong einen älteren Untermieter.

Lange Zeit tat sich dann nichts mehr, und irgendwann, bei einer Spamaufräumaktion, ging die Kommentarmaske verloren. Der letzte Eintrag im Gästebuch war vom 29. Dezember 2007. Bis dahin hatten sich aber immerhin 5762 Kommentare angesammelt.

Eigentlich fand ich es schon länger zu schade, diese Inhalte einfach brachliegen zu lassen, deshalb habe ich in der letzten Woche mit ein wenig SQL-Magie aus den alten Artikeln WordPress-Artikel und aus dem Gästebuch Kommentare zu einer WordPress(µ)-Seite gemacht. Aus einem der vielen Kubrick-Ableger habe ich ein Theme gebastelt, das sich dem Originaldesign optisch annähert. Die dahinterstehende Layout-Technik sieht natürlich heute ganz anders aus (Frameset und Tabellen gegen CSS-Boxen).

Also, fröhlichen Neustart!

08:12  Mist, die Spammer kommen jetzt am #NoSpamNX vorbei (6mal in dieser Nacht). Muss mir was anderes einfallen lassen. #
 Spam, WordPress    0

Schonmal eine WordPress-Installation auf eine neue MySQL-Version umgezogen? Gerade wenn man von Version 4.x auf Version 5.x wechselt, dann stehen anschließend oft in den alten Artikeln Worte wie “heißt” oder “größere”. Das liegt daran, dass WordPress irgendwann in der Vergangenheit (war das Version 2.3?) seine Datenhaltung auf UTF-8 umgestellt hat, ältere MySQL-Versionen aber noch keine saubere Zeichensatzunterstützung auf Tabellen- und Feldebene boten. Will man das reparieren, so muss man der Datenbank “verraten”, mit welcher Zeichencodierung die Daten in den Tabellenspalten gespeichert sind. Dazu habe ich das folgende Skript geschrieben, das von allen betroffenen Feldern die Zeichencodierung erst entfernt, um sie dann korrekt zu setzen:

alter table wp_comments change comment_author comment_author tinyblob;
alter table wp_comments change comment_author comment_author tinytext
            character set utf8;
alter table wp_comments change comment_content comment_content blob;
alter table wp_comments change comment_content comment_content text
            character set utf8;
alter table wp_links change link_name link_name varbinary(255);
alter table wp_links change link_name link_name varchar(255) character set utf8;
alter table wp_links change link_description link_description varbinary(255);
alter table wp_links change link_description link_description varchar(255)
            character set utf8;
alter table wp_links change link_notes link_notes mediumblob;
alter table wp_links change link_notes link_notes mediumtext character set utf8;
alter table wp_options change option_value option_value longblob;
alter table wp_options change option_value option_value longtext character set utf8;
alter table wp_posts change post_content post_content longblob;
alter table wp_posts change post_content post_content longtext character set utf8;
alter table wp_posts change post_title post_title blob;
alter table wp_posts change post_title post_title text character set utf8;
alter table wp_posts change post_excerpt post_excerpt blob;
alter table wp_posts change post_excerpt post_excerpt text character set utf8;
alter table wp_posts change post_content_filtered post_content_filtered blob;
alter table wp_posts change post_content_filtered post_content_filtered text
            character set utf8;
alter table wp_term_taxonomy change description description longblob;
alter table wp_term_taxonomy change description description longtext
            character set utf8;
alter table wp_terms change name name varbinary(200);
alter table wp_terms change name name varchar(200) character set utf8;
alter table wp_usermeta change meta_value meta_value longblob;
alter table wp_usermeta change meta_value meta_value longtext character set utf8;

Vielleicht hilft es ja jemandem…

Da habe ich mich mal wieder aus dem Fenster gelehnt und behauptet:

“wpcontact form kann keine umlaute.” kann man aber reparieren.

Nunja, schließlich verdiene ich mein Geld als Softwareentwickler. Da muss man sowas schon hinbekommen. Hier also, extra für Caschy, eine Version von WP Contact Form, die mit Umlauten zurechtkommt.

wp-contact-form.1.5.1.1+wazong.zip

Das ist natürlich schnell zusammengehackt, und deshalb gelten ein paar Randbedingungen:

• Der Mailserver muss 8bit-clean sein. Das sollte auf modernen Installationen kein Problem darstellen, aber ich sag’s lieber mal.
• Ich habe nur mit UTF-8 als Blogzeichensatz getestet. Es sollte auch mit anderen Zeichensätzen gehen, aber wer weiß…

Ansonsten: viel Spaß.

To the original developers: your plugin didn’t cope too well with accented characters (that happen to be common in German words). I patched a few things in wp-contactform.php to add Quoted-Printable-encoding to some header fields and removed input sanitization that I thought was over-done. Feel free to incorporate some or all changes into future versions.

Wie hier vor kurzem erwähnt arbeite ich (langsam!) an einer Umstellung der Wazong-Landschaft auf WordPress MU. Als erste Funktion, die dann aber wieder gehen muss, wollte ich heute YAPB angehen, war aber schon nach wenigen Minuten fertig:

Ersetzt man in yet-another-photoblog/lib/YapbImage.class.php in Zeile 674 (Version 1.9.22):

$phpthumb->setSourceFilename($this->uri);

durch

$phpthumb->setSourceFilename($this->systemFilePath());

dann geht es schon (zumindest auf einem WPMU im Subdomain-Modus): sowohl Bilder als auch Thumbnails werden in den richtigen (für die Blogs getrennten) Verzeichnisse abgelegt, Thumbnailgenerierung und EXIF-Anzeige funktionieren.

Was wahrscheinlich nicht funktioniert: YAPB als Siteweites Plugin in mu-plugins ablegen, so dass es automatisch für alle Blogs aktiv ist, denn das Plugin legt bei der Aktivierung Tabellen an. Aber das werde ich noch testen — und auch WPMU im Directory-Modus.

Ich spiele gerade mit WordPress MU, denn ich möchte dieses Blog gern mit dem und dem und dem (da läuft gerad der MU-Test) auf eine gemeinsame Platform setzen, außerdem möchte ich den Wazong-Benutzern ermöglichen, eigene Blogs aufzusetzen.

Damit das funktioniert, müssen natürlich erstmal alle Plugins, die ich hier jetzt im Moment benutze, mit der Multiblogversion zusammenarbeiten (oder ich muss einen Ersatz für sie finden). Zwei Sorgenkinder konnte ich schon ausmachen:

• YAPB findet die Bilddateien nicht wieder
• OpenID kann seine Einstellungen nicht speichern, funktioniert sogar möglicherweise garnicht (ohne Einstellungen schwer zu testen).

Ein paar andere Kandidaten funktionieren problemlos. Am Wochenende werde ich mal mit dem vim aufs PHP losgehen, und dann kann ich mehr dazu sagen, eventuell mit Patches für ein paar Problemfälle.

Dies ist mein erstes selbstgeschriebenes WordPress-Pluging. Es tut nicht viel; es verlängert die URLs wieder, die mit einem URL-Verkürzer verkürzt worden sind.

Das funktioniert so: für alle Links eines Posts werden beim Speichern von den Zielservern die Header abgerufen. Ist ein “Location:”-Header dabei, handelt es sich also um eine Weiterleitung, so wird die Adresse durch das Ziel der Weiterleitung ersetzt (als angenehmen Nebeneffekt korrigiert es dadurch auch “nichkanonische” URLs, also wenn man z.B. den / am Ende eines Verzeichnisses vergessen hat). Dadurch funktionieren die Links nach dem eventuellen Tod eines solchen Dienstes weiter, und Pingbacks funktionieren, wenn das Ziel der langen Adresse ein Blog ist.

Jetzt mag man fragen, wozu das gut sein soll, schließlich bräuchte man ja einfach nur keine verkürzten Links in seinen Artikeln einzufügen. Richtig nützlich wird das ganze tatsächlich erst, wenn Artikel auch von Nichtmenschen eingestellt werden (z.B. aus twitter). Das sieht dann z.B. so aus.

Also, wen’s interessiert: WP-ExpandURL 0.1

17:18  Den Patch gibt es schon: http://wordpress.org/support/topic/263012 #
 DiSo, OpenID, Patch, WordPress    0

17:07  Aaah, jetzt habe ich’s: das #OpenID-Plugin frisst alle Pingbacks. Toll, @diso … na ich bau mal einen Patch. #
 DiSo, OpenID, WordPress    0

12:46  @gissmog Auf dem Server sind — ääähm — mehrere WordPress-Installationen. #
 Hotfix, WordPress    0

12:46  @enypsilon Ich würd’s nicht drauf anlegen… #wp #hotfix #
 Hotfix, WordPress    0

12:38  nyx:/var/www# find . -name wp-login.php -print | xargs -l1 vi #
 Hotfix, WordPress    0

16:22  Lösche mal die jahrealten Entwürfe zu zwei Artikeln aus meinem WordPress. Die schreibe ich sowieso nie mehr fertig. #DgkoeFS #
 DgkoeFS, Prokrastination, WordPress    0

Ich bin nicht bei vielen Themen paranoid, aber den Verlust einmal angehäufter oder mühsam erzeugter Daten fürchte ich ständig. Dabei tippt man heutzutag ständig irgendwas in andererleute Server ein oder läd etwas auf andererleute Server hoch — fast immer auf kostenlosen Diensten, damit es von Freunden gelesen oder angesehen, weiterbenutzt oder kommentiert werden kann. Was passiert aber, wenn einer der Dienste plötzlich abgeschaltet wird (z.B. Pleite) oder Daten verliert (z.B. Datenbankcrash) oder Dinge löscht?

Außerdem ist all dieser “Content” natürlich im ganzen Netz verstreut und somit schwer wiederzufinden. Dieses Problem lösen zwar Aggregatoren wie lifestream.fm oder friendfeed.com, aber das sind ja schon wieder externe Dienste (s.o.).

Es gibt dazu nur eine Lösung: alles muss hierher. Und weil ich nicht twitter und twitpic und flickr und del.icio.us (und was noch alles) nachbauen möchte (wer außer mir würde das dann auch benutzen?), drum kopiere ich die Daten von dort in Zukunft hierher (bei Tweets und Bookmarks klappt das schon, am Rest wird noch gebaut) und passe die Darstellung an den jeweiligen Inhaltstyp an (Tweets brauchen z.B. keine Überschrift, Fotos sind einfach nur Fotos). Dadurch kann plötzlich auch alles verschlagwortet und kommentiert werden; eine Fundgrube für meine vergangenen Gedanken, eine Hirnerweiterung.

Die übrige optische Gestaltung habe ich nur wenig angepasst: Dunkel auf Hell liest sich leichter, und ich zwinge jetzt alle Leser zu dem Hochformat, mit dem die Seite ursprünglich entworfen ist (Ich weiß, das ist jetzt nicht mehr modern, aber mein Browser hat normalerweise DIN-Hochkant-Format — und zwar seit XMosaic 1.0. Warum machen die anderen Leute ihre Browser so breit? So breite Zeilen kann man doch sowieso nicht lesen). Dazu kommt noch eine deutlichere Trennung zwischen Inhalt und Metadaten, fertig ist das neue Design. Hier nochmal zum Vergleich: links “Wazong 2″ und rechts “Wazong 3″ (erstellt mit dem großartigen Browsershots):

Ein paar noch frühere Designs der Seite — aber leider nicht alle — kann man übrigens hier und hier sehen, und demnächst erzähle ich nochmal mehr über die Technik.

Schon länger angekündigt: hier wird mal wieder umgebaut (und dann auch gleich mal von WordPress 2.3.3 auf WordPress 2.7.1 umgestellt). Bitte nicht wundern, wenn es vorübergehend seltsam aussieht…

10:34  Viele Grüße nach Jena zu den WordPressies (oder WordPressern?). #wcj09 #
 Barcamp, Wordcamp, WordPress    0

Wer darf was? Benutzergruppen in WordPress (WordPress-Buch)
Wenig dokumentiert ist bis jetzt die Benutzerverwaltung von WordPress. Was man häufiger findet sind, Aussagen wie: der Admin darf alles, der Mitarbeiter nur schreiben usw. Aber auf welche Bereiche haben die einzelnen Benutzergruppen Zugriff und welche "Einsichten" haben sie in das Backend des Blogs?
aus Delicious/steinhobelgruen

Beyond TweetBacks: Introducing TweetSuite | Dan Zarrella
TweetBacks are great, but they’re just a single feature, the integration of Twitter and blogging can and should go much deeper than that.
aus Delicious/steinhobelgruen

Tweetback Plugin for WordPress – bits ‘n bleeps
Die Idee von Tweetbacks ist die, dass Tweets über ein Blog-Posting hier ebenfalls als Kommentare auftauchen – konkret realisiert bislang nur mit tinyurl.com, more to come. Heisst auf deutsch: Tweets die die Tinyurl zu diesem Posting beinhalten werden als Kommentar hier druntergesteckt.
aus Delicious/steinhobelgruen