WP-Cron و زمان‌بندی خودکار در وردپرس

WP-Cron یک سیستم زمان‌بندی داخلی در وردپرس (WordPress) است که به افزونه‌ها، قالب‌ها و هسته امکان می‌دهد وظایف مشخصی را در فواصل زمانی تعیین‌شده اجرا کنند. این سیستم برخلاف Cron واقعی سیستم‌عامل، به بازدید کاربران وابسته است: هر بار که صفحه‌ای بارگذاری می‌شود، وردپرس بررسی می‌کند که آیا وظیفه‌ای موعد اجرا رسیده است یا خیر. همین وابستگی، عامل اصلی بسیاری از مشکلاتی است که مدیران سایت با آن مواجه می‌شوند؛ از اجرا نشدن ایمیل‌های زمان‌بندی‌شده تا تجمع وظایف معوق و افزایش مصرف CPU. در این نوشتار، مکانیزم WP-Cron، تفاوت آن با Cron واقعی، روش‌های عیب‌یابی، جایگزینی اصولی با Cron سرور و نکات پیشرفته برای تیم‌های DevOps بررسی می‌شود. هدف این است که خواننده پس از مطالعه، بتواند زمان‌بندی خودکار سایت خود را به‌صورت قطعی و قابل اتکا مدیریت کند.

در پروژه‌هایی که با ووکامرس، سیستم‌های عضویتی یا سایت‌های پرمحتوا کار می‌کنند، یکی از پرتکرارترین مشکلاتی که به تیم پشتیبانی گزارش می‌شود، اجرا نشدن وظایف زمان‌بندی‌شده است. ایمیل‌های سفارش ارسال نمی‌شوند، به‌روزرسانی‌های خودکار شکست می‌خورند، و کوپن‌های منقضی همچنان فعال باقی می‌مانند. ریشه اکثر این مشکلات در نحوه رفتار WP-Cron نهفته است، نه در خود افزونه‌ها. تجربه عملی نشان می‌دهد که با درک دقیق مکانیزم WP-Cron و جایگزینی آن با Cron واقعی سرور، می‌توان تقریباً تمام این مشکلات را به‌صورت قطعی حل کرد.

WP-Cron چیست و چگونه کار می‌کند؟

WP-Cron سیستم زمان‌بندی وظایف در وردپرس است. این سیستم به هسته، افزونه‌ها و قالب‌ها اجازه می‌دهد وظایفی را ثبت کنند که در فواصل زمانی مشخص یا در زمان‌های خاص اجرا شوند. مفهوم Cron (زمان‌بندی) در سیستم‌عامل‌های یونیکسی سابقه‌ای طولانی دارد؛ اما وردپرس یک پیاده‌سازی متفاوت ارائه داده که به آن WP-Cron گفته می‌شود.

تفاوت بنیادین WP-Cron با Cron سیستم‌عامل در این است که WP-Cron به بازدید کاربران وابسته است. هر بار که یک صفحه از سایت بارگذاری می‌شود، وردپرس در تابع wp-cron.php بررسی می‌کند که آیا رویدادی موعد اجرا رسیده است یا خیر. اگر رویدادی موعدش رسیده باشد، آن را اجرا می‌کند. اگر ترافیک سایت صفر باشد، هیچ رویدادی اجرا نمی‌شود.

این طراحی در زمان معرفی WP-Cron (حدود سال ۲۰۰۵ میلادی) منطقی بود: بسیاری از سایت‌های وردپرسی روی هاست‌های اشتراکی اجرا می‌شدند که دسترسی به Cron واقعی سیستم‌عامل نداشتند. WP-Cron راه‌حلی بود که بدون نیاز به دسترسی سرور، زمان‌بندی را ممکن می‌کرد. اما در سایت‌های مدرن با ترافیک متغیر، این وابستگی به بازدید، به یک نقطه ضعف جدی تبدیل شده است.

WP-Cron یک زمان‌بند مبتنی بر بازدید است، نه یک زمان‌بند مبتنی بر زمان. این تفاوت ظریف، ریشه بسیاری از مشکلات عملیاتی است.

برای مطالعه بیشتر درباره مفاهیم پایه وردپرس، مقاله وردپرس چیست و چگونه شروع به کار با آن کنیم؟ را ببینید.

چرخه اجرای یک رویداد Cron در وردپرس

چرخه اجرای یک رویداد WP-Cron از چند مرحله تشکیل می‌شود:

ثبت رویداد: افزونه یا کد سفارشی با wp_schedule_event() یک رویداد را ثبت می‌کند.
ذخیره در دیتابیس: زمان اجرای رویداد در گزینه cron جدول wp_options ذخیره می‌شود.
بررسی در بارگذاری صفحه: هر بارگذاری صفحه، تابع wp_cron() فراخوانی می‌شود و زمان فعلی را با زمان رویدادها مقایسه می‌کند.
اجرای رویداد: اگر زمان رویدادی گذشته باشد، تابع مربوطه با استفاده از do_action_ref_array() اجرا می‌شود.
حذف یا زمان‌بندی مجدد: پس از اجرا، رویداد یک‌باره حذف می‌شود و رویداد تکرارشونده زمان‌بندی بعدی خود را دریافت می‌کند.

این چرخه ساده به نظر می‌رسد، اما در عمل با چالش‌های متعددی مواجه می‌شود که در ادامه بررسی می‌شود.

تفاوت WP-Cron با Cron واقعی سرور

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

ویژگی	WP-Cron	Cron واقعی (System Cron)
تریگر اجرا	بازدید کاربران	زمان سیستم‌عامل
دقت زمان‌بندی	متغیر و غیرقابل پیش‌بینی	دقیق در حد ثانیه
وابستگی به ترافیک	بالا	صفر
اجرای همزمان	ممکن و مشکل‌ساز	قابل کنترل با flock
نیاز به دسترسی سرور	خیر	بله
مناسب برای	هاست اشتراکی، وظایف سبک	سرور اختصاصی، VPS، وظایف حیاتی
قابلیت لاگ‌گیری	محدود	کامل
پایداری در ترافیک صفر	ندارد	دارد

همان‌طور که مشخص است، WP-Cron برای سناریوهای سبک طراحی شده و در محیط‌های حرفه‌ای، Cron واقعی سرور انتخاب بهتری است. برای مطالعه بیشتر درباره مدیریت سرور، مقاله سرور چیست و چگونه کار می‌کند؟ را ببینید.

ساختار داخلی WP-Cron

WP-Cron در سطح کد، از چند تابع و گزینه کلیدی استفاده می‌کند. درک این ساختار برای عیب‌یابی ضروری است.

گزینه‌های ذخیره‌سازی در wp_options

WP-Cron از سه گزینه اصلی در جدول wp_options استفاده می‌کند:

cron: آرایه‌ای سریالی‌شده از رویدادهای زمان‌بندی‌شده. کلید آن زمان اجرا (Unix timestamp) و مقدار آن نام هوک و آرگومان‌هاست.
cron_version: نسخه ساختار داده Cron. با هر تغییر ساختار، افزایش می‌یابد.
doing_cron: زمان آخرین اجرای Cron. برای جلوگیری از اجرای همزمان استفاده می‌شود.

گزینه cron معمولاً autoloaded است. اگر تعداد رویدادها زیاد باشد، حجم این گزینه می‌تواند به چند صد کیلوبایت برسد. برای مطالعه بیشتر درباره این موضوع، مقاله Autoload و تأثیر آن بر سرعت وردپرس را ببینید.

SELECT option_value
FROM wp_options
WHERE option_name = 'cron';

این کوئری محتوای گزینه cron را نمایش می‌دهد. محتوای آن یک رشته سریالی‌شده PHP است که با maybe_unserialize() قابل تبدیل به آرایه است.

مکانیزم spawn_cron و wp_remote_post

وقتی WP-Cron تشخیص می‌دهد که رویدادی موعدش رسیده، تابع spawn_cron() را فراخوانی می‌کند. این تابع یک درخواست HTTP غیرهمزمان به فایل wp-cron.php ارسال می‌کند:

function spawn_cron($gmt_time = 0) {
    // ...
    $cron_url = site_url('wp-cron.php?doing_wp_cron=' . sprintf('%.22F', $doing_wp_cron));
    wp_remote_post($cron_url, array(
        'timeout' => 0.01,
        'blocking' => false,
        'sslverify' => apply_filters('https_local_ssl_verify', false),
    ));
}

نکته کلیدی در این کد، مقدار timeout => 0.01 و blocking => false است. این تنظیمات باعث می‌شوند که درخواست غیرهمزمان ارسال شود و وردپرس منتظر پاسخ نماند. این یعنی اجرای Cron در پس‌زمینه انجام می‌شود و تجربه کاربر تحت تأثیر قرار نمی‌گیرد.

با این حال، اگر سایت پشت فایروال باشد یا تابع wp_remote_post مسدود شده باشد، درخواست ارسال نمی‌شود و Cron اجرا نمی‌شود. این یکی از شایع‌ترین دلایل اجرا نشدن WP-Cron در سرورهای خاص است.

هوک‌های مرتبط با Cron

وردپرس چند هوک مرتبط با Cron ارائه می‌دهد که برای افزونه‌نویسی و عیب‌یابی مفیدند:

wp_loaded: در هر بارگذاری صفحه، قبل از بررسی Cron اجرا می‌شود.
init: در زمان راه‌اندازی وردپرس، فرصت مناسبی برای ثبت رویدادهای Cron است.
wp_cron: در زمان اجرای Cron فراخوانی می‌شود.
cron_schedules: فیلتری برای افزودن فواصل زمانی سفارشی.
pre_schedule_event: فیلتری برای کنترل ثبت رویدادها.

نمونه‌ای از افزودن فاصله زمانی سفارشی:

add_filter('cron_schedules', function($schedules) {
    $schedules['every_15_minutes'] = array(
        'interval' => 900,
        'display'  => 'هر ۱۵ دقیقه'
    );
    return $schedules;
});

add_action('init', function() {
    if (!wp_next_scheduled('my_custom_event')) {
        wp_schedule_event(time(), 'every_15_minutes', 'my_custom_event');
    }
});

add_action('my_custom_event', function() {
    // منطق اجرای رویداد
});

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

چرا WP-Cron در سایت‌های واقعی به مشکل می‌خورد؟

WP-Cron در محیط‌های واقعی با چند مشکل ساختاری مواجه است که از طراحی بازدیدمحور آن ناشی می‌شود. در ادامه، این مشکلات بررسی می‌شود.

ترافیک پایین و وظایف معوق

مهم‌ترین مشکل WP-Cron، وابستگی به ترافیک است. اگر سایتی در ساعات شب یا روزهای تعطیل ترافیک نداشته باشد، رویدادهای Cron موعدشان می‌رسد اما اجرا نمی‌شوند. با بازگشت ترافیک، همه این رویدادها به‌صورت یک‌جا اجرا می‌شوند که می‌تواند به مصرف بالای CPU و کندی سایت منجر شود.

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

ترافیک بالا و اجرای همزمان

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

تداخل با کش

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

راه‌حل این مشکل، خارج کردن wp-cron.php از کش یا جایگزینی WP-Cron با Cron واقعی است.

وظایف طولانی و timeout

برخی وظایف زمان‌بندی‌شده مانند پشتیبان‌گیری کامل، به‌روزرسانی انبوه محصولات یا ارسال هزاران ایمیل، زمان‌بر هستند. WP-Cron این وظایف را درخواست HTTP اجرا می‌کند که معمولاً محدودیت زمانی دارد. اگر سرور در ۳۰ ثانیه اجرای اسکریپت را قطع کند، وظیفه نیمه‌کاره می‌ماند و در اجرای بعدی از ابتدا شروع می‌شود. این می‌تواند به حلقه‌های بی‌پایان یا داده‌های ناقص منجر شود.

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

عیب‌یابی WP-Cron

عیب‌یابی WP-Cron نیازمند رویکرد سیستماتیک است. در ادامه، روش‌های عملی بررسی می‌شود.

بازرسی رویدادهای زمان‌بندی‌شده

اولین گام، مشاهده رویدادهای ثبت‌شده است. با WP-CLI می‌توان همه رویدادها را لیست کرد:

wp cron event list
wp cron event list --fields=hook,next_run,recurrence,interval
wp cron event list --format=json

این دستورات همه رویدادهای Cron را با زمان اجرای بعدی و فاصله تکرار نمایش می‌دهند. اگر رویدادی موعدش گذشته اما اجرا نشده، مقدار next_run در گذشته خواهد بود. برای مطالعه بیشتر درباره WP-CLI، مقاله WP-CLI و مدیریت وردپرس از خط فرمان را ببینید.

برای بررسی از طریق دیتابیس:

SELECT option_value FROM wp_options WHERE option_name = 'cron';

خروجی این کوئری یک رشته سریالی‌شده است که برای خوانایی باید با PHP یا ابزار آنلاین unserialize شود.

ثبت لاگ و تحلیل رفتار

WP-Cron به‌طور پیش‌فرض لاگ نمی‌گیرد. برای فعال‌سازی لاگ، می‌توان از ثابت WP_CRON_LOCK_TIMEOUT و DISABLE_WP_CRON استفاده کرد یا یک افزونه لاگ‌گیری نصب کرد. روش ساده‌تر، افزودن کد زیر به wp-config.php است:

define('WP_CRON_LOCK_TIMEOUT', 60);
define('DISABLE_WP_CRON', true);

با فعال‌سازی DISABLE_WP_CRON، WP-Cron داخلی غیرفعال می‌شود و می‌توان اجرای Cron را به‌صورت دستی یا از طریق Cron سرور مدیریت کرد.

تست اجرای دستی Cron

