Leistungsvergleich Wordpress vs Joomla

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Dortmund
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Content Management Systeme
Autor(en):	B. Wieczorek, W. Theophil, K. Kabackij, J. Deininghaus
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:
Studiensemester:	4
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 4.1 Motivation 4.2 Zielsetzung 4.3 Aufbau 5 Grundlagen 5.1 Content Management System 5.1.1 Definition und Charakteristika 5.1.1.1 Allgemeine Definition 5.1.1.2 Content 5.1.1.3 Management von Content 5.1.1.4 Systeme zur Verwaltung von Content 5.1.2 CMS Modelle 5.1.2.1 Redaktionssysteme 5.1.2.2 WCMS 5.1.2.3 ECMS 5.1.3 Front- und Backend 5.2 Blogging 5.3 Open-Source 5.4 GPL 5.5 Nutzwertanalyse 5.6 Joomla! 5.7 WordPress 6 Nutzwertanalyse 6.1 Problemdefinition 6.2 Zielsystem 6.2.1 Systemvoraussetzungen 6.2.2 Installation 6.2.3 Administrative Oberfläche 6.2.3.1 Benutzer- und Kontenverwaltung 6.2.3.2 Benutzergruppen und Rechteverwaltung 6.2.3.3 Geschützter Bereich und Freigabeverfahren 6.2.4 Sicherheit 6.2.4.1 Anfälligkeit für Sicherheitslücken 6.2.4.2 Verfügbarkeit von Bugfixes 6.2.5 Recoveryfunktion 6.2.5.1 Datensicherung 6.2.5.2 Administrator-Passwort vergessen 6.2.6 Systemüberwachung und Monitoring 6.2.6.1 Fehlerprotokollierung 6.2.6.2 Logging 6.2.7 Templates 6.2.8 Blogging 6.2.9 Search Engine Optimization (SEO) 6.2.10 Barrierefreiheit 6.2.11 Erweiterbarkeit 6.2.12 Erweiterungen verwalten / installieren / deinstallieren 6.2.13 Mehrsprachigkeit 6.2.14 Hilfe 6.3 Gewichtung des Zielsystems 6.4 Beschreibung der Alternativen 6.4.1 Systemvoraussetzungen 6.4.2 Installation 6.4.3 Administrative Oberfläche 6.4.3.1 Benutzer- und Kontenverwaltung 6.4.3.2 Benutzergruppen und Rechteverwaltung 6.4.3.3 Geschützter Bereich und Freigabeverfahren 6.4.3.4 Teilergebnis Administrative Oberfläche 6.4.4 Sicherheit 6.4.4.1 Anfälligkeit für Sicherheitslücken 6.4.4.2 Verfügbarkeit von Bugfixes 6.4.4.3 Teilergebnis Sicherheit 6.4.5 Recoveryfunktion 6.4.5.1 Datensicherung 6.4.5.2 Administrator-Passwort vergessen 6.4.5.3 Teilergebnis Recoveryfunktion 6.4.6 Systemüberwachung und Monitoring 6.4.6.1 Fehlerprotokollierung 6.4.6.2 Logging 6.4.6.3 Teilergebnis Systemüberwachung 6.4.7 Templates 6.4.8 Blogging 6.4.9 Search Engine Optimization (SEO) 6.4.10 Barrierefreiheit 6.4.11 Erweiterbarkeit 6.4.12 Erweiterungen verwalten / installieren / deinstallieren 6.4.13 Mehrsprachigkeit 6.4.14 Hilfe 6.5 Auswertung 7 Fazit 8 Fußnoten 9 Literatur- und Quellenverzeichnis 10 Internetquellenverzeichnis

1 Abkürzungsverzeichnis

2 Abbildungsverzeichnis

3 Tabellenverzeichnis

4 Einleitung

4.1 Motivation

Auf dem Markt der Content Management Systemen (CMS) befinden sich heutzutage eine Vielzahl an verschiedenen kostenfreien oder auch kostenpflichtigen Softwarelösungen. Vor allem im Rahmen des Web 2.0, welches sich großer Begeisterung erfreut und mittlerweile an vielen Stellen des Internets Einzug gehalten hat, haben CMS an Bedeutung gewonnen. Wurden im Web 1.0 Webseiten noch statisch vom Webmaster erstellt, so bieten die Web 2.0-Seiten eine Möglichkeit der Interaktion ("Mitmachnetz") zwischen den Benutzern. Ebenfalls ist es nun nicht mehr alleinige Aufgabe des Webmasters Inhalte zu erstellen und zu veröffentlichen, sondern viel mehr gestalten sich die Inhalte einer Webseite durch einen Dialog zwischen Autoren und Lesern.

CMS werden in verschiedenen Einsatzgebieten verwendet. Hauptsächlich die stetige Aktualisierungen von Internetpräsenzen und WebBlogs, gehört zu den Aufgaben von Content Management Systemen. Der Hauptvorteil, den Unternehmen hierbei aus dem Einsatz eines entsprechenden Systems ziehen, ist der geringe Aufwand in der Pflege und Verwaltung der Inhalte. CMS bieten also eine Kostenersparnis im Hinblick darauf, dass die unternehmenseigene Website nicht auf komplizierte Art und Weise, auf dem neuesten Stand gehalten werden muss. Insbesondere die Systme Joomla! und WordPress haben sich hierbei fest unter den CMS etabliert und werden daher im Rahmen dieser Arbeit vorgestellt und miteinander verglichen.

4.2 Zielsetzung

Das Ziel dieser Seminararbeit besteht darin, einen Leistungsvergleich von Joomla! und WordPress vorzunehmen. Dieser Vergleich soll an Hand einer fiktiven Ausgangssituation vorgenommen werden. Hierbei steht die Acme Co. vor der Entscheidung ein Content Management System für Unternehmenszwecke einsetzen zu wollen. Die in Frage kommenden Alternativen wurden bereits festgelegt und nun soll mittels einer Nutzwertanalyse entschieden werden, welche Alternative die Unternehmensanforderungen am besten erfüllt. Ein vollständiger technischer Vergleich kann dabei nicht erbracht werden, so dass das Ergebnis dieser Seminararbeit zu keiner allgemeingültigen Empfehlung führt.

4.3 Aufbau

In der vorliegenden Fallstudie werden die beiden Systeme WordPress und Joomla! in einem Leistungsvergleich gegenübergestellt. Hierzu werden zunächst einige grundlegende Definitionen zum Thema CMS, Open-Source und Blogging geliefert, die in dem Kontext der beiden Alternativen notwendig sind. Außerdem werden die beiden Softwarealternativen selbst kurz vorgestellt und die Nutzwertanalyse (NWA) als Vergleichsmethode beschrieben.

Nach den Grundlagenkapiteln wird dann die Ausgangssituation beschrieben und aufgezeigt unter welchen Gesichtspunkten die Nutzwertanalyse vorgenommen werden soll. Ausgehend von der beschriebenen Situation wird dann das Zielsystem der NWA definiert und die Punkte zunächst objektiv gegenübergestellt und beschrieben. Nach der Erläuterung der Punkte, die bewertet werden, erfolgt dann die Gewichtung der einzelnen Punkte im Zielsystem und die Ausprägung der einzelnen Merkmale innerhalb der Alternativen. Zum Abschluss der Fallstudie folgt dann die Auswertung der erarbeiteten Ergebnisse und ein abschließendes Fazit unter Berücksichtigung der Ausgangssituation.

5 Grundlagen

In diesem Abschnitt erfolgt zunächst eine Definition zu Content Management Systemen, Blogging und Open Source, um dem Leser einen Überblick über die Aufgaben der Software zu verschaffen, die verglichen wird. Außerdem wird die Nutzwertanalyse in Ihren Grundzügen erklärt und die beiden Software-Tools, die verglichen werden vorgestellt.

5.1 Content Management System

5.1.1 Definition und Charakteristika

5.1.1.1 Allgemeine Definition

Nachdem der Aufbau und das Betreiben von Webseiten seit 1994 als allgemeiner Imagefaktor eines Unternehmens angesehen wurde, wurden die damit einhergehenden Probleme ebenfalls sichtbar. Eines der Probleme ist die Tatsache, dass sich die Inhalte der Webserver nicht ohne geeignete Hilfsmittel verwalten lassen. Die große Menge von Informationen konnte nicht von wenigen Experten betreut werden. Der so entstandene Bedarf wurde daraufhin von den Softwareherstellern erkannt und es entstanden die ersten Softwaresysteme für das Management von Internetinhalten, die Content Management Systeme.^[1] Diese lassen sich wie folgt Definieren: „Im strengen Sinn der Definition werden innerhalb eines Content Management Systems sämtliche digitalen Daten eines in sich geschlossenen Systems organisiert und verwaltet. Dabei geht es in der Regel um die zentrale Verwaltung aller Daten innerhalb einer Groupware Anwendung, auf die die Teilnehmer aus einem Intranet oder auch dem Internet gemeinsam zugreifen können.“^[2] Neben den grundlegenden Funktionen der Verwaltung bieten die meisten Content Management Systeme noch weitergehende Funktionen an. Hierzu gehören vor allem Funktionen zum Erstellen, Präsentieren und Kontrollieren der Daten.^[3] Der Begriff Content Management System setzt sich aus drei Wörtern zusammen, dem Content, dem Management des Content und den Systemen. Die Bedeutung der einzelnen Punkte soll im Folgenden noch einmal genau aufgezeigt werden, damit der Zusammenhang im Rahmen von Content Management Systemen eindeutig ist.

5.1.1.2 Content

Im Allgemeinen wird unter Content der Inhalt bezeichnet, den ein Betrachter optisch wahr nimmt, sobald er eine digitale Information betrachtet. Im Rahmen von CMS handelt es sich allerdings nicht nur um die reine Information, sondern um die Summe der Einzelinformationen aus Struktur, Darstellungsform (Design) und Inhalt.

Bei dieser Dreiteilung der Informationen wird auch von der „Anatomie der Dokumente bzw. Informationen“ gesprochen, welche insbesondere dann dringend erforderlich ist, wenn die Informationen automatisch weiterverarbeitet werden sollen. Als Beispiel für diese Notwendigkeit führen Berres und Bullinger ein Word-Dokument an, bei dem die Überschrift in fetter Schrift dargestellt wird. Für den menschlichen Leser ist diese Überschrift zweifelsohne als solche zu erkennen. Damit ein Content Management System in der Lage ist die Zeile als Überschrift zu interpretieren reicht die fette Schrift allerdings nicht aus. Das CMS benötigt eine entsprechende Metainformation um die Zeile richtig zu interpretieren, was z.B. durch die Wahl einer entsprechenden Überschriften-Vorlage erfolgen könnte. Für die Benutzung eines CMS müssen Inhalte also contentorientiert zur Verfügung gestellt werden, damit das CMS einen Vorteil bieten kann und sein volles Potential entfalten kann.^[4]

5.1.1.3 Management von Content

Unter dem Management von Content versteht man die Behandlung digitaler Informationseinheiten in allen Prozessen und Prozessschritten nach dem „Single Source Multiple Media“ Prinzip. Die Informationen für alle möglichen infrage kommenden Medien werden also je nach Bedarf immer aus möglichst einer einzigen Quelle aufbereitet und zur Verfügung gestellt. Hierbei geht es jedoch nicht nur um die technische Realisierung des Content Management, sondern ebenfalls um ein Umdenken zur contentorientierten Inhaltsproduktion und eine entsprechende Organisationsgestaltung um diese Inhalte dann auch entsprechend zu nutzen. Als Beispiel für das Management von Content führen Berres und Bullinger eine Internetpräsenz auf, die permanent mit neuen Informationen gefüllt werden muss. Zum einen lassen sich durch das Management der Inhalte die grundlegenden Bausteine der Internetseite immer wieder verwenden und die Autoren der Seite müssen sich lediglich darum kümmern die Inhalte, bzw. die Texte zu hinterlegen. Zum Anderen müssen gleiche Daten nicht redundant hinterlegt werden, sondern können zentral hinterlegt werden, was sowohl einen geringeren Pflegeaufwand erforderlich macht als auch sicherstellt, dass die Daten auf der Seite nicht voneinander abweichen.^[5]

5.1.1.4 Systeme zur Verwaltung von Content

Als Systeme zur Verwaltung von Content sind die Content Management Systeme selbst zu verstehen. Derzeit gibt es mehr als 60 Hersteller von Content Management Systemen auf dem Softwaremarkt. Um das richtige System für ein Unternehmen oder ein Projekt zu ermitteln, ist eine gezielte Analyse der Unternehmenssituation und –ziele notwendig, auf die hier allerdings nicht weiter eingegangen werden soll. Die Kosten für die derzeit auf dem Markt erhältlichen Systeme reichen von 0 Euro für frei verfügbare Open-Source Lösungen bis hin zu 500.000 Euro und mehr für Unternehmensanwendungen mit einer entsprechenden Projektgröße.^[6]

5.1.2 CMS Modelle

Im folgenden Abschnitt erfolgt eine Definition der wesentlichen Klassifizierungen der heute erhältlichen Content Management Systeme.

5.1.2.1 Redaktionssysteme

Ein CMS, mit dem Charakter einer schnell zu implementierenden Lösung wird als Redaktionssystem bezeichnet. Meist verfügt es über vorkonfigurierte Funktionalitäten und entspricht einer „out-of-the-box“ Lösung.^[7] Der Schwerpunkt liegt in der Erstellung der Inhalte einer Internetpräsenz. Möglichkeiten wie die Verwaltung der Inhalte oder die gestalterische Einflussnahme auf die Inhaltsdarstellung haben für ein Redaktionssystem meist nur eine geringe oder gar keine Bedeutung.^[8]

5.1.2.2 WCMS

Ein Web Content Management System (WCMS) ist genau wie ein normales CMS ein Programm zur Erstellung und Verwaltung digitaler Daten. Allerdings handelt es sich meist um eine spezialisierte Software, welche ihren Schwerpunkt auf Medien aus dem Internet legt und im besonderen Masse auf die Anforderungen des Internets eingeht.^[9]

5.1.2.3 ECMS

Ein Enterprise Content Management System (ECMS) stellt meist eine anpassbare Plattform für die gesamte E-Business Strategie eines Unternehmens dar. Dies Bezieht sich nicht nur auf die Darstellung und Verwaltung von Inhalten der Internetpräses. Vielmehr bietet ein ECMS meist auch Möglichkeiten um Shopsysteme oder ERP-Systeme mit dem System zu Verknüpfen und es so in die Geschäftsprozesse mit einzubinden.^[10]

