spackblog

Zur Zeit arbeite ich an einem Wordpress-Projekt und bin nach der Umstellung auf PHP 5.3 (vorher war versehentlich PHP 4 auf dem Webspace aktiv) über etliche Deprecated-Warnungen gestolpert. Die explizite Zuweisung von Objekten per Referenz (also mit =& statt dass das Objekt mit = geklont wird) in der wp-settings.php ist schuld, denn dieses im Grunde erwartungskonforme Verhalten ist seit PHP 5 der Normalfall, Objekte werden jetzt nur noch geklont, wenn man explizit clone benutzt, so dass die explizite Zuweisung per Referenz überflüssig ist und angemahnt wird.

Nun ist es bei einem guten Hoster ein Handgriff ein, die E_DEPRECATED-Warnungen in der php.ini zu unterdrücken, von daher ist das alles halb so wild. Die Sache ist aber ein Symptom eines großen Dilemmas: Will man – aus welchen Gründen auch immer – kompatibel zu PHP 4 bleiben, muss man manchmal Code schreiben, der in PHP ab 5.3 eine Deprecated-Warnung wirft. Das TYPO3-Backend beispielsweise warf bis vor kurzem (vielleicht auch immer noch) ebenfalls Unmengen an Deprecated-Warnungen, weil es intensiven Gebrauch von eregi-Funktionen macht. Die kann man mit gutem Geschwindigkeitsgewinn und ohne Schwierigkeiten mit PHP 4 gegen preg-Funktionen austauschen, hier ist es also lediglich eine Sache von Fleiß; ganz davon abgesehen, dass TYPO3 sowieso seit Jahren kein PHP 4 mehr unterstützt. Die Sache bei Wordpress und einigen anderen Projekten mit Objektorientierten Elementen ist aber eine Zwickmühle.

Wobei es in meinen Augen keineswegs eine Zwickmühle ist, da die Lösung auf der Hand liegt: Man wirft einfach den PHP 4 Support über Bord und hält die Anfeindungen einiger Ewiggestriger aus, die nicht wissen, wie sie bei ihren Webspace eine aktuelle PHP-Version umstellt. Diese Anfeindungen kommen leider vor, und sind einer der Gründe, wieso ich zu Serendipity keinen Code mehr beitrage. Serendipity bewahrt wie Wordpress noch immer die PHP 4 Kompatibilität und steht einer zukunftsgerichteten Weiterentwicklung damit massiv im Weg. Wordpress wird wohl ab Version 3.0 (also ab demnächst) PHP 5 vorraussetzen, damit es endlich nach vorne gehen kann. Das ist im Falle von Wordpress auch bitter nötig, wenn man sich den mitunter grauenerregenden Code anguckt. Die aktuelle Beta 1 wirft aber leider immer noch die Deprecated-Warnungen.

Es gibt so etwas wie Codehygiene. Ich frage mich, wieso sich so viele Softwareprojekte mit aller Macht dagegen stemmen, ihren Code ein wenig zu warten. Eregi-Funktionen gelten schon seit mindestens fünf Jahren als um Größenordnungen langsamer, als ihre preg-Pendants. Wieso zur Hölle liest man dann als Abhilfe für Deprecated-Meldungen immer und überall, dass man die Warnungen ausschalten soll? Wo ist das Problem, sich einmal eine Nacht hinzusetzen und die veralteten und langsamen eregi-Funktionen zu eliminieren? Wieso wird unter Verzicht auf fundamental wichtige Programmiertechniken der Objektorientierung auch mehrere Jahre nach Einstellung des Supports für PHP 4 so sehr daran geklebt? PHP 4 ist veraltet, langsam und behindert massivst eine saubere Programmierung. Das ist sogar so offensichtlich, dass es jedem auffallen müsste, der nur ansatzweise objektorientiert mit PHP programmiert. PHP 4 fehlt es an fundamentalen Funktionalitäten an allen Ecken und Enden, nicht nur bei der Objektorientierung. Bitte, hört auf mit der falsch verstandenen Rückwärtskompatibilität und blickt mal nach vorne.

