WordPress Actions erklärt: Der vollständige Entwicklerleitfaden zur Hooks API

WordPress Actions sind eine Kernkomponente der Hooks API, die es Entwicklern ermöglicht, benutzerdefinierte Funktionen an präzise definierten Punkten während des WordPress-Request-Lebenszyklus auszuführen — ohne jemals Core-Dateien zu berühren. Wenn ein Action-Hook ausgelöst wird, läuft jede für diesen Hook registrierte Funktion in Prioritätsreihenfolge, was eine modulare, wartbare und upgrade-sichere Anpassung ermöglicht.

Ob Sie ein Plugin erstellen, ein Theme entwickeln oder eine selbst gehostete WordPress-Installation in einer VPS Hosting-Umgebung verwalten — die Beherrschung von Actions ist unerlässlich. Sie sind der primäre Mechanismus, durch den WordPress selbst architektonisch aufgebaut ist — nicht nur ein Erweiterungswerkzeug für Dritte.

Wie WordPress Actions tatsächlich unter der Haube funktionieren

WordPress pflegt eine globale Registry namens $wp_filter, die alle registrierten Hooks speichert — sowohl Actions als auch Filter. Wenn do_action() aufgerufen wird, sucht WordPress den Eintrag dieses Hooks in $wp_filter, sortiert die registrierten Callbacks nach Priorität und führt sie sequenziell aus.

Der entscheidende Unterschied, den viele Tutorials übergehen: Actions sind Fire-and-Forget. Sie führen Callbacks aus, verwerfen aber alle Rückgabewerte. Wenn Sie Daten abfangen und modifizieren müssen, ist das die Aufgabe von Filtern, nicht von Actions. Die Verwechslung beider ist einer der häufigsten architektonischen Fehler bei der WordPress-Plugin-Entwicklung.

Der Ausführungsablauf sieht folgendermaßen aus:

WordPress Core (oder ein Plugin/Theme) ruft do_action( 'hook_name', ...$args ) auf.
WordPress löst alle bei hook_name registrierten Callbacks aus $wp_filter auf.
Callbacks werden nach ihrem $priority-Wert sortiert (aufsteigend — niedrigere Zahlen werden zuerst ausgeführt).
Jeder Callback wird mit den angegebenen Argumenten aufgerufen.
Rückgabewerte werden stillschweigend ignoriert.
Die Ausführung wird im ursprünglichen Code fortgesetzt, nachdem do_action() zurückgekehrt ist.

Diese Architektur bedeutet, dass ein schlecht geschriebener Callback, der bei einem frühen Hook wie init registriert ist, den gesamten Request blockieren kann. Profilieren Sie Hook-Callbacks immer in der Staging-Umgebung, bevor Sie sie in die Produktion deployen.

Actions mit `add_action()` registrieren

Die Funktion add_action() registriert ein PHP-Callable bei einem benannten Action-Hook. Ihre vollständige Signatur lautet:

add_action( string $hook_name, callable $callback, int $priority = 10, int $accepted_args = 1 ): true

Parameter erklärt:

$hook_name — Der genaue String-Bezeichner des Action-Hooks (z. B. wp_login, save_post).
$callback — Jedes gültige PHP-Callable: eine benannte Funktion, eine anonyme Funktion, eine statische Methode array( 'MyClass', 'method' ) oder eine Objektmethode array( $object, 'method' ).
$priority — Ausführungsreihenfolge relativ zu anderen Callbacks am selben Hook. Standard ist 10. Callbacks mit gleicher Priorität werden in der Reihenfolge ihrer Registrierung ausgeführt.
$accepted_args — Wie viele Argumente von do_action() an Ihren Callback übergeben werden. Standard ist 1. Sie müssen dies korrekt setzen, sonst erhält Ihr Callback abgeschnittene Argumentlisten.

Grundlegendes Beispiel: Einhängen in wp_login
function notify_admin_on_login( string $user_login, WP_User $user ): void {
    $admin_email = get_option( 'admin_email' );
    $subject     = 'Login Alert: ' . $user_login;
    $message     = sprintf(
        'User "%s" (ID: %d) logged in at %s.',
        $user_login,
        $user->ID,
        current_time( 'mysql' )
    );
    wp_mail( $admin_email, $subject, $message );
}

