Die Lücke wurde bisher leider noch nicht vom Entwickler geschlossen. Da seit dem Jahr 2008 keine Updates für QContacts veröffentlicht wurde, ist fraglich, ob noch ein offizielles Update zur Behebung der Lücke entwickelt wird.

Was ist die Ursache der Sicherheitslücke?

Die Sicherheitslücke wird durch die unsaubere Verwendung des filter_order Parameters verursacht. Dieser Parameter kann beim Aufruf der Kategorien-Ansicht in der URL definiert werden und wird in der Komponente mit der Joomla-API-Funktion getUserStateFromRequest einer Variable zugeordnet. Da die Variable – an die der Inhalt des Parameters übergeben wird – in einem SQL-Query verwendet wird, ist es über die geschickte Manipulierung des Parameters möglich, eigene SQL Anweisungen auszuführen.

Wie kann die Sicherheitslücke behoben werden?

Für alle, die auf die Kategorien-Ansicht verzichten können, empfiehlt sich die Löschung dieser Ansicht. Durch diese Maßnahme kann die Sicherheitslücke von Angreifern nicht mehr ausgenutzt werden und die Funktionsweise der restlichen Ansichten wird nicht beeinträchtigt.

Um den View zu entfernen, muss auf dem Server der Order *JoomlaStammverzeichnis*/components/com_qcontacts/views/category/ gelöscht werden. Sollte zu einem späteren Zeitpunkt ein Update für QContacts erscheinen, reicht es aus, diesen Ordner erneut hoch zu laden, um die Kategorien-Ansicht wieder nutzen zu können.

Gibt es einen Weg, um die Kategorien-Ansicht weiterhin nutzen zu können?

Möchte man die Kategorien-Ansicht weiterhin nutzen, muss die Lücke schnellstmöglich komplett beseitigt werden. Da für eine saubere Lösung jedoch ein Teil der Komponente neu implementiert werden muss, ist der Aufwand für die Beseitigung relativ hoch.

Zwei Lösungsansätze zur Beseitigung der Lücke

Sicherer als die momentane Implementierung wäre beispielsweise, wenn der Parameter filter_order nur Integer-Werte (Ganzzahlen) akzeptiert. Alternativ ist es möglich, den Parameter auf unerwünschte Zeichen zu kontrollieren und diese gegebenenfalls zu entfernen.

Ist eine Migration von Joomla 1.5 auf 2.5 unbedingt erforderlich oder gibt es eine einfachere Lösung?

Die Frage, ob eine einfachere Lösung möglich ist, ist schwierig zu beantworten. Im Prinzip kann man sagen, dass Joomla 1.5 weiterverwendet werden kann, bis eine Sicherheitslücke für Joomla selbst oder eine verwendete Erweiterung veröffentlicht wird. Sollte dieser Fall eintreten, dann besteht die Möglichkeit, dass ein unabhängiger Entwickler ein inoffizielles Update für die Schließung der Lücke veröffentlicht. Sollte dies nicht der Fall, müsste innerhalb kurzer Zeit eine Migration durchgeführt werden. Zudem besteht das Risiko, dass Sicherheitslücken bei ältere Software nicht veröffentlicht werden und die Website daher für gezielte Angriffe anfällig ist. Ich würde daher jedem – der nicht selbst ein erfahrener Entwickler ist und die Risiken sicher einschätzen kann – empfehlen, die Migration spätesten kurz vor dem Auslaufen des Supports für Joomla 1.5 durchzuführen.

Zu welchem Zeitpunkt sollte die Joomla Migration durchgeführt werden?

Aufgrund der Veröffentlichungsstrategie des Joomla Entwicklerteams (neue Versionen zu festen Zeitpunkten) würde ich empfehlen, nicht direkt nach der Veröffentlichung von Joomla 2.5 zu migrieren. Feste Veröffentlichungstermine führen meiner Meinung nach leider – durch den häufig vorhandenen Zeitdruck kurz vor dem angestrebten Veröffentlichungstermin – oft zu Fehlern in der entwickelten Applikation. Ich würde daher dazu raten, zumindest einen Monat (besser zwei) nach der Veröffentlichung von Joomla 2.5 mit der Migration zu warten. Bis dahin sollten alle schwerwiegenden Fehler entdeckt und behoben worden sein.

