Weblog

Leider ist die Implementation dieser interessanten und nützlichen Funktion in Wordpress eher unglücklich gelöst. Die Jungs von WPEngineer haben bereits im Februar vorbildlich darüber informiert, welche Klassennamen das Tag ins Markup rendert. Darunter befinden sich zahlreiche allgemein gebräuchliche Klassenbezeichnungen wie:

• archive
• author
• blog
• category
• date
• home
• page
• search
• tag

Das Problem bei der Verwendung derart gebräuchlichen Bezeichnungen sind fast zwangsläufig Kollisionen bei der Implementation bestehender CSS-Layouts in Wordpress. Gerade heute habe ich eine Mail zu diesem Thema bekommen:

Man kann sich ja mittlerweile im BODY-Tag CSS-Klassen einfügen lassen je nachdem welcher Typ von Seite aktuelle von WordPress ausgegeben wird. Dabei gibt es auch die Klasse “page” für die Seiten in WordPress. Resultat ist, dass sich das dann mit der Klasse “page” aus YAML überschneidet.

Ich kann im Moment froh sein, dass es nur eine CSS-Klasse von YAML trifft. Schon innerhalb dieses Bloglayouts hier – würde dieses Blog mit Wordpress laufen – würden weitere Klassenbezeichnungen kollidieren, denn ich verwende in meinem Bloglayout auch Klassenbezeichnungen wie “date” oder “category”. Nur sind diese Klassen in meinem Layout nicht dafür gedacht, an das body-Element geheftet zu werden. Nun könnte ich mein CSS-Framework YAML in einer nächsten Version natürlich anpassen, um der Kollision aus dem Wege zu gehen, aber ich halte dies für den falschen Weg, denn die Welt dreht sich nicht um Wordpress und YAML ist nicht allein von diesem Problem betroffen. Wordpress als Blogtool oder CMS sollte eigenständig kein Markup generieren (soweit die graue Theorie) und es sollte ebenso die Implementation bestehender Layouts nicht durch die Kollision von Klassennamen unnötig erschweren.

Ein relativ einfacher und unkomplizierter Lösungsweg heisst: Namespacing. Wordpress könnte allen dynamisch ins Markup generierten CSS-Klassen das Kürzel “wp-” voranstellen (oder dieses sogar im Backend konfigurierbar machen). Bei anderen Content Management Systemen (Bsp: TYPO3) kommt dieses Verfahren bei den meisten Extensions zum Einsatz. Auf diese Weise ließen sich die angedeuteten Probleme leicht vermeiden, während die durchaus sinnvolle Funktionalität weiterhin uneingeschränkt verfügbar bleibt. Leider bin ich selbst zu wenig bewandert in PHP und auch nur ein Gelegenheitsnutzer von Wordpress, dennoch hoffe ich, dass diese Idee auf irgendeinem Kanal an das Entwicklerteam herangetragen wird.

Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.

Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.

Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.

Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.

Templates / Themes / Online-Tutorials

• CMSimple
  • Template für CMSimple (basiert auf YAML 2.5.1)
  • Support-Forum [de|en]
• CMS Made Simple
  • YAML-Theme
• conceptCMS
  • Angepasste YAML-Versionen + Template Gut aufbereitet mit Integrationsbeispiel und Dokumentation
• Concrete5
  • "The Column Cruiser" Theme
• CoreMedia CMS
  • CoreMedia CMSDas Starter Kit enthält JSP-Templates für Standardlayouts auf YAML-Basis.
• Contenido
  • Online-Tutorial & PDF zur Implementation
• DotNetNuke
  • Skin auf YAML-Basis
• Drupal
  • Konfigurierbare YAML-Templates für Drupal 5.x und 6.x
  • Support-Forum [de]
  • Support-Forum [en]
• ExpressionEngine
  • eeSiteKit 2.0 eeSiteKit ist eine Layouterweiterung für ExpressionEngine mit vollständiger YAML-Integration
    
• Joomla
  • JYaml-Template (umfangreich konfigurierbar)
  • Support-Forum [de]
  • Support-Forum [en]
• MODx
  • Online-Tutorial (engl.)
• OLAT
  • OLAT - Open Source LMS Learning Management Software mit YAML-Template-Support
• OpenPublisher
  • OpenPublisher PHP5 Content Management System
• papaya CMS
  • Template- und Themeset dr-yaml (basierend auf YAML 2.5.1)
• Papoo
  • CMS mit YAML-Integration
• phpwcms
  • Online-Tutorial & Beispielimplementationen
• openEngine
  • knappes Online-Tutorial
• Redaxo
  • Beispielimplementationen für Redaxo 3.x und 4.x
