چگونه قالب خراب را بدون از دست دادن محتوا رفع کنیم؟

یک شب، پیامی از مشتری رسید: «صفحهٔ اصلی سفید شده، هیچ‌چیز نیست». آخرین کاری که کرده بود، به‌روزرسانی قالب بود. با خونسردی و از یک مسیر آشنا — فعال‌سازی قالب پیش‌فرض، بازگشت به نسخهٔ قبلی، عیب‌یابی جداگانه — کل مسئله در کمتر از بیست دقیقه حل شد. مشتری تعجب کرد که چرا نگران نشدم. پاسخ ساده بود: قالب خراب، اگر پیش از آن یک بکاپ و یک مسیر بازگشت داشته باشید، فاجعه نیست؛ فقط یک وقفهٔ کوتاه در دسترسی است. این مقاله، همان مسیری است که امروز برای رفع قالب خراب و بازگشت بی‌آسیب به وضعیت سالم، طی می‌کنم.

حقیقت مهم: در بیشتر موارد، محتوا گم نمی‌شود

بزرگ‌ترین ترسی که کاربران در لحظهٔ خرابی قالب تجربه می‌کنند این است که «محتوای سایت از دست رفته». اما این ترس، در اکثر موارد بی‌اساس است. وردپرس محتوای شما را در دیتابیس MySQL (My Structured Query Language — سیستم مدیریت پایگاه دادهٔ متن‌باز) نگه می‌دارد، نه در فایل‌های قالب. قالب فقط لایهٔ نمایش است و اگر آن لایه بشکند، محتوا همچنان سرِ جایش در دیتابیس باقی می‌ماند — حتی اگر آن را نبینید.

این تفکیک، نقطهٔ آرامش شماست: قالب خراب، یعنی سایت ناپدید شده؛ نه یعنی محتوا گم شده. برای درک کامل این ساختار، قالب وردپرس چیست و چگونه انتخاب کنیم را بخوانید؛ آن‌جا این لایه‌بندی را با جزئیات باز کرده‌ام. اما یادآوری مهم: در دو حالت خاص، محتوای شما در معرض خطر جدی قرار می‌گیرد — وقتی قالب خودش کدهای ویرایشیِ فایل‌محور دارد، و وقتی شورت‌کدهای اختصاصی قالب، بخشی از محتوای شما را در خودشان نگه داشته‌اند. این دو حالت، در بخش «نقشهٔ دقیق» به آن‌ها می‌رسیم.

قالب خراب، محتوا را نمی‌خورد؛ فقط پنهانش می‌کند. تفاوت این دو جمله، تفاوت بین وحشت و واکنش درست است.

ریشه‌های خرابی قالب و نشانهٔ هرکدام

پیش از هر اقدامی، باید بدانید کدام ریشه، این خرابی را ایجاد کرده. در تجربه‌ام، پنج ریشه وجود دارد و هرکدام نشانهٔ اختصاصی خودش را دارند:

این جدول، ترتیب تشخیص را هم به شما می‌دهد. اولین سؤال، همیشه این است: «آخرین تغییر چه بود؟». اگر آخرین تغییر، به‌روزرسانی هسته بوده، احتمال اینکه قالب با نسخهٔ جدید ناسازگار باشد بالاست. اگر آخرین تغییر، ویرایش دستی فایل بوده، احتمال خطای PHP بیشتر است. این «آخرین تغییر» در اکثر موارد، کلید اصلی تشخیص است و چند ساعت عیب‌یابی را حذف می‌کند.

اقدام اول: بازگشت سریع به قالب پیش‌فرض

اولین اقدام در بحران، بازگرداندن سایت به وضعیت کارکننده است — نه عیب‌یابی دقیق قالب خراب. تفکیک این دو مرحله، مهم‌ترین تصمیم شماست. وقتی سایت خواب است، وقت ندارید که ساعتی روی قالب کار کنید؛ باید اول سایت را بالا بیاورید، بعد در فرصت مناسب به قالب برگردید.

روش الف: تغییر قالب از پیشخوان

اگر پیشخوان باز می‌شود، مسیر ساده است: «نمایش ← پوسته‌ها» را باز کنید و یکی از قالب‌های پیش‌فرض وردپرس — مثلاً Twenty Twenty-Four یا نسخهٔ مشابه — را فعال کنید. این کار، سایت را بلافاصله به یک وضعیت پایدار برمی‌گرداند، حتی اگر ظاهرش با طرح دلخواه شما فرق داشته باشد.

