Interview: WordPress-Nutzung an der FAU Erlangen-Nürnberg

Wolfgang Wiese

Ich finde es immer spannend zu sehen, wie WordPress in diversen Bereichen eingesetzt wird. Da ich das letzte Mal Ende 2003 an einer Uni gearbeitet habe und WordPress damals noch kein Thema war, freue ich mich, wenn ich auch aus erster Hand erfahren kann, wie und wo WordPress im Hochschulbereich eingesetzt wird. Dafür habe ich ein kurzes Gespräch mit Wolfgang Wiese geführt, der an der Friedrich-Alexander-Universität Erlangen-Nürnberg arbeitet.

Hallo Wolfgang, wir beide kennen uns zwar seit vielen Jahren, aber das trifft nicht auf alle Leser von perun.net zu. Stelle dich bitte kurz vor und erzähle uns, was du machst.
Ich bin als Abteilungsleiter im regionalen Rechenzentrum zuständig für den Webdienst für die Friedrich-Alexander-Universität Erlangen-Nürnberg, aber auch für andere Hochschulen in Nordbayern, die den Dienst auch nutzen wollen.

Seit 2021 hosten wir auch die Website der neuen Technischen Universität Nürnberg. Man kann uns da vergleichen mit einem Provider wie 1&1, wobei wir aber zusätzlich dazu auch noch die Aufgaben einer Full-Service-Webagentur übernehmen.

Wie bist du WordPress gekommen und was schätzt an dem CMS?
Meine erste Berührung mit WordPress ist schon so lange her, das gehört bereits zur Web-Steinzeit. Wir haben WordPress 2010 als Ablöse für die damals veraltete Blogging-Software Antville eingeführt. Damals war der Hauptzweck noch nicht die Nutzung als CMS, sondern tatsächlich als zentrales Blogsystem für die FAU.

Erst ab 2013 haben wir es dann auch im Sinne eines CMS für immer mehr Webauftritte verwendet. Inzwischen betreiben wir 3 redundant ausgelegte Multisite Installationen mit zusammen über 1000 Instanzen.

Der eigentliche Grund war damals wie heute derselbe: WordPress hat im Vergleich zu den meisten anderen CMS eine sehr flache Lernkurve. Auch unbedarfte Anwender, die von IT keine Ahnung haben und auch damit eigentlich auch nichts zu tun haben wollen, kommen sehr schnell damit zurecht.

Alle anderen CMS wollten den Autoren immer in eine festgelegte Methodik der Bearbeitung zwängen. WordPress dagegen war eine Befreiung. Man konnte einfach loslegen und schreiben.

Wenn ich WordPress mit nur einem Wort charakterisieren müßte dann mit dem Wort Freiheit.

Wie kann man sich den Einsatz in einem universitären Betrieb so vorstellen? Wie wird es eingesetzt, was benötigen die Nutzer? Von wie vielen Installationen und Instanzen reden wir da? Wo liegen die Chancen und wo die Stolpersteine?
An einer Universität gibt es den Grundsatz der Freiheit von Forschung und Lehre. Dies hat für Webauftritte die unmittelbare Konsequenz, dass sich die meisten Lehrstuhlinhaber nicht einfach in ein “von oben” oder von einer zentralen Pressestelle vorgegebenes Corporate Design pressen lassen. Wenn den Profs das Corporate Design nicht passt oder die Webdienste zu streng reglementiert sind, dann kann niemand sie daran hindern, mit ihrer Website einfach zu einem Billigprovider zu “fliehen” und sich vom Bruder des Freundes der Tochter mal eben etwas zusammenklickern zu lassen.

Das andere, was man wissen muss, ist, dass die eigentlichen Webmaster der Lehrstuhl-Websites üblicherweise zeitlich befristete Angestellte sind, welche das Web nur nebenher machen. Etwa alle 2 Jahre wechseln die Webmaster, ohne dass die Nachfolger besonders eingearbeitet wurden.

Daneben gibt es nur eine Handvoll von Webauftritten, die tatsächlich mit einer professionellen dafür angestellten Webredaktion ausgestattet sind. So zum Beispiel die Hauptseite der Universität oder die Fakultätsportale.

Kurzum: Wir müssen ein Angebot machen, das so gut und einfach zu bedienen ist, dass es niemand einschränkt, leicht und möglichst ohne Zusatzschulung zu bedienen ist. Das Corporate Design in Form der Themes muss viele Freiheitsgrade ermöglichen und vielfältige Inhaltstypen berücksichtigen.

Gleichzeitig müssen alle Webauftritte sicher sein und die Anforderungen an Datenschutz und Barrierefreiheit einhalten.

Der Webdienst für Webauftritte besteht aus 2 Domain based Multisite-Instanzen mit zusammen 744 Webauftritten. Die Webauftritte werden von über 3.600 Benutzern bearbeitet.

Auf dem Blogdienst haben wir 300 aktive Instanzen auf einer Directory-based Multisite.

Unsere größte Instanz ist die deutschsprachige Hauptseite der FAU. Diese Website hat allein über 6.200 Beiträge, 804 Seiten und 10.000 Mediendateien und wird von 123 Autoren, 13 Redakteuren und 16 Administratoren verwaltet.

