Block template लागू नहीं हो रहा? शुरुआत database से कीजिए

आपकी template फ़ाइल लगभग निश्चित रूप से इसलिए अनदेखी हो रही है क्योंकि database में पड़ी एक प्रति जीत रही है। जिस पल आप Site Editor में कोई template खोलकर Save दबाते हैं, WordPress एक wp_template post record लिख देता है, और उसके बाद आपके theme folder की .html फ़ाइल की जगह वही record परोसा जाता है — यानी उसके बाद फ़ाइल में आप जो भी बदलाव करते हैं वह front end पर दिखता ही नहीं। उस record को हटाना ही फिक्स है, और hierarchy, filename या cache छूने से पहले सबसे पहले यही जाँचना चाहिए।

पुष्टि कीजिए कि database वाली प्रति मौजूद है

Appearance → Editor → Templates पर जाइए। जिस भी template को WordPress database से परोस रहा है, वह सूची में चिह्नित होता है — आपके WordPress संस्करण के हिसाब से badge पर “Customized” लिखा होता है या template एक “Customized” filter के नीचे दिखता है। वही badge पूरा जवाब है। अगर वह मौजूद है, तो आपकी फ़ाइल इस्तेमाल नहीं हो रही।

यही चीज़ command line से भी जाँची जा सकती है, जो तेज़ है और तब भी काम करती है जब Site Editor ठीक से चल न रहा हो:

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

हर पंक्ति एक database override है। post_name template के slug से मेल खाता है, इसलिए single नाम की पंक्ति templates/single.html पर छाया डाल रही है।

एक बात लोगों को उलझाती है: ये records किसी path से नहीं, बल्कि एक taxonomy term के ज़रिए theme से जुड़े होते हैं। अगर आप अपने theme के folder का नाम बदल देते हैं, तो सहेजे गए templates database में तो रहते हैं पर सक्रिय theme से मेल खाना बंद कर देते हैं, और साइट अचानक फ़ाइलों पर लौट आती है। यह “मेरा फ़ाइल अनदेखा हो रहा है” के बजाय “मेरे customizations ग़ायब हो गए” जैसा दिखता है — तंत्र वही है, लक्षण उल्टा।

इसे हटाइए

Site Editor में template का options menu खोलिए (उसके बग़ल वाले तीन बिंदु) और Clear customizations चुनिए — कुछ संस्करणों में इस पर Reset लिखा होता है। इससे database record मिट जाता है और नियंत्रण डिस्क की फ़ाइल के पास लौट आता है।

अगर menu में Clear customizations या Reset के बजाय Delete दिखे, तो वह template सिर्फ़ database में मौजूद है और उसके पीछे कोई फ़ाइल नहीं है। उसे delete करने से template पूरी तरह हट जाता है और WordPress hierarchy में नीचे की ओर fallback कर जाता है।

WP-CLI से, ऊपर की सूची में से कोई ID लेकर:

wp post delete 482 --force

यहाँ क़ीमत के बारे में ख़ुद से ईमानदार रहिए: customizations साफ़ करने से उस template के लिए Site Editor में आपने जो कुछ बनाया था वह हमेशा के लिए मिट जाता है, और उसे वापस नहीं लाया जा सकता। अगर Site Editor वाले संस्करण में असली काम पड़ा है, तो पहले block markup बाहर copy कर लीजिए — template को editor में खोलिए, code view पर जाइए, और नतीजा अपनी .html फ़ाइल में चिपका दीजिए। इससे फ़ाइल ही सच्चाई का स्रोत बन जाती है और कुछ भी नहीं खोता।

WordPress template कैसे चुनता है

Block themes वही hierarchy तर्क इस्तेमाल करती हैं जो classic themes करती हैं, बस theme की जड़ में .php फ़ाइलों की जगह templates/ में .html फ़ाइलें होती हैं। WordPress सबसे विशिष्ट से सबसे सामान्य की ओर चलता है और पहली मौजूद फ़ाइल इस्तेमाल कर लेता है।

क्या देखा जा रहा है	जाँच का क्रम
कोई एक post	single-post-{slug}.html → single-post.html → single.html → singular.html → index.html
कोई page	page-{slug}.html → page-{id}.html → page.html → singular.html → index.html
Category archive	category-{slug}.html → category-{id}.html → category.html → archive.html → index.html
Custom post type	single-{post-type}.html → single.html → singular.html → index.html
404 पेज	404.html → index.html

दो चीज़ें इस पूरे क्रम को दरकिनार कर देती हैं। पहली, ऊपर बताया गया database record। दूसरी, किसी post या page पर सीधे असाइन किया गया template — post editor खोलिए, sidebar में Template panel देखिए, और जाँचिए कि वहाँ कुछ ख़ास चुना हुआ तो नहीं है। साफ़ तौर पर की गई असाइनमेंट हर बार hierarchy को हरा देती है, और जब तक आप ढूँढने न जाएँ यह दिखती भी नहीं।

Slug आधारित templates एक ऐसे तरीक़े से नाज़ुक हैं जिसे समझ लेना ज़रूरी है। page-about.html सिर्फ़ तभी तक मेल खाता है जब तक पेज का slug about है। पेज का नाम बदलकर about-us कर दीजिए और template बिना किसी चेतावनी और बिना किसी error के लागू होना बंद कर देता है।

