In love with MODX Revolution™

Wer mich kennt oder (ältere) Einträge in diesem Blog gelesen hat, weiß dass ich ein großer Fan des CMS WebsiteBaker bin. Warum, habe ich bereits an der ein oder anderen Stelle dargelegt. Allerdings haben sich die Anforderungen an Websites in den letzten Jahren geändert: Oft geht es nicht mehr um einfache Seiten mit Text und Bild – eine Disziplin, die WebsiteBaker hervorragend beherrscht – sondern um etwas komplexere Funktionen. Mit MODX Revolution™ habe ich vor etwa einem Jahr ein ziemlich cooles Allround-Werkzeug für die Realisierung solcher Sonderwünsche für mich entdeckt. In diesem Artikel möchte ich einen kleinen Einblick in die Funktionen von MODX Revolution™ geben, die das System für mich so attraktiv machen.

MODX Revolution™ bezeichnet sich selbst als Content Management Framework, was die Vielseitigkeit der in PHP geschriebenen Software schon sehr gut in Worten ausdrückt. Denn das System ist keineswegs nur auf die Verwendung als Website-Motor ausgelegt sondern kann durch seine API beispielsweise auch als Backend für mobile Anwendungen (Smartphone-Apps) genutzt werden.

Ich schreibe übrigens immer ganz bewusst das „Revolution“ hinter „MODX“, denn parallel exisitiert auch noch MODX Evolution™ – der direkte Vorgänger von MODX Revolution™, der jedoch noch immer gepflegt wird. Evolution kenne ich jedoch nicht; dieser Artikel bezieht sich also ausschließlich auf MODX Revolution™ – auch wenn ich den Zusatz mal irgendwo vergessen sollte.

Der MODX® Manager

Das Backend von MODX Revolution™ ist der so genannte Manager. Genau genommen ist der Manager eine eigenständige Website, die mit der MODX-API kommuniziert. Nutzt man MODX Revolution™ als CMS, so ist der Manager die Schaltzentrale für alle Arbeiten rund um die Erstellung und die spätere Pflege der Website. Hier werden Optik, Funktion und Inhalt der Website festgelegt und gepflegt.

Das Dashboard von MODX Revolution™

Was MODX Revolution™ ausmacht: Template Variables, Chunks, Snippets und Plugins

Die Flexibilität und Vielseitigkeit von MODX® wird maßgeblich bestimmt von den in der Überschrift genannten MODX Elements. Diese machen für mich den Großteil der Attraktivität von MODX Revolution™ aus und ermöglichen die erstaunliche Vielfältigkeit.

Templates, Chunks, Snippets und Plugins – die grundlegenden Elemente von MODX Revolution™

Template Variables: Zusätzliche Eingabefelder

Diese Funktion kennt man auch in manch anderem CMS: In ProcessWire heißen Sie „Fields“ in WordPress „Custom Fields“ – in MODX® heißt sie „Template Variables“. Damit kann man neben dem Text auf einer Seite (in MODX® „Ressource“ genannt) noch weitere Informationen hinterlegen und auf einer beliebigen Stelle im Template ausgeben (wenn man möchte). Ein eigenes Headerbild für jede Unterseite? Ein Fall für Template Variables! Zusatzinformationen in der Sidebar auf jeder Unterseite? Ein Fall für Template Variables! Eine einheitliche Darstellung von Produktinformationen, Preisen, Ansprechpartnern je Unterseite? Ihr wisst schon: Template Variables! Die Einsatzzwecke der Template Variables – kurz TVs – sind so vielfältig wie die Anforderungen an jedes Webprojekt. Es gibt unterschiedliche Typen von TVs, die im Manager entsprechende Eingabemöglichkeiten bereithalten: Textfelder, Dateiauswahl, Kalender etc. Für die späteren Autoren der Website ist es also sehr komfortabel, die entsprechenden Parameter jeder einzelnen Resource zu ändern.

Verschiedene Template Variablen für die verschiedensten Einsatzzwecke

Template Variables ermöglichen separate Eingabemöglichkeiten bei der Bearbeitung von Resourcen.

