WordPress Şablon Hiyerarşisi: Eksiksiz Teknik Kılavuz

WordPress’in Şablon Hiyerarşisi, WordPress’in belirli bir sayfa isteğini hangi PHP şablon dosyasının işleyeceğini seçmek için kullandığı deterministik çözümleme sistemidir. Bir ziyaretçi sitenizdeki herhangi bir URL’yi yüklediğinde, WordPress sorgu bağlamını — gönderi türü, taksonomi, slug, ID ve daha fazlasını — değerlendirir, ardından aktif tema dizininde bir eşleşme bulana kadar önceliklendirilmiş aday dosya adları listesini inceler. Belirli bir şablon mevcut değilse index.php‘e geri döner.

Bu sistemi derinlemesine anlamak, ciddi WordPress geliştirme için isteğe bağlı değildir. Her özel düzenin, her tema geçersiz kılmanın ve şablon önbelleklemeyi içeren her performans optimizasyonunun temelidir. İster içerik ağırlıklı bir yayın, ister bir WooCommerce mağazası, ister başsız bir WordPress kurulumu çalıştırıyor olun, hiyerarşi her sayfa yüklemesinde hangi PHP’nin çalıştırılacağını yönetir.

Şablon Hiyerarşisi Gerçekte Nedir

Özünde, Şablon Hiyerarşisi WordPress çekirdeğine (wp-includes/class-wp-query.php ve wp-includes/template.php) yerleştirilmiş bir arama zinciridir. WordPress isteği ayrıştırmayı ve global $wp_query nesnesini doldurmayı tamamladığında, doğru şablonu çözümlemek için dahili olarak get_template_part() eşdeğerlerini çağırır. Çözümleme rastgele değildir — tema kök dizinine karşı kontrol edilen, katı, sıralı bir dosya adları listesidir.

Çoğu öğreticinin gözden kaçırdığı temel mimari içgörü: WordPress tema dizininizi taramaz. Sorgu değişkenlerine dayalı olarak önceliklendirilmiş bir aday dosya adları dizisi oluşturur, ardından locate_template() kullanarak her dosyayı kontrol eder. Bu ayrım, eksik şablonlarda hata ayıklarken veya programatik tema oluşturucular geliştirirken önem taşır.

Geri dönüş zinciri her zaman index.php‘de sona erer. Bu dosya, tema geliştirme standartlarına göre WordPress’in her temaya dahil etmesini zorunlu kıldığı tek şablon dosyasıdır.

Her Temanın Anlaması Gereken Temel Şablon Dosyaları

singular.php girişine dikkat edin — bu, birçok geliştiricinin tamamen gözden kaçırdığı bir şablondur. WordPress 4.3’te tanıtılan bu şablon, hiyerarşide single.php/page.php ile index.php arasında yer alır ve herhangi bir tekil içerik görünümü için birleşik bir yakalama işlevi görür. Temanız singular.php içeriyorsa, ne single.php ne de page.php mevcut olmadığı durumlarda devreye girer.

Sayfa Türüne Göre Tam Şablon Çözümleme Sırası

Tekil Blog Gönderileri

Bir ziyaretçi standart bir gönderi (post_type = 'post') talep ettiğinde, WordPress tam olarak şu sırayla kontrol eder:

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

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

1. adımdaki slug tabanlı varyant nadiren belgelenir, ancak başka hiçbir şablona dokunmadan tek bir öne çıkan gönderiye tamamen benzersiz bir düzen vermek için son derece kullanışlıdır.

Özel Gönderi Türleri

portfolio olarak kayıtlı bir özel gönderi türü için:

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

Arşivi için (register_post_type()‘da 'has_archive' => true gerektirir):

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

Yaygın bir tuzak: Bir özel gönderi türünü 'has_archive' => false (varsayılan) ile kaydetmek ve ardından archive-portfolio.php‘ın neden hiç yüklenmediğini merak etmek. Bu durumda arşiv URL’si basitçe 404 döndürür.

Statik Sayfalar