// wp_login passes two arguments: $user_login (string) and $user (WP_User object)
add_action( 'wp_login', 'notify_admin_on_login', 10, 2 );
Beachten Sie, dass accepted_args auf 2 gesetzt ist. Wenn Sie dies weglassen und den Standard 1 belassen, erhält Ihr Callback nur $user_login und sieht das WP_User-Objekt nie — ein stiller Fehler, der notorisch schwer zu verfolgen ist.
Objektmethoden und Closures verwenden
Moderne WordPress-Entwicklung bevorzugt die Kapselung von Logik in Klassen:
class My_Plugin {

    public function __construct() {
        add_action( 'init', array( $this, 'register_post_types' ) );
        add_action( 'save_post', array( $this, 'handle_save' ), 20, 3 );
    }

    public function register_post_types(): void {
        register_post_type( 'product', array( /* args */ ) );
    }

    public function handle_save( int $post_id, WP_Post $post, bool $update ): void {
        if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
            return;
        }
        // Custom save logic here
    }
}

new My_Plugin();
Anonyme Closures funktionieren ebenfalls, können aber nicht später mit remove_action() entfernt werden, da PHP anonyme Funktionsreferenzen nicht zuverlässig vergleichen kann. Verwenden Sie benannte Methoden, wenn Sie die Möglichkeit zur Deregistrierung benötigen.
Actions mit remove_action() entfernen
Sie können jeden Callback deregistrieren — einschließlich solcher, die von anderen Plugins oder Themes hinzugefügt wurden — mit remove_action(). Die Priorität muss genau mit der in add_action() verwendeten übereinstimmen:
remove_action( 'wp_head', 'wp_generator' ); // Removes WordPress version meta tag
Für Objektmethoden benötigen Sie eine Referenz auf dieselbe Objektinstanz:
// Inside a plugin that exposes its instance
global $my_plugin_instance;
remove_action( 'save_post', array( $my_plugin_instance, 'handle_save' ), 20 );
Ein häufiger Fallstrick: remove_action() aufzurufen, bevor das ursprüngliche add_action() ausgeführt wurde. Hängen Sie Ihre Entfernung immer in eine Action ein, die nach dem Laden des Ziel-Plugins ausgelöst wird — typischerweise plugins_loaded oder after_setup_theme.
Referenz der WordPress Core Action Hooks
Die folgende Tabelle behandelt die operativ bedeutsamsten Action-Hooks, ihren Auslösekontext und ihre praktischen Anwendungsfälle.




Hook-Name
Wird ausgelöst wenn
Typische Anwendungsfälle
Übergebene Args




muplugins_loaded
Must-use Plugins geladen
Frühes Bootstrapping, Konstanten
0


plugins_loaded
Alle Plugins geladen
Plugin-übergreifende Kompatibilitätsprüfungen
0


init
Nach WP-Laden, vor Headers
CPTs, Taxonomien, Rewrite-Regeln registrieren
0


wp_loaded
Nach init, alles geladen
REST API-Registrierung, späte Init-Aufgaben
0


wp_enqueue_scripts
Frontend-Asset-Laden
CSS/JS für Themes und Plugins einbinden
0


wp_head
Innerhalb des <head>-Tags
Meta-Tags, Inline-Styles, Analytics-Snippets
0


wp_footer
Vor </body>
Verzögerte Skripte, Tracking-Pixel
0


admin_init
Admin-Seite lädt
Settings API-Registrierung, Berechtigungsprüfungen
0


admin_enqueue_scripts
Admin-Asset-Laden
Nur-Admin CSS/JS einbinden
1 ($hook_suffix)


save_post
Beitrag gespeichert oder aktualisiert
Meta-Updates, externe API-Synchronisation, Benachrichtigungen
3


wp_login
Benutzer authentifiziert sich
Audit-Logging, Session-Management
2


user_register
Neuer Benutzer erstellt
Willkommens-E-Mails, CRM-Sync, Rollenzuweisung
1 ($user_id)


wp_logout
Benutzer meldet sich ab
Session-Bereinigung, Analytics-Events
1 ($user_id)


switch_theme
Aktives Theme wechselt
Cache-Bereinigung, Options-Migration
2


wp_trash_post
Beitrag in Papierkorb verschoben
Bereinigung verwandter Daten, externe Synchronisation
1 ($post_id)


rest_api_init
REST API initialisiert
Benutzerdefinierte REST-Routen registrieren
0


