WordPress.org-Plugin-Richtlinien: woran Einreichungen scheitern

Ein Plugin, das auf einer Testinstallation fehlerfrei läuft, ist noch kein Plugin, das WordPress.org in sein Verzeichnis aufnimmt. Jede neue Einreichung durchläuft eine automatische Vorprüfung und danach ein manuelles Review durch das Plugins Team, Maßstab sind die Detailed Plugin Guidelines. Am 29.09.2026 umfasst die Seite 18 nummerierte Richtlinien, zuletzt aktualisiert am 11.03.2026. Die Beanstandungen, die das Team beschreibt, sind selten Sonderfälle, sondern wiederkehrende Muster: fehlende oder widersprüchliche Lizenzangaben, Funktionen hinter einer Bezahlschranke, verschwiegene Anfragen an fremde Server, standardmäßig eingeschaltete Credit-Links und Plugin-Namen, die mit einer fremden Marke beginnen.

Dieser Beitrag ordnet die 18 Richtlinien nach Themen, zeigt an einem kleinen Plugin, wie Zustimmung vor einer ausgehenden Anfrage und ein Credit-Link als Opt-in im Code aussehen, erklärt die Entstehung des Slugs und verfolgt eine Einreichung vom ZIP-Upload bis zum ersten SVN-Commit, samt den Warteschlangenzahlen vom 28.09.2026. Plugin Check, die Sicherheitsfunktionen und das Readme-Format haben in dieser Reihe eigene Beiträge. Die Beiträge zu den eigenen Plugins Lite Page Cache und WP Admin Captcha zeigen, was solche Plugins auf einer Website leisten; hier geht es um den Weg ins offizielle Verzeichnis.

Achtzehn Richtlinien in vier Gruppen

Die Nummerierung verrät nichts darüber, wie oft eine Regel zur Ablehnung führt, und eine Aufschlüsselung nach Richtlinie veröffentlicht das Plugins Team nicht. Der Jahresbericht für 2025 nennt nur Summen: 12.713 geprüfte Plugins, 5.415 Freigaben, 59.137 festgestellte Probleme, und bei 38,7 Prozent der geprüften Plugins kam keine Antwort der Autoren. Daneben pflegt das Team die Handbuchseite „Common issues“ mit Auszügen aus seinen Review-Mails; auch sie ordnet nicht nach Häufigkeit und bezeichnet sich als unvollständig. Die Reihenfolge hier folgt den Themen dieser Seite und der Entwickler-FAQ und ist eine Gruppierung, keine Rangfolge.

Zwei Richtlinien rahmen die übrigen ein. Nach Richtlinie 2 tragen Entwickler die Verantwortung für jede Datei, auch für Bibliotheken Dritter, und für die Bedingungen der genutzten Dienste. Richtlinie 18 behält dem Team vor, Regeln zu ändern, Plugins zu entfernen, Ausnahmen zu gewähren und auch aus Gründen zu handeln, die nicht in der Liste stehen. Der Katalog ist eine Untergrenze, kein abschließender Vertrag.

Lizenz, lesbarer Code und mitgelieferte Bibliotheken

Richtlinie 1 verlangt eine mit der GNU General Public License vereinbare Lizenz; empfohlen wird „GPLv2 or later“, die Lizenz von WordPress selbst. Das gilt für den gesamten Inhalt der ZIP-Datei einschließlich Datendateien und Bildern, Komponenten Dritter werden an der Liste kompatibler Lizenzen auf gnu.org gemessen. „Common issues“ zeigt mehrere Spielarten desselben Problems: keine GPL-kompatible Lizenz angegeben, unterschiedliche Lizenzen in Readme und Plugin-Header, inkompatibler Code im Paket und minifizierte Dateien ohne dokumentierten Quelltext.

Der letzte Punkt gehört zu Richtlinie 4. Verschleierter Code ist verboten, minifizierte Builds sind nur zulässig, wenn der lesbare Quelltext beiliegt oder im Readme öffentlich verlinkt ist. Wer Composer nutzt, liefert die composer.json mit. Richtlinie 13 untersagt, Bibliotheken mitzuliefern, die WordPress bereits enthält; „Common issues“ nennt unter anderem jQuery, SimplePie, PHPMailer und PHPass. Auf derselben Seite stehen Entwicklungsreste wie node_modules, Testsuiten und Demo-Ordner. Nichts davon ist schwer zu beheben, doch jeder Punkt kostet eine Mailrunde. Header-Felder und Readme behandelt ein eigener Beitrag dieser Reihe.

