141 Tests, 31 Compliance-Prüfungen, null Abkürzungen: So liefern wir Statnive aus

Bevor Sie ein Plugin installieren, vertrauen Sie fremdem Code

Jedes WordPress-Plugin, das Sie aktivieren, erhält vollen Zugriff auf Ihre Datenbank, Ihr Admin-Panel und die Daten Ihrer Besucher. Die meisten Plugin-Seiten zeigen eine Sternbewertung und ein „Zuletzt aktualisiert”-Datum. Das reicht nicht aus, um eine Vertrauensentscheidung zu treffen.

Wir haben Statnive als das Analytics-Plugin entwickelt, dem wir selbst auf unseren eigenen Websites vertrauen würden. Dieser Beitrag führt durch die genaue Qualitätspipeline, die jede Codezeile von Statnive durchläuft, bevor sie Ihre WordPress-Installation erreicht. Keine vagen Behauptungen — spezifische Prüfungen, echte Zahlen und ehrliche Vorbehalte darüber, was automatisierte Tests erfassen können und was nicht.

Die Kernzahlen: 141 PHP-Unit-Tests, 31 WordPress.org-Compliance-Abschnitte, 10 spezialisierte CI-Gates, 3 PHP-Versionsziele und ein 5-KB-Tracker-Größenbudget, das bei jedem einzelnen Build durchgesetzt wird.

Schicht 1: Der Pre-Commit-Hook — nichts gelangt unkontrolliert ins Repository

Bevor Code unser Git-Repository betritt, führt ein Pre-Commit-Hook zwei Prüfungen bei jeder gestagten Datei aus:

Für PHP-Änderungen:

PHPCS (PHP CodeSniffer) validiert gestagte Dateien gegen die WordPress Coding Standards — dasselbe Regelwerk, das WordPress Core verwendet. Dies erkennt unsichere Output-Escapierung, fehlende Sanitisierung und nicht standardmäßige Code-Muster.
PHPUnit führt die vollständige Unit-Test-Suite aus. Alle 141 Tests müssen bestehen. Ein einzelnes Scheitern blockiert den Commit.

Für TypeScript/JavaScript-Änderungen:

Vitest führt alle React-Component-Tests aus. Die Dashboard-UI kann nicht regressieren, ohne hier aufgefangen zu werden.

Der Pre-Commit-Hook ist absichtlich schnell — er läuft in unter 5 Sekunden auf einer Entwicklermaschine. Das Ziel ist nicht, CI zu ersetzen, sondern die häufigsten Fehler abzufangen, bevor sie einen Round-Trip zu GitHub verschwenden. In der Praxis fängt dieses einzelne Gate etwa 80 % der Probleme ab, bevor sie jemals das Laptop des Entwicklers verlassen.

Schicht 2: Continuous Integration — 6 parallele Jobs bei jedem Push

Jeder Push auf unseren Entwicklungs- oder Main-Branch und jeder Pull Request löst eine GitHub Actions CI-Pipeline mit 6 parallelen Jobs aus:

Job	Was geprüft wird	Warum es wichtig ist
Lint (PHP 8.2, 8.3, 8.4)	PHPCS + PHPStan Level 6	Coding Standards und statische Typsicherheit über 3 PHP-Versionen
Unit Tests (PHP 8.2, 8.3, 8.4)	PHPUnit-Suite	Logikkorrektheit über 3 PHP-Versionen
Minimum Floor Smoke (PHP 8.0)	Syntax-Lint + Autoloader-Boot	Beweist, dass das Plugin auf der deklarierten minimalen PHP-Version lädt
Tracker Build	Vite-Build + gzip-Größenprüfung	Durchsetzt das 5-KB-gzipped-Budget für den Analytics-Tracker

Warum 4 PHP-Versionen?