template_redirect
Vor dem Template-Laden
Weiterleitungen, Zugriffskontrolle
0




do_action() vs do_action_ref_array(): Wann welche Funktion gilt
Beide Funktionen lösen einen Action-Hook aus, unterscheiden sich jedoch in der Art, wie Argumente übergeben werden.
do_action()
Die Standardfunktion. Argumente werden als Wert übergeben — Callbacks erhalten Kopien.
do_action( 'my_plugin_after_import', $import_id, $result_count, $errors );
do_action_ref_array()
Argumente werden als Array übergeben, und Objekte innerhalb dieses Arrays werden als Referenz übergeben (PHP-Objekte sind seit PHP 5 standardmäßig immer referenzartig). Dies ist hauptsächlich für Legacy-Kompatibilität nützlich oder wenn Sie explizit benötigen, dass Callbacks eine gemeinsame Datenstruktur mutieren.
$context = array(
    'post_id' => 42,
    'meta'    => array(),
);

do_action_ref_array( 'my_plugin_process_context', array( &$context ) );

// $context['meta'] may now be populated by hooked callbacks
Praktische Empfehlung: In modernem PHP (7.4+) ist der Verhaltensunterschied zwischen beiden für Objekte minimal. Verwenden Sie standardmäßig do_action(). Greifen Sie auf do_action_ref_array() nur zurück, wenn Sie Legacy-Code integrieren, der es explizit erwartet, oder wenn Sie benötigen, dass Callbacks einen primitiven Wert (wie eine Ganzzahl) als Referenz mutieren.
Benutzerdefinierte Action-Hooks erstellen und dokumentieren
Wenn Sie ein Plugin oder Theme erstellen, das von anderen erweitert werden soll, sollten Sie Ihre eigenen Action-Hooks definieren. So stellen Sie eine API-Oberfläche bereit, ohne Dritten direkten Zugang zu Ihren internen Strukturen zu geben.
/**
 * Fires after a custom import process completes.
 *
 * @since 1.0.0
 *
 * @param int   $import_id    The ID of the completed import batch.
 * @param int   $record_count Total number of records processed.
 * @param array $errors       Array of WP_Error objects, empty on full success.
 */
do_action( 'my_plugin_import_complete', $import_id, $record_count, $errors );
Dokumentieren Sie Ihre Hooks immer mit einem DocBlock direkt über do_action(). Dies ist es, was den WordPress-Entwicklerdokumentationsgenerator antreibt und Ihr Plugin professionell macht. Drittentwickler können dann sauber einhängen:
add_action( 'my_plugin_import_complete', function( int $import_id, int $count, array $errors ) {
    if ( ! empty( $errors ) ) {
        // Log errors to an external monitoring service
        error_log( "Import {$import_id} completed with " . count( $errors ) . ' errors.' );
    }
}, 10, 3 );
Actions vs Filter: Ein definitiver Vergleich
Dies ist die wichtigste konzeptionelle Unterscheidung in der gesamten WordPress Hooks API.




Dimension
Actions
Filter




Hauptzweck
Nebeneffekte zu einem Zeitpunkt ausführen
Daten abfangen und modifizieren


Rückgabewert
Vollständig ignoriert
Muss den (modifizierten) Wert zurückgeben


Kernfunktion
do_action()
apply_filters()


Registrierung
add_action()
add_filter()


Typische Verwendung
E-Mails senden, in DB schreiben, Assets einbinden
Beitragsinhalt modifizieren, Query-Args ändern


Kann kurzschließen?
Nein (alle Callbacks werden immer ausgeführt)
Nein (kann aber früh innerhalb des Callbacks zurückkehren)


Datenmutation
Nicht das beabsichtigte Muster
Kernzweck




Wichtige Architekturegel: Wenn Sie add_filter() verwenden, aber keinen Wert aus Ihrem Callback zurückgeben, haben Sie einen Fehler eingeführt — der gefilterte Wert wird je nach Kontext null oder false. Umgekehrt, wenn Sie add_action() verwenden und sich auf einen Rückgabewert verlassen, missbrauchen Sie die API.
Prioritätskonflikte und Ausführungsreihenfolge
Prioritätsverwaltung wird in komplexen Plugin-Ökosystemen kritisch. Betrachten Sie ein Szenario, in dem WooCommerce, ein Caching-Plugin und Ihr benutzerdefinierter Code alle in save_post einhängen:
// WooCommerce hooks at priority 10 (default)
// Your inventory sync needs WooCommerce data to already be saved
add_action( 'save_post_product', 'sync_inventory_to_erp', 99 );

