Flexibles Content Management mit MODX

Open Source Framework für professionelle Webdesigner und Developer

Die Suche nach dem besten Content Management System hat ein ganz einfaches Ergebnis: es gibt keines. Die eigentliche Frage muss nämlich ganz anders lauten: „Was ist das beste CMS für den geplanten Einsatzbereich?“ bzw. „Was ist das beste CMS für mich und meine Fähigkeiten?“ MODX ist ein Open Source Content Management Framework für professionelle Webdesigner und Developer.

Content Management System + Framework = MODX

MODX Revolution ist Open Source auf PHP Basis und für kleine bis große Websites gleichermaßen geeignet, also von der Web-Visitenkarte bis hin zur internationalen Firmenseite. Die Installation und Umsetzung verläuft dabei so zügig, dass man mit MODX eigentlich immer schneller ist, als mit handgeschriebenem Code. Und damit wird die Zielgruppe von MODX deutlich: MODX ist ein Tool für professionelle Webdesigner und -Developer. MODX Revolution (im Folgenden nur „MODX“ genannt) ist der Nachfolger von „MODX Evolution“ und eine Mischung aus CMS und CMF – aus „Content Management System“ und „Content Management Framework“ – also eine „Content Application Plattform„.

Für wen ist MODX geeignet?

Die Frage müsste eigentlich lauten: „Wer ist für MODX geeignet?“ Die größte Hürde, die man bei MODX nehmen muss, ist man selbst: MODX ist kein System für Website-Laien. Das Teil ist amtlich und für professionelle User. Kenntnisse in HTML und CSS sind daher absolut erforderlich. MODX verwaltet Content und liefert ein Markup, das bis ins Details festgelegt werden kann – und auch muss. Nach der erfolgreichen Installation liefert MODX eine leere weiße Seite aus, mit minimalem HTML Quellcode. So fängt jedes MODX Projekt an.

Der Slogan von MODX lautet: „Creative Freedom.“ MODX macht alles das, was man ihm sagt. Anders ausgedrückt: MODX gehorcht auf’s Wort, nimmt einem die Arbeit ab und steht nicht im Weg.

MODX für End-Benutzer

Für den End-Benutzer ist MODX ein System zur Veröffentlichung von Content im Web – in jeder gewünschten Art, Form oder Darstellungsweise. Es bietet ein anpassbares Backend, das von einfach bis komplex reichen kann: Der MODX Manager. Vom Blog bis hin zu voll skalierenden Web-Präsenz – das Admin-Interface bleibt einfach und bedienerfreundlich: „Drag’n’Drop“, manuelles und zeitlich gesteuertes Veröffentlichen, Asset-Verwaltung etc.

Der MODX Manager

MODX hilft beim Organisieren und Strukturieren des Contents im Dokumentenbaum und macht damit eine Optimierung für Suchmaschine zum Kinderspiel. MODX ist vollständig „Friendly URL“ kompatibel und erzeugt URLs wie „meine-website.de/wie/ich/sie/will.html“ von Haus aus.

MODX für Web-Designer

Für Web-Designer bietet MODX die vollständige Freiheit und Kontrolle über den HTML-, CSS-, JavaScript-, XML- oder „Was-auch-immer-Code“ – und das dank UTF8 für beliebige Sprachen. MODX generiert nicht eine eigene Zeile Code ohne dass man diese nicht selbst geschrieben hat. Es gibt keinen Kampf mit dem System und den eigenen Vorstellungen.

MODX bietet ein hochflexibles Templating-System und erlaubt das Ablegen von Dateien in einer beliebigen Ordner-Struktur es holt sie dort ab, wo man sie haben möchte.

MODX für Developer

Als Developer kennt man das: Viele Content Management Systeme sehen nett aus, sind aber „unter der Haube“ zusammengeschraubt und ein Mischmasch aus unzusammenhängenden Code-Schnipseln. Das macht das Arbeiten ineffektiv und anstrengend.

