Suche
First Steps mit Magnolia CMS

Magnolia CMS: Eine Praxisanleitung für die ersten Schritte

Ingo Jäger

(c) Shutterstock / ivosar

Mit der Entscheidung für ein Content-Management-System (CMS) und der Auswahl des passenden Systems beginnt für den Entwickler die eigentliche Arbeit: Die Implementierung des Systems und eines Software-Stack. Ingo Jäger ist Spezialist für CMS beim Berliner IT-Unternehmen Neofonie. Er beschreibt anhand des Java-basierten CMS Magnolia, wie ein optimaler Software-Stack aussehen muss, um komplexe Webportale umsetzen zu können.

Magnolia aus Entwicklersicht

Zur Umsetzung des Reiseportals spanien.de und dem Online-Angebot für Vorschulkinder toggolino.de hat Neofonie das Magnolia-CMS eingesetzt, sowohl als kostenlose Community-Version, als auch in der kostenpflichtigen Enterprise-Edition. Aus Entwickler-Perspektive bietet das Magnolia CMS sehr flexible Einsatzmöglichkeiten, insbesondere durch die starke Orientierung an gängigen Standards und den konsequenten Einsatz etablierter Open-Source-Technologien. Anpassungen an Konfigurationen und Funktionalitäten oder der Austausch ganzer Funktions-Komponenten wird dadurch sehr erleichtert bzw. überhaupt erst möglich.

In der Regel ist die schnelle Einarbeitung für einen Entwickler ohne Magnolia-Erfahrung ohne weiteres möglich ist. Für die Integration in eine Systemlandschaft mit verschiedenen Komponenten bietet Magnolia die Möglichkeit, auf sämtliche im Java Content Repository (JCR) abgelegten Inhalte und Konfigurationen mithilfe eines REST-Service zuzugreifen. Auch das Erzeugen oder Bearbeiten von Inhalten sowie die Ausführung von Magnolia Commands wie z.B. „Publizieren“ oder „Versionieren“ ist mit diesem REST-API möglich. Mit dem Tool-Set lässt sich beispielsweise der Export von Inhalten aus einem externen System an eine Magnolia-Instanz realisieren und gegebenenfalls sogar das „ferngesteuerte“ Publizieren von Inhalten. Eine entsprechende Dokumentation ist hier zu finden.

Darüber hinaus bringt das System auch verschiedene Factory-Klassen und Interfaces mit, um entsprechende REST-Client-Funktionalitäten zu realisieren. Damit können externe Inhalte direkt in Redaktionsdialoge integriert werden, z.B. um in einem Artikel eine bestimmte Google-News-Meldung zu referenzieren.

Falls die Interaktion mit anderen Systemkomponenten via REST nicht möglich oder nicht gewünscht ist, kann der Zugriff auf Daten außerhalb des JCR mithilfe des sogenannten Content Connector Interface realisiert werden. Java-Klassen, die dieses Interface implementieren, können sehr einfach in eine Magnolia App integriert werden, so dass ein Zugriff auf externe Daten über die native Magnolia GUI problemlos möglich ist. Eine Anwendungsmöglichkeit wäre hier die Verwaltung redaktioneller Assets wie Bilder oder PDFs im Amazon Webservice statt im JCR.

Sowohl in der Community-Edition als auch in der Enterprise-Edition stellt Magnolia sämtlichen Source Code via Git und Nexus öffentlich bereit.

Initiales Setup mit Maven

Das initiale Setup eines Magnolia-Entwicklerprojektes erfolgt üblicherweise mittels Maven Archetype. Ein entsprechender Katalog dafür wird von Magnolia bereitgestellt. Nach dem Generieren des Maven-Projekts findet man zunächst eine Verzeichnisstruktur mit einer leeren Webapp vor. Die eigentliche Magnolia-Funktionalität wird über entsprechende Overlays and Dependencies bereitgestellt. Die Grundkonfiguration ist zunächst im Overlay enthalten, kann und soll jedoch durch eigene Properties-Dateien ersetzt werden.

Magnolia kann wie jede andere Web-App auch in einen Tomcat-Server oder jeden anderen Servlet-Container deployed und dort gestartet werden.

Für die Implementierung eigener kunden- bzw. projektspezifischer Funktionalitäten wird die Kapselung in einem separaten Magnolia-Modul empfohlen. Dabei handelt es sich um ein Maven-Modul unterhalb des Magnolia-Projektes. Magnolia-Module enthalten einen Moduldeskriptor (XML), welcher die grundlegenden Meta-Daten des Moduls beinhaltet. Beim Starten der Web-App werden Magnolia-Module automatisch erkannt und mit Hilfe des Moduldeskriptors importiert bzw. geupdatet, wie auch in der Dokumentation nachzuvollziehen.

Content Storage

