Seit Oktober 2014 wird der zentrale Webauftritt der zweitgrößten bayerischen Universität und zehntgrößte Universität Deutschlands mit WordPress verwaltet. Die FAU ist aktuell auch die größte Hochschule in Deutschland, die WordPress als Content-Management-System für ihre zentralen Webauftritte verwendet.

Der zentrale Webauftritt www.fau.de bewältigt derzeit täglich etwa eine halbe Millionen Anfragen bei 65 000 Pageviews. Im Juli 2016 wurden insgesamt über 18 Millionen Hits bei etwa zwei Millionen Pageviews ausgeliefert. Neben dem zentralen Webauftritt wird seit Anfang 2015 eine domainbasierte Multisite-Instanz betrieben, auf der inzwischen über 170 (von 1 126) verschiedene eigenständige Webauftritte der Universität gehostet werden. Für persönliche Homepages von Angehörigen der Universität steht zusätzlich noch ein klassischer Blogdienst (Directory-basierte Multisite-Instanz) zur Verfügung, auf dem 233 Blogs von über 9 200 Benutzern verwaltet werden.

Wie kam es zu WordPress an der FAU? Und welche Rahmenbedingungen führten dazu?

Die Wahl von WordPress als zentrales CMS für die Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU) war abhängig von drei Aspekten: den organisatorischen Rahmenbedingungen, personelle Gegebenheiten an Universitäten und technische Gründe.

Organisatorische Rahmenbedingungen

Die FAU ist stark dezentral aufgestellt. So gibt es nicht den einen Campus, sondern die Universität verteilt sich mit über 300 Lehrstühlen auf fünf verschiedene Orte in der Metropolregion Nürnberg. Die Schwerpunkte bilden Erlangen und Nürnberg. Aber auch hier verteilt sich die Universität auf mehrere hundert räumlich getrennte Liegenschaften.

Diese Situation sorgt dafür, dass die einzelnen Einrichtungen der FAU ein hohes Maß an Selbstständigkeit und Freiheit bei Entscheidungen haben. Die Freiheit von Forschung und Lehre beschränkt sich für viele Lehrstuhlinhaber nicht allein auf wissenschaftliche oder lehrende Tätigkeiten, sondern erstreckt sich auch auf die eigene Öffentlichkeitsarbeit. Da einige Lehrstühle und Einrichtungen zudem auch untereinander in Konkurrenz um Drittmittelgeber stehen, wird ein einfaches uniformes Design, bei dem alle Lehrstühle gleich aussehen, entschieden abgelehnt.

Wenn ein Corporate Design an einer großen, dezentralen aufgestellten Organisation Verbreitung finden soll, muss es daher von Anfang an Folgendes unterstützen:

• eigene Logos in verschiedenen Formaten, Auflösungen und Farben
• eigene Einrichtungsbezeichnungen von unterschiedlichster Textlänge
• individuelle Image-Grafiken
• eigene Webadressen

Keinesfalls darf das Corporate Design nur ein Design im Sinn einer schönen, festgelegten Optik sein. Es ist zwingend notwendig, dass es die oben genannten Bedingungen unterstützt.

Hinzu kommt der besondere Bedarf an Webdesigns für universitätsübergreifende Kooperationen und Forschungsprojekte: Bei diesen muss die Möglichkeit bestehen, ein eigenes Design zu wählen, das eben nicht dem Corporate Design einer einzigen Partneruniversität entspricht.

Unter diesen Bedingungen haben klassische Ansätze zur Zwangseinführung eines zentralen CMS und der Verordnung eines einheitlichen Corporate Designs in der Praxis nur geringe Chancen, sich durchzusetzen. Für die Wahl des CMS ergeben sich aus dieser Situation folgende Forderungen: Das CMS muss:

• flexibel konfigurierbar sein,
• den Instanzen eigene Domainnamen erlauben (sowohl Subdomains als auch eigenständige Domains),
• mehrere verschiedene Designs (Themes) bereitstellen, anstelle nur ein einziges Corporate Design,
• sowohl auf einer zentralen IT-Infrastruktur als auch auf selbst verwalteten Servern betrieben werden können,
• mithilfe von Plug-ins eine große Funktionsvielfalt bereitstellen und gängige webbasierte Lösungen anbieten, die bislang selbst gepflegt wurden (beispielsweise Onlinekalender oder Publikationsverzeichnisse).

Personelle Gegebenheiten an Hochschulen in Deutschland