Ist auch eine sofortige Migration möglich?

Wenn Sie eine der neuen Funktionen von Joomla 2.5 dringend benötigen, könnte die Migration auch früher gewagt werden. Es besteht dann allerdings das Risiko, dass – bei eventuell auftretenden Fehlern – mehr Zeit als eigentlich nötig in die Migration investiert werden muss. Sollte die sofortige Migration in Betracht kommen, empfiehlt es sich, die migrierte Seite vor dem online stellen ausgiebig zu testen.

Mit welchem Zeitaufwand ist bei einer Joomla Migration zu rechnen?

Der Zeitaufwand ist von verschiedenen Faktoren abhängig. Oft wird im Zuge einer Migration eine komplette Modernisierung der Website durchgeführt oder es werden zumindest Altlasten entfernt. Sollte dies nicht nötig sein und die Website soll eins-zu-eins übernommen werden, hängt der Zeitbedarf direkt von den verwendeten Komponenten, Modulen und Plugins ab. Sollten diese nicht mit Joomla 2.5 kompatibel sein oder mittlerweile nicht mehr weiterentwickelt werden, müssen Alternativen gesucht werden und die alten Erweiterungen ersetzt werden. Hierbei könnte sich die Übernahme der mit der Erweiterung verwalteten Daten als kompliziert erweisen. Die Übernahme der Inhalte selbst, sollte meines Kenntnisstandes zufolge relativ schnell zu erledigen sein.

Um eine eigene Erweiterung zu entwickeln, ist es nicht unbedingt erforderlich, über die Architektur von Joomla Bescheid zu wissen. Mit dem Zusammenkopieren von Code aus anderen Erweiterungen lassen sich auch für Anfänger mehr oder weniger brauchbare Erweiterungen programmieren.

Sind Hintergrundinformation über die Joomla Architektur hilfreich?

Meiner Meinung nach ist es jedoch sehr hilfreich, sich vor der Entwicklung eigener Erweiterungen mit der Joomla Architektur auseinanderzusetzen. Mit diesem Hintergrundwissen ist es möglich, den Aufbau von Komponenten, Modulen und Plugins besser zu verstehen.

In diesem Artikel werde ich die Joomla Architektur auf einem sehr abstrakten Niveau beschreiben. Der folgende Text liefert daher keine konkreten Informationen zur Entwicklung eigener Joomla Erweiterungen, sollte aber als guter Einstiegspunkt in die Entwicklung unter Joomla dienen und die selbständige tiefergehende Einarbeitung in die Materie erleichtern.

Die Joomla Architektur: Übersichtsgrafik

Die Framework Ebene

Die Architektur von Joomla ist schichtweise aufgebaut. Das Fundament bildet die Framework Ebene (Framework Layer). Die Framework Ebene umfasst die internen und externen Bibliotheken (Libraries), die Plugins, sowie das Joomla Framework selbst.

Bibliotheken – die kleinen Helferlein

Eine Bibliothek ist eine Sammlung von Funktionen, die den Entwickler bei der Implementierung von Erweiterungen unterstützt und dem Entwickler somit Arbeit abnimmt.

Ein anschauliches Beispiel ist eine Bildbearbeitungsbibliothek. Eine Bildbearbeitungsbibliothek unterstützt den Entwickler – wie der Name erahnen lässt – bei der Bearbeitung von Bildern. So bieten diese Bibliotheken beispielsweise meist fertige Funktionen zum Zuschneiden, Vergrößern oder Verkleinern von Bildern. Eine solche Bibliothek ist auch in der Joomla Plattform (mehr Informationen zur Plattform sind weiter unten in diesem Artikel zu finden) verfügbar.

Externe Bibliotheken können seit der Joomla Version 1.6 über den Erweiterungsmanager im Joomla Backend installiert werden. Zuvor war es nur möglich, die mit Joomla mitgelieferten Bibliotheken zu nutzen beziehungsweise Bibliotheken zusammen mit der Erweiterung auszuliefern.

Das Framework – der Kern von Joomla

