Block Template WordPress Tidak Berubah? Mulai dari Database

File template Anda hampir pasti diabaikan karena ada salinan di database yang menang. Begitu Anda membuka sebuah template di Site Editor lalu menekan Save, WordPress menulis catatan pos wp_template, dan sejak saat itu catatan tersebutlah yang disajikan menggantikan file .html di folder tema Anda — sehingga setiap perubahan pada file setelahnya tidak terlihat di front end. Menghapus catatan itu adalah solusinya, dan itu hal pertama yang harus diperiksa sebelum Anda menyentuh hierarki, nama file, atau cache.

Pastikan salinan database itu ada

Masuk ke Appearance → Editor → Templates. Setiap template yang disajikan WordPress dari database ditandai di daftar — tergantung versi WordPress Anda, lencananya bertuliskan “Customized” atau templatenya muncul di bawah filter “Customized”. Lencana itu sudah menjawab semuanya. Kalau ada, berarti file Anda tidak dipakai.

Anda bisa memeriksa hal yang sama dari baris perintah, yang lebih cepat dan tetap bekerja bahkan ketika Site Editor bertingkah:

wp post list --post_type=wp_template --fields=ID,post_name,post_status,post_title
wp post list --post_type=wp_template_part --fields=ID,post_name,post_status,post_title

Setiap baris adalah satu penimpaan dari database. post_name cocok dengan slug template, jadi baris bernama single sedang membayangi templates/single.html.

Satu detail yang sering menjebak: catatan ini terikat ke sebuah tema lewat term taksonomi, bukan lewat jalur file. Kalau Anda mengganti nama folder tema, template tersimpan tetap ada di database tetapi berhenti cocok dengan tema aktif, dan situs mendadak jatuh kembali ke file. Itu terlihat seperti “kustomisasi saya hilang” ketimbang “file saya diabaikan” — mekanismenya sama, gejalanya berkebalikan.

Hapus catatan itu

Di Site Editor, buka menu opsi template (tiga titik di sebelahnya) lalu pilih Clear customizations — beberapa versi memberinya label Reset. Itu menghapus catatan database dan kendali kembali ke file di disk.

Kalau menunya menawarkan Delete alih-alih Clear customizations atau Reset, berarti template itu ada hanya di database dan tidak punya file di baliknya. Menghapusnya berarti membuang templatenya sama sekali dan WordPress turun mengikuti hierarki.

Lewat WP-CLI, memakai ID dari daftar di atas:

wp post delete 482 --force

Jujurlah pada diri sendiri soal ongkosnya di sini: membersihkan kustomisasi akan membuang secara permanen apa pun yang Anda bangun di Site Editor untuk template tersebut, dan itu tidak bisa dibatalkan. Kalau versi Site Editor memuat pekerjaan yang berarti, salin dulu markup bloknya keluar — buka templatenya di editor, pindah ke tampilan kode, lalu tempel hasilnya ke file .html Anda. Dengan begitu file menjadi sumber kebenaran dan tidak ada yang hilang.

Bagaimana WordPress memilih template

Block theme memakai logika hierarki yang sama dengan classic theme, hanya saja dengan file .html di templates/ alih-alih file .php di root tema. WordPress berjalan dari yang paling spesifik ke yang paling umum dan memakai file pertama yang ditemukannya.

Yang sedang dilihat	Diperiksa dengan urutan ini
Sebuah pos tunggal	single-post-{slug}.html → single-post.html → single.html → singular.html → index.html
Sebuah halaman	page-{slug}.html → page-{id}.html → page.html → singular.html → index.html
Arsip kategori	category-{slug}.html → category-{id}.html → category.html → archive.html → index.html
Sebuah custom post type	single-{post-type}.html → single.html → singular.html → index.html
Halaman 404	404.html → index.html

Ada dua hal yang menimpa ini sepenuhnya. Pertama, catatan database yang dijelaskan di atas. Kedua, template yang ditetapkan langsung ke sebuah pos atau halaman — buka editor pos, cari panel Template di sidebar, lalu periksa apakah ada pilihan spesifik di sana. Penetapan eksplisit selalu mengalahkan hierarki, dan itu tidak terlihat kecuali Anda sengaja mencarinya.