// A cache purge should happen last, after all data is written
add_action( 'save_post', 'purge_varnish_cache', 9999 );
Zu kennende Randfälle:

Negative Prioritäten sind in WordPress gültig. add_action( 'init', 'my_func', -1 ) wird vor allem mit Priorität 0 oder 10 ausgeführt.
Gleiche Priorität, mehrere Callbacks — sie werden in der Reihenfolge ausgeführt, in der add_action() aufgerufen wurde. Die Plugin-Ladereihenfolge (bestimmt durch Dateinamen alphabetisch oder Plugin Order-Plugins) beeinflusst daher das Verhalten.
Rekursive Hooks — do_action() für denselben Hook innerhalb eines Callbacks für diesen Hook aufzurufen ist technisch möglich, erzeugt aber Endlosschleifen. WordPress schützt nicht davor.
Späte Hook-Registrierung — wenn Sie add_action( 'init', ... ) aufrufen, nachdem init bereits ausgelöst wurde, wird Ihr Callback in diesem Request nie ausgeführt. Dies ist eine häufige Fehlerquelle in Code, der bedingt ausgeführt wird.

Reale Produktionsmuster
Muster 1: Entkoppeltes Event-System
Verwenden Sie benutzerdefinierte Actions, um Plugin-Komponenten zu entkoppeln und direkte Funktionsaufrufe zwischen Modulen zu vermeiden:
// In your order processing module
do_action( 'my_shop_order_paid', $order_id, $payment_method, $amount );

// In your email module (separate file, no direct dependency)
add_action( 'my_shop_order_paid', 'send_payment_confirmation_email', 10, 3 );

// In your analytics module (separate file, no direct dependency)
add_action( 'my_shop_order_paid', 'track_conversion_event', 20, 3 );
Dieses Muster bedeutet, dass Sie das Analytics-Modul vollständig deaktivieren können, ohne den Bestellverarbeitungscode zu berühren.
Muster 2: Bedingte Hook-Registrierung
Vermeiden Sie es, Hooks bedingungslos auf der obersten Ebene zu registrieren. Begrenzen Sie sie auf den Kontext, in dem sie benötigt werden:
add_action( 'admin_init', function() {
    // Only register these hooks in the admin context
    add_action( 'admin_enqueue_scripts', 'my_plugin_admin_assets' );
    add_action( 'save_post', 'my_plugin_validate_custom_fields', 10, 2 );
} );
Muster 3: Einmalige Actions mit remove_action() im Callback
function my_plugin_run_once(): void {
    // Do something that must only happen once per request
    update_option( 'my_plugin_initialized', true );

    // Deregister itself to prevent re-execution if the hook fires again
    remove_action( 'wp_loaded', 'my_plugin_run_once' );
}

add_action( 'wp_loaded', 'my_plugin_run_once' );
Leistungsüberlegungen in verwalteten Umgebungen
Bei WordPress-Installationen mit hohem Datenverkehr — ob auf einem VPS Hosting-Plan oder einem Dedicated Server — sind die kumulativen Kosten schlecht optimierter Hooks messbar.
Zu verwendende Profiling-Tools:

Query Monitor-Plugin: Zeigt jeden ausgelösten Hook, jeden ausgeführten Callback und die Ausführungszeit pro Callback.
Xdebug + KCacheGrind: Für tiefes Profiling von Callback-Ausführungspfaden.
New Relic APM: Für Hook-Performance-Monitoring auf Produktionsebene.

Optimierungsprinzipien:

Verschieben Sie aufwändige Operationen (Datenbankabfragen, HTTP-Anfragen, Datei-I/O) aus Hooks, die bei jedem Seitenaufruf ausgelöst werden (init, wp_head), in Hooks, die nur bei Bedarf ausgelöst werden (save_post, user_register).
Verwenden Sie Transients oder Object-Caching, um Ergebnisse aufwändiger Berechnungen innerhalb von Hook-Callbacks zu memoizieren.
Vermeiden Sie es, Hunderte von add_action()-Aufrufen bedingungslos beim Plugin-Laden zu registrieren. Registrieren Sie Hooks lazy nur dann, wenn die relevante Admin-Seite oder der Kontext aktiv ist.
Auf Servern mit aktiviertem OPcache (was alle ordnungsgemäß konfigurierten PHP-Umgebungen haben sollten) ist der Overhead der Hook-Registrierung selbst vernachlässigbar — die Kosten liegen darin, was die Callbacks *tun*, nicht in der Registrierung.