Durch die personelle und finanzielle Ausstattung der Hochschulen in Deutschland kommt es zu der Situation, dass ein hoher Anteil der Anstellungen zeitlich befristet ist. Und gerade Webauftritte werden oft von zeitlich befristetem Personal betreut oder auch von studentischen Hilfskräften, die nur wenige Semester da sind.

Bei den etwa 1 100 Webauftritten an der FAU konnte festgestellt werden, dass Webmaster oder Webredakteure durchschnittlich nur zwei Jahre tätig sind, bis jemand anders den jeweiligen Webauftritt übernimmt. Somit kommen wir theoretisch auf über 500 Personen pro Jahr, die von neuem im CMS geschult werden müssten. Bei einer solch hohen Zahl an Personen wächst der Aufwand an Schulungen und Einweisungen entsprechend an. Zudem muss dauerhaft eigenes Personal vorhanden sein, das überhaupt geeignete Schulungen für das CMS und auch für die Nutzung von Designs (Themes) und Plug-ins leisten kann.

Ein Administrator, der das zentrale CMS betreibt und für Plug-in- und Theme-Entwicklung zuständig ist, kann das nicht auch noch „nebenher“ machen. Hier stellt sich dann schnell die Frage, wie viel dies kostet und wer das bezahlen soll.

Ein weiterer Aspekt betrifft die Administratoren bzw. die Entwickler selbst. Die Gehälter an den Hochschulen in Deutschland unterliegen dem Tarifvertrag der Länder für den öffentlichen Dienst. Die Gehälter für IT-Fachleute im öffentlichen Dienst liegen aber deutlich unter denen der freien Wirtschaft. Das hat zur Folge, dass Hochschulen große Probleme haben, geeignetes IT-Personal zu gewinnen. Das alles hat Einfluss auf die Wahl des CMS.

Die Schulung: Das CMS muss für die Bedienung in der Rolle eines Redakteurs oder eines Autors leicht und schnell erlernbar sein. Die Usability des CMS muss daher gerade im Backend gut und eingängig sein. Grundsätzlich lässt sich sagen: Ein CMS, bei dem allein die Schulung für eine Person mehr als ein Tag Arbeitszeit kostet, ist auf Dauer nicht finanzierbar. Ein CMS hingegen, das auch im privaten Bereich weit verbreitet ist – beispielsweise durch die weite Verbreitung als Blogsystem – kommt mit wenigen Schulungsstunden aus; wenn diese nicht sogar ganz wegfallen.

Die Usability: Um den Aufwand für Schulungen zu reduzieren, muss es zu einer Abwägung kommen: CMS, die den Wünschen und Ansprüchen von Administratoren entgegenkommen, sind meist nicht so usable wie Systeme, die sich in ihrem GUI im Backend an eher unbedarfte Redakteure richten. Ein Beispiel hierfür ist die Diskussion darüber, ob Inhalte mit einem WYSIWYG-Editor (z. B. über TinyMCE) bearbeitet werden können oder nur eine einfache Texteingabe zur Verfügung steht.

Viele Administratoren und Entwickler wollen wegen Problemen durch ungültigen HTML-Code oder wegen „überkreativer“ Autoren, die gerne mal den <h1>-Tag verwenden, um ganze Textblöcke fett zu machen (Autor: „Ich will, dass der Text halt besser erkennbar ist …“), lieber durchsetzen, dass Redakteure und Autoren nur einfache Texteingabefelder haben, in der am besten gar keine Schriftformatierung möglich ist (Admins: „Die DAUs machen damit nur Unsinn! Am Ende haben wir bunte blinkende Texte auf der Website! Das geht gar nicht!“). Und wenn eine Schriftformatierung nicht zu verhindern ist, dann allenfalls über eine definierte Textsyntax, wie beispielsweise Markdown …

Redakteure dagegen verlangen heutzutage eine Eingabemöglichkeit mit WYSIWYG und sehen das Fehlen einer solchen als Bug oder als Rückschritt an.

Die Abwägung, die bei Auswahl und Organisation des CMS zu tragen kommt, ist nun die: Wenn wir das CMS leichter benutzbar machen wollen, um Schulungskosten einzusparen, dann kommen wir eben auch an Grundfunktionalitäten wie WYSIWYG-Editoren nicht vorbei. Das hat aber zur Folge, dass die Administratoren und Entwickler von Themes und Plug-ins mehr Aufwand investieren müssen, die Eingaben besser zu validieren und den Missbrauch von HTML-Tags zur Gestaltung (z. B. Verwendung von HTML-Tabellen für nicht tabellarische Daten) und semantischer Fehler (Verwendung von Überschrifttags als Ersatz für Fettdruck oder die Verwendung von Fettdruck dort, wo tatsächlich eine hierarchisch passende Überschrift gesetzt werden müsste) zu erkennen und automatisiert zu beheben.

