Zum Inhalt

Qualität prüfen

Der Sammellauf

npm run check

Das ist der Befehl vor jedem Commit. Er läuft statisch, braucht also keine laufende WordPress-Instanz, und endet mit Exit-Code 1, sobald etwas fällt — damit er in einer Pipeline verwendbar ist.

Jede Prüfung darin steht für einen Fehler, der schon einmal passiert ist. Der Schwerpunkt liegt auf den Fehlerklassen, die entstehen, wenn Code zwischen Kern und Modulen verschoben wird.

Was geprüft wird

Prüfung Fängt ab
Build Der Build läuft ohne Fehler durch
Audits audit:modules und audit:editor-assets
PHP-Syntax php -l über alle PHP-Dateien unter includes/
Modulübergreifende Aufrufe Aufrufe über Modulgrenzen ohne function_exists()
SCSS-Importrichtung Feature-Stylesheets, die doch im Haupt-Bundle landen
block.json-Pfade Verweise in block.json-Dateien, die ins Leere zeigen
Release-Zuschnitt Ob das Paket vollständig und richtig geschnitten ist

Die vierte Prüfung ist die wichtigste. Da Module zur Laufzeit abschaltbar sind, ist ein ungeschützter Aufruf über Modulgrenzen ein Fatal Error auf jeder Installation, die das andere Modul nicht aktiviert hat. Der Prüflauf findet das, bevor es ein Kunde findet.

Mit laufender Instanz

npm run check:wp

Zusätzlich zu allem oben wird eine WordPress-Instanz kalt gestartet und geprüft, ob dabei Fehler auftreten. Das setzt eine laufende Umgebung voraus — siehe Entwicklungsumgebung.

Dieser Lauf gehört vor jedes Release und nach jedem Umbau, der Module berührt.

Die beiden Audits einzeln

npm run audit:modules
npm run audit:editor-assets

audit:modules

Findet Reste und Lücken in der Modulstruktur:

  • Build-Quellen, die in einer module.json stehen, aber nicht existieren
  • Module ohne Inhalt
  • fehlende Pfade

audit:editor-assets

Findet Assets, die im Editor gemeint waren und im Frontend landen:

  • "script" in einer block.json — das lädt im Editor und im Frontend
  • editor.css oder *-editor.css unter "style"
  • enqueue_block_assets ohne den Guard wp_should_load_block_editor_scripts_and_styles()

Diese Fehlerklasse fällt beim Entwickeln nicht auf, weil im Editor alles richtig aussieht. Sichtbar wird sie erst als unnötiges CSS im Frontend.

Die Regeln dazu stehen unter Modul-Vertrag.

Vor dem Commit

Ein Git-Hook nimmt einen Teil der Arbeit ab. Einmalig einhängen:

npm run hooks:install

Der Hook packt nach jedem Commit die Release-Pakete und hebt die Versionen an. Er läuft im Hintergrund und protokolliert nach .git/twtheme-release.log.

Überspringen:

TWTHEME_SKIP_RELEASE=1 git commit -m "…"

Siehe Release-Pakete.

Barrierefreiheit

Im Theme-Repository liegt unter docs/A11Y-AUDIT-CHECKLIST.md eine Prüfliste. Sie ist ein Arbeitsdokument und bleibt dort, weil sie zum Entwicklungsstand gehört und nicht zur Anwenderdokumentation.

Was Anwender einstellen können, steht unter Barrierefreiheit.

Für das Megamenü sind bestimmte Interaktionen verbindlich — Tastaturbedienung, Escape, Klick außerhalb, Fokusverwaltung. Sie stehen unter CSS-Architektur.

Blöcke im Blick behalten

Unter docs/BLOCK-REVIEW-MATRIX.md im Theme-Repository steht, welche Blöcke geprüft wurden und wo etwas offen ist. Ebenfalls ein Arbeitsdokument.

Reihenfolge im Alltag

Wann Was
Beim Entwickeln npm run watch:css oder watch:js
Vor dem Commit npm run check
Nach Umbauten an Modulen npm run check:wp
Vor einem Release npm run check:wp und ein Blick in die Pakete

Weiter