Neben den Magnolia Properties gehört zum Setup der Applikation auch die Konfiguration von Jackrabbit. Jackrabbit ist die für das JCR verwendete Implementierung. Dabei handelt es sich um eine Open-Source-Software unter dem Dach der Apache Software Foundation. Jackrabbit setzt die entsprechenden Spezifikationen JSR 170 und JSR 283 in vollem Umfang um.

Neben dem Repository Home und den Workspaces werden in der Jackrabbit-Konfiguration auch die eigentliche Persistenz-Schicht, die Versionierung, die Sicherheitseinstellungen und noch einiges mehr festgelegt.

Nach dem Erstellen eines Magnolia-Projekts mittels Maven Archetype ist Jackrabbit initial zunächst für die Verwendung von Derby DB als Persistenzschicht konfiguriert. Die Verwendung diverser anderer Persistence-Manager-Klassen für die Verwaltung der Daten in weiteren Datenbanken wie MySQL oder Oracle sowie im Filesystem ist ebenso möglich.

Sowohl im Projekt spanien.de als auch bei toggolino.de wurde die Konfiguration für die Verwendung von MySQL angepasst, so dass auch im Bereich der Datenschicht Software-Produkte und Technologien zum Einsatz kommen und kundenseitig bereits bestehende Workflows und Prozesse beibehalten werden konnten.

Eine klassische Magnolia-Installation besteht aus einer Autoren- und einer Public-Instanz. Beide Instanzen verfügen jeweils über ein eigenes JCR mit der dazugehörigen Konfiguration. Das Publizieren von Inhalten erfolgt immer von der Autoren-Instanz auf die Public Instanz(en). Die Inhalte werden dabei von einem JCR in das andere repliziert. Die Magnolia-Community-Edition unterstützt lediglich das Publizieren auf eine Public-Instanz. Aus Gründen der Ausfallsicherheit und Lastverteilung ist aber im Produktionsbetrieb der Einsatz von mindestens zwei Public-Instanzen empfehlenswert. Für den Publish auf mehrere Instanzen ist die Lizenzierung von Magnolia EE erforderlich. Allerdings gibt es auch bei Verwendung der CE die Möglichkeit, mit zwei Frontends zu arbeiten, indem man die beiden JCRs der Public-Instanzen zu einem Cluster deklariert, so dass sie dieselbe Persistenzschicht verwenden. Mit anderen Worten: zwei Magnolia-Instanzen, aber nur ein und dieselbe Datenbank dahinter (siehe auch Dokumentation). Diese Variante kam bei der Umsetzung von spanien.de zum Einsatz. Für toggolino.de war dies nicht notwendig, da hier die Enterprise-Edition von Magnolia verwendet wird, welche ohnehin das Publizieren auf mehrere Instanzen erlaubt.

Blossom Plug-in

Durch den Einsatz des Blossom-Plug-ins wird aus einer Magnolia Web-App eine Spring-MVC-Web-App. Dadurch eröffnen sich mit Blick auf die Implementierung spezifischer Business-Logik und die Anbindung externer Komponenten für den Entwickler eine Fülle weiterer Möglichkeiten.

Blossom enthält eine Reihe von Annotations, mit denen man das komplette Magnolia Templating in Form von Spring Controllern realisieren kann. Dies betrifft sowohl die Umsetzung von Page Templates und Areas als auch Component Templates. Sogar die Dialoge lassen sich auf diese Weise erzeugen.

Neben den bereits beschriebenen Vorteilen bringt das Templating mit Blossom allerdings auch einige Besonderheiten mit sich, die sich je nach Projekt-Situation als Nachteil bei der  Entwicklung erweisen können:

  • Änderungen an Blossom-Templates erfordern einen Neustart von Magnolia
  • Blossom-Templates sind weder in der Configuration App noch sonst irgendwo in der Magnolia GUI sichtbar, so dass man immer zwingend den Source Code benötigt, um die Konfiguration bzw. Implementierung der Templates nachvollziehen zu können.

Für das Erzeugen eines Blossom-Moduls stellt Magnolia ebenfalls einen Maven Archetype zur Verfügung.

 Magnolia STK

Für die Frontend-Entwicklung bringt Magnolia das Standard Templating Kit (STK) mit, welches für das Konfigurieren der Sites, Templates, Components und Dialoge sowie das Einbinden von Ressourcen wie JavaScript und CSS vorgesehen ist. Das Arbeiten mit dem STK verlangt dem Frontend-Entwickler allerdings einiges Vorwissen über Magnolia ab. Insbesondere hinsichtlich  der mitunter aufwendigen Konfiguration von Frontend-Ressourcen kann ein erheblicher Overhead entstehen, und durch die Arbeit mit der Magnolia GUI ergeben sich beim Entwickeln spezielle Prozesse und Workflows, die sich doch erheblich von der Frontend-Entwicklung in Nicht-Magnolia-Projekten unterscheiden können.

