WordPress Template-Hierarchie: Der vollständige technische Leitfaden

WordPress's Template Hierarchy ist das deterministische Auflösungssystem, das WordPress verwendet, um auszuwählen, welche PHP-Template-Datei eine bestimmte Seitenanfrage rendert. Wenn ein Besucher eine URL auf Ihrer Website lädt, wertet WordPress den Abfragekontext aus — Post-Typ, Taxonomie, Slug, ID und mehr — und durchläuft dann eine priorisierte Liste von Kandidaten-Dateinamen, bis eine Übereinstimmung im aktiven Theme-Verzeichnis gefunden wird. Wenn kein spezifisches Template vorhanden ist, fällt es auf index.php zurück.

Dieses System auf einem tiefen Niveau zu verstehen ist für ernsthafte WordPress-Entwicklung keine Option. Es ist die Grundlage jedes benutzerdefinierten Layouts, jeder Theme-Überschreibung und jeder Performance-Optimierung, die Template-Caching beinhaltet. Ob Sie eine inhaltsreiche Publikation, einen WooCommerce-Shop oder ein headless WordPress-Setup betreiben — die Hierarchie bestimmt, welches PHP bei jedem einzelnen Seitenaufruf ausgeführt wird.

Was die Template Hierarchy tatsächlich ist

Im Kern ist die Template Hierarchy eine Lookup-Kette, die in den WordPress-Core eingebaut ist (wp-includes/class-wp-query.php und wp-includes/template.php). Wenn WordPress die Anfrage fertig geparst und das globale $wp_query-Objekt befüllt hat, ruft es intern get_template_part()-Äquivalente auf, um das korrekte Template aufzulösen. Die Auflösung ist nicht zufällig — es ist eine strenge, geordnete Liste von Dateinamen, die gegen das Stammverzeichnis Ihres Themes geprüft wird.

Die wichtigste architektonische Erkenntnis, die die meisten Tutorials übersehen: WordPress scannt Ihr Theme-Verzeichnis nicht. Es erstellt ein priorisiertes Array von Kandidaten-Dateinamen basierend auf Abfragevariablen und prüft dann jede Datei mit locate_template(). Diese Unterscheidung ist wichtig, wenn Sie fehlende Templates debuggen oder programmatische Theme-Generatoren erstellen.

Die Fallback-Kette endet immer bei index.php. Diese Datei ist die einzige Template-Datei, die WordPress gemäß den Theme-Entwicklungsstandards von jedem Theme verlangt.

Kern-Template-Dateien, die jedes Theme verstehen muss

Beachten Sie den Eintrag singular.php — dies ist ein Template, das viele Entwickler völlig übersehen. Eingeführt in WordPress 4.3, sitzt es in der Hierarchie zwischen single.php/page.php und index.php und fungiert als einheitlicher Auffangwert für jede einzelne Inhaltsansicht. Wenn Ihr Theme singular.php enthält, fängt es Fälle ab, in denen weder single.php noch page.php vorhanden ist.

Die vollständige Template-Auflösungsreihenfolge nach Seitentyp

Einzelne Blog-Beiträge

Wenn ein Besucher einen Standard-Beitrag (post_type = 'post') aufruft, prüft WordPress in genau dieser Reihenfolge:

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

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

Die slug-basierte Variante in Schritt 1 ist selten dokumentiert, aber äußerst nützlich, um einem einzelnen Flaggschiff-Beitrag ein völlig einzigartiges Layout zu geben, ohne andere Templates zu berühren.

Benutzerdefinierte Post-Typen

Für einen benutzerdefinierten Post-Typ, der als portfolio registriert ist:

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

Für sein Archiv (erfordert 'has_archive' => true in register_post_type()):

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

Ein häufiger Fallstrick: Einen benutzerdefinierten Post-Typ mit 'has_archive' => false (dem Standard) registrieren und sich dann wundern, warum archive-portfolio.php nie geladen wird. Die Archiv-URL gibt in diesem Fall einfach einen 404-Fehler zurück.