Diese Abwägung lässt sich auch berechnen: Selbst wenn wir bei 500 zu schulenden Personen pro Jahr auf nur eine einzige Unterrichtsstunde verzichten können, haben wir bereits genug Geld gespart, um stattdessen eine Person auf einer halben Stelle als Entwickler zu beschäftigen!

Das Personal: Aufgrund der Schwierigkeiten, überhaupt IT-Personal zu gewinnen, ist es nahezu unmöglich geworden, spezialisierte Bewerber für ein exotisches oder wenig verbreitetes System zu finden. Auch die Programmiersprache, unter der das CMS, die Themes und dessen Plug-ins entwickelt werden, spielt eine wichtige Rolle bei der Bewerbersuche. Wird ein Bewerber gesucht, der eine Programmiersprache beherrschen muss, die nicht unter den Top 10 der populärsten Programmiersprachen vertreten ist, sinken die Chancen, jemand Geeignetes zu finden deutlich. Und ein CMS, das keinen Administrator mehr hat, ist ganz schnell kein CMS mehr, sondern wird zur Viagra-Verkaufsplattform.

Im Fall der FAU war die Frage, wie aufwendig die Schulungen bei einem CMS sind, eines der wichtigsten Kriterien zur Entscheidung.

Da TYPO3 an deutschen Hochschulen historisch sehr weit verbreitet ist, wurde es im Rahmen eines Pilotprojekts genauer unter die Lupe genommen. Durch eine eigene Evaluation wurde ein Schulungsbedarf von etwa sechs bis acht Stunden ermittelt. Aktuell im Web abrufbare Schulungsangebote anderer Hochschulen (beispielsweise der Universitäten Freiburg, Erfurt und der TU Berlin) für Einführungs- und Vertiefungskurse in TYPO3 bestätigen diese Zahl.

WordPress hingegen ist an der FAU bereits seit 2005 als klassisches Blogsystem im Einsatz und steht als solches für alle Angehörigen der FAU zur freien Nutzung bereit. Der Blogdienst der FAU wurde und wird bereits als Ersatz für persönliche Homepages von Studierenden und Dozenten verwendet, als Informationsplattform für wissenschaftliche Projekte und für die Verbreitung aktueller Neuigkeiten von einzelnen Einrichtungen. Aktuell werden auf dem Blogdienst 233 Blogs von über 9 200 Benutzern verwaltet. Somit ist WordPress bereits seit geraumer Zeit vielen Angehörigen der FAU bekannt und dessen Bedienung gewohnt.

An der FAU wurden in Rahmen der Einführung von WordPress und dem neuen Corporate Design in der Zeit von Mai 2015 bis August 2016 insgesamt 143 Personen geschult. Hierfür wurden 679,5 Stunden Arbeitszeit aufgewendet. Im Durchschnitt benötigte eine Schulung in WordPress und dem Corporate Design der FAU also 4,75 Stunden pro Teilnehmer.

Technische Gründe

Für die Auswahl des CMS sprechen auch einige technische Gründe. Es gibt aber auch hier Zusammenhänge mit der Organisation und dem Umfang von IT an einer Hochschule.

Schnittstellen: Das CMS wird in einer IT-Landschaft eingesetzt, die aus mehreren Dutzend verschiedener Anwendungen besteht: DRM-Systeme, E-Learning-Systeme, verschiedene Kalender- und Veranstaltungssysteme, Medien- und Videoplattformen, Forschungsdatenbanken, Publikationsverwaltungen, Vorlesungsverzeichnisse etc. Viele dieser Systeme sind Datenquellen, deren Inhalte auch weiterhin auf den jeweiligen Plattform gepflegt werden, aber nun auch auf den Webseiten angezeigt werden sollen. Das CMS muss daher in der Lage sein, eine Vielzahl von gängigen Schnittstellen entweder bereits von Haus aus zu berücksichtigen oder aber sie über Plug-ins abzudecken. WordPress bietet bereits seit Jahren einige Importschnittstellen an, die hier besonders geeignet sind. Durch die oEmbed-Schnittstelle, die mit Version 2.9 hinzukam, wurde dies sogar nochmals verbessert.

