Im Juni 2009 führte WIENFLUSS im Auftrag von WienTourismus den Relaunch der offiziellen Wiener Tourismuswebsite wien.info durch. In einer losen Artikelserie wollen wir ein wenig die Hintergründe und Erfahrungen aus diesem Projekt beleuchten.

Die Qual der Wahl – oder: die Suche nach dem richtigen CMS

Die Entscheidung, ob man wien.info weiterhin auf Basis des ursprünglich für die Website entwickelten Content-Management-Systems (CMS) betreiben und ausbauen möchte, oder ob man den Wechsel zu einem neuen System wagen sollte, war eine der wesentlichen Herausforderungen des Planungsprozesses. Letztendlich wurde die Entscheidung auf Basis der beiden alternativen Konzepte (Fortführung vs. Umstieg) mit Hilfe eines Gutachters und unter Abwägung von Für und Wider zugunsten des Umstiegs gefällt.

Doch ein Schritt zurück: bevor es zu der Vorlage der beiden Konzepte und dieser Entscheidung kommen konnte, musste ein geeignetes System gefunden werden. Für ein solch komplexes und umfangreiches System sollte man sich nicht zu sehr auf das eigene Produkt-Portfolio verlassen, sondern durchaus einen Blick auf den CMS-Markt werfen.

Die wesentlichsten Auswahlkriterien:

• Content-Management: Accessibility-konformer und UTF-8-kompatibler Richtext-Editor, gute Medien- und Assetverwaltung auch aus Sicht der Barrierefreiheit, Mehrsprachigkeit, Navigations- und Taxonomiemanagement.
• Redaktionssystem: übersichtliches und benutzerfreundliches Backend, Unterstützung der Mehrsprachigkeit.
• Frontend und Templating: flexibles Templatesystem für unterschiedlichste Arten von Inhalten, Frontend-Code muss völlig eigenständig sein (barrierefrei und standardkonform), sinngebende Adressierung (speaking URLs).
• Workflow-, Rechte- und Usermanagement: Abbildbarkeit eines eigenen Lifecycles, flexible Rechteverwaltung, Versionierung und Roll-back-Möglichkeiten, Übersetzungsworkflow.
• Technologie und System: Performance, Erweiterbarkeit (offene Schnittstellen), Open-Source, Sicherheit, Linux-basierter Betrieb.
• Dokumentation, Community-Support, Verbreitung in Österreich und namhafte Referenzen.

Die Liste der recherchierten Systeme wurde recht rasch auf etwa sechs engere Kandidaten eingeschränkt. In einer genaueren Analyse konnte diese Liste auf zwei Finalisten eingedampft werden: Plone und Typo3. Beide Systeme haben sicher ihre Vor- und Nachteile, im Stechen hatte jedenfalls Typo3 das Nachsehen.
Plone ist ein auf Zope (ein Webentwicklungs-Framework) und Python (die zugrundeliegende Programmiersprache) basierendes System, das sich unter anderem durch eine sehr professionelle Entwickler-Community, hohe Flexibilität, ein übersichtliches Interface und gute Unterstützung der Mehrsprachigkeit auszeichnet. Im Gegensatz zu vielen PHP-basierten Systemen ist Plone ein sehr komplexes und anspruchsvolles System, das professionelle Entwicklungskompetenzen erfordert.

Mit Daniel Nouri hatten wir einen äußerst erfahrenen Partner. Als einer der Core-Entwickler von Plone konnte er wertvolle Expertise ins Projekt einbringen.

Harte Entwicklungsarbeit – oder: funktionale Tests als Basis der Qualitätssicherung

In der professionellen Softwareentwicklung längst unumgänglicher Standard, werden automatisierte Tests (Unit-Tests oder funktionale Tests) in vielen Bereichen der Webentwicklung bis heute eher vernachlässigt.

Wie bereits erwähnt, hat Plone eine sehr anspruchsvolle und professionelle Entwickler-Community. Gut so, denn Plone besteht aus vielen Komponenten, die von den unterschiedlichsten Entwicklern stammen. Dazu kommen noch die vielen eigenentwickelten Module.