Statische Seiten

1. Template-Datei, die über die Seitenattribute-Metabox festgelegt wurde (benutzerdefiniertes Seiten-Template)
2. page-{slug}.php
3. page-{ID}.php
4. page.php
5. singular.php
6. index.php

Benutzerdefinierte Seiten-Templates sind PHP-Dateien in Ihrem Theme-Verzeichnis, die einen Datei-Header-Kommentar enthalten:

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

Die Template Post Type-Deklaration (WordPress 4.7+) schränkt ein, welche Post-Typen dieses Template im Editor verwenden können. Ohne sie erscheint das Template im Seitenattribute-Dropdown nur für Seiten.

Kategorie-Archive

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

Benutzerdefinierte Taxonomie-Archive

Für eine Taxonomie, die als genre registriert ist, mit einem Term-Slug von thriller:

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

Autoren-Archive

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

Die Startseite (Kritischer Sonderfall)

Dies ist der am meisten missverstandene Teil der Hierarchie. WordPress unterscheidet zwischen zwei Startseiten-Szenarien:

Szenario A — Blog-Beiträge-Index als Startseite (Einstellungen > Lesen: "Ihre neuesten Beiträge"):

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

Szenario B — Statische Seite als Startseite (Einstellungen > Lesen: "Eine statische Seite"):

1. front-page.php

page.php (wenn kein front-page.php vorhanden ist)
index.php

Die entscheidende Nuance: front-page.php hat in beiden Szenarien Vorrang. Wenn front-page.php in Ihrem Theme vorhanden ist, rendert es immer die Startseite, unabhängig von den Lesen-Einstellungen. Dies überrascht viele Entwickler, die front-page.php für eine statische Startseite erstellen, aber vergessen, dass es auch den Blog-Index überschreibt, wenn sie die Einstellung später ändern.

Suchergebnisse und 404

Suchergebnisse:

1. search.php
2. index.php

404-Fehlerseiten:

1. 404.php
2. index.php

Eine gut gestaltete 404.php ist ein Conversion-Asset, keine Nachgedanke. Sie sollte ein Suchformular, Links zu beliebten Inhalten und eine klare Navigation enthalten — all das erfordert ein Verständnis des Template-Systems für eine korrekte Implementierung.

Wie WordPress Templates intern auflöst

Das Verständnis der internen Mechanik hilft beim Debuggen oder Erweitern des Systems. Der Auflösungsprozess in wp-includes/template.php funktioniert wie folgt:

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

Zwei Filter-Hooks sind hier entscheidend:

_{$type}_template_hierarchy — wird vor der Dateisuche ausgelöst und ermöglicht es Ihnen, zusätzliche Kandidaten in das Array einzufügen
{$type}_template — wird nach dem Auffinden der Datei ausgelöst und ermöglicht es Ihnen, den aufgelösten Template-Pfad vollständig auszutauschen

Über diese Hooks überschreiben Page-Builder-Plugins, Multisite-Netzwerke und WooCommerce Templates, ohne Theme-Dateien zu berühren.
Programmatisches Überschreiben der Template Hierarchy
Einen benutzerdefinierten Template-Pfad einfügen
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;
} );
Ein Template nach der Auflösung überschreiben
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;
} );
Der template_include-Filter ist der letzte Hook, bevor WordPress die Template-Datei lädt. Er empfängt den vollständig aufgelösten Pfad und muss einen gültigen Dateipfad zurückgeben.
Template-Parts und die get_template_part()-Funktion
Template-Parts sind wiederverwendbare PHP-Fragmente, die über get_template_part() geladen werden. Sie folgen ihrer eigenen Mini-Hierarchie:
// Loads content-video.php if it exists, falls back to content.php
get_template_part( 'template-parts/content', 'video' );
WordPress 5.5 hat einen dritten Parameter zum Übergeben von Daten an Template-Parts hinzugefügt:
get_template_part( 'template-parts/card', 'product', array(
    'post_id' => get_the_ID(),
    'show_price' => true,
) );
Innerhalb des Template-Parts können diese Daten abgerufen werden mit:
$args = wp_parse_args( $args, array(
    'post_id'    => 0,
    'show_price' => false,
) );
Dies eliminiert die Notwendigkeit, globale Variablen für die Datenübergabe zwischen Templates zu verwenden — eine bedeutende Verbesserung für Wartbarkeit und Testbarkeit.
Child-Themes und das Template-Override-System
Child-Themes erweitern die Hierarchie, indem sie das Child-Theme-Verzeichnis dem Template-Suchpfad voranstellen. Wenn locate_template() ausgeführt wird, prüft es:

Child-Theme-Verzeichnis (get_stylesheet_directory())
Parent-Theme-Verzeichnis (get_template_directory())

Das bedeutet, Sie können jedes Parent-Theme-Template überschreiben, indem Sie eine Datei mit identischem Namen in Ihrem Child-Theme erstellen. Sie müssen nicht die gesamte Datei kopieren — nur die Teile, die Sie ändern möchten — aber WordPress lädt die Datei als vollständige Einheit, daher müssen Sie alle erforderlichen Markups einschließen.
Häufiger Child-Theme-Fehler: functions.php aus dem Parent-Theme in das Child-Theme kopieren und erwarten, dass es die Funktionen des Parents ersetzt. Anders als andere Template-Dateien wird functions.php in einem Child-Theme zusätzlich zur functions.php des Parents geladen, nicht anstelle davon. Beide Dateien werden ausgeführt.
So erstellen Sie eine minimale Child-Theme-Struktur:
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)
Der style.css-Header muss das Parent deklarieren:
/*
 Theme Name: My Child Theme
 Template: parent-theme-directory-name
*/
Debuggen, welches Template aktiv ist
Methode 1: Query Monitor Plugin
Das Query Monitor-Plugin (kostenlos, WordPress.org) zeigt die aufgelöste Template-Datei und die vollständige Kandidaten-Hierarchie in seinem Admin-Toolbar-Panel an. Dies ist das zuverlässigste verfügbare Debugging-Tool und verursacht vernachlässigbaren Overhead.
Methode 2: Der template_include-Hook
add_filter( 'template_include', function( $template ) {
    if ( current_user_can( 'manage_options' ) ) {
        echo '<!-- Template: ' . esc_html( str_replace( ABSPATH, '', $template ) ) . ' -->';
    }
    return $template;
} );
Dies gibt den Template-Pfad als HTML-Kommentar aus, der nur für Administratoren sichtbar ist. Entfernen Sie ihn vor dem Deployment in die Produktion.
Methode 3: WP_DEBUG und Logging
Aktivieren Sie auf einem Entwicklungsserver das Debug-Logging in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Fügen Sie dann temporäres Logging innerhalb von template_include hinzu:
add_filter( 'template_include', function( $template ) {
    error_log( 'Resolved template: ' . $template );
    return $template;
} );
In einer VPS Hosting-Umgebung mit Root-Zugriff können Sie das Debug-Log in Echtzeit verfolgen:
tail -f /var/www/html/wp-content/debug.log
Dieser Ansatz ist weitaus zuverlässiger als browserbasierte Debugging-Tools bei der Fehlerbehebung der Template-Auflösung auf einem Live- oder Staging-Server.
WooCommerce und das Template-Override-System
WooCommerce verfügt über eine eigene Template-Hierarchie, die auf dem nativen WordPress-System aufbaut. WooCommerce-Templates befinden sich in wp-content/plugins/woocommerce/templates/ und werden über seine eigene wc_get_template()-Funktion geladen, die nach Überschreibungen sucht in:

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

Um WooCommerces Single-Produkt-Template zu überschreiben, kopieren Sie woocommerce/templates/single-product.php nach your-theme/woocommerce/single-product.php. Bearbeiten Sie niemals Plugin-Template-Dateien direkt — sie werden bei jedem Plugin-Update überschrieben.

