Testen, versionieren, veröffentlichen

Ein Plugin ist fertig, wenn es läuft – und bleibt es, wenn es auch nach dem zehnten Update noch läuft. Dafür braucht es mehr als einen Test im Browser: automatische Prüfungen, die bei jeder Änderung zeigen, ob etwas kaputtgegangen ist, klare Versionsnummern, die Nutzern sagen, was sich geändert hat, und einen geordneten Weg der Veröffentlichung. Diese Lektion schließt das Modul mit dem Handwerkszeug ab, das aus einem funktionierenden Plugin ein verlässliches Produkt macht.

1. Die Testpyramide

1<?php
2class BuchungTest extends WP_UnitTestCase {
3
4    public function test_ausgebuchter_termin_bekommt_hinweis() {
5        $id = self::factory()->post->create( [ 'post_type' => 'radwerk_termin', 'post_title' => 'Inspektion' ] );
6        update_post_meta( $id, 'ausgebucht', 1 );
7
8        $this->assertSame( 'Inspektion (ausgebucht)', get_the_title( $id ) );
9    }
10}

Tests laufen am bequemsten in wp-env: npm run env start fährt WordPress mit Testdatenbank hoch, und die Tests werden in dieser Umgebung ausgeführt. In einer Pipeline wie GitHub Actions laufen PHPCS, PHPStan und Tests automatisch bei jeder Änderung – für mehrere PHP- und WordPress-Versionen gleichzeitig.

2. Versionen vergeben

1## Aktuell: 2.3.1
2
3- Neu: Filter radwerk_mail_betreff
4- Behoben: Datumsformat in der Bestätigung
5- Keine Änderungen an bestehenden Hooks

3. Veröffentlichen

4. Ein Beispiel

Das Terminplugin des Fahrradladens läuft inzwischen auch bei drei befreundeten Werkstätten. Jede Änderung löst eine Pipeline aus, die PHPCS, PHPStan und 60 Tests unter PHP 8.1 bis 8.4 und den beiden letzten WordPress-Versionen ausführt. Ein privater Update-Server stellt neue Versionen bereit, die Werkstätten sehen Updates wie gewohnt im Backend. Als eine Änderung an einem Hook zwei Zusatz-Plugins gebrochen hätte, schlug ein Integrationstest an – die Änderung wurde auf Version 2.0 verschoben und vorher angekündigt.

Kompatibilität und Pflege nach dem Release

Mit der Veröffentlichung beginnt die Pflege. WordPress erscheint mehrmals im Jahr in neuen Versionen, PHP jährlich. Ein gepflegtes Plugin wird vor jeder WordPress-Version mit den Vorabversionen getestet – die Beta- und Release-Candidate-Phasen sind genau dafür gedacht – und die Angabe „Tested up to“ in der readme.txt aktualisiert. Veraltete Funktionen erkennt man an Hinweisen im Debug-Protokoll; sie sollten ersetzt werden, bevor sie entfernt werden. Für eigene Hooks und Funktionen gilt dasselbe in umgekehrter Richtung: Wer etwas entfernen möchte, markiert es zunächst mit _deprecated_function oder _deprecated_hook als veraltet und entfernt es erst in der nächsten Major-Version.

Sicherheitsmeldungen verdienen besondere Aufmerksamkeit. Eine Adresse für Meldungen – etwa in einer security.txt oder über ein Programm wie das von Patchstack oder Wordfence – sorgt dafür, dass Lücken zuerst bei Ihnen landen und nicht öffentlich. Korrekturen werden schnell als Patch veröffentlicht, im Changelog klar benannt und bei gravierenden Lücken im Verzeichnis zusätzlich an das Plugin-Team gemeldet, das automatische Updates auslösen kann. Ein Plugin, dessen Betreuung endet, sollte das offen sagen: Im Verzeichnis lässt es sich schließen oder an neue Betreuer übergeben.

Hilfreich ist auch ein Blick auf die Nutzung. Im Verzeichnis zeigt die Statistik, welche PHP- und WordPress-Versionen verbreitet sind. Die Mindestanforderungen sollten nicht höher sein als nötig, aber auch keine Versionen unterstützen, die seit Jahren keine Sicherheitsupdates mehr bekommen – das erschwert Tests und bindet unnötig Zeit.

5. Häufige Fragen

Lohnen sich Tests für ein kleines Plugin? Schon wenige Tests für die wichtigsten Abläufe sparen viel Zeit, weil sie Fehler vor dem Kunden finden. PHPCS mit den WordPress-Regeln sollte immer laufen – es findet nebenbei viele Sicherheitslücken.

Wie lange dauert die Prüfung im Verzeichnis? Das schwankt zwischen wenigen Tagen und einigen Wochen. Wer vorher Plugin Check laufen lässt und die Richtlinien beachtet, kommt deutlich schneller durch.

Was gehört in die readme.txt? Kurzbeschreibung, ausführliche Beschreibung, Installation, häufige Fragen, Changelog, getestete WordPress-Version (Tested up to) und die stabile Version. Sie ist die Produktseite im Verzeichnis.

6. Übung zum Selbermachen

Installieren Sie in Ihrer lokalen Umgebung PHPCS mit dem Regelwerk WordPress-Coding-Standards über Composer und lassen Sie es auf Ihr Übungsplugin los. Beheben Sie alle Meldungen zu Sicherheit (Escaping, Nonces, prepare) und notieren Sie, welche Sie übersehen hätten. Installieren Sie danach das Plugin Plugin Check in Playground, prüfen Sie Ihr Plugin und vergeben Sie für Ihre Korrekturen die passende Versionsnummer mit Eintrag im Changelog.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.