Vorgaben an Plugins

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

Grundlegende Anforderungen

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Das Plugin muss als Mindestanforderung kompatibel zur jeweils aktuellen WordPress- und PHP-Version sein. (WordPress-Version 6.5, PHP-Version 8.2)
  7. Alle HTML-Ausgaben müssen stets konform zur WCAG 2.2 in der Konformitätsstufe AA sein. Im Falle von interaktiven Seiten (Formularen u.ä.) ist die Konformitätsstufe AAA zu erfüllen.
  8. 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.
  9. Bietet das Plugin einen Shortcode, so muss dieser sowohl im Classic-Editor als Shortcode, als auch im Gutenberg-Editor als Block zu verwenden sein.

Betriebsbedingungen auf der CMS-Instanz der FAU

Bei einem Einsatz auf der zentralen CMS-Instanz der FAU herrschen folgende Arbeitsbedingungen:

  • Im Falle eines anstehenden WordPress-Updates hat dieses stets Priorität gegenüber dem Funktionieren von Plugins und Themes. Bei einem WordPress-Update erfolgt keine vorherige Abstimmung mit Theme- oder Plugin-Entwicklern, ob das Update durchgeführt werden kann. Stattdessen erwarten wir von allen Theme- oder Plugin-Entwicklern, dass sich diese über die anstehenden Updates über die herkömmlichen Publikationskanäle von WordPress informiert halten und bereits vor den Veröffentlichung von neuen Versionen die jeweiligen Themes und Plugins daraufhin ertüchtigten.
  • Plugins und Themes, die nach einem WordPress-Update nicht mehr funktionieren oder Fehler liefern, können ohne Vorwarnung deaktiviert werden.
  • Plugins und Themes, die länger als ein Jahr nicht mehr aktualisiert wurden oder bei denen der Entwickler nicht mehr erreichbar ist, können jederzeit und ohne Vorwarnung deaktiviert werden.

Neue Plugins entwickeln und einreichen

Wenn Sie selbst ein Plugin entwickeln möchten, das auf unserer Multisite-Instanz zur Verfügung gestellt werden soll, gibt es einiges zu beachten. Wir fassen hier die Rahmenbedingungen dafür zusammen – die Entscheidung, ob ein Plugin bei uns zur Verfügung gestellt wird, treffen wir nach eingehender Prüfung.

Fremdplugins können wir nur bei Erfüllung folgender Grundbedingungen auf der CMS-Instanz übernehmen:

  1. Die Bereitstellung des Plugins muss auf WordPress (https://de.wordpress.org/plugins/) bzw. auf GitHub (https://github.com/) erfolgen:
    • Schreiben Sie den Namen des Repositories klein (z.B. lehrstuhl-feedreader)
    • Folgende Präfixe verwenden Sie bitte nicht: rrze-, utn-, fau- und cms-
  2. Der Header des Plugins muss in folgenden Feldern angepasst werden
    • Plugin Name: Name des Plugin (Groß-/Kleinschreibung egal)
    • Plugin URI: URL des WordPress- bzw. Github-Repositories (z.B. https://github.com/RRZE-Webteam/rrze-univis)
    • Description: Beschreibung des Plugin. Stellen Sie eine aussagekräftige Erläuterung zum Zweck des Plugin zur Verfügung.
    • Version: 1.0.0
      • Hauptversionsnummer (1): indiziert meist äußerst signifikante Änderung am Plugin
      • Nebenversionsnummer (1.0): bezeichnet meistens die funktionale Erweiterung des Plugins
      • Revisionsnummer (1.0.0): enthält meist Bugfixes bzw. Sicherheits- und Wartungsupdates
    • Author: Der Name des Entwicklers (das kann auch ein Hiwi sein)
    • Author URI: wenn vorhanden, URL der Homepage des Entwicklers (z.B. http://blogs.fau.de/webworking/)
    • License: GNU GPL v3
    • Contact Name: Der Name des Webmasters als verantwortlicher Ansprechpartner
    • Contact Email: Die Mailadresse des Ansprechpartners; die Angabe einer fau.de-Adresse ist zwingend nötig (z.B. kontakt.name@fau.de)
  3. Der Webmaster ist uns gegenüber dafür verantwortlich, dass das Plugin weiterentwickelt und aktuell gehalten wird.
    Im Speziellen bedeutet das:
    • Das Plugin muss als Mindestanforderung kompatibel zur jeweils aktuellen WordPress- und PHP-Version sein.
    • Der Webmaster ist verpflichtet, sich eigenständig über die Veröffentlichung neuer WordPress-Versionen zu informieren und das Plugin unverzüglich auf Kompatibilität damit zu überprüfen.
    • Nach erfolgreicher Prüfung und eventuell erforderlichen Anpassungen muss die Versionsnummer zumindest an der Revisionsnummer erhöht werden und ein Commit erfolgen, damit die erfolgreiche Überprüfung für uns ersichtlich ist.
  4. Sie müssen damit rechnen, dass Ihr Plugin auf der CMS-Instanz von uns deaktiviert bzw. von der CMS-Instanz entfernt wird, wenn
    • Sicherheitslücken im Plugin vorliegen
    • Kompatibilitätsprobleme mit anderen auf der CMS-Instanz befindlichen Plugins oder der aktuellen WordPress- bzw. PHP-Version auftreten
    • der Webmaster der Aktualisierungspflicht des Plugins nicht nachkommt
    • der im Plugin genannte Ansprechpartner (Contact Name und Contact Email) kein bei uns registrierter Webmaster bzw. Universitätsangehöriger mehr ist
  5. Der Webmaster ist sich bewusst, dass mit der Deaktivierung des Plugins die darin bereitgestellten Funktionalitäten nicht mehr zur Verfügung stehen.
  6. Im Falle einer Deaktivierung bzw. Entfernung des Plugins erhält der Webmaster an die im Plugin hinterlegte Adresse eine E-Mail mit der Information, dass erst nach einer Behebung der Fehler und einem Update das Plugin wieder aktiviert wird.