WordPress-Websites laufen in der realen Welt auf PHP 8.0 bis 8.4. Eine Funktion, die auf PHP 8.4 funktioniert, könnte sich auf PHP 8.0 anders verhalten — Standard-Parameterwerte, Typkoerzionsregeln und veraltete Features variieren zwischen Versionen. Wir testen auf den drei Versionen, auf denen unsere vollständige Test-Suite läuft (8.2, 8.3, 8.4) und verifizieren separat, dass der Produktionscode zumindest auf PHP 8.0 — dem deklarierten Minimum in unserem Plugin-Header — parsed und startet.

Das 5-KB-Tracker-Budget

Der JavaScript-Tracker, der Seitenaufrufe auf Ihrer Website erfasst, hat ein hartes Größenlimit: 5.120 Bytes gzipped. Jeder Build misst den Output und schlägt fehl, wenn der Tracker dieses Budget überschreitet. Das ist nicht willkürlich — unser Performance-Benchmark zeigte, dass die Tracker-Größe direkt mit dem LCP-Impact korreliert. Das Budget zwingt uns, den kritischen Pfad minimal zu halten und nicht-wesentliche Features auf ein asynchrones Sekundärskript zu verschieben.

# Aus unserem CI-Workflow — die Tracker-Größenprüfung
- name: Verify tracker size
  run: |
    MAX_SIZE=5120  # 5KB in bytes
    GZIP_SIZE=$(gzip -c public/tracker/statnive.js | wc -c)
    if [ "$GZIP_SIZE" -gt "$MAX_SIZE" ]; then
      echo "::error::Tracker size (${GZIP_SIZE}B) exceeds limit (${MAX_SIZE}B)"
      exit 1
    fi

PHPStan auf Level 6

PHPStan ist ein statisches Analysetool, das Bugs findet, ohne den Code auszuführen. Level 6 (von 10) erkennt Typ-Mismatches, undefinierte Variablen, falsche Rückgabetypen und tote Code-Pfade. Wir führen es mit der phpstan-wordpress-Erweiterung aus, die WordPress-Hook-Signaturen, Filter-Rückgabetypen und $wpdb-Methoden-Contracts versteht. Kombiniert mit der $wpdb->prepare()-Durchsetzung ist dies unsere primäre Verteidigung gegen SQL-Injection — der statische Analyser markiert jede Abfrage, die Benutzereingaben verkettet, anstatt Prepared Statements zu verwenden.

Schicht 3: WordPress.org Compliance — 10 spezialisierte Gates

Hier weicht Statnives Qualitätspipeline von den meisten WordPress-Plugins ab. Über Standard-Linting und -Testing hinaus führen wir 10 eigens entwickelte Compliance-Gates aus, die WordPress.org-Plugin-Richtlinien durchsetzen — dieselben Regeln, die das Review-Team manuell bei der Einreichung prüft.

Die meisten Plugin-Entwickler entdecken diese Regeln, wenn ihre Einreichung abgelehnt wird. Wir haben sie automatisiert, damit Verstöße bei jedem Commit erkannt werden:

Sicherheits-Gates

ABSPATH-Wächter — Jede PHP-Datei muss defined('ABSPATH') prüfen, bevor sie ausgeführt wird. Dies verhindert den direkten Zugriff auf Plugin-Dateien über URL, was Serverpfade preisgeben oder Code außerhalb des WordPress-Kontexts ausführen könnte. Unser Gate scannt jede .php-Datei im Quellbaum und schlägt fehl, wenn eine Datei den Wächter vermisst.

Verbotene Muster — Ein automatisierter Scan blockiert gefährliche PHP-Funktionen, die WordPress.org explizit ablehnt: eval(), exec(), shell_exec(), system(), passthru() und curl_init(). Es erkennt auch PHP-Short-Tags, rohes json_encode() (muss wp_json_encode() verwenden) und hartcodierte wp-content-Pfade.

WP-API-Compliance — Prüft, dass alle Skripte und Stylesheets das Enqueue-System von WordPress verwenden, anstatt hartcodierte <script>- oder <link>-Tags. Scannt auch auf nicht sanitisierten Superglobal-Zugriff ($_GET, $_POST, $_REQUEST) — einer der häufigsten Ablehnungsgründe bei WordPress.org.