Wenn Sie Ihren eigenen WordPress-Stack verwalten, wird sicherzustellen, dass Ihr Server PHP 8.1+ mit OPcache, einem Bytecode-Cache und einem Object-Cache wie Redis oder Memcached betreibt, eine weitaus größere Leistungswirkung haben als die Mikro-Optimierung von Hook-Prioritäten.
WordPress Actions im Kontext der Plugin- und Theme-Entwicklung
Wenn Sie ein Plugin entwickeln, das für das WordPress.org-Repository oder den kommerziellen Vertrieb bestimmt ist, bestimmt Ihre Verwendung der Hooks API direkt die Codequalität und Kompatibilitätsbewertungen.
Best Practices für produktionsreifen Hook-Einsatz:

Prüfen Sie immer DOING_AUTOSAVE innerhalb von save_post-Callbacks, um zu vermeiden, dass aufwändige Logik bei Autosaves ausgeführt wird.
Verifizieren Sie Nonces und Berechtigungen innerhalb jedes Hook-Callbacks, der vom Benutzer übermittelte Daten verarbeitet. Vertrauen Sie nie darauf, dass der Hook selbst Sicherheit bietet.
Verwenden Sie current_action(), um zu bestimmen, welcher spezifische Hook Ihren Callback ausgelöst hat, wenn dieselbe Funktion bei mehreren Hooks registriert ist.
Verwenden Sie Namespaces für Ihre benutzerdefinierten Hook-Namen, um Kollisionen zu vermeiden: my_plugin_event_name, nicht event_name.
Versionieren Sie Ihre Hooks in der Dokumentation, damit Entwickler wissen, wann ein Hook eingeführt wurde und wann er möglicherweise veraltet sein wird.

Für Teams, die WordPress auf Infrastruktur mit VPS Control Panels deployen, ist die Pflege von Staging-Umgebungen, die die Produktion spiegeln, unerlässlich, um Hook-Interaktionen vor dem Deployment sicher zu testen.
Ihre WordPress-Installation neben benutzerdefinierten Actions absichern
Benutzerdefinierte Action-Hooks, die externe Daten verarbeiten, Authentifizierungsereignisse behandeln oder mit dem Dateisystem interagieren, erweitern die Sicherheitsangriffsfläche. Kombinieren Sie Ihre Hook-Entwicklung mit einer ordnungsgemäß gesicherten Hosting-Umgebung.
Stellen Sie sicher, dass Ihre WordPress-Installation HTTPS verwendet — ein SSL-Zertifikat ist für jede Website, die Benutzerauthentifizierung oder Formularübermittlungen verarbeitet, obligatorisch. Hook-Callbacks, die bei wp_login oder user_register ausgelöst werden, verarbeiten sensible Daten über die Leitung; ohne TLS sind diese Daten exponiert, unabhängig davon, wie gut Ihr PHP-Code geschrieben ist.
Wenn Ihr Plugin wp_mail() innerhalb von Action-Callbacks verwendet (ein gängiges Muster für Benachrichtigungen), beeinflussen die Mail-Konfiguration und der Ruf Ihres Servers direkt die Zustellbarkeit. Erwägen Sie eine dedizierte E-Mail-Hosting-Lösung mit ordnungsgemäßen SPF-, DKIM- und DMARC-Einträgen, anstatt sich auf sendmail auf Serverebene zu verlassen.
Technische Entscheidungsmatrix und wichtige Erkenntnisse
Verwenden Sie diese Checkliste bei der Implementierung von WordPress Actions in jedem Projekt:
Hook-Registrierung:

Setzen Sie $accepted_args explizit, wenn der Hook mehr als ein Argument übergibt
Verwenden Sie Prioritätswerte bewusst — dokumentieren Sie, warum nicht standardmäßige Prioritäten gewählt wurden
Registrieren Sie Hooks innerhalb von Klassenkonstruktoren oder dedizierten register_hooks()-Methoden, niemals im globalen Geltungsbereich einer Plugin-Datei
Begrenzen Sie die Hook-Registrierung auf den Kontext, in dem sie benötigt wird (Admin, Frontend, REST API)