WooCommerce hängt sich auch in woocommerce_template_single_*-Action-Hooks ein, was Ihnen granulare Kontrolle über einzelne Abschnitte (Preis, Tabs, In-den-Warenkorb-Button) gibt, ohne gesamte Template-Dateien überschreiben zu müssen. Dies ist der bevorzugte Ansatz für kleinere Änderungen.

Block-Themes und die Template Hierarchy im Full Site Editing

WordPress 5.9 führte Full Site Editing (FSE) mit Block-Themes ein, was die praktische Funktionsweise der Template Hierarchy verändert. Block-Themes speichern Templates als HTML-Dateien in einem templates/-Verzeichnis statt als PHP-Dateien:

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

Die Auflösungslogik folgt denselben Hierarchieregeln, aber WordPress prüft nun auch die Datenbank auf benutzerdefinierte Templates, die über den Site-Editor gespeichert wurden. Die Suchreihenfolge wird zu:

1. Vom Benutzer gespeichertes Template in der Datenbank (Post-Typ wp_template)
2. HTML-Datei im templates/-Verzeichnis des Themes
3. HTML-Datei im templates/-Verzeichnis des Parent-Themes
4. WordPress' eigene Fallback-Templates

Klassische PHP-Themes und Block-Themes können in einer WordPress-Installation koexistieren, aber Sie können PHP-Templates und HTML-Block-Templates nicht innerhalb eines einzelnen Themes mischen. Wenn Ihr Theme ein templates/-Verzeichnis und eine gültige theme.json hat, behandelt WordPress es als Block-Theme.

Für Teams, die performance-kritische Workloads auf Dedizierten Servern betreiben, ist das Verständnis dieser Unterscheidung bei der Evaluierung von Theme-Frameworks unerlässlich — Block-Themes verlagern das Template-Rendering auf den Block-Parser, der andere Caching-Eigenschaften als die PHP-Template-Ausführung hat.

Performance-Auswirkungen der Template Hierarchy

Jede Template-Auflösung beinhaltet Dateisystem-Prüfungen über locate_template(). Auf einer stark frequentierten Website kann dies messbaren Overhead verursachen, wenn es nicht gecacht wird. Wichtige Optimierungen:

Object-Caching: Verwenden Sie einen persistenten Object-Cache (Redis oder Memcached), um die Ergebnisse von WP_Query zu cachen und die Anzahl der Datenbankabfragen zu reduzieren, die in die Template-Auswahl einfließen.

OPcache: Stellen Sie sicher, dass PHP OPcache aktiviert und ordnungsgemäß konfiguriert ist. Da Templates PHP-Dateien sind, kompiliert OPcache sie beim ersten Laden zu Bytecode und bedient nachfolgende Anfragen aus dem Speicher. Auf einem ordnungsgemäß konfigurierten VPS mit cPanel ist OPcache typischerweise standardmäßig aktiviert, erfordert aber möglicherweise eine Anpassung von opcache.memory_consumption und opcache.max_accelerated_files für große Themes mit vielen Template-Dateien.

Unnötige Template-Dateien vermeiden: Jede Template-Datei in Ihrem Theme-Verzeichnis ist ein Kandidat, den locate_template() prüfen muss. Themes mit Hunderten von Template-Dateien (häufig bei aufgeblähten kommerziellen Themes) erhöhen den Dateisystem-I/O bei jeder nicht gecachten Anfrage. Prüfen Sie Ihr Theme und entfernen Sie ungenutzte Templates.

Full-Page-Caching: Tools wie WP Rocket, W3 Total Cache oder serverseitiges Caching (Nginx FastCGI-Cache, Varnish) umgehen die PHP-Template-Ausführung für anonyme Benutzer vollständig. Die Template-Hierarchie-Auflösung läuft nur, wenn der Cache einen Miss hat.

Praktische Anpassungsmuster

Muster 1: Kategoriespezifisches Layout ohne Plugin

