Akcje WordPress wyjaśnione: Kompletny przewodnik dewelopera po Hooks API

WordPress Actions to podstawowy komponent Hooks API, który pozwala programistom wykonywać niestandardowe funkcje w precyzyjnie zdefiniowanych punktach cyklu życia żądania WordPress — bez dotykania plików rdzenia. Gdy hook akcji zostaje wywołany, każda funkcja zarejestrowana do tego hooka uruchamia się w kolejności priorytetów, umożliwiając modułowe, łatwe w utrzymaniu i bezpieczne dla aktualizacji dostosowywanie.

Jeśli budujesz wtyczkę, rozwijasz motyw lub zarządzasz samodzielnie hostowaną instalacją WordPress na środowisku VPS Hosting, opanowanie Actions jest niezbędne. Są one głównym mechanizmem, na którym opiera się architektura samego WordPress — nie tylko narzędziem rozszerzeń dla podmiotów trzecich.

Jak WordPress Actions faktycznie działają pod maską

WordPress utrzymuje globalny rejestr o nazwie $wp_filter, który przechowuje wszystkie zarejestrowane hooki — zarówno akcje, jak i filtry. Gdy wywoływane jest do_action(), WordPress wyszukuje wpis tego hooka w $wp_filter, sortuje zarejestrowane wywołania zwrotne według priorytetu i wykonuje je sekwencyjnie.

Kluczowe rozróżnienie, które wiele poradników pomija: Actions działają na zasadzie „odpal i zapomnij”. Wykonują wywołania zwrotne, ale odrzucają wszelkie zwracane wartości. Jeśli potrzebujesz przechwycić i zmodyfikować dane, to zadanie Filtrów, nie Actions. Mylenie tych dwóch jest jednym z najczęstszych błędów architektonicznych w tworzeniu wtyczek WordPress.

Przepływ wykonania wygląda następująco:

1. Rdzeń WordPress (lub wtyczka/motyw) wywołuje do_action( 'hook_name', ...$args ).
2. WordPress rozwiązuje wszystkie wywołania zwrotne zarejestrowane do hook_name z $wp_filter.
3. Wywołania zwrotne są sortowane według wartości $priority (rosnąco — niższe liczby uruchamiają się pierwsze).
4. Każde wywołanie zwrotne jest wywoływane z dostarczonymi argumentami.
5. Zwracane wartości są po cichu ignorowane.
6. Wykonanie kontynuuje się w kodzie źródłowym po powrocie do_action().

Ta architektura oznacza, że źle napisane wywołanie zwrotne zarejestrowane do wczesnego hooka, takiego jak init, może zablokować całe żądanie. Zawsze profiluj wywołania zwrotne hooków na środowisku testowym przed wdrożeniem na produkcję.

Rejestrowanie Actions za pomocą add_action()

Funkcja add_action() rejestruje wywoływalny element PHP do nazwanego hooka akcji. Jej pełna sygnatura to:

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

Wyjaśnienie parametrów:

$hook_name — Dokładny identyfikator tekstowy hooka akcji (np. wp_login, save_post).
$callback — Dowolny prawidłowy wywoływalny element PHP: nazwana funkcja, funkcja anonimowa, metoda statyczna array( 'MyClass', 'method' ) lub metoda obiektu array( $object, 'method' ).
$priority — Kolejność wykonania względem innych wywołań zwrotnych na tym samym hooku. Domyślnie 10. Wywołania zwrotne o tym samym priorytecie uruchamiają się w kolejności rejestracji.
$accepted_args — Ile argumentów z do_action() przekazać do wywołania zwrotnego. Domyślnie 1. Musisz ustawić to poprawnie, inaczej wywołanie zwrotne otrzyma skróconą listę argumentów.

