Block template-ul din WordPress nu se aplică? Începe cu baza de date

Fișierul tău de șablon este aproape sigur ignorat pentru că o copie din baza de date câștigă. În clipa în care deschizi un șablon în Editorul de site și apeși Salvează, WordPress scrie o înregistrare de tip wp_template, iar de atunci acea înregistrare este servită în locul fișierului .html din folderul temei — deci orice modificare faci ulterior în fișier este invizibilă pe front-end. Ștergerea acelei înregistrări este soluția și este primul lucru de verificat, înainte să umbli la ierarhie, la numele fișierului sau la cache.

Confirmă că există copia din baza de date

Mergi la Aspect → Editor → Șabloane. Orice șablon pe care WordPress îl servește din baza de date este marcat în listă — în funcție de versiunea ta de WordPress, eticheta scrie „Personalizat” sau șablonul apare sub un filtru „Personalizate”. Eticheta aceea este tot răspunsul. Dacă e acolo, fișierul tău nu este folosit.

Poți verifica același lucru din linia de comandă, ceea ce este mai rapid și funcționează chiar și când Editorul de site face figuri:

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

Fiecare rând este o suprascriere din baza de date. Valoarea post_name corespunde slug-ului șablonului, deci un rând numit single umbrește templates/single.html.

Un detaliu care încurcă lumea: aceste înregistrări sunt legate de o temă printr-un termen de taxonomie, nu printr-o cale de fișier. Dacă redenumești folderul temei, șabloanele salvate rămân în baza de date, dar nu se mai potrivesc cu tema activă, iar site-ul cade brusc înapoi pe fișiere. Asta arată ca „mi-au dispărut personalizările”, nu ca „fișierul meu e ignorat” — același mecanism, simptom opus.

Șterge-o

În Editorul de site, deschide meniul de opțiuni al șablonului (cele trei puncte de lângă el) și alege Șterge personalizările — unele versiuni o numesc Resetează. Asta șterge înregistrarea din baza de date, iar controlul revine fișierului de pe disc.

Dacă meniul oferă Șterge în loc de Șterge personalizările sau Resetează, acel șablon există doar în baza de date și nu are niciun fișier în spate. Ștergerea lui elimină complet șablonul, iar WordPress coboară pe ierarhie.

Din WP-CLI, folosind un ID din lista de mai sus:

wp post delete 482 --force

Fii sincer cu tine în privința costului: ștergerea personalizărilor aruncă definitiv tot ce ai construit în Editorul de site pentru acel șablon și nu se poate anula. Dacă versiunea din Editorul de site conține muncă reală, copiază întâi markup-ul de blocuri — deschide șablonul în editor, comută pe vizualizarea de cod și lipește rezultatul în fișierul tău .html. Așa fișierul devine sursa de adevăr și nu se pierde nimic.

Cum alege WordPress un șablon

Temele bloc folosesc aceeași logică de ierarhie ca temele clasice, doar cu fișiere .html în templates/ în loc de fișiere .php în rădăcina temei. WordPress merge de la cel mai specific la cel mai general și folosește primul fișier care există.

Ce se vizualizează	Se verifică în această ordine
Un articol individual	single-post-{slug}.html → single-post.html → single.html → singular.html → index.html
O pagină	page-{slug}.html → page-{id}.html → page.html → singular.html → index.html
O arhivă de categorie	category-{slug}.html → category-{id}.html → category.html → archive.html → index.html
Un tip de conținut personalizat	single-{post-type}.html → single.html → singular.html → index.html
Pagina 404	404.html → index.html

Două lucruri anulează complet asta. Primul, înregistrarea din baza de date descrisă mai sus. Al doilea, un șablon atribuit direct unui articol sau unei pagini — deschide editorul de articole, caută panoul Șablon din bara laterală și verifică dacă este selectat ceva anume acolo. O atribuire explicită bate ierarhia de fiecare dată și este invizibilă dacă nu te duci special să o cauți.

Șabloanele bazate pe slug sunt fragile într-un fel pe care merită să-l ții minte. page-about.html se potrivește doar cât timp slug-ul paginii este about. Redenumești pagina în about-us și șablonul încetează să se aplice, fără avertisment și fără eroare.