PHP Frameworks bieten hingegen oft viel Power, aber es fehlt ihnen ein User-Interface, mit dem die Kunden diese Power auch bedienen können. MODX Revolution verbindet die Leistungsfähigkeit eines Frameworks (CMF) mit dem Userinterface eines CMS und vereinigt so das Beste aus beiden Welten.

MODX bietet eine flexible, starke und robuste API, die auf OOP Prinzipien aufbaut und benutzt mit xPDO ein PDO-basiertes Object Relational Model (ORM). Erweiterungen der Basisfunktionen sind damit schnell erstellt und mit „Custom Manager Pages“ können ganze Applikationen auch innerhalb des MODX Backends laufen.

Frontend vs. Backend

Der oft an MODX geäußerte Kritikpunkt „Es gibt ja kein XYZ-Modul für MODX“ ist richtig, wenn man mit XYZ Dinge wie „Lightbox“, „Content Slider“, „Accordeon Menu“, „Video Player“ und sonstigen Frontend-Code meint.

MODX liefert das Markup für die Lightbox der Wahl, nicht die Lightbox selbst. MODX liefert die Strukturen, mit denen der Content so aufbereitet wird, dass der Slider des Vertrauens damit arbeiten kann.

Falls man etwas Frondend-Magic braucht, so realisiert man das in MODX kurzerhand selbst. Beispiel gefällig? Ein universeller Player für YouTube Videos. Die speziellen MODX Begrifflichkeiten wie „Chunk“ oder „Tags“ werden später noch ausführlich erklärt.

1. HTML-Quelltext für YouTube Player besorgen
   Dazu ruft man ein beliebiges Video auf YouTube auf und klickt auf den Button „Einbetten“, woraufhin folgender HTML-Code angezeigt wird:<iframe width="640" height="360"
   src="http://www.youtube.com/embed/8L8UCfxmtSw" frameborder="0"
   allowfullscreen></iframe>
2. Erstellung eines MODX Chunks
   Den HTML-Code kopiert man mit Copy’n’Paste in den Chunk „meinYouTubePlayer“ und verändert ihn folgendermaßen:<iframe width="640" height="360"
   src="http://www.youtube.com/embed/[[+youtubeID]]" frameborder="0"
   allowfullscreen></iframe>
3. Player einsetzen und fertig
   An der Stelle der Website, wo das Video angespielt werden soll, wir folgender MODX Chunk-Tag eingefügt:[[$meinYouTubePlayer? &youtubeID=`8L8UCfxmtSw`]]

Das kann mitten im Text sein oder an einer beliebigen anderen Stelle. Wenn der Chunk mit einer anderen YouTube-ID aufgerufen wird, dann wird eben das andere Video abgespielt. Die YouTube-ID könnte in einer Template Variablen gespeichert werden, sodass für jeden Artikel ein entsprechendes YouTube-Video abgespielt wird. Mit dieser Arbeitsweise lassen sich in MODX alle möglichen Frontend-Funktionalitäten einsetzen, ohne das ein Programmierer extra Hand anlegen muss! Auch Twitter „Bootstrap“, Zurb „Foundation“ oder irgend ein anderes Framework lassen sich problemlos einbinden.

Technische Voraussetzungen

Um es abzukürzen: MODX läuft eigentlich bei allen Web-Hostern, die PHP und MySQL anbieten – also praktisch überall.

• Technische Basis: PHP
• Datenbanken: MySQL (auch MS-SQL )
• Plattformen (Client/Server): browserbasiert (Win, Mac, Linux etc.)
• Web- und Applikationsserver: Apache 2.2.x, IIS 7.0, nginx 1.2.x

Wer’s ganz genau wissen will oder muss, kann sich hier die Details anschauen.

Installation

Kurz: ein Kinderspiel. Die aktuellste Fassung von MODX Revolution gibt es unter modx.com als ZIP-Archiv. Dieses entpackt man entweder direkt auf dem Server oder überträgt die Dateien einzeln per ftp. Das Setup wir durch ein Anhängen von „/setup/“ an den Domainnamen aufgerufen: Angaben zur Installationsart (Neu oder Update) machen, gewünschten Sprachversion wählen (kann später geändert werden) und Angaben zur Datenbankverbindung machen. Fertig.

