Das erste eigene Plugin

Ein Plugin ist im Kern erstaunlich einfach: eine PHP-Datei mit einem besonderen Kommentar in einem eigenen Ordner. Trotzdem entscheidet der Aufbau in den ersten Stunden darüber, ob ein Plugin nach zwei Jahren noch wartbar ist. Diese Lektion begleitet den Bau eines Terminplugins für einen Fahrradladen – von der ersten Datei über den Lebenszyklus mit Aktivierung und Deinstallation bis zu einer Struktur, in der auch größere Funktionen übersichtlich bleiben.

1. Die Hauptdatei

1<?php
2/**
3 * Plugin Name:       Radwerk Termine
4 * Description:       Werkstatttermine online buchen.
5 * Version:           1.0.0
6 * Requires at least: 6.9
7 * Requires PHP:      8.1
8 * Author:            Radwerk
9 * License:           GPL-2.0-or-later
10 * Text Domain:       radwerk-termine
11 */
12
13defined( 'ABSPATH' ) || exit;

Die Zeile mit ABSPATH verhindert, dass jemand die Datei direkt im Browser aufruft. Ab hier gilt: Die Hauptdatei bleibt klein. Sie definiert Konstanten wie Version und Pfad, lädt die übrigen Dateien und hängt den Start an einen Hook. Die eigentliche Logik liegt in Klassen im Ordner includes.

2. Eine Struktur, die mitwächst

Abb. 2.1Ordnerstruktur eines WordPress-Plugins

Alle Funktionen, Klassen, Optionen und Hooks brauchen ein eindeutiges Präfix oder einen Namespace. Ohne das kollidieren Namen früher oder später mit anderen Plugins – eine Funktion namens termin_speichern existiert womöglich schon, und die Website bricht mit einem fatalen Fehler ab. Moderne Plugins nutzen einen PHP-Namespace und den Autoloader von Composer, wie in Modul 2 gezeigt.

1<?php
2namespace Radwerk\Termine;
3
4defined( 'ABSPATH' ) || exit;
5
6const VERSION = '1.0.0';
7define( 'RADWERK_PFAD', plugin_dir_path( __FILE__ ) );
8
9require RADWERK_PFAD . 'vendor/autoload.php';
10
11register_activation_hook( __FILE__, [ Installation::class, 'aktivieren' ] );
12register_deactivation_hook( __FILE__, [ Installation::class, 'deaktivieren' ] );
13
14add_action( 'plugins_loaded', function () {
15    ( new Plugin() )->starten();
16} );

3. Der Lebenszyklus

1<?php
2defined( 'WP_UNINSTALL_PLUGIN' ) || exit;
3
4// Nur löschen, wenn in den Einstellungen gewünscht
5if ( get_option( 'radwerk_daten_loeschen' ) ) {
6    delete_option( 'radwerk_einstellungen' );
7    global $wpdb;
8    $wpdb->query( "DROP TABLE IF EXISTS {$wpdb->prefix}radwerk_buchungen" );
9}

4. Plugin oder Theme?

Faustregel: Alles, was beim Theme-Wechsel erhalten bleiben muss, gehört in ein Plugin. Inhaltstypen, Blöcke mit Inhalt, Formulare, Schnittstellen und Geschäftslogik sind Plugin-Sache; Farben, Schriften, Vorlagen und Layout sind Theme-Sache. Für kleine, website-spezifische Anpassungen, die nie deaktiviert werden sollen, eignen sich „Must-Use-Plugins“ im Ordner mu-plugins: Sie werden automatisch geladen und tauchen nicht in der normalen Plugin-Liste auf.

Sauber starten: eine Checkliste

Bevor das erste Feature entsteht, lohnt eine halbe Stunde für die Grundlagen, die später kaum noch nachzurüsten sind. Dazu gehört ein Versionsverwaltungssystem wie Git vom ersten Tag an, damit jede Änderung nachvollziehbar und rückgängig zu machen ist. Dazu gehören eine composer.json mit Autoloading und eine package.json, falls Blöcke oder Skripte gebaut werden. Eine Datei mit Coding Standards – etwa phpcs.xml mit den Regeln von WordPress – sorgt dafür, dass Code einheitlich bleibt und typische Sicherheitsfehler auffallen. Und eine lokale Umgebung mit wp-env, die per Befehl startet, macht es leicht, auch nach Monaten wieder einzusteigen.

Wichtig ist außerdem, früh über Übersetzbarkeit nachzudenken. Alle sichtbaren Texte werden mit Funktionen wie __() und esc_html__() und der Text Domain des Plugins ausgegeben. So kann das Plugin später ohne Codeänderung übersetzt werden, auch wenn es zunächst nur auf Deutsch erscheint. Wer das von Anfang an tut, erspart sich das mühsame Nachrüsten Hunderter Zeichenketten. Schließlich sollte die Hauptdatei prüfen, ob die Mindestanforderungen erfüllt sind, und sonst eine verständliche Meldung im Backend zeigen, statt mit einem fatalen Fehler abzubrechen.

5. Häufige Fragen

Wie entwickle ich lokal? Mit einer lokalen Umgebung wie WordPress Studio, wp-env oder Docker. wp-env startet mit einem Befehl eine WordPress-Instanz, in die der Plugin-Ordner eingebunden ist – ideal auch für Tests. WordPress Playground eignet sich für schnelle Experimente direkt im Browser.

Klassen oder Funktionen? Für sehr kleine Plugins genügen Funktionen mit Präfix. Sobald mehrere Bereiche entstehen – Einstellungen, Blöcke, Schnittstellen –, sind Klassen mit Namespace übersichtlicher und lassen sich besser testen.

Muss ein Plugin GPL-lizenziert sein? Im offiziellen Verzeichnis ja. Da Plugins eng mit WordPress verbunden sind, gilt die GPL nach herrschender Auffassung auch für den PHP-Code kommerzieller Plugins. Verkauft werden meist Updates, Support und Zusatzleistungen.

6. Übung zum Selbermachen

Legen Sie ein Plugin „Mein Hinweis“ mit korrektem Kopf an. Bei der Aktivierung soll es eine Option mein_hinweis_text mit einem Standardtext anlegen, bei der Deinstallation diese Option wieder löschen. Über einen Filter auf the_content wird der Text unter jedem Beitrag ausgegeben – natürlich mit esc_html maskiert. Aktivieren, deaktivieren und löschen Sie das Plugin und prüfen Sie jeweils in der Tabelle wp_options, was mit der Option passiert.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.