toscho.design

WordPress-Tutorial: Ein Framebreaker-Plugin schreiben

Thomas Scholz — Sun, 28 Feb 2010 17:17:13 +0000

Ein Framebreaker ist ein kleines Javascript, das die Website in den Vordergrund hebt, wenn jemand versucht, sie in seinen Frame einzubetten.

In der einfachsten Variante steht das Script im head:

So wird die URL im Verlauf ersetzt und der Zurückbutton funktioniert weiterhin normal.

Nun kann nicht jeder WordPress-Benutzer frei an seinem Theme herumschrauben. Oft wird es aus anderen Quellen aktualisiert, und dann würde der Code überschrieben werden. Ein Plugin löst das Problem, indem es diese Funktionalität vom Theme trennt.

Dateien anlegen

Zuerst erstellen wir ein Verzeichnis framebreaker im Pluginverzeichnis; da legen wir eine PHP-Datei hinein, die wir passenderweise auch framebreaker.php nennen.
Der Dateiname spielt übrigens keine Rolle; er muß nur auf .php enden. Wir achten aber darauf, daß er von anderen leicht als ›Hauptdatei‹ erkannt wird, damit sich jeder schnell zurechtfindet. main.php wäre also auch ein passender Name, code.php eher nicht.
Es ist üblich, bei Datei- und Verzeichnisnamen nur Kleinbuchstaben, Zahlen und Bindestriche zu verwenden.

Wenn das Plugin aus nur einer Datei besteht, braucht es kein eigenes Verzeichnis. Für den Anwender ist es aber übersichtlicher, wenn jedem Plugin ein Verzeichnis entspricht, weil er dann im FTP-Programm nur den Baum aufklappen muß, um alle Plugins zu sehen.
Wollen wir bei einem späteren Update doch weitere Dateien hinzufügen – Icons, Sprachdateien oder eine Optionsseite – müssen wir ohnehin ›umziehen‹.

Metadaten

Der Kopf der Datei sollte so aussehen:

/*
Plugin Name: Framebreaker
Plugin URI:  http://toscho.de/2010/wordpress-tutorial-framebreaker-plugin/
Description: Baut ein Javascript in den HTML-Kopf, das die Website vor dem Einframen schützt.
Version:     0.1
Author:      Thomas Scholz
Author URI:  http://toscho.de
*/

WordPress genügt der Name; den Rest können wir technisch gesehen weglassen. Aber davon rate ich ab. Die Angaben helfen dem Nutzer, sich für oder gegen das Plugin zu entscheiden. Fehlen sie, sieht es schnell ›verdächtig‹ aus.

Falls wir unser fantastisches Plugin irgendwann auf wordpress.org veröffentlichen wollen, sollten wir jetzt schon nachsehen, ob eines mit diesem Namen existiert.
Die Suche nach ›Framebreaker‹ liefert bis jetzt noch keine Ergebnisse; wir können also weitermachen.

Der Name sollte eher beschreiben als unterhalten, die Hauptfunktion also klar wiedergeben. Wäre ›Framebreaker‹ schon weg, das bestehende Plugin dazu aber nicht so gut, daß wir unsere Arbeit fallen oder dort einfließen lassen wollen, könnten wir noch ›Break Frames‹ oder ›Frame Escape‹ versuchen. ›Luftjucker‹ klänge zwar deutlich amüsanter und ist sicher noch frei, aber danach sucht niemand.

Real gibt es natürlich schon eine Menge Framebreaker (in sehr unterschiedlicher Qualität); unser Plugin brauchen wir dort also nicht anzumelden.

Beim Auslesen der Metadaten wird noch kein Plugin-Code ausgeführt; wir können aber in der Beschreibung ein paar HTML-Elemente verwenden:

a[href][title],
abbr[title],
acronym[title],
code,
em und
strong

Die Beschreibung selbst sollte kurz und knackig sein, kein Roman. Zeilenumbrüche sind nicht erlaubt.

Alle Metadaten zusammen dürfen nicht mehr als 8 KiB beanspruchen.

Guter Stil

Benutze immer , um PHP zu öffnen, niemals Short Open Tags wie oder . In manchen Installationen funktioniert nur die ausführliche Schreibweise.