Callback-Implementierung:

Prüfen Sie immer DOING_AUTOSAVE, DOING_CRON und wp_is_json_request() wo relevant
Verifizieren Sie Nonces mit check_admin_referer() oder check_ajax_referer() bevor Sie Benutzereingaben verarbeiten
Verlassen Sie sich nie auf Rückgabewerte von do_action() — verwenden Sie Filter, wenn Sie Daten zurückbenötigen
Verwenden Sie current_action(), wenn ein Callback mehreren Hooks dient

Benutzerdefiniertes Hook-Design:

Versehen Sie alle benutzerdefinierten Hook-Namen mit dem Präfix Ihres Plugins/Themes
Dokumentieren Sie jeden benutzerdefinierten Hook mit einem vollständigen DocBlock über do_action()

Übergeben Sie genug Argumente, um den Hook nützlich zu machen, ohne unnötig internen Zustand preiszugeben
Bevorzugen Sie do_action() gegenüber do_action_ref_array(), es sei denn, Sie haben einen spezifischen Grund

Leistung und Wartung:

Profilieren Sie Hook-Callbacks mit Query Monitor, bevor Sie in die Produktion deployen
Vermeiden Sie Datenbankabfragen innerhalb von Hooks, die bei jeder Anfrage ausgelöst werden
Verwenden Sie remove_action(), um Drittanbieter-Hooks zu bereinigen, die mit Ihrer Implementierung in Konflikt stehen
Testen Sie Hook-Interaktionen in einer Staging-Umgebung, die die Produktionsinfrastruktur spiegelt

FAQ

Was ist der Unterschied zwischen add_action() und add_filter() in WordPress?

add_action() registriert einen Callback, um Nebeneffekte an einem bestimmten Ausführungspunkt auszuführen — der Rückgabewert wird verworfen. add_filter() registriert einen Callback, um einen Wert zu empfangen, zu modifizieren und zurückzugeben. Eines zu verwenden, wo das andere angemessen ist, ist ein funktionaler Fehler: Ein Filter-Callback, der keinen Wert zurückgibt, macht die gefilterten Daten zunichte.

Warum wird mein add_action()-Callback nicht ausgelöst?

Die häufigsten Ursachen sind: (1) der Hook-Name ist falsch geschrieben, (2) add_action() wird aufgerufen, nachdem der Hook in der aktuellen Anfrage bereits ausgelöst wurde, (3) $accepted_args ist zu niedrig und der Callback erhält falsche Daten, was einen stillen PHP-Fehler verursacht, oder (4) eine bedingte Prüfung innerhalb des Callbacks verhindert die Ausführung. Verwenden Sie Query Monitor, um zu überprüfen, ob der Hook ausgelöst wurde und ob Ihr Callback registriert war.

Kann ich add_action() innerhalb eines anderen Action-Callbacks verwenden?

Ja, und dies ist ein gängiges Muster. Zum Beispiel das Registrieren von Hooks innerhalb von plugins_loaded oder init, um sicherzustellen, dass Abhängigkeiten verfügbar sind. Der innere Hook muss jedoch nach dem äußeren ausgelöst werden, damit die Registrierung wirksam wird.

Was steuert der $priority-Parameter tatsächlich?

Er steuert die Reihenfolge, in der mehrere bei demselben Hook registrierte Callbacks ausgeführt werden. Niedrigere Zahlen werden zuerst ausgeführt. Der Standard ist 10. Gültige Werte umfassen negative Ganzzahlen. Wenn zwei Callbacks dieselbe Priorität teilen, werden sie in der Reihenfolge ausgeführt, in der sie über add_action() registriert wurden.

Wie entferne ich sicher eine Action, die von einem Drittanbieter-Plugin hinzugefügt wurde?

Hängen Sie Ihren remove_action()-Aufruf in eine Action ein, die nach dem Laden des Plugins ausgelöst wird — typischerweise plugins_loaded mit hoher Priorität oder after_setup_theme. Sie müssen den genauen Hook-Namen, die Callback-Referenz und die Priorität aus dem ursprünglichen add_action()-Aufruf übereinstimmen. Für Objektmethoden benötigen Sie Zugang zur selben Objektinstanz, die seriöse Plugins über eine globale Variable oder eine statische get_instance()-Methode bereitstellen.