برای تست، می‌توان رویدادهای موعد رسیده را به‌صورت دستی اجرا کرد:

wp cron event run --due-now
wp cron event run my_custom_hook
wp cron test

دستور wp cron test بررسی می‌کند که آیا WP-Cron به‌درستی کار می‌کند. اگر این دستور خطا برگرداند، یعنی WP-Cron در سطح پایه با مشکل مواجه است. برای مطالعه بیشتر درباره عیب‌یابی سایت، مقاله چگونه مشکل سرعت سایت را عیب‌یابی کنیم؟ را ببینید.

جایگزینی WP-Cron با Cron واقعی سرور

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

غیرفعال‌سازی WP-Cron داخلی

اولین گام، غیرفعال کردن WP-Cron داخلی است. این کار با افزودن یک ثابت به wp-config.php انجام می‌شود:

define('DISABLE_WP_CRON', true);

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

تنظیم Crontab سرور

گام بعدی، تنظیم Crontab سرور است. با دستور crontab -e فایل Cron را باز کنید و خط زیر را اضافه کنید:

*/5 * * * * cd /var/www/html && wp cron event run --due-now > /dev/null 2>&1

این خط، هر ۵ دقیقه رویدادهای موعد رسیده را اجرا می‌کند. برای سایت‌های حساس، می‌توان فاصله را به ۱ دقیقه کاهش داد:

* * * * * cd /var/www/html && wp cron event run --due-now > /dev/null 2>&1

برای لاگ‌گیری و دیباگ:

*/5 * * * * cd /var/www/html && wp cron event run --due-now >> /var/log/wp-cron.log 2>&1

گام مهم دیگر، جلوگیری از اجرای همزمان با flock است:

*/5 * * * * flock -n /tmp/wp-cron.lock -c "cd /var/www/html && wp cron event run --due-now"

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

جایگزین مدرن با systemd timers

در سیستم‌های مدرن لینوکسی، systemd timers جایگزین قدرتمندتری برای Crontab هستند. مزایای systemd timers:

لاگ‌گیری یکپارچه با journald
کنترل دقیق‌تر بر اجرای همزمان
پشتیبانی از وابستگی بین سرویس‌ها
قابلیت restart خودکار در صورت خطا

یک unit file نمونه:

[Unit]
Description=WordPress Cron
After=network.target

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/var/www/html
ExecStart=/usr/local/bin/wp cron event run --due-now

و timer متناظر:

[Unit]
Description=Run WordPress Cron every 5 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
Unit=wp-cron.service

[Install]
WantedBy=timers.target

پس از ایجاد این فایل‌ها در /etc/systemd/system/، با دستورات systemctl enable wp-cron.timer و systemctl start wp-cron.timer فعال می‌شوند.

جایگزینی WP-Cron با Cron واقعی، یکی از کم‌هزینه‌ترین و مؤثرترین بهینه‌سازی‌هایی است که می‌توان روی یک سایت وردپرسی انجام داد.

ترکیب WP-Cron با WP-CLI

WP-CLI و WP-Cron ترکیبی طبیعی می‌سازند. WP-CLI دستورات متعددی برای مدیریت Cron ارائه می‌دهد که فرآیند عیب‌یابی و اجرا را ساده می‌کنند:

wp cron event list
wp cron event schedule my_hook now 'hourly'
wp cron event unschedule my_hook
wp cron event run --due-now
wp cron event delete my_hook
wp cron test

wp cron event schedule: ثبت رویداد جدید
wp cron event unschedule: حذف رویداد
wp cron event run --due-now: اجرای رویدادهای موعد رسیده
wp cron event delete: حذف رویداد با نام مشخص

این دستورات به‌ویژه در اسکریپت‌های استقرار و CI/CD بسیار مفیدند. برای مطالعه بیشتر، مقاله CI/CD برای پروژه‌های وردپرسی را ببینید.

وظایف پرکاربرد مبتنی بر Cron در وردپرس

بسیاری از قابلیت‌های وردپرس و افزونه‌ها به WP-Cron وابسته‌اند. در ادامه، پرکاربردترین این وظایف بررسی می‌شود.

انتشار زمان‌بندی‌شده نوشته‌ها

انتشار زمان‌بندی‌شده (Scheduled Posts) به WP-Cron وابسته است. اگر Cron اجرا نشود، نوشته‌های زمان‌بندی‌شده در زمان مقرر منتشر نمی‌شوند. این مشکل به‌ویژه در سایت‌های خبری که انتشار زمان‌بندی‌شده بخشی از جریان کاری است، بحرانی می‌شود. راه‌حل قطعی، استفاده از Cron واقعی سرور است.