Naturgemäß können bei einem derart komplexen und modular aufgebauten System Änderungen an einer Stelle Auswirkungen auf andere Teile haben. Eine manuelle Überprüfung aller Funktionen nach jeder Änderung wäre eine nicht zu bewältigende Aufgabe und Updates im laufenden Betrieb würden damit zum Hasardspiel werden.

Daher sind wir dem Beispiel der Plone-Community gefolgt und haben von Anfang an funktionale Tests für jede unserer Entwicklungen geschrieben – ein nicht zu unterschätzender Aufwand, der sich aber spätestens im laufenden Betrieb rechnet. Vor jedem Update werden hunderte dieser Tests durchlaufen; auf mehreren Instanzen von Entwicklungs- und Testservern.

Erst wenn alle Testdurchläufe erfolgreich waren, wird ein Update des Produktionssystems in Angriff genommen. Selbstverständlich laufen auch dort noch ein letztes Mal die Tests durch, doch Fehler darf man sich hier eigentlich keine mehr erlauben – ein Rollback ist nicht nur lästig und peinlich, sondern verursacht unnötige Stillstandszeiten am Server.

Jedes Ding hat zwei Seiten – oder: die Trennung zwischen Front- und Backend

Eine unserer Grundanforderungen war ein vom Frontend vollständig isoliertes Backend, da bei komplexen und inhaltsstarken Layouts eine Verwaltung der Inhalte direkt im Frontend unpraktikabel wäre. Für gewisse Arten von Websites (z.B. Community-Plattformen, Intranet) macht eine solche Art des „In-Page-Editings“ durchaus Sinn – ab einer entsprechenden Komplexität ist dieses Konzept aber nur sehr bedingt einsetzbar. Abgesehen davon, dass sich ein autonomes Frontend leichter für eine gute Performance optimieren lässt.

Plone ist allerdings als Community-Plattform entwickelt worden. Die Unterscheidung von Front- und Backend ist daher nicht von vornherein vorgesehen. Wir haben deshalb eine vollständige Trennung zwischen dem öffentlichen Frontend und dem Redaktionssystem implementiert. Das wirkte sich nicht nur positiv auf die Geschwindigkeit des Frontends aus, sondern ermöglichte auch eine bessere Arbeitsteilung zwischen Plone-Entwicklern und Frontend-Entwicklern.

Zu diesem Zweck haben wir ein komplettes Set an Templates und Views (View / Controller) für das sogenannte PublicSkin erstellt. Nicht ganz einfach war es allerdings, das Standardverhalten von Plone in gewissen Bereichen so einzuschränken, dass man vom Frontend (wenn auch nicht eingeloggt) keinesfalls auf’s Backends gelangen konnte.

Ein weiterer wichtiger Teil der Trennung von Front- und Backend war die Änderung des Sprachverhaltens von Plone. Standardmäßig verhält sich Plone so, dass das Interface jeweils die Sprache der Inhalte annimmt. Bei einem arabischen Artikel wäre also das gesamte Backend ebenfalls arabisch. Das mag für manche Websites oder Redaktionen durchaus Sinn machen, in unserem Fall musste dieses Verhalten aber geändert werden.

Anmerkung: Die erwähnte Trennung von Frontend und Backend wurde von Daniel Nouri als Plone-Erweiterung auch in Form von collective.skinny zur Verfügung gestellt.

Herausforderungen – oder: Stärken, Hindernisse und Grenzen von Plone und Zope

Dass Flexibilität oft ein Segen, aber immer ein Fluch ist, dürfte wohl den meisten Softwareentwicklern ein Begriff sein. Für Zope und Plone gilt dasselbe. Vielfach hat das System unschlagbare Stärken, an anderen Stellen gibt es Hindernisse, die dank der systemgegebenen Flexibilität – nicht immer einfach, aber doch – überwunden werden können.