Das Ganze machen wir mit vier Webservern a 2 × 8 Core CPU und 120 GB RAM auf Ubuntu, Apache und PHP mit FPM.
Die Datenbanken und der Fileserver sind ausgelagert auf andere Server.

Auf Twitter sehe ich des Öfteren, dass du dich über Gutenberg beklagst. Du hattest sogar in einem Tweet geschrieben, dass ihr auf einer Team-Sitzung den Umstieg auf ClassicPress überlegt habt. Was war der Anlass?
In unserem Team führen wir schon recht lange die Diskussion, wann, ob und wie wir den Block Editor einführen. Momentan haben wir uns dazu noch zu keinem Fahrplan durchringen können.

Unsere zwei großen Probleme sind auf Seite der Autoren: Viele unserer Autoren, die Lehrstuhl-Webmaster, kommen mit dem Block Editor nicht zurecht. Und wollen das auch nicht: Die sind es gewohnt, daß ein einfacher WYSIWYG-Editor vorhanden ist. Der die wesentlichsten Tools auf einen Blick und immer anzeigen lässt.

Die meisten unserer Webmaster arbeiten zudem in der Welt der Office-Anwendungen und nutzen daher gern Copy-and-paste. Also von Word in WordPress rein und zurück.

Das verträgt sich aber nicht mit dem Block Editor, der nach einem Paste von längeren Texten einfach mal ungefragt aus den Absätzen einzelne, getrennte Blöcke macht.

Das andere Problem ist der FSE-Ansatz. Ganz kurz: Das wollen die Autoren überhaupt nicht. Die wollen Text veröffentlichen. Und das schnell und ohne wildes Geklicker in den Optionen. Punkt.

Das drumherum, die Optik der Website auf verschiedenen Ausgabemedien, ist den meisten völlig egal – das soll bitteschön das Theme machen.

Selbst in den WordPress-Kursen unseres Schulungszentrums kommen die Leute nicht mit dem Block Editor klar und wechseln schnell wieder auf den Classic Editor.

Wir haben aktuell nur ein einziges Einsatzszenario, bei dem wir derzeit den Block Editor anbieten: in Rahmen eines Newsletter-Plugins. Dort aktivieren wir für die optische Gestaltung von HTML-Newslettern, die in Custom Post Types gespeichert werden, den Block Editor.

Wenn wir, bei unserem Autorenkreis und im Einsatzkontext als CMS, den Block Editor zulassen wollen, dann wird das nur optional gehen. Als Angebot neben dem HTML Editor, dem Classic Editor und ggf. sogar weiteren Editoren.

Und, das ist wichtig, als Angebot pro Autor, nicht pro Seite. Es muss möglich sein, dass dieselbe Seite, derselbe Post von einem Autor mit dem Block Editor bearbeitet werden kann, während ein anderer mit dem Classic Editor arbeitet. Oder ein Dritter eben den HTML Editor bevorzugt.

Das Iceberg Plugin, der einen Markdown-Editor innerhalb des Block-Editors ermöglicht, ist ein Proof of Concept, dass dies möglich sein sollte. Auch ist die Syntax der Block-Anweisungen als HTML-Kommentare naturgemäß genauso interpretierbar wie es auch die traditionellen Shortcodes sind. Warum sollte es daher unmöglich sein, Block-Anweisungen in Shortcode-Anweisungen umzuwandeln, wenn der Classic Editor verwendet wird, während der Shortcode-Anweisungen, die vom Classic Editor gesetzt wurden, ebenso vom Block Editor verstanden werden? Technisch sehe ich da keine Hürden. Man muss es nur tun.

Lasst uns doch die Welten der verschiedenen Editoren verbinden und den Autoren das lassen, wofür WordPress immer schon stand: Freiheit.

Der Gedanke auf ClassicPress zu wechseln ist eher ein Ausdruck der Zynik, aber keine echte Option. Wenn ich mir die Entwicklung bei ClassicPress und das sehr wenig benutzte Forum dort anschaue, dann scheint mir das leider inzwischen eine Todgeburt zu sein.

Zudem ist die Idee auf der Version 4.9 sitzenzubleiben in meinen Augen eine Fehlentscheidung gewesen. Das erinnert mich an das Schicksal vieler alter TYPO3 Installationen, die auf der Version 3 festhingen und noch immer hängen, weil ein Basis-Template nur auf dieser Version arbeitete.

Den Rückschritt auf WordPress 4.9 werden wir sicher nicht gehen. Denn der Core von WordPress ist gut gepflegt. Und an diese Version hängen wir uns dran. Egal, welchen Editor wir dann am Ende nutzen.

Diesen Beitrag teilen:

Verwandte Beiträge:

Ein Kommentar

  1. Interessant. Ich sehe auch, dass Redakteure zusammenhängende Texte und keine Abfolge von P-Blöcken verfassen wollen. Klar, für Marketing-Experten, die nebenbei UX/UI- und SEO-Fachleute sind und hauptsächlich Platz für CTA-Buttons benötigen, ist der Gutenberg-Editor super. Aber aber für Menschen, die längere Gedanken verfassen möchten, ist er meiner Meinung nach weniger geeignet.

    – Gibt es eigentlich keinen Blog-Block, der für die Zielgruppe Redakteure optimiert ist? Etwas moderner als der Classic Editor kann er gerne sein …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.