1. Sayfa Özellikleri meta kutusu aracılığıyla ayarlanan şablon dosyası (özel sayfa şablonu)
2. page-{slug}.php
3. page-{ID}.php
4. page.php
5. singular.php
6. index.php

Özel sayfa şablonları, bir dosya başlığı yorumu içeren tema dizininizdeki PHP dosyalarıdır:

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

Template Post Type bildirimi (WordPress 4.7+), bu şablonu düzenleyiciden hangi gönderi türlerinin kullanabileceğini kısıtlar. Bu bildirim olmadan, şablon yalnızca sayfalar için Sayfa Özellikleri açılır menüsünde görünür.

Kategori Arşivleri

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

Özel Taksonomi Arşivleri

genre olarak kayıtlı ve thriller terim slug’ına sahip bir taksonomi için:

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

Yazar Arşivleri

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

Ön Sayfa (Kritik Kenar Durum)

Bu, hiyerarşinin en yanlış anlaşılan kısmıdır. WordPress iki ön sayfa senaryosunu birbirinden ayırır:

Senaryo A — Ön sayfa olarak blog gönderileri dizini (Ayarlar > Okuma: “En son gönderileriniz”):

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

Senaryo B — Ön sayfa olarak statik sayfa (Ayarlar > Okuma: “Statik bir sayfa”):

1. front-page.php

page.php (front-page.php mevcut değilse)
index.php

Kritik nüans: front-page.php, her iki senaryoda da öncelik alır. Temanızda front-page.php mevcutsa, Okuma ayarlarından bağımsız olarak her zaman ön sayfayı işler. Bu durum, statik bir ana sayfa için front-page.php oluşturan ancak daha sonra ayarı değiştirdiklerinde bunun blog dizinini de geçersiz kılacağını unutun birçok geliştiriciye sürpriz yapar.

Arama Sonuçları ve 404

Arama sonuçları:

1. search.php
2. index.php

404 hata sayfaları:

1. 404.php
2. index.php

İyi hazırlanmış bir 404.php, sonradan düşünülmüş bir şey değil, bir dönüşüm varlığıdır. Bir arama formu, popüler içerik bağlantıları ve net gezinme içermeli — bunların tümü doğru şekilde uygulamak için şablon sistemini anlamayı gerektirir.

WordPress Şablonları Dahili Olarak Nasıl Çözümler

Dahili mekanizmayı anlamak, sistemi hata ayıklarken veya genişletirken yardımcı olur. wp-includes/template.php‘daki çözümleme süreci şu şekilde işler:

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

Burada iki filtre kancası kritik öneme sahiptir:

_{$type}_template_hierarchy — dosya aramasından önce tetiklenir, diziye ek adaylar eklemenizi sağlar
{$type}_template — dosya konumlandırıldıktan sonra tetiklenir, çözümlenen şablon yolunu tamamen değiştirmenizi sağlar

Bu kancalar, sayfa oluşturucu eklentilerinin, çok siteli ağların ve WooCommerce’in tema dosyalarına dokunmadan şablonları geçersiz kılma yöntemidir.
Şablon Hiyerarşisini Programatik Olarak Geçersiz Kılma
Özel Şablon Yolu Ekleme
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;
} );
Çözümleme Sonrasında Şablonu Geçersiz Kılma
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;
} );
template_include filtresi, WordPress şablon dosyasını yüklemeden önceki son kancadır. Tam olarak çözümlenmiş yolu alır ve geçerli bir dosya yolu döndürmesi gerekir.
Şablon Parçaları ve get_template_part() Fonksiyonu
Şablon parçaları, get_template_part() aracılığıyla yüklenen yeniden kullanılabilir PHP parçalarıdır. Kendi mini hiyerarşilerini takip ederler:
// Loads content-video.php if it exists, falls back to content.php
get_template_part( 'template-parts/content', 'video' );
WordPress 5.5, şablon parçalarına veri aktarmak için üçüncü bir parametre ekledi:
get_template_part( 'template-parts/card', 'product', array(
    'post_id' => get_the_ID(),
    'show_price' => true,
) );
Şablon parçasının içinde bu verileri şu şekilde alın:
$args = wp_parse_args( $args, array(
    'post_id'    => 0,
    'show_price' => false,
) );
Bu, şablonlar arasında veri aktarmak için global değişken kullanma ihtiyacını ortadan kaldırır — bakım ve test edilebilirlik açısından önemli bir iyileştirme.
Alt Temalar ve Şablon Geçersiz Kılma Sistemi
Alt temalar, şablon arama yoluna alt tema dizinini öne ekleyerek hiyerarşiyi genişletir. locate_template() çalıştığında şunları kontrol eder:

Alt tema dizini (get_stylesheet_directory())
Üst tema dizini (get_template_directory())

Bu, alt temanızda aynı ada sahip bir dosya oluşturarak herhangi bir üst tema şablonunu geçersiz kılabileceğiniz anlamına gelir. Dosyanın tamamını kopyalamanız gerekmez — yalnızca değiştirmek istediğiniz kısımları — ancak WordPress dosyayı eksiksiz bir birim olarak yükler, dolayısıyla gerekli tüm işaretlemeyi dahil etmeniz gerekir.
Yaygın alt tema hatası: Üst temadan functions.php‘ı alt temaya kopyalamak ve üst temanın fonksiyonlarının yerini almasını beklemek. Diğer şablon dosyalarının aksine, alt temadaki functions.php, üst temanın functions.php‘ının yerine değil, ek olarak yüklenir. Her iki dosya da çalışır.
Minimal bir alt tema yapısı oluşturmak için:
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)
style.css başlığı üst temayı bildirmelidir:
/*
 Theme Name: My Child Theme
 Template: parent-theme-directory-name
*/
Hangi Şablonun Aktif Olduğunu Hata Ayıklama
Yöntem 1: Query Monitor Eklentisi
Query Monitor eklentisi (ücretsiz, WordPress.org), yönetici araç çubuğu panelinde çözümlenen şablon dosyasını ve tam aday hiyerarşisini görüntüler. Bu, mevcut en güvenilir hata ayıklama aracıdır ve ihmal edilebilir ek yük ekler.
Yöntem 2: template_include Kancası
add_filter( 'template_include', function( $template ) {
    if ( current_user_can( 'manage_options' ) ) {
        echo '<!-- Template: ' . esc_html( str_replace( ABSPATH, '', $template ) ) . ' -->';
    }
    return $template;
} );
Bu, şablon yolunu yalnızca yöneticilere görünür bir HTML yorumu olarak çıktılar. Üretime dağıtmadan önce kaldırın.
Yöntem 3: WP_DEBUG ve Günlükleme
Bir geliştirme sunucusunda, wp-config.php‘da hata ayıklama günlüğünü etkinleştirin:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Ardından template_include içine geçici günlükleme ekleyin:
add_filter( 'template_include', function( $template ) {
    error_log( 'Resolved template: ' . $template );
    return $template;
} );
Kök erişimine sahip bir VPS Hosting ortamında, hata ayıklama günlüğünü gerçek zamanlı olarak takip edebilirsiniz:
tail -f /var/www/html/wp-content/debug.log
Bu yaklaşım, canlı veya hazırlık sunucusunda şablon çözümleme sorunlarını giderirken tarayıcı tabanlı hata ayıklama araçlarına güvenmekten çok daha güvenilirdir.
WooCommerce ve Şablon Geçersiz Kılma Sistemi
WooCommerce, WordPress’in yerel sisteminin üzerine oturan kendi şablon hiyerarşisiyle birlikte gelir. WooCommerce şablonları wp-content/plugins/woocommerce/templates/‘da bulunur ve şu konumlardaki geçersiz kılmaları kontrol eden kendi wc_get_template() fonksiyonu aracılığıyla yüklenir:

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