Benutzerverwaltung: Die Benutzerverwaltung bei mehreren hundert Webauftritten mit ebenfalls mehreren hundert Administratoren, Redakteuren oder Autoren, kann nicht manuell gepflegt werden: Potenziell müssen sich alle 40 000 Studierenden und jeder der über 6 000 Angestellten der FAU mit ihrer unweiten Kennung anmelden können. Gleichzeitig muss dafür gesorgt werden, dass Personen, die nicht mehr zur Universität gehören, auch nicht mehr auf die Systeme zugreifen können. Es muss daher eine Anbindung an vorhandene uniweite IdM-Systeme bzw. einem uniweiten Single Sign-On (SSO) möglich sein. An den Hochschulen Deutschlands hat sich hierbei Shibboleth als Authentifizierungsverfahren durchgesetzt. Mit der Library SimpleSAMLphp konnte ein Plug-in entwickelt werden, das dies unterstützt und benutzerbezogene Daten in das WordPress-System integriert.

Erweiterbarkeit: WordPress verfügt über eine überaus große und aktive Community. Dies ist nicht nur an den schnellen Updatezyklen des Core-Systems bemerkbar, sondern auch am riesigen Umfang der WordPress Plugin Directory. Zwar kann und muss man die Qualität vieler Plug-ins in Zweifel ziehen und jedes Plug-in vor dem Einsatz sorgsam prüfen, jedoch ist die Kontrolle über neue Plug-ins und Themes, die in das Directory hochgeladen werden, etwas strenger als bei den Repositorys anderer Open-Source-CMS. Theme- und Plug-in-Tester verhindern grobe Schnitzer in der Entwicklung und sorgen so für eine gewisse, wenn auch geringe, Eingangshürde.

Systemressourcen: Der Ressourcenverbrauch von WordPress ist im Vergleich zu anderen CMS durchaus moderat. Für die zentrale Website der FAU (www.fau.de) sowie für die englischsprachige Version der Website (www.fau.eu) wurde bis August 2016 nur ein einziger virtueller Server mit sechs Cores und 12 GB RAM verwendet. Ein weiterer Server oder ein Load Balancer waren für diesen Webauftritt alleine bislang nicht notwendig.

Zum Caching von Seiten wird das Plug-in WP Super Cache verwendet. Die Datenbank wird mithilfe einer angepassten Version des HyperDB-Plug-ins im Master/Slave-Modus angesteuert. Erst ab September 2016 wurde hier nochmals nachgelegt und der eine Server durch zwei virtuelle Server (à vier Cores mit 8 GB RAM) ersetzt, die über einen Load Balancer wechselseitig angesprochen werden.

WordPress-IT-Infrastruktur an der FAU

Für den Unterhalt einer WordPress-Multisite-Infrastruktur, die es erlaubt, gleichzeitig mehrere hundert eigenständige Webauftritte zu verwalten, sind nochmals höhere Ansprüche hinsichtlich Skalierbarkeit und Ausfallsicherheit zu erfüllen. Insbesondere muss es möglich sein, bei einem Serverausfall oder der Notwendigkeit einer Wartung von Servern (z. B. durch ein notwendiges Betriebssystemupdate) weiterhin mit allen Webauftritten online zu bleiben. Dies gilt für alle Komponenten der IT-Infrastruktur: Load Balancer, Webserver, Fileserver und Datenbankserver.

Aufgrund der steigenden Zahl an Webauftritten, die an der FAU auf WordPress-Instanzen umgestellt werden, müssen die Server zudem ausreichend großzügig dimensioniert sein, und es muss jederzeit möglich sein, weitere Server zu ergänzen.

Alle Anfragen von außen laufen über einen Load Balancer (Hardwarelösung, A10 Thunder ADC) ein. Er reicht die Anfragen direkt an einen der eigentlichen Webserver weiter. Derzeit werden hierzu zwei Webserver mit zwei CPUs à acht Cores und 128 GB RAM verwendet (Abb. 1). Ein weiterer Server steht zu Test- und Redundanzzwecken bereit.

Der Load Balancer verteilt die Anfragen im Least-Connection-Modus. Das bedeutet, dass eine Anfrage an den Server geleitet wird, der in dem Moment die wenigsten offenen Verbindungen abzuarbeiten hat.

Sollte der Load Balancer DDoS-Angriffe erkennen, weist er sie selbsttätig ab. Gleichwohl sind dem Load Balancer noch weitere Firewalls vorgelagert, die es gewohnt sind, einiges abzufangen.

