Montag, 6. Februar 2017
[*]

WordPress-Updates vergessen .htaccess

, 23:31

Nachdem das Social Plugin von Mailchimp, das hier früher so schön die Reaktionen von Facebook und Twitter als Kommentare ins Blog importiert hat, zu funktionieren aufgehört hatte, habe ich mich ein wenig mit IndieWeb beschäftigt. Lange noch nicht tiefgehend genug, aber die Plugins funktionierten erstmal ganz gut und brachten meinem Blog Webmentions bei (wie z.B. hier zu sehen ist).

Doch am vorletzten Wochenende habe ich ein paar Updates installiert (sowohl für WordPress als auch für das Webmentions-Plugin), und am Anfang der letzten Woche kamen dann gar keine Webmentions mehr an. Bei Bridgy fand ich erstmal nur nichtssagende Fehlermeldungen.

Auf meinen frustrierten Tweet meldeten sich aber sofort freundliche Helfer, darunter der Autor des Webmentions-Plugins, und gemeinsam konnten wir der Ursache auf die Spur kommen: tatsächlich hatte Bridgy eine ordentliche Logdatei, aus der hervorging, dass mein Apache einen Serverfehler 500 zurückgibt:

0.1.0.2 - - [30/Jan/2017:00:42:03 -0800] "POST /_ah/queue/propagate HTTP/1.1" 304 1071 "https://brid.gy/retry" "AppEngine-Google; (+http://code.google.com/appengine)"

2017-01-30 08:42:00.032720 D Params: NestedMultiDict([('response_key', u'aglzfmJy...')])
2017-01-30 08:42:00.937850 I Source: Thomas Renger (Facebook) 10153250416376118, http://brid-gy.appspot.com/facebook/10153250416376118
2017-01-30 08:42:01.030590 I Created by this poll: http://brid-gy.appspot.com/log?start_time=1485727919&key=aglzfmJyaWQtZ3lyIwsSDEZhY2Vib29rUGFnZSIRMTAxNTMyNTA0MTYzNzYxMTgM
2017-01-30 08:42:01.130020 I Starting Response like tag:facebook.com,2013:10155005024956118_liked_by_10153108342655662 https://www.facebook.com/10153250416376118/posts/10155005024956118#liked-by-10153108342655662
2017-01-30 08:42:01.729090 I Webmention from https://brid-gy.appspot.com/like/facebook/10153250416376118/10155005024956118/10153108342655662 to https://dentaku.wazong.de/2017/01/29/digitale-albtraeume-teil-2/
2017-01-30 08:42:01.834260 I Using cached webmention endpoint u'W https dentaku.wazong.de': https://dentaku.wazong.de/wp-json/webmention/1.0/endpoint
2017-01-30 08:42:01.845109 I Sending...
2017-01-30 08:42:02.543940 W Error sending to endpoint: {'body': u'<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator,\n [no address given] and inform them of the time the error occurred,\nand anything you might have done that may have\ncaused the error.</p>\n<p>More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at dentaku.wazong.de Port 80</address>\n</body></html>\n', 'code': '...', 'request': u'POST https://dentaku.wazong.de/wp-json/webmention/1.0/endpoint (with source=https://brid-gy.appspot.com/like/facebook/10153250416376118/10155005024956118/10153108342655662, target=https://dentaku.wazong.de/2017/01/29/digitale-albtraeume-teil-2/)', 'http_status': 500}
2017-01-30 08:42:02.544750 W Propagate task failed

Aber vorher war das doch auch gegangen. Was hatte sich also geändert?

Nun, in der neuen Version war der API-Endpunkt für Webmentions in den Namespace der WordPress-REST-API hinein verlegt (wo er auch logisch hin gehört). Nach einigem Experimentieren fanden wir aber heraus, dass die komplette REST-API auf meinem Server nicht funktionierte — und zwar bei allen Blogs. Im Errorlog sah das dann so aus:

[Mon Jan 30 10:09:56 2017] [error] [client 0.0.0.0] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Mon Jan 30 10:09:56 2017] [debug] core.c(3116): [client 0.0.0.0] r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
...

Es brauchte einiges an weiterem Debugging um herauszufinden, was meine Installation von anderen unterschied: meine .htaccess-Datei stammte noch von der ursprünglichen WordPress-µ-2.9-Installation, in die ich die Blogs 2009 umgezogen habe. Die Unterschiede, die sich da über die Jahre ergeben haben, sind bei WordPress auch ordentlich dokumentiert, aber da steht leider nicht, dass mit den älteren Varianten einige neue Funktionen gar nicht … äääh … funktionieren.

Nachdem ich die zentralen Rewrite-Regeln von:

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

zu:

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L] 
RewriteRule ^(wp-(content|admin|includes).*) $1 [L] 
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L] 

„modernisiert“ hatte, funktionierte auch die REST-API. Und schon kamen die Webmentions wieder an.

Also Achtung! Überprüft auch Eure WordPress-Blogs mal, ob die .htaccess-Datei auf dem neuesten Stand ist, denn das Update aktualisiert sie nicht für Euch. Ruft mal ${euerblog}/wp-json/ auf und guckt, ob da ein JSON-String oder eine Fehlermeldung kommt.

Vielen Dank an @pfefferle für die Hilfe beim Debugging.

Freitag, 17. Juli 2015
[*]

Certificate Pinning funktioniert nicht

, 14:13

Wenn Webseiten verschlüsselte Verbindungen benutzen (https), dann wird zu Beginn des Kontakts dem Browser vom Server ein Zertifikat gezeigt, mit dem der Server versichert, dass er auch der richtige Server ist (und nicht irgendein Angreifer, der auf der Leitung steht). Die Ausstellung und Überprüfung dieser Zertifikate folgt einem hierarchischen Ansatz („X.509“), und die Liste der als vertrauenswürdig betrachteten Herausgeber sieht gar nicht so vertrauenswürdig aus, wie man sich das wünschen würde (siehe hier). Es gab immer wieder Fälle, in denen sehr neugierige Menschen sich von einer der zwielichtigeren Zertifizierungsstellen der Liste ein Zertifikat für eine bekannte Webseite organisiert haben. Sie konnten dann alles mithören ohne dass den Benutzern aufgefallen wäre, dass sie nicht direkt mit z.B. Google reden.

Eine Gegenmaßnahme für dieses Problem ist das Certificate Pinning: der Browser merkt sich für alle Webseiten, mit denen er sich schon einmal verbunden hat, das Zertifikat und schlägt Alarm, wenn ihm später ein anderes vorgezeigt wird (funktioniert natürlich nur unter der Annahme, dass die Verbindung nicht schon von Anfang an infiltriert ist, aber das nehmen wir einfach mal an).

Genau zu diesem Zweck habe ich jetzt ein paar Monate lang das Firefox-Plugin Certificate Patrol benutzt. Das Plugin funktioniert auch super, aber es bringt trotzdem keinen Sicherheitsgewinn.

Das liegt daran, dass viele größere Webseiten ihre Daten über Content Delivery Networks ausliefern, und dass die es mit den Zertifikaten nicht so genau nehmen: die über die ganze Welt verteilten Server, die Dateien für dieselbe Webseite ausliefern, scheinen oft jeder ein anderes Zertifikat zu benutzen.

Certificate Patrol bietet sogar noch die Möglichkeit, nicht schon bei einem bloßen Zertifikatswechsel zu warnen sondern erst dann, wenn das geänderte Zertifikat auch von einem anderen Herausgeber stammt, aber selbst diese geringe Integritätsbedingung halten viele CDNs nicht ein.

Wenn ich also mit Certificate Pinning im Web unterwegs bin, muss ich ununterbrochen Warnmeldungen lesen und wegklicken, lesen und wegklicken, lesen und wegklicken, und irgendwann nur noch wegklicken…

Ich werde deshalb Certificate Patrol wieder deinstallieren, denn wenn es mich irgendwann mal vor einem tatsächlichen Lauschangriff warnen würde, würde ich es wahrscheinlich nicht einmal lesen. 🙁

Freitag, 7. Februar 2014
[*]

Today is Pungenday, the 38th day of Chaos in the YOLD 3180

, 23:27

Einer der wazong-Benutzer trug den Feature-Request an mich heran, dass sein Blog die Datumsangaben bitte gemäß Diskordianischem Kalender anzeigen sollte. Das ist eine Funktion, die ich auch länger schon haben wollte, dafür müsste es doch ein Plugin geben — das hier ist schließlich WordPress.

Leider fand ich nur dieses: Discordian Date. Aber das konnte nur das aktuelle Datum in einem Widget darstellen. Na gut, dann musste ich eben selbst ran.

Ich habe mich also zwei Abende hingesetzt, und nun ist Version 0.1 meines kleinen Plugins fertig geworden. Es unterstützt bisher nur die ausgegebenen Daten an Artikeln und Kommentaren, hier zu sehen auf einer Artikelseite:

Screenshot mit Diskordianischen Daten

Um auch die Archivstruktur nach dem Gesetz der Fünf anzuordnen, muss ich noch tiefer in WordPress eingreifen. Das kommt später. Dafür habe ich mir Mühe gegeben, die Implementation so sauber wie möglich in die API einzufügen, damit das Diskordianische Datum genau so wie das Gregorianische Datum mit PHP-Formatstrings formatiert werden kann.

Für spätere Version habe ich noch folgendes auf der „Roadmap“:

  • Implementierung der noch fehlenden Formatstrings (z.B. Wochennummer, zweistelliges Jahr,…)
  • WordPress-Archive nach Diskordianischem Kalender
  • Apostelfeiertage und Monatsfeiertage
  • Sprachunterstützung (die soll abschaltbar werden, denn manche Leute mögen die Übersetzungen der Monate und Wochentage nicht)

Bis dahin Viel Spaß mit ddate Version 0.1!

Samstag, 4. Mai 2013
[*]

Entfernt endlich Java aus dem Browser!

, 00:08

Java ist eine mächtige Sprache mit vielen Vorteilen:

Eine ausgereifte Virtuelle Maschine mit robuster Unterstützung von Nebenläufigkeit, die in der Geschwindigkeit ohne den Einsatz maschinenspezifischen Codes schwer zu schlagen ist, und deren Verbreitung auf unzähligen Systemen das einst gegebene Versprechen „Write once, run anywhere.“ so gut wie möglich einlöst. Dazu gibt es einen bunten Strauß an APIs für alle möglichen Einsatzgebiete.

Alles könnte so schön sein. Seit einiger Zeit aber hört man alle paar Wochen bis Monate (gefühlt ist es alle drei Tage) Meldungen über Sicherheitslücken und Exploits. Die Lücken befinden sich praktisch immer in der Absicherung des Browserplugins, der sogenannten Sandbox, dabei wird das Plugin gar nicht mehr gebraucht.

Vor 10 Jahren ergab es durchaus Sinn, Java-Applets in Webseiten zu integrieren: während JavaScript (nicht zu verwechseln, merke: „Java verhält sich zu JavaScript wie Wal zu Walnuss.“) noch in einem echten Interpreter ausgeführt wurde und entsprechend langsam war, hatte Java bereits einen JIT-Compiler. Auf der damaligen Hardware war das ein echter Vorteil, zumal die verlängerten Startzeiten im Vergleich zur Downloaddauer über die damaligen Internetverbindungen kaum ins Gewicht fielen. Heute wird auch JavaScript vor der Ausführung kompiliert, und so bleiben nur die Nachteile:

Das Sandboxkonzept ist bei der gegebenen Sprachmächtigkeit nicht in den Griff zu bekommen. Die JVM hat volle Unterstützung für Datei- und Netzwerkoperationen sowie Möglichkeiten zur dynamischen Erzeugung von Klassen, die diese Funktionen benutzen.

Die JavaScript-API in Browsern hat dagegen keinen schreibenden Zugriff auf das Dateisystem und kann im Netzwerk nur http-Verbindungen aufbauen. Nur mit einer Sprache, deren Laufzeitumgebung keine Konzepte der verbotenen Operationen hat, lässt sich eine halbwegs sichere Sandbox implementieren.

Das bedeutet nicht, dass es völlig unmöglich ist, auch aus der JavaScript-Sandbox auszubrechen, aber in Java muss der Angreifer nur die virtuelle Maschine austricksen, während er bei einer JavaScript-Lücke den systemspezifischen Maschinencode selbst einschleusen müsste. Während also JavaScript zum Ausbruch aus seinem Sandkasten ein Schäufelchen zur Verfügung hat, handelt es sich bei Java eher um einen Radlader. „Write once, run anywhere“ gilt bei Java eben auch für Exploitcode.

Die Konsequenz muss sein, Java komplett aus dem Browser zu entfernen — und das sage ich als Java-Entwickler. Beliebte und benötigte Java-Anwendungen wie Wordle oder ELSTER können genau so gut lokal als Programme installiert werden. Die JVM an sich ist nämlich nicht unsicherer oder sicherer als andere Laufzeitumgebungen, und es schmerzt, dass nach Jahren des „Java? Das ist doch viel zu langsam.“ sich jetzt „Java? Das ist doch viel zu unsicher.“ im allgemeinen Bewusstsein festsetzt.

Die Überlegungen gelten genau so übrigens auch für Flash.

Freitag, 12. Oktober 2012
[*]

Twitterpause

, 23:24

Dass Twitter die Richtlinien zur API-Benutzung enger zieht ist ja schon länger bekannt. Da ich aber eigentlich gerade keine Twitterclients entwickle, hatte ich den Zeitplan dieser Abschaltungen bisher nicht im Kopf.

Am Mittwochabend haben aber die Twitter-Tools, und damit die WordPress-Integration aufgehört zu funktionieren. Nun aktualisiert sich also mein Tweetarchiv nicht mehr, und meine in Twitter gekippten Gedanken scrollen vorbei und sind weg.

Es gibt eine komplett neue Version 3.0 der Twitter-Tools, in der die Zugriffe wohl auf in Zukunft noch unterstützte API-Endpunkte umgestellt sind. Die vorherige Version 2.4 hatte ich aber in vielen Punkten an meine persönlichen Bedürfnisse angepasst. Bis das wieder mit meiner Seite funktioniert, könnte etwas Zeit vergehen. Bis dahin versuche ich, Twitterpause zu machen, auch als eine Form des schwachen Protests.