Trialware, Dienste und Code von fremden Servern

Die schärfsten Grenzen betreffen das Geschäftsmodell. Richtlinie 5 verbietet Trialware: Funktionen dürfen nicht bis zur Zahlung gesperrt sein und nicht nach einer Testphase oder einem Kontingent abschalten. Reiner Sandbox-Zugang zu einer API gilt ebenfalls als Trialware. Richtlinie 9 wertet es zudem als unredlich, den Eindruck zu erwecken, enthaltene Funktionen müssten erst bezahlt werden.

Was erlaubt ist, beschreibt Richtlinie 6. Ein Plugin darf Schnittstelle zu einem externen, auch kostenpflichtigen Dienst sein, wenn dieser substanzielle Funktionalität bietet und im Readme dokumentiert ist, am besten mit Link zu den Nutzungsbedingungen. Ausgeschlossen sind Dienste, die nur Lizenzen prüfen, während die Funktion im Plugin steckt, Code, der nur zum Schein auf einen Server wandert, und reine Shops.

Die technische Seite regelt Richtlinie 8. Code aus einem dokumentierten Dienst darf über eine sichere Verbindung geladen werden. Verboten sind Updates oder Installationen von Plugins, Themes und Add-ons von anderen Servern als WordPress.org, die Installation einer Premium-Fassung desselben Plugins, fremde CDNs für anderes als Schriften und per iframe eingebundene Admin-Seiten. „Common issues“ ergänzt, dass Plugins für Updates keine anderen Server kontaktieren und keine Bilder, Skripte oder Stylesheets ohne Dienstbezug auslagern dürfen.

Für Freemium-Plugins ergibt sich ein klares Muster. Das kostenlose Plugin muss für sich vollständig sein, bezahlte Funktionen dürfen in einem Dienst liegen, und Upgrade-Hinweise sind im Rahmen von Richtlinie 11 erlaubt: kontextbezogen oder auf der Einstellungsseite, seitenweite Hinweise schließbar. Die eigene Bezahlfassung darf das kostenlose Plugin nicht herunterladen und installieren.

Zustimmung vor Anfragen und Links im Frontend

Richtlinie 7 untersagt Kontakt zu fremden Servern ohne ausdrückliche und autorisierte Zustimmung, üblicherweise per Opt-in, Registrierung beim Dienst oder Kontrollkästchen in den Einstellungen. Die Datenerhebung gehört ins Readme, möglichst mit Datenschutzerklärung. Als unzulässig nennt die Richtlinie unter anderem automatisches Sammeln ohne Bestätigung, ausgelagerte Assets ohne Dienstbezug, undokumentiert genutzte externe Daten wie Sperrlisten und Werbung Dritter, die Aufrufe verfolgt. Plugins, die Schnittstelle zu einem Dienst sind, etwa ein Spamfilter mit externer API, sind ausgenommen: Installation und Konfiguration gelten dort als Zustimmung.

Richtlinie 10 überträgt das Prinzip auf das Frontend. „Powered by“-Hinweise und Links müssen optional und standardmäßig ausgeschaltet sein, das Opt-in muss eine klar formulierte Wahl sein und kein Satz in den Nutzungsbedingungen, und das Plugin darf nicht von einem angezeigten Credit abhängen.

Das folgende Plugin berechnet eine Lesezeit rein lokal und bietet zwei optionale Extras: wöchentliche Nutzungsstatistiken an einen Beispielserver und einen Link zur Plugin-Website. Beide Optionen stehen standardmäßig auf false. Ohne Zustimmung kehrt die Statistikfunktion zurück, bevor eine Anfrage entsteht, und der Link erscheint erst nach dem zweiten Opt-in. Weil die HTTP-API im Standard-User-Agent die Adresse der Website mitsendet, setzt das Beispiel einen eigenen User-Agent.