WooCommerce’in tekil ürün şablonunu geçersiz kılmak için woocommerce/templates/single-product.php‘ı your-theme/woocommerce/single-product.php‘a kopyalayın. Eklenti şablon dosyalarını asla doğrudan düzenlemeyin — her eklenti güncellemesinde üzerine yazılırlar.

WooCommerce ayrıca woocommerce_template_single_* eylem kancalarına da bağlanır; bu, tüm şablon dosyalarını geçersiz kılmadan bireysel bölümler (fiyat, sekmeler, sepete ekle düğmesi) üzerinde ayrıntılı kontrol sağlar. Bu, küçük değişiklikler için tercih edilen yaklaşımdır.

Blok Temalar ve Tam Site Düzenlemede Şablon Hiyerarşisi

WordPress 5.9, şablon hiyerarşisinin pratikte nasıl çalıştığını değiştiren blok temalarla Tam Site Düzenlemeyi (FSE) tanıttı. Blok temalar, şablonları PHP dosyaları yerine bir templates/ dizininde HTML dosyaları olarak depolar:

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

Çözümleme mantığı aynı hiyerarşi kurallarını takip eder, ancak WordPress artık Site Düzenleyici aracılığıyla kaydedilen kullanıcı tarafından özelleştirilmiş şablonlar için veritabanını da kontrol eder. Arama sırası şu hale gelir:

1. Veritabanında kullanıcı tarafından kaydedilen şablon (wp_template gönderi türü)
2. Temanın templates/ dizin HTML dosyası
3. Üst temanın templates/ dizin HTML dosyası
4. WordPress’in yerleşik yedek şablonları

Klasik PHP temalar ve blok temalar bir WordPress kurulumunda bir arada bulunabilir, ancak tek bir tema içinde PHP şablonları ve HTML blok şablonlarını karıştıramazsınız. Temanızda bir templates/ dizini ve geçerli bir theme.json varsa, WordPress onu blok tema olarak değerlendirir.

Performans açısından kritik iş yükleri çalıştıran ekipler için Dedicated Servers, tema çerçevelerini değerlendirirken bu ayrımı anlamak çok önemlidir — blok temalar şablon oluşturmayı blok ayrıştırıcısına devreder; bu, PHP şablon yürütmesinden farklı önbellekleme özelliklerine sahiptir.

Şablon Hiyerarşisinin Performans Etkileri

Her şablon çözümleme, locate_template() aracılığıyla dosya sistemi kontrolleri içerir. Yüksek trafikli bir sitede, önbelleğe alınmazsa bu ölçülebilir ek yük ekleyebilir. Temel optimizasyonlar:

Nesne önbellekleme: WP_Query sonuçlarını önbelleğe almak ve şablon seçimine giren veritabanı sorgularının sayısını azaltmak için kalıcı bir nesne önbelleği (Redis veya Memcached) kullanın.

OPcache: PHP OPcache’in etkin ve düzgün yapılandırılmış olduğundan emin olun. Şablonlar PHP dosyaları olduğundan, OPcache bunları ilk yüklemede bayt koduna derler ve sonraki istekleri bellekten karşılar. Düzgün yapılandırılmış bir VPS with cPanel‘de OPcache genellikle varsayılan olarak etkindir, ancak çok sayıda şablon dosyasına sahip büyük temalar için opcache.memory_consumption ve opcache.max_accelerated_files ayarlarının yapılması gerekebilir.

Gereksiz şablon dosyalarından kaçının: Tema dizininizdeki her şablon dosyası, locate_template()‘ın kontrol etmesi gereken bir adaydır. Yüzlerce şablon dosyasına sahip temalar (şişirilmiş ticari temalarda yaygın), önbelleğe alınmamış her istekte dosya sistemi G/Ç’sini artırır. Temanızı denetleyin ve kullanılmayan şablonları kaldırın.

Tam sayfa önbellekleme: WP Rocket, W3 Total Cache veya sunucu düzeyinde önbellekleme (Nginx FastCGI önbelleği, Varnish) gibi araçlar, anonim kullanıcılar için PHP şablon yürütmesini tamamen atlar. Şablon hiyerarşisi çözümlemesi yalnızca önbellek ıskalandığında çalışır.