Template बनाम template part

Template पूरा दृश्य render करता है और hierarchy से चुना जाता है। Template part एक टुकड़ा है — header, footer, sidebar — जिसे templates अपने अंदर खींचते हैं। Parts parts/ में रहते हैं, templates templates/ में, और database में वे wp_template_part records के रूप में अलग सहेजे जाते हैं।

आम उलझन: आप header संपादित करते हैं, और बदलाव उन पेजों पर दिखने लगता है जिन्हें आप छूना ही नहीं चाहते थे। यह सही व्यवहार है। एक ही part हर उस template में साझा है जो उसे शामिल करता है। अगर आपको किसी एक template पर अलग header चाहिए, तो आपको एक दूसरी part फ़ाइल चाहिए और एक ऐसा template जो उसे संदर्भित करे — साझा part को संपादित करके आपको कभी भी अलग-अलग template के लिए अलग नतीजा नहीं मिलेगा।

उल्टा भी होता है। आप पूरा page layout parts/ में रख देते हैं और सोचते हैं कि hierarchy उसे उठाती क्यों नहीं। Parts hierarchy में उम्मीदवार होते ही नहीं; कोई request सीधे उन तक कभी नहीं पहुँचेगी।

फ़ाइल के नाम और जगह

कुछ भी ज़्यादा असामान्य मानने से पहले ये जाँच लीजिए:

• फ़ोल्डर templates/ है, बहुवचन में, theme की जड़ में। न template/, न block-templates/। block-templates/ उस Gutenberg-plugin वाले दौर का सही नाम था जब block themes core में नहीं आई थीं, और बहुत से tutorials आज भी वही दिखाते हैं — मौजूदा WordPress में यह काम नहीं करता।
• Template parts parts/ में जाते हैं, template-parts/ में नहीं (वह PHP partials के लिए classic-theme की परंपरा है)।
• एक्सटेंशन .html है। templates/ में रखी .php फ़ाइल अनदेखी कर दी जाती है।
• Filenames छोटे अक्षरों में होते हैं और hyphens इस्तेमाल करते हैं। single-Post.html या single_post.html मेल नहीं खाएँगे। macOS जैसे case-insensitive filesystem पर यह स्थानीय रूप से चल जाता है और Linux सर्वर पर टूट जाता है — क्लासिक “मेरी मशीन पर तो चलता है” वाली गड़बड़।
• templates/index.html का होना ज़रूरी है। उसके बिना WordPress theme को block theme मानता ही नहीं और Site Editor शायद दिखे ही नहीं।
• अगर आप child theme में काम कर रहे हैं, तो उसके templates parent के templates पर भारी पड़ते हैं। Child theme में छूटी हुई कोई पुरानी फ़ाइल चुपचाप उस parent फ़ाइल को हरा देगी जिसे आप संपादित कर रहे हैं।

जिन custom templates को post editor में चुना जा सकना चाहिए, उन्हें theme.json में customTemplates के नीचे घोषित करना भी ज़रूरी है — फ़ाइल का base नाम, एक पढ़ने योग्य शीर्षक, और वे post types जिन पर वह लागू होता है। उस entry के बिना फ़ाइल मौजूद तो रहती है पर Template panel में कभी नहीं आती।

Caching — इसे सबसे आख़िर में जाँचिए

Caching असली वजह हो सकती है, पर यह सबसे कम संभावित है, और सबसे पहले इसी की ओर भागना वह तरीक़ा है जिससे लोग पूरी दोपहर गँवा देते हैं।

अपना page cache purge कीजिए, और अगर Redis या Memcached जैसा persistent object cache चला रहे हैं तो उसे भी flush कीजिए — template resolution के नतीजे वहाँ रुके हो सकते हैं। फिर browser cache को दरकिनार करके पेज दोबारा लोड कीजिए।

जिससे मदद नहीं मिलेगी: OPcache साफ़ करना। Block templates .html फ़ाइलें हैं और PHP उन्हें कभी compile नहीं करता, इसलिए OPcache का इनसे कोई लेना-देना नहीं। अगर कभी OPcache flush करने से यह ठीक होता लगा हो, तो उसी समय कुछ और भी बदला होगा।

फिर भी अटके हैं?

अगर कोई database record नहीं है, filename सही है, post पर कोई template साफ़ तौर पर असाइन नहीं है, और caches पहले ही purge हो चुके हैं, तो plugins की तरफ़ देखिए। Template resolution को filter करने वाली कोई भी चीज़ — page builder, membership plugin, बहुभाषी plugin, LMS — request के आख़िर में अपना template बदलकर रख सकती है। किसी default block theme पर जाइए और plugins बंद करके परखिए, फिर एक-एक करके चालू कीजिए।

और अगर template लागू तो हो रहा है पर ख़ाली render होता है, तो यह अलग समस्या है: जाँचिए कि फ़ाइल का block markup सही है या नहीं, क्योंकि टूटा हुआ block comment editor से error फेंकवाने के बजाय चुपचाप content हटवा सकता है।