روش ب: تغییر قالب از دیتابیس

اگر پیشخوان هم باز نمی‌شود (که در خرابی‌های شدید قالب رخ می‌دهد)، باید از دیتابیس قالب را تغییر دهید. این کار از طریق phpMyAdmin (ابزار تحت وب مدیریت دیتابیس) در پنل هاست انجام می‌شود. اگر با cPanel آشنایی کامل ندارید، ابتدا cPanel چیست و چه کاربردی دارد را بخوانید.

در phpMyAdmin، جدول wp_options را باز کنید. دو رکورد کلیدی وجود دارد:

template     →  قالب فعال فعلی
stylesheet   →  قالب یا چایلد‌تم فعال

مقدار این دو را به نام پوشهٔ یکی از قالب‌های پیش‌فرض وردپرس تغییر دهید — مثلاً twentytwentyfour. بعد از ذخیره، سایت باید بلافاصله بالا بیاید. نکتهٔ حیاتی: مقدار این دو فیلد باید نام پوشهٔ قالب باشد، نه نام نمایشی آن.

در حالت عادی، هر دو مقدار یکسان هستند. اما اگر روی قالب فعلی، یک چایلد تم نصب بود، مقدار stylesheet نام چایلد را دارد و template نام والد. این تفکیک را در قالب چایلد چیست و چه زمانی به آن نیاز داریم کامل باز کرده‌ام و توصیه می‌کنم قبل از هر تغییر دیتابیسی، آن را بخوانید.

در بحران، اولویت اول بازگرداندن سایت به وضعیت کارکننده است، نه عیب‌یابی قالب. عیب‌یابی، وقتی انجام می‌شود که سایت روی قالب پیش‌فرض، آرام و پایدار کار می‌کند.

محتوا کجا ذخیره می‌شود و چه چیزی از دست می‌رود؟

برای اینکه بدانید چه چیزی واقعاً در معرض خطر است، باید بدانید هر بخش سایت کجا ذخیره می‌شود. این تفکیک، هستهٔ فهم «چه چیزی از دست می‌رود و چه چیزی نه» است:

• نوشته‌ها، برگه‌ها و دیدگاه‌ها: در جدول‌های wp_posts و wp_comments. به‌طور کامل مستقل از قالب.
• کاربران و نقش‌ها: در جدول‌های wp_users و wp_usermeta. مستقل از قالب.
• تصاویر و رسانه: در پوشهٔ wp-content/uploads/. مستقل از قالب.
• تنظیمات وردپرس: در جدول wp_options. مستقل از قالب، اما بعضی از این تنظیمات می‌توانند اشاره به قالب داشته باشند.
• تنظیمات Customizer قالب: در جدول wp_options، تحت کلیدهایی با پیشوند theme_mods_. این‌ها وابسته به قالب هستند و با تغییر قالب، معنایشان تغییر می‌کند.
• ویجت‌ها: در جدول wp_options، تحت کلید sidebars_widgets. وابسته به موقعیت‌های قالب.
• منوها: در جدول wp_terms و wp_term_taxonomy، اما اتصالشان به موقعیت‌های قالب، در تنظیمات قالب است.

پس تصویر روشن می‌شود: محتوای اصلی، تصاویر، کاربران و دیدگاه‌ها — همه در جای خودشان می‌مانند. چیزی که با تغییر قالب گم یا منحرف می‌شود، «حافظهٔ ظاهری» سایت است: رنگ‌ها، فونت‌ها، چیدمان، جای ویجت‌ها و منوها. این تفکیک، همان چیزی است که در مقالهٔ تغییر قالب وردپرس بدون آسیب هم به‌صورت جدول کامل آورده‌ام.

نقشهٔ دقیق: کدام بخش‌ها آسیب می‌بینند و کدام‌ها نه

حالا با این تفکیک، یک نقشهٔ دقیق می‌سازیم:

کاملاً سالم می‌ماند

• نوشته‌ها، برگه‌ها و دیدگاه‌ها
• تصاویر و فایل‌های رسانه
• کاربران و نقش‌ها
• ساختار دسته‌بندی و برچسب
• افزونه‌ها و تنظیماتشان

احتمالاً جابه‌جا یا نیازمند بازچینی

• منوها (احتمالاً به موقعیت‌های قالب جدید وصل نیستند)
• ویجت‌ها (سیدبار و فوتر باید دوباره بازچینی شوند)
• تنظیمات Customizer (باید دوباره تنظیم شوند)
• تصویر شاخص پیش‌فرض قالب (احتمالاً از دست می‌رود)

