Block ٹیمپلیٹ لاگو نہیں ہو رہا؟ شروعات ڈیٹابیس سے کریں

آپ کی ٹیمپلیٹ فائل تقریباً یقیناً اس لیے نظرانداز ہو رہی ہے کہ ڈیٹابیس میں پڑی ایک نقل جیت رہی ہے۔ جس لمحے آپ Site Editor میں ٹیمپلیٹ کھول کر Save دباتے ہیں، WordPress ایک wp_template پوسٹ ریکارڈ لکھ دیتا ہے، اور اس کے بعد سے تھیم فولڈر کی .html فائل کے بجائے وہی ریکارڈ پیش ہوتا ہے — یعنی بعد میں فائل پر کی گئی ہر ترمیم فرنٹ اینڈ پر غائب رہتی ہے۔ اس ریکارڈ کو صاف کرنا ہی حل ہے، اور ہائرارکی، فائل کے نام یا کیش کو ہاتھ لگانے سے پہلے یہی سب سے پہلے دیکھنا چاہیے۔

تصدیق کریں کہ ڈیٹابیس نقل موجود ہے

Appearance → Editor → Templates پر جائیں۔ جو بھی ٹیمپلیٹ WordPress ڈیٹابیس سے پیش کر رہا ہے، وہ فہرست میں نشان زد ہوتا ہے — آپ کے WordPress ورژن کے حساب سے بیج پر “Customized” لکھا ہوتا ہے یا ٹیمپلیٹ “Customized” فلٹر کے نیچے آتا ہے۔ وہی بیج پورا جواب ہے۔ اگر وہ موجود ہے تو آپ کی فائل استعمال نہیں ہو رہی۔

یہی بات کمانڈ لائن سے بھی جانچی جا سکتی ہے، جو تیز تر ہے اور تب بھی چلتی ہے جب 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

ہر قطار ایک ڈیٹابیس اوور رائیڈ ہے۔ post_name ٹیمپلیٹ کے slug سے ملتا ہے، یعنی single نام کی قطار templates/single.html پر سایہ ڈالے ہوئے ہے۔

ایک تفصیل لوگوں کو ضرور الجھاتی ہے: یہ ریکارڈ کسی راستے سے نہیں بلکہ ایک taxonomy term کے ذریعے تھیم سے جڑے ہوتے ہیں۔ اگر آپ اپنے تھیم کے فولڈر کا نام بدل دیں تو محفوظ ٹیمپلیٹس ڈیٹابیس میں تو رہتے ہیں مگر فعال تھیم سے میل کھانا چھوڑ دیتے ہیں، اور سائٹ اچانک فائلوں پر واپس آ جاتی ہے۔ یہ “میری تخصیصات غائب ہو گئیں” جیسا لگتا ہے، نہ کہ “میری فائل نظرانداز ہو رہی ہے” — طریقہ کار وہی ہے، علامت الٹی ہے۔

اسے صاف کریں

Site Editor میں ٹیمپلیٹ کا آپشنز مینیو کھولیں (اس کے ساتھ والے تین نقطے) اور Clear customizations چنیں — کچھ ورژنز میں اس پر Reset لکھا ہوتا ہے۔ اس سے ڈیٹابیس ریکارڈ حذف ہو جاتا ہے اور اختیار ڈسک پر پڑی فائل کو واپس مل جاتا ہے۔

اگر مینیو میں Clear customizations یا Reset کے بجائے Delete ہو، تو وہ ٹیمپلیٹ صرف ڈیٹابیس میں ہے اور اس کے پیچھے کوئی فائل نہیں۔ اسے حذف کرنے سے ٹیمپلیٹ مکمل ختم ہو جاتا ہے اور WordPress ہائرارکی میں نیچے کی طرف واپس چلا جاتا ہے۔

WP-CLI سے، اوپر والی فہرست کے کسی ID کے ساتھ:

wp post delete 482 --force

یہاں قیمت کے بارے میں خود سے کھرے رہیں: تخصیصات صاف کرنے سے وہ سب کچھ ہمیشہ کے لیے ضائع ہو جاتا ہے جو آپ نے اُس ٹیمپلیٹ کے لیے Site Editor میں بنایا تھا، اور اسے واپس نہیں لایا جا سکتا۔ اگر Site Editor والے نسخے میں واقعی محنت لگی ہے تو پہلے block markup باہر نقل کر لیں — ٹیمپلیٹ ایڈیٹر میں کھولیں، کوڈ ویو پر جائیں، اور نتیجہ اپنی .html فائل میں چسپاں کر دیں۔ اس طرح فائل ہی سچائی کا منبع بن جاتی ہے اور کچھ ضائع نہیں ہوتا۔