5.1.3 Front- und Backend

Im Allgemeinen lässt sich ein CMS in zwei grundlegende Teile aufteilen. Dem Frontend und dem Backend. Das Frontend steht hierbei für die eigentliche Webseite, die mit dem CMS betreut wird. Die Daten im Frontend werden hierbei meist automatisch und dynamisch aus den gepflegten Inhalten generiert. Das Backend hingegen lässt sich als Rückgrat des CMS verstehen. Es handelt sich um die Administrationsplattform eines Systems, in dem die Inhalte gepflegt werden und das System selbst konfiguriert wird.^[11]

5.2 Blogging

Das Blogging oder bloggen leitet sich vom englischen Wort Weblog ab und ist laut dem Duden wie folgt definiert:

„Blọg, das, auch: der; -s, -s [engl. blog, gek. aus: weblog, Weblog] (EDV Jargon): Weblog.“^[12]

Es handelt sich demnach, um ein aus dem englischen stammendes künstliches Wortgebilde, aus den Wörtern Web und Log. Das Web steht hierbei für das World Wide Web (WWW). Das Wort Log steht für ein Tagebuch, wie bei einem Logbuch. Sinngemäß müsste der Weblog also als Online-Tagebuch übersetzt werden. Nach Ansicht von Simovic ist dies aber eine unglückliche Übersetzung, da ein Tagebuch nach deutschem Verständnis eher intime Informationen beinhaltet und demnach ist der Begriff Online-Journal ihm zufolge treffender, um einen Blog zu beschreiben.^[13] Laut Simovic ist ein Weblog wie folgt zu definieren: „Ein Weblog ist eine sehr aktive und dynamische Website, die bestimmte Merkmale hat. Einige davon sind der chronologische Aufbau, der Fokus auf die einzelnen Beiträge und die persönliche Beziehung zwischen dem Autor bzw. dem Blogger einerseits und dem Leser/Besucher andererseits.“^[14]

5.3 Open-Source

Open-Source Software ist ein Begriff der 1998 mit der Gründung der Open Source Initiative (OSI) fest definiert wurde. Zwar gab es bereits in den sechziger Jahren quelloffene Software, allerdings wird der Begriff Open Source nur für Software benutzt, die durch eine von der OSI anerkannte Lizenz geschützt ist. Damit eine Softwarelizenz durch die OSI anerkannt wird, muss sie mindestens folgenden zehn Punkten entsprechen:^[15]

1) „Freie Weitergabe: Die Lizenz darf niemanden in seinem Recht einschränken, die Software als Teil eines Software-Paketes, das Programme unterschiedlichen Ursprungs enthält, zu verschenken oder zu verkaufen. Die Lizenz darf für den Fall eines solchen Verkaufs keine Lizenz- oder sonstigen Gebühren festschreiben.

2) Quellcode: Das Programm muss den Quellcode beinhalten. Die Weitergabe muss sowohl für den Quellcode als auch für die kompilierte Form zulässig sein. Wenn das Programm in irgendeiner Form ohne Quellcode weitergegeben wird, so muss es eine allgemein bekannte Möglichkeit geben, den Quellcode zum Selbstkostenpreis zu bekommen, vorzugsweise als gebührenfreien Download aus dem Internet. Der Quellcode soll die Form eines Programms sein, die ein Programmierer vorzugsweise bearbeitet. Absichtlich unverständlich geschriebener Quellcode ist daher nicht zulässig. Zwischenformen des Codes, so wie sie ein Präprozessor oder ein Übersetzer („Translator“) erzeugt, sind unzulässig.

3) Abgeleitete Software: Die Lizenz muss Veränderungen und Derivate zulassen. Außerdem muss sie es zulassen, dass die solcherart entstandenen Programme unter denselben Lizenzbestimmungen weitervertrieben werden können wie die Ausgangssoftware.

4) Unversehrtheit des Quellcodes des Autors: Die Lizenz darf die Möglichkeit, den Quellcode in unveränderter Form weiterzugeben, nur dann einschränken, wenn sie vorsieht, dass zusammen mit dem Quellcode so genannte „Patch Files“ weitergegeben werden dürfen, die den Programmcode bei der Kompilierung verändern. Die Lizenz muss die Weitergabe von Software, die aus verändertem Quellcode entstanden ist, ausdrücklich erlauben. Die Lizenz kann verlangen, dass die abgeleiteten Programme einen anderen Namen oder eine andere Versionsnummer als die Ausgangssoftware tragen.

5) Keine Diskriminierung von Personen oder Gruppen: Die Lizenz darf niemanden benachteiligen.

6) Keine Einschränkung bezüglich des Einsatzfeldes: Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Bereich einzusetzen. Beispielsweise darf sie den Einsatz des Programms in einem Geschäft oder in der Genforschung nicht ausschließen.

7) Weitergabe der Lizenz: Die Rechte an einem Programm müssen auf alle Personen übergehen, die diese Software erhalten, ohne dass für diese die Notwendigkeit bestünde, eine eigene, zusätzliche Lizenz auszuüben.

8) Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein: Die Rechte an dem Programm dürfen nicht davon abhängig sein, ob das Programm Teil eines bestimmten Software-Paketes ist. Wenn das Programm aus dem Paket herausgenommen und im Rahmen der zu diesem Programm gehörenden Lizenz benutzt oder weitergegeben wird, so sollen alle Personen, die dieses Programm dann erhalten, alle Rechte daran haben, die auch in Verbindung mit dem ursprünglichen Software-Paket gewährt wurden.

9) Die Lizenz darf die Weitergabe zusammen mit anderer Software nicht einschränken: Die Lizenz darf keine Einschränkungen enthalten bezüglich anderer Software, die zusammen mit der lizensierten Software weitergegeben wird. So darf die Lizenz z.B. nicht verlangen, dass alle anderen Programme, die auf dem gleichem Medium weitergegeben werden, auch quelloffen sein müssen.

10) Die Lizenz muss technologieneutral sein: Die Lizenz darf keine individuelle Technologie, Software-Art oder Schnittstelle voraussetzen.“^[16]

Die originalen Anforderungen an eine Open-Source Lizenz lassen sich auf der Internetseite der OSI nachlesen http://www.opensource.org/docs/osd.

5.4 GPL

Im Folgenden soll nun kurz auf die GNU General Public Licence (GPL) eingegangen werden, die den hier betrachteten Softwarealternativen zugrunde liegt. GPL ist die wohl bekannteste Lizenz für Open-Source Software. Sie wurde im Jahr 1989 in der Version 1.0 veröffentlicht und 1991 erschien die Version 2.0, die bis heute noch in unveränderter Form in Kraft ist. Die GPL ist im Wesentlichen durch den Gründer des GNU-Projektes, Richard Stallman erstellt worden. Zahlreiche erfolgreiche Open-Source Programme, sowie weite Teile des Linux-Kernels stehen unter der GPL Lizenz. Neben zahlreichen Rechten, die die Lizenznehmer durch die GPL erhalten, bringt die GPL auch Pflichten mit sich, von denen die Wichtigste das sogenannte „Copyleft“ darstellt. Das bedeutet, dass alle aus einer unter der GPL stehenden Software entstehenden Derivate der Software ebenfalls unter die GPL gestellt werden müssen. Die Free Software Foundation (FSF) ist eine Institution, die untrennbar mit der GPL verbunden ist. Neben umfangreichen Informationen, die sie zu dem Thema auf der Internetseite http://www.fsf.org bereitstellt, hat sie das alleinige Recht neue Versionen der GPL herauszugeben.^[17]

5.5 Nutzwertanalyse

Bei der Nutzwertanalyse handelt es sich um einen entscheidungstheoretischen Modellansatz, mit dessen Hilfe Auswahlprobleme gelöst werden. Die Nutzwertanalyse wurde in den USA unter der Bezeichnung „utility analysis“ entwickelt und durch Christof Zangemeister erstmals im deutschsprachigen Raum ausführlich beschrieben.^[18] Zangemeister beschreibt die Nutzwertanalyse hierbei wie folgt: „Die Nutzwertanalyse ist eine Planungsmethode zur systematischen Entscheidungsvorbereitung bei der Auswahl von Projektalternativen. Sie analysiert eine Menge komplexer Handlungsalternativen mit dem Zweck, die einzelnen Alternativen entsprechend den Präferenzen des Entscheidungsträgers bezüglich eines mehrdimensionalen Zielsystems zu ordnen.“^[19] Neben der Beurteilung objektiv erfasster Daten wie bei einer Kostenrechnung, Wirtschaftlichkeitsvergleichen oder einer Investitionsrechnung, soll die Nutzwertanalyse vor allem ebenfalls subjektive Werte beurteilen und mit in die Entscheidungsfindung einbeziehen. Die Nutzwertanalyse findet also ihre Anwendung dort, wo mehr als eine Alternative für eine Entscheidung zur Verfügung steht und nicht quantifizierbare Ziele mit in das Entscheidungsfindungssystem einbezogen werden sollen.^[20]

„Die Nutzwertanalyse besteht aus folgenden Verfahrensschritten:

1. Zielkriterienbestimmung,
2. Zielkriteriengewichtung,
3. Teilnutzenbestimmung,
4. Nutzwertermittlung,
5. Beurteilung der Vorteilhaftigkeit.“^[21]

Im ersten Schritt der Nutzwertanalyse werden die relevanten Zielkriterien in einem Katalog zusammengefasst und hierarchisch gegliedert. Die Zielkriterien sind hierbei Ziele, Anforderungen, Funktionen oder Eigenschaften, die an eine Alternative gestellt werden. Die Ziele auf der letzten Gliederungsebene, die Elementarziele, können durch eine schrittweise Abstraktion mit einem gemeinsamen Begriff zusammengefasst werden. Die oberen Begriffe benennen hierbei das Gesamtziel. Dann folgen Gruppenziele und schließlich die Elementarziele, die nach messbaren Kriterien beurteilt und quantitativ bewertet werden.^[22] Für Zielkriterien gilt darüber hinaus, dass Sie operational formuliert werden müssen. Für jedes Kriterium ist demnach eine Messskala erforderlich^[23], „auf der die Zielerreichung auf nominalem, ordinalem oder kardinalem Skalarniveau gemessen werden kann.“^[24] Neben der Messbarkeit der Ziele, ist beim Festlegen der Ziele darauf zu achten, dass einzelne Eigenschaften nicht mehrfach bewertet werden. Der Kraftstoffverbrauch eines Autos könnte beispielsweise sowohl durch die Eigenschaft „Betriebskosten“ dargestellt werden, als auch durch die Eigenschaft „Kraftstoffverbrauch“.^[25] Die letzte wesentliche Prämisse an die Ziele ist eine Nutzenunabhängigkeit. Das Erreichen eines Zielkriteriums, muss also immer möglich sein, ohne das ein anderes Ziel hierfür erreicht werden muss. Die Nutzenunabhängigkeit kann meist aber nicht vollkommen gewährleistet werden, so dass hier davon ausgegangen wird, dass eine bedingte Unabhängigkeit meist ausreichend ist. Liegen für bestimmte Ziele nur vollkommene Abhängigkeiten vor, sollten diese vollständig zusammengefasst werden.^[23]

Bei der Zielkriteriengewichtung geht es darum festzulegen, wie wichtig die einzelnen Kriteri-en für die Beurteilung der Alternativen sind. Hierzu wird jedes Kriterium mit einem Gewichtungsfaktor versehen, der angibt, wie wichtig das Kriterium im Verhältnis zu den anderen Faktoren ist. Hierbei sollte man eine breite Skalierung wählen, da eine zu geringe Skalierung dazu führen kann, dass die Ergebnisse infolge einer zu geringen Streuung nicht aussagekräftig sind.^[26] Zur Bestimmung der Kriteriengewichte können laut Götze verschiedene Skalierungsmethoden benutzt werden. Im Folgenden sollen kurz die direkte und die indirekte Intervallskalierung beschrieben werden. Bei der direkten Intervallskalierung wird jedem Zielkriterium ein Wert aus einer Intervallskala zugeordnet, so dass die einzelnen Werte die Präferenzunterschiede des Entscheidungsträgers widerspiegeln. Bei der indirekten Intervallskalierung werden den einzelnen Zielen nicht direkt Werte zugeordnet, sondern zunächst eine Rangfolge der Ziele gebildet. Anschließend werden den Kriterien Rangziffern zugeordnet. Angefangen mit der 1 für das unwichtigste Kriterium, bis hin zu einem K für das wichtigste Kriterium bei einer Anzahl von K Kriterien. Abschließend werden die Rangziffern in Gewichte gemäß der Intervallskala transformiert. Götze sieht es als sinnvoll an, dass die Teilgewichte in beiden Methoden so normiert werden sollten, dass deren Summe 1 oder 100 ergibt. Die Gewichtung muss für alle Ebenen der Zielhierarchie erfolgen, die im ersten Schritt für das Zielsystem festgelegt wurden.

Die im dritten Schritt der NWA durchzuführende Teilnutzenbestimmung wird jeweils für die unterste Ebene jeder Alternative und jedes Kriteriums durchgeführt und besteht aus zwei Schritten. Im ersten Schritt wird beurteilt, wie stark die einzelnen Kriterien pro Alternative ausgeprägt sind.^[27] Zur Beurteilung bieten sich folgende drei Möglichkeiten an: 1) Nominalskalen, also eine Aussage darüber, ob etwas zutrifft oder nicht. 2) Ordinalskalen, wie die Benotung in der Schule. 3) Kardinalskalen, bei denen die Bewertung auf einer Punkteskala von beispielsweise 1-10 stattfindet. Sind die einzelnen Kriterien beurteilt, erfolgt der zweite Schritt der Teilnutzenbestimmung, bei der die Messergebnisse in konkrete Teilnutzen transformiert werden.^[28] Gemäß Götze können hierfür drei verschiedene Verfahren genutzt werden, die im Folgenden kurz beschrieben werden: Mit Hilfe von diskreten Transformationsfunktionen können ordinale Werte direkt in einen bestimmten Teilnutzenwert überführt werden.^[29] Die folgende Abbildung stellt dies tabellarisch dar:

Die schrittweise-konstanten Transformationsfunktionen dienen dazu, kardinale Werte in spezifische Teilnutzenwerte zu überführen.^[31] Hierbei werden dann festgelegten Intervallen konstante Teilnutzenwerte zugeordnet, wie in folgender Darstellung tabellarisch gezeigt:^[32]

