Ein Ein-Personen-SaaS durch das Review von WordPress.org bringen

Das Problem war der Medienbruch, nicht die Analyse

Lautheitsprüfung ist ein gelöstes Problem — es gibt seit Jahren Werkzeuge dafür. Ungelöst war der Weg dorthin: Wer eine Podcast-Folge in WordPress hochlädt, müsste die Datei erst wieder herunterladen, in eine Audio-Anwendung laden, prüfen, korrigieren, exportieren und neu hochladen. Bei wöchentlichen Folgen ist das der Punkt, an dem die Qualitätskontrolle stillschweigend entfällt.

Die Produktentscheidung war deshalb nicht „bessere Analyse bauen“, sondern „die vorhandene Analyse dorthin bringen, wo die Datei ohnehin liegt“.

Warum daraus acht Dienste wurden

Ein WordPress-Plugin kann keine Audioverarbeitung machen. Shared Hosting hat weder die Rechenzeit noch die nötigen Bibliotheken, und eine HTTP-Anfrage darf nicht minutenlang offen bleiben. Also ist das Plugin nur der Client, und die Arbeit passiert woanders:

Eine FastAPI-Schicht nimmt den Upload entgegen, prüft API-Schlüssel und Kontingent und legt die Datei in einem S3-kompatiblen Objektspeicher ab. Ein ClamAV-Dienst scannt sie, bevor sie irgendetwas anderes anfasst — es sind fremde Dateien aus fremden WordPress-Installationen. Die eigentliche Analyse und Reparatur läuft asynchron in einem Celery-Worker mit FFmpeg. Postgres hält Schlüssel, Kontingente und Sitzungsdaten, Redis ist Queue und Cache, Traefik terminiert TLS.

Das ist keine Architektur, die man sich für ein Nebenprojekt wünscht. Sie ergibt sich aus der Anforderung, und genau deshalb steht sie hier: Jeder dieser Dienste löst ein konkretes Problem, keiner ist Selbstzweck.

Das eigentliche Gate war WordPress.org

Der Teil, der am meisten über die Arbeit aussagt, ist nicht die Audio-Pipeline, sondern die Aufnahme ins offizielle Plugin-Verzeichnis. Dort prüft ein Review-Team, das man nicht kennt, den Code auf Sicherheitslücken, korrektes Escaping jeder Ausgabe, Berechtigungsprüfungen und Internationalisierung.

Das Review hat Dinge gefunden, die ich selbst nicht gesehen hatte — und die Vorbereitung darauf hat weitere zutage gefördert. Im Changelog stehen sie namentlich: eine Berechtigungsprüfung, die nur die Upload-Rechte der Website prüfte statt der Bearbeitbarkeit des konkreten Beitrags; Backend-Nachrichten, die ungeprüft in die Seite geschrieben wurden; API-Schlüssel und Webhook-Token, die als Klartext-Eingabefelder im Formular standen und damit auf jedem Screenshot und in jeder Bildschirmfreigabe mitliefen.

Diese Einträge stehen öffentlich im Changelog, weil das der Sinn eines Changelogs ist. Wer eine Sicherheitslücke still behebt, nimmt seinen Nutzern die Möglichkeit zu beurteilen, ob sie betroffen waren.

Was 36 Versionen bedeuten

Ausgeliefert wird über dasselbe Verzeichnis, über das WordPress alle Updates verteilt. Das heißt: Jede Version geht an bestehende Installationen, und eine kaputte Version bricht fremde Websites.

Genau das ist einmal passiert. In Version 1.0.27 kam bei einer Aufräumaktion ein Funktionsaufruf mit fehlendem Argument in den Code, der bei jeder Installation mit konfiguriertem Webhook das gesamte WordPress-Backend zum Absturz brachte. Gefunden wurde er erst zwei Versionen später. Der Changelog-Eintrag dazu nennt die betroffenen Versionen, den auslösenden Commit und die Empfehlung, sofort zu aktualisieren.

Nicht schön, aber der ehrliche Umgang damit ist der Punkt. Wer 36 Versionen ausliefert, produziert irgendwann eine schlechte. Was zählt, ist, ob die Nutzer erfahren, was los war.

Was hier nicht steht

Nutzerzahlen. Das Verzeichnis weist derzeit weniger als zehn aktive Installationen aus, und das ist kein Verkaufsargument — es wäre unredlich, es zu einem zu machen. Was dieses Projekt belegt, ist etwas anderes: dass ein vollständiger Dienst mit Queue, Objektspeicher, Virenscanner und Abrechnung von einer Person gebaut, durch ein fremdes Review gebracht und über Monate gepflegt werden kann.