در معرض خطر جدی

• شورت‌کدهای اختصاصی قالب قدیم: اگر در نوشته‌ها از شورت‌کدهایی مثل [button] یا [slider] استفاده کرده‌اید که به قالب وابسته بودند، بعد از تغییر قالب، به متن خام تبدیل می‌شوند. اینجا اولین باری است که «محتوای شما» واقعاً در معرض خطر است — چون بخشی از محتوا در قالبی ذخیره شده که دیگر معنایی برای سایت ندارد.
• محتوای ذخیره‌شده در صفحه‌ساز قالب: اگر قالب شما یک صفحه‌ساز اختصاصی داشت (مثل Divi Builder یا مشابه) و صفحات با آن ساخته شده‌اند، بعد از تغییر قالب، محتوای این صفحات به‌سختی قابل بازیابی است. این سناریو، دردناک‌ترین حالت قالب‌محور است.
• کدهای سفارشی داخل فایل functions.php قالب: اگر کد سفارشی مثل یک تابع تولیدکنندهٔ محتوا در فایل قالب داشته‌اید، با تغییر قالب، آن کد از کار می‌افتد. راه پیشگیری این حالت را در رفع خطای Parse error در functions.php و به‌طور کلی‌تر، در «انتقال کدهای سفارشی به چایلد‌تم» باز کرده‌ام.

این نقشه، به شما می‌گوید چرا قبل از هر تغییری در قالب، بازبینی شورت‌کدها و کدهای سفارشی ضروری است. اگر این بازبینی را انجام دهید، در بیشتر موارد خرابی قالب، صرفاً یک وقفهٔ کوتاه است، نه یک فاجعهٔ محتوایی.

بازگشت از بکاپ: وقتی راه دیگری نیست

در برخی موارد — وقتی خرابی قالب چنان عمیق است که حتی تغییر قالب از دیتابیس هم جواب نمی‌دهد، یا وقتی خودِ دیتابیس آسیب دیده — تنها راه، بازگشت از بکاپ است. این تصمیم، همیشه باید آخرین گزینه باشد، چون بکاپ شما را به یک نقطهٔ زمانی گذشته برمی‌گرداند و هر تغییری که بعد از آن بکاپ داده‌اید، از دست می‌رود.

بکاپ کامل یا جزئی؟

پیش از بازیابی، به این سؤال جواب دهید: آیا واقعاً به بکاپ کامل نیاز دارید، یا فقط بخشی از آن؟ در اکثر موارد، بازیابی بخشی کافی است:

• بازیابی فقط قالب: اگر فقط فایل‌های قالب خراب شده‌اند و دیتابیس سالم است، به‌جای بازیابی کل سایت، فقط پوشهٔ قالب را از بکاپ برگردانید. این کار، مزیت بزرگی دارد: هیچ تغییری در محتوای اخیر از دست نمی‌رود.
• بازیابی کل سایت: فقط در مواردی که خرابی، هم فایل‌ها و هم دیتابیس را تحت تأثیر قرار داده باشد.

مسیر بازیابی

روش‌های بازیابی، بسته به ابزار بکاپ شما فرق می‌کند. اگر با یکی از افزونه‌های معتبر بکاپ گرفته‌اید، مسیر بازیابی در پیشخوان افزونه است. اگر بکاپ دستی از فایل و دیتابیس دارید، مسیر بازیابی از طریق File Manager و phpMyAdmin است. راهنمای کامل در بازیابی سایت از بکاپ آمده است. اگر هم بکاپ ندارید، اول از همه به پشتیبانی هاست تیکت بزنید — برخی هاست‌ها بکاپ خودکار دارند و می‌توانند سایت شما را به یک نقطهٔ گذشته برگردانند.

یک تذکر عملی مهم: پیش از هر بازیابی، از وضعیت فعلی سایت — حتی اگر خراب است — یک بکاپ بگیرید. بکاپِ خرابی، در بیشتر موارد ارزشمندتر از بکاپِ سالم است، چون می‌توانید بعداً دربارهٔ اینکه «چه چیزی باعث خرابی شد» بررسی کنید و در آینده پیشگیری کنید.

هر تصمیمی برای بازیابی، باید با یک بکاپ از وضعیت فعلی شروع شود. حتی اگر آن وضعیت خراب است.

رفع دستی خرابی قالب