Das Framework ist sozusagen der Kern von Joomla und somit der das wichtigste Element der Joomla Architektur. Es beinhaltet alle Klassen, welche in Paketen (packages) organisiert sind. Die öffentlichen Methoden des Frameworks bilden die Joomla API, welche intensiv bei der Entwicklung von Erweiterungen verwendet wird.

Ein Beispiel ist die abstrakte Klasse JDatabase und die von JDatabase erbenden Klassen JDatabaseMySQL und JDatabaseMySQLi, welche für das Management der Datenbankverbindung verantwortlich sind.

Eine vollständige Erläuterung des Frameworks würde leider den Rahmen dieses Artikel sprengen. Interessierte können jedoch mit Hilfe des API-Browsers etwas in den Klassen stöbern.

Plugins – Eingriff in das Framwork

In vielen Fällen möchte man Funktionen implementieren, welche eigentlich einen Eingriff in das Framwork erfordern. Um einen solchen Eingriff und die damit verbundenen Probleme zu vermeiden, gibt es den Plugin-Mechanismus. Dieser Mechanismus ermöglicht es, beim Auftreten vordefinierter Events, eigenen Code (definiert im Plugin) auszuführen.

Ein viel verwendetes Event ist "onPrepareContent". Dieses Event tritt vor der Vorbereitung der Inhalte (Artikel) für die Präsentation ein und wird meist zur Manipulation der Inhalte verwendet. Zum Beispiel zum Ersetzen von Platzhaltern mit dem eigentlichen Inhalt.

Die Anwendungsebene

Auf der Framework Ebene aufbauend findet sich die Anwendungsebene (Applikation Layer). Die Anwendungsebene besteht seit Joomla 1.6 aus drei Anwendungen, welche alle von der Framework-Klasse JApplication erben.

Die erste Anwendung ist JInstallation, welche für die Installation von Joomla verantwortlich ist. Zudem gibt es noch JAdministrator und JSite. Wie die Namen bereits vermuten lassen, ist JAdministrator für die Joomla Administrationsoberfläche und JSite für das Frontend zuständig.

Die Erweiterungsebene

Nun sind wir bei der obersten Ebene angelangt, bei welcher es für die meisten interessant wird: Der Joomla Erweiterungsebene (Extension Layer). Auf der Erweiterungsebene befinden sich die Module, Komponenten und Templates. Zusammen mit Joomla werden bereits einige dieser Erweiterungen ausgeliefert. Beispielsweise die Standardtemplates und der Medienmanager.

Wer selbst Module oder Komponenten entwickelt, arbeitet immer auf der Erweiterungsebene. Mit den darunterliegenden Ebenen sollte nur mit Hilfe der Joomla API (Application Programming Interface) kommuniziert werden.

Die strikte Trennung der Ebenen hat unter anderem den Vorteil, dass sich Änderungen an der internen Funktionsweise des Framework oder der Applikationsebene nicht auf die Funktion der Erweiterungen auswirken. Ausgenommen natürlich der Fall, dass sich die API selbst ändert.

Die Ausgliederung der Plattform

Die Framework Ebene wurde mit dem Erscheinen von Joomla 1.7 aus dem Joomla CMS Projekt ausgegliedert und wird seitdem als eigenständiges Projekt weitergeführt. Das ausgegliederte Projekt trägt den Namen Joomla Platform und kann unabhängig vom Joomla CMS als Grundgerüst für die Entwicklung von PHP-Webanwendung genutzt werden. Aktuell ist die Plattform in der Version 11.2 verfügbar.

Weitere CMS Architektur Artikel 

Ich hoffe, ich konnte einigen mit diesem Artikel eine verständliche Einführung in die Architektur von Joomla geben. In Zukunft werde ich wahrscheinlich weitere technische Artikel über die Architektur anderer Content-Management-Systeme (CMS) schreiben. Dies soll unter anderem dazu beitragen, dass die Wahl des richtigen CMS auch mit Blick auf die Architektur getroffen werden kann.

Bilderquellen

[Die Joomla Architektur] http://docs.joomla.org/File:Joomla_Architecture.jpg

[Der Pluginmanager] http://docs.joomla.org/Help16:Extensions_Plugin_Manager

[Der Erweiterungsmanager] http://docs.joomla.org/File:ExtensionInstallation.jpg