Erstellen Sie category-news.php in Ihrem Theme-Verzeichnis. WordPress verwendet es automatisch für das „news”-Kategorie-Archiv. Kein Plugin, kein Filter-Hook — nur eine Datei mit dem richtigen Namen.

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

Muster 2: Pro-Autoren-Layout für hervorgehobene Mitwirkende

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

Muster 3: Bedingte Logik innerhalb von index.php

Wenn Sie ein minimales Theme erstellen und mehrere Template-Dateien vermeiden möchten, können Sie bedingte Tags innerhalb von index.php verwenden:

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

Dieses Muster wird von Themes wie Twenty Twenty-One verwendet und ist vollkommen gültig. Der Kompromiss besteht darin, dass eine einzelne große index.php mit wachsender Komplexität schwerer zu warten wird.

Multisite und Template Hierarchy

In einem WordPress-Multisite-Netzwerk kann jede Site im Netzwerk ein anderes aktives Theme verwenden. Die Template Hierarchy funktioniert pro Site identisch, aber netzwerkaktivierte Plugins können template_include– oder _{$type}_template_hierarchy-Filter verwenden, um gemeinsame Templates über alle Sites hinweg einzufügen, ohne Theme-Dateien zu duplizieren.

Ein häufiges Multisite-Muster ist ein „Netzwerk-Template”-Verzeichnis außerhalb des Web-Roots, das über Plugin-Level-Filter-Hooks referenziert wird. Dies ermöglicht einem zentralen Design-Team, Template-Updates gleichzeitig auf alle Sites zu übertragen — ein erheblicher operativer Vorteil für Agenturen, die Dutzende von Kunden-Sites auf einem einzigen Shared Web Hosting– oder VPS-Environment verwalten.

SSL, Sicherheit und Template-Datei-Berechtigungen

Template-Dateien sind PHP und müssen als ausführbarer Code behandelt werden. Falsche Dateiberechtigungen sind ein häufiger Angriffsvektor. Auf einem Linux-Server sollten Theme-Template-Dateien dem Webserver-Benutzer gehören (typischerweise www-data oder nginx) und auf Modus 644 gesetzt sein:

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

Setzen Sie PHP-Dateien niemals auf 777. Wenn eine Template-Datei Schreibzugriff benötigt (ungewöhnlich und generell nicht ratsam), verwenden Sie 664 mit korrekter Gruppenbesitzschaft.

Die Kombination Ihrer WordPress-Installation mit einem gültigen SSL-Zertifikat stellt sicher, dass template-gerenderter Inhalt — einschließlich dynamisch generierter Seiten mit sensiblen Benutzerdaten — immer über HTTPS übertragen wird. Dies ist für jede Site mit Kontaktformularen, Benutzerkonten oder E-Commerce nicht verhandelbar.

Template Hierarchy Referenz: Visueller Ablauf

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

Entscheidungsmatrix: Wann welchen Anpassungsansatz verwenden

Wichtige technische Erkenntnisse

