آموزش گام‌به‌گام صفحهٔ سفید وردپرس

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

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

صفحه سفید وردپرس؛ قبل از هر تغییر، سه سؤال

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

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

قدم اول؛ روشن‌کردن گزارش خطا

اولین کار فنی، برداشتن استتار است: گزارش خطا را روشن کنید تا PHP بگوید دقیقاً کجا گریه می‌کند. در فایل wp-config.php، پیش از خط درخواست نصب، دو تعریف را اضافه یا اصلاح کنید: حالت دیباگ را روشن و نمایش خطا را روی صفحه خاموش نگه دارید و ثبت در فایل لاگ را فعال کنید. به این ترتیب بازدیدکننده سایت سفیدِ خالی می‌بیند ولی شما خطا را در فایل debug.log داخل پوشهٔ محتوا می‌خوانید؛ اگر به فایل‌ها دسترسی راحت ندارید، لاگ خطای سمت هاست هم معمولاً همان ردیف‌ها را دارد.

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

قدم دوم؛ ایزوله‌کردن افزونه‌ها

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

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

قدم سوم؛ آزمون قالب

اگر ایزوله‌سازی افزونه‌ها جواب نداد، نوبت قالب است. همان ترفند را تکرار کنید: پوشهٔ قالب فعال را تغییر نام دهید؛ وردپرس می‌کوشد به قالب پیش‌فرض موجود برگردد و اگر سایت دوباره دیده شد، علت در قالب است — بیشتر از همه در فایل functions.php که هر دست‌کاری کوچکی در آن می‌تواند کل سایت را سفید کند. قاعدهٔ خطای رایج را بدانید: یک نویسهٔ اضافه بعد از بستن برچسب PHP در آن فایل، کافی است تا خروجی کل سایت خراب شود.

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

قدم چهارم؛ سقف حافظه و منابع سرور

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

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

مسیر بازگشت؛ بازیابی از بکاپ

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

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

جمع‌بندی؛ سه‌گانهٔ پیشگیری که صفحهٔ سفید را نادر می‌کند

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

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

رصد ما، رشد شما.