Ierarhia Șabloanelor WordPress: Ghidul Tehnic Complet

WordPress's Template Hierarchy este sistemul determinist de rezolvare pe care WordPress îl folosește pentru a selecta ce fișier șablon PHP redă o anumită cerere de pagină. Când un vizitator încarcă orice URL de pe site-ul dvs., WordPress evaluează contextul interogării — tipul de postare, taxonomia, slug-ul, ID-ul și altele — apoi parcurge o listă prioritizată de nume de fișiere candidate până găsește o potrivire în directorul temei active. Dacă nu există un șablon specific, se revine la index.php.

Înțelegerea acestui sistem la un nivel profund nu este opțională pentru dezvoltarea serioasă WordPress. Este fundația oricărui aspect personalizat, a oricărei suprascrieri de temă și a oricărei optimizări de performanță care implică stocarea în cache a șabloanelor. Indiferent dacă rulați o publicație cu conținut bogat, un magazin WooCommerce sau o configurație WordPress headless, ierarhia guvernează ce PHP se execută la fiecare încărcare de pagină.

Ce este de fapt Ierarhia Șabloanelor

În esență, Ierarhia Șabloanelor este un lanț de căutare integrat în nucleul WordPress (wp-includes/class-wp-query.php și wp-includes/template.php). Când WordPress termină de analizat cererea și de populat obiectul global $wp_query, apelează intern echivalente get_template_part() pentru a rezolva șablonul corect. Rezolvarea nu este aleatorie — este o listă strictă, ordonată de nume de fișiere verificate față de directorul rădăcină al temei dvs.

Perspectiva arhitecturală cheie pe care majoritatea tutorialelor o omit: WordPress nu scanează directorul temei dvs. Construiește un array prioritizat de nume de fișiere candidate pe baza variabilelor de interogare, apoi verifică fiecare fișier folosind locate_template(). Această distincție contează când depanați șabloane lipsă sau construiți generatoare de teme programatice.

Lanțul de rezervă se termină întotdeauna la index.php. Acest fișier este singurul fișier șablon pe care WordPress îl cere fiecărei teme să îl includă, conform standardelor de dezvoltare a temelor.

Fișierele Șablon de Bază pe Care Fiecare Temă Trebuie să le Înțeleagă

Observați intrarea singular.php — acesta este un șablon pe care mulți dezvoltatori îl ignoră complet. Introdus în WordPress 4.3, se află între single.php/page.php și index.php în ierarhie, acționând ca un catch-all unificat pentru orice vizualizare de conținut singular. Dacă tema dvs. include singular.php, va prinde cazurile în care nici single.php nici page.php nu există.

Ordinea Completă de Rezolvare a Șabloanelor pe Tip de Pagină

Postări Individuale de Blog

Când un vizitator solicită o postare standard (post_type = 'post'), WordPress verifică în această ordine exactă:

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

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

Varianta bazată pe slug de la pasul 1 este rareori documentată, dar extrem de utilă pentru a oferi unei singure postări emblematice un aspect complet unic fără a atinge niciun alt șablon.

Tipuri de Postări Personalizate

Pentru un tip de postare personalizat înregistrat ca portfolio:

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

Pentru arhiva sa (necesită 'has_archive' => true în register_post_type()):

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

O capcană comună: înregistrarea unui tip de postare personalizat cu 'has_archive' => false (implicit) și apoi întrebarea de ce archive-portfolio.php nu se încarcă niciodată. URL-ul arhivei returnează pur și simplu un 404 în acel caz.

Pagini Statice

1. Fișier șablon setat prin caseta meta Page Attributes (șablon de pagină personalizat)
2. page-{slug}.php
3. page-{ID}.php
4. page.php
5. singular.php
6. index.php

Șabloanele de pagini personalizate sunt fișiere PHP din directorul temei dvs. care includ un comentariu de antet al fișierului:

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

Declarația Template Post Type (WordPress 4.7+) restricționează ce tipuri de postări pot folosi acest șablon din editor. Fără ea, șablonul apare în meniul derulant Page Attributes doar pentru pagini.

Arhive de Categorii

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

Arhive de Taxonomii Personalizate

Pentru o taxonomie înregistrată ca genre cu un slug de termen thriller:

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

Arhive de Autori

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

Pagina de Start (Caz Limită Critic)

Aceasta este partea cel mai des înțeleasă greșit din ierarhie. WordPress face distincție între două scenarii pentru pagina de start:

Scenariul A — Indexul postărilor de blog ca pagină de start (Setări > Citire: "Cele mai recente postări ale dvs."):

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

Scenariul B — Pagină statică ca pagină de start (Setări > Citire: "O pagină statică"):

1. front-page.php

page.php (dacă nu există front-page.php)
index.php

Nuanța critică: front-page.php are prioritate în ambele scenarii. Dacă front-page.php există în tema dvs., redă întotdeauna pagina de start indiferent de setările de Citire. Acest lucru surprinde mulți dezvoltatori care creează front-page.php pentru o pagină de start statică, dar uită că va suprascrie și indexul de blog dacă schimbă ulterior setarea.

Rezultatele Căutării și 404

Rezultatele căutării:

1. search.php
2. index.php

Paginile de eroare 404:

1. 404.php
2. index.php

Un 404.php bine conceput este un activ de conversie, nu o idee de ultim moment. Ar trebui să includă un formular de căutare, linkuri către conținut popular și navigare clară — toate acestea necesitând înțelegerea sistemului de șabloane pentru a fi implementate corect.

Cum Rezolvă WordPress Șabloanele Intern

Înțelegerea mecanicii interne ajută la depanare sau extinderea sistemului. Procesul de rezolvare din wp-includes/template.php funcționează astfel:

// 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;
}

Două hook-uri de filtre sunt critice aici:

_{$type}_template_hierarchy — se declanșează înainte de căutarea fișierului, permițându-vă să injectați candidați suplimentari în array
{$type}_template — se declanșează după localizarea fișierului, permițându-vă să înlocuiți complet calea șablonului rezolvat

Aceste hook-uri sunt modul în care plugin-urile de page builder, rețelele multisite și WooCommerce suprascriu șabloanele fără a atinge fișierele temei.
Suprascrierea Programatică a Ierarhiei Șabloanelor
Injectarea unei Căi de Șablon Personalizate
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;
} );
Suprascrierea unui Șablon După Rezolvare
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;
} );
Filtrul template_include este ultimul hook înainte ca WordPress să încarce fișierul șablon. Primește calea complet rezolvată și trebuie să returneze o cale de fișier validă.
Părți de Șablon și Funcția get_template_part()
Părțile de șablon sunt fragmente PHP reutilizabile încărcate prin get_template_part(). Urmează propria lor mini-ierarhie:
// Loads content-video.php if it exists, falls back to content.php
get_template_part( 'template-parts/content', 'video' );
WordPress 5.5 a adăugat un al treilea parametru pentru transmiterea datelor către părțile de șablon:
get_template_part( 'template-parts/card', 'product', array(
    'post_id' => get_the_ID(),
    'show_price' => true,
) );
În interiorul părții de șablon, recuperați aceste date cu:
$args = wp_parse_args( $args, array(
    'post_id'    => 0,
    'show_price' => false,
) );
Aceasta elimină necesitatea de a folosi variabile globale pentru transmiterea datelor între șabloane — o îmbunătățire semnificativă pentru mentenabilitate și testabilitate.
Temele Copil și Sistemul de Suprascriere a Șabloanelor
Temele copil extind ierarhia prin adăugarea directorului temei copil la începutul căii de căutare a șabloanelor. Când locate_template() rulează, verifică:

Directorul temei copil (get_stylesheet_directory())
Directorul temei părinte (get_template_directory())

Aceasta înseamnă că puteți suprascrie orice șablon al temei părinte creând un fișier cu același nume în tema dvs. copil. Nu trebuie să copiați întregul fișier — doar părțile pe care doriți să le modificați — dar WordPress încarcă fișierul ca o unitate completă, deci trebuie să includeți tot marcajul necesar.
Greșeală comună cu tema copil: Copierea functions.php din tema părinte în tema copil și așteptarea că va înlocui funcțiile părintelui. Spre deosebire de alte fișiere șablon, functions.php dintr-o temă copil este încărcat în plus față de functions.php al părintelui, nu în locul acestuia. Ambele fișiere se execută.
Pentru a crea o structură minimă de temă copil:
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)
Antetul style.css trebuie să declare părintele:
/*
 Theme Name: My Child Theme
 Template: parent-theme-directory-name
*/
Depanarea Șablonului Activ
Metoda 1: Plugin-ul Query Monitor
Plugin-ul Query Monitor (gratuit, WordPress.org) afișează fișierul șablon rezolvat și ierarhia completă a candidaților în panoul barei de instrumente de administrare. Acesta este cel mai fiabil instrument de depanare disponibil și adaugă un overhead neglijabil.
Metoda 2: Hook-ul template_include
add_filter( 'template_include', function( $template ) {
    if ( current_user_can( 'manage_options' ) ) {
        echo '<!-- Template: ' . esc_html( str_replace( ABSPATH, '', $template ) ) . ' -->';
    }
    return $template;
} );
Aceasta afișează calea șablonului ca un comentariu HTML vizibil doar pentru administratori. Eliminați-l înainte de a implementa în producție.
Metoda 3: WP_DEBUG și Jurnalizare
Pe un server de dezvoltare, activați jurnalizarea de depanare în wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Apoi adăugați jurnalizare temporară în interiorul template_include:
add_filter( 'template_include', function( $template ) {
    error_log( 'Resolved template: ' . $template );
    return $template;
} );
Într-un mediu de VPS Hosting cu acces root, puteți urmări jurnalul de depanare în timp real:
tail -f /var/www/html/wp-content/debug.log
Această abordare este mult mai fiabilă decât instrumentele de depanare bazate pe browser atunci când depanați rezolvarea șabloanelor pe un server live sau de staging.
WooCommerce și Sistemul de Suprascriere a Șabloanelor
WooCommerce vine cu propria ierarhie de șabloane care se află deasupra sistemului nativ al WordPress. Șabloanele WooCommerce se află în wp-content/plugins/woocommerce/templates/ și sunt încărcate prin propria sa funcție wc_get_template(), care verifică suprascrierile în:

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

Pentru a suprascrie șablonul de produs unic al WooCommerce, copiați woocommerce/templates/single-product.php în your-theme/woocommerce/single-product.php. Nu editați niciodată fișierele șablon ale plugin-ului direct — acestea sunt suprascrise la fiecare actualizare a plugin-ului.

WooCommerce se conectează și la hook-urile de acțiune woocommerce_template_single_*, ceea ce vă oferă control granular asupra secțiunilor individuale (preț, file, buton de adăugare în coș) fără a suprascrie fișiere șablon întregi. Aceasta este abordarea preferată pentru modificări minore.

Temele Block și Ierarhia Șabloanelor în Full Site Editing

WordPress 5.9 a introdus Full Site Editing (FSE) cu teme block, care schimbă modul în care funcționează ierarhia șabloanelor în practică. Temele block stochează șabloanele ca fișiere HTML într-un director templates/ în loc de fișiere PHP:

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

Logica de rezolvare urmează aceleași reguli de ierarhie, dar WordPress verifică acum și baza de date pentru șabloane personalizate de utilizator salvate prin Site Editor. Ordinea de căutare devine:

1. Șablon salvat de utilizator în baza de date (tipul de postare wp_template)
2. Fișier HTML din directorul templates/ al temei
3. Fișier HTML din directorul templates/ al temei părinte
4. Șabloanele de rezervă incluse în WordPress

Temele PHP clasice și temele block pot coexista într-o instalare WordPress, dar nu puteți amesteca șabloane PHP și șabloane block HTML în cadrul unei singure teme. Dacă tema dvs. are un director templates/ și un theme.json valid, WordPress o tratează ca o temă block.

Pentru echipele care rulează sarcini de lucru critice pentru performanță pe Servere Dedicate, înțelegerea acestei distincții este esențială la evaluarea framework-urilor de teme — temele block transferă redarea șabloanelor către parserul de blocuri, care are caracteristici de caching diferite față de execuția șabloanelor PHP.

Implicațiile de Performanță ale Ierarhiei Șabloanelor

Fiecare rezolvare de șablon implică verificări ale sistemului de fișiere prin locate_template(). Pe un site cu trafic ridicat, aceasta poate adăuga un overhead măsurabil dacă nu este stocat în cache. Optimizări cheie:

Caching de obiecte: Folosiți un cache de obiecte persistent (Redis sau Memcached) pentru a stoca în cache rezultatele WP_Query și a reduce numărul de interogări în baza de date care alimentează selecția șabloanelor.

OPcache: Asigurați-vă că PHP OPcache este activat și configurat corespunzător. Deoarece șabloanele sunt fișiere PHP, OPcache le compilează în bytecode la prima încărcare și servește cererile ulterioare din memorie. Pe un VPS cu cPanel configurat corespunzător, OPcache este de obicei activat implicit, dar poate necesita ajustarea opcache.memory_consumption și opcache.max_accelerated_files pentru teme mari cu multe fișiere șablon.

Evitați fișierele șablon inutile: Fiecare fișier șablon din directorul temei dvs. este un candidat pe care locate_template() trebuie să îl verifice. Temele cu sute de fișiere șablon (comune în temele comerciale supraîncărcate) cresc I/O-ul sistemului de fișiere la fiecare cerere fără cache. Auditați tema și eliminați șabloanele neutilizate.

Caching de pagini complete: Instrumente precum WP Rocket, W3 Total Cache sau caching la nivel de server (Nginx FastCGI cache, Varnish) ocolesc complet execuția șabloanelor PHP pentru utilizatorii anonimi. Rezolvarea ierarhiei șabloanelor rulează doar când cache-ul nu găsește o intrare.

Tipare Practice de Personalizare

Tiparul 1: Aspect Specific Categoriei Fără un Plugin

Creați category-news.php în directorul temei dvs. WordPress îl folosește automat pentru arhiva categoriei „news”. Niciun plugin, niciun hook de filtru — doar un fișier cu numele corect.

<?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(); ?>

Tiparul 2: Aspect Per-Autor pentru Contributori Evidențiați

// 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(); ?>

Tiparul 3: Logică Condiționată în index.php

Dacă construiți o temă minimală și doriți să evitați mai multe fișiere șablon, puteți folosi etichete condiționale în interiorul 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(); ?>

Acest tipar este folosit de teme precum Twenty Twenty-One și este perfect valid. Compromisul este că un singur index.php mare devine mai greu de întreținut pe măsură ce complexitatea crește.

Multisite și Ierarhia Șabloanelor

Într-o rețea WordPress Multisite, fiecare site din rețea poate folosi o temă activă diferită. Ierarhia șabloanelor funcționează identic per site, dar plugin-urile activate la nivel de rețea pot folosi filtrele template_include sau _{$type}_template_hierarchy pentru a injecta șabloane partajate pe toate site-urile fără a duplica fișierele temei.

Un tipar multisite comun este un director de „șabloane de rețea” în afara rădăcinii web, referit prin hook-uri de filtre la nivel de plugin. Aceasta permite unei echipe centrale de design să împingă actualizări de șabloane pe toate site-urile simultan — un avantaj operațional semnificativ pentru agențiile care gestionează zeci de site-uri client pe un singur mediu de Găzduire Web Partajată sau VPS.

SSL, Securitate și Permisiunile Fișierelor Șablon

Fișierele șablon sunt PHP și trebuie tratate ca cod executabil. Permisiunile incorecte ale fișierelor sunt un vector de atac comun. Pe un server Linux, fișierele șablon ale temei ar trebui să fie deținute de utilizatorul serverului web (de obicei www-data sau nginx) și setate la modul 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 {} ;

Nu setați niciodată fișierele PHP la 777. Dacă un fișier șablon necesită acces de scriere (neobișnuit și în general inadvisabil), folosiți 664 cu proprietate de grup corespunzătoare în schimb.

Asocierea instalării dvs. WordPress cu un Certificat SSL valid asigură că conținutul redat de șabloane — inclusiv paginile generate dinamic cu date sensibile ale utilizatorilor — este întotdeauna transmis prin HTTPS. Aceasta este non-negociabilă pentru orice site care folosește formulare de contact, conturi de utilizator sau e-commerce.

Referință Ierarhie Șabloane: Flux Vizual

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

Matrice de Decizie: Când să Folosiți Care Abordare de Personalizare

Concluzii Tehnice Cheie

• index.php este obligatoriu. Fiecare temă trebuie să îl includă. Este rezerva universală care termină fiecare lanț de rezolvare.
• singular.php este stratul de mijloc subutilizat. Prinde orice postare sau pagină unică când nici single.php nici page.php nu există. Folosiți-l în teme minimale pentru a reduce numărul de fișiere.
• front-page.php suprascrie totul pentru pagina de start, indiferent de setările de Citire. Dacă există, se încarcă — întotdeauna.
• Denumirea fișierelor este sensibilă la majuscule pe serverele Linux. Category-News.php nu va corespunde când WordPress caută category-news.php. Aceasta este o eroare silențioasă dificil de depanat fără Query Monitor.
• Filtrul template_include este suprascrierea principală. Se declanșează după ce toată rezolvarea ierarhiei este completă și vă oferă o ultimă oportunitate de a schimba orice șablon din orice motiv.
• Temele block stochează șabloanele ca HTML, nu PHP. Logica ierarhiei este identică, dar formatul fișierului și structura directorului diferă fundamental față de temele clasice.
• functions.php al temei copil se încarcă în plus față de cel al părintelui, nu în locul acestuia. Toate celelalte fișiere șablon urmează tiparul standard de suprascriere.
• Ajustarea OPcache contează la scară. Pe site-urile cu trafic ridicat, asigurați-vă că opcache.max_accelerated_files depășește numărul total de fișiere PHP din instalarea dvs. WordPress, inclusiv toate șabloanele temei.
• Șabloanele WooCommerce se află în afara ierarhiei WordPress. Necesită un flux de lucru separat de suprascriere prin subdirectorul woocommerce/ din tema dvs.
• Asociați munca de personalizare a șabloanelor cu un domeniu configurat corespunzător și Înregistrare Domeniu pentru a asigura consistența URL-urilor canonice pe toate paginile redate de șabloane.

Întrebări Frecvente

Ce se întâmplă dacă WordPress nu poate găsi niciun fișier șablon în ierarhie?

WordPress găsește întotdeauna index.php deoarece este necesar pentru orice temă validă. Dacă index.php lipsește, WordPress aruncă o eroare fatală și afișează o pagină goală sau o eroare de server. Acesta este singurul fișier șablon a cărui absență strică complet site-ul.

Pot folosi ierarhia șabloanelor într-un plugin fără a modifica tema activă?

Da. Folosiți filtrul _{$type}_template_hierarchy pentru a adăuga o cale de director de plugin la începutul array-ului de candidați înainte ca locate_template() să ruleze, sau folosiți template_include pentru a schimba calea șablonului rezolvat după rezolvare. Astfel funcționează WooCommerce, bbPress și majoritatea plugin-urilor majore pentru a injecta propriile șabloane fără a necesita modificări ale temei.

De ce front-page.php suprascrie indexul meu de blog chiar și când am setat „Cele mai recente postări ale dvs.” în setările de Citire?

Deoarece front-page.php are prioritate necondiționată pentru pagina de start în toate configurațiile de Citire. Dacă doriți ca indexul de blog să folosească home.php în schimb, redenumiți sau eliminați front-page.php din tema dvs. În interiorul front-page.php, folosiți is_home() pentru a detecta dacă pagina de start este și indexul de blog și redați corespunzător.

Cum aflu ce fișier șablon folosește în prezent WordPress pentru o pagină specifică?

Instalați plugin-ul Query Monitor. Afișează calea șablonului rezolvat și ierarhia completă a candidaților în bara de instrumente de administrare la fiecare încărcare de pagină. Alternativ, adăugați un filtru temporar template_include care afișează calea ca un comentariu HTML vizibil doar pentru administratori.

Ierarhia șabloanelor funcționează la fel în WordPress Multisite?

Logica de rezolvare per site este identică. Fiecare site rezolvă șabloanele față de propria sa temă activă. Diferența este la nivel de rețea: plugin-urile activate la nivel de rețea pot folosi hook-uri de filtre pentru a injecta șabloane partajate pe toate site-urile, iar funcția get_stylesheet_directory() returnează calea corectă pentru tema activă a fiecărui site individual, nu o cale de rețea partajată.