در برخی موارد، لازم نیست قالب را عوض کنید یا از بکاپ بازیابی کنید. اگر ریشهٔ مشکل مشخص است و از نوع کوچک (مثلاً یک خط خطای PHP در یک فایل)، می‌توانید به‌صورت دستی آن را رفع کنید. سه سناریوی رایج:

سناریو اول: خطای PHP در فایل functions.php

اگر پیشخوان باز نمی‌شود اما پیام خطای دقیقی داده (مثل «خطای Parse در خط ۴۵»)، می‌توانید از طریق FTP یا File Manager به فایل wp-content/themes/theme-name/functions.php دسترسی پیدا کنید. خطی که در پیام آمده، معمولاً محل خطا را نشان می‌دهد. اگر آخرین تغییر شما در این فایل بوده، همان را برگردانید. اگر مطمئن نیستید، از آخرین نسخهٔ سالم این فایل (از بکاپ) استفاده کنید.

سناریو دوم: خطای نبود فایل style.css

این خطا وقتی رخ می‌دهد که فایل style.css قالب به‌خاطر تغییر نام یا حذف نباشد. در آن حالت، وردپرس قالب را نمی‌شناسد. راه‌حل: فایل style.css را با هدر استاندارد بازسازی کنید. راهنمای کامل این سناریو در رفع خطای استایل شیت قالب و خطای Missing style.css در قالب وردپرس آمده است.

سناریو سوم: خطای ناسازگاری با نسخهٔ PHP

اگر بعد از ارتقای نسخهٔ PHP در هاست، سایت خراب شده، ممکن است قالب با نسخهٔ جدید PHP سازگار نباشد. راه‌حل موقت: نسخهٔ PHP را در پنل هاست به نسخهٔ قبلی برگردانید. راه‌حل بلندمدت: به‌روزرسانی قالب یا مهاجرت به یک قالب نگهداری‌شده. جزئیات بیشتر در رفع خطای ناسازگاری قالب با نسخه وردپرس.

در هر سه سناریو، یک اصل مشترک وجود دارد: پیش از هر تغییری در فایل‌های قالب، بکاپ بگیرید. اگر تغییر دستی شما باعث خرابی بزرگ‌تر شود، بکاپ، خط نجات شماست. راهنمای بکاپ را در چگونه از سایت وردپرسی بکاپ بگیریم آورده‌ام.

استجینگ: پیشگیری از بحران بعدی

پس از اینکه سایت را بازگرداندید، بهترین زمان برای ساخت استجینگ است. استجینگ، یک نسخهٔ آینه‌ای از سایت شماست که می‌توانید هر تغییری را روی آن آزمایش کنید، بدون آنکه سایت زنده آسیب ببیند. اگر این مفهوم برایتان تازه است، راهنمای کامل در توسعه وردپرس با محیط لوکال چگونه انجام می‌شود آمده است.

ساخت استجینگ، سه مزیت بزرگ دارد:

• آزمایش به‌روزرسانی‌ها پیش از اجرا: پیش از آنکه قالب را روی سایت زنده به‌روزرسانی کنید، روی استجینگ آزمایش کنید. اگر خراب شد، فقط استجینگ صدمه می‌بیند.
• آزمایش تغییرات بزرگ: اگر قصد تغییر ساختار سایت یا جایگزینی قالب دارید، استجینگ، محیط امن تست است.
• بازگشت آسان: در استجینگ، می‌توانید آزادانه بکاپ بگیرید و بازیابی کنید، چون در دسترس کاربران واقعی نیست.

روش منظم تست قالب پیش از انتشار را در بهترین روش تست قالب وردپرس پیش از انتشار آورده‌ام. اگر روی هر پروژه‌ای این روش را اجرا کنید، تعداد بحران‌های ناشی از قالب به‌شدت کاهش می‌یابد.

چایلد تم: بیمه‌ای برای آینده

پس از بازگرداندن سایت و ساخت استجینگ، قدم سوم و مهم‌ترین قدم پیشگیرانه این است: تمام تغییرات دلخواهتان را در چایلد تم بگذارید. چایلد تم، یک قالب کوچک است که روی قالب والد سوار می‌شود و فقط چیزهایی را که می‌خواهید، بازنویسی می‌کند. مزیت اصلی: وقتی قالب والد به‌روزرسانی می‌شود، تمام تغییرات شما در چایلد دست‌نخورده باقی می‌ماند.

ساختار ساده‌ای که در چایلد تم استفاده می‌کنم:

wp-content/themes/my-child/
├── style.css      ← هویت چایلد (هدر الزامی)
├── functions.php  ← کد و enqueue
└── screenshot.png ← اختیاری، نمایش در پیشخوان

در فایل style.css، هدر چایلد با دو کلید مهم مشخص می‌شود:

/*
Theme Name: My Site Child
Template: astra
Text Domain: my-site-child
Version: 1.0
*/

کلید Template باید نام پوشهٔ قالب والد باشد، نه نام نمایشی آن. راهنمای کامل ساخت چایلد تم را در قالب چایلد چیست و چه زمانی به آن نیاز داریم آورده‌ام. به‌طور خلاصه: اگر روی قالب فعلی تان، تغییرات قابل‌توجهی اعمال کرده‌اید — از تنظیمات سفارشی گرفته تا کدهای کوچک — بدون چایلد تم، هر به‌روزرسانی، همه‌چیز را از بین می‌برد. و همین «تغییراتِ پاک‌شده»، یکی از دلایلی است که گاهی اوقات کاربران گزارش می‌دهند «محتوا از دست رفت» — در حالی که در واقع، تنظیمات قالب بوده که پاک شده.

چایلد تم، هزینه‌اش صفر است، ولی بیمه‌اش صد درصد. اگر امروز روی قالب اصلی سایتتان کد سفارشی دارید، امروز وقت ساخت چایلد تم است.

انتقال محتوا به قالب جدید

اگر تصمیم گرفته‌اید قالب را به‌کلی تغییر دهید (به‌خاطر یک خرابی حل‌نشدنی یا به‌خاطر نیاز جدیدی)، باید محتوای وابسته به قالب قدیم را به قالب جدید منتقل کنید. سه سناریوی اصلی انتقال محتوا:

سناریو اول: انتقال شورت‌کدها

شورت‌کدهای قالب قدیم به متن خام تبدیل می‌شوند. دو راه پیش روی شماست: یکی، جایگزینی دستی آن‌ها با بلوک‌های بومی گوتنبرگ (Gutenberg — ویرایشگر بلوک وردپرس)، و دیگری، ساخت شورت‌کدهای جایگزین در چایلد تم یا افزونهٔ سفارشی. روش دوم، در سایت‌های با محتوای زیاد، زمان‌بر است اما نتیجهٔ تمیزتری می‌دهد. راهنمای ساخت شورت‌کد در ساخت شورت‌کد با کدنویسی وردپرس آمده است.

سناریو دوم: انتقال تنظیمات Customizer

تنظیمات قالب قدیم (رنگ‌ها، فونت‌ها، چیدمان) باید در قالب جدید دوباره تنظیم شوند. اگر قالب قدیم امکان Export/Import داشت، خروجی بگیرید. اگر نه، می‌توانید مقادیر کلیدهای theme_mods را از دیتابیس (از طریق phpMyAdmin) استخراج کنید و به‌عنوان مرجع استفاده کنید.

سناریو سوم: بازچینی منوها و ویجت‌ها

منوها و ویجت‌ها به موقعیت‌های قالب وصل هستند. قالب جدید، موقعیت‌های متفاوتی دارد؛ پس باید بازچینی دستی انجام دهید. روش استاندارد در پیکربندی منو و ویجت‌های وردپرس آمده است. این بخش، در تجربهٔ من، بیشترین وقت را در انتقال قالب می‌گیرد، ولی آن هم در نهایت به یک ساعت کار دستی می‌رسد.

اگر بعد از انتقال متوجه شدید که یکی از افزونه‌ها با قالب جدید سازگار نیست، راهنمای رفع تعارض در رفع خطای تضاد افزونه‌ها در وردپرس را ببینید.

پیشگیری: پروتکل قالب‌محور

یک پروتکل پنج‌مرحله‌ای که در پروژه‌های خودم، تعداد بحران‌های قالب را به‌شدت کاهش داده:

1. بکاپ قبل از هر تغییر: به‌روزرسانی قالب، فعال‌سازی یک افزونه، یا هر تغییر ساختاری، بدون بکاپ انجام نمی‌شود.
2. استجینگ برای تست: همهٔ تغییرات قالب‌محور، ابتدا روی استجینگ آزمایش می‌شوند.
3. چایلد تم برای تغییرات سفارشی: تمام سفارشی‌سازی‌های قالب، در چایلد انجام می‌شوند.
4. تست سازگاری پیش از انتشار: پیش از آپدیت قالب روی سایت زنده، سازگاری‌اش با افزونه‌ها و نسخهٔ فعلی وردپرس بررسی می‌شود.
5. پایش بعد از انتشار: پس از هر آپدیت، در ۲۴ ساعت اول، سایت را با دقت پایش می‌کنم — چون بعضی از خرابی‌ها، فوری خودشان را نشان نمی‌دهند.