Integritäts-Gates

Readme & Versionskonsistenz — Die Plugin-Version muss an drei Stellen übereinstimmen: readme.txt Stable Tag, statnive.php-Header und die STATNIVE_VERSION-PHP-Konstante. Ein Mismatch bedeutet, dass WordPress die falsche Versionsnummer anzeigen würde — verwirrend für Benutzer und ein Warnsignal für Reviewer. Dieses Gate validiert auch die Tag-Anzahl (max. 5), die Länge der Kurzbeschreibung (max. 150 Zeichen), das Vorhandensein der LICENSE-Datei und den External Services-Disclosure-Abschnitt.

Distribution-ZIP-Validierung — Erstellt die eigentliche ZIP-Datei, die zu WordPress.org hochgeladen würde, und validiert dann ihren Inhalt. Erforderliche Dateien müssen vorhanden sein (statnive.php, readme.txt, LICENSE, src/Plugin.php, nicht-minifizierter Tracker-Quellcode). Verbotene Dateien müssen fehlen (node_modules/, .git/, composer.json, tests/, phpunit, Config-Dateien). ZIP-Größe muss unter 25 MB bleiben.

Header-Parität — Validiert, dass alle 11 erforderlichen Plugin-Header-Felder vorhanden und konsistent sind. Prüft, dass die Tested up to-WordPress-Version innerhalb von 2 Minor-Releases der aktuellen stabilen Version liegt — ein veralteter Wert signalisiert ein nicht gewartetes Plugin und kann das WordPress.org-Suchranking beeinflussen.

Architektur-Gates

Architektur-Blocker — Scannt nach Mustern, die auf Richtlinienverstöße hinweisen: Phone-Home-HTTP-Aufrufe in Aktivierungshooks (Benutzer sollten beim Aktivieren eines Plugins keine Netzwerkanfragen sehen), benutzerdefinierte Auto-Updater-Hooks (WordPress.org übernimmt Updates) und gebündelte MaxMind-GeoIP-Datenbanken (Benutzer müssen ihren eigenen Lizenzschlüssel bereitstellen).

Freemium-Grenze — Die kostenlose WordPress.org-Version darf keinen Lizenzierungs-Code enthalten. Dieses Gate scannt nach Mustern wie isPro(), checkLicense(), trial_expires und premium_only — um sicherzustellen, dass der .org-Build wirklich kostenlos ist, nicht eine eingeschränkte Testversion.

External Services Audit — Extrahiert jede https://-Domain, die im PHP-Quellcode referenziert wird, und verifiziert dann, dass jede im External Services-Abschnitt von readme.txt dokumentiert ist. Jede undokumentierte externe Verbindung schlägt den Build fehl. So garantieren wir Transparenz darüber, wohin Ihre Daten fließen.

Statnive holen: Code, dem Sie vertrauen können

Jede in diesem Beitrag beschriebene Prüfung läuft automatisch bei jeder Änderung. Kein Mensch muss daran denken, den Sicherheits-Scan auszuführen oder die Versionskonsistenz zu prüfen — die Pipeline durchsetzt es. Statnive von WordPress.org installieren und das Ergebnis sehen: schnelle, datenschutzfreundliche Analytics auf Ihrem eigenen Server.

Schicht 4: WordPress Plugin Check — strenger als erforderlich

Der Plugin Check (PCP) ist ein offizielles Tool des WordPress.org-Teams, das dieselben automatisierten Prüfungen ausführt, die das Review-Team verwendet. Die meisten Plugins konfigurieren PCP so, dass nur bei Fehlern ein Scheitern ausgelöst wird.

Statnive schlägt sowohl bei Fehlern ALS AUCH bei Warnungen fehl.

Das ist eine bewusste Entscheidung. PCP-Warnungen markieren oft legitime Probleme — veraltete Funktionsnutzung, Barrierefreiheitslücken, Performance-Bedenken — die zwar keine Einreichung blockieren, aber die Plugin-Qualität mit der Zeit verschlechtern. Indem wir Warnungen als Fehler behandeln, fangen wir Probleme ab, mit denen andere Plugins ausgeliefert werden.