Stetige Transformationsfunktionen sind analog zu den stückweise-konstanten, allerdings mit dem Unterschied, daß auch kleine Unterschiede in den Bewertungen, zu Unterschieden in den Teilnutzenwerten führen.^[34]

Im vierten Schritt der Nutzwertermittlung werden die zuvor gewonnenen konstanten Werte zu einem Gesamtnutzen für jede der in Frage kommenden Alternativen verdichtet. Die folgende Abbildung zeigt dies anhand eines Beispiels, bei dem mit drei Kriterien über die Wahl eines Standortes entschieden werden soll:

Nach dem Erstellen des Zielsystems werden dann die Teilnutzenwerte der einzelnen Standorte ermittelt:

Um abschließend die Gesamtnutzen der einzelnen Alternativen zu bestimmen, wird der ermittelte Zielerreichungsgrad jeder Alternative mit dem Gewichtungsfaktor des entsprechenden Kriteriums multipliziert und dann die Summe jeder Standortalternative ermittelt. Die einzelnen Alternativen werden danach mit Rängen gemäß dem Zielsystem versehen, wie die folgende Abbildung zeigt:^[37]

Nachdem die Alternativen bewertet wurden, kann nun in der Beurteilung der Vorteilhaftigkeit über die beste Alternative gemäß dem erstellten Zielsystem entschieden werden. Gemäß Götze lassen sich hierzu folgende Vorteilhaftigkeitsregeln festhalten:^[39] „Ein Investitionsobjekt ist absolut vorteilhaft, wenn sein Nutzwert größer ist als ein vorzugebender Grenzwert. Relativ vorteilhaft ist ein Investitionsobjekt, wenn sein Nutzwert größer ist als der eines anderen zur Wahl stehenden Objektes.“^[40]

5.6 Joomla!

Joomla! ist ein Web-Content-Management-System das durch das Joomla! Core Team entwickelt wird. Bei dem Joomla! Core Team handelt es sich eine Gruppe von Software-Entwicklern, die sich im August 2005 von dem australischen Unternehmen Miro trennten. Hier arbeiteten sie an einer Software namens Mambo, die nach dem Bruch mit Miro als Joomla! weiterentwickelt und veröffentlicht wurde. Joomla! ist als Open-Source Software unter einer GPL v2 Lizenz kostenlos erhältlich. Joomla! wurde komplett in der Programmiersprache PHP programmiert und plattformunabhängig, da alle notwendigen Programme wie ein Apache Server oder eine MYSQL-Datenbank für Windows, Linux und andere Betriebssysteme, ebenfalls kostenlos zur Verfügung stehen.^[41] Die Version 1.0 von Joomla!, die erste offizielle Version der Software, erschien am 19.September 2005.^[42] Die aktuelle Softwareversion von Joomla! ist die Version 1.5.17, die seit dem 27. April 2010 unter anderem auf der deutschen Joomla! Homepage unter http://www.joomla.de erhältlich ist.

5.7 WordPress

WordPress ist ein Content Management System, das auf PHP und MySQL basiert und seit 2003 kostenlos im Internet erhältlich ist. Die Software wird vorwiegend als Blogging-Software verwendet, bietet aber auch Möglichkeiten zur Erstellung von statischen Seiten.^[43] Bei WordPress handelt es sich um eine Open-Source Software, die unter einer GPL-Lizenz vollständig frei verfügbar ist und beispielsweise auf der Internetseite http://www.wordpress.com heruntergeladen werden kann. WordPress ist der offizielle Nachfolger des Blogging-Systems „b2/cafelog“, auf dessen weiterentwickelten Quellcode die Software basiert.^[44] Die erste Version 0.70 von WordPress wurde am 27. Mai 2003 namenlos veröffentlicht. Alle darauf folgenden Versionen haben als Codename, den Namen eines bekannten Jazzmusikers, dem diese Version jeweils gewidmet ist.^[45] Die aktuelle Version 2.9 trägt den Codenamen „Carmen“ und ist in der Subversion 2.9.2 seit dem 15. Februar 2010 erhältlich.^[46]

6 Nutzwertanalyse

6.1 Problemdefinition

Ein kleines mittelständisches Unternehmen (KMU), die Acme Co., welches im deutschen Unterhaltungssektor tätig ist, plant einen neuen Internetauftritt aufgrund einer anstehenden internationalen Expansion. Der Auftritt muss aus der eigentlichen Webseite bestehen sowie aus einem Corporate-Blog, der aus dem Internet erreichbar sein soll.

Anforderung an die Webseite ist es, über unternehmenseigene Produkte zu informieren und so neue Kunden und Interessenten anzulocken. Außerdem soll über einen Corporate-Blog über die Tätigkeiten und Entwicklungen innerhalb des Unternehmens informiert werden. Die Nutzung und die Verwaltung der Webseite sollen einfach gestaltet werden können und zukünftig durch die Mitarbeiter verwaltet werden, weshalb die Software über eine entsprechende Rechtestruktur verfügen muss. Die Unternehmensphilosophie sieht vor, dass die Webseite darüber hinaus behindertengerecht gestaltet wird und ein Höchstmaß an Barrierefreiheit gewährleistet wird. Da das KMU gerade erst dabei ist, die ausländischen Märkte zu erschließen, ist es unbedingt erforderlich, die neue Internetpräsenz optimal in den Suchmaschinen zu positionieren. Aufgrund der anstehenden Internationalisierung des KMU ist davon auszugehen, dass zukünftig anderssprachige Mitarbeiter ebenfalls mit der Software arbeiten müssen. Dies impliziert die Unterstützung von Mehrsprachigkeit im Front- wie auch im Backend.

Da zukünftige Unternehmensentwicklungen derzeit nicht absehbar sind, ist bei der Auswahl der Software ebenfalls darauf zu achten, dass diese flexibel erweiterbar ist.

6.2 Zielsystem

6.2.1 Systemvoraussetzungen

Die Systemvoraussetzungen beschreiben die Anforderungen, die ein System haben muss, damit ein Content Management System auf ihm installiert werden kann.

6.2.2 Installation

Die Installation einer Software (in dem Falle eines Content Management Systeme auf einem Webserver) entscheidet sich sehr stark von der Installation, die man als Anwender von einem Windows Betriebssystem kennt. Bei der Installation eines CMS wird in der Regel zuerst die ZIP Datei mit den PHP und HTML -Dateien auf dem lokalen PC entpackt und anschließend mittels eines FTP Programms auf den Webserver übertragen und ggf. die notwendige Rechte gesetzt^[47]. Anschließend wird der Einrichtungsassistent aufgerufen, indem man in der Regel meistens die URL der Webpräsenz aufruft, über die das CMS später einmal zu erreichen ist.

6.2.3 Administrative Oberfläche

6.2.3.1 Benutzer- und Kontenverwaltung

Je nachdem wie umfangreich ein CMS ist, gibt es unterschiedlich viele Benutzer, die auf den Inhalt dessen zugreifen möchten. Ein CMS kann nur dann seine Stärke zeigen, wenn mehrere Benutzer Dokumente gemeinsam bearbeiten und gestalten können. Vor allem aufgrund des verschiedenen Kenntnisstandes sowie der unterschiedlichen Motivation ist eine Abgrenzung in verschiedene Gruppen wichtig. Diesen Gruppen können dann in der Rechteverwaltung auch entsprechende Berechtigungen gegeben werden. Weitergehend werden im Rahmen eines CMS Benutzer auch nach Front- und Backend differenziert.
Hinzu kommt, dass meistens auf einen Webmaster verzichtet werden soll, welcher die Inhalte zentral pflegt. Eine Zeitersparnis kann aber nur dann gewonnen werden, wenn die Lieferanten der Inhalte die Beiträge selbst erstellen und veröffentlichen können. Ebenso benötigen verschiedene Web-Seiten die Möglichkeit einen geschützten Bereich nutzen zu können, in dem nur registrierte Nutzer Zugang zu bestimmten Informationen erhalten.^[48]

• Berechtigung

Zur Definition des Begriffes Berechtigung ist zu erwähnen, dass es sich hierbei um eine Berechtigung (authorization), also eine explizite Zulassung handelt, welche sich auf einen Benutzer (personenbezogen) bezieht oder auf die Hardware. Dem Benutzer wird hiermit die Erlaubnis eingeräumt, bestimmte Funktionalitäten zu nutzen und auf bestimmte Datenbestände zugreifen zu können.^[49]

An Hand der Berechtigungskonzepte Authentifizierung und Autorisierung sollen die vorliegenden Systeme analysiert werden, allerdings unterscheiden sich Joomla! und WordPress bei der Gestaltung des Berechtigungskonzeptes kaum voneinander.

• Authentifizierung

Ist ein Benutzer auf einer Webseite registriert und loggt sich mit seinem Namen oder einem Nickname (Pseudonym) und seinem Passwort ein, so weiß das System, welcher Benutzer sich gerade angemeldet hat. Das System kann so Aktionen des jeweiligen Benutzers nachvollziehen und die Aktionen somit kontrollieren. Nach Hansen und Neumann versteht man "[u]nter der Authentifizierung (engl. authentification) [..] die nachweißliche Identifikation eines Benutzers oder eines Kommunikationspartners (beispielsweise eines softwarebasierten Dienstes)."^[50]

• Autorisierung

Da der Begriff Autorisierung häufig mit Authentifizierung verwechselt wird, soll auch dieser hier kurz erläutert werden. Autorisierung bedeutet, dass nach dem Schritt der Authentifizierung überprüft wird, ob der jeweilige Benutzer die entsprechenden Rechte besitzt, eine Seite zu betrachten oder zu verändern. Zur besseren Übersicht der Rechtestruktur und zur Definition der Zugriffsebenen, können die Benutzer einer Gruppe, wie z.B. Leser, Redakteur oder Administrator, zugeordnet werden.^[48]

6.2.3.2 Benutzergruppen und Rechteverwaltung

Mit dem Punkt Benutzergruppen und Rechteverwaltung soll untersucht werden, welche Berechtigungen die Benutzer erhalten. Dabei muss unterschieden werden, auf welche Bereiche (Front- und/oder Backend) und welche Ressourcen zugegriffen werden darf. Damit soll geklärt werden, in welchem Umfang die Benutzer auf Seiten und Beiträge Zugriff erhalten. Ebenfalls soll analysiert werden, ob die standardmäßig mitgelieferten Berechtigungsstrukturen der jeweiligen Systeme angepasst werden können oder ob diese fest vorgegeben sind.

6.2.3.3 Geschützter Bereich und Freigabeverfahren

Der geschützte Bereich auf einer Webseite soll gewährleisten, dass Inhalte, die nur für den registrierten Benutzerkreis gedacht sind, auch nur von diesem einzusehen ist. Daher sollen unter diesem Punkt die Möglichkeiten analysiert werden, wie Außenstehenden der Zugang zu diesen Inhalten verwehrt werden soll
Zusätzlich soll noch erläutert werden, inwiefern Inhalte durch eine definierte Instanz, wie z.B. die Gruppe der Administratoren, überblickt und dann später freigegeben werden kann.

6.2.4 Sicherheit

Sicherheit in einem CMS bedeutet nicht nur, dass Angriffe, welche über eine Firewall kommen, abgewehrt werden müssen. In diesem Kapitel soll gezeigt werden, welchen üblichen Angriffsmethoden Content Management Systeme ausgesetzt sind und wo die größten Sicherheitslücken bisher vorhanden waren.

6.2.4.1 Anfälligkeit für Sicherheitslücken

Immer wieder werden PHP-basierende Open-Source-Produkte angegriffen, insbesondere Content Management Systeme. Da die Installation eines CMS nicht besonders einfach ist und ebenso die Möglichkeiten eingeschränkt sind, ein Update auf eine neuere Version durchzuführen, werden diese häufig Ziel eines Angriffs. Da der Zugriff auf den Inhalt einer Seite über das CMS selbst gewährt wird, kommt erschwerend hinzu, dass wenn sich ein Fehler im System selber befindet, die Seite virtuell angreifbar wird. Häufig angewandte Angriffsmethode besteht in einem "Verschandeln" oder "Verunstalten" der Seite (sog. Defacement).

Die OWASP (Open Web Application Security Project) als gemeinnützige Organisation betrachtet beispielsweise technologie- und sprachunabhängig die Sicherheit von Applikationen. Relativ regelmäßig werden Top-Ten-Listen veröffentlicht, mit den häufigsten Sicherheitslücken. Die aktuelle Liste von April 2010 ^[51] zeigt, dass Injection, also das Einschleusen von fremdem Code in externe Systeme oder in das Betriebssystem, noch vor dem Cross-Site-Scripting (XSS) liegt. Ebenso gehören zu den häufigsten Sicherheitslücken unsicherer direkter Objektzugriff sowie eine fehlerhafte Authentifizierung oder ein fehlerhaftes Session-Management.
Die OWASP hat zudem ein Dokument namens "OWASP Guide to Building Secure Web Applications and Web Services" verfasst, welches nicht nur die oben erwähnten Punkte beschreibt, sondern auch weitere Aspekte, wie z.B. Sicherheit bei Web Services.

• Injection

Injection und insbesondere SQL-Injection verbergen ein hohes Gefahrenpotenzial, da Nutzerdaten ungeprüft direkt in SQL-Kommandos übernommen werden. Die Schwere dieser Angriffsform hängt vom Datenbanktyp und der Anwendung ab.
Besonders wenn SQL-Anweisungen (query) in der URL abgebildet werden, können diese leicht in Anweisungen umgewandelt werden, die z.B. die Tabelleninhalte unwiderruflich löschen. Eine MySQL-Erweiterung von PHP würde diesem Angriff entgegenwirken, da nur eine Anweisung pro Aufruf der entsprechenden Funktion erlaubt ist. Jedoch kann mit dem SQL-Kommando UNION eine weitere Anfrage an die erste SELECT-Anweisung angehängt werden. Dies ist im ersten Moment nicht schädlich, da es sich hierbei um eine Auswahlanweisung handelt, allerdings können so auch Daten, wie z.B. Passwörter, aus der Datenbank abgefragt werden.
Vermeiden lassen sich diese potenziellen Gefahrenquellen, indem man die SQL-Anweisungen nicht direkt ausgibt, sondern mit sog. Stored Procedures, also gespeicherten Datenbankabfragen mit Platzhaltern, arbeitet. Ebenso ist das Bearbeiten der Anweisung durch Maskieren des Apostrophs (dieses beendet den SQL-String) eine mögliche Lösung.^[52]

