wp easy-svg icons validate

WP-CLI-Befehl · Easy SVG Pro · Status: Stabil

Dieser Befehl ist ein Probelauf. Er liest jedes SVG in einem Ordner, schickt es durch genau den Sanitizer und Härter, den ein Import auf dieser Seite verwenden würde, und sagt dir pro Datei, ob sie behalten würde. Es wird nichts geschrieben und nichts registriert. Mit --strict scheitert er, sobald auch nur eine Datei übersprungen würde. So wird daraus eine Qualitätsschranke für dein Icon-Repository.

Verwendung

wp easy-svg icons validate <dir> [--strict]

Wann du es brauchst

• Bevor du Icons von einer Designerin in den Ordner assets/icons eines Themes oder in einen Drop-in-Ordner committest.
• In der CI bei jedem Pull Request, der Icons ändert, damit eine Datei, die die Seite ablehnen würde, nie in Produktion landet.
• Vor wp easy-svg icons import, um zu sehen, was kopiert und was übersprungen würde.
• Nachdem du die Allow-Liste im Konfigurator erweitert oder verkleinert hast, um zu sehen, welche Icons auf dieser Seite betroffen sind.

Ein ZIP-Paket prüfst du damit nicht. Der Befehl liest nur einzelne .svg-Dateien in einem Ordner. Importier das Paket lieber auf einer Staging-Seite mit wp easy-svg pack import.

Parameter

Rückgabewert

Standardwert

Ohne --strict meldet der Befehl nur und endet immer mit 0, sobald er gelaufen ist.

Beispiele

Einen Ordner von Hand prüfen

wp easy-svg icons validate ./wp-content/themes/acme/assets/icons

+----------------------+----------+---------+------------+
| file                 | slug     | status  | reason     |
+----------------------+----------+---------+------------+
| .../icons/phone.svg  | phone    | ok      |            |
| .../icons/Phone.svg  | phone    | skipped | duplicate  |
| .../icons/empty.svg  | empty    | skipped | no-drawing |
+----------------------+----------+---------+------------+

Einen Pull Request in der CI absichern

#!/usr/bin/env bash
set -euo pipefail

ICONS_DIR="wp-content/themes/acme/assets/icons"

# Ein falscher Pfad würde still durchgehen, also sicherstellen, dass es etwas zu prüfen gibt.
count=$(find "$ICONS_DIR" -maxdepth 1 -name '*.svg' | wc -l)
if [ "$count" -eq 0 ]; then
	echo "Keine SVG-Dateien in $ICONS_DIR gefunden" >&2
	exit 1
fi

wp easy-svg icons validate "$ICONS_DIR" --strict

Jeden Unterordner eines Icon-Repositorys prüfen

Der Befehl arbeitet nicht rekursiv, also läufst du selbst über die Ordner und sammelst das Ergebnis:

status=0
for dir in icons/*/; do
	echo "== $dir"
	wp easy-svg icons validate "$dir" --strict || status=1
done
exit $status

Defensiv: kaputtes Setup von schlechtem Icon unterscheiden

if ! wp plugin is-active easy-svg; then
	echo "Easy SVG Support ist nicht aktiv, es kann nichts geprüft werden." >&2
	exit 2
fi
wp easy-svg icons validate ./icons --strict

So funktioniert es

1. Die Prüfung stellt sicher, dass die Lizenz aktiv und die Funktion WP-CLI an ist. Ein Benutzer oder eine Berechtigung ist nicht nötig.
2. Der Befehl holt sich den Sanitizer der Seite aus Easy SVG Support und prüft, ob easy_svg_harden_icon_markup() existiert. Fehlt eins davon, bricht er ab, weil ein Ergebnis aus einer schwächeren Prüfung nicht dem entspräche, was ein Import speichert.
3. Er listet <dir>/*.svg und behandelt jede Datei in dieser Reihenfolge:
   • Der Slug ist der Dateiname ohne .svg, kleingeschrieben, jede Folge anderer Zeichen wird zu -. Ergibt der Name keinen gültigen Slug, lautet der Grund bad-name.
   • Eine zweite Datei mit demselben Slug (Phone.svg und phone.svg) ist duplicate. Die erste gewinnt.
   • Eine leere oder nicht lesbare Datei ist unreadable.
   • Lehnt der Sanitizer sie ab: not-svg.
   • Bleibt nach dem Härten kein <svg> mit mindestens einem Kindelement übrig: no-drawing.
4. Die Tabelle wird ausgegeben. Mit --strict bricht der Befehl danach bei der ersten Zeile ab, die nicht ok ist.

Geprüft wird mit der Allow-Liste dieser Seite, einschließlich der Tags und Attribute, die über den Konfigurator oder den Filter esw_svg_allowed_tags dazukamen. Derselbe Ordner kann also auf einer Seite durchgehen und auf einer anderen scheitern.

Stolperfallen

• Ein falscher Pfad geht durch. Ein Ordner, den es nicht gibt oder der keine .svg-Dateien enthält, ergibt eine leere Tabelle und Exit-Code 0, auch mit --strict. Prüf, ob der Ordner Dateien hat, bevor du einem grünen CI-Lauf traust.
• Nicht rekursiv. Dateien in Unterordnern werden nicht geprüft. Lauf selbst über die Unterordner.
• Keine Größenprüfung. Dateien werden nicht gegen easy_svg_pro_source_file_max_bytes (2 MB) gemessen. Eine Datei, die hier durchgeht, kann als Quellordner trotzdem als too-large abgelehnt werden.
• Das Manifest wird ignoriert. manifest.json wird nicht gelesen. Namen kommen nur aus den Dateinamen, eine vom Manifest umbenannte Datei wird also unter ihrem Dateinamen geprüft, und ein kaputtes Manifest lässt die Prüfung nicht scheitern, obwohl der Ordner als Quelle nichts registrieren würde. Für Manifest-Fehler nimm wp easy-svg icons problems auf dem echten Ordner.
• Ohne --strict bleibt die CI grün. Der einfache Befehl endet immer mit 0, sobald er gelaufen ist.
• Großgeschriebene Endungen. Die Liste sucht genau nach *.svg, ICON.SVG wird auf einem Dateisystem mit Groß- und Kleinschreibung also nicht gelesen.

Siehe auch

• wp easy-svg icons import
• wp easy-svg icons problems
• easy_svg_pro_dangerous_tags
• Mit WP-CLI automatisieren