اطلاع‌رسانی ایمیلی

بسیاری از افزونه‌ها ایمیل‌های اطلاع‌رسانی را با WP-Cron ارسال می‌کنند. اگر Cron اجرا نشود، این ایمیل‌ها هرگز ارسال نمی‌شوند. این مشکل به‌ویژه در ووکامرس شایع است. برای مطالعه بیشتر درباره رفع مشکلات ایمیل، مقاله رفع مشکلات SMTP در وردپرس را ببینید.

پشتیبان‌گیری خودکار

افزونه‌های پشتیبان‌گیری مانند UpdraftPlus و BackupBuddy از WP-Cron برای زمان‌بندی پشتیبان‌گیری استفاده می‌کنند. اگر WP-Cron پایدار نباشد، پشتیبان‌گیری خودکار نیز نامطمئن می‌شود. برای مطالعه بیشتر درباره پشتیبان‌گیری، مقاله کرون وردپرس چیست و چگونه زمان‌بندی خودکار کارها را درست مدیریت کنیم؟ را ببینید.

وظایف زمان‌بندی‌شده ووکامرس

ووکامرس از WP-Cron برای چندین وظیفه حیاتی استفاده می‌کند:

پاک‌سازی سشن‌های منقضی
به‌روزرسانی وضعیت سفارش‌های معلق
ارسال ایمیل‌های سفارش
به‌روزرسانی کش محصولات
پردازش کوپن‌های منقضی

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

نکات امنیتی WP-Cron

فایل wp-cron.php از طریق HTTP قابل فراخوانی است. این یعنی هر کسی می‌تواند با ارسال درخواست به این فایل، Cron را اجرا کند. این موضوع می‌تواند به حملات DoS (Denial of Service) منجر شود، زیرا مهاجم می‌تواند با ارسال درخواست‌های مکرر، منابع سرور را مصرف کند.

راهکارهای امنیتی:

غیرفعال‌سازی WP-Cron داخلی: با DISABLE_WP_CRON، فایل wp-cron.php دیگر از طریق HTTP فراخوانی نمی‌شود.
محدود کردن دسترسی به wp-cron.php: در .htaccess یا Nginx، دسترسی به این فایل را محدود کنید.
استفاده از nonce: در صورت اجبار به استفاده از WP-Cron داخلی، می‌توان از nonce برای تأیید درخواست استفاده کرد.
پایش لاگ درخواست‌ها: درخواست‌های مکرر به wp-cron.php می‌تواند نشانه حمله باشد.

نمونه محدودسازی در Nginx:

location = /wp-cron.php {
    allow 127.0.0.1;
    deny all;
}

این پیکربندی اجازه می‌دهد WP-Cron فقط از طریق localhost اجرا شود و دسترسی خارجی مسدود شود. برای مطالعه بیشتر درباره امنیت، مقاله چگونه امنیت وردپرس را تقویت کنیم؟ را ببینید.

تأثیر WP-Cron بر عملکرد سایت

WP-Cron دو نوع تأثیر بر عملکرد دارد:

تأثیر مستقیم: هر بارگذاری صفحه، یک بررسی کوچک انجام می‌شود تا ببیند آیا Cron باید اجرا شود. این بررسی معمولاً ناچیز است، اما در سایت‌های پرترافیک می‌تواند جمع شود.
تأثیر غیرمستقیم: اجرای همزمان Cron در سایت‌های پرترافیک می‌تواند به مصرف بالای CPU و کندی سایت منجر شود.

با جایگزینی WP-Cron با Cron واقعی، تأثیر مستقیم حذف می‌شود و تأثیر غیرمستقیم کنترل‌شده می‌شود. برای مطالعه بیشتر درباره بهینه‌سازی سرعت، مقاله چگونه سرعت سایت وردپرسی را افزایش دهیم؟ را ببینید.

WP-Cron در CI/CD و محیط‌های توزیع‌شده

در معماری‌های CI/CD و محیط‌های توزیع‌شده، مدیریت WP-Cron پیچیده‌تر می‌شود:

محیط‌های چندسروری: اگر سایت روی چند سرور اجرا شود، WP-Cron باید فقط روی یک سرور اجرا شود تا از اجرای همزمان جلوگیری شود.
محیط‌های Docker: در معماری‌های Kubernetes، WP-Cron باید به‌عنوان یک CronJob جداگانه تعریف شود، نه در Pod اصلی.
محیط‌های Staging: در محیط‌های استیجینگ، WP-Cron باید غیرفعال باشد تا ایمیل‌ها و وظایف تولیدی اجرا نشوند.