Leider konnte ich die Lizenzierung der Grafik vor der Publizierung des Artikels nicht klären. Zwischenzeitlich konnte ich aber in Erfahrung bringen, dass die Infografik unter der Creative Commons BY-NC-SA Lizenz veröffentlicht wurde. Daher werde ich euch die Grafik natürlich nicht vorenthalten.

Die Grafik wurde von Sander Potjer erstellt. Sander ist ein Webdesigner, welcher sich unter anderem in der Niederländischen Joomla Community engagiert.

Für alle, die dem Englischen nicht mächtig sind, hat David Jardin von SistaSystems eine deutsche Übersetzung angefertigt.

Joomla Geschichte

Die erste Joomla Version erschien im Jahr 2005 und wurde logischerweise mit der Versionsnummer 1.0 ausgezeichnet. Joomla 1.0 war ein Fork von Mambo und wurde von ehemaligen Mambo Entwicklern wegen Streitigkeiten um die Namensrechte an Mambo ins Leben gerufen [@joomla-geschichte].

Kurze Zeit nach der Veröffentlichung von Joomla 1.0 wurde mit der Entwicklung von Joomla 1.5 begonnen. Die Fertigstellung von Joomla 1.5 dauerte mehr als zwei Jahre und wurde im Januar 2008 abgeschlossen. Aus technischer Sicht war die Einführung des Model-View-Controller (MVC) Patterns eine der größten und wichtigsten Neuerungen in Joomla 1.5.

Der neue Veröffentlichungszyklus

Mit der Veröffentlichung von Joomla 1.6 wurde das Projekt auf einen neuen Veröffentlichungszyklus umgestellt. Der neue Veröffentlichungszyklus sah vor, alle sechs Monate eine neue Joomla Version zu veröffentlichen. Ziel der neuen Strategie war es, den Besuchern neue Funktionen zeitnah zur Verfügung zu stellen. Zur neuen Strategie gehörte auch die Einführung der Joomla Versionen mit Langzeit-Support. Hintergrund für diese Entscheidung war, dass viele Anwender nicht jedes halbe Jahr auf eine neue Version umsteigen wollen und Anbieter von umfangreichen Erweiterungen nicht immer mit dem hohen Tempo mitziehen können.

Die zukünftige Versionierung

Nach Joomla 1.6 erschien Joomla 1.7. Ebenfalls eine Zwischenversion mit Kurzeit-Support. Die Folgende Version mit Langzeit-Support wird Joomla 2.5. Ein .5 hinter der Hauptversionsnummer wird in Zukunft alle Joomla Versionen mit Langzeit-Support kennzeichnen. Zwischen zwei Langzeit-Support-Versionen werden jeweils zwei Zwischenversionen, welche mit .0 und .1 gekennzeichnet sind, erscheinen. Für diese Versionierung hat sich die Joomla Community in einer Abstimmung entschieden. Zur Abstimmung standen jedoch nur zwei mögliche Varianten. [@abstimmung] [@abstimmung-ergebnis]

Ein schlüssiges Konzept?

Über die neue Versionierung wurde viel diskutiert. Meiner Meinung nach ist sie für Neueinsteiger beziehungsweise Joomla "Gelegenheitsnutzer" wahrscheinlich zu verwirrend, jedoch ist auch eine gewisse Logik hinter der Entscheidung erkennbar. Der Schlüssel zum Erfolg der neuen Versionierung wird daher wohl eine unmissverständliche Kommunikation der Versionierung auf den offiziellen Joomla Seiten sein.

Update: Infografik Joomla Versionierung

In diesem Artikel finden Interessierte noch eine Infografik, welche die Joomla Entwicklungsstrategie sehr schön visualisiert.

Quellen

[joomla-geschichte] Joomla – Wikipedia, besucht am 3. Dezember 2011, http://de.wikipedia.org/wiki/Joomla#Geschichte

[abstimmung] Vote for the Version | Joomla! Community Portal, besucht am 3. Dezember 2011, http://community.joomla.org/blogs/leadership/1472-vote-for-the-version.html