Template berbasis slug rapuh dengan cara yang layak diingat baik-baik. page-about.html hanya cocok selama slug halamannya about. Ganti nama halaman itu menjadi about-us dan templatenya berhenti berlaku tanpa peringatan dan tanpa pesan kesalahan.

Template versus template part

Sebuah template merender satu tampilan utuh dan dipilih oleh hierarki. Sebuah template part adalah potongan — header, footer, sidebar — yang ditarik masuk oleh template. Part tinggal di parts/, template tinggal di templates/, dan keduanya disimpan terpisah di database sebagai catatan wp_template_part.

Kebingungan yang umum: Anda mengedit header, lalu perubahannya muncul di halaman yang tidak ingin Anda sentuh. Itu perilaku yang benar. Satu part dipakai bersama oleh setiap template yang menyertakannya. Kalau Anda ingin header berbeda pada satu template, Anda butuh file part kedua dan sebuah template yang merujuknya — mengedit part yang dipakai bersama tidak akan pernah memberi Anda variasi per template.

Kebalikannya juga terjadi. Anda menaruh tata letak halaman utuh di parts/ lalu heran kenapa hierarki tidak pernah mengambilnya. Part sama sekali bukan kandidat dalam hierarki; tidak akan pernah ada rute yang mengarah langsung ke sana.

Penamaan dan lokasi file

Periksa hal-hal ini sebelum menduga sesuatu yang lebih rumit:

• Foldernya adalah templates/, bentuk jamak, di root tema. Bukan template/, bukan block-templates/. block-templates/ memang nama yang benar pada era plugin Gutenberg sebelum block theme masuk ke core, dan banyak tutorial masih menampilkannya — itu tidak bekerja di WordPress sekarang.
• Template part masuk ke parts/, bukan template-parts/ (yang merupakan konvensi classic theme untuk partial PHP).
• Ekstensinya .html. File .php di dalam templates/ diabaikan.
• Nama file memakai huruf kecil dan tanda hubung. single-Post.html atau single_post.html tidak akan cocok. Pada filesystem yang tidak membedakan huruf besar-kecil seperti macOS, ini jalan di lokal dan rusak di server Linux — kegagalan klasik “jalan kok di komputer saya”.
• templates/index.html wajib ada. Tanpa itu, WordPress tidak menggolongkan temanya sebagai block theme dan Site Editor bisa saja tidak muncul sama sekali.
• Kalau Anda bekerja di tema anak, templatenya berprioritas di atas milik tema induk. File sisa di tema anak akan diam-diam mengalahkan file induk yang sedang Anda edit.

Template kustom yang seharusnya bisa dipilih di editor pos juga perlu dideklarasikan di theme.json di bawah customTemplates, lengkap dengan nama dasar filenya, judul yang mudah dibaca manusia, dan post type yang berlaku untuknya. Tanpa entri itu, filenya ada tetapi tidak pernah muncul di panel Template.

Caching — periksa paling akhir

Caching itu nyata, tetapi ini penyebab yang paling kecil kemungkinannya, dan mendahulukannya adalah cara orang membuang waktu seharian.

Bersihkan cache halaman Anda dan, kalau Anda memakai object cache persisten seperti Redis atau Memcached, bersihkan juga itu — hasil penentuan template bisa tertahan di sana. Lalu muat ulang dengan cache browser dilewati.

Yang tidak akan membantu: membersihkan OPcache. Block template adalah file .html dan tidak pernah dikompilasi PHP, jadi OPcache tidak ada hubungannya dengan ini. Kalau membersihkan OPcache pernah terlihat menyelesaikan masalah ini, ada hal lain yang berubah pada saat bersamaan.

Masih buntu?

Kalau tidak ada catatan database, nama filenya benar, tidak ada penetapan template eksplisit pada pos, dan cache sudah dibersihkan, lihat ke plugin. Apa pun yang memfilter penentuan template — page builder, plugin membership, plugin multibahasa, LMS — bisa menyisipkan templatenya sendiri di akhir permintaan. Ganti ke block theme bawaan dan uji dengan semua plugin dimatikan, lalu aktifkan satu per satu.

Dan kalau templatenya memang diterapkan tetapi tampil kosong, itu masalah yang berbeda: periksa apakah markup blok di dalam file itu valid, sebab komentar blok yang rusak bisa membuat editor membuang konten tanpa suara alih-alih memunculkan pesan kesalahan.