Für das Projekt toggolino.de wurde auf die Verwendung statischer Ressourcen innerhalb von Magnolia und damit auf das Arbeiten mit dem STK komplett verzichtet. Stattdessen werden sämtliche Grafiken, CSS- und JavaScript-Dateien auf separate Apache-Server-Instanzen deployed und im Betrieb von dort ausgeliefert. Die eigentliche Frontend-Entwicklung erfolgt innerhalb einer eigenen „Static Webapp“ unter Verwendung von Grunt.

Ab Version 5.4 ersetzt Magnolia das Standard Templating Kit durch die Magnolia Templating Essentials (MTE) mit dem Ziel, die Frontend-Entwicklung für Magnolia generell zu flexibilisieren und damit zu erleichtern.

Device Detection und Responsive Layout

Die von Magnolia mitgelieferten Konfigurationen für eine separate Auslieferung verschiedener Frontends in Abhängigkeit von sogenannten Channels (Device, Medium, Location, …) kommt beispielsweise zum Einsatz, wenn die Ansicht der Webseiten auf mobilen Endgeräten spezielle Frontendlösungen erfordert. Für das Projekt toggolino.de wurde auf den Einsatz dieser Technologie bewusst verzichtet, da die entwickelten Frontends ohnehin ein responsives Layout gewährleisten und eine serverseitige Device Detection damit obsolet ist. Desweiteren würde die Channel-Konfiguration die Verwendung des STK erfordern, welches hier ja ebenfalls ausgeklammert wurde.

Magnolia Content Apps

Neben den bereits erwähnten Features beinhaltet Magnolia auch ein eigenes App-Framework. Mit Magnolia-Apps können spezielle Funktionalitäten realisiert werden, mit denen gegebenfalls auch Inhalte und Konfigurationen verwaltet werden können, die vom redaktionellen Standard abweichen. Magnolia Apps lassen sich in folgende Typen unterteilen:

  • Content App
  • Functional App
  • Embedded App
  • Small App Layout

Content Apps kommen dabei sicherlich am häufigsten zum Einsatz. Im Projekt toggolino.de wurde ein Produktkatalog als Content App realisiert, wobei die Produktdaten in einem eigenen Workspace des JCR abgelegt und verwaltet werden.

Bestehende Content Apps lassen sich in der Regel auch sehr einfach kopieren und anpassen, da es sich dabei fast ausschließlich um Konfigurationen und nur in wenigen Fällen um Java-Code handelt. Bei toggolino.de wurde beispielsweise die Kategorien-App kopiert und für die Verwendung mit Lernkategorien angepasst. Dafür musste in der Konfiguration lediglich der Root-Knoten für die Kategorien-Inhalte angepasst und der Dialog für die Pflege der Kategorien um zwei Felder für das Einfügen spezieller Lernkategorie-Icons ergänzt werden.

Magnolia Node API

Um Inhalte im JCR auch programmatisch erzeugen und manipulieren zu können, bietet Magnolia eine eigene Node API an. Diese fand auch bei der Umsetzung von toggolino.de vielfach Anwendung, beispielsweise in der Versions-Handler-Klasse des Projekt-Moduls, um eigene Konfigurationen auf programmatischem Wege zu initialisieren. Bei der Entwicklung eines automatischen Importers für die TV-Programm-Daten von SUPER RTL kam die Magnolia Node API ebenfalls zum Einsatz. Die Daten wurden dabei zunächst mittels Spring REST von einer externen Datenquelle abgeholt, danach mittels JAXB auf entsprechende Node-Klassen gemapped und schließlich mithilfe der Node API im JCR persistiert. Mit Spring REST und JAXB kamen auch hier wieder Technologien zum Einsatz.

Die zyklische Ausführung solcher Import-Prozesse lässt sich übrigens durch das Magnolia-Scheduler-Modul steuern, welches Teil der Enterprise-Edition ist.

Aufmacherbild: CMS Content Management System von Shutterstock / Urheberrecht: ivosar

 

Neo Tech BlogÜber Neo Tech Blog

Neo Tech Blog befasst sich praxisnah mit plattformübergreifenden Anwendungen und Technologien für Web und Mobile.

Verwandte Themen:

Geschrieben von
Ingo Jäger
Ingo Jäger
Ingo Jäger ist seit 2008 als Softwareentwickler mit Fokus auf Java bei der Neofonie tätig. Zuvor war er u.a. als Entwickler und Projektmanager bei der AOL beschäftigt. Sein ausgeprägtes Know-how für Content Management Systeme bringt er bei der Umsetzung unterschiedlicher Kundenprojekte ein. Ingos weitere Leidenschaft ist Fußball.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.