learn

رفع صفحه سفید وردپرس؛ تشخیص خطای PHP، قالب و حافظه

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

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

گسترهٔ صفحه سفید وردپرس را مشخص کنید

صفحهٔ اصلی، یک نوشته، پیشخوان و همان URL در مرورگر دیگر را مقایسه کنید. اگر فقط یک صفحه سفید است، قالب یا محتوای اختصاصی آن را بررسی کنید. اگر HTML در پاسخ وجود دارد اما دیده نمی‌شود، CSS یا JavaScript هم می‌تواند دخیل باشد.

پاسخ ۵۰۰ با پاسخ ۲۰۰ خالی یکسان نیست؛ کد وضعیت را در Network مرورگر ببینید. راهنمای خطاهای رایج وردپرس چند علت شناخته‌شده را معرفی می‌کند، اما انتخاب راه‌حل به پیام واقعی خطا نیاز دارد.

لاگ خطا را بخوانید، خطا را عمومی نکنید

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

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

از بازیابی و تغییر هدفمند استفاده کنید

در برخی خطاهای بحرانی، وردپرس ایمیل Recovery Mode برای مدیر می‌فرستد. از مسیر معتبر وارد شوید و مؤلفهٔ مرتبط را بررسی کنید. اگر افزونه‌ای تازه تغییر کرده، غیرفعال‌سازی موقت همان افزونه از پیشخوان معمولاً از خاموش‌کردن همهٔ ابزارها دقیق‌تر است.

اگر پیشخوان در دسترس نیست، مدیر مجاز می‌تواند از فایل‌منیجر یا اتصال امن، پوشهٔ همان افزونه را در مسیر wp-content/plugins موقتاً تغییر نام دهد. مسیر معمول wp-content با خط تیره است، نه wp_content. نام اصلی را ثبت کنید و فایل‌ها را حذف نکنید.

برگرداندن پوشه الزاماً به معنی فعال‌شدن دوبارهٔ افزونه نیست؛ وضعیت آن را در پیشخوان بررسی کنید. همچنین افزونه‌های اجباری در mu-plugins و فایل‌های drop-in با این روش معمول کنار گذاشته نمی‌شوند.

قالب را با جایگزین سالم آزمایش کنید

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

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

کمبود حافظه با کمبود دیسک فرق دارد

پیام Allowed memory size exhausted به سقف حافظهٔ پردازش PHP اشاره می‌کند. این محدودیت با فضای ذخیره‌سازی فایل‌ها یکسان نیست. تنظیم memory_limit در PHP سقف مصرف حافظهٔ اسکریپت را مشخص می‌کند؛ خرید فضای دیسک بیشتر الزاماً آن را رفع نمی‌کند.

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

به‌روزرسانی ناقص و حالت تعمیرات

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

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

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب