Hierarchia Szablonów WordPress: Kompletny Przewodnik Techniczny

WordPress's Template Hierarchy to deterministyczny system rozwiązywania szablonów, którego WordPress używa do wyboru pliku szablonu PHP renderującego dane żądanie strony. Gdy odwiedzający ładuje dowolny URL w witrynie, WordPress ocenia kontekst zapytania — typ wpisu, taksonomię, slug, ID i inne — a następnie przechodzi przez priorytetową listę kandydujących nazw plików, aż znajdzie dopasowanie w katalogu aktywnego motywu. Jeśli nie istnieje żaden konkretny szablon, następuje powrót do index.php.

Głębokie zrozumienie tego systemu nie jest opcjonalne w poważnym tworzeniu stron WordPress. Jest to fundament każdego niestandardowego układu, każdego nadpisania motywu i każdej optymalizacji wydajności związanej z buforowaniem szablonów. Niezależnie od tego, czy prowadzisz publikację z dużą ilością treści, sklep WooCommerce, czy bezgłową konfigurację WordPress, hierarchia zarządza tym, jaki PHP wykonuje się przy każdym pojedynczym ładowaniu strony.

Czym naprawdę jest hierarchia szablonów

W swojej istocie hierarchia szablonów to łańcuch wyszukiwania wbudowany w rdzeń WordPress (wp-includes/class-wp-query.php i wp-includes/template.php). Gdy WordPress kończy parsowanie żądania i wypełnianie globalnego obiektu $wp_query, wewnętrznie wywołuje odpowiedniki get_template_part() w celu rozwiązania właściwego szablonu. Rozwiązanie nie jest losowe — to ściśle uporządkowana lista nazw plików sprawdzanych w katalogu głównym motywu.

Kluczowy wgląd architektoniczny, który większość poradników pomija: WordPress nie skanuje katalogu motywu. Konstruuje priorytetową tablicę kandydujących nazw plików na podstawie zmiennych zapytania, a następnie sprawdza każdy plik za pomocą locate_template(). To rozróżnienie ma znaczenie podczas debugowania brakujących szablonów lub budowania programowych generatorów motywów.

Łańcuch awaryjny zawsze kończy się na index.php. Ten plik jest jedynym plikiem szablonu, którego WordPress wymaga od każdego motywu, zgodnie ze standardami tworzenia motywów.

Podstawowe pliki szablonów, które każdy motyw musi rozumieć

Zwróć uwagę na wpis singular.php — to szablon, który wielu programistów całkowicie pomija. Wprowadzony w WordPress 4.3, znajduje się między single.php/page.php a index.php w hierarchii, działając jako ujednolicony catch-all dla dowolnego widoku pojedynczej treści. Jeśli Twój motyw zawiera singular.php, przechwyci przypadki, gdy nie istnieje ani single.php, ani page.php.

Pełna kolejność rozwiązywania szablonów według typu strony

Pojedyncze wpisy na blogu

Gdy odwiedzający żąda standardowego wpisu (post_type = 'post'), WordPress sprawdza w dokładnie tej kolejności:

single-post-{slug}.php (WordPress 4.4+, np. single-post-hello-world.php)
single-post.php

1. single.php
2. singular.php
3. index.php

Wariant oparty na slugu w kroku 1 jest rzadko dokumentowany, ale niezwykle przydatny do nadania pojedynczemu flagowemu wpisowi całkowicie unikalnego układu bez dotykania żadnego innego szablonu.

Niestandardowe typy wpisów

Dla niestandardowego typu wpisu zarejestrowanego jako portfolio:

1. single-portfolio-{slug}.php
2. single-portfolio.php
3. single.php
4. singular.php
5. index.php

Dla jego archiwum (wymaga 'has_archive' => true w register_post_type()):

1. archive-portfolio.php
2. archive.php
3. index.php

Częsta pułapka: rejestrowanie niestandardowego typu wpisu z 'has_archive' => false (domyślnie) i zastanawianie się, dlaczego archive-portfolio.php nigdy się nie ładuje. URL archiwum po prostu zwraca 404 w takim przypadku.

Strony statyczne

1. Plik szablonu ustawiony przez meta box Atrybuty strony (niestandardowy szablon strony)
2. page-{slug}.php
3. page-{ID}.php
4. page.php
5. singular.php
6. index.php

Niestandardowe szablony stron to pliki PHP w katalogu motywu, które zawierają komentarz nagłówkowy pliku:

<?php
/**
 * Template Name: Full Width Layout
 * Template Post Type: page
 */

Deklaracja Template Post Type (WordPress 4.7+) ogranicza, które typy wpisów mogą używać tego szablonu z edytora. Bez niej szablon pojawia się w menu rozwijanym Atrybuty strony tylko dla stron.

Archiwa kategorii

1. category-{slug}.php
2. category-{ID}.php
3. category.php
4. archive.php
5. index.php

Archiwa niestandardowych taksonomii

Dla taksonomii zarejestrowanej jako genre z slugiem terminu thriller:

1. taxonomy-genre-thriller.php
2. taxonomy-genre.php
3. taxonomy.php
4. archive.php
5. index.php

Archiwa autorów

1. author-{user_nicename}.php
2. author-{user_ID}.php
3. author.php
4. archive.php
5. index.php

Strona główna (krytyczny przypadek brzegowy)

To najbardziej niezrozumiała część hierarchii. WordPress rozróżnia dwa scenariusze strony głównej:

Scenariusz A — Indeks wpisów na blogu jako strona główna (Ustawienia > Czytanie: „Najnowsze wpisy”):

1. front-page.php
2. home.php
3. index.php

Scenariusz B — Strona statyczna jako strona główna (Ustawienia > Czytanie: „Statyczna strona”):

1. front-page.php

page.php (jeśli nie istnieje front-page.php)
index.php

Kluczowy niuans: front-page.php ma pierwszeństwo w obu scenariuszach. Jeśli front-page.php istnieje w Twoim motywie, zawsze renderuje stronę główną niezależnie od ustawień Czytania. To zaskakuje wielu programistów, którzy tworzą front-page.php dla statycznej strony głównej, ale zapominają, że nadpisze ona również indeks bloga, jeśli później zmienią to ustawienie.

Wyniki wyszukiwania i 404

Wyniki wyszukiwania:

1. search.php
2. index.php

Strony błędu 404:

1. 404.php
2. index.php

Dobrze zaprojektowany 404.php to zasób konwersji, a nie afterthought. Powinien zawierać formularz wyszukiwania, linki do popularnych treści i przejrzystą nawigację — wszystko to wymaga zrozumienia systemu szablonów, aby poprawnie zaimplementować.

Jak WordPress rozwiązuje szablony wewnętrznie

Zrozumienie wewnętrznej mechaniki pomaga podczas debugowania lub rozszerzania systemu. Proces rozwiązywania w wp-includes/template.php działa następująco:

// Simplified representation of WordPress template resolution
function get_query_template( $type, $templates = array() ) {
    $type = preg_replace( '|[^a-z0-9-]+|', '', $type );

    if ( empty( $templates ) ) {
        $templates = array( "{$type}.php" );
    }

    // Fires before template resolution — allows plugins/themes to modify the list
    $templates = apply_filters( "_{$type}_template_hierarchy", $templates );

    $template = locate_template( $templates );

    // Fires after template is located — allows final override
    $template = apply_filters( "{$type}_template", $template, $type, $templates );

    return $template;
}

Dwa hooki filtrów są tu kluczowe:

_{$type}_template_hierarchy — uruchamia się przed wyszukiwaniem pliku, pozwalając wstrzyknąć dodatkowych kandydatów do tablicy
{$type}_template — uruchamia się po zlokalizowaniu pliku, pozwalając całkowicie zamienić rozwiązaną ścieżkę szablonu

Te hooki są sposobem, w jaki wtyczki page builderów, sieci multisite i WooCommerce nadpisują szablony bez dotykania plików motywu.
Programowe nadpisywanie hierarchii szablonów
Wstrzykiwanie niestandardowej ścieżki szablonu
add_filter( 'single_template_hierarchy', function( $templates ) {
    // Prepend a plugin-directory template before theme templates are checked
    if ( is_singular( 'portfolio' ) ) {
        array_unshift( $templates, plugin_dir_path( __FILE__ ) . 'templates/single-portfolio.php' );
    }
    return $templates;
} );
Nadpisywanie szablonu po rozwiązaniu
add_filter( 'template_include', function( $template ) {
    if ( is_singular( 'portfolio' ) && current_user_can( 'edit_posts' ) ) {
        // Load a debug template for editors
        $debug_template = get_stylesheet_directory() . '/debug/single-portfolio-debug.php';
        if ( file_exists( $debug_template ) ) {
            return $debug_template;
        }
    }
    return $template;
} );
Filtr template_include to ostatni hook przed załadowaniem pliku szablonu przez WordPress. Otrzymuje w pełni rozwiązaną ścieżkę i musi zwrócić prawidłową ścieżkę pliku.
Części szablonów i funkcja get_template_part()
Części szablonów to wielokrotnie używane fragmenty PHP ładowane przez get_template_part(). Mają własną mini-hierarchię:
// Loads content-video.php if it exists, falls back to content.php
get_template_part( 'template-parts/content', 'video' );
WordPress 5.5 dodał trzeci parametr do przekazywania danych do części szablonów:
get_template_part( 'template-parts/card', 'product', array(
    'post_id' => get_the_ID(),
    'show_price' => true,
) );
Wewnątrz części szablonu pobierz te dane za pomocą:
$args = wp_parse_args( $args, array(
    'post_id'    => 0,
    'show_price' => false,
) );
Eliminuje to potrzebę używania zmiennych globalnych do przekazywania danych między szablonami — znacząca poprawa dla utrzymywalności i testowalności.
Motywy potomne i system nadpisywania szablonów
Motywy potomne rozszerzają hierarchię, dodając katalog motywu potomnego na początku ścieżki wyszukiwania szablonów. Gdy locate_template() działa, sprawdza:

Katalog motywu potomnego (get_stylesheet_directory())
Katalog motywu nadrzędnego (get_template_directory())