[abstimmung-ergebnis] The Version Votes Are In | Joomla! Community Portal, besucht am 3. Dezember 2011, http://community.joomla.org/blogs/leadership/1472-vote-for-the-version.html

Die aktuelle Situation

Dies ist bei Croogo glücklicherweise nicht so. Seit Anfang Mai 2010 wurden immerhin vier Updates für Croogo 1.3, sowie eine Beta Version von Croogo 1.4 veröffentlicht. Croogo 1.4 bietet keine wirklichen Neuerungen, da nur ein Update des verwendeten CakePHP Frameworks von Version 1.3 auf 2.0 durchgeführt wurde.

Die Verbesserungen im Überblick

In der 1.3 Serie hat sich zwischenzeitlich jedoch einiges getan. In Version 1.3.1 wurde das Taxonomie System überarbeitet, sodass es ab dieser Version möglich war, einem Term mehreren Vokabularen zuzuweisen. Neben der Verbesserung des Taxonomie Systems wurde ein neues Security Feature – eine Beschränkung der missglückten Login Versuche – eingeführt. Desweiteren wurden einige Unit Tests hinzugefügt. Eine vollständige Liste der Verbesserungen ist im offiziellen Blog zu finden.

Mit dem Erscheinen von Version 1.3.2 wurde das Plugin System verbessert, sodass Erweiterungen auch von nicht-Entwicklern verwendet werden können. Bisher war es für die Einbindung von Erweiterungen nötig, CakePHP Hintergrundwissen mitzubringen (offizielle Ankündigung).

Mit den Versionen 1.3.3 und 1.3.4 wurden keine größeren Änderungen eingeführt. Mit diesen Versionen wurden Verbesserungen am Admin Panel – qua Benutzerfreundlichkeit – vorgenommen und einige Fehler beseitigt. Mit dem Erscheinen von Croogo 1.3.4 im Oktober 2011 hat Croogo offiziell die Beta Phase verlassen.

Verfügbare Erweiterungen und Themes

Seit meinem letzten Blick auf die Croogo Website wurde eine beachtliche Anzahl Erweiterungen veröffentlicht. Natürlich ist die Vielfalt der Erweiterungen (noch) nicht mit Joomla, Drupal oder WordPress vergleichbar… Eine kleine, interessante Auswahl wäre beispielsweise das Markdown Plugin, der CKEditor, sowie ein Lucene Search Plugin. Neben den Erweiterungen stehen auf der Croogo Website zudem sechs freie Themes zum Download bereit.

Was ist in Zukunft von Croogo zu erwarten?

Insgesamt hinterlässt der Fortschritt bei Croogo einen sehr guten Eindruck. Beim Lesen der offiziellen Update Ankündigungen gewinnt man das Gefühl, der Hauptentwickler versteht etwas von seinem Handwerk. Die Portierung auf CakePHP 2.0, sowie die Entwicklung von diversen Erweiterungen durch verschiedene Entwickler deuten auf eine positive Zukunft und eine wachsende Community hin. Sobald es meine freie Zeit zulässt, werde ich auf jeden Fall wieder einen ausführlicheren Blick auf Croogo werfen.

Beim Einsatz von Java in der Web-Entwicklung gibt es allerdings ein großes Problem: Das Hosting. Ich habe mich nun eine Weile umgeschaut, konnte aber keinen seriösen Webspace Anbieter finden.

Java Hosting Möglichkeiten

Natürlich gibt es noch ein paar Alternativen zum einfachen Webspace mieten, diese kommen für mich allerdings nicht in Betracht. Ein managed Server ist für mich schlicht überdimensioniert. Für ein paar kleine Websites mit durchschnittlichem Besucheraufkommen lohnt sich die Anmietung nicht.

Für die preisgünstigere Alternative – einen selbst gewarteter virtueller Server – habe ich keine Zeit. Die Grundkonfiguration mag zwar schnell erledigt sein. Für den sicheren Betrieb ist aber deutlich mehr Zeit zu investieren. Das Einspielen von Updates und die Analyse und Abwehr von Angriffen machen einen vServer schnell zum Teilzeitjob.

