Als Unternehmen muss man auch beim Webauftritt auf das Geld achten. Der Einsatz eines Open-Source-CMS bietet sich meist an – es ist frei verfügbar und bei den großen Anbietern auch mit jeder Menge Features angereichert. Dabei können aber versteckte Kosten lauern – und unterm Strich fährt man vielleicht mit einer selbstentwickelten Lösung günstiger und besser.

François Zaninotto, Contributor beim Symfony-Projekt, hat sich in seinem Blog mit dem Thema auseinandergesetzt und wägt den Einsatz eines fertigen Open-Source-Content-Management-Systems gegen eine eigene, maßgeschneiderte Lösung ab. Dabei erklärt er nicht nur, wo genau versteckte Kosten lauern können, sonder zeigt auch auf, warum es sinnvoll sein kann eine eigene Lösung zu entwickeln. Selbst wenn das bedeutet, der schier endlosen Zahl an CMS-Lösungen eine weitere hinzuzufügen.

Was zu beachten ist

Worauf ist bei der kritischen Betrachtung eines CMS nun aber zu achten? François hat die wichtigsten Aspekte die für oder gegen ein fertiges CMS sprechen können, in elf Fragen zusammengefasst:

• Kann der Inhalt unabhängig von einer Webseite existieren?
• Kann Inhalt auf mehr als nur einer Seite im Webauftritt existieren?
• Gibt es mehrere Views für einen einzelnen Inhalt?
• Können Inhalte in verschiedenen Versionen gleichzeitig vorliegen?
• Können Inhalte im Backend geändert werden, ohne dass sie sich im Frontend ändern?
• Können die User eine Seite mit Widgets/Komponenten selbst zusammenstellen und steht ein WYSIWYG-Interface zur Verfügung?
• Können definierte Bereiche im Template auch mehrere Widgets/Komponenten enthalten?
• Können Unterseiten verschiedene Templates haben?
• Können Unterseiten in verschiedenen Versionen gleichzeitig vorliegen?
• Können User die Veröffentlichung von Seiten und Inhalten timen?
• Kann sich das CMS die URLs für Inhalte merken, deren Titel sich geändert hat?

No existing CMS will be able to answer these questions in every possible way. But designing your own relational schema based on the answer to these questions makes sense, economically speaking. Don’t make it complex if you don’t need do, or, to put it otherwise, Keep It Simple, Stupid. François Zaninotto, 2008

Aber auch weitere Punkte sind zu beachten. Wie können Änderungen am System zum Beispiel von der Testumgebung auf das Live-System überspielt werden? Müssen kompliziert einzelne Datensätze einer Tabelle in eine andere Tabelle übertragen werden (ohne die Live-Tabelle dabei komplett zu überspielen)? Oder reicht es vielleicht, nur etwas Code auf den Live-Server aufzuspielen?

Selbstgemacht. Aber wie?

Wer sich nach sorgfältiger Analyse für eine Eigenentwicklung entschieden hat, wird auf verschiedene technische Herausforderungen stoßen. Was das – speziell bei umfangreichen CMS – bedeuten kann, soll das folgende Gedankenexperiment verdeutlichen:

Welche Content-Typen brauche ich beispielsweise? Es gibt Artikel, aber vielleicht auch Filme, Bildergallerien oder auch Umfragen. Und wie werden diese abgelegt? Wird es eine Tabelle für alles geben oder vielleicht eine eigene Tabelle für jeden Typ? Aber was, wenn mehrere Tabellen in einer Übersicht zusammengeführt werden müssen? Vielleicht muss eine neue Tabelle mit Referenzen zu den Einträgen der übrigen Tabellen erstellt werden und natürlich aktuell gehalten werden.

If you are a developer, whenever you meet a client that asks you for a Drupal integration, try to sell your knowledge of CMS architectures rather than a few hours of developer time. Raise the important questions, talk about the possible problems of using off-the-shelf solutions. If you ever used one of those before, you will have plenty of issues to talk about. Then, try to convince your customer to trust you into a custom development. Make it small at the beginning, so that the customer can start using it right away and refine its requirements incrementally. François Zaninotto, 2008