DISABLE_WP_CRON = true به معنای بستن نقطه انتهایی (endpoint) فایل wp-cron.php نیست؛ این تنظیم فقط مانع از این می‌شود که WordPress درخواست loopback خودش را اجرا کند. این فایل همچنان از طریق وب قابل دسترسی است، بنابراین هر کسی می‌تواند با فراخوانی آن، فرآیند کامل بوت‌استرپ (bootstrap) WordPress را اجبار کند.

آن نقطه ورود پنهان می‌تواند باعث هدر رفتن CPU، حافظه و PHP workers شود، به‌ویژه در سایت‌های شلوغ. اگر فکر می‌کردید در را بسته‌اید، هنوز این کار را نکرده‌اید.

چرا این تنظیم اغلب اشتباه درک می‌شود

وقتی WordPress یک وظیفه زمان‌بندی شده (scheduled task) را اجرا می‌کند، ابتدا سعی می‌کند یک درخواست HTTP سریع به فایل wp-cron.php خودش ارسال کند. قرار دادن DISABLE_WP_CRON روی true به هسته (core) دستور می‌دهد که از آن درخواست داخلی صرف‌نظر کند. هسته تنظیمات وب‌سرور را تغییر نمی‌دهد و هیچ لایه احراز هویتی به wp-cron.php اضافه نمی‌کند. این اسکریپت همچنان یک URL عمومی باقی می‌ماند که حتی اگر فرآیند PHP زودتر از موعد متوقف شود، وضعیت 200 را برمی‌گرداند.

مهاجمی که این URL را پیدا کند، می‌تواند مکرراً به آن پینگ بدهد و باعث شود WordPress هر بار تمام افزونه‌ها، قالب‌ها و پایگاه داده را بارگذاری کند. در یک هاست اشتراکی یا سایتی با PHP workers محدود، این نقطه انتهایی واحد می‌تواند به یک بردار حمله منع سرویس (denial-of-service) تبدیل شود.

واقعاً چه کاری باید انجام داد

برای انتقال کارهای زمان‌بندی شده به یک زمان‌بند در سطح سیستم (مانند cron، systemd-timer و غیره) و بستن درِ عمومی، این پنج مرحله را دنبال کنید.

۱. غیرفعال کردن loopback داخلی

این خط را به wp-config.php اضافه کنید:

define( 'DISABLE_WP_CRON', true );

این کار مانع از تلاش WordPress برای ارسال درخواست HTTP خودش می‌شود، اما درخواست‌های خارجی را متوقف نمی‌کند.

۲. مسدود کردن wp-cron.php در وب‌سرور

برای مثال در Nginx، یک بلوک location اضافه کنید که وضعیت 403 Forbidden را برگرداند:

location = /wp-cron.php {
    return 403;
}

حالا سرور قبل از اینکه حتی PHP شروع به کار کند، درخواست را رد می‌کند و هزینه بوت‌استرپ را از بین می‌برد.

۳. افزودن یک mu-plugin به عنوان شبکه ایمنی

یک افزونه must-use (قرار داده شده در wp-content/mu-plugins) بسازید که هر درخواستی که به wp-cron.php می‌رسد را ثبت (log) کرده و با کد 403 خارج شود. این کار درخواست‌هایی را که به نحوی قوانین سرور را دور می‌زنند (مثلاً از طریق یک hostname متفاوت یا قوانین CDN edge) شناسایی می‌کند.

۴. سرکوب فراخوانی‌های async در Action Scheduler

بسیاری از افزونه‌ها از کتابخانه Action Scheduler استفاده می‌کنند که می‌تواند درخواست‌های loopback خودش را ایجاد کند. به action_scheduler_queue_runner متصل شوید (hook) و برای درخواست‌های غیر CLI خروجی زودهنگام داشته باشید تا از تلاش این کتابخانه برای باز کردن درهای خودش جلوگیری کنید.

۵. جدا کردن queue runner از هوک WP-Cron

queue runner پیش‌فرض Action Scheduler را که به هوک wp در cron متصل است، حذف کنید. این کار تضمین می‌کند که صف فقط زمانی اجرا شود که شما صراحتاً آن را از طریق خط فرمان (command line) اجرا کنید.

اجرای صحیح وظایف (jobs)

با بسته شدن نقطه انتهایی عمومی، از زمان‌بند سیستم استفاده کنید تا WordPress را یک بار در دقیقه (یا هر بازه‌ای که نیاز دارید) از طریق WP-CLI فراخوانی کنید:

wp cron event run --due-now

آن دستور واحد، رویدادهای اصلی cron و صف Action Scheduler را در یک محیط کنترل‌شده، با استفاده از همان فرآیند PHP که برای هر کار CLI دیگری استفاده می‌کنید، پردازش می‌کند.

مزایایی که می‌توانید اندازه‌گیری کنید

  • امنیت – هیچ کاربر احراز هویت نشده‌ای نمی‌تواند کارهای سنگین پس‌زمینه را شروع کند.
  • عملکرد – PHP workers برای بازدیدکنندگان واقعی در دسترس می‌مانند؛ جهش‌های حافظه ناشی از ضربه‌های تصادفی cron از بین می‌روند.
  • قابلیت اطمینان – زمان‌بندی به حالت پیش‌دستانه (proactive) در می‌آید؛ شما دقیقاً می‌دانید چه زمانی یک وظیفه اجرا می‌شود، زیرا توسط cron سیستم هدایت می‌شود، نه توسط بارگذاری صفحه توسط یک بازدیدکننده.

مواردی که پس از تغییر باید مراقب آن‌ها باشید

به کد وضعیت HTTP در wp-cron.php تکیه نکنید؛ ممکن است حتی زمانی که توسط PHP مسدود شده است، همچنان 200 برگرداند. در عوض:

  • اندازه صف Action Scheduler را مانیتور کنید. رشد مداوم صف اغلب نشان‌دهنده از دست رفتن اجراهای زمان‌بندی شده است.
  • لاگ‌های سرور را برای ورودی‌های "403" در بلوک location مربوط به wp-cron.php بررسی کنید.
  • تعداد فرآیندهای PHP-FPM یا FastCGI را در زمان اوج ترافیک مشاهده کنید تا تأیید شود که بار سیستم کاهش یافته است.

یک نکته احتیاطی

برخی از مدیران DISABLE_WP_CRON را روی false نگه می‌دارند زیرا برای اجرای طبیعی cron به سایت‌هایی با ترافیک کم متکی هستند. روش بالا این وابستگی را کاملاً از بین می‌برد، اما یک مرحله نگهداری اضافه می‌کند: باید مطمئن شوید که زمان‌بند سیستم به درستی اجرا می‌شود. اگر سرویس cron سرور از کار بیفتد، وظایف زمان‌بندی شده متوقف می‌شوند. این تنظیمات را با مانیتورینگ سرویس cron سیستم ترکیب کنید تا از این مشکل جلوگیری شود.

خلاصه مطلب: قرار دادن DISABLE_WP_CRON روی true فقط مانع از پینگ کردن WordPress به خودش می‌شود؛ این کار نقطه انتهایی عمومی wp-cron.php را نمی‌بندد. فایل را در وب‌سرور مسدود کنید، یک fallback با mu-plugin اضافه کنید و تمام کارهای زمان‌بندی شده را از طریق یک زمان‌بند سیستم و با استفاده از WP-CLI هدایت کنید. انجام این کار سایت را ایمن می‌کند، کارهای غیرضروری PHP را کاهش می‌دهد و کنترل دقیقی بر زمان اجرای وظایف پس‌زمینه به شما می‌دهد.