Oznacza to, że możesz nadpisać dowolny szablon motywu nadrzędnego, tworząc plik o identycznej nazwie w motywie potomnym. Nie musisz kopiować całego pliku — tylko części, które chcesz zmienić — ale WordPress ładuje plik jako kompletną jednostkę, więc musisz uwzględnić wszystkie wymagane znaczniki.
Częsty błąd motywu potomnego: Kopiowanie functions.php z motywu nadrzędnego do motywu potomnego i oczekiwanie, że zastąpi funkcje nadrzędne. W przeciwieństwie do innych plików szablonów, functions.php w motywie potomnym jest ładowany dodatkowo do functions.php nadrzędnego, a nie zamiast niego. Oba pliki są wykonywane.
Aby stworzyć minimalną strukturę motywu potomnego:
my-child-theme/
├── style.css          (required — contains theme header comment)
├── functions.php      (optional — enqueue parent styles here)
└── single-post.php    (overrides parent's single-post.php)
Nagłówek style.css musi deklarować rodzica:
/*
 Theme Name: My Child Theme
 Template: parent-theme-directory-name
*/
Debugowanie aktywnego szablonu
Metoda 1: Wtyczka Query Monitor
Wtyczka Query Monitor (bezpłatna, WordPress.org) wyświetla rozwiązany plik szablonu i pełną hierarchię kandydatów w panelu paska narzędzi administratora. Jest to najbardziej niezawodne dostępne narzędzie do debugowania i dodaje znikome obciążenie.
Metoda 2: Hook template_include
add_filter( 'template_include', function( $template ) {
    if ( current_user_can( 'manage_options' ) ) {
        echo '<!-- Template: ' . esc_html( str_replace( ABSPATH, '', $template ) ) . ' -->';
    }
    return $template;
} );
Wyświetla ścieżkę szablonu jako komentarz HTML widoczny tylko dla administratorów. Usuń go przed wdrożeniem na produkcję.
Metoda 3: WP_DEBUG i logowanie
Na serwerze deweloperskim włącz logowanie debugowania w wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Następnie dodaj tymczasowe logowanie wewnątrz template_include:
add_filter( 'template_include', function( $template ) {
    error_log( 'Resolved template: ' . $template );
    return $template;
} );
W środowisku VPS Hosting z dostępem root możesz śledzić log debugowania w czasie rzeczywistym:
tail -f /var/www/html/wp-content/debug.log
To podejście jest znacznie bardziej niezawodne niż poleganie na narzędziach do debugowania opartych na przeglądarce podczas rozwiązywania problemów z rozwiązywaniem szablonów na serwerze produkcyjnym lub stagingowym.
WooCommerce i system nadpisywania szablonów
WooCommerce dostarcza własną hierarchię szablonów, która znajduje się na szczycie natywnego systemu WordPress. Szablony WooCommerce znajdują się w wp-content/plugins/woocommerce/templates/ i są ładowane przez własną funkcję wc_get_template(), która sprawdza nadpisania w:

wp-content/themes/your-theme/woocommerce/

Aby nadpisać szablon pojedynczego produktu WooCommerce, skopiuj woocommerce/templates/single-product.php do your-theme/woocommerce/single-product.php. Nigdy nie edytuj plików szablonów wtyczki bezpośrednio — są nadpisywane przy każdej aktualizacji wtyczki.

WooCommerce podpina się również do hooków akcji woocommerce_template_single_*, co daje szczegółową kontrolę nad poszczególnymi sekcjami (cena, zakładki, przycisk dodaj do koszyka) bez nadpisywania całych plików szablonów. Jest to preferowane podejście do drobnych modyfikacji.

Motywy blokowe i hierarchia szablonów w pełnym edytowaniu witryny

WordPress 5.9 wprowadził pełne edytowanie witryny (FSE) z motywami blokowymi, co zmienia praktyczne działanie hierarchii szablonów. Motywy blokowe przechowują szablony jako pliki HTML w katalogu templates/ zamiast plików PHP:

my-block-theme/
├── templates/
│   ├── index.html
│   ├── single.html
│   ├── page.html
│   ├── archive.html
│   └── 404.html
├── parts/
│   ├── header.html
│   └── footer.html
└── theme.json

Logika rozwiązywania podąża za tymi samymi regułami hierarchii, ale WordPress sprawdza teraz również bazę danych pod kątem szablonów dostosowanych przez użytkownika zapisanych przez Edytor witryny. Kolejność wyszukiwania staje się:

1. Szablon zapisany przez użytkownika w bazie danych (typ wpisu wp_template)
2. Plik HTML w katalogu templates/ motywu
3. Plik HTML w katalogu templates/ motywu nadrzędnego
4. Wbudowane szablony awaryjne WordPress

Klasyczne motywy PHP i motywy blokowe mogą współistnieć w instalacji WordPress, ale nie można mieszać szablonów PHP i szablonów blokowych HTML w jednym motywie. Jeśli Twój motyw ma katalog templates/ i prawidłowy theme.json, WordPress traktuje go jako motyw blokowy.

Dla zespołów prowadzących krytyczne pod względem wydajności obciążenia na Serwerach Dedykowanych, zrozumienie tego rozróżnienia jest niezbędne przy ocenie frameworków motywów — motywy blokowe przenoszą renderowanie szablonów na parser bloków, który ma inne charakterystyki buforowania niż wykonywanie szablonów PHP.

Implikacje wydajnościowe hierarchii szablonów

Każde rozwiązanie szablonu wiąże się ze sprawdzaniem systemu plików przez locate_template(). Na witrynie o dużym ruchu może to dodać mierzalne obciążenie, jeśli nie jest buforowane. Kluczowe optymalizacje:

Buforowanie obiektów: Użyj trwałej pamięci podręcznej obiektów (Redis lub Memcached), aby buforować wyniki WP_Query i zmniejszyć liczbę zapytań do bazy danych wpływających na wybór szablonu.

OPcache: Upewnij się, że PHP OPcache jest włączony i prawidłowo skonfigurowany. Ponieważ szablony to pliki PHP, OPcache kompiluje je do kodu bajtowego przy pierwszym ładowaniu i obsługuje kolejne żądania z pamięci. Na prawidłowo skonfigurowanym VPS z cPanel, OPcache jest zazwyczaj domyślnie włączony, ale może wymagać dostrojenia opcache.memory_consumption i opcache.max_accelerated_files dla dużych motywów z wieloma plikami szablonów.

Unikaj niepotrzebnych plików szablonów: Każdy plik szablonu w katalogu motywu jest kandydatem, który locate_template() musi sprawdzić. Motywy z setkami plików szablonów (powszechne w rozdętych komercyjnych motywach) zwiększają I/O systemu plików przy każdym żądaniu bez buforowania. Przeprowadź audyt motywu i usuń nieużywane szablony.

Buforowanie całych stron: Narzędzia takie jak WP Rocket, W3 Total Cache lub buforowanie na poziomie serwera (Nginx FastCGI cache, Varnish) całkowicie omijają wykonywanie szablonów PHP dla anonimowych użytkowników. Rozwiązywanie hierarchii szablonów działa tylko przy braku trafienia w pamięć podręczną.

Praktyczne wzorce dostosowywania

Wzorzec 1: Układ specyficzny dla kategorii bez wtyczki

Utwórz category-news.php w katalogu motywu. WordPress automatycznie używa go dla archiwum kategorii „news”. Żadna wtyczka, żaden hook filtra — tylko plik z właściwą nazwą.

<?php
/**
 * Template for the "news" category archive.
 * Inherits from: category.php → archive.php → index.php
 */
get_header();
?>
<main class="news-archive">
    <h1><?php single_cat_title(); ?></h1>
    <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
        <?php get_template_part( 'template-parts/card', 'news' ); ?>
    <?php endwhile; endif; ?>
    <?php the_posts_pagination(); ?>
</main>
<?php get_footer(); ?>

Wzorzec 2: Układ per-autor dla wyróżnionych współpracowników

// author-jane-smith.php — loads only for the author with nicename "jane-smith"
get_header();
?>
<div class="featured-author-layout">
    <?php get_template_part( 'template-parts/author', 'featured' ); ?>
    <!-- Custom bio section, social links, etc. -->
</div>
<?php get_footer(); ?>

Wzorzec 3: Logika warunkowa wewnątrz index.php

Jeśli budujesz minimalny motyw i chcesz uniknąć wielu plików szablonów, możesz używać tagów warunkowych wewnątrz index.php:

<?php get_header(); ?>

<?php if ( is_front_page() && is_home() ) : ?>
    <?php get_template_part( 'template-parts/home', 'blog-index' ); ?>
<?php elseif ( is_front_page() ) : ?>
    <?php get_template_part( 'template-parts/home', 'static' ); ?>
<?php elseif ( is_single() ) : ?>
    <?php get_template_part( 'template-parts/content', get_post_type() ); ?>
<?php elseif ( is_archive() ) : ?>
    <?php get_template_part( 'template-parts/archive', 'default' ); ?>
<?php else : ?>
    <?php get_template_part( 'template-parts/content', 'none' ); ?>
<?php endif; ?>

<?php get_footer(); ?>

Ten wzorzec jest używany przez motywy takie jak Twenty Twenty-One i jest całkowicie prawidłowy. Kompromisem jest to, że pojedynczy duży index.php staje się trudniejszy w utrzymaniu wraz ze wzrostem złożoności.

Multisite i hierarchia szablonów

W sieci WordPress Multisite każda witryna w sieci może używać innego aktywnego motywu. Hierarchia szablonów działa identycznie dla każdej witryny, ale wtyczki aktywowane na poziomie sieci mogą używać filtrów template_include lub _{$type}_template_hierarchy do wstrzykiwania współdzielonych szablonów we wszystkich witrynach bez duplikowania plików motywu.

Powszechnym wzorcem multisite jest katalog „szablonów sieciowych” poza katalogiem głównym sieci, do którego odwołują się hooki filtrów na poziomie wtyczki. Pozwala to centralnemu zespołowi projektowemu wypychać aktualizacje szablonów do wszystkich witryn jednocześnie — znacząca przewaga operacyjna dla agencji zarządzających dziesiątkami witryn klientów w jednym środowisku Hostingu Współdzielonego lub VPS.

SSL, bezpieczeństwo i uprawnienia plików szablonów

Pliki szablonów to PHP i muszą być traktowane jako kod wykonywalny. Nieprawidłowe uprawnienia plików są powszechnym wektorem ataku. Na serwerze Linux pliki szablonów motywu powinny być własnością użytkownika serwera WWW (zazwyczaj www-data lub nginx) i ustawione na tryb 644:

find /var/www/html/wp-content/themes/your-theme -type f -name "*.php" -exec chmod 644 {} ;
find /var/www/html/wp-content/themes/your-theme -type d -exec chmod 755 {} ;

Nigdy nie ustawiaj plików PHP na 777. Jeśli plik szablonu wymaga dostępu do zapisu (niezwykłe i generalnie niezalecane), użyj 664 z właściwą własnością grupy.

Połączenie instalacji WordPress z prawidłowym Certyfikatem SSL zapewnia, że treści renderowane przez szablony — w tym dynamicznie generowane strony z wrażliwymi danymi użytkowników — są zawsze przesyłane przez HTTPS. Jest to bezwzględnie wymagane dla każdej witryny używającej formularzy kontaktowych, kont użytkowników lub e-commerce.

Hierarchia szablonów: wizualny przepływ

Request URL
    |
    v
WordPress Query Resolution (WP_Query)
    |
    +-- Is it the front page?
    |       front-page.php → home.php → index.php
    |
    +-- Is it a single post?
    |       single-{type}-{slug}.php → single-{type}.php → single.php → singular.php → index.php
    |
    +-- Is it a static page?
    |       [custom template] → page-{slug}.php → page-{ID}.php → page.php → singular.php → index.php
    |
    +-- Is it a category archive?
    |       category-{slug}.php → category-{ID}.php → category.php → archive.php → index.php
    |
    +-- Is it a custom taxonomy?
    |       taxonomy-{tax}-{term}.php → taxonomy-{tax}.php → taxonomy.php → archive.php → index.php
    |
    +-- Is it an author archive?
    |       author-{nicename}.php → author-{ID}.php → author.php → archive.php → index.php
    |
    +-- Is it a date archive?
    |       date.php → archive.php → index.php
    |
    +-- Is it search results?
    |       search.php → index.php
    |
    +-- Is it a 404?
            404.php → index.php

Macierz decyzyjna: kiedy używać którego podejścia do dostosowywania

Kluczowe wnioski techniczne

• index.php jest obowiązkowy. Każdy motyw musi go zawierać. Jest to uniwersalny fallback kończący każdy łańcuch rozwiązywania.
• singular.php to niedoceniana środkowa warstwa. Przechwytuje dowolny pojedynczy wpis lub stronę, gdy nie istnieje ani single.php, ani page.php. Używaj go w minimalnych motywach, aby zmniejszyć liczbę plików.
• front-page.php nadpisuje wszystko dla strony głównej, niezależnie od ustawień Czytania. Jeśli istnieje, zawsze się ładuje.
• Nazewnictwo plików jest wrażliwe na wielkość liter na serwerach Linux. Category-News.php nie będzie pasować, gdy WordPress szuka category-news.php. To cicha awaria, którą trudno debugować bez Query Monitor.
• Filtr template_include to główne nadpisanie. Uruchamia się po zakończeniu całego rozwiązywania hierarchii i daje ostatnią możliwość zamiany dowolnego szablonu z dowolnego powodu.
• Motywy blokowe przechowują szablony jako HTML, nie PHP. Logika hierarchii jest identyczna, ale format pliku i struktura katalogów różnią się fundamentalnie od klasycznych motywów.
• functions.php motywu potomnego ładuje się dodatkowo do nadrzędnego, a nie zamiast niego. Wszystkie inne pliki szablonów podążają za standardowym wzorcem nadpisywania.
• Dostrajanie OPcache ma znaczenie w skali. Na witrynach o dużym ruchu upewnij się, że opcache.max_accelerated_files przekracza całkowitą liczbę plików PHP w instalacji WordPress, w tym wszystkich szablonów motywu.
• Szablony WooCommerce znajdują się poza hierarchią WordPress. Wymagają oddzielnego przepływu pracy nadpisywania przez podkatalog woocommerce/ w motywie.
• Połącz pracę nad dostosowywaniem szablonów z prawidłowo skonfigurowaną domeną i Rejestracją Domeny, aby zapewnić spójność kanonicznego URL na wszystkich stronach renderowanych przez szablony.

FAQ

Co się dzieje, jeśli WordPress nie może znaleźć żadnego pliku szablonu w hierarchii?

WordPress zawsze znajduje index.php, ponieważ jest wymagany dla każdego prawidłowego motywu. Jeśli index.php brakuje, WordPress zgłasza błąd krytyczny i wyświetla pustą stronę lub błąd serwera. Jest to jedyny plik szablonu, którego brak całkowicie psuje witrynę.

Czy mogę używać hierarchii szablonów we wtyczce bez modyfikowania aktywnego motywu?

Tak. Użyj filtra _{$type}_template_hierarchy, aby dodać ścieżkę katalogu wtyczki na początku tablicy kandydatów przed uruchomieniem locate_template(), lub użyj template_include, aby zamienić rozwiązaną ścieżkę szablonu po rozwiązaniu. W ten sposób WooCommerce, bbPress i większość głównych wtyczek wstrzykuje własne szablony bez wymagania modyfikacji motywu.

Dlaczego front-page.php nadpisuje mój indeks bloga, nawet gdy ustawiam „Najnowsze wpisy” w ustawieniach Czytania?

Ponieważ front-page.php ma bezwarunkowe pierwszeństwo dla strony głównej we wszystkich konfiguracjach Czytania. Jeśli chcesz, aby indeks bloga używał home.php, zmień nazwę lub usuń front-page.php z motywu. Wewnątrz front-page.php użyj is_home(), aby wykryć, czy strona główna jest również indeksem bloga i odpowiednio renderować.

Jak sprawdzić, którego pliku szablonu WordPress aktualnie używa dla konkretnej strony?

Zainstaluj wtyczkę Query Monitor. Wyświetla rozwiązaną ścieżkę szablonu i pełną hierarchię kandydatów na pasku narzędzi administratora przy każdym ładowaniu strony. Alternatywnie dodaj tymczasowy filtr template_include, który wyświetla ścieżkę jako komentarz HTML widoczny tylko dla administratorów.

Czy hierarchia szablonów działa tak samo w WordPress Multisite?

Logika rozwiązywania per-witryna jest identyczna. Każda witryna rozwiązuje szablony względem własnego aktywnego motywu. Różnica jest na poziomie sieci: wtyczki aktywowane na poziomie sieci mogą używać hooków filtrów do wstrzykiwania współdzielonych szablonów we wszystkich witrynach, a funkcja get_stylesheet_directory() zwraca prawidłową ścieżkę dla aktywnego motywu każdej indywidualnej witryny, a nie współdzieloną ścieżkę sieciową.