Die eigentlichen Webserver sind einheitlich installiert: als Serversoftware wird Apache verwendet. Die Konfiguration der Apaches wird über ein Versionsverwaltungssystem verteilt. Vor der Installation und dem zeitlich abgestuften Restart der Apache-Server mit einer neuen Konfiguration wird sie auf einem gesonderten Webserver auf Lauffähigkeit getestet. Alle Webauftritte sind so konfiguriert, dass sie nur noch über SSL ausgeliefert werden.

Die eigentlichen Dateien der WordPress-Installation und die Datenverzeichnisse der WordPress-Instanzen liegen dabei nicht auf den Servern, sondern werden über NF Mounts von einem Fileserver bereitgestellt. Das gilt auch für die Dateien vom Plug-in Super Cache und etwaige Session-Dateien von PHP. Letzteres ist besonders wichtig, da zeitlich aufeinanderfolgende Anfragen eines Clients von unterschiedlichen Webservern bedient werden könnten. Diese müssen daher auf dieselben Session-Informationen zugreifen können.

Ähnliches gilt auch für die MySQL-Datenbank: Sie wird zwar von einem MySQL-Server bereitgestellt, zur Ausfallsicherheit werden aber alle Datenbankinhalte zusätzlich an einen MySQL-Slave-Server gespiegelt. Sollte der MySQL-Master ausfallen, zu langsam werden oder in Wartung gehen, schwenkt WordPress mithilfe des HyperDB-Plug-ins nach einer Sekunde Delay automatisch auf den MySQL-Slave-Server um.

Anmerkung: Um dieser Struktur herum befinden sich noch weitere Server, wie zum Beispiel Server für Syslog- und Apache-Logs und zur Systemüberwachung. Sie spielen aber in der grundsätzlichen Struktur keine Rolle und sind daher nicht aufgeführt.

Themes und Plug-ins

Administratoren, die eine WordPress-Instanz für ihren Webauftritt einrichten, erhalten eine fest vorgegebene Auswahl an Themes und Plug-ins. Es ist den einzelnen Administratoren nicht möglich, eigene Themes oder Plug-ins zu installieren oder sie zu bearbeiten. Gleichwohl stehen zehn verschiedene Themes zur Verfügung, sowie fünfzig verschiedene Plug-ins, die fast jeden Bedarf abdecken.

Unter den zehn Themes befinden sich die sechs Themes mit dem zentralen FAU-Design, indessen verschiedenen Varianten für die fünf Fakultäten der FAU und den zentralen Einrichtungen, sowie vier flexibel konfigurierbare Themes, die primär für Projekte, Kongresse und Kooperationen verwendet werden (Abb. 2).

Bei der Entwicklung der FAU Themes wurde darauf geachtet, dass sie auch eigenständig auf selbst verwalteten Servern lauffähig sind. Daher wurde auch absichtlich darauf verzichtet, das eigentliche zentrale Theme FAU-Einrichtungen vorauszusetzen und alle Themes der Fakultäten als Child Themes zu entwickeln. Die FAU-Themes, beispielsweise das Theme FAU-Einrichtungen, nutzen verschiedene Frameworks und Techniken:

• Die HTML-Grundstruktur wird mit einer abgespeckten Version von Bootstrap erstellt.
• Für Icons und Symbole wird der Iconfont Font Awesome
• Alle CSS-Dateien werden mithilfe von SASS erzeugt.
• Bei optionalen Skripten wird jQuery eingesetzt.
• Für die Einbindung und Darstellung von externen Daten wird die oEmbed-Schnittstelle bevorzugt, wozu sowohl in den Themes als auch in eigenen Plug-ins entsprechende Erweiterungen zur Verfügung gestellt werden.

Die Entwicklung findet grundsätzlich öffentlich über GitHub statt. So finden sich in der Teamübersicht des RRZE-Webteams alle FAU Themes sowie die meisten selbstentwickelten Plug-ins. Lediglich solche Themes und Plug-ins, in denen vertraulichere Informationen enthalten sein könnten, werden über ein internes GitLab verwaltet.

Durch die Nutzung einer öffentlichen Projektplattform ergeben sich viele organisatorische Vorteile. So unterstützen wir die Einrichtungen der Universität, die WordPress auf eigenen Servern betreiben wollen, und fördern so die Akzeptanz gegenüber dem System und dem FAU-Design deutlich. Gleichzeitig ermöglichen wir es so Studierenden und Mitarbeitern der Universität, sich mit eigenen Vorschlägen und auch mit Codeverbesserungen einzubringen.