MODX Revolution läuft. Danach kann man sich direkt ins Backend einloggen, in den „MODX Manager“.

MODX Manager

Der „MODX Manager“ ist das Backend von MODX und wird durch Anhängen von „/manager/“ an den Domainnamen aufgerufen. Aber, und das sollte man schon jetzt wissen: Der Manager ist nicht MODX! Der Manger ist nur eine „Website“, mit der MODX Revolution bedient wird. Er ist eine von vielen möglichen Schnittstelle zwischen dem MODX Framework und dem User. Wer möchte, kann sich auch seine eigene Verwaltungsoberfläche für MODX bauen.

Im Weiteren werden aber „MODX Revolution“ bzw „MODX“ und „MODX Manager“ synonym verwendet – denn der MODX Manager ist quasi der sichtbare Teil von MODX Revolution. Im oberen Teil befindet sich das Hauptmenü mit den Funktionsbereichen. Links befindet sich der Dokumentenbaum (Resources), die Liste der Elemente (Elements) und die Ansicht auf Dateienstruktur (Files). Rechts befindet sich der Hauptbereich, wo die eigentliche Arbeit erledigt wird.

Package Management

MODX Revolution verfügt über ein integriertes Package Management mit dem Erweiterungen aller Art heruntergeladen und installiert werden können. Diese Transport Packages können Snippets, Chunks, Plugins, Komponenten, Manager Templates etc. enthalten. Was das alles genau ist kommt später.

MODX Package Management

Die wichtigsten Packages sind „wayfinder“ zur Menüerstellung, „getResources“ zur Zusammensetzung beliebiger Inhalte und „TinyMCE“ als WYSIWYG-Editor. Weitere nützliche Packages sind „FormIt“ für Formulare aller Art, „Articles“ für Blogs, „Discuss“ für Foren, „CodeMirror“ oder „Ace“ für’s einfachere Coden und „MIGX“ für komplexe Datenstrukturen.

User- und Rechteverwaltung

Das Sicherheitssystem von MODX basiert auf dem Attribute-Based Access Control (ABAC) Ansatz. Jeder User ist z.B. ein Object, das einer oder mehreren User Groups zugeordnet ist und das über Access Control Lists (ACLs) in verschiedenen Situation verschiedene Rechte besitzt. Auf diese Weise können die Möglichkeiten eines MODX Users sehr granular eingestellt werden. Für den Anfang muss man sich hierüber aber (zum Glück) noch keine Gedanken machen.

Usern können eigene System Settings (siehe entsprechendes Kapitel) haben und damit Standard-Parameter überschreiben, z.B. „tree_root_id“ um spezielle „Zweige“ des Dokumentenbaumes aufzublenden oder „manager_language“ um eine andere Sprache im Manager zu verwenden.

Media Management / Media Sources

Die Verwaltung von Dateien erfolgt über den Reiter „Files“. Hier können Verzeichnisse angelegt und Dateien hochgeladen werden. In Verbindung mit „Media Sources“ lassen sich Zugriffe auf verschieden Speicherorte anlegen, Abkürzungen sozusagen, Damit können User auf bestimmte Verzeichnisse eingeschränkt werden.

Tags

Damit MODX zwischen statischem Code und dynamischem Content unterscheiden kann gibt es eine Tag-Syntax, die von einem sehr leistungsfähigen Parser analysiert und interpretiert wird. Das funktioniert so wie bei einem Serienbrief: Ein Teil ist immer gleich und der veränderliche Teil wird von Tags vertreten. Diese sehen in MODX so aus: [[tokenIdentifier]].

Hier eine Übersicht der MODX Tags für Funktionalitäten, die wir im weiteren Stück für Stück vorstellen:

Diese Tags können an nahezu allen Stellen verwendet werden: im Text, in Feldern und das auch noch verschachtelt: [[~[[++site_start]]]] erzeugt einen Link auf das Dokument (also dessen ID), welches als Startseite festgelegt wurde. Auf den ersten Blick vielleicht etwas verwirrend, aber damit lassen sich komplexe Dinge im Handumdrehen realisieren.

Im Folgenden müssen wir etwas vor und zurück springen, da sich viele der Tags in anderen Elementen aufrufen lassen. Dadurch wird ein linearer Erklärungsstrang unmöglich. Sorry, aber mit großer Flexibilität geht auch ein größeres Maß an Komplexität einher.

 Resource

Im Prinzip sind Resourcen – einfach ausgedrückt – Seiten. Es gibt verschiedene Arten von Resourcen, wie z.B. Dokumente, Weblinks, Symlinks, Dateien oder was auch immer. Im Normalfall hat man es aber mit Dokumenten zu tun. Resources werden in einer Baumstruktur organisiert. Dieser Baum kann als „Sitemap“ der Website aufgefasst werden.

Jede Resource besitzt eine eindeutige ID. Mit dieser ist sie systemweit ansprechbar, z.B. für Links. Dabei braucht man sich keine Gedanken um die URL oder den Resource-Typ zu machen – darum kümmert sich MODX. Resourcen bestehen aus Felder wie „Pagetitle“, „Alias“, „Content“ etc.

Was genau in Resourcen gespeichert wird hängt vom Content-Typ ab. Es kann Richtext/HTML sein, aber auch Javascript, RSS, JSON, SVG, XML oder einfach nur Text. Je nach Typ wird der HTML-Header einer Resource automatisch gesetzt. Somit kann MODX z.B. auch als CMS für die XML-Inhalte einer Flash-Anwendung benutzt werden.

Templates

Jeder Resource wird ein Template zugeordnet. Dieses Template gibt die Form vor, in der die Resource dargestellt wird. Im Regelfall besteht ein Template aus Header, Footer, Menüs, dem Content etc.

Template Variables

Jede Resource hat einen vorgegebenen Satz an Felder. Benötigt man weitere Felder (Custom Fields), so können diese über „Template Variablen“ (TV) realisiert werden. Diese sind einem Template zugeordnet und damit auch für die Resourcen verfügbar, die das Template verwenden.

Als bildliche Analogie kann man sich die Felder einer Resource und die Template Variablen als einen Setzkasten vorstellen: Die einzelnen Elemente des Content kommen in separate Fächer und diese Fächer können dann an beliebiger Stelle und in beliebiger Kombination flexibel ausgegeben werden, z.B. <div>[[*sidebox]]</div>.

Ein Beispiel aus der Praxis: Eine Resource soll über ein weiteres Content Feld für eine Randspalte verfügen. Also wird eine Template Variable „sidebox“ vom Typ „Rich Text“ angelegt und diese dem Template zugeordnet. Damit verfügt die Resource nun über ein weiteres Feld, in das der Inhalt für eine Randspalte eingegeben werden kann. Aber warum kann man den Inhalt der Randspalte nicht einfach mit in das Content-Feld eingeben und mit einem DIV versehen? Das geht doch auch? Ja, aber dann vermischen wir Inhalt und Struktur – und werden unflexibel.

Ein Beispiel zur Content-Aggregation mit „getResources“ findet sich im Kapitel „Snippets“.

Es gibt eine ganze Reihe von TV-Typen: Text, Rich Text, Check Box, Radio Buttons, DropDown List, Date, URL/Email, File/Image, Resource List, Tag/Auto-Tag etc. Für ganz spezielle Anwendungsbereiche gibt es nachladbare „Custom TVs“, z.B. für „GoogleMaps“ oder komplexe TV Konstrukte mit „MIGX“. Eine TV kann dabei mehren Template zugeordnet werden.