• index.php ist obligatorisch. Jedes Theme muss es enthalten. Es ist der universelle Fallback, der jede Auflösungskette beendet.
• singular.php ist die untergenutzte mittlere Schicht. Es fängt jeden einzelnen Beitrag oder jede Seite ab, wenn weder single.php noch page.php vorhanden ist. Verwenden Sie es in minimalen Themes, um die Dateianzahl zu reduzieren.
• front-page.php überschreibt alles für die Startseite, unabhängig von den Lesen-Einstellungen. Wenn es vorhanden ist, wird es geladen — immer.
• Dateinamen sind auf Linux-Servern case-sensitive. Category-News.php wird nicht gefunden, wenn WordPress nach category-news.php sucht. Dies ist ein stiller Fehler, der ohne Query Monitor schwer zu debuggen ist.
• Der template_include-Filter ist die Master-Überschreibung. Er wird ausgelöst, nachdem die gesamte Hierarchieauflösung abgeschlossen ist, und gibt Ihnen eine letzte Möglichkeit, jedes Template aus beliebigem Grund auszutauschen.
• Block-Themes speichern Templates als HTML, nicht als PHP. Die Hierarchielogik ist identisch, aber das Dateiformat und die Verzeichnisstruktur unterscheiden sich grundlegend von klassischen Themes.
• Child-Theme functions.php wird zusätzlich zur des Parents geladen, nicht anstelle davon. Alle anderen Template-Dateien folgen dem Standard-Override-Muster.
• OPcache-Tuning ist bei großem Maßstab wichtig. Stellen Sie auf stark frequentierten Sites sicher, dass opcache.max_accelerated_files die Gesamtzahl der PHP-Dateien in Ihrer WordPress-Installation überschreitet, einschließlich aller Theme-Templates.
• WooCommerce-Templates befinden sich außerhalb der WordPress-Hierarchie. Sie erfordern einen separaten Override-Workflow über das woocommerce/-Unterverzeichnis in Ihrem Theme.
• Kombinieren Sie Ihre Template-Anpassungsarbeit mit einer ordnungsgemäß konfigurierten Domain und Domain-Registrierung, um die Konsistenz kanonischer URLs über alle template-gerenderten Seiten hinweg sicherzustellen.

FAQ

Was passiert, wenn WordPress keine Template-Datei in der Hierarchie finden kann?

WordPress findet immer index.php, da es für jedes gültige Theme erforderlich ist. Wenn index.php fehlt, wirft WordPress einen fatalen Fehler und zeigt eine leere Seite oder einen Serverfehler an. Dies ist die einzige Template-Datei, deren Fehlen die Site vollständig zum Absturz bringt.

Kann ich die Template Hierarchy in einem Plugin verwenden, ohne das aktive Theme zu ändern?

Ja. Verwenden Sie den _{$type}_template_hierarchy-Filter, um einen Plugin-Verzeichnispfad dem Kandidaten-Array voranzustellen, bevor locate_template() ausgeführt wird, oder verwenden Sie template_include, um den aufgelösten Template-Pfad nach der Auflösung auszutauschen. So fügen WooCommerce, bbPress und die meisten großen Plugins ihre eigenen Templates ein, ohne Theme-Änderungen zu erfordern.

Warum überschreibt front-page.php meinen Blog-Index, auch wenn ich in den Lesen-Einstellungen „Ihre neuesten Beiträge” festgelegt habe?

Weil front-page.php in allen Lesen-Konfigurationen bedingungslos Vorrang für die Startseite hat. Wenn Sie möchten, dass der Blog-Index stattdessen home.php verwendet, benennen Sie front-page.php in Ihrem Theme um oder entfernen Sie es. Verwenden Sie innerhalb von front-page.php is_home(), um zu erkennen, ob die Startseite auch der Blog-Index ist, und rendern Sie entsprechend.

Wie finde ich heraus, welche Template-Datei WordPress aktuell für eine bestimmte Seite verwendet?

Installieren Sie das Query Monitor-Plugin. Es zeigt den aufgelösten Template-Pfad und die vollständige Kandidaten-Hierarchie in der Admin-Toolbar bei jedem Seitenaufruf an. Alternativ fügen Sie einen temporären template_include-Filter hinzu, der den Pfad als HTML-Kommentar ausgibt, der nur für Administratoren sichtbar ist.

Funktioniert die Template Hierarchy in WordPress Multisite genauso?

Die siteübergreifende Auflösungslogik ist identisch. Jede Site löst Templates gegen ihr eigenes aktives Theme auf. Der Unterschied liegt auf Netzwerkebene: Netzwerkaktivierte Plugins können Filter-Hooks verwenden, um gemeinsame Templates über alle Sites hinweg einzufügen, und die get_stylesheet_directory()-Funktion gibt den korrekten Pfad für das aktive Theme jeder einzelnen Site zurück, nicht einen gemeinsamen Netzwerkpfad.