Die letzte Möglichkeit – und gleichzeitig mein Favorit – wäre ein Premium Webspace Anbieter. Idealerweise eine Kombination aus vServer und normalen Webspace, wie sie mein momentaner Hoster anbietet. So hat man keinen Wartungsaufwand, aber dennoch die Flexibilität die Konfiguration selbst anzupassen. Leider sind solche Hoster kaum zu finden. Die meisten Anbieter, die ich gefunden habe, sind relativ unseriös. Entweder die Website ist optisch und technisch so schlecht, dass man die Seite schnell wieder verlässt oder die Preise bewegen sich in einem Rahmen, indem meiner Meinung nach kein qualitativ gutes Hosting angeboten werden kann.

Google App Engine: Die Alternative

Gestern bin ich zufällig noch über die Google App Engine gestolpert. Ich habe zwar schon von diesem Service gehört, mich aber noch nicht intensiver damit auseinandergesetzt. Die Idee der App Engine ist, dass man für seine eigenen Applikationen die Google Infrastruktur nutzen kann. Bis zu den bestimmten Grenzen sogar kostenlos. Sollte das Limit überschritten werden, müssen nur die Ressourcen bezahlt werden, die wirklich genutzt wurden. Ein großer Vorteil der App Engine gegenüber einem gemieteten Server ist die Tatsache, dass die eigene Website auch bei einem plötzlichen Besucheransturm stabil und performant erreichbar ist.

Wo ist der Haken?

Näher will ich nun nicht mehr auf die Google App Engine eingehen, denn es gibt einen Hacken an dem Angebot, der viele Anwendungen unmöglich macht. Zum Abspeichern der Daten muss – fast zwangsweise – die von Google zur Verfügung gestellte Datenbank verwendet werden. Da die "Java Database Connectivity" (JDBC) Klasse nicht unterstützt wird, ist es schwierig beziehungsweise unmöglich eine eigene Datenbank zu verwenden.

Mal davon abgesehen, dass mit der Verwendung einer eigenen Datenbank viele Nachteile verbunden wären. Beispielsweise ginge die enorme Skalierbarkeit verloren, da die Datenbank einen Schwachpunkt in der Performance darstellt. Zudem stellt eine für externe Anwendungen offene Datenbank ein großes Sicherheitsrisiko dar. Die meist unverschlüsselten Übertragung der Daten über das Internet von der Applikation zur Datenbank ist ebenfalls nicht empfehlenswert.

Und ganz ehrlich: Wer will seine gesamte Datenbank Google überlassen? Womöglich noch mit Kunden-, oder Benutzerdaten… Ich mit Sicherheit nicht.

Welche Alternativen gibt es noch?

Viele Möglichkeiten bleiben nicht mehr übrig. Ich werde mir allerdings noch die managed vServer genauer anschauen. Wobei ich vermute, dass auch hier das Managen eines Java Containers oft nicht übernommen wird. Daher werde ich vermutlich vorerst bei PHP bleiben. Eventuell noch einen Blick auf Python werfen. Ob sich das Erlernen einer weiteren Skriptsprache wirklich lohnt, muss ich aber noch genau überdenken.

Falls jemand einen guten Java Hoster kennt, kann er natürlich gerne die URL als Kommentar hinterlassen.

Zeit für ein paar Screenshots der überarbeiteten Administrationsoberfläche inklusive der neuen Rechteverwaltung.

Der Login

Das Kontrollpanel / Dashboard

Globale Rechte Einstellungen

Access Levels

Neue Icons

Hilfe Center

Kategorie-Manager

Artikel-Manager

Artikel bearbeiten

Menü-Manager

Benutzer hinzufügen

Die Zugriffslevel

Shortcuts in der Menüleiste

Umgesehen habe ich mich, da ich momentan – aus verschiedenen Gründen – mit Joomla – welches ich momentan hauptsächlich einsetze – unzufrieden bin. Folgend poste ich, die zur Findung des optimalen CMS angelegte Pro und Contra Liste. Die Liste hat nicht den Anspruch vollständig zu sein. Vielmehr ist sie eine Stichwortsammlung. Argumente habe ich für die CMS Joomla 1.5 (aktuell genutzt), Drupal 7 (PHP Alternative) und dotCMS (Java Alternative) gesammelt.

Pro Joomla 1.5