Chunks: Häppchenweise HTML

Chunks sind kleine oder große Schnippsel HTML. Ich nutze Chunks gern für wiederkehrende Elemente, die ich in mehreren Templates verwenden möchte. Beispielsweise den Footer einer Site oder den Code für Google Analytics bzw. Piwik. Gibt es Änderungen – beispielsweise eine Erweiterung des Analytics-Code – dann ändere ich das im Chunk und, bämm, ist die Änderung, überall dort wo der Code ausgeben wird, übernommen.

In Chunks lässt sich HTML-Code für die spätere Wiederverwendung auslagern

Snippets: Kleine PHP-Päckchen

Snippets sind im Prinzip gekapselte PHP-Funktionen, die man an beliebiger Stelle aufrufen kann. In WebsiteBaker, LEPTON oder BlackCat CMS kennt man das als „Droplets“.

Snippets sind PHP-Funktionen, welche über MODX Tags an beliebiger Stelle platziert werden können.

Plugins: PHP für Systemevents

Ein Plugin ist PHP-Code, der beim Auftreten bestimmter System-Events (kenn man in WordPress beispielsweise als „Hooks“) ausgeführt wird. Viele Plugins kommen zusammen mit den so genannten „Extras“ (später mehr dazu) über die integrierte Paketverwaltung. In einem Projekt nutzte ich beispielsweise ein Plugin, um beim Speichern der Resource (OnDocFormSave-Event) eine in TVs erfasste Adresse mittels der Google-Maps-API in Längen- und Breitengrad umzuwandeln. Plugins stellen ihre Funktionen in erster Linie im Backend, also im Manager, bereit und nicht im Frontend. Generell gehört das Frontend bei MODX® dem Entwickler, dazu komme ich am Ende aber noch einmal.

Plugins können sich an System Events von MODX® hängen und führen dann eigenen PHP-Code aus.

Templates

Templates bestimmen die (HTML)-Ausgabe der in MODX® erfassten Inhalte. Wie auch die MODX Elements werden die Templates im Manager angelegt und in der Datenbank gespeichert. Wer mag, kann auch statische Dateien aus dem Dateisystem verwenden – beispielsweise wenn man seine Arbeit in einer Versionskontrolle wie GIT verwalten möchte.

Mit Templates wird die Ausgabe von Resource nbestimmt.

Zur Ausgabe von Inhalten, Systemeinstellungen und MODX Elements kommt eine systemeigene Syntax, die MODX Tags, zur Anwendung, die man aber schnell erlernt hat:

[[*field]]

Damit kann man beispielsweise den Inhalt der Seite ([[*content]]) oder den Inhalt einer Template Variable ([[*namedertemplatevariable]]) ausgeben.

[[$chunk]]

Hiermit gibt man den Inhalt eines Chunks – also separat gespeichertes HTML – aus.

[[snippet]]