Pratik Özelleştirme Kalıpları

Kalıp 1: Eklenti Olmadan Kategoriye Özgü Düzen

Tema dizininizde category-news.php oluşturun. WordPress bunu otomatik olarak “news” kategori arşivi için kullanır. Eklenti yok, filtre kancası yok — sadece doğru ada sahip bir dosya.

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

Kalıp 2: Öne Çıkan Katkıda Bulunanlar için Yazar Başına Düzen

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

Kalıp 3: index.php İçinde Koşullu Mantık

Minimal bir tema oluşturuyorsanız ve birden fazla şablon dosyasından kaçınmak istiyorsanız, index.php içinde koşullu etiketler kullanabilirsiniz:

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

Bu kalıp, Twenty Twenty-One gibi temalar tarafından kullanılır ve tamamen geçerlidir. Takas, karmaşıklık arttıkça tek bir büyük index.php‘ın bakımının zorlaşmasıdır.

Çok Siteli Yapı ve Şablon Hiyerarşisi

Bir WordPress Çok Siteli ağında, ağdaki her site farklı bir aktif tema kullanabilir. Şablon hiyerarşisi site başına aynı şekilde çalışır, ancak ağ genelinde etkinleştirilen eklentiler, tema dosyalarını çoğaltmadan tüm sitelere paylaşılan şablonlar eklemek için template_include veya _{$type}_template_hierarchy filtrelerini kullanabilir.

Yaygın bir çok siteli kalıp, web kökünün dışında eklenti düzeyindeki filtre kancaları aracılığıyla başvurulan bir “ağ şablonu” dizinidir. Bu, merkezi bir tasarım ekibinin tüm sitelere şablon güncellemelerini aynı anda göndermesine olanak tanır — tek bir Shared Web Hosting veya VPS ortamında düzinelerce müşteri sitesini yöneten ajanslar için önemli bir operasyonel avantaj.

SSL, Güvenlik ve Şablon Dosyası İzinleri

Şablon dosyaları PHP’dir ve çalıştırılabilir kod olarak ele alınmalıdır. Yanlış dosya izinleri yaygın bir saldırı vektörüdür. Bir Linux sunucusunda, tema şablon dosyaları web sunucusu kullanıcısına (genellikle www-data veya nginx) ait olmalı ve 644 moduna ayarlanmalıdır:

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

PHP dosyalarını asla 777 olarak ayarlamayın. Bir şablon dosyası yazma erişimi gerektiriyorsa (alışılmadık ve genel olarak tavsiye edilmez), uygun grup sahipliğiyle 664 kullanın.

WordPress kurulumunuzu geçerli bir SSL Certificate ile eşleştirmek, şablon tarafından işlenen içeriğin — hassas kullanıcı verileri içeren dinamik olarak oluşturulan sayfalar dahil — her zaman HTTPS üzerinden iletilmesini sağlar. İletişim formları, kullanıcı hesapları veya e-ticaret kullanan herhangi bir site için bu tartışmasızdır.

Şablon Hiyerarşisi Referansı: Görsel Akış

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

Karar Matrisi: Hangi Özelleştirme Yaklaşımı Ne Zaman Kullanılır

Temel Teknik Çıkarımlar