P.S. Ich bin übrigens latent auf der Suche nach einem neuen Blogsystem. Serendipity möchte ich den Rücken kehren, weil sich an der Front scheinbar nichts mehr tun wird. Auf PHP 5 umstellen? Neue Programmierkonzepte zulassen? Nix da, alles bleibt, wie es ist. Ein System, dessen Core so ungerne angefasst wird, ist nicht meins. Davon abgesehen, dass der Core in meinen Augen sowieso gar kein HTML ausgeben sollte. S9Y ist super stabil und funktioniert bei mir seit nunmehr fast sechs Jahren ohne jedes nennenswerte Problem vor sich hin, aber in etwa so lange hat sich auch nicht mehr wirklich etwas nennenswertes weiter entwickelt; das stimmt zwar nicht ganz, aber die Änderungen blieben insgesamt doch sehr dezent. Wordpress ist leider keine Alternative, auch wenn das Backend großartig ist. Ein Blick in den Core an beliebiger Stelle sollte ausreichend Anlass geben, das System nicht zu wollen. Was ist eigentlich aus Habari geworden?

Aktuell gibt es im Zuge der HTML5-Spezifikations-Diskussion eine in meinen Augen völlig überflüssige Unterdiskussion: Soll man HTML oder XHTML schreiben? Der von mir geschätzte Eric Eggert argumentiert pro HTML und hat gute Argumente im Gepäck, die ich jetzt nicht noch mal wiedergeben mag. Ich selber schreibe seit Jahren strikt nach XHTML-Syntax mit dem DOCTYPE XHTML 1.0 Strict, liefere aber als text/html aus, was schon immer widersprüchlich war und sich mit HTML5, dessen DOCTYPE ich seit einiger Zeit nur noch verwende, ja sowieso erledigt hat. Deswegen und weil in meinen Augen korrekter Code sowohl in HTML als auch in XHTML gültig ist (bzw. funktioniert), halte ich die Diskussion für überflüssig. Echtes XHTML scheidet in der Praxis wegen des IEs und weil ein wohlgeformtes XML-Dokument faktisch nicht dauerhaft und zu jedem Zeitpunkt sicherzustellen ist, sowieso aus. Auch ich selber übersehe gelegentlich solche Fehler und dann würde das rendern der ganzen Seite abbrechen. In Atom-Feeds sieht man ja, wie lästig das ist: Ein Tippfehler oder auch nur eine benannte HTML-Entity im Dokument (hallo an die WYSIWYGs dieser Welt) und der Feedreader verarbeitet den ganzen Feed nicht mehr, na vielen Dank.

Für wichtig halte ich aber die Frage, ob man die SGML-Freiheiten von HTML nutzt oder sich Mühe gibt, sauberen und wohlgeformten XML-Code zu schreiben. Und da sehe ich den großen Schwachpunkt von HTML: Hier sind syntaktische Konstrukte erlaubt, die mir den kalten Schweiß auf die Stirn treiben und die wirklich niemand benutzen sollte. Aber auch schon so Dinge wie ungequotete oder fehlende Attributwerte kann ich nicht ertragen. All das ist in HTML erlaubt und was erlaubt ist, wird von irgendwelchen Leuten und vor allem WYSIWYG-Editoren auch genutzt. Das war der Grund, wieso ich meine Dokumente stets als XHTML 1.0 strict deklariert habe: Solche schlechten Angewohnheiten müssen zumindest vom Validator bemängelt werden. Dass die Browser so fehlertolerant sind ist in der Praxis ja schön, aber es verleitet eben auch zu krudem und unverständlichen und fehleranfälligem Code. XML-Syntax ist letztlich wegen der strikteren Regeln deutlich einfacher zu erlernen und zu nutzen: Klare Regeln sind hier immens von Vorteil für alle, das merkt man spätestens, wenn man Menschen an HTML und allgemein Auszeichnungssprachen heranführt.