Das PCP-Gate läuft auf dem gebauten Distribution-Verzeichnis (nicht dem Quellbaum), mit PHP 8.0 — dem deklarierten Minimum. Das bedeutet, wir testen genau das, was Benutzer installieren würden, auf der ältesten PHP-Version, die wir unterstützen.

Schicht 5: Das Release-Gate — 31 Abschnitte vor jedem ausgelieferten Release

Vor einem Release kombiniert das vollständige Gate alles oben Genannte in einer einzigen Pass-or-Fail-Entscheidung:

Statische Test-Gates (müssen alle bestehen):

Gate	Prüfung	Tool
S-1	WordPress Coding Standards	PHPCS
S-2	Statische Typenanalyse	PHPStan Level 6
S-3	PHP Unit + Integration Tests	PHPUnit
S-4	React-Component-Tests	Vitest
S-5	Offizieller Plugin Check	PCP (Fehler + Warnungen)

Compliance-Grep-Gates (17 automatisierte Musterprüfungen):

Gates	Was sie durchsetzen
C-1	ABSPATH-Wächter in jeder PHP-Datei
C-2	Lizenz-Datei-Validierung
C-3, C-4	Kein Phone-Home bei Aktivierung, keine versteckten Paywalls
C-5	Readme-Struktur, Versionsparität, External Services Disclosure
C-6	Kein unsanitisierter Superglobal-Zugriff
C-7	Keine gebündelten GeoIP-Datenbanken
C-8, C-9, C-10	Kein benutzerdefinierter Updater, keine gebündelten Core-Bibliotheken, kein externes CDN
C-11, C-12	Cron-Bereinigung bei Deaktivierung, Uninstall-Funktion vorhanden
C-13	SVN-Assets-Verzeichnisstruktur
C-14	ZIP-Integrität und -Größe
C-15	Datenbanktabellenerstellung folgt dbDelta-Format
C-16	Alle benutzersichtbaren Strings sind internationalisiert
C-17	WordPress Privacy API Hooks registriert

Über die automatisierten Gates hinaus umfasst jedes Release eine manuelle Überprüfung mit Performance-Budgets, Browser-Kompatibilität, Barrierefreiheit (WCAG 2.2 AA), Admin-UX-Klarheit, Upgrade/Migrations-Sicherheit und Fehlerbehandlung. Die vollständige Checkliste umfasst 31 Abschnitte in 3 Schweregradebenen:

KRITISCH — automatisierte Gates, die die Release-Pipeline blockieren
RELEASE-BLOCKER — manuelle Prüfungen, die vor dem Tagging einer Version bestanden werden müssen
QUALITÄTS-GATE — Standards, die wir uns setzen, überprüft, aber beratend

Sicherheit und Datenschutz: Von der Pipeline verifiziert, nicht nur versprochen

Viele Analytics-Plugins listen Sicherheits- und Datenschutz-Features auf ihrer Marketing-Seite auf. Wir zeigen lieber, wie diese Versprechen mechanisch durchgesetzt werden:

Alle SQL-Abfragen verwenden Prepared Statements. PHPStans WordPress-Erweiterung markiert jeden $wpdb-Methodenaufruf, der Benutzereingaben verkettet, anstatt $wpdb->prepare() zu verwenden. Dies wird zum Zeitpunkt der statischen Analyse erfasst — bevor der Code jemals ausgeführt wird.

Keine Cookies, kein localStorage, kein Fingerprinting. Die Compliance-Gates scannen nach Cookie-setzenden Funktionen und Browser-Storage-APIs. Die Unit-Test-Suite verifiziert, dass die Tracker-Payload nur gehashte, nicht umkehrbare Besucher-Identifikatoren enthält.

