{"id":20855,"date":"2026-10-07T11:52:00","date_gmt":"2026-10-07T09:52:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=20855"},"modified":"2026-09-30T12:13:32","modified_gmt":"2026-09-30T10:13:32","slug":"plugin-check-lokal-und-ci","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/plugin-check-lokal-und-ci\/","title":{"rendered":"Plugin Check lokal und in der CI: Befunde vor dem Review"},"content":{"rendered":"

Jedes Plugin, das im Verzeichnis von WordPress.org eingereicht wird, durchl\u00e4uft zuerst einen automatischen Scan, erst danach liest jemand aus dem Plugins Team den Code. Ein Teil dessen, was im Review beanstandet wird, l\u00e4sst sich maschinell finden: ein fehlender Lizenz-Header, ungesch\u00fctzte Ausgaben, ein Skript von einem \u00f6ffentlichen CDN, eine Text Domain, die nicht zum Slug passt. Plugin Check, kurz PCP, ist das Werkzeug, das WordPress.org genau daf\u00fcr ver\u00f6ffentlicht. Laut Beschreibung f\u00fchrt es die meisten Pr\u00fcfungen aus, die auch bei neuen Einreichungen laufen, und zwar auf jeder WordPress-Installation, bevor irgendetwas hochgeladen wird.<\/p>\n

Dieser Beitrag zeigt Plugin Check 2.1.0 an drei Stellen: in der Oberfl\u00e4che im Backend, auf der Kommandozeile mit WP-CLI und in einem GitHub-Actions-Workflow mit der offiziellen Action. Als Pr\u00fcfobjekt dient ein kleines Plugin mit absichtlich eingebauten Fehlern. Zu jedem Fehler nennt der Text die Pr\u00fcfung und den Ergebniscode, den ein Lauf von Plugin Check 2.1.0 unter WordPress 7.1.2 meldet, und zeigt danach die korrigierte Fassung.<\/p>\n

Was Plugin Check pr\u00fcft<\/h2>\n

Aktuell im Verzeichnis ist Version 2.1.0 vom 16. August 2026. Vorausgesetzt werden WordPress 6.3 und PHP 7.4; die Plugin-Seite nennt \u201eTested up to\u201c 7.0.6, w\u00e4hrend die aktuelle WordPress-Version 7.1.2 lautet. Neu in 2.1.0 ist unter anderem eine Pr\u00fcfung auf \u00c4nderungen an der PHP-Fehlerausgabe zur Laufzeit.<\/p>\n

Im Quelltext von 2.1.0 registriert die Klasse Default_Check_Repository<\/code> 34 Pr\u00fcfungen. Jede tr\u00e4gt einen Slug wie late_escaping<\/code> und geh\u00f6rt zu einer oder mehreren Kategorien. Es gibt zwei Arten. Statische Pr\u00fcfungen lesen den Code, ohne ihn auszuf\u00fchren, meist \u00fcber PHP_CodeSniffer-Sniffs aus den WordPress Coding Standards oder aus dem eigenen Sniff-Satz von Plugin Check, teils \u00fcber eigene Logik. Laufzeitpr\u00fcfungen f\u00fchren das Plugin, das daf\u00fcr aktiviert sein muss, mit einem abgetrennten Satz Datenbanktabellen aus und beobachten, was es tut; in 2.1.0 sind das die f\u00fcnf Performance-Pr\u00fcfungen zu Reichweite und Gr\u00f6\u00dfe von Skripten und Stylesheets sowie zur Ladestrategie.<\/p>\n\n\n\n\n\n\n\n\n\n
Kategorie (Slug)<\/th>\nBeispiele f\u00fcr Pr\u00fcfungen in 2.1.0<\/th>\n<\/tr>\n<\/thead>\n
General (general<\/code>)<\/td>\ni18n_usage<\/code>, php_error_reporting<\/code>, ai_provider<\/code><\/td>\n<\/tr>\n
Plugin Repo (plugin_repo<\/code>)<\/td>\nplugin_readme<\/code>, plugin_header_fields<\/code>, file_type<\/code>, offloading_files<\/code>, setting_sanitization<\/code>, prefixing<\/code>, plugin_review_phpcs<\/code>, trademarks<\/code><\/td>\n<\/tr>\n
Security (security<\/code>)<\/td>\nlate_escaping<\/code>, direct_file_access<\/code>, safe_redirect<\/code>, direct_db_queries<\/code>, direct_db<\/code><\/td>\n<\/tr>\n
Performance (performance<\/code>)<\/td>\nenqueued_scripts_in_footer<\/code>, performant_wp_query_params<\/code>, enqueued_scripts_scope<\/code>, non_blocking_scripts<\/code><\/td>\n<\/tr>\n
Accessibility (accessibility<\/code>)<\/td>\nkeine: Die Kategorie ist definiert, aber keine mitgelieferte Pr\u00fcfung aus 2.1.0 ist ihr zugeordnet<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Alle in 2.1.0 registrierten Security-Pr\u00fcfungen tragen zus\u00e4tzlich die Kategorie plugin_repo<\/code>. Ein Lauf nur \u00fcber Plugin Repo deckt also Escaping und direkten Dateizugriff bereits ab. Das ist wichtig, weil die FAQ des Plugins festh\u00e4lt, dass ein Plugin f\u00fcr die Aufnahme ins Verzeichnis in der Regel alle Pr\u00fcfungen der Kategorie Plugin Repo bestehen muss. Die \u00fcbrigen Kategorien gelten als zus\u00e4tzlich.<\/p>\n

Jedes Ergebnis ist entweder ERROR<\/code> oder WARNING<\/code> und hat eine Schwere (Severity); Standard ist 5, eine fehlende Lizenz im Plugin-Header meldet die Pr\u00fcfung mit 9. Fehler stehen f\u00fcr Verst\u00f6\u00dfe gegen Anforderungen des Verzeichnisses. Warnungen markieren Code, der oft, aber nicht immer ein Problem ist: $_GET<\/code> ohne Nonce zu lesen ist bei einem harmlosen Anzeigeparameter unkritisch und in einem Formular-Handler eine echte L\u00fccke. Den Typ legt die jeweilige Pr\u00fcfung fest. Das PHPCS-Regelwerk von Plugin Check stuft einige Sniffs bewusst auf Warnungen herunter, etwa die Nonce-Pr\u00fcfung und die Bereinigung von Eingaben.<\/p>\n

Lokal ausf\u00fchren: Backend und WP-CLI<\/h2>\n

Plugin Check wird wie jedes andere Plugin installiert. Das README des Projekts r\u00e4t vom Einsatz auf Produktivseiten ab, weil Laufzeitpr\u00fcfungen das gepr\u00fcfte Plugin tats\u00e4chlich ausf\u00fchren. Nach der Aktivierung steht unter Werkzeuge \u2192 Plugin Check eine Seite bereit, die nur Nutzer mit dem Recht zur Plugin-Verwaltung sehen. Dort gibt es eine Plugin-Auswahl sowie Checkboxen f\u00fcr Kategorien und Ergebnistypen. Die Ergebnisse erscheinen je Datei mit Zeile, Spalte, Typ, Code und Meldung; seit Version 1.8.0 lassen sie sich als CSV, JSON oder Markdown exportieren.<\/p>\n

F\u00fcr wiederholte L\u00e4ufe ist der WP-CLI-Befehl praktischer. Als Argument akzeptiert er einen Plugin-Slug, einen Pfad oder die URL einer ZIP-Datei. Standardm\u00e4\u00dfig laufen nur statische Pr\u00fcfungen. F\u00fcr Laufzeitpr\u00fcfungen beschreibt das README einen Umweg: --require<\/code> l\u00e4dt die Datei cli.php<\/code> von Plugin Check, bevor WordPress startet. Au\u00dferdem muss das gepr\u00fcfte Plugin aktiv sein; bei einem inaktiven Plugin l\u00e4sst Plugin Check die Laufzeitpr\u00fcfungen ohne Hinweis weg, und --checks=enqueued_scripts_scope<\/code> endet dann mit \u201edoes not exist\u201c.<\/p>\n

# Install and activate Plugin Check (2.1.0 at the time of writing).\nwp plugin install plugin-check --activate\n\n# All static checks for wp-content\/plugins\/lw-hello-banner.\nwp plugin check lw-hello-banner\n\n# Include runtime checks (plugin must be active): load cli.php before WordPress boots.\nwp plugin check lw-hello-banner --require=.\/wp-content\/plugins\/plugin-check\/cli.php\n\n# Limit the run to categories or to single checks.\nwp plugin check lw-hello-banner --categories=plugin_repo,security\nwp plugin check lw-hello-banner --checks=late_escaping,i18n_usage\n\n# Errors only, as one JSON array for scripts.\nwp plugin check lw-hello-banner --ignore-warnings --format=strict-json\n\n# Show result codes, then ignore one specific code.\nwp plugin check lw-hello-banner --format=csv --fields=code,message\nwp plugin check lw-hello-banner --ignore-codes=textdomain_mismatch\n\n# Checks for an update of an existing directory plugin.\nwp plugin check lw-hello-banner --mode=update\n\n# What is available in the installed version.\nwp plugin list-checks --format=csv\nwp plugin list-check-categories<\/code><\/pre>\n
Die wichtigsten Optionen von wp plugin check<\/code> in Version 2.1.0:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Option<\/th>\nWirkung<\/th>\n<\/tr>\n<\/thead>\n
--checks=<\/code>, --exclude-checks=<\/code><\/td>\nnur die genannten Pr\u00fcfungen ausf\u00fchren oder sie auslassen<\/td>\n<\/tr>\n
--categories=<\/code><\/td>\nLauf auf Kategorien beschr\u00e4nken, kommagetrennt<\/td>\n<\/tr>\n
--ignore-codes=<\/code><\/td>\neinzelne Ergebniscodes ausblenden, etwa textdomain_mismatch<\/code><\/td>\n<\/tr>\n
--ignore-warnings<\/code>, --ignore-errors<\/code><\/td>\neinen der beiden Ergebnistypen ausblenden<\/td>\n<\/tr>\n
--format=<\/code><\/td>\ntable<\/code> (Standard), csv<\/code>, json<\/code>, ctrf<\/code> sowie strict-table<\/code>, strict-csv<\/code>, strict-json<\/code>, strict-ctrf<\/code><\/td>\n<\/tr>\n
--fields=<\/code><\/td>\nSpalten w\u00e4hlen, zum Beispiel code,message<\/code><\/td>\n<\/tr>\n
--exclude-directories=<\/code>, --exclude-files=<\/code><\/td>\nPfade bei dateibasierten Scans \u00fcberspringen; .git<\/code>, vendor<\/code>, vendor_prefixed<\/code>, vendor-prefixed<\/code> und node_modules<\/code> sind ohnehin ausgenommen<\/td>\n<\/tr>\n
--severity=<\/code>, --error-severity=<\/code>, --warning-severity=<\/code><\/td>\nnur Ergebnisse ab einer bestimmten Schwere zeigen<\/td>\n<\/tr>\n
--mode=<\/code><\/td>\nnew<\/code> (Standard) oder update<\/code>; im Update-Modus ist ein veraltetes \u201eTested up to\u201c eine Warnung statt eines Fehlers<\/td>\n<\/tr>\n
--slug=<\/code><\/td>\nden Slug \u00fcberschreiben, gegen den Text Domain und Readme verglichen werden<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Pr\u00fcfungs-Slugs und Ergebniscodes sind zweierlei. --checks=i18n_usage<\/code> w\u00e4hlt eine Pr\u00fcfung aus, --ignore-codes=WordPress.WP.I18n.TextDomainMismatch<\/code> blendet einen einzelnen Befund daraus aus. Zum Nachschlagen der Codes empfiehlt die CLI-Dokumentation --format=csv --fields=code,message<\/code>. F\u00fcr Skripte z\u00e4hlt noch ein Detail: Im Quelltext von 2.1.0 gibt der Befehl die Befunde aus, setzt ihretwegen aber keinen Fehler-Exitcode. Ein Shell-Skript, das bei Befunden scheitern soll, muss die Ausgabe also selbst auswerten; im Test meldete der Befehl beim fehlerhaften Beispiel zw\u00f6lf Fehler und endete trotzdem mit Exitcode 0. Die GitHub Action erledigt genau das. Mit --format=json<\/code> steht vor jeder Datei eine Zeile FILE: \u2026<\/code> mit einem eigenen JSON-Array, die Ausgabe als Ganzes ist also kein g\u00fcltiges JSON; --format=strict-json<\/code> liefert ein einziges Array, allerdings ohne Dateinamen. Ohne Befunde geben beide Formate nur eine Erfolgszeile aus.<\/p>\n
Ein Beispiel-Plugin mit eingebauten Fehlern<\/h2>\n
Das Beispiel besteht aus einer Datei im Ordner wp-content\/plugins\/lw-hello-banner\/<\/code>, der Slug lautet damit lw-hello-banner<\/code>. Das Plugin zeigt oben auf der Seite einen Gru\u00df, liest einen optionalen Namen aus der URL, bietet unter Einstellungen \u2192 Allgemein ein Notizfeld und l\u00e4dt ein dekoratives Skript. Neun Fehler sind absichtlich enthalten: keine readme.txt<\/code>, kein Lizenz-Header, eine vom Slug abweichende Text Domain, kein Schutz gegen direkten Dateiaufruf, ein Aufruf von error_reporting()<\/code>, register_setting()<\/code> ohne Bereinigung, Ausgaben ohne Escaping, ein \u00fcbersetzbarer String mit Platzhalter, aber ohne \u00dcbersetzerkommentar, und ein Skript vom CDN ohne Version und Ladeargumente.<\/p>\n
<?php\n\/**\n * Plugin Name: LW Hello Banner\n * Description: Shows a greeting banner at the top of the front page.\n * Version:     0.1.0\n * Author:      Lukas Wojcik\n * Text Domain: hello-banner\n *\/\n\n\/\/ Intentionally faulty example for Plugin Check. Do not use on a live site.\n\nerror_reporting( E_ALL );\n\nfunction lw_hello_banner_register_setting() {\n\tregister_setting( 'general', 'lw_hello_banner_note' );\n\n\tadd_settings_field(\n\t\t'lw_hello_banner_note',\n\t\t__( 'Banner note', 'hello-banner' ),\n\t\t'lw_hello_banner_field',\n\t\t'general'\n\t);\n}\nadd_action( 'admin_init', 'lw_hello_banner_register_setting' );\n\nfunction lw_hello_banner_field() {\n\techo '<input type=\"text\" name=\"lw_hello_banner_note\" value=\"' . get_option( 'lw_hello_banner_note' ) . '\">';\n}\n\nfunction lw_hello_banner_assets() {\n\twp_enqueue_script( 'lw-hello-banner', 'https:\/\/cdn.jsdelivr.net\/npm\/canvas-confetti@1.9.3\/dist\/confetti.browser.min.js' );\n}\nadd_action( 'wp_enqueue_scripts', 'lw_hello_banner_assets' );\n\nfunction lw_hello_banner_render() {\n\t$name = isset( $_GET['lw_name'] ) ? $_GET['lw_name'] : 'Guest';\n\t$note = get_option( 'lw_hello_banner_note', '' );\n\n\techo '<div class=\"lw-hello-banner\"><p>' . sprintf( __( 'Hello, %s!', 'hello-banner' ), $name ) . ' ' . $note . '<\/p><\/div>';\n}\nadd_action( 'wp_body_open', 'lw_hello_banner_render' );<\/code><\/pre>\n
Was Plugin Check dazu meldet<\/h2>\n
Die Tabelle f\u00fchrt die Befunde auf, die wp plugin check lw-hello-banner<\/code> mit Plugin Check 2.1.0 unter WordPress 7.1.2 meldet, zusammen zw\u00f6lf Fehler und neun Warnungen; ein Lauf mit --require<\/code> liefert dieselbe Liste. Zeilennummern fehlen; OutputNotEscaped<\/code> erscheint viermal, TextDomainMismatch<\/code> und NonceVerification.Recommended<\/code> je zweimal.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Ergebniscode<\/th>\nPr\u00fcfung (Kategorie)<\/th>\nTyp<\/th>\nUrsache im Beispiel<\/th>\n<\/tr>\n<\/thead>\n
no_plugin_readme<\/code><\/td>\nplugin_readme<\/code> (plugin_repo)<\/td>\nERROR<\/td>\nkeine readme.txt<\/code><\/td>\n<\/tr>\n
plugin_header_no_license<\/code><\/td>\nplugin_header_fields<\/code> (plugin_repo)<\/td>\nERROR<\/td>\nkein License<\/code>-Header<\/td>\n<\/tr>\n
textdomain_mismatch<\/code><\/td>\nplugin_header_fields<\/code> (plugin_repo)<\/td>\nWARNING<\/td>\nHeader nennt hello-banner<\/code>, Slug ist lw-hello-banner<\/code><\/td>\n<\/tr>\n
missing_direct_file_access_protection<\/code><\/td>\ndirect_file_access<\/code> (security, plugin_repo)<\/td>\nERROR<\/td>\nFunktionen und Hooks ohne ABSPATH<\/code>-Abfrage<\/td>\n<\/tr>\n
WordPress.WP.I18n.TextDomainMismatch<\/code><\/td>\ni18n_usage<\/code> (general, plugin_repo)<\/td>\nERROR<\/td>\n__()<\/code>-Aufrufe mit falscher Text Domain<\/td>\n<\/tr>\n
WordPress.WP.I18n.MissingTranslatorsComment<\/code><\/td>\ni18n_usage<\/code> (general, plugin_repo)<\/td>\nERROR<\/td>\n%s<\/code> ohne translators:<\/code>-Kommentar<\/td>\n<\/tr>\n
PluginCheck.CodeAnalysis.PHPErrorReporting.DirectErrorReportingCall<\/code><\/td>\nphp_error_reporting<\/code> (general)<\/td>\nWARNING<\/td>\nerror_reporting( E_ALL )<\/code><\/td>\n<\/tr>\n
WordPress.PHP.DevelopmentFunctions.prevent_path_disclosure_error_reporting<\/code><\/td>\nplugin_review_phpcs<\/code> (plugin_repo)<\/td>\nWARNING<\/td>\nerror_reporting( E_ALL )<\/code><\/td>\n<\/tr>\n
PluginCheck.CodeAnalysis.SettingSanitization.register_settingMissing<\/code><\/td>\nsetting_sanitization<\/code> (plugin_repo)<\/td>\nERROR<\/td>\nregister_setting()<\/code> ohne drittes Argument<\/td>\n<\/tr>\n
WordPress.Security.EscapeOutput.OutputNotEscaped<\/code><\/td>\nlate_escaping<\/code> (security, plugin_repo)<\/td>\nERROR<\/td>\nget_option()<\/code>, __()<\/code>, $name<\/code> und $note<\/code> im echo<\/code><\/td>\n<\/tr>\n
PluginCheck.CodeAnalysis.EnqueuedResourceOffloading.OffloadedContent<\/code><\/td>\noffloading_files<\/code> (plugin_repo)<\/td>\nERROR<\/td>\nSkript-URL auf cdn.jsdelivr.net<\/code><\/td>\n<\/tr>\n
WordPress.WP.EnqueuedResourceParameters.MissingVersion<\/code>, .NotInFooter<\/code><\/td>\nenqueued_scripts_in_footer<\/code> (performance)<\/td>\nWARNING<\/td>\nkeine Version, kein f\u00fcnftes Argument<\/td>\n<\/tr>\n
WordPress.Security.NonceVerification.Recommended<\/code><\/td>\nplugin_review_phpcs<\/code> (plugin_repo)<\/td>\nWARNING<\/td>\n$_GET['lw_name']<\/code> ohne Nonce-Pr\u00fcfung<\/td>\n<\/tr>\n
WordPress.Security.ValidatedSanitizedInput.MissingUnslash<\/code>, .InputNotSanitized<\/code><\/td>\nplugin_review_phpcs<\/code> (plugin_repo)<\/td>\nWARNING<\/td>\n$_GET['lw_name']<\/code> unbehandelt verwendet<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\"Vom
Plugin Check 2.1.0 ordnet Pr\u00fcfungen Kategorien zu; Fehler stoppen die CI, Warnungen werden annotiert<\/figcaption><\/figure>\n
Drei Dinge fallen auf. Erstens meldet Plugin Check die Text Domain doppelt, aus zwei verschiedenen Pr\u00fcfungen: Die Header-Pr\u00fcfung vergleicht den Header Text Domain<\/code> mit dem Slug und gibt eine Warnung aus, der i18n-Sniff vergleicht jeden \u00dcbersetzungsaufruf mit dem Slug und gibt einen Fehler aus. Zweitens stammen die Befunde zu Nonce und Bereinigung nicht aus der Kategorie Security, sondern aus plugin_review_phpcs<\/code>, einem PHPCS-Lauf mit dem Review-Regelwerk von Plugin Check; ein Lauf mit --categories=security<\/code> zeigt sie nicht. Drittens enth\u00e4lt das Regelwerk auch die Sniff-Gruppe WordPress.PHP.DevelopmentFunctions<\/code> als Warnung. Sie meldet die Zeile mit error_reporting()<\/code> tats\u00e4chlich ein zweites Mal, als prevent_path_disclosure_error_reporting<\/code>.<\/p>\n
Beim CDN-Skript kommt ein weiterer Punkt hinzu: Die Laufzeitpr\u00fcfungen zu Reichweite und Ladestrategie von Skripten werten nur Skripte aus, deren URL im Plugin-Ordner liegt. Das CDN-Skript melden deshalb nur die statischen Pr\u00fcfungen, und der Lauf mit --require<\/code> liefert dieselbe Liste wie der ohne. Zum Tragen kommen die Laufzeitpr\u00fcfungen erst bei der korrigierten Fassung mit mitgeliefertem Skript: Ohne die Bedingung is_front_page()<\/code> meldet Plugin Check es als EnqueuedScriptsScope<\/code> (\u201eThis script is being loaded in all frontend contexts.\u201c), aber nur in einem Lauf mit --require<\/code>.<\/p>\n
Die korrigierte Fassung<\/h2>\n
Das korrigierte Plugin besteht aus drei Dateien: der Hauptdatei, einer readme.txt<\/code> und einem kleinen lokalen Skript in assets\/<\/code>. Die Hauptdatei erh\u00e4lt einen vollst\u00e4ndigen Header mit Lizenz, Requires at least<\/code> und der Text Domain lw-hello-banner<\/code> sowie eine ABSPATH<\/code>-Abfrage. Der Aufruf von error_reporting()<\/code> entf\u00e4llt. register_setting()<\/code> bekommt Typ, sanitize_callback<\/code> und Standardwert. Ausgaben werden erst beim Ausgeben mit esc_attr()<\/code>, esc_html()<\/code> und esc_html__()<\/code> gesch\u00fctzt. Das Skript liegt im Plugin, tr\u00e4gt eine Version und wird nur auf der Startseite mit in_footer<\/code> und strategy<\/code> geladen. Die Array-Form des f\u00fcnften Arguments von wp_enqueue_script()<\/code> gibt es seit WordPress 6.3, was zur angegebenen Mindestversion passt.<\/p>\n
<?php\n\/**\n * Plugin Name:       LW Hello Banner\n * Description:       Shows a greeting banner at the top of the front page.\n * Version:           0.2.0\n * Requires at least: 6.3\n * Requires PHP:      7.4\n * Author:            Lukas Wojcik\n * License:           GPLv2 or later\n * License URI:       https:\/\/www.gnu.org\/licenses\/gpl-2.0.html\n * Text Domain:       lw-hello-banner\n *\/\n\nif ( ! defined( 'ABSPATH' ) ) {\n\texit;\n}\n\ndefine( 'LW_HELLO_BANNER_VERSION', '0.2.0' );\n\n\/**\n * Registers the banner note setting and its field on Settings > General.\n *\/\nfunction lw_hello_banner_register_setting() {\n\tregister_setting(\n\t\t'general',\n\t\t'lw_hello_banner_note',\n\t\tarray(\n\t\t\t'type'              => 'string',\n\t\t\t'sanitize_callback' => 'sanitize_text_field',\n\t\t\t'default'           => '',\n\t\t)\n\t);\n\n\tadd_settings_field(\n\t\t'lw_hello_banner_note',\n\t\t__( 'Banner note', 'lw-hello-banner' ),\n\t\t'lw_hello_banner_field',\n\t\t'general',\n\t\t'default',\n\t\tarray( 'label_for' => 'lw_hello_banner_note' )\n\t);\n}\nadd_action( 'admin_init', 'lw_hello_banner_register_setting' );\n\n\/**\n * Prints the input field for the banner note.\n *\/\nfunction lw_hello_banner_field() {\n\tprintf(\n\t\t'<input type=\"text\" class=\"regular-text\" id=\"lw_hello_banner_note\" name=\"lw_hello_banner_note\" value=\"%s\">',\n\t\tesc_attr( get_option( 'lw_hello_banner_note', '' ) )\n\t);\n}\n\n\/**\n * Loads the bundled script on the front page only.\n *\/\nfunction lw_hello_banner_assets() {\n\tif ( ! is_front_page() ) {\n\t\treturn;\n\t}\n\n\twp_enqueue_script(\n\t\t'lw-hello-banner',\n\t\tplugins_url( 'assets\/lw-hello-banner.js', __FILE__ ),\n\t\tarray(),\n\t\tLW_HELLO_BANNER_VERSION,\n\t\tarray(\n\t\t\t'in_footer' => true,\n\t\t\t'strategy'  => 'defer',\n\t\t)\n\t);\n}\nadd_action( 'wp_enqueue_scripts', 'lw_hello_banner_assets' );\n\n\/**\n * Prints the banner on the front page.\n *\/\nfunction lw_hello_banner_render() {\n\tif ( ! is_front_page() ) {\n\t\treturn;\n\t}\n\n\t\/\/ phpcs:ignore WordPress.Security.NonceVerification.Recommended -- Read-only display value, nothing is stored.\n\t$name = isset( $_GET['lw_name'] ) ? sanitize_text_field( wp_unslash( $_GET['lw_name'] ) ) : '';\n\tif ( '' === $name ) {\n\t\t$name = __( 'Guest', 'lw-hello-banner' );\n\t}\n\n\t$greeting = sprintf(\n\t\t\/* translators: %s: visitor name *\/\n\t\t__( 'Hello, %s!', 'lw-hello-banner' ),\n\t\t$name\n\t);\n\n\t$note = get_option( 'lw_hello_banner_note', '' );\n\n\techo '<div class=\"lw-hello-banner\"><p>' . esc_html( $greeting );\n\tif ( '' !== $note ) {\n\t\techo ' ' . esc_html( $note );\n\t}\n\techo '<\/p><button type=\"button\">' . esc_html__( 'Dismiss', 'lw-hello-banner' ) . '<\/button><\/div>';\n}\nadd_action( 'wp_body_open', 'lw_hello_banner_render' );<\/code><\/pre>\n
Den Namen aus der URL beh\u00e4lt die Fassung bewusst bei, und zwar im Parameter lw_name<\/code>: WordPress selbst liest name<\/code> als Beitrags-Slug, ?name=Anna<\/code> macht aus der Startseite deshalb eine 404-Seite, auf der is_front_page()<\/code> false liefert. Er wird mit wp_unslash()<\/code> und sanitize_text_field()<\/code> behandelt, die verbleibende Nonce-Warnung unterdr\u00fcckt ein phpcs:ignore<\/code>-Kommentar, der den Sniff nennt und eine Begr\u00fcndung tr\u00e4gt. Die FAQ von Plugin Check beschreibt solche Annotationen als vorgesehenen Weg f\u00fcr Fehlalarme von PHPCS in einer bestimmten Zeile. Die Begr\u00fcndung tr\u00e4gt hier nur, weil der Wert nichts ver\u00e4ndert: Er wird nicht gespeichert und l\u00f6st keine Aktion aus. Bei einem Formular, das Daten speichert, geh\u00f6ren Nonce und Capability-Pr\u00fcfung dazu; das behandelt ein eigener Beitrag dieser Reihe<\/a> ausf\u00fchrlich.<\/p>\n
=== LW Hello Banner ===\nContributors: lukaswojcik\nTags: banner, greeting\nRequires at least: 6.3\nTested up to: 7.1\nRequires PHP: 7.4\nStable tag: 0.2.0\nLicense: GPLv2 or later\nLicense URI: https:\/\/www.gnu.org\/licenses\/gpl-2.0.html\n\nShows a short, dismissible greeting banner at the top of the front page.\n\n== Description ==\n\nLW Hello Banner prints a greeting on the front page. An optional note can be set under Settings > General.\n\n== Changelog ==\n\n= 0.2.0 =\n* Fix all findings reported by Plugin Check.\n\n= 0.1.0 =\n* Initial version.<\/code><\/pre>\n
Zwei Details der Readme ergeben sich direkt aus dem Code der Pr\u00fcfung. \u201eTested up to\u201c muss der aktuellen Hauptversion von WordPress entsprechen, derzeit 7.1. Ein \u00e4lterer Wert ist bei neuen Plugins ein Fehler und im Update-Modus eine Warnung; ein Wert mit Patch-Stufe wie 7.1.2 wird als invalid_tested_upto_minor<\/code> gemeldet. Au\u00dferdem vergleicht die Pr\u00fcfung die Lizenz in der Readme mit der im Plugin-Header und meldet Abweichungen als license_mismatch<\/code>, deshalb steht in beiden Dateien derselbe Wortlaut. Die Felder von Readme und Plugin-Header behandelt ein eigener Beitrag dieser Reihe<\/span>.<\/p>\n
\/\/ assets\/lw-hello-banner.js\n( function () {\n\tconst banner = document.querySelector( '.lw-hello-banner' );\n\tif ( ! banner ) {\n\t\treturn;\n\t}\n\n\tconst button = banner.querySelector( 'button' );\n\tif ( button ) {\n\t\tbutton.addEventListener( 'click', function () {\n\t\t\tbanner.hidden = true;\n\t\t} );\n\t}\n} )();<\/code><\/pre>\n
Plugin Check in GitHub Actions<\/h2>\n
Die offizielle Anbindung ist das Repository WordPress\/plugin-check-action. Die neueste Version ist v1.1.9 vom 11. August 2026, das mitwandernde Tag v1<\/code> zeigt derzeit auf denselben Commit. Es handelt sich um eine Composite Action: Zuerst richtet sie Node 24 ein, installiert @wordpress\/env<\/code>, startet eine WordPress-Instanz mit dem Plugin-Ordner unter wp-content\/plugins<\/code>, installiert Plugin Check aus dem Verzeichnis, dazu die unter Requires Plugins<\/code> genannten Plugins, und ruft dann wp plugin check<\/code> mit --format=json<\/code> und --require=.\/wp-content\/plugins\/plugin-check\/cli.php<\/code> auf. Laufzeitpr\u00fcfungen sind also dabei. Laut Dokumentation l\u00e4uft wp-env standardm\u00e4\u00dfig auf Docker, der \u00fcbliche Ubuntu-Runner ist deshalb die naheliegende Wahl.<\/p>\n
Ein Node-Skript wertet die JSON-Datei aus. Jedes Ergebnis wird zu einer Annotation an der betroffenen Datei, mit dem Ergebniscode als Titel. Jedes ERROR<\/code> setzt den Exitcode auf 1 und l\u00e4sst den Job scheitern, Warnungen erscheinen nur als Annotation. Mit strict: true<\/code> z\u00e4hlt jedes Ergebnis als Fehler. Bei Pull Requests schreibt oder aktualisiert die Action zus\u00e4tzlich einen Zusammenfassungskommentar, das Rohergebnis landet als Artefakt plugin-check-results<\/code>.<\/p>\n
Eingaben in v1.1.9: build-dir<\/code> (Standard .\/<\/code>), checks<\/code>, exclude-checks<\/code>, categories<\/code>, exclude-files<\/code>, exclude-directories<\/code>, ignore-codes<\/code>, ignore-warnings<\/code>, ignore-errors<\/code>, include-experimental<\/code>, wp-version<\/code> (latest<\/code> oder trunk<\/code>), severity<\/code>, error-severity<\/code>, warning-severity<\/code>, include-low-severity-errors<\/code>, include-low-severity-warnings<\/code>, slug<\/code>, strict<\/code> und repo-token<\/code>. Listen-Eingaben nehmen einen Eintrag je Zeile.<\/p>\n
Zwei Details entscheiden dar\u00fcber, ob die Ergebnisse stimmen. Die Action leitet den Slug aus dem letzten Teil von build-dir<\/code> ab. Beim Standard .\/<\/code> ist das der Name des Checkout-Verzeichnisses, und der entspricht laut GitHub-Dokumentation dem Repository-Namen, etwa \/home\/runner\/work\/my-repo-name\/my-repo-name<\/code>. Hei\u00dft das Repository anders als das Plugin, f\u00e4llt jeder \u00dcbersetzungsaufruf durch. Zudem warnt die Pr\u00fcfung file_type<\/code> in 2.1.0 vor einem Ordner .github<\/code> im Plugin und beanstandet weitere versteckte Dateien. Wer das Repository-Wurzelverzeichnis pr\u00fcft, pr\u00fcft also Dateien, die nie ausgeliefert werden. Der folgende Workflow baut deshalb mit git archive<\/code> den Ordner, der tats\u00e4chlich hochgeladen w\u00fcrde, ber\u00fccksichtigt dabei die export-ignore<\/code>-Eintr\u00e4ge aus .gitattributes<\/code> und \u00fcbergibt diesen Ordner als build-dir<\/code>.<\/p>\n
# .github\/workflows\/plugin-check.yml\nname: Plugin Check\n\non:\n  pull_request:\n  push:\n    branches:\n      - main\n\npermissions:\n  contents: read\n  pull-requests: write # only for the summary comment on pull requests\n\njobs:\n  plugin-check:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v7\n\n      # Build the folder that would be shipped, without .github and other\n      # development files (see export-ignore in .gitattributes).\n      - name: Build distributable plugin folder\n        run: |\n          mkdir -p build\n          git archive --format=tar --prefix=lw-hello-banner\/ HEAD | tar -x -C build\n\n      - name: Run Plugin Check\n        uses: wordpress\/plugin-check-action@v1\n        with:\n          # The folder name becomes the slug (text domain check, readme check).\n          build-dir: .\/build\/lw-hello-banner\n          wp-version: latest\n          # Optional filters, one entry per line:\n          # categories: |\n          #   plugin_repo\n          #   security\n          # exclude-checks: |\n          #   enqueued_scripts_scope\n          # ignore-codes: |\n          #   textdomain_mismatch\n          # Fail on warnings as well:\n          # strict: true<\/code><\/pre>\n
# .gitattributes: files that git archive leaves out of the build\n\/.gitattributes export-ignore\n\/.github        export-ignore\n\/.gitignore     export-ignore\n\/build          export-ignore<\/code><\/pre>\n
Die Berechtigung pull-requests: write<\/code> ist nur f\u00fcr den Zusammenfassungskommentar n\u00f6tig; laut den Berechtigungstabellen von GitHub deckt sie den Kommentar-Endpunkt ab. Fehlt sie, protokolliert die Action eine Warnung beim Kommentieren, wertet die Ergebnisse aber trotzdem aus. Wer feste Versionen bevorzugt, verweist statt auf v1<\/code> auf wordpress\/plugin-check-action@v1.1.9<\/code> oder auf dessen Commit-Hash.<\/p>\n
Grenzen und offene Punkte<\/h2>\n