Rechtemanagement

Ein Paradebeispiel für die Flexibilität von Plone ist das integrierte Rechtemanagement. Berechtigungen, Rollen, Gruppen und Benutzer, dazu die Möglichkeit unterschiedlichster Authentifizierungsarten – all das ergibt ein äußerst mächtiges System.

Hier gilt also ganz allgemein: alles ist machbar, aber nichts einfach. Interessant wurde dieser Bereich für uns, da keines der vorkonfigurierten Rechte-Schemata von Plone genau auf die Anforderungen von WienTourismus passte. Es mussten neue Rollen eingeführt werden und neue Berechtigungen. An einer Vielzahl von Stellen im System mussten eigene Rechteüberprüfungen eingebaut werden. Dazu kam, dass die vordefinierten Berechtigungen von Plone und Zope teilweise etwas „unlogisch“ sind. So beispielsweise „Copy & Move“: Kopieren und Verschieben sind zwar zwei grundlegend unterschiedliche Aufgaben, werden aber in Plone als gemeinsames Recht vergeben.

Alles in allem bietet Plone ein sehr flexibles Rechtemanagement, das aber durchaus seine Grenzen hat. Ein detailliertes Rechte-Schema zu erstellen bedeutet einen nicht unerheblichen Zeitaufwand. Ob wir mit einem anderen CMS die vielfältigen Anforderungen rascher umsetzen hätten können, bleibt in Frage gestellt.

Workflow & Staging

Eine wichtige Funktion eines professionellen CMS ist ein frei definierbarer Redaktionsworkflow und die Inhalte schrittweise zu erarbeiten, zu kontrollieren, dann frei zu schalten und später wieder offline zu nehmen (Staging). Am besten natürlich auch zeitlich steuerbar.

Auch für diese Aufgabe kommt bei Plone mit plone.app.iterate ein Zusatzprodukt zum Einsatz. Dieses ist für die in Plone standardmäßig integrierten Workflow-Definitionen optimiert. In unserem Fall musste allerdings wieder einiges angepasst werden.

Für die zeitlich gesteuerte, automatische Statusänderungen haben wir ein eigenes Zusatzprodukt entwickelt, das für unseren Workflow optimiert ist und sowohl Statusänderungen an einzelnen Artikeln als auch an ganzen Ordnern samt Inhalt ermöglicht.

Bei einer so umfangreichen Website wie wien.info (knapp 5.500 Artikel, etwa 3.000 Bilder) ist es für die Redakteure natürlich auch wichtig, den Status jedes Dokuments im jeweiligen Kontext sofort zu sehen (Ist der Artikel, auf den ich da verlinke überhaupt online?). Diese Information ist in Plone und LinguaPlone (unserem Zusatzprodukt fürs Sprachmanagement) kaum ersichtlich. In der Navigation, im eigens gebauten Linkdialog und an vielen anderen Stellen musste hier nachgebessert werden.

TinyMCE statt Kupu

Barrierefreiheit war eine der Grundanforderungen für den Relaunch. Ein guter Richtext-Editor daher Pflicht. Mit Kupu ist ein Editor in Plone integriert, der unsere Anforderungen nur zum Teil erfüllen konnte. Wir haben uns daher entschieden ein Zusatzprodukt zu integrieren, das TinyMCE in Plone einbindet. Abweichende Konfigurationen des Editors für unterschiedliche Anwendungen waren hier die große Herausforderung.

Fazit

Im Großen und Ganzen war und ist Plone trotz seiner Komplexität oder gerade wegen der daraus resultierenden Flexibilität für unsere Anforderungen das richtige™ System geblieben. Auch wenn wir an der einen oder anderen Stelle ins System eingreifen mussten, sind wir im Endeffekt an keiner Stelle in eine Sackgasse geraten. Plone ist ein sehr mächtiges System, das wohl fast allen Anforderungen gerecht werden kann – wenn man sich vor der dazugehörigen Herausforderung nicht fürchtet.