Codekeks

Der lange Weg von der Plugin-Idee bis zur Veröffentlichung auf WordPress.org – Teil 2

Teil 2

4. Testen, Absichern und Feinschliff

4.1. Codequalität und Sicherheit

Bevor ein Plugin an andere Nutzer verteilt wird, sollte es durch einen gründlichen Code-Check gehen. Dazu gehören:

  • Sanitizing & Escaping: Jede Benutzereingabe (Formulare, GET/POST-Variablen) muss gefiltert und abgesichert werden. Nutze Funktionen wie sanitizetextfield() oder eschtml().
  • Nonces & Permissions: Verhindere unautorisierte Änderungen mit checkadminreferer() und überprüfe Benutzerrechte via currentusercan().
  • Keine direkten Datei-Zugriffe: Vermeide Aufrufe von $FILES, $SERVER oder direkten Includes ohne vorherige Prüfung von ABSPATH.

Ein Beispiel für sichere Formularverarbeitung:

if (isset($_POST['submit'])) {
    check_admin_referer('amm_save_opts');
    if (current_user_can('manage_options')) {
        update_option('amm_admin_maintenance_opts', sanitize_text_field($_POST['message']));
    }
}

4.2. Testing mit WP\DEBUG

In deiner wp-config.php sollte während der Entwicklung stehen:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Fehler und Warnungen landen dann in /wp-content/debug.log.\
Vor der Veröffentlichung immer mit aktivem Debug testen – das deckt Deprecated-Funktionen und Syntaxfehler zuverlässig auf.

4.3. Internationalisierung (i18n)

WordPress erwartet, dass jedes Plugin mehrsprachig nutzbar ist.\
Nutze die Standardfunktionen:

__('Text', 'admin-maintenance-message');
_e('Text', 'admin-maintenance-message');

Danach kann mit makepot oder Tools wie Poedit eine .pot-Datei erstellt werden.\
Die Übersetzungen gehören in /languages/.

5. Der Weg zur Freigabe: WordPress.org Review-Prozess

5.1. Das Readme-Format

Die readme.txt ist mehr als Deko – sie ist Pflicht und Grundlage für die Plugin-Seite.\
Sie folgt einem festen Format:

=== Plugin Name ===
Contributors: deinname
Tags: admin, notice, dashboard
Requires at least: 6.0
Tested up to: 6.8
Stable tag: 0.1.5
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

== Description ==
Hier kommt die Hauptbeschreibung deines Plugins hin.

== Installation ==
1. Plugin hochladen
2. Aktivieren
3. Unter Einstellungen konfigurieren

== Changelog ==
= 0.1.5 =
* Erste stabile Version

Der Readme-Validator auf wordpress.org/plugins/developers/readme-validator hilft, Fehler zu finden.

5.2. Der Review-Prozess

Sobald du dein Plugin über die Seite Add Your Plugin einreichst, überprüft ein Freiwilligenteam den Code.

Typische Beanstandungen sind:

  • Inline-Styles (<style>) statt wpenqueuestyle()
  • Fehlende Prefixe bei Klassen oder Optionen
  • Unsichere Funktionen (eval, base64_decode, direkte DB-Zugriffe)
  • Fehlende Übersetzungstexte oder unvollständiger Header

Nach der Freigabe erhältst du Zugriff auf ein SVN-Repository, z. B.:

https://plugins.svn.wordpress.org/admin-maintenance-message

6. Arbeiten mit SVN

6.1. Grundstruktur im Repository

Das WordPress-Plugin-Verzeichnis erwartet:

/trunk       # Aktuelle Entwicklungsdateien
/tags        # Versions-Ordner (z. B. /tags/0.1.5)
/assets      # Banner, Screenshots, Icons für Pluginseite

6.2. Upload-Schritte

svn checkout https://plugins.svn.wordpress.org/admin-maintenance-message
svn add --force trunk
svn commit -m "Initial Commit"
svn copy trunk tags/0.1.5
svn commit -m "Tag 0.1.5"

Nach einigen Minuten erscheint dein Plugin unter:\
https://wordpress.org/plugins/admin-maintenance-message

7. Nach der Veröffentlichung

7.1. Updates veröffentlichen

Erhöhe die Version in readme.txt und im Plugin-Header, dann wiederhole den Commit-Vorgang:

svn commit -m "Update to 0.1.6"
svn copy trunk tags/0.1.6
svn commit -m "Tag 0.1.6"

7.2. Plugin-Assets

Bilder kommen ins Verzeichnis /assets/ im SVN-Root:

assets/
├── banner-772x250.png
├── banner-1544x500.png
└── icon-256x256.png

Sie werden automatisch auf der Plugin-Seite angezeigt.

8. Fazit: Warum sich der Aufwand lohnt

Ein Plugin im offiziellen Verzeichnis zu haben, bedeutet mehr als nur Sichtbarkeit. Es steht für:

  • Vertrauen in die Codequalität
  • Erfahrung im Umgang mit WordPress-Standards
  • Nachhaltige Weiterentwicklung

Der Prozess kann anstrengend sein – aber er schärft das Bewusstsein für sauberen Code, Sicherheit und Dokumentation. Und er ist ein großartiger Beitrag zur Community.