اجرای این پنج مرحله، در هر پروژه، حداکثر دو تا سه ساعت وقت می‌گیرد؛ در مقابل، حل یک بحران قالب، در تجربهٔ من، همیشه بیش از این مقدار بوده. با اختلاف. برای آشنایی با معیارهای انتخاب قالبی که این پروتکل را از ابتدا ساده‌تر می‌کند، چگونه یک قالب وردپرس استاندارد را تشخیص دهیم و مهم‌ترین امکانات یک قالب وردپرس حرفه‌ای را ببینید.

اشتباهاتی که خرابی را به فاجعه تبدیل می‌کنند

پنج اشتباه که در بازبینی پروژه‌ها زیاد دیده‌ام:

• ویرایش مستقیم فایل‌های قالب والد: رایج‌ترین و پرهزینه‌ترین. هر تغییر سفارشی، باید در چایلد تم انجام شود؛ هر تغییری در قالب والد، در آپدیت بعدی از بین می‌رود.
• به‌روزرسانی قالب روی سایت زنده و بدون بکاپ: این کار، در اکثر موارد قابل پیشگیری است. حتی اگر مطمئن باشید، بکاپ هزینه‌ای ندارد.
• حذف قالب قدیم بی‌درنگ بعد از تغییر: اگر بعد از تغییر، چیزی از قالب قدیم لازم شود (مثلاً یک فایل اسکچ یا تصویر)، دسترسی به آن ندارید. قالب قدیم را چند هفته نگه دارید و بعد تصمیم بگیرید.
• نصب قالب جدید به‌جای تست روی استجینگ: در بیشتر موارد، به‌جای راه‌اندازی استجینگ، کاربران قالب جدید را مستقیم روی سایت زنده نصب می‌کنند و سپس با بحران مواجه می‌شوند. هزینهٔ ساخت استجینگ بسیار کمتر از هزینهٔ بحران است.
• نادیده گرفتن هشدارهای قبل از تغییر: وردپرس قبل از برخی به‌روزرسانی‌ها هشدار می‌دهد که «سازگاری این قالب با نسخهٔ فعلی وردپرس تأیید نشده است». این هشدارها را جدی بگیرید. اگر هشدار است، منتظر بمانید تا سازنده تأیید کند.

یک قاعدهٔ سرانگشتی که در پروژه‌هایم جواب داده: هر تغییری که زمان پیاده‌سازی‌اش کمتر از پنج دقیقه است، باید پیش از انجام، بکاپ داشته باشد. چون همین تغییرات کوچک، در برخی موارد، بزرگ‌ترین خرابی‌ها را می‌سازند.

سخن آخر: تفاوت بحران و وقفه

خرابی قالب، در نگاه اول ترسناک است؛ اما تجربه نشان می‌دهد در بیش از نود درصد موارد، فقط یک وقفهٔ کوتاه در دسترسی است، نه یک بحران محتوایی. کلید کار، در سه اقدام مشخص نهفته: بازگرداندن سریع سایت به وضعیت پایدار (تغییر قالب پیش‌فرض)، فهم دقیق اینکه چه چیزی گم شده و چه چیزی نه، و بازسازی لایه‌های ازدست‌رفته (تنظیمات قالب، منوها، ویجت‌ها). اگر پیش از بحران، بکاپ داشته باشید و پس از بحران، چایلد تم و استجینگ بسازید، دفعهٔ بعد که قالب به‌روزرسانی می‌شود، خرابی دیگر «وقفۀ اضطراری» نخواهد بود؛ فقط یک قدم عادی در نگهداری سایت است.

اگر تجربه‌ای از یک خرابی قالب دارید — به‌خصوص موردی که در نهایت معلوم شد ریشه در شورت‌کد یا صفحه‌ساز قالب بوده — خوشحال می‌شوم در دیدگاه‌ها بخوانم. چه چیزی باعث آن شد و در نهایت چطور بازگشتید؟ همان تجربه، برای خواننده‌ای که همین حالا با یک قالب خراب دست‌وپنجه نرم می‌کند، از هر مقالهٔ مرجع مفیدتر است. 🛠️