Also mein simples Fazit: Aktuell und in Zukunft deklariere ich als HTML5, schreibe aber in strikter XML-Syntax. Das ist in HTML5 gültig, für jeden verständlich und eindeutig und es geht mit gutem Beispiel voran. Wünschenswert wäre ein Modus in HTML5, dessen Syntax XML statt SGML nutzt (was sich im Validator ausdrückt), ohne gleichzeitig die Strenge von XML beim Parsen im User-Agent zu erzwingen. Warum basiert HTML5 überhaupt auf SGML? Wer hat was davon? Wer nutzt überhaupt die Freiheiten von SGML? Was spricht gegen eine HTML5 Spezifikation, die XML-artige Syntax vorschreibt, aber den Browsern Fehlertoleranz erlaubt?

Aktuell soll ja wieder mal der IE6 endlich sterben. In Norwegen sind einige große Nachrichtenseiten mit einer IE6-Warnung unterwegs und der IE6 Death March ist auch unterwegs. Ich verkaufe schon seit einiger Zeit IE6-Anpassungen nur noch als extra zu bezahlende Zusatzoption, wobei es bei mir dank semantisch sinnvollem Code hier nur um optische Feinheiten geht, die ich für entbehrlich halte. Wie auch immer: Bisher hat kein Kunde Aufpreis für den IE6 zahlen wollen. Geht doch.

Nun baue ich gerade meine Lifestream-Seite auf und befreie mich bei der Gelegenheit von jedem IE6-Mist. Meine Contentboxen hat der IE6 schlicht gar nicht angezeigt (wohl aber konnte man die unsichtbaren Links anklicken), so dass ich mich entschieden habe, dem IE6 und älteren Versionen einfach alle Styles vollständig wegzunehmen und stattdessen eine rote Alarm-Box einzublenden. Die Inhalte bleiben vollständig nutzbar, es sieht nur total scheiße aus. Sehr befriedigend, kann ich so den IE6-Nutzern doch etwas von der Hässlichkeit vermitteln, die dem IE6 innewohnt.

Zu diesem Zweck habe ich eine kleine statische PHP Klasse geschrieben, die ich hiermit gerne zur Verfügung stellen möchte. Wer Lust hat, kann die einfach für sich anpassen und in seine Projekte einbinden. Ich habe mich gegen eine clientseitige Lösung mit CSS und/oder JavaScript entschieden, weil ich "gute" Besucher nicht mit dem für sie sowieso unsichtbaren IE6-Code belasten wollte. Ich denke, das ist eine gute Idee.

Die Klasse ist recht simpel gestaltet und schreit geradezu danach, bei Bedarf verfeinert zu werden (mir reicht das erst mal so). Also in Kürze:

1. Einbinden der Klasse, etwa indem man den Code direkt in sein Projekt kopiert oder als Datei abspeichert und mit require_once('PFAD/fuck_ie6.class.php'); einbindet.
2. Da die Klasse statisch ist, muss sie nicht instanziiert werden. Man ruft also die drei statischen Methoden wo man sie braucht.
3. Folgende Methoden und Variablen stehen zur Verfügung:
   • fuck_ie6::is_ie6() gibt true zurück, wenn der Besucher mit einem IE4, 5 oder 6 unterwegs ist, sonst false. Praktisch, wenn man bestimmte Inhalte wie Stylesheets ohne Conditional Comments für diese Besucher aus- oder einblenden möchte. Im Prinzip ist das nur eine sehr simple RegEx.
   • fuck_ie6::print_style() und fuck_ie6::print_alert_box() printen den Inhalt der Variablen $alert_style und $alert_content in Abhängigkeit vom Browser des Besuchers. Die beiden Methoden ersparen einem also nur die if-Abfrage mit fuck_ie6::is_ie6() im Template ein.
   • Die beiden Variablen $alert_style und $alert_content enthalten den Style und den Code, die für die Alarm-Box genutzt werden sollen. Hier finden Anpassungen an die eigenen Wünsche statt.