نمونه تعریف CronJob در Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: wordpress-cron
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: wp-cron
            image: wordpress:cli-php8.2
            command: ["wp", "cron", "event", "run", "--due-now"]
            workingDir: /var/www/html
          restartPolicy: OnFailure

این CronJob هر ۵ دقیقه اجرا می‌شود و رویدادهای موعد رسیده را پردازش می‌کند.

اشتباهات رایج در مدیریت WP-Cron

اشتباهات رایج در مدیریت WP-Cron می‌تواند به مشکلات جدی منجر شود. برخی از مهم‌ترین این اشتباهات:

نادیده گرفتن اجرای همزمان: بدون flock، اجرای همزمان Cron می‌تواند به مصرف بالای CPU منجر شود.
استفاده از WP-Cron برای وظایف سنگین: WP-Cron برای وظایف سبک طراحی شده، نه برای پشتیبان‌گیری چند گیگابایتی.
عدم لاگ‌گیری: بدون لاگ، عیب‌یابی تقریباً غیرممکن است.
فعال بودن WP-Cron داخلی در کنار Cron سرور: این کار باعث اجرای دوگانه می‌شود.
نادیده گرفتن تداخل با کش: اگر صفحه‌ای از کش سرو شود، WP-Cron اجرا نمی‌شود.
عدم استفاده از flock: این ابزار ساده، از اجرای همزمان جلوگیری می‌کند.
محدود کردن دسترسی به wp-cron.php بدون تنظیم Cron جایگزین: این کار می‌تواند به توقف کامل وظایف زمان‌بندی‌شده منجر شود.
اجرای Cron با کاربر root: باید با کاربر مالک فایل‌های وردپرس اجرا شود.
نادیده گرفتن منطقه زمانی سرور: تفاوت منطقه زمانی سرور با منطقه زمانی سایت می‌تواند به اجرای نادرست منجر شود.
عدم پایش دوره‌ای رویدادها: رویدادهای معوق باید به‌صورت دوره‌ای بررسی شوند.

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

پرسش‌های پرتکرار درباره WP-Cron

در این بخش، به پرسش‌های متداول درباره WP-Cron پاسخ داده می‌شود. این ساختار برای بهینه‌سازی محتوا برای موتورهای پاسخگو (Answer Engines) نیز مفید است.

WP-Cron چیست و چه تفاوتی با Cron سرور دارد؟

WP-Cron سیستم زمان‌بندی داخلی وردپرس است که به بازدید کاربران وابسته است. Cron سرور، ابزار سیستم‌عامل است که بر اساس زمان دقیق اجرا می‌شود. تفاوت اصلی این است که WP-Cron در سایت‌های کم‌ترافیک ممکن است اجرا نشود، اما Cron سرور همیشه در زمان مقرر اجرا می‌شود.

چگونه WP-Cron را غیرفعال کنیم؟

با افزودن define('DISABLE_WP_CRON', true); به فایل wp-config.php. پس از این تنظیم، باید Cron سرور را برای اجرای وظایف زمان‌بندی‌شده تنظیم کنید.

چگونه WP-Cron را با Cron سرور جایگزین کنیم؟

ابتدا WP-Cron داخلی را با DISABLE_WP_CRON غیرفعال کنید. سپس یک خط در Crontab سرور اضافه کنید که هر چند دقیقه wp cron event run --due-now را اجرا کند. برای جلوگیری از اجرای همزمان، از flock استفاده کنید.

چرا نوشته‌های زمان‌بندی‌شده منتشر نمی‌شوند؟

دلیل اصلی، اجرا نشدن WP-Cron است. اگر سایت ترافیک کمی داشته باشد یا WP-Cron غیرفعال باشد اما Cron جایگزین تنظیم نشده باشد، رویدادهای زمان‌بندی‌شده اجرا نمی‌شوند. راه‌حل، تنظیم Cron سرور است.

آیا WP-Cron بر سرعت سایت اثر می‌گذارد؟

به‌طور مستقیم، تأثیر ناچیزی دارد، زیرا بررسی Cron در هر بارگذاری بسیار سریع است. اما اگر Cron به‌صورت همزمان در سایت پرترافیک اجرا شود، می‌تواند به مصرف بالای CPU و کندی منجر شود. جایگزینی با Cron سرور این مشکل را حل می‌کند.

آیا WP-Cron با ووکامرس کار می‌کند؟

بله. ووکامرس از WP-Cron برای چندین وظیفه مانند پاک‌سازی سشن‌ها، ارسال ایمیل سفارش و به‌روزرسانی کش استفاده می‌کند. برای فروشگاه‌های جدی، جایگزینی WP-Cron با Cron سرور توصیه می‌شود.

چند وقت یک‌بار Cron سرور را اجرا کنیم؟

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

