خطای زمان‌بندی ازدست‌رفته در وردپرس معمولاً با بررسی سه موضوع روشن می‌شود: زمان نوشته و منطقه زمانی سایت، امکان راه‌اندازی WP-Cron و اجرای موفق همان رویداد. اگر یک نوشته منتشر نشده، فوراً همه کارهای زمان‌بندی را اجرا یا حذف نکنید. ابتدا مشخص کنید کار اصلاً ثبت شده، موعد آن رسیده و در کدام مرحله متوقف شده است.
این راهنما برای نوشته‌های دارای پیام Missed schedule و وظایف زمان‌بندی وردپرس است. صف کار بعضی افزونه‌ها سازوکار جداگانه‌ای دارد؛ برای مثال، وضعیت صف WooCommerce را نباید بدون بررسی با فهرست رویدادهای عادی WP-Cron یکی دانست. مراحل را ابتدا با یک نوشته آزمایشی انجام دهید تا خبر یا پیشنهاد فروش شما ناخواسته منتشر نشود.
چرا زمان انتشار ثبت شده، اما مقاله منتشر نمی‌شود؟
WP-Cron در حالت معمول یک فرایند پیوسته مانند زمان‌بند سیستم‌عامل نیست. بارگذاری صفحات می‌تواند بررسی کارهای سررسیدشده را فعال کند. در سایت کم‌ترافیک یا سایتی که بیشتر پاسخ‌هایش از کش ارائه می‌شود، رسیدن زمان به‌تنهایی اجرای دقیق در همان ثانیه را تضمین نمی‌کند. این تفاوت، علت بررسی یک زمان‌بند واقعی برای کارهای حساس به زمان است.
با این حال، تأخیر همیشه از کمبود بازدید نیست. درخواست داخلی سایت ممکن است به دلیل خطای DNS، TLS، محدودیت دسترسی یا پاسخ برنامه شکست بخورد. گاهی نیز خود رویداد اجرا می‌شود ولی کد افزونه خطا می‌دهد. ابزار و روش تشخیص باید این حالت‌ها را جدا کند؛ افزایش تصادفی تعداد اجرای cron می‌تواند فقط خطا و بار بیشتری تولید کند.
| نشانه | بررسی پیشنهادی | مسیر اصلاح |
|---|---|---|
| زمان نوشته با ساعت موردنظر فرق دارد | منطقه زمانی و تاریخ نوشته | اصلاح همان زمان‌بندی |
| کارها با اولین بازدید اجرا می‌شوند | وابستگی به بارگذاری و کش | ارزیابی زمان‌بند سرور |
| آزمون spawning خطا دارد | درخواست داخلی و تنظیمات cron | رفع علت ارتباط یا پیکربندی |
| فقط یک hook خطا می‌دهد | لاگ همان افزونه و ورودی کار | رفع خطای callback در محیط آزمایشی |
| تعداد زیادی کار قدیمی انباشته شده | مدت اجرا و هم‌زمانی وظایف | بررسی ظرفیت و زمان‌بندی کارهای سنگین |
۱. زمان واقعی سایت و نوشته را تطبیق دهید
در تنظیمات عمومی وردپرس، منطقه زمانی را ببینید و با ساعت نمایش‌داده‌شده در زمان‌بندی نوشته مقایسه کنید. زمان local و UTC را با هم اشتباه نگیرید. برای کسب‌وکاری که با ساعت تهران کار می‌کند، انتخاب منطقه زمانی مناسب به فهم و نگهداری زمان‌ها کمک می‌کند. تغییر منطقه زمانی سایت روی نوشته‌های قدیمی و کارهای دیگر هم نیازمند بررسی است؛ صرفاً برای یک نوشته، تنظیم کل سایت را بی‌دلیل عوض نکنید.
وضعیت نوشته باید واقعاً زمان‌بندی‌شده باشد. ذخیره پیش‌نویس با تاریخی در آینده الزاماً همان ثبت انتشار خودکار نیست. عنوان نوشته، وضعیت و زمان نهایی را در فهرست نوشته‌ها ببینید. برای یک آزمون، نوشته‌ای بدون اطلاعات حساس با عنوان مشخص بسازید، چند دقیقه بعد را انتخاب کنید و نتیجه را پس از موعد از صفحه عمومی و فهرست مدیریت بررسی کنید.
۲. سلامت درخواست داخلی و خطاهای مرتبط را بررسی کنید
بخش سلامت سایت می‌تواند بعضی خطاهای loopback و زمان‌بندی را گزارش کند. نتیجه را همراه متن دقیق پیام ثبت کنید. اگر سایت از داخل سرور نمی‌تواند نام خودش را resolve کند یا TLS معتبر ببیند، همان علت باید بررسی شود. بازشدن سایت از تلفن شما به‌تنهایی سلامت اتصال سرور به خودش را ثابت نمی‌کند؛ مسیر این دو درخواست متفاوت است.
اگر محیط آزمایشی پشت ورود اضافی یا محدودیت IP است، درخواست داخلی هم ممکن است به همان محدودیت برخورد کند. برای عیب‌یابی، استثنای محدود و متناسب با معماری را با مدیر سرور طراحی کنید. برداشتن عمومی احراز هویت محیط آزمایشی یا خاموش‌کردن کامل فایروال، تغییر بزرگ‌تری از نیاز بررسی است. گزارش وب‌سرور در زمان آزمون می‌تواند لایه مسدودکننده را نشان دهد.
۳. در صورت دسترسی SSH، فهرست رویدادها را بخوانید
فرمان‌های زیر برای نصب دارای WP-CLI هستند. آن‌ها را با کاربر مالک سایت و مسیر واقعی وردپرس اجرا کنید؛ برای بررسی معمول، اجرای بی‌دلیل با root لازم نیست. مسیر نمونه را جایگزین کنید. فرمان list فهرست hookها و زمان اجرای بعدی را می‌دهد و برای ثبت وضعیت پیش از هر تغییر مناسب است.
wp --path=/path/to/wordpress cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp --path=/path/to/wordpress cron testآزمون cron test فقط خواندن فهرست نیست؛ سیستم راه‌اندازی cron را از راه HTTP آزمایش می‌کند و می‌تواند کارهای سررسیدشده را به جریان بیندازد. آن را در زمان مناسب و با شناخت کارهای منتظر اجرا کنید. اگر DISABLE_WP_CRON فعال باشد، گزارش آزمون باید در کنار وجود زمان‌بند خارجی تفسیر شود؛ صرف این پیام به معنی خرابی سایتی با cron خارجی سالم نیست.
در خروجی، زمان GMT را به منطقه زمانی موردنظر تبدیل کنید و hook مربوط را با مستندات مؤلفه تطبیق دهید. هر نام ناشناخته‌ای را حذف نکنید. رویداد افزونه پشتیبان‌گیری، ایمیل و انتشار هرکدام اثر متفاوتی دارند. اگر یک hook مرتب شکست می‌خورد، زمان رخداد را با لاگ PHP مقایسه کنید تا callback مشکل‌دار مشخص شود.
۴. چرا اجرای دستی همه رویدادها راه‌حل اولیه نیست؟
فرمان‌های اجرای کارهای سررسیدشده می‌توانند بکاپ، ایمیل، همگام‌سازی یا انتشار واقعی را فعال کنند. اگر هدف فقط تشخیص یک نوشته است، دامنه آزمون را محدود کنید. ابتدا نسخه پشتیبان و فهرست کارهای معوق را داشته باشید و برای اجرای هدفمند از مستندات همان ابزار یا افزونه استفاده کنید. حذف دسته‌جمعی صف، شواهد تشخیص را هم از بین می‌برد.
فرض کنید هر شب بکاپ سنگین با درون‌ریزی محصول هم‌زمان است و انتشار نیز تأخیر پیدا می‌کند. راه بهتر، اندازه‌گیری زمان و مصرف منابع همان دو کار و جداکردن برنامه آن‌هاست. اجرای cron در فاصله‌های بسیار کوتاه، ظرفیت پردازنده و دیسک اضافه ایجاد نمی‌کند. اگر وظیفه گیر کرده یا خطای تکراری دارد، علت همان وظیفه را برطرف کنید.
۵. چه زمانی cron واقعی سرور مناسب است؟
اگر انتشار منظم یا اجرای وظایف مستقل از بازدید نیاز دارید، می‌توان WP-Cron را از زمان‌بند میزبان فراخوانی کرد. این کار در cPanel، DirectAdmin یا VPS روش و مسیر مخصوص خود را دارد. نسخه PHP خط فرمان، کاربر اجرا، مسیر فایل و فاصله اجرا را با میزبان هماهنگ کنید. PHP وب و CLI ممکن است نسخه، افزونه و محدودیت حافظه یکسانی نداشته باشند.
ترتیب درست این است: ابتدا کار خارجی را ایجاد و خروجی آن را ثبت کنید، سپس یک وظیفه آزمایشی را بدون بازدید سایت اجراشده ببینید. فقط بعد از تأیید مسیر جدید، درباره غیرفعال‌کردن راه‌اندازی مبتنی بر بازدید تصمیم بگیرید. افزودن DISABLE_WP_CRON بدون جایگزین سالم می‌تواند همه وظایف وابسته را متوقف کند. این راهنما عمداً یک فرمان cron ثابت برای همه هاست‌ها پیشنهاد نمی‌دهد.
چک‌لیست تأیید رفع مشکل
- یک نوشته آزمایشی با زمان و منطقه زمانی روشن، پس از موعد واقعاً منتشر شده باشد.
- زمان اجرای بعدی رویدادهای تکرارشونده جلو رفته و صف قدیمی بی‌دلیل رشد نکند.
- گزارش زمان‌بند میزبان، اجرای موفق و نبود خطای مسیر یا PHP را نشان دهد.
- وظایف حساس مانند اعلان‌ها و بکاپ نیز جدا بررسی شده باشند.
- مسئول رسیدگی به هشدار و روش برگشت تنظیمات مشخص باشد.
برای پیگیری، نام hook، زمان انتظار، نتیجه آزمون و آخرین تغییر افزونه‌ها را به پشتیبانی بفرستید. اگر مسئله با خطای منابع همراه است، راهنمای 503 وردپرس به بررسی همان لایه کمک می‌کند. برای رسیدگی به اجرای منظم وظایف و گزارش‌ها نیز خدمات مدیریت سایت و سرور را با نیاز واقعی خود تطبیق دهید.
پرسش‌های رایج درباره WP-Cron
چرا مقاله با اولین بازدید بعد از موعد منتشر می‌شود؟
این رفتار می‌تواند با فعال‌شدن cron هنگام بارگذاری صفحه سازگار باشد. ابتدا وضعیت تنظیمات و نبود زمان‌بند مستقل را بررسی کنید؛ یک مشاهده به‌تنهایی علت قطعی همه تأخیرها نیست.
آیا نصب افزونه نمایش cron کافی است؟
ابزار دیدن رویدادها به تشخیص کمک می‌کند، اما اتصال داخلی ناموفق، callback خراب یا کمبود منابع را خودبه‌خود رفع نمی‌کند.
اگر DISABLE_WP_CRON فعال است، آن را حذف کنم؟
اول وجود و سلامت زمان‌بند خارجی را بررسی کنید. این تنظیم در بعضی معماری‌ها عمدی است و تغییر آن بدون شناخت مسیر اجرا می‌تواند رفتار متفاوتی ایجاد کند.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.