Podstawowy przykład: Podpięcie do 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 );
Zauważ, że accepted_args jest ustawione na 2. Pominięcie tego i pozostawienie domyślnego 1 oznacza, że wywołanie zwrotne otrzymuje tylko $user_login i nigdy nie widzi obiektu WP_User — cichy błąd, który jest notorycznie trudny do wyśledzenia.
Używanie metod obiektów i domknięć
Nowoczesne tworzenie wtyczek WordPress preferuje enkapsulację logiki wewnątrz klas:
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();
Anonimowe domknięcia również działają, ale nie można ich usunąć za pomocą remove_action() później, ponieważ PHP nie może niezawodnie porównywać referencji do funkcji anonimowych. Używaj nazwanych metod, gdy potrzebujesz możliwości wyrejestrowania.
Usuwanie Actions za pomocą remove_action()
Możesz wyrejestrować dowolne wywołanie zwrotne — w tym te dodane przez inne wtyczki lub motywy — używając remove_action(). Priorytet musi dokładnie odpowiadać temu, który był użyty w add_action():
remove_action( 'wp_head', 'wp_generator' ); // Removes WordPress version meta tag
W przypadku metod obiektów potrzebujesz referencji do tej samej instancji obiektu:
// Inside a plugin that exposes its instance
global $my_plugin_instance;
remove_action( 'save_post', array( $my_plugin_instance, 'handle_save' ), 20 );
Częsta pułapka: wywoływanie remove_action() przed uruchomieniem oryginalnego add_action(). Zawsze podpinaj usuwanie do akcji, która uruchamia się po załadowaniu docelowej wtyczki — zazwyczaj plugins_loaded lub after_setup_theme.
Informacje o podstawowych hookach akcji WordPress
Poniższa tabela obejmuje najbardziej operacyjnie istotne hooki akcji, ich kontekst uruchamiania i praktyczne przypadki użycia.




Nazwa hooka
Uruchamia się gdy
Typowe przypadki użycia
Przekazywane argumenty




muplugins_loaded
Załadowano wtyczki must-use
Wczesne bootstrapowanie, stałe
0


plugins_loaded
Załadowano wszystkie wtyczki
Sprawdzanie kompatybilności między wtyczkami
0


init
Po załadowaniu WP, przed nagłówkami
Rejestracja CPT, taksonomii, reguł przepisywania
0


wp_loaded
Po init, wszystko załadowane
Rejestracja REST API, późne zadania inicjalizacyjne
0


wp_enqueue_scripts
Ładowanie zasobów front-end
Kolejkowanie CSS/JS dla motywów i wtyczek
0


wp_head
Wewnątrz tagu <head>
Metatagi, style inline, fragmenty kodu analitycznego
0


wp_footer
Przed </body>
Odroczone skrypty, piksele śledzące
0


admin_init
Ładowanie strony administracyjnej
Rejestracja Settings API, sprawdzanie uprawnień
0


admin_enqueue_scripts
Ładowanie zasobów administracyjnych
Kolejkowanie CSS/JS tylko dla panelu administracyjnego
1 ($hook_suffix)


save_post
Post zapisany lub zaktualizowany
Aktualizacje meta, synchronizacja z zewnętrznym API, powiadomienia
3


wp_login
Użytkownik się uwierzytelnia
Rejestrowanie audytu, zarządzanie sesją
2


user_register
Nowy użytkownik utworzony
E-maile powitalne, synchronizacja z CRM, przypisanie roli
1 ($user_id)


wp_logout
Użytkownik się wylogowuje
Czyszczenie sesji, zdarzenia analityczne
1 ($user_id)


switch_theme
Zmiana aktywnego motywu
Czyszczenie pamięci podręcznej, migracja opcji
2


wp_trash_post
Post przeniesiony do kosza
Czyszczenie powiązanych danych, synchronizacja zewnętrzna
1 ($post_id)


rest_api_init
Inicjalizacja REST API
Rejestracja niestandardowych tras REST
0


template_redirect
Przed załadowaniem szablonu
Przekierowania, kontrola dostępu
0