• Cross-Site-Scripting (XSS)

Beim Cross-Site-Scripting wird, allgemein gesagt, von einer anderen Site, also einer Cross-Site, Script-Code eingefügt. Dies geschieht dadurch, dass es einem Angreifer gelingt, schädlichen JavaScript-Code in eine Seite einzufügen. Da es sich um eine clientseitige Technologie handelt, wird dieser Code auf dem Client ausgeführt.
Grund für diese Lücke ist, dass Daten, die vom Benutzer kommen, ungeprüft publiziert werden. Zudem kann eine einfache Manipulation einer URL zu einem Einfügen von weiteren Elementen oder Formatierungen führen, wie z.B.

- Grafiken (kann zum "Verschandeln" der Seite genutzt werden)
- CSS-Formatierungen (mit einer solchen Formatierung kann u.U. die ganze Seite unsichtbar gemacht werden)
- Links (erhöhen möglicherweise Platzierungen in den Suchmaschinen)

Des Weiteren ist es möglich bei Vorhandensein einer XSS-Lücke JavaScript-Code einzuschleusen, mit dem Daten des Benutzers ausgespäht werden könnten. Dies kann z.B. durch den erlaubten Zugriff auf Cookies im Browser geschehen.
Diese Lücke bringt ein großes Gefahrenpotenzial mit sich, da PHP Cookies verwendet werden, um sein Session-Management zu betreiben. Angenommen die Cookies werden ausgelesen, kann der Angreifer mit geringem technischen Aufwand selber Cookies mit diesen Werten erstellen und sich damit am System anmelden. Damit kann das System den Angreifer und das Opfer später nicht auseinander halten. Insbesondere Benutzer mit Administratorenrechten können hiervon einen großen Schaden davon tragen.
Umgehen kann man diese Gefahren nur mit anderen Technologien, wie z.B. der integrierten Funktionalität von PHP HTML-Sonderzeichen wie < und > in entsprechende Entitäten < und > umzuwandeln. PHP bietet dies außerdem auch als Funktion htmlentities() an.^[53]

6.2.4.2 Verfügbarkeit von Bugfixes

Bugfixes dienen der Ausbesserung von aufgetretenen Sicherheitslücken oder zur Behebung von Fehlern im Programmcode (Schreibfehler an sich, Performance Probleme, ...), welche u.U. auch weitere Sicherheitslücken öffnen können.

6.2.5 Recoveryfunktion

6.2.5.1 Datensicherung

Die Datensicherung, oder auch Backup genannt, stellt eine essentielle Aufgabe des Administrators dar. Damit bei einem Ausfall des Systems und möglichen Beschädigungen von Dateien gewährleistet werden kann, dass es zu keinem langfristigen Datenverlust kommt. Im Wesentlichen geht es dabei darum, dass die Daten nach einem bestimmten Zeitrahmen auf ein weiteres Speichermedium kopiert werden können, damit im Falle eines Ausfalls auf diese Daten zurückgegriffen werden kann.
Zu analysieren ist hierbei, ob das jeweilige System die Möglichkeit bietet, die für das CMS wichtigen Dateien und Datenbanken einfach zu sichern oder u.U. auch eine inkrementelle oder differentielle Sicherung vornehmen zu können.

• inkrementelles Backup

Als zeitlicher Bezugspunkt für das inkrementelle Backup wird die letzte komplette Sicherung oder das letzte inkrementelle Backup verwendet. Dadurch soll im Gegensatz zum Vollbackup der Speicherplatz für die Datensicherung sowie die verwendete Zeit reduziert werden^[54]

• differentielles Backup

Für das Erstellen eines differentiellen Backups muss zunächst ein Vollbackup erstellt werden. Nur die Änderungen, die seit dem letzten Vollbackup angefallen sind, sind im differentiellen Backup enthalten. Auch hier ist die Reduzierung des Speicherplatztes von Vorteil, aber zusätzlich eine verkürzte Rückspielzeit im Gegensatz zum inkrementellen Backup, da nur das Vollbackup sowie das letzte differentielle Backup eingespielt werden muss. Dies bedeutet aber ebenfalls auch einen Nachteil, da Änderungen über mehrere Backups unverändert mit gesichert werden müssen.^[55]

6.2.5.2 Administrator-Passwort vergessen

Auch einem Administrator kann es passieren, dass ihm das Passwort nicht mehr einfällt. Für diesen Fall benötigt ein CMS eine Möglichkeit dieses Passwort entweder anzuzeigen oder es zurücksetzen zu können. Dabei soll auf mögliche sicherheitskritische Einstellungen eingegangen werden, die es einem Angreifer ermöglichen könnte, ebenfalls an das Administrator-Passwort zu gelangen.

6.2.6 Systemüberwachung und Monitoring

6.2.6.1 Fehlerprotokollierung

Unter dem Thema Fehlerprotokollierung sollen in der weiteren Betrachtung Möglichkeiten und Funktionalitäten analysiert werden, die zu einer erhöhten Stabilität der Webseite führen sollen. Hierzu gehören eine Überwachung der Datenbank- sowie PHP-Aktivitäten.

6.2.6.2 Logging

Da eine aktive Überwachung der möglicherweise auftretenden Fehlerzustände sehr aufwändig sein kann, soll geprüft werden, ob die Systeme über eine Versandfunktionalität von Systemnachrichten verfügen.

6.2.7 Templates

Die Darstellung der Ansicht der Webseite eines CMS wird fast ausschließlich über sogenannte Templates (in WordPress auch Themes genannt) zu Verfügung gestellt^{[56], [57]}. Sie definieren die Bereiche der Webseite, in denen später Text oder Grafiken angezeigt werden sollen.

Die Templates bestehen in der Regel aus mehreren Komponenten, die je nach Umfang des Templates variieren können. Sie umfassen mindestens eine Hauptseite, die in PHP und/oder HTML geschrieben ist, notwendige Grafiken und eine oder mehrere CSS Dateien. Sollen spezielle optische Effekte mithilfe von JavaScript realisiert werden (z.B. über die MooTools ^[58]), werden dem Template häufig noch JavaScript Dateien hinzugefügt.

6.2.8 Blogging

Bei einem Blog geht es primär darum Inhalte bereitzustellen die kategorisch oder chronologisch aufeinander folgen (1). Dafür muss die jeweilige Software das Einstellen und Durchblättern der Beiträge unterstützten. Die so erzeugten Inhalte werden anschließend vom Webblogsystem via HTML (2) dem Leser bereitgestellt, der wiederum jeden einzelnen Eintrag aufrufen, lesen (8) und wenn gewünscht zum vorherigen Eintrag zurückgehen kann. Die so erzeugten Inhalte werden ebenfalls von Suchmaschinen indexiert (4) und können vom Internetsurfer auch darüber gefunden werden (5). Wichtig ist beim Blog des weiteren eine RSS Funktionalität um die Internetsurfer über neue Inhalte zu informieren. Bei einem sogenannten RSS Feed wird der eigentliche Inhalt aus dem Webblogsystem als XML Datei bereitgestellt (3) und kann vom Internetsurfer (6) mittels eines RSS-Readers (7) gelesen werden. Der Vorteil beim RSS Feed ist, das der Internetsurfer die Seite nicht aktiv aufrufen muss. Der RSS Reader kümmert sich darum alle neuen noch nicht gelesenen Webseiten für ihn abzurufen und gesammelt darzustellen (z.B. auf dem PC oder Mobiltelefon).

6.2.9 Search Engine Optimization (SEO)

Eine Suchmaschine wie Google, Yahoo! oder Ähnliche stellt eine Art Intelligentes Schlagwortverzeichnis dar. Um dieses Verzeichnis aufzubauen gibt es sogenannte Crawler (vereinzelt auch Roboter oder auch Spider genannt) die sich von Link zu Link und damit von Seite zu Seite bewegen, sie analysieren und die jeweiligen besuchten Webseiten in das Verzeichnis aufnehmen.^[59] Um nun einen guten Platz (ein gutes Ranking) in der Trefferliste einer Suchmaschine zu erhalten bedienen sich viele Betreiber von Webseiten einer sogenannten Suchmaschinen Optimierung oder in Englisch Search Engine Optimization (SEO). Diese Methode beschäftigt sich mit den Merkmalen (neben den reinen qualitativen Inhalten) von denen bekannt ist, das die Crawler und damit die Suchmaschinen sie besonders beachten.^[60]

6.2.10 Barrierefreiheit

Unter Barrierefreiheit versteht man Webseiten „die von allen Besuchern ungeachtet technischer und/oder körperlicher Hürden oder Einschränkungen benutzt werden können.“^[61]

Solche Hürden sind beispielsweise^[62]:

• Kontrastarme Seiten: für Menschen mit Farbfehlsichtigkeit
• Kleine Texte: für Menschen mit Sehschwäche, beispielweise ältere Mitbürger
• Bilder: für Blinde, die sich Ihre Homepage von einem Screenreader vorlesen lassen
• Ignorieren technischer Standards: Das beschränkt die Besucher auf bestimmte Browser
• Aktive Inalte für Funktionalität: Sie schließen Menschen aus, die die entsprechenden Plugins nicht haben oder nicht haben wollen.
• Komplexe Sprache: Dadurch wird die Lesbarkeit erschwert, nicht nur für Menschen mit einem unterdurchschnittlichen IQ.

Um nun allen Menschen den Zugang zu Informationen zu ermöglichen und solche Hürden zu entfernen gibt es seit Juli 2002 die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (kurz BITV). Diese Verordnung besagt, dass alle externen Webauftritte von Behörden, der Regierung und der Ministerien bis zum Ende des Jahres 2005 barrierefrei sein müssen.^[63] Die BITV basiert auf den Grundlagen der vom W3C (das Konsortium des WWW) verabschiedete Richtlinie Web Content Accessibility Guidelines 1.0 (WCAG1).^[64] „Aber auch in der Privatwirtschaft finden sich Firmen, die sich mittels einer Zielvereinbarung dazu bereit erklären, die Anforderungen der BITV zu erfüllen.“^[65]
Die wichtigsten Voraussetzungen um solche Hürden möglichst gering zu halten ist die Verwendung von validem XHTML und die Gestaltung des Layouts konsequent mit CSS anstelle Tabellen oder unsichtbaren Bildern zur Positionierung von Elementen. ^[66] Damit kann z.B. sichergestellt werden, dass ein Screen Reader, der die Webseite von „links nach rechts und von oben nach unten“^[67] liest und den ein blinder Webseiten Besucher verwendet, keine Probleme mit der Verarbeitung hat.

6.2.11 Erweiterbarkeit

Wenn das jeweilige Content-Management System eingerichtet ist und stabil auf dem Webserver läuft, dann entsteht schnell der Wunsch die eigene Seite zu erweitern und mit dem Besucher intensiver in Kontakt zu treten. Sowohl Joomla! als auch WordPress bringen von Haus aus zahlreiche Erweiterungen mit. Es besteht aber auch die Möglichkeit, viele weitere Module, Plugins kostenfrei aber auch teils kostenpflichtig aus dem Internet herunterzuladen, oder Erweiterungen selbst zu programmieren. Unter dem Begriff Erweiterungen sind einzelne PHP Anwendungen zu verstehen, welche die Funktionen von CMS erweitern. Auf diese Weise kann das CMS um ein Bewertungssystem, Internetshop, Forum oder Gästebuch erweitert werden. Beide Systeme bieten da eine große Vielfalt und geben dem Betreiber die Möglichkeit das CMS individuell und problemlos zu gestalten.^[68]

Die Erweiterungen werden in fünf Gruppen eingeteilt:^[69]

• Komponenten:^[70]

  • bestehen aus einer Gruppe von PHP-Skripten und stellen dem System Erweiterungen zur Verfügung. Wenn die Komponenten aktiviert sind, dann können einige von diesen Erweiterungen von dem Anwender gesehen werden, wie z. B. Online-Shop, Newsletter oder Forensysteme. Andere jedoch stellen eine funktionale Erweiterung dar, die der Anwender nicht direkt sieht, dabei handelt es sich z. B. Suchmaschinenoptimierung oder Benutzerrechte Verwaltung.

• Module:^[70]

  • zeigen die meisten Daten im Frontend-Bereich an. Module sind ein zusätzlicher Bereich zum Inhaltsbereich. Meistens werden Module eingesetzt, um eine Komponente an einer anderen Stelle als im Inhaltsbereich anzuzeigen. Ein Beispiel für ein Modul ist die Anzeige der User, die gerade online sind.

• Plugins:^{[69], [70]}

  • hierbei handelt es sich um kleine Erweiterungen, die Seiten übergreifende Funktionen zur Verfügung stellen. Plugins können z. B. genutzt werden, um Inhalte eines Moduls in einen Text zu laden oder bei der webseitweiten suche.

• Templates:^[71]

  • sind für das Layout und die Gestaltungsvorlagen verantwortlich. Templates werden selten als Erweiterungen bezeichnet, jedoch bei der Installation und Integration verhalten sie sich ähnlich wie Module. Beide Systeme stellen eine sehr große Anzahl von kostenlosen aber auch kostenpflichtigen Templates zur Verfügung. Es können auch eigene Templates entwickelt werden, die auf das eigene Bedürfnis angepasst sind und die Vorschriften von Corporate Identity und Corporate Design eines Unternehmens erfüllen.

• Sprachpakete:^[72]
  

  • gehören ebenfalls nicht zu den typischen Erweiterungen. Sprachpakete ersetzen Textkonstanten durch einen lokalisierten Text. Mehr zu diesem Thema finden Sie im Kapitel 6.4.12.2 Mehrsprachigkeit.

Das System sollte nicht mit unnötigen Erweiterungen überfüllt werden, da diese getestet, gewartet und aktualisiert werden und zudem zueinander kompatibel sein müssen.
Aus diesem Grund sind zahlreiche Erweiterungen nicht notwendig, z. B. ein Forum kann zunächst durch ein Kontaktformular abgebildet werden. Erst wenn eine größere Menge Besucher sich auf der Webseite registriert und tatsächlich Einträge schreibt, sollte das CMS auf ein vollfunktionsfähiges Forum erweitert werden. Alle Erweiterungen benötigen einen höheren Wartungsaufwand. So muss z. B. ein Forum betreut, von Werbung freigehalten und die Beiträge auf verbotene Inhalte kontrolliert werden. Je umfangreicher die Erweiterungen sind, desto höher wird der Wartungsaufwand und das Fehlerpotenzial sein.^[73]

