Własna wtyczka czy motyw potomny — co wybrać?

Podstawowy podział: funkcja vs wygląd

Zarówno wtyczka jak i motyw potomny pozwalają rozszerzyć WordPress o własny kod PHP. Różnica jest koncepcualna: motyw odpowiada za wygląd i prezentację, a wtyczka odpowiada za funkcjonalność i logikę. Naruszenie tej zasady jest przyczyną wielu problemów z utrzymaniem projektów WordPress.

Wyobraź sobie, że za rok zmieniasz motyw strony na zupełnie nowy design. Jeśli logika sklepu, custom post types czy integracje API siedzą w functions.php starego motywu — tracisz je wszystkie. Jeśli są w dedykowanej wtyczce — przeżywają zmianę motywu bez żadnej modyfikacji.

Kiedy wybrać wtyczkę?

Wtyczka to właściwy wybór dla:

• Custom Post Types i taksonomii — niezależnie od motywu Twoje typy treści powinny przeżyć jego zmianę
• Integracji z zewnętrznymi API — płatności, CRM, systemy rezerwacji
• Shortcody i bloki Gutenberga — przenośna funkcjonalność dla edytora
• Modyfikacji zachowania WordPressa — np. własne role użytkowników, workflow publikacji
• Funkcji wielokrotnego użytku — chcesz zainstalować ten sam kod w kilku projektach
• Ciężkich integracji — kod z zależnościami (Composer, klasy, namespace)

<?php
// Przykład: CPT w dedykowanej wtyczce — przeżyje zmianę motywu
// Plik: plugins/moj-portfolio/includes/post-types.php

function moj_portfolio_cpt(): void {
    register_post_type( 'portfolio', [
        'public'   => true,
        'label'    => 'Portfolio',
        'supports' => [ 'title', 'editor', 'thumbnail' ],
        'rewrite'  => [ 'slug' => 'portfolio' ],
    ]);
}
add_action( 'init', 'moj_portfolio_cpt' );

Kiedy wybrać motyw potomny?

Motyw potomny jest właściwym narzędziem gdy:

• Nadpisujesz szablony PHP motywu nadrzędnego — np. single.php, archive.php
• Modyfikujesz style CSS motywu — dodajesz własne reguły lub nadpisujesz istniejące
• Tworzysz własne szablony stron — nowe szablony widoczne w metaboxie "Szablon strony"
• Rejestrujesz menu i wsparcie motywu — add_theme_support(), register_nav_menus()
• Enqueue'ujesz zasoby specyficzne dla motywu — style i skrypty powiązane z designem

<?php
// Przykład: w functions.php motywu potomnego
// Nadpisanie długości excerptów i style — logika prezentacyjna

function dziecko_excerpt( int $len ): int { return 22; }
add_filter( 'excerpt_length', 'dziecko_excerpt' );

function dziecko_style(): void {
    wp_enqueue_style( 'dziecko-style', get_stylesheet_uri() );
}
add_action( 'wp_enqueue_scripts', 'dziecko_style' );

Szara strefa — co gdy jest wątpliwość?

W praktyce nigdy nie wszystko jest czarno-białe. Oto typowe przypadki graniczne:

<?php
// Enqueue GSAP — logika animacji czy styl?
// --> Zależy od projektu: jeśli GSAP jest częścią designu motywu = motyw
//     Jeśli jest modułem niezależnej funkcji (np. slider) = wtyczka

// Rejestracja fontu Google
// --> Ścisłe powiązanie z designem = motyw potomny

// Shortcode [galeria] wyświetlający portfolio
// --> Funkcja przenośna, niezależna od wyglądu = wtyczka

// Modyfikacja title tag
// --> Prezentacyjna (SEO meta) = może być motyw, ale lepiej wtyczka (Rank Math)

Praktyczna architektura projektu

W dojrzałym projekcie WordPress podział wygląda zazwyczaj tak:

• Wtyczka projektowa (projekt-core) — CPT, taksonomie, shortcody, bloki, integracje API, role użytkowników
• Motyw potomny — szablony PHP, CSS, enqueue zasobów, menu, sidebar, footer
• Wtyczki zewnętrzne — WooCommerce, Rank Math, WPForms, ACF — instalowane ze sprawdzonych źródeł

Podsumowanie

Wybór między wtyczką a motywem potomnym to tak naprawdę wybór między przenośnością a powiązaniem z motywem. W każdym projekcie WordPress warto zadać sobie jedno pytanie przy każdej nowej funkcji: "Co stanie się z tym kodem gdy zmienię motyw za rok?" Odpowiedź na to pytanie wskazuje właściwe miejsce na kod.