do_action() vs do_action_ref_array(): Kiedy każda z nich ma zastosowanie
Obie funkcje wywołują hook akcji, ale różnią się sposobem przekazywania argumentów.
do_action()
Standardowa funkcja. Argumenty są przekazywane przez wartość — wywołania zwrotne otrzymują kopie.
do_action( 'my_plugin_after_import', $import_id, $result_count, $errors );
do_action_ref_array()
Argumenty są przekazywane jako tablica, a obiekty w tej tablicy są przekazywane przez referencję (obiekty PHP są zawsze domyślnie referencyjne od PHP 5). Jest to przydatne głównie do zachowania kompatybilności ze starszym kodem lub gdy jawnie potrzebujesz, aby wywołania zwrotne mutowały wspólną strukturę danych.
$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
Praktyczne wskazówki: W nowoczesnym PHP (7.4+) różnica w zachowaniu między tymi dwoma funkcjami jest minimalna dla obiektów. Używaj do_action() domyślnie. Sięgaj po do_action_ref_array() tylko podczas integracji ze starszym kodem, który jawnie tego oczekuje, lub gdy potrzebujesz, aby wywołania zwrotne mutowały wartość prymitywną (jak liczba całkowita) przekazaną przez referencję.
Tworzenie i dokumentowanie niestandardowych hooków akcji
Budując wtyczkę lub motyw przeznaczony do rozszerzania przez innych, powinieneś definiować własne hooki akcji. W ten sposób udostępniasz powierzchnię API bez dawania podmiotom trzecim bezpośredniego dostępu do swoich wewnętrznych elementów.
/**
 * 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 );
Zawsze dokumentuj swoje hooki za pomocą DocBlock bezpośrednio powyżej do_action(). To właśnie zasila generator dokumentacji dla programistów WordPress i sprawia, że Twoja wtyczka jest profesjonalna. Zewnętrzni programiści mogą wtedy podpiąć się w czysty sposób:
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 Filtry: Definitywne porównanie
To najważniejsze konceptualne rozróżnienie w całym Hooks API WordPress.




Wymiar
Actions
Filtry




Główny cel
Wykonywanie efektów ubocznych w określonym momencie
Przechwytywanie i modyfikowanie danych


Zwracana wartość
Całkowicie ignorowana
Musi zwracać (zmodyfikowaną) wartość


Podstawowa funkcja
do_action()
apply_filters()


Rejestracja
add_action()
add_filter()


Typowe użycie
Wysyłanie e-maili, zapis do bazy danych, kolejkowanie zasobów
Modyfikowanie treści postów, zmiana argumentów zapytań


Może skrócić wykonanie?
Nie (wszystkie wywołania zwrotne zawsze się uruchamiają)
Nie (ale można zwrócić wcześniej wewnątrz wywołania zwrotnego)


Mutacja danych
Nie jest zamierzonym wzorcem
Główny cel




Kluczowa zasada architektoniczna: Jeśli używasz add_filter(), ale nie zwracasz wartości z wywołania zwrotnego, wprowadziłeś błąd — filtrowana wartość stanie się null lub false w zależności od kontekstu. I odwrotnie, jeśli używasz add_action() i polegasz na zwracanej wartości, nieprawidłowo używasz API.
Konflikty priorytetów i kolejność wykonania
Zarządzanie priorytetami staje się krytyczne w złożonych ekosystemach wtyczek. Rozważ scenariusz, w którym WooCommerce, wtyczka do buforowania i Twój niestandardowy kod podpinają się do save_post:
// 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 );
Przypadki brzegowe, które warto znać:

Ujemne priorytety są prawidłowe w WordPress. add_action( 'init', 'my_func', -1 ) uruchamia się przed wszystkim o priorytecie 0 lub 10.
Ten sam priorytet, wiele wywołań zwrotnych — wykonują się w kolejności wywołania add_action(). Kolejność ładowania wtyczek (określona alfabetycznie przez nazwę pliku lub wtyczki Plugin Order) wpływa zatem na zachowanie.
Rekurencyjne hooki — wywoływanie do_action() dla tego samego hooka wewnątrz wywołania zwrotnego dla tego hooka jest technicznie możliwe, ale tworzy nieskończone pętle. WordPress nie chroni przed tym.
Późna rejestracja hooka — jeśli wywołasz add_action( 'init', ... ) po tym, jak init już się uruchomił, Twoje wywołanie zwrotne nigdy nie wykona się w tym żądaniu. Jest to częste źródło błędów w kodzie uruchamianym warunkowo.

Wzorce produkcyjne z rzeczywistego świata
Wzorzec 1: Rozdzielony system zdarzeń
Używaj niestandardowych akcji do rozdzielania komponentów wtyczki, unikając bezpośrednich wywołań funkcji między modułami:
// 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 );
Ten wzorzec oznacza, że możesz całkowicie wyłączyć moduł analityczny bez dotykania kodu przetwarzającego zamówienia.
Wzorzec 2: Warunkowa rejestracja hooków
Unikaj bezwarunkowego rejestrowania hooków na najwyższym poziomie. Ogranicz je do kontekstu, w którym są potrzebne:
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 );
} );
Wzorzec 3: Jednorazowe akcje z remove_action() wewnątrz wywołania zwrotnego
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' );
Kwestie wydajności w zarządzanych środowiskach
W instalacjach WordPress o dużym ruchu — niezależnie od tego, czy działają na planie VPS Hosting czy Serwer Dedykowany — skumulowany koszt źle zoptymalizowanych hooków jest mierzalny.
Narzędzia do profilowania:

Wtyczka Query Monitor: Pokazuje każdy hook, który się uruchomił, każde wywołanie zwrotne, które zostało wykonane, oraz czas wykonania na wywołanie zwrotne.
Xdebug + KCacheGrind: Do głębokiego profilowania ścieżek wykonania wywołań zwrotnych.
New Relic APM: Do monitorowania wydajności hooków na poziomie produkcyjnym.

Zasady optymalizacji:

Przenieś kosztowne operacje (zapytania do bazy danych, żądania HTTP, operacje I/O na plikach) z hooków uruchamianych przy każdym ładowaniu strony (init, wp_head) do hooków uruchamianych tylko gdy jest to konieczne (save_post, user_register).
Używaj transientów lub buforowania obiektów do memoizacji wyników kosztownych obliczeń wewnątrz wywołań zwrotnych hooków.
Unikaj bezwarunkowego rejestrowania setek wywołań add_action() podczas ładowania wtyczki. Leniwie rejestruj hooki tylko wtedy, gdy aktywna jest odpowiednia strona administracyjna lub kontekst.
Na serwerach z włączonym OPcache (które powinny mieć wszystkie prawidłowo skonfigurowane środowiska PHP), narzut samej rejestracji hooków jest pomijalny — koszt leży w tym, co wywołania zwrotne *robią*, a nie w samej rejestracji.

Jeśli zarządzasz własnym stosem WordPress, zapewnienie, że Twój serwer działa na PHP 8.1+ z OPcache, pamięcią podręczną kodu bajtowego i pamięcią podręczną obiektów, taką jak Redis lub Memcached, będzie miało znacznie większy wpływ na wydajność niż mikro-optymalizacja priorytetów hooków.
WordPress Actions w kontekście tworzenia wtyczek i motywów
Tworząc wtyczkę przeznaczoną do repozytorium WordPress.org lub dystrybucji komercyjnej, Twoje użycie Hooks API bezpośrednio determinuje jakość kodu i oceny kompatybilności.
Najlepsze praktyki dla hooków klasy produkcyjnej:

Zawsze sprawdzaj DOING_AUTOSAVE wewnątrz wywołań zwrotnych save_post, aby uniknąć uruchamiania kosztownej logiki przy autozapisach.
Weryfikuj nonce’y i uprawnienia wewnątrz każdego wywołania zwrotnego hooka, które przetwarza dane przesłane przez użytkownika. Nigdy nie zakładaj, że sam hook zapewnia bezpieczeństwo.
Używaj current_action(), aby określić, który konkretny hook wywołał Twoje wywołanie zwrotne, gdy ta sama funkcja jest zarejestrowana do wielu hooków.
Używaj przestrzeni nazw dla niestandardowych nazw hooków, aby uniknąć kolizji: my_plugin_event_name, nie event_name.
Wersjonuj swoje hooki w dokumentacji, aby programiści wiedzieli, kiedy hook został wprowadzony i kiedy może zostać wycofany.

Dla zespołów wdrażających WordPress na infrastrukturze z Panelami Sterowania VPS, utrzymywanie środowisk testowych odzwierciedlających produkcję jest niezbędne do bezpiecznego testowania interakcji hooków przed wdrożeniem.
Zabezpieczanie instalacji WordPress wraz z niestandardowymi Actions
Niestandardowe hooki akcji przetwarzające zewnętrzne dane, obsługujące zdarzenia uwierzytelniania lub wchodzące w interakcję z systemem plików wprowadzają obszar podatności na ataki. Połącz tworzenie hooków z odpowiednio zabezpieczonym środowiskiem hostingowym.
Upewnij się, że Twoja instalacja WordPress używa HTTPS — Certyfikat SSL jest obowiązkowy dla każdej witryny obsługującej uwierzytelnianie użytkowników lub przesyłanie formularzy. Wywołania zwrotne hooków uruchamiane przy wp_login lub user_register przetwarzają wrażliwe dane przez sieć; bez TLS te dane są narażone niezależnie od tego, jak dobrze napisany jest Twój kod PHP.
Ponadto, jeśli Twoja wtyczka używa wp_mail() wewnątrz wywołań zwrotnych akcji (powszechny wzorzec dla powiadomień), konfiguracja poczty i reputacja Twojego serwera bezpośrednio wpływają na dostarczalność. Rozważ dedykowane rozwiązanie Hosting Poczty E-mail z odpowiednimi rekordami SPF, DKIM i DMARC zamiast polegania na sendmail na poziomie serwera.
Macierz decyzji technicznych i kluczowe wnioski
Użyj tej listy kontrolnej podczas implementowania WordPress Actions w dowolnym projekcie:
Rejestracja hooków:

Ustaw $accepted_args jawnie, gdy hook przekazuje więcej niż jeden argument
Używaj wartości priorytetów celowo — dokumentuj, dlaczego wybrano priorytety inne niż domyślne
Rejestruj hooki wewnątrz konstruktorów klas lub dedykowanych metod register_hooks(), nigdy w globalnym zakresie pliku wtyczki
Ogranicz rejestrację hooków do kontekstu, w którym jest potrzebna (panel administracyjny, front-end, REST API)

Implementacja wywołań zwrotnych:

Zawsze sprawdzaj DOING_AUTOSAVE, DOING_CRON i wp_is_json_request() tam, gdzie jest to istotne
Weryfikuj nonce’y za pomocą check_admin_referer() lub check_ajax_referer() przed przetworzeniem jakichkolwiek danych użytkownika
Nigdy nie polegaj na zwracanych wartościach z do_action() — używaj filtrów, jeśli potrzebujesz danych z powrotem
Używaj current_action() gdy jedno wywołanie zwrotne obsługuje wiele hooków

Projektowanie niestandardowych hooków:

Używaj przestrzeni nazw dla wszystkich niestandardowych nazw hooków z prefiksem Twojej wtyczki/motywu
Dokumentuj każdy niestandardowy hook pełnym DocBlock powyżej do_action()

• Przekazuj wystarczającą liczbę argumentów, aby hook był użyteczny, nie ujawniając niepotrzebnie stanu wewnętrznego
• Preferuj do_action() nad do_action_ref_array(), chyba że masz konkretny powód

Wydajność i utrzymanie:

• Profiluj wywołania zwrotne hooków za pomocą Query Monitor przed wdrożeniem na produkcję
• Unikaj zapytań do bazy danych wewnątrz hooków uruchamianych przy każdym żądaniu
• Używaj remove_action() do czyszczenia hooków podmiotów trzecich, które kolidują z Twoją implementacją
• Testuj interakcje hooków w środowisku testowym odzwierciedlającym infrastrukturę produkcyjną

FAQ

Jaka jest różnica między add_action() a add_filter() w WordPress?

add_action() rejestruje wywołanie zwrotne do wykonywania efektów ubocznych w określonym punkcie wykonania — zwracana wartość jest odrzucana. add_filter() rejestruje wywołanie zwrotne do odbierania, modyfikowania i zwracania wartości. Używanie jednego tam, gdzie odpowiedni jest drugi, jest błędem funkcjonalnym: wywołanie zwrotne filtra, które nie zwraca wartości, unieważni filtrowane dane.

Dlaczego moje wywołanie zwrotne add_action() nie uruchamia się?

Najczęstsze przyczyny to: (1) nazwa hooka jest błędnie napisana, (2) add_action() jest wywoływane po tym, jak hook już się uruchomił w bieżącym żądaniu, (3) $accepted_args jest zbyt niskie i wywołanie zwrotne otrzymuje błędne dane powodując cichy błąd PHP, lub (4) sprawdzenie warunkowe wewnątrz wywołania zwrotnego uniemożliwia wykonanie. Użyj Query Monitor, aby sprawdzić, czy hook się uruchomił i czy Twoje wywołanie zwrotne zostało zarejestrowane.

Czy mogę używać add_action() wewnątrz innego wywołania zwrotnego akcji?

Tak, i jest to powszechny wzorzec. Na przykład rejestrowanie hooków wewnątrz plugins_loaded lub init, aby zapewnić dostępność zależności. Jednak wewnętrzny hook musi uruchomić się po zewnętrznym, aby rejestracja odniosła skutek.

Co faktycznie kontroluje parametr $priority?

Kontroluje kolejność, w jakiej wiele wywołań zwrotnych zarejestrowanych do tego samego hooka jest wykonywanych. Niższe liczby uruchamiają się pierwsze. Domyślna wartość to 10. Prawidłowe wartości obejmują ujemne liczby całkowite. Gdy dwa wywołania zwrotne mają ten sam priorytet, wykonują się w kolejności, w jakiej zostały zarejestrowane za pomocą add_action().

Jak bezpiecznie usunąć akcję dodaną przez wtyczkę podmiotu trzeciego?

Podepnij wywołanie remove_action() do akcji uruchamianej po załadowaniu wtyczki — zazwyczaj plugins_loaded z wysokim priorytetem lub after_setup_theme. Musisz dopasować dokładną nazwę hooka, referencję wywołania zwrotnego i priorytet użyty w oryginalnym wywołaniu add_action(). W przypadku metod obiektów potrzebujesz dostępu do tej samej instancji obiektu, którą renomowane wtyczki udostępniają przez zmienną globalną lub statyczną metodę get_instance().