چگونه از اجرای همزمان Cron جلوگیری کنیم؟

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

آیا می‌توان WP-Cron را روی هاست اشتراکی جایگزین کرد؟

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

چگونه رویدادهای Cron را از دیتابیس حذف کنیم؟

با wp cron event delete hook_name در WP-CLI یا wp_clear_scheduled_hook('hook_name') در کد PHP. برای حذف همه رویدادها، می‌توان گزینه cron را از جدول wp_options حذف کرد، اما این کار توصیه نمی‌شود زیرا افزونه‌ها رویدادهای خود را مجدداً ثبت می‌کنند.

نکات پیشرفته برای مهندسان ارشد و تیم‌های DevOps

برای مهندسان ارشد و تیم‌های DevOps، WP-Cron یک مسئله چندلایه است که نیازمند درک عمیق از معماری، زمان‌بندی و پایداری سیستم است. در این بخش، به نکات پیشرفته‌ای می‌پردازیم که در پروژه‌های بزرگ حیاتی می‌شوند.

مدیریت WP-Cron در معماری چندسروری

در معماری‌های چندسروری (Load Balanced)، WP-Cron باید فقط روی یک سرور اجرا شود. اجرای Cron روی همه سرورها می‌تواند به اجرای چندباره یک رویداد منجر شود که پیامدهایی مانند ارسال چندباره ایمیل یا ثبت چندباره داده دارد. راه‌حل‌ها:

تعیین یک سرور اختصاصی به‌عنوان Cron server
استفاده از یک سرویس جداگانه برای CronJob (مانند Kubernetes CronJob)
استفاده از قفل توزیع‌شده با Redis

نمونه استفاده از قفل توزیع‌شده با Redis:

add_action('init', function() {
    if (wp_doing_cron()) {
        $lock_key = 'wp_cron_lock';
        $redis = new Redis();
        $redis->connect('127.0.0.1', 6379);
        
        if (!$redis->set($lock_key, getmypid(), ['nx', 'ex' => 300])) {
            exit; // Cron already running elsewhere
        }
    }
});

این کد تضمین می‌کند که در هر لحظه فقط یک سرور Cron را اجرا می‌کند.

پایش و هشداردهی Cron

در محیط‌های تولیدی، باید Cron به‌صورت فعال پایش شود. معیارهای کلیدی:

زمان آخرین اجرای موفق Cron
تعداد رویدادهای معوق
زمان اجرای هر رویداد
نرخ شکست رویدادها

یک اسکریپت نمونه برای هشدار:

#!/bin/bash
cd /var/www/html
OVERDUE=$(wp cron event list --due-now --format=count)
if [ "$OVERDUE" -gt 10 ]; then
    curl -X POST https://hooks.slack.com/... -d "{"text": "Warning: $OVERDUE overdue cron events"}"
fi

این اسکریپت را می‌توان به‌عنوان بخشی از Crontab یا یک سرویس جداگانه اجرا کرد.

جایگزینی WP-Cron با صف پردازش

برای وظایف سنگین، WP-Cron مناسب نیست. جایگزین‌های مدرن:

Action Scheduler (ووکامرس): یک سیستم صف پردازش مبتنی بر دیتابیس که در ووکامرس استفاده می‌شود.
Redis Queue: استفاده از Redis برای مدیریت صف وظایف.
RabbitMQ: سیستم پیام‌رسان حرفه‌ای برای صف‌های توزیع‌شده.
AWS SQS: سرویس صف مدیریت‌شده آمازون.

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

تحلیل رفتار Cron در سطح کد

برای درک دقیق رفتار Cron، می‌توان زمان اجرای هر رویداد را ثبت کرد:

add_action('init', function() {
    add_action('my_custom_event', function() {
        $start = microtime(true);
        
        // منطق رویداد
        
        $duration = microtime(true) - $start;
        error_log(sprintf('my_custom_event took %.2f seconds', $duration));
    });
});

این کد زمان اجرای رویداد را در error log ثبت می‌کند. تحلیل این داده‌ها می‌تواند به شناسایی رویدادهای کند کمک کند.

مدیریت Cron در محیط‌های Immutable

در محیط‌های Immutable (مانند Docker و Kubernetes)، فایل‌های سیستم قابل تغییر نیستند. بنابراین، تنظیم Cron باید به‌صورت declarative انجام شود. راه‌حل‌ها:

در Docker: افزودن Crontab به image در زمان build
در Kubernetes: تعریف CronJob به‌عنوان یک منبع جداگانه
در محیط‌های CI/CD: اجرای Cron از طریق pipeline

نمونه Dockerfile:

FROM wordpress:php8.2-apache

RUN apt-get update && apt-get install -y cron 
    && echo "*/5 * * * * cd /var/www/html && wp cron event run --due-now >> /var/log/wp-cron.log 2>&1" > /etc/cron.d/wp-cron 
    && chmod 0644 /etc/cron.d/wp-cron

CMD ["cron", "-f"]

این Dockerfile یک سرویس Cron داخلی راه‌اندازی می‌کند که هر ۵ دقیقه رویدادها را اجرا می‌کند.

ملاحظات منطقه زمانی

منطقه زمانی سرور ممکن است با منطقه زمانی سایت متفاوت باشد. این تفاوت می‌تواند به اجرای نادرست رویدادهای زمان‌بندی‌شده منجر شود. راه‌حل‌ها:

تنظیم منطقه زمانی سرور با timedatectl set-timezone Asia/Tehran
استفاده از UTC در سرور و تبدیل در سطح برنامه
ثبت زمان‌ها به‌صورت UTC و تبدیل در نمایش

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

مقایسه WP-Cron با Action Scheduler

Action Scheduler یک سیستم صف پردازش است که توسط ووکامرس توسعه یافته و در نسخه‌های اخیر وردپرس نیز به‌عنوان یک راه‌حل عمومی شناخته می‌شود. تفاوت‌های کلیدی:

ویژگی	WP-Cron	Action Scheduler
ذخیره‌سازی	wp_options	جداول اختصاصی
مقیاس‌پذیری	محدود	بالا
پردازش موازی	خیر	بله
تلاش مجدد	محدود	خودکار
پایش	محدود	کامل
مناسب برای	وظایف سبک	وظایف سنگین و حجیم

برای سایت‌های بزرگ، Action Scheduler انتخاب بهتری است. برای مطالعه بیشتر درباره بهینه‌سازی دیتابیس، مقاله Database Optimization و بهینه‌سازی دیتابیس وردپرس را ببینید.

الگوهای ضد‌الگوی رایج در WP-Cron

در بازبینی کد افزونه‌های متعدد، چند الگوی ضد‌الگو (Anti-Pattern) رایج دیده می‌شود:

ثبت رویداد در هر بارگذاری صفحه: این کار باعث تجمع رویدادهای تکراری می‌شود. باید با wp_next_scheduled() بررسی شود.
اجرای وظایف سنگین در WP-Cron: وظایفی که بیش از ۳۰ ثانیه طول می‌کشند، باید به صف منتقل شوند.
نادیده گرفتن خطا: اگر رویدادی خطا بدهد اما خطا مدیریت نشود، در اجرای بعدی دوباره تلاش می‌شود و ممکن است به حلقه بی‌پایان منجر شود.
عدم استفاده از transient برای قفل: برای جلوگیری از اجرای همزمان یک رویداد، باید از قفل استفاده شود.
حذف نکردن رویداد در زمان غیرفعال‌سازی افزونه: این کار باعث باقی ماندن رویدادهای یتیم می‌شود.

نمونه الگوی صحیح ثبت رویداد:

register_activation_hook(__FILE__, function() {
    if (!wp_next_scheduled('my_plugin_daily_event')) {
        wp_schedule_event(time(), 'daily', 'my_plugin_daily_event');
    }
});

register_deactivation_hook(__FILE__, function() {
    wp_clear_scheduled_hook('my_plugin_daily_event');
});

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

نکات کلیدی برای پایداری بلندمدت

در پایان، چند نکته کلیدی برای پایداری بلندمدت WP-Cron:

در محیط تولید، همیشه WP-Cron داخلی را غیرفعال و از Cron سرور استفاده کنید.
از flock برای جلوگیری از اجرای همزمان استفاده کنید.
لاگ‌گیری فعال داشته باشید و رویدادهای معوق را پایش کنید.
وظایف سنگین را به صف‌های پردازش منتقل کنید.
دسترسی به wp-cron.php را محدود کنید.
منطقه زمانی سرور را با سایت هماهنگ کنید.
رویدادها را در زمان غیرفعال‌سازی افزونه پاک کنید.
در معماری‌های چندسروری، فقط یک سرور را مسئول Cron کنید.
در محیط‌های Docker و Kubernetes، از CronJob استفاده کنید.
برای وظایف پیچیده، Action Scheduler را جایگزین WP-Cron کنید.

اگر در پروژه‌های خود با مشکل WP-Cron مواجه شده‌اید، جالب است بدانم کدام بخش بیشترین چالش را ایجاد کرده است. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل متفاوتی برای پایدارسازی زمان‌بندی پیدا کرده‌اید که می‌تواند برای دیگران مفید باشد.