• guter Webspace mit PHP Unterstützung ist leicht zu finden
• kommerzielle Verdienstmöglichkeiten durch breite Nutzerbasis
• Supportforen und freie Bücher für Kunden, die ihre Website selbst pflegen möchten, sind verfügbar
• Erweiterungen nutzen MVC-Pattern
• viele Erweiterungen verfügbar
• Einfache (Komplett-)Verwaltung für Kunden

Contra Joomla 1.5

• PHP Programmierung
• Codequalität
• Inhaltsstruktur (Bereiche und Kategorien)
• Abwärtskompatibilität (Inovationskiller)
• viele Erweiterungen nötig für Standard Blog funktionalität
• viel Overhead bei der Entwicklung von Erweiterungen
• allgemein zu feste Strukturen
• kein Rechtemanagement

Pro Drupal 7

• guter Webspace mit PHP Unterstützung ist leicht zu finden
• Multi-Site Support
• Modularer Aufbau
• Flexibilität
• Erweiterungen, die nur eine Funktion erfüllen
• Code-Basis ist gut nachvollziehbar
• Dokumentation
• Inhalte sind für Kunden einfach verwaltbar
• Multi-Language Support
• Keine Abwärtskompatibilität
• Small Core verfügbar
• Installationsprofile
• Bildverwaltung (inkl. Thumbnailgenerierung und Resizing)
• Organisation des Projektteams/ der Community

Contra Drupal 7

• PHP Programmierung
• eigene Inhaltsstrukturen nur beschränkt unterstützt

Pro dotCMS 1.9

• Java Programmierung
• Multi-Site Support
• Flexibilität
• Inhaltsstrukturen vollständig selbst definierbar
• Skriptingmöglichkeiten (z.B. in PHP und Ruby)
• Theming

Contra dotCMS 1.9

• guter Webspace mit Java Support ist schwer zu bekommen
• Weiterentwicklung abhängig von einer Firma
• gemischte Lizenz (Community und Enterprise Editionen)
• Komplexe Codebasis -> lange Einarbeitungszeit für guten Überblick über das System
• Dokumentation

Fazit

Da ich viel Wert auf Flexibilität, multi-Site, sowie multi-Language Support und ein überblickbares Systems lege, werde ich mich schlussendlich wohl für Drupal 7 entscheiden. Die Umsetzung des Vorhabens wird jedoch eine Weile dauern und falls ich während der Arbeit noch größere Nachteile oder Einschränkungen von Drupal entdecke, werde ich hier berichten.

Welches System ich in Zukunft meinen Kunden vorschlage, hängt weiterhin von deren Einsatzzweck ab. Joomla bietet gegenüber den anderen Systemen Vorteile, wenn ein Kunde – mit relativ wenig Vorwissen – seine Website vollständig selbst verwalten möchte.

Anmerkung: Ich unterscheide in der Einleitung dieses Artikels zwischen Web-CMS und CMS. Anlass hierfür ist, dass in der "Java-Welt" auch Content-Management-Systeme existieren, die nicht hauptsächlich für die Verwaltung von Internet-, bzw. Intranet-Seiten entwickelt wurden. In der "PHP-Welt" gibt es solche Systeme meines Wissens nach nicht, daher wird CMS oft mit Web-CMS gleichgesetzt.

Aufgrund der hohen Updatefrequenz einiger Content-Management-Systeme (CMS) könnte ich fast jeden Tag eine Newsmeldung über ein CMS schreiben. Für interessante Hintergrundartikel – z.B. über die Entwicklung von Erweiterungen – bleibt dann wenig Zeit. Daher werde ich in Zukunft im Blog nur noch wirklich wichtige Neuerscheinungen und Updates erwähnen.

Die Frequenz in der neue Artikel veröffentlicht werden, wird voraussichtlich etwas zurückgehen. Sollte sich aber bei ein bis drei Artikel pro Woche einpendeln.

Die Testberichte werden weiterhin ein Teil von AboutCMS sein. Die Informationen zu den Updates können bei den meisten CMS über einen RSS-Feed abgerufen werden. Zudem gibt es genügend Seiten, die über solche Ereignisse schreiben.

In diesem Sinne: Weiterhin viel Spaß beim Lesen des Blogs.