Über sogenannte „Bindings“ können TVs mit allen möglichen Datenquellen verbunden werden. Zu abstrakt? Hier ein Beispiel: eine DropDown Liste kann mit einer SQL Abfrage verknüpft werden und so eine Auswahl aus den Ergebnisse anbieten.

Chunks

Ein Chunk ist – auf den ersten Blick – einfach nur ein Code-Stücke, das mehrfach verwendet werden kann, z.B. der HEAD-Bereich für mehrere Templates: [[$myHeaderChunk]]. Im Prinzip vergleichbar mit einem Textbaustein. Chunks selbst dürfen keinen PHP Code enthalten, können aber „Snippets“ mit [[SnippetName]] einbinden – und diese beinhalten dann den PHP-Code. Aber Chunks können noch mehr.

Placeholders, Properties and Property Sets

Damit Chunks dynamisch werden, können in ihnen Systemeinstellungen, Platzhalter (Placeholders) und, wie bereits erwähnt, Snippets verwendet werden.

Mittels <title>[[++site_name]]</title> kann z.B. der in den Systemeinstellungen hinterlegte Name der Website eingesetzt werden.

Mit Placeholders können an Chunks übergebene Parameter verarbeitet werden, wie im Beispiel am Anfang dieses Artikel gezeigt. Für den Fall, dass der Chunk versehentlich ohne Parameter aufgerufen wird, kann einem „Placeholder“ eine „Property“ zugewiesen werden, also eine Voreinstellung, die nur bei Bedarf überschrieben wird. Mehrerer Properties können in „Property Sets“ zusammengefasst werden. Im Fall unseres YouTube-Players vom Anfang, beispielsweise Angaben zu Höhe und Breite des iframes. Damit das ganze noch flexibler wird können Chunks mit einem oder mehreren Property Set verbunden werden. Klingt verwirrend, ist es auch, aber extrem praktisch:

[[$youtube@size480? &video=`qnydFmqHuVo`]]
[[$youtube@size640? &video=`qnydFmqHuVo`]]

Na, klingelt’s? Einfacher und flexibler geht’s nicht!

Output Filter

Manchmal müssen gespeicherte Inhalte vor der Ausgabe modifiziert werden. Wie würde man z.B. auf den Fall reagieren, dass eine Resource zwar ein Feld für ein Zusatztitel enthält, dieses aber leer ist? Hier helfen „Output Filter“ und „Chaining“ weiter: [[*longtitle:empty=`k.A.`]] bedeutet „Wenn die TV „longtitle“ leer ist, dann gebe „k.A.“ aus“.

Mit „Conditional Filters“ werden komplexere Abfragen möglich, z.B.:
[[+numbooks:lt=`5`:then=`Weniger als 5 Stück`:else=`OK, 5 und mehr. `]]

Eigene Filter lassen sich mit Snippets in PHP programmieren.

Grundsätzlich kann man alle MODX-Tags durch Output-Filter verändern, also auch Chunks, Snippets, Lexicon Einträge etc. – auch wenn Parameter übergeben werden! Im folgenden Beispiel wird ein Lexicon Eintrag auf 66 Zeichen eingekürzt:
[[%about_msg:ellipsis=`66`? &language=`de` &namespace=`core` &topic=`about`]]

Snippets

Bis hierhin sind wir beim Einsatz von MODX völlig ohne PHP-Code ausgekommen. Für viele Projekte reicht das aus. Vorgefertigte Snippets, wie beispielsweise „getResources“ zur Content-Aggregation oder „wayfinder“ zum Bau von Menüs, lassen sich über das Package Management installieren. Der Einsatz erfolgt mit Hilfe der MODX Tag-Syntax, z.B.:

[[getResources? &parents=`15` &depth=`3` &tpl=`outputTpl`]]

Das bedeutet übersetzt: „Übergebe die Resourcen unterhalb der Resource mit der ID 15 an den Chunk „outputTpl“ und zwar bis zu 3 Ebenen tief.“ Im Chunk „outputTpl“ wird über Placeholder gesteuert, was dargestellt wird und was nicht:

<h1>[[+pagetitle]]</h1>
[[+content]]

Für solche Sachen braucht man also kein PHP. Für andere schon. Eigene Snippets sind schnell in PHP programmiert. Für den Einstieg sind eigene „Output Filter“ ein guter Start.

return substr ($input , 0, 50) . " &hellip;";

Aufgerufen wird das Snippet z.B. mit [[*pagetitle:shorten50]]

Mit „Snippets“ kann MODX um zusätzliche Funktionen erweitert werden, da diese auf die komplette API von MODX zugreifen können. Damit betritt man ein völlig neues Universum an Möglichkeiten. Aber das führt hier zu weit. Leider.

Plugins

Plugins sind PHP-Skripte, die an bestimmte Events gekoppelt werden. Denn immer wenn MODX etwas macht, wird ein Event erzeugt. Man kann mit Plugins alle Funktionen von MODX um eigene Bestandteile erweitern – und das ohne im Core herumzubasteln. Ein paar Beispiele für Events sind „OnInitCulture“, „OnChunkSave“, „OnWebPagePrerender“. Oder anders ausgedrückt: Plugin sind Snippets, die bei bestimmten MODX Ereignissen automatisch ausgeführt werden.

System Settings

Hier kann MODX in allen Details konfiguriert werden. Und man kann viel konfigurieren, sehr viel.

Contexts

Mit Contexts lassen sich MODX Installationen aufteilen und mit eigenen System Settings versehen. Damit lassen sich mehre Domains gleichzeitig verwalten, Sprachversionen organisieren, Landing Pages einrichten etc.

Lexicon Management / Namespaces

Im MODX Lexikon lassen sich, wie man es auch vermuten würde, sprachspezifische Einstellungen hinterlegen. Alle Menüpunkte des Managers sind hier abgelegt und können nach belieben abgewandelt werden. Auch andere Erweiterungen von MODX legen hier ihre sprachlichen Varianten ab.

Der spannende Teil ist aber, dass sich das Lexikon auch für eigene Websites nutzen lässt. Dazu legt man lediglich einen neuen Namespace an, also einen eigenen Bereich innerhalb des Lexikons, z.B. „meine-website.de“, in dem sich nun Übersetzungen in allen erforderlichen Sprachen speichern lassen. Namespaces können noch in thematisch Bereiche unterteilt werden, den sog. „Topics“.

Beispiel: Ein Kontakt-Formular soll, je nach gewählter Sprache, anders beschriftet sein. Das Formular selbst ist in einem Chunk gespeichert. Um jetzt nicht für jede Sprache einen eigenen Chunk anlegen zu müssen, werden die Bezeichner der Felder über das Lexikon verwaltet. Statt „Postleitzahl“ schreibt man [[%plz? &namespace=`meine-website.de`]] und hinterlegt im Lexikon nun plz=“Postleitzahl“ für „Deutsch“, plz=“Zip code“ für „Englisch“ und plz=“Code postal“ für „Französisch“. Der komplexere Aufruf sähe beispielweise so aus:

[[%plz? &language=`de` &namespace=`meine-website.de` &topic=`contact`]]

Im Lexikon lassen sich auch Zahlen oder ganze Code-Fragmente speichern, also alles, was aus Text besteht.

Dokumentation und Community

Allgemeine Informationen zu MODX Revolution finden sich auf der Homepage MODX LLC., der Firma hinter MODX: modx.com. Die weitergehende Dokumentation hört auf den Namen „RTFM“ und ist unter rtfm.modx.com verfügbar.

Darüber hinaus hat MODX eine sehr hilfsbereite und kompetente Community, die auch Neulingen gegenüber nicht überheblich ist, sondern unterstützt: Auf www.modxcms.de , bei Twitter unter „@MODX_DE“ bzw. „#MODX“ und über Facebook.

Zum Schluss noch ein paar Beispielwebsites:

• www.complex.com
• pearldrum.com
• www.delldesignlibrary.com