Vorgaben an Plugins

Stand: 7. Oktober 2024

Bei der Nutzung, Entwicklung oder Erweiterung von Plugins haben wir einige Rahmenbedingungen, die stets zu beachten sind.

Anforderungen an neue Plugins auf dem CMS-Angebot des RRZE

1. Für das jeweilige Plugin muss stets ein fachkompetenter Ansprechpartner vorhanden sein, der im Falle von Problemen oder Fehlern zeitnah reagiert.
2. Das Plugin muss als Mindestanforderung kompatibel zur jeweils aktuellen WordPress- und PHP-Version der CMS-Instanz des RRZE sein: WordPress-Version 6.8, PHP-Version 8.2.
3. Alle Ausgaben (sowohl im Frontend, als auch im Backend) müssen stets konform zur aktuell gültigen Version der WCAG in der Konformitätsstufe AA sein. Im Falle von interaktiven Seiten (Formularen u.ä.) ist die Konformitätsstufe AAA zu erfüllen.
4. Die Bereitstellung des Plugins muss auf WordPress (https://de.wordpress.org/plugins/) bzw. auf einem öffentlichen GitHub-Repository (https://github.com/) oder auf einer öffentlichen Gitlab-Repository erfolgen. Eine manuelle Aktualisierung über uns zugesandte ZIP-Dateien ist nicht möglich.
5. Die programmiertechnische Fehlerfreiheit von Plugins ist zu gewährleisten:
   1. Das Theme wird mittels des Plugins Plugin Check (PCP) geprüft. Der Test mit Hilfe dieses Plugins sollte keine Fehler aufzeigen. Ausnahmen gelten für Warnungen und Fehlermeldungen hinsichtlich von versteckten Dateien (bspw. für die Datei .gitignore).
   2. Plugins sollten stets auf einer WordPress-Installation entwickelt und getestet werden, bei der ein DEBUG-Modus so eingestellt ist, dass er Warnung ausgibt. Kein Plugin darf im produktiven Betrieb Warnings oder gar Fatal Errors liefern.
6. Enthält das Plugin JS- oder CSS-Komponenten, muss sichergestellt werden, dass diese nur dann in der WordPress-Installation „enqueued“ werden, wenn das Plugin in der jeweiligen Seite tatsächlich zur Anwendung kommt. Ein grundsätzliches Einbinden auf jeder Seite der Installation ist nicht zulässig. Stattdessen muss ein register() erfolgen und das enqueue() erst dann, wenn ein Shortcode oder eine Funktion ausgeführt wird, die tatsächlich ein Ergebnis ausgibt.
7. Hinsichtlich der Verwendung von Bibliotheken und Buildprozessen (Composer u.a.) ist zu beachten:
   • Bei der Bereitstellung von JS-Dateien ist darauf zu achten, ob etwaige JS-Bibliotheken nicht bereits von WordPress selbst zur Verfügung gestellt werden. In diesem Fall sind die von der WordPress-Instanz zu nutzen. Keinesfalls darf beispielsweise eine eigene jQuery-Bibliothek vom Plugin nochmals mit- und ausgeliefert werden, wenn diese bereits zuvor vom Theme oder einem anderen Plugin ebenfalls enqueued wurde.
   • Werden JS-Dateien bereitgestellt, sind diese in minifizierter Form bereitzustellen. Die minifizierte Form kann im Dateinamen durch den Bestandteil „min“ gekennzeichnet werden. Für Debug- und Testzwecke kann das Plugin in nicht minifizierter Form genutzt werden. In dem produktiven Einsatz ist die minifizierte Version zu laden. Die JS-Datei des Plugins sollte den Namen des Plugins tragen und mit .js enden.
   • Werden Schriften oder Bibliotheken eingebunden, müssen diese im Source des Plugins vorhanden sein und von dort „lokal“ eingebunden werden. Die Verwendung von externen CDNs (wie beispielsweise fonts.google.com) ist nicht zulässig.
8. Werden CSS-Dateien bereit gestellt, die einen Umfang von mehr als 50 Codezeilen (ohne Kommentare) haben, ist zwingend der CSS-Präprozessor SASS zu verwenden. Die CSS-Dateien sollen mit Hilfe von SASS minifiziert werden. Auf die Verwendung von Vendor-Codes in den SASS-Dateien soll verzichtet werden. Vielmehr sollten diese nur mittels eines Autoprefixers in der erzeugten CSS-Datei ergänzt werden. Die CSS-Datei des Plugins sollte den Namen des Plugins tragen und mit .css enden.
9. Ausgaben der Plugins sollten im besten Fall sowohl mittels Shortcodes als auch im Blöcken (hybride Lösung) verfügbar sein. Sollte das Plugin nur auf einem klassichen Theme zum Einsatz kommen, kann auf die Block-Editor Komponente verzichtet werden. Grundsätzlich sollen jedoch alle Plugins, die nach dem 1.1.2025 bereitgestellt werden, auch eine Block-Komponente für den neuen Block Editor anbieten. Hinsichtlich der Entwicklung der Blöcke gibt es ergänzende Anforderungen.
10. Plugins dürfen keine Pagebuilder-Funktion abseits der Funktionen des Block Editors einführen oder integrieren.
11. Werden durch Plugins fremde Ressourcen abgerufen oder angezeigt, sind die Anforderungen an den Datenschutz zu berücksichtigen. Ist eine Einbindung nicht zu verhindern, so ist dies mit dem RRZE abzustimmen, so daß u.U. die Aktivierung eines Consent Banners aktiviert werden kann.
12. Kommerzielle Plugins, deren Nutzung eine kostenpflichtige Lizenz erfordert, können nur über das RRZE beschafft und installiert werden. Für den Betrieb dieser Plugins ist eine gesonderte Wartungsgebührt erforderlich, die zu den Lizenzkosten des Plugins hinzukommen.