Täglich rotierende Salts. Derselbe Besucher erzeugt täglich einen anderen Hash, was tagesübergreifendes Tracking verhindert. Dies wird durch dedizierte Unit-Tests abgedeckt, die die Hash-Einzigartigkeit über Salt-Rotationen hinweg verifizieren.

HMAC-Signaturen auf Tracker-Payloads. Jeder Seitenaufruf-Hit ist mit einem serverseitig generierten Schlüssel signiert. Die Signaturverifizierung wird in der Unit-Suite getestet — ungültige oder manipulierte Payloads werden abgelehnt.

External Service Transparenz. Das CI-Gate extrahiert jede externe Domain aus dem Quellcode und verifiziert, dass sie in der readme.txt-Disclosure erscheint. Wenn ein Entwickler einen HTTP-Aufruf zu einer neuen Domain hinzufügt, schlägt der Build fehl, bis die Domain dokumentiert ist.

Was automatisierte Tests nicht erfassen können

Wir glauben an Transparenz über Einschränkungen, nicht nur über Fähigkeiten.

Automatisierte Tests verifizieren, dass Code unter bekannten Bedingungen korrekt funktioniert. Sie können nicht erfassen:

Subtile UX-Verwirrung — ein Dashboard-Diagramm, das technisch korrekt, aber für nicht-technische Benutzer irreführend ist
Performance-Grenzfälle — eine Abfrage, die mit 1.000 Zeilen schnell ist, aber bei 100.000 degradiert. Wir haben k6-Load-Tests für kritische Pfade, aber sie können nicht jede Datenform abdecken
WordPress-Ökosystem-Konflikte — Plugin- oder Theme-Interaktionen, die nur auf spezifischen Hosting-Konfigurationen auftauchen. Wir testen gegen WP 6.4 bis trunk, aber das WordPress-Ökosystem hat 60.000+ Plugins
Zero-Day-Schwachstellen — keine Menge statischer Analyse verhindert die Ausnutzung zuvor unbekannter Angriffsvektoren

Wir mindern diese Lücken durch manuelle Überprüfung bei jedem Release, ein öffentliches GitHub-Repository, wo jeder den Code prüfen kann, und aktives Monitoring der WordPress.org-Support-Foren auf Meldungen aus realen Installationen.

Warum wir das veröffentlicht haben

Forschung zeigt, dass über 50 % der WordPress-Plugin-Entwickler gemeldete Schwachstellen nicht vor der öffentlichen Offenlegung patchen. Plugins gehen jahrelang ohne Updates. Benutzer haben keine Möglichkeit, ein gut gewartetes Plugin von einem aufgegebenen zu unterscheiden, außer an Sternbewertungen und „Zuletzt aktualisiert”-Daten.

Wir glauben, das WordPress-Ökosystem verdient bessere Signale. Die Veröffentlichung unserer Qualitätspipeline ist eine Möglichkeit, die Messlatte zu erhöhen — sowohl für uns selbst (jetzt, da sie öffentlich ist, können wir Prüfungen nicht still überspringen) als auch für das Ökosystem (andere Plugin-Entwickler können ähnliche Praktiken übernehmen).

Wenn Sie Analytics-Plugins für Ihre WordPress-Website evaluieren, ermutigen wir Sie, jeden Kandidaten zu fragen: Wie testen Sie? Welche Prüfungen laufen vor einem Release? Kann ich die CI-Konfiguration sehen?

Statnives gesamte Codebasis ist Open Source auf GitHub. Jede Workflow-Datei, jeder Test, jedes in diesem Beitrag beschriebene Compliance-Gate ist öffentlich prüfbar.

Statnive ausprobieren

Diese gesamte Entwicklung dient einem Ziel: Ihnen Analytics zu geben, dem Sie auf Ihrem eigenen WordPress-Server vertrauen können. Keine Drittanbieter-Datenübertragungen, keine Cookies, keine Tracking-Skripte, die Ihre Website verlangsamen.

Statnive kostenlos von WordPress.org installieren — Ihre Daten bleiben auf Ihrem Server, verifiziert durch 141 Tests und 31 Compliance-Prüfungen bei jedem Release.