Laß das schließende ?> am Ende der PHP-Datei weg, damit sich keine Leerzeilen oder -zeichen einschleichen, die das berüchtigte Headers already sent auslösen.
Benenne deine Klassen und Funktionen stets so, daß sie wahrscheinlich nicht mit anderen Plugins oder gar dem Core kollidieren. Benutze im Zweifel function_exists() und class_exists().
Stelle niemals, wirklich nie, Variablen in den globalen Namensraum!
Schreib alles in UTF-8. Mit jeder anderen Zeichenkodierung wirst du ganz sicher Probleme bekommen.
Kommentiere ausführlich und benutze PHPDoc, aus dem man automatisch eine ordentliche Dokumentation erstellen kann.
Grundfunktion
Bisher kann man das Plugin nur aktivieren; es tut noch nichts.

Also brauchen wir zwei weitere Abschnitte: Eine Funktion, die den Javascriptcode ausgibt, und eine Angabe dazu, wo und wann sie ausgeführt werden soll.
Die Funktion ist einfach:
if ( ! function_exists('toscho_write_framebreaker') )
{
    /**
     * Inserts a javascript frame buster.
     * @return void
     */
    function toscho_write_framebreaker()
    {
?>


Wir wollen das Script in den Kopf des HTML-Codes schreiben; dort wartet in WordPress schon die Funktion wp_head() auf uns. Die steht in jedem ordentlichen Theme, meistens in der Datei header.php:




Wir finden die Funktion in der Datei wp-includes/general-template.php:
/**
 * Fire the wp_head action
 *
 * @since 1.2.0
 * @uses do_action() Calls 'wp_head' hook.
 */
function wp_head() {
    do_action('wp_head');
}
Zu Deutsch: Die Funktion löst einfach die gleichnamige Aktion aus. 
Filter und Aktionen
Hier kommen wir zu den beiden einfachsten Schnittstellen (Hooks) für Pluginautoren. Eine Aktion (action) wird zu einem bestimmten Zeitpunkt in der Verarbeitung ausgelöst, ähnlich dem Onclick-Event in Javascript. Manchmal, aber nicht immer, werden noch Variablen übergeben.
Ein Filter (filter) übergibt immer mindestens eine Variable – und er erwartet, daß die Filterfunktion sie nach dem Bearbeiten wieder zurückliefert.
Weit mehr als 1000 solcher Hooks bietet WordPress derzeit an; Adam R. Brown hält eine aktuelle Liste vor: WordPress Hook Database.
Wir können auch eigene Filter und Aktionen bereitstellen, damit andere Autoren in ihren Plugins und Themes unserem Code nicht hilflos ausgeliefert sind.

Wenn wir etwas direkt ausgeben, dann sollten wir immer einen Filter anbieten. Deshalb schreiben wir unsere Funktion jetzt ein bißchen um:
if ( ! function_exists('toscho_write_framebreaker') )
{
    /**
     * Inserts a javascript frame buster.
     * @return void
     */
    function toscho_write_framebreaker()
    {
        $script = '
';
        /**
         * To alter the script output just use
         * add_filter('toscho_write_framebreaker', 'your_function');
         */
        apply_filters('toscho_write_framebreaker', $script);

        echo $script;

        return;
    }
}
Beim Aufruf der Funktion apply_filters() sieht WordPress nach, ob jemand einen Filter für den ersten Parameter definiert hat. Wenn ja, dann wird er ausgeführt, ehe wir weiterarbeiten. Dieses elegante und mächtige Werkzeug ermöglicht eine reibungsarme Kommunikation zwischen Themes, Plugins und dem Core.
Den Framebreaker an eine Aktion binden
Jetzt bringen wir unser Plugin zum Arbeiten, mit nur einer Zeile nach der Funktion:
add_action('wp_head', 'toscho_write_framebreaker');
Wenn die Funktion do_action() mit einem Parameter aufgerufen wird, sieht WordPress wiederum nach, ob für diesen Parameter Aktionen angeboten werden. Wir könnten unser Plugin noch um eine eigene Aktion erweitern:
add_action('framebreak', 'toscho_write_framebreaker');
Dann könnte ein Theme-Autor in seine Vorlage schreiben:
do_action('framebreak');
Wird das Plugin deaktiviert, passiert dann einfach nichts. Ist es aber aktiv, wird der Javascript-Code ausgegeben.
Manche Plugin-Autoren stellen Ausgaben zur Verfügung, die man an beliebiger Stelle im Theme aufrufen kann. Genau dafür existieren eigene Aktionen.

Schlampig hingegen wäre dies:
if ( function_exists('meine_plugin_funktion')
{
    meine_plugin_funktion();
}
Das komplette Plugin
Im Ganzen sieht das Plugin – ergänzt um eine Lizenzangabe – jetzt so aus:
/*
Plugin Name: Framebreaker
Plugin URI:  http://toscho.de/2010/wordpress-tutorial-framebreaker-plugin/
Description: Baut ein Javascript in den HTML-Kopf, das die Website vor dem Einframen schützt.
Version:     0.1
Author:      Thomas Scholz
Author URI:  http://toscho.de
License:     GPL
*/

/*
Copyright 2010  Thomas Scholz  (email: info@toscho.de)

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License,
version 2, as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
MA  02110-1301  USA
*/

if ( ! function_exists('toscho_write_framebreaker') )
{
    /**
     * Inserts a javascript frame buster.
     * @return void
     */
    function toscho_write_framebreaker()
    {
        $script = '
';
        /**
         * To alter the script output just use
         * add_filter('toscho_write_framebreaker', 'your_function');
         */
        apply_filters('toscho_write_framebreaker', $script);

        echo $script;

        return;
    }
}

add_action('wp_head', 'toscho_write_framebreaker');

Testen
Jetzt aktivieren wir das Plugin. Wenn sich ein Fehler eingeschlichen hat, verweigert WordPress die Aktivierung, und wir sehen (meistens) die passende PHP-Fehlermeldung am Anfang der Plugin-Verwaltungsseite.
Wenn kein Fehler auftritt, laden wir jetzt unsere Startseite neu und sehen in den Quellcode: Richtig, da steht der Framebreaker.
Unser erstes Plugin ist fertig.
Naja … Software ist niemals ›fertig‹. Wir könnten beispielsweise noch Ausnahmen einbauen, die bestimmte Frames zulassen. Dank des Filters kann das zwar jetzt schon jeder tun, aber eine kleine Optionsseite dafür wäre handlicher. Vielleicht im nächsten Teil?
Lektüre

Writing a Plugin und Plugin Resources im Codex.
Olivier ›Ozh‹ Richard: Top 10 Most Common Coding Mistakes in WordPress Plugins.
Frank Bültge: WP - Tutorial, wir schreiben ein simples WP-Plugin - Teil 0 – von 2006, aber immer noch gute Lektüre.



WordPress: Länge der Artikelliste im Backend anpassen
Thomas Scholz — Wed, 24 Feb 2010 18:02:39 +0000
Markus gab heute im WP-Forum mal wieder einen guten Tipp: Die Menge der Artikel pro Seite im Backend wird über den Meta-Key edit_per_page in der Tabelle wp_usermeta gesteuert.

Abgefragt wird sie in der Datei /wp-admin/includes/post.php mit:
$posts_per_page = (int) get_user_option( 'edit_per_page', 0, false );
Die Funktion get_user_option() wiederum bietet einen Filter an:
apply_filters("get_user_option_{$option}", $result, $option, $user);
Und daraus folgt dieser kleine Eintrag in der functions.php, mit dem ich künftig 100 Artikel sehe, ohne die Datenbank anzufassen:
add_filter('get_user_option_edit_per_page',
    create_function('','return 100;'));
Das kann man noch an eine Abfrage des Userlevels binden, wenn man möchte. Mir reicht es so.
Strenggenommen gehört so eine Modifikation natürlich nicht ins Theme, sondern in ein Plugin. Andererseits möchte ich dafür nicht extra ein zusätzliches Plugin laden. Kompromisse, wohin man sieht …
Und noch strenger gesehen ist diese Option bereits vorhanden: In den Optionen der Artikelansicht. Dort findet sie aber kaum jemand, deshalb setze ich sie global.



WordPress-Dashboard: ›Approved‹ nicht ›Genehmigt‹
Thomas Scholz — Tue, 09 Feb 2010 12:34:03 +0000
Dank einer kleinen Schlamperei seitens der WordPress-Entwickler kann das Approved im Dashboard derzeit nicht per Sprachdatei ins Deutsche übersetzt werden.
Mich stört es nicht, einige Kunden aber schon.
Bis das behoben ist, kann man sich mit einem kleinen Workaround in der functions.php des Themes aushelfen:
add_filter(
    'ngettext',
    create_function(
        '$t,$s,$p',
        'return "Approved"== $p?"Genehmigte":$t;'),
    10, 3);
Keine Schlamperei, sondern Absicht: Dashboard wird weiterhin nicht ins Deutsche übersetzt. Auch diesen Bug kann man leicht reparieren, ohne die Sprachdatei anzufassen, wie auch das Submitted on:
if ( ! function_exists('toscho_translations') )
{
    function toscho_translations($str)
    {
        // Diesen Array bei Bedarf um weitere Übersetzungen erweitern.
        $trans = array (
            'Dashboard'     => 'Übersicht',
            'Submitted on'  => 'Eingereicht am'
        );

        foreach ( $trans as $original => $translation )
        {
            $str = str_replace($original, $translation, $str);
        }

        return $str;
    }
    add_filter('gettext', 'toscho_translations');
}
Und so sieht das Ergebnis aus:




Webdesign fürs iPad
Thomas Scholz — Tue, 02 Feb 2010 13:43:33 +0000
Der Bettvorleger ist gelandet. Apple hat am Mittwoch das iPad vorgestellt, ein Gerät, das die Nachteile eines Notebooks mit denen des iPhones kombiniert: Kein USB-Anschluß, kein DVD- oder BlueRay-Laufwerk, kein UMTS. Multitasking, das Ausführen parallel laufender Programme, geht auch nicht. Das einzige, das glänzt, ist das Display in einer Auflösung von 768×1024 Pixeln.

Viele Beobachter geben sich jetzt enttäuscht. So ein Wirbel um ein so langweiliges Spielzeug? Mich hat das nicht überrascht oder gar enttäuscht. Ich mache mit Apple ohnehin keine Geschäfte.

Aber für den Markt freue ich mich: Die Geräteklasse wird durch Apple eingeführt und bekannt gemacht, und jeder Konkurrent kann den Pionier leicht ausstechen. Es genügt ein USB-Anschluß und die Option, daß der Kunde im Gegensatz zum iPad seine Akkus selber wechseln kann, wenn er möchte. Packt man noch ein richtiges, mattes Display drauf und eine UMTS-Verbindung, dann kommt sogar ein mobiles Gerät dabei heraus.
Als Designer freue ich mich auch: Die Bildschirmbreite von maximal 1024 Pixeln wird all jenen auf die Füße fallen, die bisher Festbreiten gemeißelt und damit das Web verschmutzt haben. Real werden die Benutzer dieses Spielzeugs lieber hochkant lesen, also nur 768 Pixel bereitstellen. Gute Layouts passen sich dem an, schlechte werden einfach nicht mehr benutzt.
Wer jetzt erst auf ein modernes Layout umstellt, mag dies bedenken:

Auf einem Touchscreen sollten Links nicht zu dicht beieinander liegen. Finger treffen schlechter als eine Maus. Peter-Paul Koch hat dazu gerade ein bißchen geforscht: The touch action.

Das interessante Problem hierbei: Wer mit solchen Bildschirmmaßen kommt und doch eine Maus benutzt, der möchte keinen Platz für zusätzlichen Leeraum vergeuden. Vielleicht wird sich der iPad-Safari ja per Javascript zu erkennen geben, damit man den gezielt ansprechen kann.

Die Pseudo-Klasse :hover oder onmouse*-Events werden nicht angesprochen.
Eine horizontale Navigation sollte am Seitenrand umbrechen, sonst verschwinden vielleicht wichtige Elemente rechts hinter dem Bildschirmrand.
Bei Tageslicht liefert ein Spiegeldisplay schlechte Kontraste. Orangefarbene Links auf weißem Hintergrund beispielsweise dürften kaum noch zu erkennen sein.

Sehr lange Texte möchte sicher niemand auf weißem Hintergrund lesen. Hier kann man einen Styleswitcher anbieten, wenn das iPad keinen eigenen Regler mitbringt.

Safari, der Webbrowser auf dem iPad, unterstützt Media Queries ein bißchen. Das kann man so ansprechen:
@media screen and (max-device-width: 1024px)
{
    /* Horizontal */
}
@media screen and (max-device-width: 768px)
{
    /* Vertikal */
}
@media screen and (max-device-width: 480px)
{
    /* iPhone. Findet @media handheld nicht. */
}
Opera und Firefox verstehen das natürlich auch, im Gegensatz zu Safari sogar nach einer IE-Expression.
* html textarea
    {
        border:             expression(
            this.onfocus = function()
                {
                    this.style.borderColor = '#27b';
                },
            this.onblur = function()
                {
                    this.style.borderColor = '#888';
                }
            );
    }

@media screen and (max-device-width: 768px)
{
    /* Das liest Safari nicht. */
}

Auf dem iPad gibt es kein Flash. Dafür sollte normalerweise schon längst eine Alternative bereitstehen, aber oft sieht die eher peinlich aus. Safari versteht Javascript und Canvas; wer das nutzt, kann auf Flash oft verzichten.
Wenn der Safari als Mobilvariante installiert ist, dann kann er vielleicht kein position:fixed.




WordPress: WP-Cron begrenzen
Thomas Scholz — Sat, 30 Jan 2010 16:49:28 +0000
So sehr ich WordPress auch schätze – einige Macken gehen mir tüchtig auf die Nerven. Dazu gehören auch die vielen Requests auf wp-cron.php?doing_wp_cron.

Solch ein Request wird bei (fast?) jedem Aufruf einer Seite oder eines Artikels angestoßen. Zwar werden dabei kaum Daten übertragen, aber ein bißchen Zeit kostet es eben doch, und das Logfile wächst ohne Not.
Ich habe mir deshalb in die Konfigurationsdatei wp-config.php diese kleine Einschränkung eingetragen:
if ( 0 < (time() % 10) )
{
    define('DISABLE_WP_CRON', TRUE);
}
Zu Deutsch: Wenn sich der aktuelle, in Sekunden gemessene UNIX-Timestamp nicht genau durch 10 teilen läßt, verzichte ich auf WP-Cron.
Damit funktionieren noch die Kontrollen auf neue Plugin- oder WordPress-Versionen, doch die Menge der Requests schrumpft dramatisch. Wer noch weniger Aufrufe haben möchte, der erhöhe einfach den Teiler.
Natürlich könnte man die Pseudo-Cronjobs auch einfach komplett abschalten und einen richtigen Cron benutzen. WordPress sendet aber einen POST-Request, dessen Zusammensetzung ich nach jedem Update neu überprüfen müßte, um den echten Cron entsprechend anzupassen. Das ist mir zu umständlich.
Einen guten Überblick über die anstehenden Cronjobs bekommt man mit dem Plugin Cron View. Das sieht dann ungefähr so aus:

Wer gerne Plugins ausprobiert, sollte sich das unbedingt mal ansehen, denn nicht jeder Autor schreibt eine saubere Deinstallation.



WordPress: Grundeinstellungen per Plugin setzen
Thomas Scholz — Fri, 29 Jan 2010 19:23:06 +0000
Wer öfter mal ein WordPress-Blog installiert, weiß die vielen Einstellungsseiten nicht unbedingt zu goutieren. Ich habe mir dafür ein kleines Plugin geschrieben, das die wichtigsten Optionen auf einen Schlag setzt, die Blogroll (Linkliste) leert und die Dummytexte löscht:
Download Toschos Basic Settings.
/*
Plugin Name: Toscho's basic settings
Plugin URI: http://toscho.de/2010/wordpress-grundeinstellungen-per-plugin-setzen/
Description: Some useful default configuration settings. See 'wp-admin/options.php' for more options.
Version: 0.3
Author: Thomas Scholz
Author URI: http://toscho.de
*/

function set_toscho_defaults()
{
    global $wpdb;
    $o = array(
        'avatar_default'            => 'blank',
        'avatar_rating'             => 'G',
        'category_base'             => '/thema',
        'comment_max_links'         => 0,
        'comments_per_page'         => 0,
        'date_format'               => 'd.m.Y',
        'default_ping_status'       => 'closed',
        'default_post_edit_rows'    => 30,
        'links_updated_date_format' => 'j. F Y, H:i',
        'permalink_structure'       => '/%year%/%postname%/',
        'rss_language'              => 'de',
        'timezone_string'           => 'Etc/GMT-1',
        'use_smilies'               => 0,
        'start_of_week'             => 1
    );

    foreach ( $o as $k => $v )
    {
        update_option($k, $v);
    }

    // Delete dummy post and comment.
    wp_delete_post(1, TRUE);
    wp_delete_comment(1);

    // empty blogroll
    $wpdb->query("DELETE FROM $wpdb->links WHERE link_id != ''");

    return;
}
register_activation_hook(__FILE__, 'set_toscho_defaults');
Dieses Plugin aktivieren, deaktivieren und löschen. Fertig.
Nachtrag: Dieses kleine Plugin hat jetzt auch seine eigene GitHub-Adresse: http://github.com/toscho/WordPress-Basic-Settings.



CSS: Mit ::selection markierten Text hervorheben
Thomas Scholz — Tue, 26 Jan 2010 22:58:53 +0000
Das Pseudo-Element ::selection stand lange im Entwurf für die CSS3-Selektoren. Das ursprüngliche Ziel war: Die normale Gestaltung des Browsers für markierte Elemente sollte mit CSS ausgedrückt und überschrieben werden können.

Seit dem 10. März 2009 jedoch fehlt es, weil es zu schlecht definiert war und es zu aufwendig gewesen wäre, den Text konsensfähig zu verbessern.
Der alte Text im Wortlaut:
The ::selection pseudo-element applies to the portion of a document that has been highlighted by the user. This also applies, for example, to selected text within an editable text field. This pseudo-element should not be confused with the :checked pseudo-class (which used to be named :selected) 
Although the ::selection pseudo-element is dynamic in nature, and is altered by user action, it is reasonable to expect that when a UA re-renders to a static medium (such as a printed page, see CSS21) which was originally rendered to a dynamic medium (like screen), the UA may wish to transfer the current ::selection state to that other medium, and have all the appropriate formatting and rendering take effect as well. This is not required — UAs may omit the ::selection pseudo-element for static media. 
These are the CSS properties that apply to ::selection pseudo-elements: color, background, cursor (optional), outline (optional). The computed value of the 'background-image' property on ::selection may be ignored.

Ein paar Lücken springen sofort ins Auge:

Was soll eine »portion of a document« sein? Wenn ich beispielsweise im Zitat den unteren Teil des ersten Absatzes markiere und den oberen des zweiten: Wie sieht dann die Box des Pseudo-Elements aus? Oder sind es zwei Boxen? Was erwischt p::selection?
Wenn im markierten Text Generated Content auftaucht: Ist der dann Teil des Dokuments?
Kann der Selektor ::selection + ::before zutreffen? Und ::selection + ::selection?

Dennoch haben Opera und Webkit den Selektor implementiert, und Mozilla immerhin eine Variante mit dem -moz-Präfix.
Ich empfehle den Einsatz immer dann, wenn heller Text auf dunklem Hintergrund steht. Die normale Markierung kann der Leser sonst vielleicht schlecht oder gar nicht erkennen.
Beispiel:
.dark ::selection
    {
        color:      #000;
        background: #ff9;
    }
.dark ::-moz-selection
    {
        color:      #000;
        background: #ff9;
    }
Wir können die beiden Varianten leider nicht bündeln, denn der Browser muß eine Regel ignorieren, wenn er einen Selektor nicht erkennt. Mehr als Vorder- und Hintergrundfarbe kann man derzeit in keinem Browser ändern. Reicht ja auch.
Einen kurzen Test auf die oben genannten Lücken sollte man sich schon gönnen, aber im Groben kann nichts richtig schiefgehen.



Lächeln 0.9
Thomas Scholz — Mon, 25 Jan 2010 22:59:57 +0000
An vielen Social Networks des Web 2.0 – Twitter mal ausgenommen – irritiert mich immer wieder, wie wenig Humor man dort findet. 

Bei Facebook entsteht er eher unfreiwillig oder als Twitterimport.
delicious.com füttert gerade mal meinen Zynismus: 10435 Nutzer haben delicious.com als Lesezeichen gespeichert und 44136 sogar Google.
youtube.com glänzt mit dummen Kommentaren.
Bei Xing.com treten sich die Leute gegenseitig auf die Krawatten.
Und auf Google Wave kann man nur über Google Wave lachen.

Woran liegt das? Übersehe ich etwas? Fehlt mir der Humor?

Das Usenet habe ich lustiger in Erinnerung, ebenso IRC.

›Alte‹ Netzwerke, deren Teilnehmer vielleicht auch ob dieses Mangels nicht in die ›neuen‹ wechseln mögen …



Goodbye Google Wave
Thomas Scholz — Sun, 24 Jan 2010 18:28:06 +0000
Vor ein paar Tagen habe ich mich mal wieder bei Google Wave eingeloggt. Das kann ich jedem nur empfehlen, der sich von Twitter erholen will, von überquellenden Feedreadern und Todo-Listen, für deren Ausdruck man einen ganzen Wald niedermähen müßte.

Denn Google Wave ist der OBI des Internets: Zwischen Regalen voller Technik hört der Forschungsreisende allein das Echo seiner Schritte. Hier und da tappt noch ein Zombie durch die Gänge oder ein braver Ritter auf der Suche nach dem heiligen Blip.

Macht nix: Denen kann man leicht ausweichen, sie sind langsam. In Google Wave ist alles langsam, deshalb heißt es ja ›Echtzeitweb‹.
Foto: Lonely Monkey Ape at the Zoo von epSos.de
Wenn man doch mal jemandem begegnet, dann entfaltet Google Wave freilich seine ganze Pracht: 

Man kann einander beim Vertippen zusehen, sofern man in dieser Fitzelschriftwüste überhaupt etwas zu lesen vermag. 
Man kann »kollaborieren«, was ganz vermutlich etwas anderes ist als »kollabieren«. 
Man kann, das ist wirklich neu, miteinander chatten.
Und gemeinsam Dokumente erstellen kann man auch. Wenn man möchte – und auf einen brauchbaren Export ebenso verzichtet wie auf eine Versionsverwaltung. Aber die gibt es im »richtigen« Leben doch auch nicht. Nur im richtigen Internet. Dem von heute, von 2010.
Florian bringt es auf den Punkt:


Und auf welches Grab spucken wir nächstes Jahr?



Warum UTF-8?
Thomas Scholz — Sat, 23 Jan 2010 22:13:51 +0000
Manche Leute halten UTF-8 immer noch für Voodoo. Schade. Wer Textformate produziert, muß irgendwann 20 Minuten aufwenden, um die Grundlagen der Zeichenkodierung zu verstehen, und er sollte UTF-8 benutzen – und dabei wissen, was er tut. Warum?
UTF-8 ist eine Zeichenkodierung für Unicode. Damit können wir alle Zeichen aus Unicode benutzen, ohne sie zu maskieren: das deutsche Alphabet und das chinesische, Währungszeichen, Musiknoten, Pfeile und Schachfiguren.
In E-Mails mag UTF-8 noch nicht immer angebracht sein; im Markup jedoch können wir nicht mehr darauf verzichten:

In unseren Formularen wollen wir jedes Zeichen verarbeiten können. Wenn wir kein UTF benutzen, riskieren wir, wichtige Daten zu verlieren.
Alle XML-Parser müssen UTF-8 verstehen (und UTF-16). Newsfeeds, SVG, XSLT, RDF – all diese Formate sollten wir nur in UTF-8 oder UTF-16 schreiben, damit jeder sie gewiß verarbeiten kann.
Alle wichtigen APIs der großen Webdienste liefern UTF-8 aus: Flickr, Twitter, Youtube oder Delicious. Wenn wir diese Daten verarbeiten wollen, sollten wir uns nicht den Umweg einer Konvertierung zumuten.
UTF-8 ist im Unterschied zu UTF-16 bedingt kompatibel zu US-ASCII, denn alle ASCII-Zeichen werden deckungsgleich kodiert. Zeichen oberhalb des Dezimalwerts 127 freilich brauchen zwei Bytes. Deshalb ist es in allen Sprachen, die eine Variante des lateinischen Alphabets verwenden, sehr kompakt.
Die meisten Browser verwenden für Nicht-ASCII-Zeichen in URLs UTF-8. Wenn wir das nicht erwarten, werden wir unsere Besucher sicher bald frustrieren.
UTF-8 können wir validieren: So finden und reparieren wir falsch kodierte Zeichen, ehe der Leser sie sieht.
UTF-8 braucht kein BOM. Auch ein Vorteil gegenüber UTF-16 und UTF-32. Anleitung: Bom entfernen.

In einigen Programmiersprachen – Perl oder PHP beispielsweise – hängt die Implementierung der Multibytekodierungen noch ein bißchen. Aber mit ein wenig Lektüre können wir auch diese Probleme meistens lösen. Nie entschuldigen sie allein den Verzicht auf UTF-8.
Zu diesem Artikel wurde ich durch zwei Diskussionsbeiträge inspiriert: einen schlechten und einen guten. Der gute stammt von Björn Höhrmann, dem ich deshalb ausdrücklich danken will.