<?php
/**
* a very simple static class for sniffing Internet Explorer 6 and below
*
* can detect whether the user comes with an annoying IE (version 4,5 or 6)
* additionally holds content and styles for a red alert box
*
* @author	Gregor Nathanael Meyer <Gregor [at] der-meyer.de>
* @license  http://creativecommons.org/licenses/by-sa/3.0/de/ Creative Commons cc-by-sa
* @version  0.1  first release
*/
class fuck_ie6
{
  /**
    * the style block used for the alert box
    * @static
    */
  public static $alert_style = '  <style>
  .errorBox {
    background: #fbe3e4;
    color: #8a1f11;
    border: 2px solid #fbc2c4;
    width: 80%;
    padding: 25px;
    margin: 0 auto;
    font-size: 1em;
    line-height: 1.3em;
  }
  </style>';
  
  /**
    * the HTML of the alert box
    * @static
    */
  public static $alert_content = '<p class="errorBox"><strong>Alarm:</strong> Offensichtlich bist Du mit einem alten Internet Explorer (6.0 oder älter) unterwegs. Da dieser Browser aus dem Jahr 2001 die auf dieser Seite genutzten modernen Webstandards nicht hinreichend unterstützt, habe ich das visuelle Beiwerk für Dich deaktiviert. Die Inhalte sind weiterhin erreichbar.</p>';
  
  
  /**
    * the IE6 detector function
    * uses just a simple RegEx to read the UA string
    * @static
    */
  public static function is_ie6()
  {
    return preg_match('#^Mozilla/4.0 \(compatible; MSIE [456]#i', $_SERVER['HTTP_USER_AGENT']) ? true : false;
  }
  
  /**
    * prints the style block in case of IE<=6
    * @static
    */
  public static function print_style()
  {
    if ( self::is_ie6() )
    {
      echo self::$alert_style;
    }
  }
  
  /**
    * prints the alert box content in case of IE<=6
    * @static
    */
  public static function print_alert_box()
  {
    if ( self::is_ie6() )
    {
      echo self::$alert_content;
    }
  }
}

Ein Beispiel könnt ihr bei meinem Lifestream sehen.

Scheiße. Ich binde in der Sidebar u.a. meine letzten identi.ca Dents ein, was an sich ne schöne Sache ist. Ich tue das nicht beim Nutzer mit einem JavaScript, sondern hole die bei Bedarf alle zehn Minuten aktualisiert mit PHP ab und binde sie direkt in meine Seite ein. Soweit so gut, alle wären zufrieden, wenn nicht… ja wenn ich nicht plötzlich in unpassenden Google-Treffern ertrinken würde. Was ist hier passiert?

Google indiziert gelegentlich mein Blog und nimmt alle vorgefundenen Inhalte (ausgenommen die in der robots.txt ausgeschlossenen Kategorien- und Tagseiten) in seinen Index auf. Leider passiert das auch mit den Inhalten in der Sidebar und besonders lästig, passiert das mit meinen dort nur temporär zu findenden identi.ca Dents. Dumm ist jetzt, dass jemand bei Google etwas sucht, was dort zu finden ist und Google zeigt auf einen zufälligen Artikel in meinem Blog, wo der gesuchte Content aber sehr wahrscheinlich durch die aktuellen Dents ersetzt wurde, also nicht mehr da ist. Das will niemand, wie kann man das also lösen?

Der naheliegendste Ansatz ist simpel: Ich binde die Inhalte nicht mehr via PHP Serverseitig ein, sondern liefere ein Script, auf dass sich der Browser des Besuchers die Dents selber hole und einbaue. Google sieht keine Dents mehr, alles ist geritzt. Allerdings mag ich solche JavaScript-Lösungen gar nicht, erzeugen sie doch einen nicht geringen und überflüssigen Overhead bei identi.ca und bei meinen Besuchern.

Die nächste Idee liegt ebenfalls nahe: Das ist eigentlich nur indirekt mein Problem, viel mehr ist es eine Unzulänglichkeit von Google, relevanten Inhalt auf meinem Blog zu finden. Wie kann man Google (immer stellvertretend für alle Suchmaschinen) also dabei helfen? Zwei Wege fallen mir da ein, die aber beide bisher noch nicht (ist das so?) unterstützt werden:

1. HTML5 bietet die praktische semantische Auszeichnung <aside>, mit der man nicht inhaltsrelevante Dinge wie die Sidebar auszeichnet. Allerdings klingt die Spezifikation eher so, dass dort Inhalte einer Randspalte hinein gehören, wie man sie etwa in Büchern findet, also durchaus relevanter Content. Semantisch hat man also nur vielleicht seine Hausaufgaben gemacht. Schaden tut es auch nicht, also werde ich das demnächst benutzen.
2. Das Mkroformat "Robot Exclusion Profile" könnte die Lösung sein. Hierbei werden Tags analog zu den ROBOTS Meta-Angaben mit entsprechenden Klassen versehen, die Hinweise auf die Verarbeitung durch Suchmaschinen liefern. Das scheint mir der richtige Weg zu sein, allerdings unterstützt meines bisherigen Wissens auf Basis einer zehnminütigen Recherche nach noch keine Suchmaschine dieses Mikroformat (seit 2005 im Entwurfsstatus). Zu allem Unglück hat Yahoo eine abweichende Variante implementiert: class="robots-nocontent". Na vielen Dank, zwei voneinander abweichende Methoden… Und Google? Ich konnte keine Infos dazu finden und dank der zwei möglichen Methoden weiß ich jetzt nicht, welche ich vorgreifend für die Zukunft schon mal einsetzen soll. Yahoo ist bei mir ein eher seltener Referrer und ehrlich gesagt ist mir auch egal, was Yahoo so an Alleingängen macht. So hehr das Ziel von Yahoo auch ist, sind sie (zumindest in Deutschland) nicht in der Marktposition, eine neue Technik zu etablieren. Google muss das unterstützen, dann wird es praktisch relevant. Von Live Search brauche ich gar nicht zu reden, auch wenn ich von dort deutlich mehr (zumeist unpassende) Suchtreffer bekomme als von Yahoo.

Also Fazit: Außer meine Dents/Tweets per JavaScript einzubinden oder sie ganz aus meiner globalen Sidebar wegzulassen, ist mir aktuell keine praktisch relevante Möglichkeit bekannt, hierfür Google Hinweise für sinnvolle Suchtreffer zu geben und ich werde wohl weiterhin Scharen von enttäuschten Besuchern von Google bekommen.

Oder hat jemand eine gute Anregung parat?

Schon eine halbe Ewigkeit habe ich Pläne für ein Redesign meines Blogs im Hinterkopf herumgeistern, jetzt werde ich mich mal da dran setzen. Die Vorlesung ist durch, ich habe sogar schon Klausurfragen gebastelt (brauchen noch einigen Schliff), das Buchprojekt ist fertig (hoffe ich zumindest, mehr dazu in den nächsten Tagen) und ich bin heiß auf Neues. Die beiden Phenom II Rechner, die ich nächste Woche baue sind leider nicht für mich, deswegen muss was andere neues her. HTML 5 kommt mir da ganz gelegen. Entgegen der bisher vorherrschenden Meinung, kann man Einiges daraus bereits jetzt – wenn auch unter Vorbehalt – nutzen und so wird mein erstes eigenes Blogdesign voraussichtlich intensiven Gebrauch der neuen Strukturtags von HTML 5 machen. Voll progressiv, ey! Ich bin gespannt, denn endlich wird es semantische Auszeichnungen für Dinge geben, die bereits zuvor hätten ausgezeichnet werden sollen. Dazu auch demnächst mehr. Wer nicht warten kann, kann ja schon mal in den aktuellen Stand der HTML 5 Entwicklung reinschnuppern und etwa etwa hier mal gucken, was man aktuell schon benutzen könnte.

Vielleicht nehme ich bei der Gelegenheit auch gleich eine neue Blogsoftware her, ich habe da schon eine im Blick. Der S9Y-Importer mag allerdings bisher keine Tags importieren, was ein ziemlicher Showstopper ist. Mal schauen, ob ich das einfach fixen kann. Irgendwelche Tipps, welche vielversprechende Blogsoftware ich meine?