Vortrag bei MODX Meetup Berlin #1

kleiner Blick in unsere Runde im Konferenzraum vom Büro 2.0:
Bild vergrößern

Von Erhard Maria Klein

Beim ersten MODX Community Meetup in Berlin am 27.03.2014 habe ich einen Vortrag über unseren Einsatz von textile zur Formatierung von rich content gehalten. Hier finden Sie den Vortrag in Stichworten zusammengefasst und ein paar weiterführende Links:

die passende Lösungsstrategie finden

Bei einem CMF wie MODX spielt die Strategie, wie man das Werkzeug einsetzt, eine wichtigere Rolle als bei klassischen CMSen. Man kann das bei Anfänger-Fragen in den Foren oft sehen: Die Leute wollen etwas umsetzen, gehen dann aber an die Problemlösung mit einer “Denke”, die nicht gut zu MODX passt, weil sie z.B. vorher mit Wordpress oder typo3 gearbeitet haben.

Ich möchte Euch heute meine Strategie für das ein Standard-Problem vorstellen, das jeder von Euch hat: wie ermöglicht man dem Kunden möglichst einfach und flexibel seine Inhalte zur formatieren?

rich text und rich media content

Ich verstehe darunter Inhalte, die redaktionell nicht nur einen formatierten Text haben (also Überschriften, Absätze, fett, Listen usw.) sondern eine komplexere Struktur: eingebettete Bilder mit Lightbox, Video- und Audioplayer, Mehrspaltigkeit, usw.
Ich nenne es zusammengefasst „rich content“

Wir wollen unseren Kunden ermöglichen, ihre Inhalte möglichst flexibel aber zugleich einfach, standardkonform und – ganz wichtig – responsive zu formatieren und zu präsentieren.

Weit verbreitete Lösungsansätze

Es gibt normalerweise zwei Lösungsansätze, die man oft auch mischt:

1. Man macht verschiedene Templates für verschiedene Darstellungsfälle (Bild linksbündig, Bild oben drüber im Panoramaformat, Seite mit zweispaltigem Inhalt usw.)
2. oder man nimmt einen rich-text-Editor und bietet ggf. reduzierte wysiwyg-Möglichkeiten.

Ich bin kein Freund von wysiwyg-Editoren,

- weil es die Kunden dazu verführt Dinge zu tun, die sie nicht verstehen, (→ s.a. falscher Umgang mit Word)
- weil es die Gefahr gibt, dass man formatierten Text aus Word o.ä. kopiert und dann ein Teil des grottigem HTML-Codes auf diesem Wege untergeschoben bekommt.
- und weil ich nichts davon halte, komplexe Inhalte über HTML-Code in den Content einzubetten. Der Content sollte nur den Inhalt enthalten. <div>s oder <span>s o.ä. – egal, auf welchem Weg sie dort hinkommen – hat im Content m.E. nichts zu suchen. Man hat nämlich sonst später, wenn man die Darstellungsschicht ändern will, Probleme mit den hard codierten rich-content-Elementen in den Contentfeldern – z.B. wenn man nachträglich die Bilder auf Retina-Auflösung umstellen will oder ein Dienst wie youtube die Art den Einbettungscode ändert.

Außerdem wird es immer wichtiger, dass Inhalte auch dynamisch zwischen verschiedenen Portalen über APIs ausgetauscht werden. Wenn man in seinem Content dann HTML-Code stehen hat, der für die Einbettung von Bildern usw. dient, kann das bei einer anderen Website, die die Inhalte ebenfalls darstellen soll, schwierig sein.

Themen wie Konformität, Responsivität und Barrierefreiheit spielen für mich ebenfalls eine Rolle.

Ich möchte gerne, dass ein Kunde (nur) seinen Inhalt semantisch auszeichnet und das CMS die vollständige Kontrolle über die HTMLisierung und Darstellung des Inhalts behält.
Von der Grundhaltung her bin ich eher Purist: mach’ es einfach, mach’ es überschaubar, vermeide Überflüssiges.

textile

Ich möchte Euch heute textile vorstellen. Eine Textauszeichnungssprache, mit der hunderte von Redakteuren unserer Kunden ohne große EDV-Vorbildung seit bald einem Jahrzehnt erfolgreich arbeiten.

Und ich möchte Euch zeigen, wie wir das rich-content-Problem damit lösen. textile kann man nicht intuitiv bedienen. Es setzt eine kleine Einführung voraus. Die wichtigsten Sachen lernt man buchstäblich in wenigen Minuten und wenn man regelmäßig damit arbeitet, kommt man i.d.R. genau so schnell – wenn nicht schneller – zum Ziel, als wenn man mit einem wysiwyg-Editor arbeitet. textile erzeugt validen HTML-Code und die Stil-Vorlagen sind für den Redakteur nicht so einfach überformbar.

1. textilefilter installieren: Extra textileFilter 1.1.0-pl (Bruno)
2. als output modifier einsetzen: [ [ *content:textile ] ]
3. einige Beispiele
Absätze: Leerzeile
<br>: Zeilenumbruch
fett: *
kursiv: _
Überschriften: h1 … h9
Liste (ul): *
Liste (ol): #
Link: “Linkbezeichnung”:Linkziel – auch interne Links mit [ [ ~ n ] ]

bisschen komplizierter:
Alignment z.B. rechtsbündig: p>.
Klassen zuweisen: p(small).
Tabellen: | (hier werden schnell auch weitere Optionen, Klassen usw. nötig)

Fortgeschrittene
textile ist transparent für HTML → z.B. youtube embedded code, googleMaps
Fortgeschrittene können auch inline-Styles machen: z.B. p{margin-top:2em}.
span: %

Bilder: ! url !

→ hier sind die Grenzen erreicht! Der Textilefilter kann (nur) richtext und es kann rich media content über HTML-Code einbetten.

WB_XPage

Ich habe einen eigenen Output-Filter entwickelt, der textile um weitere rich-content-Funktionen erweitert: WB_XPage.
Der Filter setzt MIGX und eine bestimmte Umgebung an TVs voraus. Ich habe daraus bislang kein Package daraus gemacht. Wer Interesse daran hat, kann sich gerne bei mir melden.

1. output modifier WB_XPage (greift auf MIGX-TV images zu, Konfiguration von Bildformaten)
2. Beispiele:
- Bilder einbauen: Lightbox, Ausrichtung, Formate
- Funktionen, die textile nicht bietet, ergänzen:
hr
target korrigieren
Mailencoding
3. Vereinfachter Syntax für die Einbettung von Snippets und Chunks [snippte:attribut1:attribut2] statt [ [ snippet? &key1=`attribut1` &key2=`attribut2` ] ])
4. <div>s
Mehrspaltigkeit und Boxen im Content benötigen <div>s. Wenn ein <div> nicht geschlossen ist, wird das ganze Layout zerlegt. Lösung: Snippet, das die div-Bilanz überwacht. Am Ende, außerhalb des content-Aufrufs wird ein Snippet „ende“ noch einmal aufgerufen. Es kann dann nur noch überschaubarer Unsinn passieren, der HTML-Code bleibt valide.