Ein Ein-Personen-Produkt durch die Prüfung von WordPress.org bringen

Das Problem war der Umweg, nicht die Prüfung

Die Lautstärke einer Aufnahme zu prüfen, ist kein neues Problem. Dafür gibt es seit Jahren Programme. Ungelöst war der Weg dorthin. Wer eine Podcast-Folge in WordPress hochlädt, müsste sie wieder herunterladen, in einem Tonprogramm öffnen, prüfen, korrigieren, speichern und neu hochladen. Bei einer Folge pro Woche lässt man das irgendwann einfach weg.

Ich habe deshalb keine bessere Prüfung gebaut. Ich habe die vorhandene Prüfung dorthin gebracht, wo die Datei ohnehin liegt.

Warum im Hintergrund acht Programmteile laufen

Eine WordPress-Erweiterung kann selbst keinen Ton verarbeiten. Dafür fehlt auf den meisten Websites die Rechenleistung, und eine Website darf nicht minutenlang auf eine Antwort warten. Die Erweiterung ist deshalb nur der Schalter. Die Arbeit passiert auf einem eigenen Rechner.

Dort wird jede Datei zuerst entgegengenommen und gespeichert. Dann prüft ein Virenscanner sie, denn es sind fremde Dateien von fremden Websites. Erst danach wird sie untersucht und repariert. Das läuft im Hintergrund, damit niemand warten muss.

Für Kenner: die acht Dienste

Eine FastAPI-Schicht nimmt den Upload entgegen, prüft API-Schlüssel und Kontingent und legt die Datei in einem S3-kompatiblen Objektspeicher ab. ClamAV scannt sie. Analyse und Reparatur laufen asynchron in einem Celery-Worker mit FFmpeg. Postgres hält Schlüssel, Kontingente und Sitzungsdaten, Redis ist Queue und Cache, Traefik terminiert TLS.

Für ein Nebenprojekt wünscht man sich so viel Technik nicht. Sie ergibt sich aus der Aufgabe. Jeder dieser Teile löst ein bestimmtes Problem, keiner ist zum Spaß da.

Die eigentliche Hürde war WordPress.org

Am meisten über die Arbeit sagt nicht die Tonverarbeitung. Es ist die Aufnahme ins offizielle Verzeichnis von WordPress. Dort prüft ein Team, das man nicht kennt, das ganze Programm. Es sucht nach Sicherheitslücken und schaut, wer was darf.

Die Prüfer haben Dinge gefunden, die ich selbst nicht gesehen hatte. Die Vorbereitung darauf hat weitere ans Licht gebracht. Sie stehen mit Namen in der öffentlichen Versionsliste. Eine Prüfung schaute nur, ob jemand etwas hochladen darf, aber nicht, ob er den einzelnen Beitrag bearbeiten darf. Meldungen des Dienstes wurden ungeprüft in die Seite geschrieben. Und Zugangsschlüssel standen lesbar im Formular. Sie wären also auf jedem Bildschirmfoto zu sehen gewesen.

Diese Einträge sind öffentlich, weil eine Versionsliste dafür da ist. Wer eine Sicherheitslücke still behebt, nimmt seinen Nutzern die Möglichkeit zu beurteilen, ob sie betroffen waren.

Was 36 Versionen bedeuten

Neue Versionen kommen über dasselbe Verzeichnis, über das WordPress alle Aktualisierungen verteilt. Jede Version landet also auf Websites, die schon laufen. Eine kaputte Version macht fremde Websites kaputt.

Genau das ist einmal passiert. In Version 1.0.27 kam beim Aufräumen ein Fehler ins Programm. Bei allen, die eine bestimmte Benachrichtigung eingerichtet hatten, ließ er den ganzen Verwaltungsbereich von WordPress abstürzen. Gefunden habe ich ihn erst zwei Versionen später. Der Eintrag dazu nennt die betroffenen Versionen und die Ursache. Er empfiehlt, sofort zu aktualisieren.

Schön ist das nicht. Aber auf den ehrlichen Umgang damit kommt es an. Wer 36 Versionen herausgibt, liefert irgendwann eine schlechte. Entscheidend ist, ob die Nutzer erfahren, was los war.

Was hier nicht steht

Nutzerzahlen. Das Verzeichnis nennt derzeit weniger als zehn aktive Installationen. Das ist kein Verkaufsargument, und ich mache auch keines daraus. Dieses Projekt zeigt etwas anderes: Eine Person kann einen vollständigen Dienst mit Virenscanner und Abrechnung bauen, durch eine fremde Prüfung bringen und über Monate pflegen.