WordPress ٹیمپلیٹ کیسے چنتا ہے

block themes وہی ہائرارکی منطق استعمال کرتی ہیں جو classic themes کی ہے، بس تھیم کی جڑ میں .php فائلوں کے بجائے templates/ میں .html فائلیں ہوتی ہیں۔ WordPress سب سے مخصوص سے سب سے عام کی طرف چلتا ہے اور پہلی موجود فائل استعمال کر لیتا ہے۔

کیا دیکھا جا رہا ہے	جانچ کی ترتیب
ایک تنہا پوسٹ	single-post-{slug}.html → single-post.html → single.html → singular.html → index.html
ایک صفحہ	page-{slug}.html → page-{id}.html → page.html → singular.html → index.html
کیٹیگری آرکائیو	category-{slug}.html → category-{id}.html → category.html → archive.html → index.html
کسٹم پوسٹ ٹائپ	single-{post-type}.html → single.html → singular.html → index.html
404 صفحہ	404.html → index.html

دو چیزیں اس پوری ترتیب کو بےاثر کر دیتی ہیں۔ پہلی، اوپر بیان کیا گیا ڈیٹابیس ریکارڈ۔ دوسری، وہ ٹیمپلیٹ جو براہِ راست کسی پوسٹ یا صفحے پر مقرر کر دیا گیا ہو — پوسٹ ایڈیٹر کھولیں، سائیڈبار میں Template پینل دیکھیں، اور جانچیں کہ وہاں کوئی مخصوص چیز منتخب تو نہیں۔ صراحتاً مقرر کردہ ٹیمپلیٹ ہر بار ہائرارکی کو ہرا دیتا ہے، اور جب تک آپ خود جا کر نہ دیکھیں یہ نظر نہیں آتا۔

slug پر مبنی ٹیمپلیٹس ایسے نازک ہیں کہ یہ بات ذہن نشین کر لینی چاہیے۔ page-about.html صرف اُس وقت تک میل کھاتا ہے جب تک صفحے کا slug about ہے۔ صفحے کا نام about-us کریں اور ٹیمپلیٹ بغیر کسی وارننگ اور بغیر کسی ایرر کے لاگو ہونا بند کر دیتا ہے۔

ٹیمپلیٹ بمقابلہ ٹیمپلیٹ پارٹ

ٹیمپلیٹ پورا منظر رینڈر کرتا ہے اور ہائرارکی اسے منتخب کرتی ہے۔ ٹیمپلیٹ پارٹ ایک ٹکڑا ہے — ہیڈر، فوٹر، سائیڈبار — جسے ٹیمپلیٹس اپنے اندر کھینچتے ہیں۔ پارٹس parts/ میں رہتے ہیں، ٹیمپلیٹس templates/ میں، اور ڈیٹابیس میں یہ الگ الگ wp_template_part ریکارڈز کے طور پر محفوظ ہوتے ہیں۔

عام الجھن یہ ہے: آپ ہیڈر میں ترمیم کرتے ہیں، اور تبدیلی ان صفحات پر بھی آ جاتی ہے جنہیں آپ چھونا نہیں چاہتے تھے۔ یہ درست برتاؤ ہے۔ ایک پارٹ کو ہر وہ ٹیمپلیٹ استعمال کرتا ہے جو اسے شامل کرتا ہے۔ اگر آپ کو کسی ایک ٹیمپلیٹ پر مختلف ہیڈر چاہیے تو آپ کو دوسری پارٹ فائل اور ایسا ٹیمپلیٹ بنانا ہو گا جو اسی کا حوالہ دے — مشترکہ پارٹ میں ترمیم سے فی ٹیمپلیٹ فرق کبھی نہیں ملے گا۔

اس کا الٹ بھی ہوتا ہے۔ آپ پورے صفحے کا لے آؤٹ parts/ میں رکھ دیتے ہیں اور حیران ہوتے ہیں کہ ہائرارکی اسے اٹھاتی کیوں نہیں۔ پارٹس ہائرارکی میں امیدوار ہوتے ہی نہیں؛ کوئی درخواست کبھی براہِ راست ان تک نہیں پہنچے گی۔

فائل کا نام اور مقام

کسی زیادہ عجیب وجہ کا سوچنے سے پہلے یہ دیکھ لیں:

• فولڈر تھیم کی جڑ میں templates/ ہے، جمع کی صورت میں۔ نہ template/، نہ block-templates/۔ block-templates/ اُس زمانے کا درست نام تھا جب block themes core میں آنے سے پہلے Gutenberg پلگ اِن کا حصہ تھیں، اور بہت سے ٹیوٹوریلز اب بھی یہی دکھاتے ہیں — موجودہ WordPress میں یہ کام نہیں کرتا۔
• ٹیمپلیٹ پارٹس parts/ میں جاتے ہیں، template-parts/ میں نہیں (وہ PHP کے ٹکڑوں کے لیے classic-theme کا طریقہ ہے)۔
• ایکسٹینشن .html ہے۔ templates/ میں پڑی کوئی .php فائل نظرانداز ہو جاتی ہے۔
• فائلوں کے نام چھوٹے حروف میں اور ہائفن کے ساتھ ہوتے ہیں۔ single-Post.html یا single_post.html میل نہیں کھائیں گے۔ macOS جیسے حروف کی چھوٹائی بڑائی نظرانداز کرنے والے فائل سسٹم پر یہ مقامی طور پر چل جاتا ہے اور Linux سرور پر ٹوٹ جاتا ہے — کلاسک “میری مشین پر تو چل رہا تھا” والی خرابی۔
• templates/index.html کا موجود ہونا لازم ہے۔ اس کے بغیر WordPress تھیم کو block theme شمار نہیں کرتا اور Site Editor شاید بالکل ظاہر ہی نہ ہو۔
• اگر آپ چائلڈ تھیم میں کام کر رہے ہیں تو اس کے ٹیمپلیٹس پیرنٹ پر فوقیت رکھتے ہیں۔ چائلڈ تھیم میں رہ گئی کوئی پرانی فائل خاموشی سے اُس پیرنٹ فائل کو ہرا دے گی جس میں آپ ترمیم کر رہے ہیں۔

جو کسٹم ٹیمپلیٹس پوسٹ ایڈیٹر میں قابلِ انتخاب ہونے چاہییں، انہیں theme.json کے customTemplates کے نیچے بھی بیان کرنا پڑتا ہے — فائل کے بنیادی نام، ایک قابلِ فہم عنوان، اور ان پوسٹ اقسام کے ساتھ جن پر یہ لاگو ہوں۔ اس اندراج کے بغیر فائل موجود تو رہتی ہے مگر Template پینل میں کبھی ظاہر نہیں ہوتی۔

کیشنگ — اسے سب سے آخر میں دیکھیں

کیشنگ ایک حقیقی چیز ہے مگر یہ سب سے کم ممکن وجہ ہے، اور سب سے پہلے اسی کی طرف لپکنا وہ طریقہ ہے جس سے لوگ پوری دوپہر ضائع کرتے ہیں۔

اپنا پیج کیش صاف کریں، اور اگر آپ Redis یا Memcached جیسا مستقل آبجیکٹ کیش چلاتے ہیں تو اسے بھی خالی کریں — ٹیمپلیٹ حل ہونے کے نتائج وہاں رکے ہو سکتے ہیں۔ پھر براؤزر کیش نظرانداز کر کے صفحہ دوبارہ لوڈ کریں۔

جو چیز مدد نہیں کرے گی: OPcache صاف کرنا۔ block ٹیمپلیٹس .html فائلیں ہیں اور PHP انہیں کبھی کمپائل نہیں کرتا، اس لیے OPcache کا ان سے کوئی تعلق نہیں۔ اگر کبھی آپ کو لگا کہ OPcache خالی کرنے سے یہ ٹھیک ہوا تو اُسی وقت کوئی اور چیز بھی بدلی تھی۔

پھر بھی پھنسے ہوئے ہیں؟

اگر ڈیٹابیس ریکارڈ نہیں، فائل کا نام درست ہے، پوسٹ پر کوئی ٹیمپلیٹ صراحتاً مقرر نہیں، اور کیشیں بھی صاف ہو چکی ہیں، تو پلگ اِنز کو دیکھیں۔ کوئی بھی چیز جو ٹیمپلیٹ حل ہونے کے عمل کو فلٹر کرتی ہو — page builder، ممبرشپ پلگ اِن، کثیر لسانی پلگ اِن، یا LMS — درخواست کے آخری حصے میں اپنا ٹیمپلیٹ بدل کر رکھ سکتی ہے۔ کسی ڈیفالٹ block theme پر جائیں اور پلگ اِنز بند کر کے آزمائیں، پھر ایک ایک کر کے دوبارہ چالو کریں۔

اور اگر ٹیمپلیٹ لاگو تو ہو رہا ہے مگر خالی رینڈر ہوتا ہے، تو یہ الگ مسئلہ ہے: جانچیں کہ فائل میں موجود block markup درست ہے، کیونکہ خراب block تبصرہ ایڈیٹر سے ایرر پھینکوانے کے بجائے خاموشی سے مواد چھانٹ دیتا ہے۔