Führt den PHP-Code eines Snippets aus und gibt das Resultat an dieser Stelle aus. Das kann man mit einem Funktionsaufruf in PHP vergleichen – und ja, Parameter kann man natürlich auch übergeben: [[snippetname? &parameter1=`wert1` &parameter2=`wert2]]

[[+placeholder]]

Gibt den Inhalt eines Platzhalters aus. Platzhalter können von Snippets oder Plugins über die API definiert werden – ein Snippet kann auf diese Weise beispielsweise mehrere Rückgabewerte liefern, die man nach nur einmaligem Aufruf an meheren Stellen innerhalb des Templates ausgeben kann.

[[~link]]

Erzeugt eine URL auf Basis einer übergebenen Resource-ID. Hat beispielsweise die Impressumseite die Resource-ID 12, so erzeugt [[~12]] die URL zur Seite. Somit könnte man beispielweise den Impressum-Link im Footer ausgeben. Man kann die MODX Tags auch kombinieren: [[~[[id]]]] erzeugt beispielsweise die URL zur aktuellen Seite – nützlich z.B. beim action-Attribut von Formularen. Auch hier kann man natürlich wieder Parameter übergeben: [[~[[id]]? &parameter=`wert`]]

[[++system_setting]]

Damit kann man den Wert einer beliebigen System-Einstellung ausgeben. Zum Beispiel der Name der Website im title-Element der HTML-Ausgabe mit : [[++site_name]]. Oder die URL der Site mit [[++site_url]].

Output Modifier

Um mit den Ausgaben der MODX Tags noch flexibler umzugehen, stellt MODX Revolution™ die Output Filter, auch Output Modifier genannt, bereit. Diese werden einfach mit einem Doppelpunkt getrennt an den entsprechenden MODX Tag angehängt. Eine Seitenbeschreibung auf 60 Zeichen kürzen? Here we go: [[+description:ellipsis=`60`]]. In einer Artikelliste eine Meldung ausgeben, wenn kein Artikel vorhanden ist? That’s it: [[+NoOfArticles:is=`0`:then=`Keine Artikel gefunden`]].

Extras: Funktionserweiterungen

Extras kennt man auch von anderen Systemen – das sind Erweiterungen des Funktionsumfangs des CMS. Bei WordPress nennt man sie beispielsweise „Plugins“, bei Joomla! „Extensions“ bei WebsiteBaker und dessen Ablegern heißen sie „Module“. Extras kann man über die in MODX Revolution™ integrierte Paketverwaltung komfortablel im Manager installieren, beispielsweise einen WYSIWYG-Editor wie den TinyMCE. Im Prinzip liefern Extras meist einen oder mehrere der MODX-Elements, i.d.R. Plugins, Snippets und Chunks, zur Realisierung bestimmter Funktionen. Zum Zeitpunkt der Erstellung dieses Artikels gibt es rund 600 Extras für MODX Revolution™. Das ist natürlich deutlich weniger als bei manch anderem populären CMS – aber MODX funktioniert halt auch anders als viele andere Systeme: Für die meisten Aufgabenstellungen gibt es exakt ein Extra welches man dann durch Verwendung der mitgelieferten MODX-Elements den eigenen Bedürfnissen anpasst.

Über das Package Management können komfortabel Extras installiert werden.

Form Customization: Das Backend anpassen

Eine weitere große Stärke von MODX Revolution™ ist die Anpassbarkeit des Managers, als des Backends. Über das das so genannte Form Customization lässt sich sehr feingliedrig festlegen, an welcher Stelle User-Interface-Elemente dargestellt werden. Diese Anpassungen lassen sich je nach Bedarf global, je Benutzer oder je Template festlegen. Ein Praxisbeispiel: In einem Projekt lassen sich mit einem eigenen Template verschiede Mitarbeiter eines Unternehmens erfassen, welche später – über Template Variablen – einzelnen Unterseiten der Website zugeordnet werden können. Für die Erfassung der Mitarbeiter brauche ich beispielsweise keinen WYSIWYG-Editor sondern nur einzelne Eingabefelder für Telefon- und Faxnummer sowie E-Mail-Adresse. Mittels Form Customization kann ich für alle Seiten, die das Mitarbeiter-Template verwenden, das Feld mit dem WYSIWYG-Editor ausblenden und die Eingabefelder für die Kontaktdaten (Template Variablen) prominent platzieren. Spätere Autoren der Website sehen somit nur Eingabefelder, die für die Erfassung eines Mitarbeiters notwendig sind.

Mittels Form Customization kann der MODX® Manager den Bedürfnissen des Projektes angepasst werden

Fein(st)gliedrige Rechteverwaltung

Mit den so genannte Access Control Lists und den Access Policies lassen sich in MODX Revolution™ die Rechte einzelner Benutzer oder Benutzergruppen sehr detailliert einstellen. Sehr viel feingliedriger, als ich es von anderen CMS kannte. Das mag am Anfang etwas nach Overkill aussehen, hat sich aber schon tatsächlich bei Projekten als sehr nützlich erwiesen. Dabei geht es nicht einmal darum, dass man Autoren der Webite irgendwie misstraut – nein, das ist nicht der Fall – aber die Möglichkeit, bestimmte Einstellmöglichkeiten (die im Zweifelsfall eher zu unerwarteten Resultaten führen können und Laien möglicherweise verwirren) mal vorsorglich abzuschalten, ist überaus wertvoll. Verbessert die Nutzerfahrung und schützt die Website.

Access Policies: Feingliedrige Einstellmöglichkeiten der Berechtigungen

Nicht nur HTML

Ich hatte weiter oben bereits erwähnt, dass in MODX Revolution™ Seiten nicht „Seiten“ sondern „Resourcen“ heißen. Und das ist auch sinnvoll – den MODX® kann nicht nur HTML ausliefern sondern out-of-the-box auch viele andere Inhaltstypen. Beispielsweise JSON oder XML bei der Verwendung von MODX® als Backend für andere Apps. Aber auch ganz klassisch Javascript und CSS, wenn man Skripte und Styles direkt im MODX® Manager und nicht im Dateisystem verwalten möchte. Natürlich lassen sich beliebige weitere Inhaltstypen definieren.

Resourcen in MODX® können nicht nur HTML ausgeben

Das Frontend gehört dem Entwickler

MODX Revolution™ schreibt keine einzige Zeile HTML in die Frontendausgabe, ohne dass man das explizit veranlasst. Plugins werfen nicht – wie in vielen andern CMS (*hust* WordPress *hust*) üblich – eigene Skripte, Stylesheets oder fiese Tabellenlayouts in teils übermäßiger Anzahl ins Frontend sondern überlassen das ganz bewusst dem Ersteller der Website. Für die HTML-Ausgabe nutzen die meisten Plugins Chunks, wodurch man den Code sehr feingliedrig an die eigenen Bedürfnisse anpassen kann. Eventuell nötige Javascripte oder separate Stylesheets lassen sich durch die Nutzung spezieller Templates ganz gezielt nur auf den Seiten bereitstellen, auf denen sie auch wirklich benötigt werden. Man behält also die hohe Individualisierbarkeit statischer HTML-Seiten und kann dennoch ein modernes CMS als Unterbau nutzen. Großartig! Damit lassen sich auch komplexe Webdesigns ohne stundenlanges Umbiegen von – je nach CMS – Plugins oder Modulen umsetzen.

Mein Fazit

So viel Flexibilität und Anpassbarkeit hat natürlich seinen Preis. MODX Revolution™ ist – meiner Meinung nach – kein geeignetes System, wenn man schnell eine Low-Budget-Site mit einer handvoll konventioneller Seiten und meinetwegen noch einem Kontaktformular hochziehen möchte. Das ist wie das sprichwörtliche Schießen mit Kanonen auf Spatzen. Hier haben andere Syteme die Nase vorn. Mein Favorit für kleine Projekte oder Projekte mit dünnem Budget, ist nach wie vor WebsiteBaker oder LEPTON CMS oder auch das noch relativ neue BlackCat CMS (auf LEPTON CMS basierend). Sobald die Anforderungen an ein Webprojekt allerdings komplexer werden, gelieferte Webdesigns detailverliebt und sehr präzise bei dennoch schlanker Codeausgabe im Frontend umgesetzt werden sollen, dann ist MODX Revolution™ derzeit meine absolute Empfehlung. Die Lernkurve während der Einarbeitung ist deutlich steiler als in vielen anderen populären CMS, wird jedoch nachhaltig mit höchster Vielseitigkeit belohnt.

Buchempfehlung

Für all Diejenigen, die jetzt Blut geleckt haben, möchte ich das Buch von MODX Revolution™ Evangelist Bob Ray empfehlen: „MODX: The Official Guide„. Dieses Buch in Telefonbuchstärke bietet einen sehr umfangreichen aber gut verdaulichen Einstieg in MODX® und hat mir am Anfang sehr geholfen, die Konzepte hinter MODX Revolution™ noch besser zu verstehen.

MODX: The Official Guide – ein gelungenes (englischsprachiges) Buch für den Einstieg in MODX.