• TYPO3
  • Templates für TemplaVoila Komplettpaket (ehem. YAML für TemplaVoila)
  • Templates für TemplaVoila (db_ttv 4.0.4)
  • YAML für Autoparser
  • YAML Framework für TYPO3 (fdfx_yaml)
  • local settings for fdfx_yaml (fdfx_yamllocal)
  • Support-Forum [de]
  • Support-Forum [en]
• TYPOlight
  • YAML Integration in TYPOlight (Tl_Yaml)
  • Spaltenset-Erweiterung (subcolumns)
  • YAML-Werkzeuge (yamltools)
  • WorkShop & Screencast
• Website Baker
  • Template auf Basis von YAMLs "Simple Project"
• Wordpress
  • Tutorial zur Templateerstellung mit YAML
  • YAML Green Theme (konfigurierbar im Backend)
  • Blitzblank Theme
  • Simplex Theme
• xt:Commerce
  • YAML für xt:Commerce
  • YAML für xt:C VEYTON 4
  • Support-Forum [de]
  • Support-Forum [en]
• Zikula
  • Blanktheme
• ZMS
  • YAML 2.5 Templates für ZMS 2.9+

Entwicklertools

• YAML Builder
• YAML Debug
• CSSDOC-Editierhilfen für verschiedene Editoren

Die Diskussion in den Kommentaren ließ nicht lange auf sich warten und ist ausgeprochen fasettenreich. Bemerkenswert und und leider kein Einzelfall sind Kommentare mit folgendem Tenor:

Wenn es kostenlos ist, ist es kostenlos! Ich zahle gern für gute Software und gute Plugins, auch gern mal etwas mehr. Aber irgendwie versteh ich Eure Sicht trotzdem nicht, denn im Grunde liest es sich ja schon so raus das ihr gönnerhaft GPL Plugins schreibt, dann aber trotzdem hofft eine Spende zu bekommen, letztlich ist GPL dann sinnfrei weil ihr für Eure Leistung einen finanziellen Gegenwert erhaltet, auch wenn der sicherlich nicht im Verhältnis zu Euer Arbeit steht.

Kommentar Nr. 48

Die GPL ist aus Anwendersicht eine tolle Sache, den diese Lizenz gibt dem Anwender sehr viele Freiheiten und die notwendige Rechtssicherheit, aber keine Arbeit – und schon gar nicht qualitativ hochwertige Arbeit – ist umsonst. Der Autor dieses Kommentars sieht das jedoch ganz anders.

Seit vielen Jahren existieren zahlreiche schillernde Perlen am Open-Source-Himmel, die da lauten: Mozilla Firefox & Thunderbird, Wordpress, MySQL, OpenOffice, Joomla, Ubuntu, jQuery, Eclipse u.v.a.m. All diese Dinge gibt es quasi gratis für den Anwender. Dieser Umstand lässt schnell vergessen, dass hinter diesen erfolgreichen Großprojekten finanzkräftige Firmen, Organisationen oder Sponsoren stecken, die solche langfristig angelegten Projekte mit einer Vielzahl exzellenter Entwickler überhaupt ermöglichen und die vom Nutzer letztlich als qualitativ hochwertige Produkte wahrgenommen werden. Doch die GPL vereint nicht nur Großprojekte. Eine riesige Menge an Erweiterungen für diese Projekte aber auch viele kleinere, eigenständige Entwicklungen werden unter GPL lizensiert, wobei hier viel öfter kleinere Entwicklerteams oder Einzelentwickler wie Frank Bültge stehen. Und für diese Entwicklungen gilt das oben gesagte leider nicht. Zwei, drei Schritte von den Top-100 der Open-Source-Projekte entfernt ist es mit dem externen Geldregen in der Regel vorbei. Und hierbei spreche nicht vom reich werden, sondern vom notwendigen Lebensunterhalt. Die Mozilla-Entwickler leben genauso wenig von Luft und der ewigen Liebe der Nutzercommunity.

Doch genau dieser Teil von Open Source scheint vielfach ignoriert oder nicht verstanden zu werden. Anders kann ich mir solche Kommentare nicht erklären. Oder nehmen wir folgenden Kommentar:

... So wie Autoren das erste Buch fast verschenken, wird die zweite Auflage teuer an den Mann gebracht.

Kommentar Nr. 45

Das mag ein undurchdachter Spruch eines ahnunglosen Bloggers sein, aber dieser Satz dürfte wirklich jedem Fachbuchautor unter die Haut gehen, denn gegensätzlicher könnten die Mutmaßungen des Kommentarautors und der Realität kaum sein. Frank Bültge hat hierzu übrigens bereits Stellung genommen, klingt dabei aber aus meiner Sicht relativ resignierend.