<?php
/**
 * Plugin Name:       Reading Time Badge
 * Description:       Shows the estimated reading time above posts. Usage statistics and a credit link are opt-in.
 * Version:           1.0.0
 * Requires at least: 6.5
 * Requires PHP:      7.4
 * License:           GPLv2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       reading-time-badge
 *
 * @package ReadingTimeBadge
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

define( 'RTBADGE_VERSION', '1.0.0' );
define( 'RTBADGE_STATS_URL', 'https://stats.example.com/v1/ping' );

/**
 * Returns the settings merged with defaults. Every outgoing feature is off by default.
 *
 * @return array
 */
function rtbadge_get_settings() {
	$defaults = array(
		'share_stats' => false,
		'show_credit' => false,
	);
	return wp_parse_args( (array) get_option( 'rtbadge_settings', array() ), $defaults );
}

/**
 * Stores exactly two booleans, whatever the form sends.
 *
 * @param mixed $input Raw option value.
 * @return array
 */
function rtbadge_sanitize_settings( $input ) {
	$input = is_array( $input ) ? $input : array();
	return array(
		'share_stats' => ! empty( $input['share_stats'] ),
		'show_credit' => ! empty( $input['show_credit'] ),
	);
}

add_action( 'admin_init', 'rtbadge_register_settings' );

/**
 * Registers the option with a sanitize callback.
 */
function rtbadge_register_settings() {
	register_setting(
		'rtbadge',
		'rtbadge_settings',
		array(
			'type'              => 'array',
			'sanitize_callback' => 'rtbadge_sanitize_settings',
			'default'           => array(
				'share_stats' => false,
				'show_credit' => false,
			),
		)
	);
}

add_action( 'admin_menu', 'rtbadge_add_settings_page' );

/**
 * Adds the settings page below Settings.
 */
function rtbadge_add_settings_page() {
	add_options_page(
		__( 'Reading Time Badge', 'reading-time-badge' ),
		__( 'Reading Time Badge', 'reading-time-badge' ),
		'manage_options',
		'rtbadge',
		'rtbadge_render_settings_page'
	);
}

/**
 * Renders two unchecked-by-default opt-in checkboxes.
 */
function rtbadge_render_settings_page() {
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}
	$settings = rtbadge_get_settings();
	?>
	<div class="wrap">
		<h1><?php echo esc_html( get_admin_page_title() ); ?></h1>
		<form action="options.php" method="post">
			<?php settings_fields( 'rtbadge' ); ?>
			<p>
				<label>
					<input type="checkbox" name="rtbadge_settings[share_stats]" value="1" <?php checked( $settings['share_stats'] ); ?>>
					<?php esc_html_e( 'Send usage statistics (plugin, WordPress and PHP version) to stats.example.com once a week.', 'reading-time-badge' ); ?>
				</label>
			</p>
			<p>
				<label>
					<input type="checkbox" name="rtbadge_settings[show_credit]" value="1" <?php checked( $settings['show_credit'] ); ?>>
					<?php esc_html_e( 'Show a link to the plugin website next to the reading time on the public site.', 'reading-time-badge' ); ?>
				</label>
			</p>
			<?php submit_button(); ?>
		</form>
	</div>
	<?php
}

add_action( 'admin_init', 'rtbadge_maybe_send_stats' );

/**
 * Sends usage statistics at most once a week, and only after opt-in.
 */
function rtbadge_maybe_send_stats() {
	$settings = rtbadge_get_settings();
	if ( ! $settings['share_stats'] ) {
		return; // No consent: no request at all.
	}
	if ( false !== get_transient( 'rtbadge_stats_sent' ) ) {
		return;
	}
	set_transient( 'rtbadge_stats_sent', 1, WEEK_IN_SECONDS );

	wp_remote_post(
		RTBADGE_STATS_URL,
		array(
			'blocking'   => false,
			'timeout'    => 5,
			// The default user agent of the HTTP API contains the site URL; replace it.
			'user-agent' => 'reading-time-badge/' . RTBADGE_VERSION,
			'body'       => array(
				'plugin_version' => RTBADGE_VERSION,
				'wp_version'     => get_bloginfo( 'version' ),
				'php_version'    => PHP_VERSION,
			),
		)
	);
}

add_filter( 'the_content', 'rtbadge_prepend_reading_time' );

/**
 * Prepends the reading time. The credit link appears only after opt-in.
 *
 * @param string $content Post content.
 * @return string
 */