• index.php zorunludur. Her tema bunu içermelidir. Her çözümleme zincirini sonlandıran evrensel geri dönüştür.
• singular.php kullanılmayan orta katmandır. Ne single.php ne de page.php mevcut olmadığında herhangi bir tekil gönderi veya sayfayı yakalar. Dosya sayısını azaltmak için minimal temalarda kullanın.
• front-page.php ön sayfa için her şeyi geçersiz kılar, Okuma ayarlarından bağımsız olarak. Mevcutsa her zaman yüklenir.
• Dosya adlandırma Linux sunucularında büyük/küçük harf duyarlıdır. WordPress category-news.php ararken Category-News.php eşleşmez. Bu, Query Monitor olmadan hata ayıklaması zor olan sessiz bir başarısızlıktır.
• template_include filtresi ana geçersiz kılmadır. Tüm hiyerarşi çözümlemesi tamamlandıktan sonra tetiklenir ve herhangi bir nedenden dolayı herhangi bir şablonu değiştirmek için son fırsatı sunar.
• Blok temalar şablonları PHP değil HTML olarak depolar. Hiyerarşi mantığı aynıdır, ancak dosya formatı ve dizin yapısı klasik temalardan temelden farklıdır.
• Alt tema functions.php, üst temanın yerine değil ek olarak yüklenir. Diğer tüm şablon dosyaları standart geçersiz kılma kalıbını takip eder.
• OPcache ayarı ölçekte önem taşır. Yüksek trafikli sitelerde, opcache.max_accelerated_files‘ın tüm tema şablonları dahil WordPress kurulumunuzdaki toplam PHP dosyası sayısını aştığından emin olun.
• WooCommerce şablonları WordPress hiyerarşisinin dışında bulunur. Temanizdeki woocommerce/ alt dizini aracılığıyla ayrı bir geçersiz kılma iş akışı gerektirirler.
• Şablon özelleştirme çalışmanızı, tüm şablon tarafından işlenen sayfalarda kurallı URL tutarlılığını sağlamak için düzgün yapılandırılmış bir alan adı ve Domain Registration ile eşleştirin.

SSS

WordPress hiyerarşide hiçbir şablon dosyası bulamazsa ne olur?

WordPress her geçerli tema için zorunlu olduğundan her zaman index.php‘ı bulur. index.php eksikse, WordPress ölümcül bir hata fırlatır ve boş bir sayfa veya sunucu hatası görüntüler. Bu, yokluğu siteyi tamamen bozan tek şablon dosyasıdır.

Aktif temayı değiştirmeden bir eklentide şablon hiyerarşisini kullanabilir miyim?

Evet. locate_template() çalışmadan önce aday diziye bir eklenti dizini yolu eklemek için _{$type}_template_hierarchy filtresini kullanın veya çözümleme sonrasında çözümlenen şablon yolunu değiştirmek için template_include‘ı kullanın. WooCommerce, bbPress ve çoğu büyük eklenti, tema değişikliği gerektirmeden kendi şablonlarını bu şekilde ekler.

Okuma ayarlarında “En son gönderileriniz”i ayarlamama rağmen front-page.php neden blog dizinimi geçersiz kılıyor?

Çünkü front-page.php tüm Okuma yapılandırmalarında ön sayfa için koşulsuz öncelik alır. Blog dizininin bunun yerine home.php kullanmasını istiyorsanız, temadan front-page.php‘ı yeniden adlandırın veya kaldırın. front-page.php içinde, ön sayfanın aynı zamanda blog dizini olup olmadığını tespit etmek ve buna göre işlemek için is_home() kullanın.

WordPress’in belirli bir sayfa için şu anda hangi şablon dosyasını kullandığını nasıl öğrenebilirim?

Query Monitor eklentisini yükleyin. Her sayfa yüklemesinde yönetici araç çubuğunda çözümlenen şablon yolunu ve tam aday hiyerarşisini görüntüler. Alternatif olarak, yolu yalnızca yöneticilere görünür bir HTML yorumu olarak çıkaran geçici bir template_include filtresi ekleyin.

Şablon hiyerarşisi WordPress Çok Siteli yapısında aynı şekilde çalışır mı?

Site başına çözümleme mantığı aynıdır. Her site şablonları kendi aktif temasına göre çözümler. Fark ağ düzeyindedir: ağ genelinde etkinleştirilen eklentiler, paylaşılan şablonları tüm sitelere eklemek için filtre kancalarını kullanabilir ve get_stylesheet_directory() fonksiyonu, paylaşılan bir ağ yolu değil, her bireysel sitenin aktif teması için doğru yolu döndürür.