Doch wo ist der Ausweg? Viele Kommentatoren empfehlen Frank, sich besser zu vermarkten, sein Wissen nicht – für lau – preiszugeben. Und die meisten versichern ganz selbstverständlich, für gute Software auch zu zahlen. Doch geht das überhaupt? Vorrausgesetzt man ist freiberuflich dieser Branche unterwegs, können Veröffentlichungen unter GPL-Lizenz, wie auch Bücher, die perfekte Eigen-PR sein. In diesem Fall entsteht die Entlohnung nämlich nicht direkt über Lizenzeinnahmen sondern indirekt und langfristig über den wachsenen Bekanntheitsgrad und die Reputation in der Community, wodurch man Aufträge aquirieren kann - von deren Entlohnung der Entwickler letztlich seine Miete und die Brötchen bezahlt.

Doch dieser indirekte Weg – und dabei gleichen sich die Umstände bei Frank Bültge und mir – ist bei so manchem Entwickler nur in Ausnahmefällen bzw. gar nicht möglich. Sowohl Frank Bültge als auch ich dürfen uns als so genannte "Freizeitkämpfer" bezeichnen. Wir haben andere, zeitintensive Berufe und tummeln uns mehr oder weniger in unser Freizeit in dieser Branche. Das machen viele, klar, aber nur wenige mit jahrelanger Ausdauer und in der Qualität, wie sie Frank Bültge vorlebt.

Ich selbst stand mit YAML vor knapp 4 Jahren genau vor dieser Entscheidung. Nach ersten Nutzungsanfragen aus dem professionellen Bereich musste eine Entscheidung hinsichtlich einer sinnvollen Lizenz getroffen werden. Ich habe all diese Probleme bereits damals gewälzt und mich mit YAML bewusst gegen die GPL entschieden. Und diese Entscheidung war in den vergangen Jahren immer wieder Grund zahlreicher verbaler Tiefschläge von Leuten, die meine Arbeit nur allzu gern unter GPL (und wohl somit ohne jegliche Gegenleistung) gesehen hätten, die ich hier nicht wieder auffrischen will. Und erstaunlicherweise kamen diese Stimmen vorwiegend aus dem Agenturumfeld.

Ich kann aus heutiger Sicht sagen, dass ich damals richtig entschieden habe und dies auch immer wieder tun würde. Der Weg war nicht gerade frei von Steinen aber letztlich erfolgreich. Ich sehe YAML als Open Source Projekt, denn der bei weitem überwiegende Teil der Downloads geht auf Nutzer, welche das Framework unter der Creative Commons Lizenz einsetzen. Und in diesem Bereich sind durchaus Parallelen zu erkennen. Fachliches Feedback ist extrem selten und hätte ich nicht einige wenige treue Helfer, würde die Weiterentwicklung sehr viel schwieriger sein. Der Supportaufwand, gerade aus diesem Bereich heraus ist jedoch gewaltig. Und Support ist keineswegs ein optionales Gut. Er gehört dazu, ob man will oder nicht. Auch ich hatte über drei Jahre einen kleinen Paypal-Button auf meiner Seite, der in dieser Zeit gerade einmal 35 EUR eingebracht hat. Seit August letzten Jahres ist er deshalb einer Amazon-Wunschliste gewichen - welche sehr viel mehr Akzeptanz bei den Nutzern hat. An dieser Stelle möchte ich mich deshalb bei allen bedanken, die mir über die Wunschliste bereits Freude bereitet haben. Ich versuche auch stets, soweit es die beiliegende Amazon-Rechnung ermöglicht, mich bei den jeweiligen Absendern persönlich zu bedanken. Leider klappt das nicht immer. Deshalb an dieser Stelle stellvertretend mein nochmaliger Dank an alle Spender.

Ich kann und möchte aber nicht sagen, dass Frank mit seiner Entscheidung pro GPL etwas falsch gemacht hätte. Vielmehr gibt es offensichtlich zahlreiche Leute da draußen, die bis heute das Konzept "Open Source" nicht verstanden haben. Open Source war nie als Einbahnstraße gedacht und kann auch so nicht funktionieren und es täte mir leid wenn Leute wie Frank, denen im konkreten Fall die Wordpress-Community viel zu verdanken hat, sich resigniert vom Open Source Gedanken abwenden.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

• YAML 3.2 (aktuelle Entwickerversion Beta 3)
• YAML 3.1
• YUI 3.0 beta1
• 960 grid system
• Blueprint CSS 0.9