function rtbadge_prepend_reading_time( $content ) {
	if ( ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) {
		return $content;
	}
	$words   = preg_split( '/\s+/u', trim( wp_strip_all_tags( $content ) ), -1, PREG_SPLIT_NO_EMPTY );
	$minutes = max( 1, (int) ceil( count( $words ) / 200 ) ); // Assumes 200 words per minute.

	$badge = '<p class="rtbadge">' . esc_html(
		sprintf(
			/* translators: %d: estimated reading time in minutes */
			_n( '%d minute read', '%d minutes read', $minutes, 'reading-time-badge' ),
			$minutes
		)
	);

	$settings = rtbadge_get_settings();
	if ( $settings['show_credit'] ) {
		$badge .= ' &middot; <a href="' . esc_url( 'https://example.com/reading-time-badge/' ) . '">'
			. esc_html__( 'Reading Time Badge', 'reading-time-badge' ) . '</a>';
	}

	return $badge . '</p>' . $content;
}

Das Readme dokumentiert, was wann an wen geht. Genau diese Bestandteile verlangt „Common issues“ für externe Dienste: wann das Plugin den Dienst nutzt, einen Link zum Dienst und Links zu Nutzungsbedingungen oder Datenschutzerklärung. Die Überschrift im Beispiel ist ein Vorschlag, keine Vorgabe.

== Privacy and external services ==

Reading Time Badge calculates the reading time locally and works without any external service.

If the option "Send usage statistics" under Settings > Reading Time Badge is enabled,
the plugin sends the plugin version, the WordPress version and the PHP version
to stats.example.com once a week. The request contains no site URL, no user data
and no content. As with any HTTP request, the server's IP address is visible to the service.
The option is disabled by default.

* Service: https://stats.example.com/
* Terms of use: https://stats.example.com/terms/
* Privacy policy: https://stats.example.com/privacy/

Plugin-Name, Slug und Markenrecht

Der Slug ist die dauerhafte Adresse eines Plugins im Verzeichnis und im SVN. Laut Einreichungsseite entsteht er aus dem Header Plugin Name; ist der Name vergeben, wird eine Zahl angehängt. Die Entwickler-FAQ erlaubt eine Slug-Änderung nach der Einreichung, nach der Freigabe keine mehr, während der angezeigte Name später änderbar bleibt.

Richtlinie 17 verbietet eine Marke oder den Namen eines anderen Projekts als einzigen oder ersten Begriff eines Slugs, sofern Inhaberschaft oder berechtigte Vertretung nicht nachgewiesen sind. Das Beispiel ist WordPress selbst: Die Marke gehört der WordPress Foundation, und die Regel gilt ausdrücklich auch für Plugin-Slugs. Für alle anderen empfiehlt die Richtlinie die Form „Funktion for Marke“, besser noch einen eigenständigen Namen. Richtlinie 16 ergänzt, dass sich Slugs nicht reservieren lassen; eingereicht wird nur ein vollständiges Plugin.

Der Header der dritten Variante steht unten. „Common issues“ erwartet außerdem, dass die Hauptdatei nach dem Slug benannt ist und die Text Domain zu ihm passt.

<?php
/**
 * Plugin Name: Delivery Dates for WooCommerce
 * Description: Lets customers pick a delivery date at checkout.
 * Version:     1.0.0
 * License:     GPLv2 or later
 * Text Domain: delivery-dates-for-woocommerce
 *
 * @package DeliveryDatesForWooCommerce
 */

// Main file: delivery-dates-for-woocommerce/delivery-dates-for-woocommerce.php
// Slug proposed on submission: delivery-dates-for-woocommerce

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

Auch das Konto hinter einer Einreichung zählt. Die FAQ erlaubt grundsätzlich eine Einreichung zur gleichen Zeit, bis zu zehn bei mehr als einer Million aktiven Installationen, und sperrt Zweitkonten, die diese Grenze umgehen. Organisationen reichen über ihr offizielles Konto ein. Richtlinie 9 verbietet Sockenpuppen-Konten und falsche Identitäten zur Umgehung früherer Sanktionen. Seit dem 01.10.2024 ist Zwei-Faktor-Authentifizierung für alle Konten von Plugin-Inhabern und Committern Pflicht.

Vom ZIP-Upload bis zum ersten SVN-Commit

Am Anfang steht eine ZIP-Datei unter 10 MB, die sich über „Plugin hochladen“ installieren lässt. Seit dem 01.10.2024 läuft sie zuerst durch die Kategorie „Plugin Repo“ von Plugin Check; ein Befund der Stufe Fehler blockiert die Einreichung bis zur Korrektur. Diesen Schritt beschreibt der eigene Beitrag zu Plugin Check. Nach dem Upload folgen eine Bestätigungsmail und der Eintrag in die Warteschlange.

Das manuelle Review prüft Sicherheit, Kompatibilität, Richtlinientreue und Präsentation. Ohne Befund wird das Plugin freigegeben, sonst listet eine Mail die nötigen Änderungen. Die FAQ bittet um Antworten im selben Mailverlauf und darum, nicht neu einzureichen. Ausnahme: Ein Review, das nach drei Monaten nicht abgeschlossen ist, wird abgelehnt; dann wird neu eingereicht und auf die alte Mail geantwortet.

Nach der Freigabe erklärt eine Mail den Zugang zum Subversion-Repository unter https://plugins.svn.wordpress.org/ plus Slug, mit trunk/, tags/ und assets/. Beim Benutzernamen zählt die Groß- und Kleinschreibung, und in den Kontoeinstellungen lässt sich ein eigenes SVN-Passwort setzen. Laut FAQ ist das Plugin live, sobald der Code committet ist. Für spätere Releases gilt seit dem 05.06.2026 eine Wartezeit von derzeit sechs Stunden vor der Verteilung über die Update-API; eine automatische Sicherheitsprüfung analysiert dabei die Änderungen und sperrt Releases mit hohem Risikowert.

Die Warteschlange am 28.09.2026

Der Wochenbericht vom 28.09.2026 auf make.wordpress.org/updates nennt 4.598 Plugins in der Warteschlange. Nur 30 davon sind neu und unbearbeitet, 3.860 warten auf ihre Autoren, 475 auf einen Reviewer, und 233 sind als „wartet auf Reviewer, Mail noch nicht verschickt“ markiert. Am 07.09.2026 standen 4.893 Plugins in der Warteschlange, davon 160 neu und unbearbeitet.

Eine Wartezeit nennen die Berichte nicht. Die geringe Zahl unbearbeiteter Einreichungen spricht dafür, dass das erste Review derzeit bald nach dem Upload folgt, doch das ist eine Deutung. Die offiziellen Zeitangaben weichen voneinander ab: Die Einreichungsseite spricht von einem bis zehn Tagen mit dem Ziel von fünf Werktagen, die FAQ erwartet die Freigabe eines kleinen, fehlerfreien Plugins binnen vierzehn Tagen nach dem ersten Review. Wie stark die Lage schwankt, zeigt der Statusbericht vom Juni 2026: rund 1.050 Plugins Mitte April, wenige Wochen später nahezu null, im Mai ein Rekord von rund 700 Einreichungen pro Woche.

Grenzen und offene Punkte

Offizielle Daten dazu, welche Richtlinie am häufigsten zur Ablehnung führt, gibt es nicht; die Gruppierung ist keine Rangfolge. Die Warteschlangenzahlen beschreiben einen Zustand, keine Wartezeit, und die meisten Einträge warten auf Autoren, nicht auf Reviewer. Die Angaben vom Juni und vom September zählen vermutlich Unterschiedliches, und eine ältere Handbuchseite von 2022 nennt noch vierzehn Werktage.

Ob die sechsstündige Wartezeit auch für das erste Release eines frisch freigegebenen Plugins gilt, lässt die Ankündigung offen. Die Vorprüfung mit Plugin Check ist so beschrieben, wie sie im Oktober 2024 angekündigt wurde; ihr Umfang kann sich geändert haben. Die Richtlinien werden regelmäßig überarbeitet, ein erneuter Blick kurz vor der Einreichung lohnt sich. Das Beispiel-Plugin besteht die WordPress Coding Standards ohne Befund; Plugin Check 2.1.0 meldet unter WordPress 7.1.2 nur die fehlende readme.txt (no_plugin_readme), mit einer vollständigen Readme um den gezeigten Abschnitt nichts mehr, Laufzeitprüfungen eingeschlossen.