Șablon versus parte de șablon

Un șablon randează o vizualizare întreagă și este ales de ierarhie. O parte de șablon este un fragment — antet, subsol, bară laterală — pe care șabloanele îl includ. Părțile stau în parts/, șabloanele stau în templates/, iar în baza de date sunt stocate separat, ca înregistrări wp_template_part.

Confuzia obișnuită: editezi antetul, iar modificarea apare pe pagini pe care nu intenționai să le atingi. Este comportamentul corect. O parte este partajată de fiecare șablon care o include. Dacă vrei un antet diferit pe un singur șablon, ai nevoie de un al doilea fișier de parte și de un șablon care îl referențiază — editarea celei partajate nu îți va da niciodată variație per șablon.

Se întâmplă și invers. Pui un layout complet de pagină în parts/ și te miri de ce nu îl alege niciodată ierarhia. Părțile nu sunt deloc candidate în ierarhie; nimic nu va rula vreodată direct spre ele.

Denumirea și locația fișierelor

Verifică astea înainte să presupui ceva mai exotic:

• Folderul este templates/, la plural, în rădăcina temei. Nu template/, nu block-templates/. block-templates/ a fost numele corect în perioada pluginului Gutenberg, înainte ca temele bloc să ajungă în nucleu, iar multe tutoriale îl arată în continuare — în WordPress-ul actual nu funcționează.
• Părțile de șablon merg în parts/, nu în template-parts/ (care este convenția temelor clasice pentru fragmentele PHP).
• Extensia este .html. Un fișier .php din templates/ este ignorat.
• Numele de fișiere se scriu cu litere mici și cu cratime. single-Post.html sau single_post.html nu se vor potrivi. Pe un sistem de fișiere care nu ține cont de majuscule, cum e macOS, merge local și se strică pe un server Linux — clasicul eșec de tip „la mine pe calculator merge”.
• templates/index.html trebuie să existe. Fără el, WordPress nu clasifică tema ca temă bloc, iar Editorul de site s-ar putea să nu apară deloc.
• Dacă lucrezi într-o temă child, șabloanele ei au prioritate față de cele ale temei părinte. Un fișier rămas uitat în tema child va bate în tăcere fișierul din tema părinte pe care îl editezi.

Șabloanele personalizate care ar trebui să poată fi selectate din editorul de articole trebuie declarate și în theme.json, sub customTemplates, cu numele de bază al fișierului, un titlu lizibil și tipurile de conținut cărora li se aplică. Fără acea intrare, fișierul există, dar nu apare niciodată în panoul Șablon.

Cache-ul — verifică-l ultimul

Cache-ul este o problemă reală, dar este cea mai puțin probabilă cauză, iar dacă începi cu el pierzi o după-amiază.

Golește cache-ul de pagină și, dacă rulezi un cache persistent de obiecte precum Redis sau Memcached, golește-l și pe acela — rezultatele rezolvării șabloanelor pot fi ținute acolo. Apoi reîncarcă pagina ocolind cache-ul browserului.

Ce nu ajută: golirea OPcache. Block template-urile sunt fișiere .html și nu sunt niciodată compilate de PHP, deci OPcache nu are nicio legătură cu ele. Dacă odată ți s-a părut că golirea OPcache a rezolvat asta, altceva s-a schimbat în același timp.

Tot blocat?

Dacă nu există înregistrare în baza de date, numele fișierului este corect, nu există un șablon atribuit explicit articolului, iar cache-urile sunt deja golite, uită-te la pluginuri. Orice filtrează rezolvarea șabloanelor — un page builder, un plugin de membership, unul multilingv, un LMS — poate substitui propriul șablon târziu în cerere. Comută pe o temă bloc implicită și testează cu pluginurile dezactivate, apoi reactivează-le pe rând.

Iar dacă șablonul chiar se aplică, dar se randează gol, aceea este altă problemă: verifică dacă markup-ul de blocuri din fișier este valid, pentru că un comentariu de bloc prost format poate face editorul să elimine conținutul în tăcere, în loc să arunce o eroare.