ابزار سلامت سایت؛ کلینیک تخصصی سرور
قبل از اینکه برای هر مشکل سراغ نصب افزونه برویم، بهتر است اول وضعیت فنی سایت و سرور را بررسی کنیم. وردپرس ابزاری به نام Site Health یا سلامت سایت دارد که اطلاعات مهمی درباره سرور، PHP، حافظه، ماژولها و وضعیت کلی سایت نمایش میدهد.
مسیر بررسی سلامت سایت:
ابزارها > سلامت سایت > اطلاعات > سرور
در این بخش میتوانید مواردی مثل نسخه PHP، محدودیت حافظه، وضعیت سرور، ماژولهای فعال و تنظیمات مهم هاست را بررسی کنید. برای مثال اگر قبلاً در فایل wp-config.php مقدار حافظه وردپرس را افزایش داده باشید، از این مسیر میتوانید مطمئن شوید که مقدار جدید واقعاً روی سایت اعمال شده است.
ماژولهای مهم سرور برای وردپرس
وردپرس برای عملکرد درست به بعضی PHP Extensions یا ماژولهای سمت سرور وابسته است. این ماژولها روی ارتباط سایت با سرویسهای بیرونی، پردازش تصاویر و پشتیبانی از فرمتهای مدرن اثر مستقیم دارند.
- cURL: ماژول ارتباطی سرور است و برای اتصال سایت به درگاه پرداخت، APIها، لایسنس افزونهها و دریافت آپدیتها استفاده میشود. اگر cURL مشکل داشته باشد، ارتباط سایت با سرویسهای بیرونی مختل میشود.
- GD: یک ماژول پایه و سبک برای پردازش تصویر است. وردپرس با کمک آن میتواند تصاویر بندانگشتی، کراپها و سایزهای مختلف تصویر را بسازد.
- Imagick: نسخه حرفهایتر پردازش تصویر است و معمولاً کیفیت بهتری در تغییر سایز، رندر رنگها و مدیریت تصاویر ارائه میدهد. اگر روی هاست فعال باشد، گزینه بهتری نسبت به GD محسوب میشود.
- پشتیبانی WebP و AVIF: اگر هاست از تصاویر WebP یا AVIF پشتیبانی نکند، مشکل معمولاً از نبود کتابخانههای لازم روی سرور است. در این حالت باید از هاستینگ بخواهید پشتیبانی این فرمتها را فعال کند.
رفع خطای SSL و محتوای ناامن
گاهی SSL روی هاست فعال است و سایت با آدرس HTTPS باز میشود، اما قفل کنار آدرس مرورگر کامل و امن نمایش داده نمیشود یا مرورگر هشدار امنیتی میدهد. دلیل رایج این مشکل، Mixed Content یا محتوای ناامن است.
Mixed Content یعنی صفحه سایت با HTTPS لود شده، اما بعضی فایلها مثل تصویر، CSS یا JavaScript هنوز با آدرس HTTP بارگذاری میشوند. مرورگرها اجازه نمیدهند داخل یک صفحه امن، فایل ناامن لود شود؛ به همین دلیل قفل SSL شکسته یا ناقص نمایش داده میشود.
مثال ساده از محتوای ناامن:
<img src="http://yourdomain.ir/test.jpg">
در این مثال، تصویر هنوز با http لود میشود، در حالی که خود سایت باید با https باز شود.
روش اصولی رفع Mixed Content
برای رفع Mixed Content، بهتر است مشکل را از ریشه در دیتابیس اصلاح کنیم. نصب دائمی افزونههایی مثل Really Simple SSL ممکن است برای بعضی کاربران ساده باشد، اما برای سایت حرفهای بهتر است افزونه اضافه را برای همیشه روی سایت نگه نداریم.
روش تمیزتر این است که از افزونه Better Search Replace بهصورت موقت استفاده کنیم.
مراحل کلی:
- اول از سایت و دیتابیس بکآپ بگیرید.
- افزونه Better Search Replace را نصب کنید.
- آدرس قدیمی را جستجو کنید:
http://site.irو با نسخه امن جایگزین کنید:https://site.ir - بعد از تست سایت و اطمینان از درست شدن قفل SSL، افزونه را حذف کنید.
🟠 نکته مهم: عملیات Search & Replace مستقیم روی دیتابیس انجام میشود. قبل از اجرای نهایی، حتماً بکآپ داشته باشید و اگر افزونه گزینه Dry Run دارد، ابتدا حالت تست را اجرا کنید.
خطای ۴۰۴ صفحات داخلی و پیوندهای یکتا
یکی از خطاهای رایج وردپرس این است که صفحه اصلی سایت باز میشود، اما نوشتهها، محصولات یا صفحات داخلی خطای ۴۰۴ میدهند. در این حالت معمولاً سایت پاک نشده و دیتابیس هم از بین نرفته است.
دلیل رایج این مشکل، خراب شدن یا حذف شدن فایل .htaccess است. این فایل مثل نقشهخوان و راهیاب سرور عمل میکند. وقتی فایل .htaccess آسیب ببیند، سرور میتواند صفحه اصلی را پیدا کند، اما نمیداند آدرس صفحات داخلی را چطور باید به وردپرس وصل کند.
راهحل سریع:
تنظیمات > پیوندهای یکتا
بدون اینکه چیزی را تغییر دهید، فقط روی دکمه ذخیره تغییرات کلیک کنید. با این کار وردپرس معمولاً قوانین پیوندهای یکتا را دوباره مینویسد و فایل .htaccess بازسازی میشود.
🟠 نشانه مهم: اگر صفحه اصلی باز میشود اما مقالات یا صفحات داخلی خطای ۴۰۴ میدهند، یکی از اولین جاهایی که باید بررسی کنید، پیوندهای یکتا و فایل .htaccess است.
غیرفعال کردن افزونه معیوب از هاست
گاهی بعد از نصب یا آپدیت یک افزونه، سایت سفید میشود یا پیشخوان دیگر باز نمیشود. در این وضعیت ممکن است دسترسی به پیشخوان وردپرس نداشته باشید تا افزونه را از داخل مدیریت غیرفعال کنید.
در این حالت میتوانید از طریق فایلمنیجر هاست یا FTP وارد مسیر افزونهها شوید:
wp-content/plugins
بعد پوشه افزونه مشکوک مثلا plugin-name را به plugin-name-disabled تغییر نام دهید. با این کار وردپرس دیگر آن افزونه را پیدا نمیکند و آن را غیرفعال در نظر میگیرد. اگر مشکل از همان افزونه باشد، سایت دوباره بالا میآید.
این روش یکی از سریعترین راهها برای نجات سایت در زمان خطاهای افزونهای است، مخصوصاً وقتی پیشخوان وردپرس در دسترس نیست.
عیبیابی با WP_DEBUG
وقتی سایت سفید میشود یا خطای ۵۰۰ میدهد، وردپرس معمولاً برای حفظ امنیت، جزئیات خطا را به کاربر نمایش نمیدهد. این رفتار از نظر امنیتی درست است، اما برای عیبیابی باید بتوانیم بفهمیم مشکل دقیقاً از کدام فایل، افزونه یا خط کد آمده است.
اینجا WP_DEBUG وارد عمل میشود. این قابلیت کمک میکند خطاهای پنهان وردپرس را ببینیم یا در فایل لاگ ذخیره کنیم.
روشن کردن سیستم عیبیابی
این کد داخل فایل wp-config.php قرار میگیرد:
define( 'WP_DEBUG', true );
این خط، سیستم عیبیابی وردپرس را فعال میکند. البته فقط روشن کردن WP_DEBUG کافی نیست؛ باید مشخص کنیم خطاها کجا نمایش داده یا ذخیره شوند.
نمایش خطا روی ظاهر سایت
برای محیط طراحی یا تست، میتوان خطاها را مستقیم روی صفحه نمایش داد:
define( 'WP_DEBUG_DISPLAY', true );
این روش برای زمان طراحی مفید است، چون سریعاً نشان میدهد مشکل از کدام فایل، افزونه یا خط کد است. اما برای سایت زنده و پربازدید مناسب نیست، چون ممکن است مسیر فایلها و اطلاعات فنی سایت را به کاربران نشان دهد.
ذخیره خطا در فایل debug.log
برای سایتهای زنده، روش حرفهایتر این است که خطاها به کاربر نمایش داده نشوند و بهجای آن، در یک فایل متنی ذخیره شوند:
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
با این تنظیم، خطاها در فایل زیر ذخیره میشوند:
wp-content/debug.log
این روش کمک میکند ظاهر سایت برای کاربران خراب نشود، اما شما همچنان بتوانید خطاها را بررسی کنید.
تنظیم پیشنهادی WP_DEBUG برای سایت زنده
برای سایت زنده، هنگام عیبیابی میتوانید از این ترکیب استفاده کنید:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
بعد از پایان عیبیابی، بهتر است دیباگ را خاموش کنید:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );
🟠 نکته مهم: روشن ماندن دیباگ روی سایت زنده میتواند باعث تولید فایلهای لاگ حجیم شود و در بعضی شرایط اطلاعات فنی سایت را لو بدهد. دیباگ باید فقط هنگام بررسی مشکل فعال باشد.
بهینهسازی WP-Cron
WP-Cron سیستم زمانبندی داخلی وردپرس است. کارهایی مثل انتشار مقالات زمانبندیشده، اجرای برخی بکآپهای دورهای، ارسال ایمیلها، بررسی آپدیتها و بعضی وظایف افزونهها از طریق این سیستم مدیریت میشوند.
در روت سایت وردپرسی، فایلی به نام wp-cron.php وجود دارد. این فایل مدیر وظایف زمانبندیشده وردپرس است، اما یک نکته مهم دارد: این فایل بهخودیخود فعال و زنده نیست. برای اجرا شدن، به یک محرک نیاز دارد.
WP-Cron پیشفرض؛ کارگر تنبل
در حالت پیشفرض، WP-Cron با ورود کاربران فعال میشود. یعنی هر وقت یک بازدیدکننده صفحهای از سایت را باز کند، وردپرس بررسی میکند که آیا وظیفه زمانبندیشدهای عقب افتاده یا نه.
این روش را میتوان شبهکرون یا Pseudo-Cron دانست.
تشبیه ساده:
- WP-Cron پیشفرض مثل کارگری است که لیست وظایف دارد، اما خودش به ساعت نگاه نمیکند.
- فقط وقتی زنگ در به صدا دربیاید، یعنی کاربری وارد سایت شود، بیدار میشود و لیست کارهایش را بررسی میکند.
این روش در سایتهای ساده ممکن است قابل قبول باشد، اما برای سایتهای خلوت یا خیلی شلوغ مشکل ایجاد میکند.
مشکل WP-Cron در سایتهای خلوت و شلوغ
در سایتهای خلوت، اگر بازدیدی انجام نشود، WP-Cron هم اجرا نمیشود. مثلاً اگر نوشتهای را برای ساعت ۶ عصر زمانبندی کرده باشید، اما اولین بازدیدکننده ساعت ۸ شب وارد سایت شود، ممکن است نوشته همان زمان منتشر شود. این همان مشکل Missed Schedule یا اجرای عقبافتاده وظایف است.
در سایتهای پربازدید هم مشکل برعکس است. چون با هر بازدید، وردپرس ممکن است WP-Cron را بررسی کند، درخواستهای زیاد میتوانند باعث فشار اضافی روی CPU و منابع سرور شوند.
پس مشکل اصلی WP-Cron پیشفرض این است:
- در سایت خلوت ممکن است وظایف دیر اجرا شوند.
- در سایت شلوغ ممکن است سرور بیدلیل درگیر بررسیهای زیاد شود.
قفل زمانی برای WP-Cron
یک روش ساده برای کاهش فشار WP-Cron، تعیین قفل زمانی است. با این کار، وردپرس مجبور میشود بین هر بار بررسی کرون، حداقل یک فاصله زمانی مشخص را رعایت کند.
کد زیر باید داخل فایل wp-config.php قرار بگیرد:
// تعیین حداقل فاصله زمانی بین هر بار بررسی کرون، به ثانیه
define( 'WP_CRON_LOCK_TIMEOUT', 300 );
عدد 300 یعنی ۳۰۰ ثانیه یا ۵ دقیقه. با این تنظیم، اگر یک کاربر وارد سایت شود و WP-Cron اجرا شود، تا ۵ دقیقه بعد حتی اگر کاربران زیادی وارد سایت شوند، وردپرس دوباره کرون را پشت سر هم اجرا نمیکند.
این روش برای کاهش فشار در سایتهای پربازدید مفید است، اما هنوز وابستگی WP-Cron به بازدید کاربران را بهطور کامل قطع نمیکند.
انتقال WP-Cron به Cron Job واقعی سرور
روش حرفهایتر این است که اجرای WP-Cron را از بازدید کاربران جدا کنیم و آن را به Cron Job واقعی سرور بسپاریم. در این حالت، سیستمعامل سرور مثلاً هر ۵ یا ۱۰ دقیقه یکبار فایل wp-cron.php را اجرا میکند، بدون اینکه منتظر ورود کاربر بماند.
مرحله اول، غیرفعال کردن محرک پیشفرض وردپرس است. این کد داخل wp-config.php قرار میگیرد:
define( 'DISABLE_WP_CRON', true );
با این کد، وردپرس دیگر با هر بازدید کاربر WP-Cron را اجرا نمیکند.
مرحله دوم، ساخت Cron Job در هاست است. در کنترل پنلهایی مثل cPanel یا DirectAdmin وارد بخش Cron Jobs شوید و یک کرونجاب مثلاً هر ۵ یا ۱۰ دقیقه تنظیم کنید.
نمونه دستور:
php /home/username/public_html/wp-cron.php >/dev/null 2>&1
در این دستور، مسیر زیر باید با مسیر واقعی هاست شما جایگزین شود:
/home/username/public_html/
عبارت زیر هم باعث میشود خروجیهای اجرای کرون به ایمیل یا فایلهای اضافی تبدیل نشوند و فضای هاست را پر نکنند:
>/dev/null 2>&1
🟠 نکته مهم: اگر مسیر PHP یا مسیر سایت در هاست متفاوت باشد، باید آن را از پنل هاست یا پشتیبانی هاست بگیرید.
قانون طلایی مهاجرت سایت و Cron Job
تنظیمات Cron Job مربوط به سطح سرور است، نه خود وردپرس. یعنی اگر سایت را با افزونههایی مثل Duplicator، All-in-One WP Migration یا ابزارهای مشابه به هاست جدید منتقل کنید، Cron Jobهای سرور معمولاً همراه سایت منتقل نمیشوند.
بعد از انتقال سایت به هاست جدید، باید حتماً Cron Job را دوباره در پنل هاست جدید بسازید. اگر این کار انجام نشود، ممکن است موارد زیر دچار مشکل شوند:
- مقالات زمانبندیشده منتشر نشوند.
- بکآپهای اتوماتیک اجرا نشوند.
- ایمیلهای زمانبندیشده ارسال نشوند.
- بعضی وظایف افزونهها عقب بیفتند.
- کارهای زمانبندیشده ووکامرس یا سایت آموزشی درست اجرا نشوند.
جمعبندی ساده WP-Cron این است:
WP-Cron یک سیستم پسیو است؛ یعنی خودش بهتنهایی کاری نمیکند و فقط وقتی یک محرک از بیرون، چه کاربر و چه سرور، آن را صدا بزند، بیدار میشود و وظایف عقبافتاده را بررسی میکند.
جمعبندی
نگهداری وردپرس فقط نصب افزونه امنیتی یا گرفتن بکآپ نیست. یک وبمستر حرفهای باید بتواند خطاهای رایج را تشخیص دهد، مسیرهای اصلی عیبیابی را بشناسد و بداند هر مشکل از کدام بخش شروع میشود.
در این درس یاد گرفتید که:
- با Site Health وضعیت فنی سرور و ماژولها را بررسی کنید.
- نقش cURL، GD و Imagick را در عملکرد وردپرس بشناسید.
- خطای Mixed Content را تشخیص دهید و با اصلاح آدرسهای دیتابیس، SSL را کامل کنید.
- مشکل ۴۰۴ صفحات داخلی را از طریق پیوندهای یکتا و
.htaccessبرطرف کنید. - افزونه معیوب را حتی بدون دسترسی به پیشخوان، از طریق هاست غیرفعال کنید.
- با WP_DEBUG خطاهای پنهان وردپرس را پیدا کنید.
- اجرای WP-Cron را از حالت پیشفرض به حالت حرفهایتر و قابل کنترلتر منتقل کنید.
هدف نهایی این است که هنگام خطاهای وردپرس، بهجای ترس و آزمونوخطای بیهدف، بتوانید مثل یک متخصص مشکل را مرحلهبهمرحله بررسی کنید و سایت را با کمترین وابستگی به پشتیبانی هاست به حالت سالم برگردانید.