Vor der Erweiterung müssen also folgende Punkte bedacht werden:

• Notwendigkeit der Erweiterung prüfen
• Entscheiden ob fertige Erweiterungen nutzen oder eigene Module erstellen
• Ist die Erweiterung zu den vorhandenen Modulen kompatibel?
• Testfälle erstellen
• Erweiterung im Testsystem einrichten
  • Testen
  • Dokumentieren
• Echtsystem sichern
• Erweiterung einbauen
• Auf Updates achten
• Regelmäßig warten und die Funktionalität kontrollieren

6.2.12 Erweiterungen verwalten / installieren / deinstallieren

Die meistern Contentmanagement Systeme werden irgendwann erweitert und es gibt nur wenige Systeme, die mit den Standard Funktionalitäten auskommen. Aus diesem Grund ist die optimale Verwaltung / Installation und Deinstallation von Erweiterungen sehr wichtig. An dieser Stelle kann sichergestellt werden welche Erweiterungen im System aktiviert, deaktiviert sind und vor allem ob Erweiterungen richtig und vollständig installiert und deinstalliert werden.

6.2.13 Mehrsprachigkeit

Der Erfolg einer Internetpräsenz bzw. dessen Attraktivität für die Bentzer beruht vielfach darauf, dass die Webseite mehrsprachig gestaltet wurde. Auch im deutschsprachigen Raum können die Betreiber nicht davon ausgehen, dass der Besucher die Landessprache beherrscht.
Wenn Mehrsprachigkeit als Ziel eines Internettauftritts gesetzt wird, so stehen die meisten vor einem großen Problem. Es gibt viele aufwändige Möglichkeiten die Sprache eines CMS zu verstellen, allen voran die manuelle Anpassung der Webseite durch den Betreiber. Dazu werden jedoch Kenntnisse in HTML, Java und PHP benötigt, um die Anpassungen korrekt vornehmen zu können. Wahlweise kann der Betreiber auf dem verwendeten Webserver für jede Sprache ein eigenständiges CMS installieren, allerdings hat dieses Verfahren mehr Nachteile als Vorteile und ist sehr verwaltungsintensiv.
Im vorliegenden Kapitel soll untersucht werden, ob die beiden betrachteten CMS multilanguage-fähig sind.

6.2.14 Hilfe

Die Hilfeseite ist für die meisten Benutzer einer Webseite bzw. eines Blogs die erste Anlaufstelle, wenn Fragen oder Probleme auftreten. Hierbei soll untersucht werden, wie umfangreich die Hilfe-Seiten standardmäßig angelegt werden sind, ob diese außerdem noch erweiterbar sind und ob verschiedene Sprachversionen eingepflegt werden können.

6.3 Gewichtung des Zielsystems

Um die beiden Softwarealternativen Joomla! und WordPress objektiv miteinander vergleichen zu können wurde die Nutzwertanalyse von uns als vergleichende Methode herangezogen. Die Vorgehensweise der NWA wurde bereits im Kapitel 5.4 ausführlich beschrieben. Dennoch soll an dieser Stelle noch einmal kurz die Vorgehensweise für die Gliederung unseres Zielsystems erläutert werden.

Insgesamt haben wir vierzehn übergeordnete Ziele anhand der Aufgabenstellung aus Kapital 6.1 ermittelt und in unser Zielsystem mit aufgenommen. Jedes Kriterium hat hierbei eine an der Aufgabenstellung angelehnte Gewichtung bekommen, wobei die Summe der Gewichtungen für alle übergeordneten Ziele insgesamt 100 % beträgt. Mit Ausnahme der Punkte "Installation", "Systemvoraussetzungen", "Barrierefreiheit", "Mehrsprachigkeit" und "Hilfe" ist jedes übergeordnete Ziel, noch einmal in Unterziele aufgeteilt, die ihrerseits auch wieder eine Gewichtungssumme von 100% aufweisen. Die Gesamtsumme aller Oberziele entspricht dann dem gesamten Leistungsvergleich von Joomla! mit WordPress.

Um die Ziele möglichst exakt beurteilen zu können, haben wir uns für alle Beurteilungen des Leitungsvergleichs für eine Kardinalskala entschieden. Die Skala reicht hierbei jeweils von 1-10, wobei 10 das beste Ergebnis ist. In dieser Arbeit wird also folgende Bewertungsskala verwendet:

In der folgenden Tabelle ist die konkrete Zielkriteriengewichtung für die Nutzwertanalyse dargestellt.

6.4 Beschreibung der Alternativen

6.4.1 Systemvoraussetzungen

Sowohl WordPress wie auch Joomla! benötigen beide PHP in der Version 4.3.x und höher sowie einen MySQL Server. Da allerdings sowohl die MySQL Version 3.23 als auch die 4.1.2 nicht mehr supported wird ^[74] und beide CMS MySQL in der Version 5.x unterstützten wird dieser Unterschied nicht gewichtet. Des weiteren ist für die Acme Co. die Systemvoraussetzungen nicht von hoher Bedeutung, da es eine große Anzahl von Webhostern gibt, die genau diese Systemanforderungen erfüllen ^[75],[76].

6.4.2 Installation

Sowohl Joomla! wie auch WordPress kommen beide mit einem grafischen Einrichtungsassistenten daher, der startet (vorausgesetzt man hat die Inhalte der zuvor heruntergeladenen .zip Datei bereits auf den Webserver kopiert) wenn man die URL der eigentlichen Webpräsenz aufruft. Der Einrichtungsassistent führt den Anwender Schritt für Schritt durch die Installation und erfragt dabei z.B. den Namen der Webseite, Zugangsdaten für den mySQL Server usw. Ein großer Vorteil stellt hierbei der Joomla! Pre-Installion Check im Installer da (siehe Abbildung). Im Gegensatz zu WordPress kontrolliert der Pre-Installation Check ob alle notwendigen Subkomponenten vorhanden und alle Rechte auf die Verzeichnisse gesetzt wurden.

6.4.3 Administrative Oberfläche

6.4.3.1 Benutzer- und Kontenverwaltung

Die Benutzer- bzw. Kontenverwaltung kann in Joomla! über das Control Panel, dem Kontrollzentrum auf der Startseite, erreicht werden. Die sehr übersichtliche Verwaltung der Benutzer kennt nach der Installation nur einen Nutzer: den Super-Administrator. Dieser ist dadurch gekennzeichnet, dass er alles, was Joomla! hergibt auch nutzen kann. So kann er sich bspw. im Frontend einloggen, besitzt dort alle Funktionalitäten, kann aber vor allem Einstellungen im Backend vornehmen.^[79]
Zu den Fähigkeiten des Super-Administrators gehören das Erstellen neuer Nutzer sowie das Editieren, Filtern, Ausloggen oder Deaktivieren bestehender Nutzer auf einen Blick im sog. „User Manager“. Hingegen bietet WordPress in der betrachteten Version lediglich die Möglichkeit neue Benutzer anzulegen, diese zu editieren oder eine andere Rolle, d.h. andere Zugriffsrechte, zu gewähren.

Vorteilhaft ist bei Joomla! der ständige Überblick für den Administrator über die Anzahl aller im Front- und Backend angemeldeten User. Diese Anzeige befindet sich in der Menüleiste des Backends unter „Logged in Users“. Diese zeigt bei Joomla! nicht nur die Anzahl der angemeldeten User, sondern auch die Zugriffsebene sowie die letzte Aktivität an. In der Grundinstallation bietet WordPress diese Funktionalität hingegen nicht. Ebenso fehlt die genauere Anzeige der User im sog. Dashboard, dem „Armaturenbrett“ von WordPress.

6.4.3.2 Benutzergruppen und Rechteverwaltung

Beide Systeme verfolgen die Idee, dass entsprechende Berechtigungen über Nutzergruppen organisiert werden, denen die User zugeordnet werden. Daher resultiert eine Handvoll von Gruppen, denen verschiedenste Möglichkeiten im Front- wie auch im Backend zur Verfügung stehen. Die Rechte der Gruppen werden aufbauend aufeinander zugeordnet, so dass z.B. ein „Author“ mindestens die Rechte der Gruppe „Registered“ besitzt und darauf aufbaut.

Laut den Erfahrungen der Community-Mitglieder sind Administratorrechte bei Joomla! schon zu mächtig, wenn nur Artikel gepostet werden sollen. Mit diesen höheren Rechten kann bereits zu viel unwissentlich oder sogar absichtlich zerstört werden. Hingegen besitzt ein Benutzer der Gruppe „Editor“ bei Joomla! zu wenige Rechte, da Inhalte wohl live geändert, diese aber nicht direkt live geschaltet werden können.

Eine genaue Gegenüberstellung ist schwer möglich, da WordPress mit weniger differenzierten Nutzergruppen arbeitet. Joomla! hingegen geht in die andere Richtung und will mit der nächsten Version dem Administrator eine Möglichkeit an die Hand geben die Nutzergruppen und deren Berechtigungen noch weiter zu spezifizieren und die Möglichkeit selbst erstellter Nutzergruppen bieten.^[80]

6.4.3.3 Geschützter Bereich und Freigabeverfahren

Die Rechte, auf einen geschützten Bereich zugreifen zu können, basieren auf der Zugriffsebene für Menüeinträge und Inhaltselemente. Falls nun die Zugriffsebene „registered“ lautet, so ist ein Element nur für angemeldete Benutzer verfügbar. Eine weitere Zugriffsebene ist „special“, welche der Nutzergruppe „Registered“ keinen Zugriff gewährt, aber den übrigen Nutzergruppen, die somit weitreichendere Berechtigungen besitzen. Nachteilig bei Joomla! ist es, dass selbst wenn Elemente im Menü gesperrt sind, ein Direktzugriff via URL möglich ist, die sich erfahrene Benutzer aus bekannten URLs herleiten können. Dies kann mit ein wenig Mühe verhindert werden, indem die Zugriffsebene für das Inhaltsverzeichnis in diesem Fall eingestellt wird.^[81]

Zunächst wird die Einrichtung eines geschützten Bereichs in Joomla! erklärt, die über den Module Manager vorgenommen wird. Über das Login-Formular können folgende Informationen zu dem Bereich angegeben werden:

• Pre-text und Post-text: Texte, die vor und nach dem Text erscheinen
• Login bzw. Logout Redirection Page: gibt an, wohin der User nach dem Login weitergeleitet wird
• Greeting: Text, der nach dem Login in dem geschützten Bereich erscheint
• Name/Username: gibt an, ob User mit Namen oder Username begrüßt wird

Des weiteren können Einstellungen in den "Global Configuration" vorgenommen werden, die bestimmen, wie sich der User registrieren muss. Dies umfasst verschiedene Möglichkeiten, wie z.B., dass sich der User selber registrieren kann. Dies erspart dem Administrator bzw. Super-Administrator einiges an Arbeit und Zeit, da er die User nicht mehr per Hand anlegen muss („allow user registration“). Einstellbar ist ebenfalls, welcher Gruppe neue User direkt zugeordnet werden. Sinnvoll ist der Standardwert „Registered“. Jede höhere Zugriffsebene würde ein zu hohes Sicherheitsrisiko darstellen („new user registration type“). Ergänzend zur Registrierung durch den User kommt das sog. „Double-Opt-In“-Verfahren. Dieses Verfahren regelt, dass der User seinen Account mit einer Aktivierungsmail bestätigen muss. Damit soll theoretisch ausgeschlossen werden, dass eine Registrierung mit einer ungültigen Mail-Adresse möglich ist („new user account activation“). Bei Nutzung einer temporären Mail-Adresse kann aber auch diese Hürde mit ein wenig Mühe umgangen werden. Voraussetzung für dieses Verfahren ist, dass der Mailversand, auf dem die Website gehostet wird, erlaubt ist. Als letzte Einstellung, die über die Global Configuration vorgenommen werden kann, kann festgelegt werden, ob der User im Front-End die Sprache, den Editor und die Hilfeseite selbst wählen kann („front-end user parameters“), oder ob dies über den User Manager vorher festgelegt wird. Zusätzlich zu der Einrichtung eines geschützten Bereichs gehört es, festzulegen, welche Links nur für registrierte User im Menü angezeigt werden. Diese Funktionalität ist über den Content Manager („show unauthorised links“) sowie den Menu Manager für Inhaltselemente und Menüs steuerbar („show unauthorised links“). Wird diese Option eingestellt, sieht ein nicht registrierter Nutzer Menüeinträge mit der Zugriffsebene „registered“ oder „special“. Eine Meldung, dass der Nutzer nicht berechtigt ist, erhält dieser erst, wenn er auf den Menüeintrag klickt. Letztlich müssen Inhaltselemente und Menüs per Zugriffsebene in den jeweiligen Listen oder im Editiermodus definiert werden, die nur für registrierte Nutzer sichtbar sind.

Joomla! bietet neben den drei verschiedenen Zugriffsebenen „public“, „registered“, „special“ die Möglichkeit Rechte hinzuzufügen. Bei einer manuellen Änderung muss die zugrunde liegende Datenbank (Tabelle jos_groups) angefasst und um die neue Gruppe ergänzt werden. Problematisch wird es jedoch, wenn ein Element diese Nutzergruppe besitzt, da es dann nicht mehr angezeigt wird. Weitere Eingriffe in die Core-Dateien von Joomla! sowie die Komponenten bzw. Module sind nötig, die aber wiederum eine eingeschränkte Updatefähigkeit des Systems nach sich ziehen. Wahlweise kann der Administrator aber auf fertige Erweiterungen, wie z.B. den Community Builder zurückgreifen.^[82]

6.4.3.4 Teilergebnis Administrative Oberfläche

6.4.4 Sicherheit

6.4.4.1 Anfälligkeit für Sicherheitslücken

Aufgrund der früheren Denkweise, dass Sicherheit weder im Design noch bei der eigentlichen Programmierung implementiert werden müsste, hat dazu geführt, dass Joomla! früher durch Schwachstellen im Code aufgefallen war. Dies ist aber kein Einzelfall gewesen, da auch WordPress diese Sicherheitslücken aufgewiesen hat.

6.4.4.2 Verfügbarkeit von Bugfixes

Joomla! wie auch WordPress hatten in jüngster Zeit keine großen Probleme mit Sicherheitslücken des Systems. Die Fehler, die bei der Programmierung von eigenen Modulen gemacht werden, sind wesentlich prägnanter. Daher ist es sehr sinnvoll, nach dem Bekanntwerden eines Fehlers nach Aktualisierungen Ausschau zu halten, welche diesen Fehler beheben. Hierfür eignet sich bei Joomla! vor allem das Abonnieren des Newsletters, ebenso wie Informationen des Unternehmens „Secunia“, welche sich auf das Auffinden von Fehlern spezialisiert hat. Der zweite wichtige Aspekt ist selbsterstellter PHP-Code, der von Benutzern, z.B. im Rahmen eines Moduls, eingebracht wird. Hierbei ist ebenfalls zu beachten, dass dieser fehlerfrei geschrieben ist und regelmäßigen Sicherheitskontrollen unterzogen wird.^[83]

Die Durchführung von Updates bedeutet auch für WordPress eine grundlegende Aufgabe des CMS-Betreibers, sowie Fehler bei der Programmierung von selbsterstellten Modulen zu vermeiden. Auch hier ist die Community stets bestrebt größere entstandene Sicherheitslücken zeitnah zu schließen. WordPress bietet zusätzlich die Möglichkeit, dass der Benutzer einen Hinweis im Backend erhält, sobalbd eine neuere Version verfügbar ist, als die installierte.^{[84], [85]}

6.4.4.3 Teilergebnis Sicherheit

6.4.5 Recoveryfunktion

6.4.5.1 Datensicherung

Weder bei Joomla! noch bei WordPress besteht die Möglichkeit ein Backup der eigenen Seite zu erstellen, ohne dass eine Erweiterung eingesetzt wird. Der Betreiber der Seite ist dafür zuständig die Inhalte der Seite regelmäßig zu sichern. Dabei wird für Joomla! geraten die Datenbank entweder zu kopieren oder einen sog. Dump mit phpMyAdmin zu erstellen. Der Kopiervorgang würde bedeuten, dass MySQL in dieser Zeit angehalten werden müsste, während die Sicherung im laufenden Betrieb mit Hilfe des sog. Dumps ebenfalls Probleme mit sich bringen kann. Der Dump enthält die Beschreibung der Routine, wie die Tabelle angelegt wird und mit welchen Daten sie gefüllt wird. Da diese Routine in Klarschrift festgehalten wird, kann es zu Problemen mit dem Zeichensatz kommen, ebenso zu Problemen aufgrund von inkorrekten Daten oder basierend auf unterschiedlichen phpMyAdmin-Versionen.^{[86], [87]} Bei Joomla! müssen nicht alle Verzeichnisse und Dateien gesichert werden, sondern es reicht, wenn bestimmte Ordner für Bilder und Templates sowie die Konfigurationsdatei configuration.php gesichert werden. Alle weiteren Inhalte sind in der Datenbank eingebettet. WordPress hingegen benötigt eine Liste von Verzeichnissen, welche sechs Punkte umfasst (WordPress Kerninstallation, WordPress Plugins, Themen, Bilder und Dateien, Javascripts, PHP-Skripte und andere Code-Dateien, weitere Dateien und statische Webseitenanteile).^[88]

6.4.5.2 Administrator-Passwort vergessen

Vergisst ein Benutzer bei Joomla! sein Passwort, so kann ihm ein Administrator mit wenigen Klicks ein neues Passwort vergeben. Beide Systeme bieten zusätzlich die Funktion, dass der Benutzer im Frontend selber angeben kann, dass er das Passwort vergessen hat und sich dieses per Mail zuschicken lassen kann. Das Zurücksetzen des Administrator-Passworts jedoch, falls dieses vergessen wurde, ist in beiden Systemen nur über die zugrundeliegende Datenbank möglich. Als Datenbankverwaltung für solche Zwecke kann phpMyAdmin verwendet werden, mit dem in der jeweiligen Tabelle das Passwort neugesetzt werden kann. Hierzu muss noch zusätzlich ein MD5-Hash (Message Digest Algorithm) generiert und eingetragen werden. WordPress bietet zudem noch die Möglichkeiten, das Passwort über FTP, über das Emergency Password Script oder über Mail via FTP zurückzusetzen.^[89] Das Emergency Password Script bringt allerdings den großen Nachteil mit sich, dass falls Zugriff auf den Inhalt der Seite besteht, dieses Skript im entsprechenden Verzeichnis abgelegt und mit der Ausführung großer Schaden anrichten werdeb kann.

Falls in einem Joomla!-System der Super-Administrator gelöscht wurde, kann dieser über einen Eingriff in die Datenbank wiederhergestellt werden. Hingegen besagen die „Best Practices“ für WordPress, dass das Löschen des Standard-Benutzers „Admin“ eine Vorkehrung gegen mögliche Angriffe darstellen kann.

6.4.5.3 Teilergebnis Recoveryfunktion

6.4.6 Systemüberwachung und Monitoring

6.4.6.1 Fehlerprotokollierung

Bei beiden Content Management Systemen ist es möglich, eine oder mehrere Protokolldateien erstellen zu lassen, in der Fehlerzustände (Errors) festgehalten werden. Joomla! bietet diese Funktionalität lediglich auf der darunterliegenden Schicht im Apache. Hier werden die PHP und MySQL-Aktivitäten von Apache mitgeloggt, so dass nur über diesen Weg beispielsweise die Zugriffsdaten nachvollziehbar sind. Hingegen gibt es bei WordPress über eine Anpassung der wp-config.php-Datei die Möglichkeit eine Datei zu bestimmen, in die Informationen des Apache geschrieben werden. Die wp-config.php-Datei dient generell dazu die WordPress Konfigurationseinstellungen vorzunehmen, welche für die Anbindung der MySQL-Datenbank benötigt werden. Diese Datei ist standardmäßig nicht im Download-Paket enthalten und muss per Hand erstellt werden.^[90]

6.4.6.2 Logging

Joomla! bietet die Möglichkeit, bestimmten Nutzern die Mails, die vom System ausgesendet werden, zuzuschicken. Dies geschieht über den User Manager im Backend. WordPress bietet diese Möglichkeit bisher nicht.

6.4.6.3 Teilergebnis Systemüberwachung

6.4.7 Templates

In Joomla! wird das Hauptdesign hauptsächlich mittels einer index.php geregelt, in der die unterschiedlichen Modulpositionen (wie z.B. das Navigationsmenü) über Platzhalter definiert werden.^[91] Eine große Besonderheit von Joomla! stellt das Überschreiben der Ausgaben von nachträglich installierten Komponenten und Modulen dar^[92]. Damit ist es möglich die Ausgabe der Komponenten und Module so anzupassen, das sie sich in die Darstellung der Webseite einfügen, ohne die Komponenten und Module selbst zu verändern. Somit lassen sich Komponenten und Module per Softwareupdate aktualisieren, ohne die Darstellung des CMS / der Webseite zu zerstören. Mit dieser Funktion ist es auch möglich, barierefreie Webseiten zu erstellen.
In WordPress wird das Hauptdesign ebenfalls über eine index.php geregelt wobei man die Möglichkeit hat, bestimmte Teilbereiche (z.B. die Kategorien, die Kommentare, Einzelansicht der Seiten, des Archives) des Webseite ebenfalls zu überschreiben.^[93]
Sowohl bei Joomla! als auch bei WordPress gibt es im Internet eine Vielzahl von Templates zur Verwendung. Einige davon sind kostenlos und andere müssen käuflich erworben werden. Der Preis der Templates richtet sich in der Regel nach dem Verwendungszweck. Templates, die man Geschäftlich verwenden will sind teurer als private. Will man ein Template exklusiv erwerben, kommen hier nochmal höhere Kosten auf einen hinzu.^[94] Darüber hinaus können von einer Vielzahl von eigenständigen Entwicklerfirmen individuelle Templates in Auftrag gegeben werden ^[95],[96] Hat man sich für ein Template entscheiden kann man dieses über das Backend im System installieren. Hier wird die ZIP Datei ausgewählt, via Button auf den Webserver hochgeladen und anschließend installiert. Technisches Wissen ist hierfür nicht erforderlich.
Hat man das technische Wissen selbst ein Template zu erstellen, gibt es sowohl für Joomla! als auch für WordPress Dreamweaver Plugins, die genutzt werden können um Templates mittels WYSIWYG-Editor zu entwickeln.
Im Lieferunfang von Joomla! gibt es zur Zeit drei Templates wobei ein Template (Beez) speziell auf die Barrierefreiheit abziehlt. WordPress hingegen bietet lediglich zwei Templates an.

