In Teil 3 ging es um die Leitplanken, unter denen dieses Plugin entstanden ist. Diesmal geht es darum, was passiert, wenn so ein Projekt zum ersten Mal von jemandem angeschaut wird, der es nicht gebaut hat.
Ein WordPress-Plugin veröffentlichen heißt nämlich nicht hochladen. Es heißt: durch ein Review, und zwar ein gründliches.
Die Eckdaten vorweg. Erster Commit am 17. August, freigegeben am 29. August. Zwölf Tage, zwei Review-Runden, vier Beanstandungen. Eine davon war ein Denkfehler von mir, und er hat mich hunderte Meldungen gekostet.
Runde eins: Der Name ist zu generisch
Das Plugin hieß zur Einreichung schlicht „Club Sports Manager„. Beschreibend, sagt was es tut, und genau das war das Problem.
WordPress.org lässt keine Namen zu, die wie eine Gattungsbezeichnung klingen. Die Begründung leuchtet ein, sobald man sie hört: Ein Name wie „Club Sports Manager“ belegt einen Allgemeinbegriff, den andere danach nicht mehr verwenden können. Im Verzeichnis stehen deshalb Produktnamen, keine Kategorien.
Also bekam der beschreibende Teil eine Marke davor: Squadeno – Club Sports Manager. Das war schnell erledigt und in der Sache richtig. Ich hätte vorher darauf kommen können.
Die Falle, in die ich selbst gelaufen bin
Beim Umbenennen habe ich dann einen Fehler gemacht, der mich zwei Tage gekostet hat, und er ist so lehrreich, dass er hier ausführlich stehen darf.
Ein Plugin im Verzeichnis hat zwei Bezeichner. Den Anzeigenamen, den jeder sieht. Und den Slug, der in der Adresse steht und den Ordner benennt. Zusätzlich verlangt WordPress.org, dass die sogenannte Textdomain, über die alle Übersetzungen laufen, exakt dem Slug entspricht.
Ich habe den Namen geändert und dabei angenommen, der Slug wandere mit. Also habe ich die Textdomain gleich mit umgestellt.
Falsch. Der Slug wird bei der Erst-Einreichung aus dem damaligen Namen abgeleitet und ist danach dauerhaft. Eine spätere Umbenennung ändert daran nichts. Mein Slug lautete weiterhin club-sports-manager, meine Textdomain inzwischen squadeno-club-sports-manager, und die Validierung meldete das exakt 456 Mal.
Ausgegangen ist es gut. Auf Bitte hat das Review-Team den Slug tatsächlich geändert, was nicht selbstverständlich ist und normalerweise nicht passiert. Damit war meine Textdomain plötzlich korrekt, und der Rückbau-Plan, den ich mir schon zurechtgelegt hatte, war hinfällig.
Die Lehre bleibt trotzdem: Der Slug ist permanent, und er entsteht in dem Moment, in dem du zum ersten Mal auf Absenden drückst. Wer über den Namen nachdenkt, denkt zu spät nach.
Runde zwei: drei Beanstandungen
Die zweite Runde lief automatisiert und brachte drei Punkte. Alle drei waren berechtigt.
Erstens, nach Hause telefonieren. Mein Plugin kann Karten einbinden, und die sind bewusst abschaltbar. Im Frontend hat der Schalter auch sauber funktioniert. Im Backend nicht: Die Karte im Editor für Sportstätten lud ihre Kacheln unabhängig von der Einstellung, weil der Schalter nur die Ausgabe gated hat und nicht die Pflegemaske.
Das heißt, ein Administrator, der Karten ausdrücklich abgelehnt hatte, baute beim Anlegen einer Sporthalle trotzdem eine Verbindung zu einem fremden Server auf. Aus Datenschutzsicht ist das ein echter Fehler, kein Formalismus. Heute prüft dieselbe Funktion überall, und ohne Zustimmung erscheint statt der Karte ein Hinweis mit Link in die Einstellungen. Koordinaten kann man weiterhin von Hand eintragen.
Zweitens, Quelloffenheit. Die Editor-Bausteine liegen im Paket als zusammengepackte Dateien, wie das bei modernem JavaScript üblich ist. Die lesbaren Quellen dazu lagen im Repository, und das Repository ist privat.
Für WordPress.org ist das nicht ausreichend. Wer ein Plugin ausliefert, muss den lesbaren Quelltext mitliefern, wenn er ihn nicht anderweitig öffentlich zugänglich macht. Ein Verweis auf ein Repository, das niemand öffnen kann, zählt nicht. Seitdem stecken die Quellen samt Bauanleitung im Paket, und in der Beschreibung steht ein eigener Abschnitt, der erklärt, welche Quelldatei zu welcher gebauten Datei gehört.
Das hat mich zuerst geärgert und überzeugt mich inzwischen. Ein Verein, der das Plugin in fünf Jahren noch betreibt, soll nicht davon abhängen, dass mein privates Repository dann noch existiert.
Drittens, Absicherung von Formularen. Eine WordPress-Funktion zur Prüfung von Formular-Einmalschlüsseln lässt sich von anderen Erweiterungen austauschen. Deshalb darf man ihr keine ungeprüfte Eingabe übergeben, auch wenn die Standardfassung damit umgehen kann.
Die Lösung ist unspektakulär. Es gibt jetzt genau eine Stelle im Code, an der dieser Wert gelesen und bereinigt wird, und alle Formulare benutzen sie. Solche Befunde mag ich, weil die Korrektur den Code nebenbei aufräumt.
Was ich bewusst drin gelassen habe
Zwei Dinge habe ich nicht geändert, und beide Male war die Überlegung interessanter als die Entscheidung.
Die Kartenbibliothek liegt lokal im Plugin statt von einem fremden Server geladen zu werden. Das klingt nach überflüssigem Ballast, und ich habe kurz überlegt, sie zu entfernen. Dahinter steckt ein verbreitetes Missverständnis: Diese Bibliothek ist keine Offline-Karte, sondern nur das Programm, das Karten anzeigt. Die Kartenbilder selbst kommen in jedem Fall live von einem externen Dienst. Ein Rauswurf hätte also keinen einzigen externen Aufruf gespart, nur etwa 50 KB im Paket. Und mitgeliefert zu werden ist genau das, was WordPress.org verlangt. Beanstandet war nie das Mitliefern, sondern das Laden ohne Zustimmung.
Der zweite Punkt sind strukturierte Daten für Suchmaschinen, die als kleiner Block direkt in der Seite stehen müssen. Für alles andere gilt die Regel, Skripte und Styles nur über die dafür vorgesehenen Wege einzubinden. Hier geht das technisch nicht, und das ist eine anerkannte Ausnahme. Alle übrigen eingebetteten Style-Anweisungen im Projekt sind bei der Gelegenheit rausgeflogen.
Der Test, der zu früh grün war
Es gibt ein offizielles Prüfwerkzeug, mit dem man sein Plugin vorab gegen die Regeln des Verzeichnisses laufen lassen kann. Ich hatte das gemacht. Null Fehler.
Und trotzdem ist mir der Textdomain-Fehler durchgerutscht, alle 456 Stück.
Der Grund war banal und deshalb besonders ärgerlich: Ich hatte gegen einen Ordner geprüft, der bereits den neuen Namen trug. Damit stimmte die Textdomain innerhalb meines Tests überein, und genau die Abweichung, um die es ging, konnte gar nicht auffallen. Das Werkzeug hat nichts falsch gemacht. Ich hatte ihm eine Wirklichkeit vorgesetzt, die es draußen nicht gab.
Das ist derselbe Fehlertyp wie der Migrationstest aus Teil 3, der grün wurde, weil ein Zwischenschritt die Realität begradigt hat. Ein Test prüft immer nur die Welt, die man ihm hinstellt.
Nach der Freigabe
Freigegeben wurde am 29. August. Die Auslieferung läuft bei WordPress.org über ein Versionsverwaltungssystem, das die meisten Entwickler seit Jahren nicht mehr angefasst haben, und das Passwort dafür ist ein anderes als das des Kontos. Diese beiden Sätze hätten mir eine halbe Stunde gespart.
Von Hand hochgeladen habe ich genau einmal. Seitdem macht das die Pipeline: Ein Commit auf dem Hauptzweig baut das Paket, spiegelt es ins Verzeichnis und setzt denselben Versionsstempel im Repository. Abgesichert ist das über einen Schalter, ohne den die ganze Strecke stumm bleibt. So konnte ich sie in Ruhe fertig bauen und testen, bevor sie zum ersten Mal wirklich etwas veröffentlicht hat.
Auf diesem Weg sind seitdem sechs Releases rausgegangen.
Fazit
Zwölf Tage klingt nach einer Erfolgsgeschichte, und ich bin auch zufrieden damit. Nur ist die Freigabe nicht das Ziel gewesen, sondern die Startlinie. Seit dem 29. August ist deutlich mehr Arbeit ins Projekt geflossen als davor.
Was ich mitgenommen habe, lässt sich in drei Sätze fassen. Der Name entsteht früher, als man denkt, und ist danach nicht mehr verhandelbar. Ein Schalter, der nur die halbe Software erreicht, ist kein Schalter. Und eine Prüfung, die man selbst zurechtlegt, prüft vor allem die eigene Annahme.
Von den vier Beanstandungen ging keine gegen die Idee des Plugins, und keine betraf die Funktionen. Alle vier betrafen die Sorgfalt am Rand. Genau die Stellen also, an denen man bei einem Projekt für den Verein im Ort am ehesten großzügig wäre.
Im letzten Teil geht es um den Moment, auf den die ganze Sache hinauslief: Wie sich die Einführung beim TV Ober-Olm tatsächlich anfühlt, wenn Leute ohne Technikhintergrund anfangen, ihre eigenen Trainingszeiten einzutragen. Den schreibe ich, wenn die neue Seite live ist.
Dieser Artikel ist Teil 4 einer Serie über ein WordPress-Plugin für Sportvereine. Zuvor: das Problem des Vereins, die Entscheidung für ein Produkt und die Leitplanken der Entwicklung.
Alle Teile der Serie: Zur Themenseite „Squadeno – das Plugin für Sportvereine“