Das ist aber nicht so einfach: mehrfach hatte ich heute bereits den Impuls, einen kurzen Gedanken mitzuteilen.

Entzugserscheinungen.

Montag, 12. März 2012
[*]

Plugin: Automatic Hashtags

, 14:46

Ich habe mir mal wieder ein kleines WordPress-Plugin geschrieben. Es fügt im Postinhalt gefundene Hashtags zu den Posttags von WordPress hinzu. Man schreibt also #Hashtag, und es wird das Tag Hashtag an den Artikel gehängt.

Wozu soll das gut sein? Es soll mit den üblichen Twitter-Plugins zusammenarbeiten. Leider klappt das ausgerechnet mit dem beliebten Twitter Tools nicht. Das setzt nämlich die Tags im letzten Moment vor dem Speichern noch einmal auf seine Liste. Ändert man aber in twitter-tools/twitter-tools.php in der Funktion do_tweet_post ungefähr in Zeile 515 wp_set_post_tags in wp_add_post_tags ändert, dann klappt’s:

function do_tweet_post($tweet) {
    global $wpdb;
    global $aktt;
    remove_action('publish_post', 'aktt_notify_twitter', 99);

[...]

    $post_id = wp_insert_post($data);
    add_post_meta($post_id, 'aktt_twitter_id', $tweet->tw_id, true);
    wp_add_post_tags($post_id, $this->blog_post_tags);
    add_action('publish_post', 'aktt_notify_twitter', 99);
}

In Zukunft sind hier also die Microblog-Einträge besser in die Taxonomie eingebunden.

Falls jemand das Plugin gebrauchen kann (es ist aber wirklich nur ein Zehnzeiler), kann es hier runtergeladen werden.

Donnerstag, 10. Dezember 2009
[*]

Sonderservice: WP-Plugin-Bugfix

, 00:29

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.

Dienstag, 27. Oktober 2009
[*]

Manchmal ist ein Patch ganz einfach

, 22:16

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.

Freitag, 9. Oktober 2009
[*]

MU!

, 09:49

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.

Dienstag, 18. August 2009
[*]

Mein erstes eigenes Plugin: WP-ExpandURL

, 23:04

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

Montag, 9. Februar 2009
[*]

EclEmma – Java Code Coverage for Eclipse
EclEmma is a free Java code coverage tool for Eclipse, available under the Eclipse Public License. Internally it is based on the great EMMA Java code coverage tool, trying to adopt EMMA's philosophy for the Eclipse workbench.
aus Delicious/steinhobelgruen

Tags , , , , , ,   Kommentare  Kommentare deaktiviert für EclEmma – Java Code Coverage for Eclipse
Montag, 26. Januar 2009
[*]

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

Tags , ,   Kommentare  Kommentare deaktiviert für Beyond TweetBacks: Introducing TweetSuite | Dan Zarrella
Mittwoch, 7. Januar 2009
[*]

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

Tags , ,   Kommentare  Kommentare deaktiviert für Tweetback Plugin for WordPress – bits’n’bleeps
Montag, 20. Oktober 2008
[*]

Benachrichtigung bei neuen Kommentaren – Abmahnung und ein bisschen Schuldgefühl (Advisign – Recht und Webdesign)
Das Abmahnen-bei-Kommentarbenachrichtigung-Problem eingehend beleuchtet.
aus Delicious/steinhobelgruen

Tags , , , ,   Kommentare  Kommentare deaktiviert für Benachrichtigung bei neuen Kommentaren – Abmahnung und ein bisschen Schuldgefühl (Advisign – Recht und Webdesign)
Montag, 20. August 2007
[*]

Verstecktes gezwitscher

, 09:05

Twitter ist… äh, naja, Twitter eben (obwohl: vor kurzem habe ich irgendwo das innovative Wort „Microblogging“ dafür gelesen). Die Twittertools von Alex King sind eine sehr hübsche Möglichkeit, den dort eingegebenen Quatsch in sein Blog zu integrieren. Leider zerfällt damit die Struktur — zumindest dann, wenn man es nicht schafft auch noch mindestens einen Artikel pro Tag „von Hand“ zu schreiben. Wenn man Leser hat, dann beschweren die sich.

Abhilfe schafft das Plugin Category Visibility: damit lasse ich jetzt das ganze getwitter in eine versteckte Kategorie laufen (naja, in der Kategorienliste links kann man immernoch draufklicken), und so taucht es nicht mehr zwischen den normalen Beiträgen auf, kann aber mit der Suchfunktion gefunden werden und ist im Feed drin.

Das gleiche mache ich jetzt mir der Kategorie Linkdump.