Vergleicht man den Quelltext den ein mitgeliefertes Joomla! Template erzeugt mit denen von WordPress fällt auf das nur die Joomla! Templates eine Fehlerfrei Validierung (mittels http://validator.w3.org) bestehen. Die mit WordPress gelieferten Templates fallen durch den Validator durch. Da aber nur ein fehlerfreies Template problemlos von einem Screenreader verarbeitet werden kann, können zumindest die WordPress Templates nicht als barierefrei angesehen werden.
Beide Systeme bieten die Möglichkeit via Backend die unterschiedlichen Templates zu editieren, so dass das arbeitsaufwändige Austauschen der Template-Dateien mittels FTP Client entfällt. Joomla! kann hier zudem mit einem Vorschaumodus (Preview) aufwarten den man in WordPress vermisst.

6.4.8 Blogging

Die Trackback Funktion wird von Joomla! von Haus aus nicht unterstützt, kann aber über Komponenten von Fremdanbietern nachgerüstet werden. Für die Acme Co. ist diese Funktionalität allerdings nicht so wichtig, da aufgrund der Angebotenen Inhalte, wahrscheinlich keine Trackbacks Verwendung finden. Die für die Acme Co. wichtigste Funktion ist hier vielmehr die Möglichkeit bestimmte Elemente als RSS-Feed bereitzustellen. Diese Möglichkeit bieten Joomla! und WordPress in gleichem Maße. Ein weiterer Punkt sind die Kategorien für den Corporate Blog der Acme Co. sowie die Möglichkeit eine Historisierung bereitzustellen. Hier zeigt WordPress das es als Blog konzipiert wurde und bietet z.B. einen Kalender und eine Tagwolke zum direkten Zugriff auf die Einträge. Die Kalender und Tagwolken Funktionalitäten müssen bei Joomla! erst nachinstalliert werden.

6.4.9 Search Engine Optimization (SEO)

Die Search Engine Optimazation (SEO) beginnt in der Regel beim Template. Hier sollte darauf geachtet werden, dass der Quelltext, den die Systeme erzeugen, syntaktisch korrekt ist, so dass der Crawler keine Probleme hat, den Inhalt der Seite zu analysieren (siehe auch das Kapitel Templates).^[97]
Darüber hinaus ist es notwendig einen qualitativen Inhalt zu bieten und gewisse Schlüsselwörter, sog. Keywords, zielgenau für bestimmte Seiten vergeben zu können^[60], um den Crawlern die Arbeit zu erleichtern. Das gestaltet sich bei Joomla! ziemlich einfach, so das man beim Schreiben der unterschiedlichen Seiten für jede eigene Keywords vergeben kann. Bei WordPress gibt es so eine Möglichkeit nicht, sie kann aber über von der Comunity geschriebene Plugins nachgerüstet werden.
Ein wichtiger Punkt beim SEO sind suchmaschinenfreundliche URLs. Im Test zeigte sich das beide Systeme in der Lage sind solche suchmaschinenfreundliche URLs zu erzeugen. Wird die Funktion eingeschaltet verwandeln sich URLs wie z.B. www.mydomain.tld/?news.php=123 in eine suchmaschinenfreundlichere URL, wie z.B. www.mydomain.tld/news/123. Damit wird der Suchmaschine eine Verzeichnisstruktur vorgegaukelt, anhand dessen eine einfachere Indexierung durchgeführt werden kann.
Diese Veränderung der URLs benötigt allerdings das Apache mod_rewrite, was unter Umständen nicht bei jedem Webhoster installiert ist. Einzig Joomla! bietet eine Möglichkeit suchmaschinenfreundlichere URLs zu erzeugen, wenn der eigene Webserver kein solches Modul zu Verfügung stellt. Verwendet man gar einen Microsoft ISS Webserver, so muss man auf diese Funktion komplett verzichten. Laut Tobias Hauser und Christian Wenz gibt es das Modul IISRewrite für den Microsoft ISS welches aber nur unter Windows 2000 und NT 4 getestet wurde.^[98]
Zu beachten ist zudem das für die korrekte mod_rewrite funktion eine .htaccess im root des Webservers zu erstellen ist. Bei Joomla! muss diese nur umbenannt werden ^[99], wobei WordPress den Inhalt zum Kopieren und Einfügen in der Konfiguration anzeigt. Bei den Testinstallation im Rahmen dieses Vergleichs hat sich zudem gezeigt, dass einige günstige Hoster das Erstellen der .htaccess nicht zulassen.
Darüber hinaus gibt es für beide Systeme eine Vielzahl von SEO Plugins. So lässt sich z.B. mit einem Zusatzmodul für Joomla! vollautomatisch ein Siteindex anlegen, den die Suchmaschinen indexieren und dem sie folgen können. Das verhindert doppelte Inhalte und unter Umständen Abwertungen im Suchergebnis.

6.4.10 Barrierefreiheit

Da aber beide Systeme (WordPress und Joomla!) die darstellbaren Webseiten anzeigen und generieren wird nun auch auch ersichtlich, dass die Grundlage für eine barrierefreie Webseite in dem verwendeten System selbst liegt. Die Anwender haben praktisch keine Möglichkeit die dynamisch generierten Webseiten anzupassen. Hier ist die Programmierung der Systeme und deren Erweiterungen und Anpassung durch Templates gefragt.
Bei Joomla! wurde sich dem Problem schon sehr früh angenommen und seit der Version 1.5.0 ist es möglich komplett barrierefreie Webseiten zu gestalten. Joomla! liefert hier auch gleich ein Template mit dem Namen Beez mit, das barrierefrei ist und des Weiteren komplett auf Nutzerfreundlichkeit (Accesibility) ausgelegt ist. Bei WordPress ist es seit der Version 2.6 möglich, barrierefreie Webseiten zu gestalten.

6.4.11 Erweiterbarkeit

Wie bereits im Kapitel 6.2.11 Erweiterbarkeit beschrieben, bieten beide Systeme eine große Anzahl von Erweiterungen, mit denen Onlineshops, Foren, Bildergalerien in das System integriert werden können.
Über die genaue Anzahl der zur Verfügung stehenden Erweiterungen kann nur spekuliert werden, weil nicht jeder Entwickler oder nicht jedes Unternehmen die Erweiterungen auch veröffentlicht. Aber aufgrund der großen WordPress Community gehen wir davon aus, dass die reine Anzahl der Erweiterungen bei WordPress höher ist als bei Joomla!.
Die große Masse sagt nichts über die Klasse aus und vor allem nichts über die Komplexität und die Qualität. Allein wenn wir die größeren Erweiterungen von Joomla! betrachten, stellen wir fest, dass nur ein Teil dieser Erweiterungen in WordPress zur Verfügung steht und ein noch kleinerer Teil problemlos funktioniert. Ein gutes Beispiel dafür ist JoomFish und die vielen WordPress Lösungen zu denen in Communitys hauptsächlich Lösungsvorschläge zu Problemen gefunden werden.
Für beide Systeme, findet der Anwender kostenfreie und kostenpflichtige Lösungen und für beide Systeme gibt es Berater und Entwickler die kostenpflichtig individuelle Lösungen anbieten. Aus all diesen Gründen ergibt sich folgende Punkteverteilung:

6.4.12 Erweiterungen verwalten / installieren / deinstallieren

Mit der Installation einer Erweiterung bindet der Betreiber eines CMS’ Quellcode bzw. Mini-Programme in das System ein. Dies kann u.U. nicht wie geplant verlaufen. Außer den Problemen, die bereits im Kapitel Erweiterberkeit erwähnt worden sind, kann auch "bösartiger" Code eingeschleust werden, der dann z.B. Datenbankpasswörter ausspäht oder Dateien auf dem Server verändert. Aus diesem Grund ist an dieser Stelle Vorsicht geboten, und alle Erweiterungen sollten erst einmal gründlich in einem Testsystem geprüft werden.

In Joomla! lassen sich die meisten Komponenten ohne große Probleme und sehr bequem in das bestehende System integrieren. Um die Komponenten einzubinden, hat der Betreiber im Backend im Bereich „Install/Uninstall“ drei verschiedene Möglichkeiten zur Auswahl (siehe Abbildung 07):^[100]

• „Upload Package File“
• „Install from Directory“
• „Install from URL“

In den meisten Fällen sind die Erweiterungen in Form eines ZIP-Archives vorhanden. Um ein ZIP-Archiv zu installieren, kann der Administrator die Funktion „Upload Package File“ verwenden. Mit dieser Funktion wird das Archiv selbstständig auf den Webserver hochgeladen, entpackt und installiert. In diesem Fall ist die Installation einer Erweiterung unter Joomla! abgeschlossen.
Ein derartig problemloser Durchlauf der Installation kann jedoch nicht nicht bei allen Erweiterungen gewährleistet werden, da die meisten Erweiterungen aus unterschiedlichen Komponenten, Plugins und Modulen bestehen. Diese müssen in einer bestimmten Reihenfolge eingespielt werden. Hierbei sind vor allem die Installationshinweise des Herstellers zu beachten. Sollten keine Hinweise vorhanden sein, ist es ratsam, zunächst die Komponenten, dann die Module und anschließend die Plugins zu installieren.
Einige Entwickler packen alle Bestandteile ihrer Erweiterung in ein ZIP-Archiv, das allerdings nicht über die bereits erklärte Funktion „Upload Package File“ installiert werden kann. In diesem Fall muss der Administrator das Archiv auf einer lokalen Festplatte entpacken und anschließend die Funktion „Install from Directory“ (aus Verzeichnis installieren) verwenden. Wie in dem bereits erwähnten Installationsverfahren werden auch bei dieser Installationsmethode die Objekte auf den Server übertragen und automatisch installiert.
Die dritte Möglichkeit, die Joomla! zum Installieren von Erweiterungen anbietet, ist „Install from URL„. Wie der Name es schon sagt, werden die Erweiterungen in diesem Fall direkt von einem Server installiert.

So wie bei Joomla!, so gibt es auch für WordPress viele kostenlose Erweiterungen, die sich ohne große Probleme installieren lassen. Um die Erweiterungen zu installieren, stellt WordPress zwei automatische Funktionen zu Verfügung, mit denen die Installation durch einen Knopfdruck durchgeführt wird. Des Weiteren gibt es eine dritte Möglichkeit, um die Installationen durchzuführen, jedoch funktionieren diese nicht vollautomatisch. Ähnlich wie bei Joomla! muss der Administrator bei dieser Methode ein ZIP-Archiv auf den Webserver laden. Das Archiv mit der Erweiterung, muss im Ordner \htdocs\wordpress\wp-content manuell hinterlegt werden. Anschließend kann der Administrator das entsprechende Modul unter Plugins –> Verwalten aktivieren.^[101]
Die zweite Methode findet der Administrator unter Plugins->Installieren-Hochladen. An dieser Stelle kann der Administrator den Pfad des ZIP-Archives eingeben und den Knopf "Installieren" betätigen. Anschließend wird die Installation automatisch durchgeführt.
Mit der dritten Methode, die WordPress zur Verfügung stellt, hat der Administrator die Möglichkeit direkt aus dem Backend die Module von der WordPress-Seite herunterzuladen und zu installieren. Dabei kann der Administrator gezielt nach Plugins suchen, die Neuesten anzeigen lassen oder über die Schlagwörter die gewünschten Plugins suchen wie die folgende Abbildung zeigt.^[102]

Alle Module und Erweiterungen, die vom Administrator installiert werden können, müssen auch die Möglichkeit bieten, diese zu deaktivieren oder auch zu deinstallieren. Beide Systeme stellen dabei unterschiedliche Werkzeuge zur Verfügung, die im nachfolgenden Text näher beschrieben werden.

Die bereits erwähnten Erweiterungskategorien Plugins, Sprachpakete und die Templates können unter Joomla! wahlweise deaktiviert oder deinstalliert werden. In der Maske „Extensions -> Install/Uninstall“ kann der Administrator die gewünschte Erweiterungskategorie auswählen, aus der die Erweiterungen deinstalliert oder ausgeschaltet werden sollen. In jeder dieser Kategorien erhält der Administrator eine Übersicht mit derzeit installierten Erweiterungen. Die für das Content Management System wichtigen Funktionalitäten sind grau hinterlegt und können von dem Administrator weder gelöscht noch ausgeschaltet werden.
Um beispielweise eine Komponente zu deaktivieren, muss der Administrator nur den grünen Haken neben dem Modul herausnehmen. Ähnlich simpel gestaltet sich die Deinstallation unter Joomla!. Um ein Programm zu deinstallieren, muss das Feld links neben dem Namen angeklickt werden und anschließend der Knopf "Deinstallieren" betätigt werden.
Die Verwaltung der Module und Erweiterungen ist unter Joomla! sehr einfach und lässt sich schnell erlernen. Dabei kann der Anwender beinahe von Anfang an intuitiv das System verwalten (siehe Abbildung 09).

Mit WordPress lassen sich die Erweiterungen ähnlich wie Joomla! komplett intuitiv bedienen, verwalten, deaktivieren und entfernen. Aus diesem Grund wird in diesem Kapitel nur auf die wesentlichen Unterschiede zu Joomla! eingegangen.
Bevor der Administrator eine Erweiterung aus dem System löschen kann, muss er diese zunächst deaktivieren und kann diese dann anschließend löschen. Der Administrator hat aber auch die Möglichkeit sich direkt aus dem Backend heraus den Quellcode der Erweiterung anzeigen zu lassen. Diese Funktion ist vor allem für Entwickler interessant oder bei der Fehleranalyse sehr hilfreich.
Den entscheidenden Unterschied zu Joomla! bietet WordPress mit der Möglichkeit die Erweiterungen zu aktualisieren. Sobald ein Update für vorhandene Erweiterungen veröffentlicht wird, wird der Administrator darüber im Backend informiert. Somit besteht die Möglichkeit, sich entweder weitere Informationen anzeigen zu lassen oder die jeweilige Erweiterung zu aktualisieren. ^[103]

6.4.13 Mehrsprachigkeit

Joomla! bietet von Haus aus die Möglichkeit, mehre Sprachpakete zu installieren. Des Weiteren gibt es eine Komponente namens Joom!Fish, die die unterschiedlichen Sprachen unterstützt.
Einmal installiert, lassen sich mehrsprachige Seiten nahezu genauso zügig entwickeln, wie eine ganz "normale" Joomla!-gestützte Webseite. Das Hauptziel von Joom!Fish ist, die manuellen Übersetzungen für komplexere Webseiten zu unterstützen.
Über die installierten Sprachpakete werden die statischen Texte in Joomla! und in zahlreichen weiteren Modulen übersetzt. Dadurch wird dem Betreiber des CMS der größte Teil der Arbeit abgenommen. Trotzdem wird die Flexibilität bewahrt und es können eigene Übersetzungen vorgenommen werden. Der Anwender, der sich im Frontend der Seite befindet, kann durch das Klicken einer entsprechenden Landesflagge die Sprache auf der Seite umstellen. ^[104]

Die Installation und Integration von Joom!Fish funktioniert in drei Schritten: ^[104]

• Installation der Sprachdatei
• Installation von Joom!Fish2.0
• Installation der zusätzlichen Konfiguration für die Erweiterungen.

Zur abschließenden Betrachtung kann festgehalten werden, dass die Installation und Integration der Mehrsprachigkeit in Joomla! voll gegeben ist. Durch das Modul Joom!Fish braucht der Administrator keine Kopie der Datenbank zu erstellen oder auf andere komplexe Methoden umzusteigen. Das Modul lässt sich schnell in die vorhandene Infrastruktur einbinden, ist für komplexe Seiten geeignet und ermöglicht sogar Bloggs mehrsprachig darzustellen. Das schnelle und problemlose Einbinden in die Infrastruktur ermöglichen zahlreiche Dokumentationen und Videoeinleitungen.

WordPress bietet ebenfalls die Möglichkeit eine andere Sprache in das System einzubinden, indem Sprachdateien ins System geladen werden. Dieses Vorgehen ist unerwartet aufwändig und erfordert vom Administrator gute PHP-Kenntnisse, um Anpassungen im Script vorzunehmen.
Um die Blogs in einer anderen Sprache darzustellen z. B. Englisch, bietet die WordPress-Community viele unterschiedliche Plugins. Alle diese Plugins haben unterschiedliche Stärken und Schwächen, so dass der Betreiber des CMS bei Implementierungsproblemen auf die Hilfe der Community angewiesen ist.

Folgende Plugins werden in den Communitys empfohlen:

• Polyglot
• Gengo
• ML multilingual
• Language Switcher
• qTranslate

Der Betreiber einer Seite hat die Qual der Wahl, um sich für das richtige Plugin zu entscheiden. Das große Problem ist dabei, die mangelnde Dokumentation. Die Communitys gehen meistens auf unterschiedliche Fehler ein. Welches Plugin wann eingesetzt werden sollte, ist für den Anwender nicht immer klar erkennbar. Auf das gleiche Problem stößt der Anwender bei der Suche nach Dokumentationen. Aus diesem Grund können die einzelnen Plugins innerhalb dieser Seminararbeit nicht im Detail geprüft und ausgewertet werden. Es gibt jedoch einige mehrsprachige Seiten, die mit WordPress erstellt wurden. Das deutet darauf hin, dass die Plugins funktionieren. Der WordPress Administrator braucht ebenfalls nicht auf komplexe Methoden umzusteigen, um die Mehrsprachigkeit zu sichern. Des weiteren bietet das Modul qTranslate (siehe Abbildung 10), eine Mehrsprachigkeit von Bloggs. Hierbei muss der Anwender, den Blogg händisch in zwei Sprachen eingeben.

6.4.14 Hilfe

Welches Hilfsmenü ein Benutzer im Joomla!-System sieht kann direkt beim Anlegen des Nutzers eingestellt werden. Hier bietet Joomla! den Vorteil, dass mehrere verschiedensprachige Seiten ausgewählt werden können, die bereits erstellt wurden, oder es können weitere Hilfsmenüs von anderen Servern, sog. „local help server“, eingebettet werden. Zudem hat der Benutzer noch die Möglichkeit in seinem Benutzerprofil im Frontend das Hilfsmenü einzustellen. WordPress hingegen bietet nur die Möglichkeit der Dokumentation und der Support Foren.

6.5 Auswertung

Im Gesamtergebnis der Nutzwertanalyse zeigt sich, dass Joomla! einen klaren Vorsprung von 99,2% gegenüber WordPress mit 88,4% hat. Die Analyse hat gezeigt, dass die beiden Systeme in vielen Bereichen ähnlich sind, was sich auch im Ergebnis wiederspiegelt, da nur eine Differenz von 10,8 Prozentpunkten vorliegt.

Gerade im Blogging-Bereich hat WordPress sogar einen klaren Vorsprung gegenüber Joomla!. Als Grund hierfür ist anzuführen, dass WordPress von seinem Ursprung her eine reine Blog-Software ist und somit gewisse Grundfunktionalitäten wie z.B. Trackback mitbringt.

Da aber bei der Betrachtung des Praxisbeispiels Blogging nur einen kleinen Teil der Anforderungen ausmacht, hat er wenig Einfluss auf das Gesamtergebnis. Im Gesamten wird bspw. dem Bereich "Sonstiges", der sich aus den Unterpunkten Mehrsprachigkeit und Hilfe zusammensetzt, ein höherer Nutzwert beigemessen.

Damit ist Joomla! die Alternative, die der Acme Co. empfohlen werden sollte.

7 Fazit

Der Leistungsvergleich hat gezeigt, dass unter der gegebenen Zielsetzung Joomla!, die durch das Unternehmen zu wählende Softwarealternative darstellt. Allerdings handelt es sich hierbei, wie anfangs bereits erwähnt, um keinen vollständigen Vergleich und somit auch nicht um eine allgemeingültige Empfehlung.

Da die Anforderung darin besteht, die Internetpräsenz der Acme Co. möglichst flexibel für zukünftige Unternehmensentwicklungen zu gestalten, bietet Joomla! neben den genannten Nutzwertkriterien eine weitaus größere Erweiterbarkeit als WordPress. In Joomla!, als vollwertiges CMS, können Komponenten des E-Commerce, wie auch Shopsysteme, eingebunden werden, die dem Unternehmen neben der Internetpräsenz einen Mehrwert bieten. Trotz des Ergebnisses der Nutzwertanalyse, also der Vorteile von Joomla!, stellt WordPress im Bereich des Blogging die bessere Alternative dar.

Die Allgemeingültigkeit des ermittelten Ergebnisses sowie die Stabilität der bewerteten Kriterien müssten durch eine Sensitivitätsanalyse im Einzelfall betrachtet werden, um einen individuellen Nutzen hieraus ziehen zu können. Eine Verschiebung der Gewichtung könnte bewirken, dass die Alternative WordPress einen höheren Nutzwert erzielt.

Es bleibt abzuwarten, ob sich die beiden Systeme von einander weg oder auf einander zu bewegen werden. Bei einer Erweiterung der Funktionalitäten von WordPress ist es denkbar, dass es sich einem vollwertigen Content Management System annähert.

8 Fußnoten

1. ↑ Vgl. Berres, Bullinger (2002), S. 387
2. ↑ Cyres - CMS
3. ↑ Vgl. Cyres - CMS
4. ↑ Vgl. Berres, Bullinger (2002), S. 388 f.
5. ↑ Vgl. Berres, Bullinger (2002), S. 389
6. ↑ Vgl. Berres, Bullinger (2002), S. 390 ff.
7. ↑ Vgl. Berres, Bullinger (2002), S. 408
8. ↑ Vgl. Cyres - Redaktionssysteme
9. ↑ Vgl. Cyres - WCMS
10. ↑ Vgl. Berres, Bullinger (2002), S.409
11. ↑ Vgl. Florence et al. (2008), S. 946 f.
12. ↑ Duden (2007)
13. ↑ Vgl. Simovic (2007), S. 19
14. ↑ Simovic (2007), S. 19
15. ↑ Vgl. Brügge et al. (2004), S.19 f.
16. ↑ Brügge et al. (2004), S. 20 f.
17. ↑ Vgl. Jaeger et al. (2005), S.2 ff.
18. ↑ Vgl. Schreiner (2002), S. 12 f.
19. ↑ Zangemeister (1972), S. 45
20. ↑ Vgl. Litke (2007), S. 138
21. ↑ Götze (2008), S. 181
22. ↑ Vgl. Litke (2007), S. 139
23. ↑ ^{23,0 23,1} Vgl. Götze (2008), S. 181
24. ↑ Götze (2008), S. 181
25. ↑ Vgl. Litke (2007), S. 139
26. ↑ Vgl. Litke (2007), S. 140
27. ↑ Vgl. Götze (2008), S. 182
28. ↑ Vgl. Litke (2007), S. 140
29. ↑ Vgl. Götze (2008), S. 183
30. ↑ Litke (2007), S. 141
31. ↑ Vgl. Götze (2008), S. 183
32. ↑ Vgl. Litke (2007), S. 141
33. ↑ Litke (2007), S. 141
34. ↑ Vgl. Götze (2008), S. 183
35. ↑ Litke (2007), S. 141
36. ↑ Litke (2007), S. 142
37. ↑ Vgl. Litke (2007), S. 141
38. ↑ Litke (2007), S. 142
39. ↑ Vgl. Götze (2008), S. 183
40. ↑ Götze (2008), S. 184
41. ↑ Vgl. Wikipedia - Joomla
42. ↑ Vgl. Speer, Wassermann (2008), S. 13
43. ↑ Vgl. Thon-Soun (2010), S. 19
44. ↑ Vgl. Wikipedia - WordPress
45. ↑ Vgl. Thon-Soun (2010), S. 19
46. ↑ Vgl. Wikipedia - WordPress
47. ↑ Vgl. Schürmann (2008), S 17 ff.
48. ↑ ^{48,0 48,1} Vgl. Ebersbach et al. (2009)
49. ↑ Vgl. Lipinski (2004), S. 87
50. ↑ Hansen, Neumann (2005), S. 287
51. ↑ Vgl. OWASP - Top Ten
52. ↑ Vgl. Hauser, Wenz (2009), S.359 ff.
53. ↑ Vgl. Hauser, Wenz (2009), S.354 ff.
54. ↑ Vgl. Störl (2001), S. 136
55. ↑ Vgl. Abts, Mülder (2009), S. 455
56. ↑ Vgl. Kempkens (2009), S. 125
57. ↑ Vgl. Bonfranchi-Simovic, Simovic (2008) , S. 191 ff
58. ↑ Vgl. MooTools Webseite
59. ↑ Vgl. Ebersbach et al. (2009), S. 627
60. ↑ ^{60,0 60,1} Vgl. Ebersbach et al. (2009), S. 628
61. ↑ Ebersbach et al. (2009), S. 279
62. ↑ Vgl. Ebersbach et al. (2009), S. 279
63. ↑ Vgl. Hauser, Wenz (2009), S. 398
64. ↑ Vgl. Ebersbach et al. (2009), S. 281
65. ↑ Ebersbach et al. (2009), S. 281
66. ↑ Vgl. Ebersbach et al. (2009), S. 279
67. ↑ Vgl. Hauser, Wenz (2009), S. 397
68. ↑ Vgl. Luhm (2007), S. 168 ff.
69. ↑ ^{69,0 69,1} Vgl. Speer, Wassermann (2008) S. 193 f.
70. ↑ ^{70,0 70,1 70,2} Vgl. Graf (2007) S. 35
71. ↑ Vgl. Speer, Wassermann (2008) S. 193 f.
72. ↑ Vgl. Speer, Wassermann (2008) S. 194
73. ↑ Vgl. Luhm (2007), S. 68-89
74. ↑ MySQL - Lifecycle
75. ↑ Vgl. WebHostlist Webseite
76. ↑ HostSuche Webseite
77. ↑ Vgl. Joomla! Systemvoraussetzungen
78. ↑ Vgl. WordPress Systemvoraussetzungen
79. ↑ Vgl. Hauser, Wenz (2009), S. 131
80. ↑ Vgl. Koch (2007), S. 81
81. ↑ Vgl. Hauser, Wenz (2009), S.139
82. ↑ Vgl. Hauser, Wenz (2009), S. 141 ff.
83. ↑ Vgl. Koch (2007), S. 331 ff.
84. ↑ Vgl. Simovic (2007), S. 362 f.
85. ↑ Vgl. Alby (2008), S. 113
86. ↑ Vgl. Hauser, Wenz (2009), S. 162 f.
87. ↑ Vgl. Schürmann (2009), S. 588 f.
88. ↑ Vgl. WordPress Dokumentation - Backups
89. ↑ Vgl. WordPress Dokumentation - Resetting Your Password
90. ↑ Vgl. WordPress Dokumentation - Configure Error Log
91. ↑ Vgl. Ebersbach et al. (2009) , S 241 ff.
92. ↑ Vgl. Kempkens (2009), S. 150
93. ↑ Vgl. Bonfranchi-Simovic, Simovic (2008), S. 192 ff.
94. ↑ Vgl. TemplateMonster Webseite
95. ↑ Vgl. Prateeksha Web Design
96. ↑ Vgl. ScriptLance Webseite
97. ↑ Vgl. Ebersbach et al. (2009), S. 629 ff.
98. ↑ Vgl. Hauser, Wenz (2009), S. 344
99. ↑ Vgl. Hauser, Wenz (2009), S. 342
100. ↑ Schürmann (2008), S. 391
101. ↑ Vgl. WordPress-Deutschland Webseite
102. ↑ Vgl. Alby (2007), S. 129-130
103. ↑ Vgl. Thon-Soun (2008), S. 231
104. ↑ ^{104,0 104,1} Joom!Fish Webseite

9 Literatur- und Quellenverzeichnis

Abts, Mülder (2009)	Abts, D./ Mülder, W.: Grundkurs Wirtschaftsinformatik, 6. Aufl., Vieweg + Teubner-Verlag, Wiesbaden (2009)
Alby (2008)	Alby, T.: Professionell bloggen mit WordPress, 1. Aufl., Carl Hanser Verlag, München (2008)
Berres, Bullinger (2002)	Berres A./ Bullinger, H.-J: E-Business - Handbuch für Entscheider: Praxiserfahrungen, Strategien, 1. Aufl., Springer Verlag, Berlin (2002)
Bonfranchi-Simovic, Simovic (2008)	Bonfranchi-Simovic, T./Simovic, V.: WordPress - Das Praxisbuch, 2. Aufl., mitp, Heidelberg (2008)
Bonfranchi-Simovic, Simovic (2010)	Bonfranchi-Simovic, T./Simovic, V.: WordPress - Das Praxisbuch, 3. Aufl., mitp, Heidelberg (2010)
Brügge et al. (2004)	Brügge, B./ Harhoff, D./ Picot, A./ Creighthon, O./ Fiedler, M./ Henkel, J.: Open-source-software: Eine ökonomische und technische Analyse., 3. Aufl., Springer Verlag, Berlin, Heidelberg (2004)
Duden (2007)	Duden, 6. Aufl., Dudenverlag, Mannheim/Leipzig/Wien/Zürich (2007)
Ebersbach et al. (2009)	Ebersbach, A./ Glaser, M./ Kubani, R.: Joomla! 1.5, 2. Aufl., Galileo Press, Bonn (2009)
Florence et al. (2008)	Florence, M./ Wenz, C./ & Naurice, F.: Das Website Handbuch: Programmierung und Design, 1. Aufl., Markt und Technik Verlag, München (2008)
Götze (2008)	Götze, U.: Investitionsrechnung: Modelle und Analysen zur Beurteilung von Investitionsvorhaben, 6. Aufl., Springer Verlag, Berlin/Heidelberg (2008)
Graf (2007)	Graf, H.: Joomla! 1.5: Websites organisieren und gestalten mit dem Open Source-CMS, Addison-Wesley Verlag, München (2007)
Hansen, Neumann (2005)	Hansen, H. R./Neumann,G.: Wirtschaftsinformatik 1 - Grundlagen und Anwendungen, 9. Aufl., Lucius & Lucius Verlagsgesellschaft, Stuttgart (2005)
Hauser, Wenz (2009)	Hauser, T./ Wenz, C.: Joomla! 1.5 - Das open source-CMS einsetzen und erweitern, 3. Aufl., Carl Hanser Verlag, München (2009)
Jaeger et al. (2005)	Jaeger, T./ Koglin, O./ Kreutzer, T./ Metzger, A./ Schulz, C.: Die GPL kommentiert und erklärt, 1. Aufl., O'Reilly Verlag, Köln (2005)
Kempkens (2009)	Kempkens, A.:Das Joomla! Entwicklerhandbuch, 1. Aufl., Addison-Verlag, München (2009)
Koch (2007)	Koch, D.: Joomla! 1.5 - Webseiten gestalten und administrieren, Data Becker, Düsseldorf (2007)
Lipinski (2004)	Lipinski, K.: Handlexikon der Informationstechnologie, mitp-Verlag, Bonn (2004)
Litke (2007)	Litke, H.-D.: Projektmanagement: Methoden, Techniken, Verhaltensweisen, Evolutionäres Projektmanagement, 5. Aufl., Carl Hanser Verlag, München (2007)
Lotze, Theune (2005)	Lotze, T./ Theune, C.: Content Management mit Plone: Handbuch für Autoren und Redakteure, 1. Aufl., Gocept GmbH & Co. KG., Heidelberg (2005)
Luhm (2007)	Luhm, T. P.: Das Einsteigerseminar Joomla! 1.5, 1. Aufl., Bhv Verlag, Heidelberg (2007)
Schürmann (2008)	Schürmann, T.: Praxiswissen Joomla!, 1. Aufl., O’Reilly, Köln (2008)
Schürmann (2009)	Schürmann, T.: Joomla! Websites erweitern & optimieren, 1. Aufl., O’Reilly, Köln (2009)
Schreiner (2002)	Schreiner, F.: Die Nutzwertanalyse als Instrument des Controlling, Books on Demand, Norderstedt (2002)
Simovic (2007)	Simovic, V.: WordPress - Das Praxisbuch, 1. Aufl., mitp, Heidelberg (2007)
Speer, Wassermann (2008)	Speer, C./ Wassermann, T.: Joomla! 1.5 - Das Praxisbuch, 1. Aufl., MITP-Verlag, Heidelberg (2008)
Störl (2001)	Störl, U.: Backup und Recovery in Datenbanksystemen, 1. Aufl., Teubner-Verlag, Stuttgart/Leipzig/Wiesbaden (2001)
Thon-Soun (2010)	Thon-Soun, M.:WordPress 2.8: Vom einfachen Blog zur dynamischen Website, Addison-Wesley, München (2010)
Zangemeister (1972)	Zangemeister, C.: Nutzwertanalyse in der Systemtechnik – Eine Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen. Diss. Techn. Univ. Berlin 1970, 2. Aufl., Wittemann, München (1972)

10 Internetquellenverzeichnis

Cyres - CMS	http://www.cyres.de/cms-grundlagen/cms-definition/content-management-system.htm, Stand: 10.06.2010
Cyres - Redaktionssysteme	http://www.cyres.de/cms-grundlagen/cms-definition/redaktionssystem.htm , Stand: 10.06.2010
Cyres - WCMS	http://www.cyres.de/cms-grundlagen/cms-definition/web-content-management-system.htm , Stand: 10.06.2010
HostSuche Webseite	http://www.hostsuche.de, Stand: 19.05.2010
Joomla! Systemvoraussetzungen	http://www.joomla.org/technical-requirements.html, Stand: 19.05.2010
Joom!Fish Webseite	http://www.joomfish.net/documents/PM_3.09_kempkens_joomfish.pdf, Stand: 01.06.2010
MooTools Webseite	http://demos.mootools.net, Stand: 15.06.2010
MySQL - Lifecycle	http://www.mysql.de/about/legal/lifecycle, Stand: 05.06.2010
OWASP - Top Ten	http://www.owasp.org/index.php/Top_Ten, Stand: 18.05.2010
Prateeksha Web Design	http://www.prateeksha.com, Stand: 12.05.2010
ScriptLance Webseite	http://www.scriptlance.com, Stand: 12.05.2010
TemplateMonster Webseite	http://www.templatemonster.com, Stand: 12.05.2010
Wikipedia - Joomla!	http://de.wikipedia.org/wiki/Joomla, Stand: 26.05.2010
Wikipedia - WordPress	http://de.wikipedia.org/wiki/Wordpress, Stand: 26.05.2010
WebHostListe Webseite	http://www.webhostlist.de, Stand: 26.05.2010
WordPress Dokumentation	http://codex.wordpress.org, Stand: 15.06.2010
WordPress Systemvoraussetzungen	http://wordpress.org/about/requirements, Stand: 19.05.2010
WordPress Deutschland Webseite	http://doku.wordpress-deutschland.org/Plugin_Management, Stand: 12.05.2010