چرا کارهای زمان‌بندی‌شدهٔ ووکامرس دیر اجرا می‌شوند؟
وقتی ارسال سفارش به انبار، گزارش روزانه یا یک کار خودکار عقب می‌افتد، اول باید مشخص شود کار هنوز شروع نشده یا شروع شده و شکست خورده است. تعداد کارهای Pending به‌تنهایی مشکل را اثبات نمی‌کند؛ زمان سررسید، گزارش اجرا و نتیجهٔ واقعی در مقصد، مسیر بررسی را روشن می‌کنند.
برای تفاوت اجرای کار با نتیجهٔ سرویس، راهنمای پیامک وضعیت سفارش و کد رهگیری را ببینید.
WP-Cron و Action Scheduler چه تفاوتی دارند؟
WP-Cron سازوکار زمان‌بندی وردپرس است. در حالت پیش‌فرض، بررسی کارهای موعدرسیده با بارگذاری صفحات آغاز می‌شود؛ پس زمان تعیین‌شده الزاماً زمان دقیق اجرا نیست. در سایت کم بازدید، شروع کار می‌تواند عقب بیفتد. اجرای زمان‌بندی‌شده از سمت سرور، وابستگی شروع اجرا به بازدید را کاهش می‌دهد، اما خطای خود کار را برطرف نمی‌کند.
Action Scheduler کتابخانهٔ صف کارهای پس‌زمینه است که در ووکامرس و افزونه‌های آن استفاده می‌شود. این ابزار وضعیت و سابقهٔ اجرای کارها را قابل پیگیری می‌کند. صف، روش شروع پردازش و تابعی که کار را انجام می‌دهد لایه‌های متفاوت‌اند: ممکن است صف سالم باشد، اما ارتباط با سامانهٔ مقصد شکست بخورد. هر کار زمان‌بندی‌شدهٔ وردپرس نیز الزاماً در Action Scheduler ثبت نشده است.
پیش از تغییر تنظیمات، این اطلاعات را ثبت کنید
- کدام قابلیت عقب افتاده و آخرین خروجی درست آن چه زمانی ثبت شده است؟
- کار مربوط به کدام افزونه و نام عملیات یا hook است؟
- زمان سررسید و منطقهٔ زمانی نمایش‌داده‌شده چیست؟
- وضعیت کار چیست و آخرین گزارش اجرا چه می‌گوید؟
- در همان زمان، خطای PHP، محدودیت منابع یا قطع ارتباط مقصد ثبت شده است؟
- آیا مشکل بعد از به‌روزرسانی، تغییر هاست یا تغییر دسترسی API شروع شده است؟
در نصب‌های متداول ووکامرس، بخش Scheduled Actions از مسیر «ووکامرس ← وضعیت ← عملیات زمان‌بندی‌شده» قابل بررسی است؛ عنوان منو با نسخه و زبان ممکن است متفاوت باشد. عملیات را بر اساس وضعیت، نام hook و گروه مربوط محدود کنید. از ارسال تصویر گزارش دارای اطلاعات مشتری یا کلید دسترسی در پیام عمومی خودداری کنید؛ نام عملیات، زمان و پیام خطای پاک‌سازی‌شده برای بررسی اولیه مفید است.
وضعیت صف را چگونه تفسیر کنیم؟
| مشاهده | برداشت اولیه | بررسی بعدی |
|---|---|---|
| Pending با زمان آینده | ممکن است انتظار طبیعی باشد. | زمان و منطقهٔ زمانی را کنترل کنید. |
| Pending موعدگذشته و رو به افزایش | شروع یا ظرفیت پردازش نیاز به بررسی دارد. | مسیر اجرا، منابع و سن قدیمی‌ترین کار را بررسی کنید. |
| Failed برای یک عملیات مشخص | گزارش همان کار سرنخ اصلی است. | خطای تابع، داده و پاسخ مقصد را کنار هم ببینید. |
| In-progress طولانی | عملیات طولانی یا توقف احتمالی مطرح است. | زمان شروع و گزارش‌های PHP و مقصد را تطبیق دهید. |
| Complete ولی خروجی مقصد غایب | اتمام تابع با صحت نتیجهٔ کسب‌وکار یکسان نیست. | شناسهٔ مقصد و قواعد ثبت نتیجه را بررسی کنید. |
این جدول مسیر بررسی پیشنهاد می‌کند و تشخیص قطعی نیست. یک عکس از تعداد صف کافی نیست؛ دو یا چند مشاهده در یک بازهٔ متناسب با عملیات نشان می‌دهد صف واقعاً تخلیه می‌شود یا کارهای جدید سریع‌تر از ظرفیت اجرا ساخته می‌شوند.
۱. آیا مسیر شروع اجرا فعال است؟
اگر WP-Cron غیرفعال شده، مسئول سرور باید وجود و موفقیت مسیر جایگزین را بررسی کند. تنظیم DISABLE_WP_CRON بدون اجرای جایگزین می‌تواند کارهای وابسته به آن را عقب بیندازد. صرف وجود یک cron job در پنل هاست کافی نیست: زمان اجرای واقعی، پاسخ فرمان، مسیر صحیح سایت و خطاهای آن باید دیده شود. انتخاب فاصلهٔ اجرا به حساسیت کار و ظرفیت هاست بستگی دارد؛ یک فاصلهٔ ثابت برای همهٔ فروشگاه‌ها مناسب نیست.
۲. آیا پردازش شروع می‌شود اما ظرفیت کافی ندارد؟
وقتی زمان سررسید مرتب عقب می‌ماند، نرخ ایجاد و پایان کارها را برای عملیات مربوط مقایسه کنید. برای نمونه، یک اتصال ممکن است برای هر تغییر کالا چند کار مشابه بسازد. کوتاه‌کردن فاصلهٔ اجرای صف، علت تولید کارهای زائد را حل نمی‌کند. ابتدا تعداد کارها، زمان اجرای هر دسته، محدودیت PHP و پاسخ سرویس مقصد را اندازه بگیرید؛ سپس دربارهٔ دسته‌بندی یا تغییر روش اجرا تصمیم بگیرید.
Action Scheduler ابزار اجرای صف با WP-CLI هم دارد. این مسیر برای بعضی بارهای کاری کنترل بیشتری می‌دهد، اما نیازمند تنظیم سرور و بررسی ترتیب و وابستگی عملیات است. اجرای جداگانهٔ گروه‌ها یا افزایش هم‌زمانی باید با قواعد واقعی پروژه تطبیق داده شود؛ سرعت بیشتر اگر باعث رقابت روی یک سفارش یا عبور از محدودیت API شود، نتیجهٔ بهتری نمی‌دهد.
۳. آیا خود عملیات یا مقصد خطا می‌دهد؟
اگر شروع کار در گزارش ثبت شده و سپس خطا آمده است، همان خطا را دنبال کنید. خطای دسترسی API، دادهٔ ناقص، تغییر قالب پاسخ یا timeout هرکدام اصلاح متفاوتی می‌خواهند. برای یک کار مشخص، شناسهٔ سفارش یا کالا را با گزارش مقصد تطبیق دهید. نتیجهٔ مبهم، مثل قطع ارتباط بعد از ارسال درخواست، باید پیش از تلاش مجدد از نظر احتمال ثبت قبلی در مقصد بررسی شود.
اجرای دستی و تلاش مجدد چه زمانی مناسب است؟
پیش از اجرای دوباره، معلوم کنید اثر قبلی وجود دارد یا نه و افزونه چه سازوکاری برای جلوگیری از ثبت تکراری دارد. آزمون یک نمونهٔ کنترل‌شده، با ثبت ورودی و خروجی، از اجرای دسته‌جمعی قابل بررسی‌تر است. برای عملیات مالی یا موجودی، کلید پایدار و روش تطبیق مقصد را در شرح نیاز افزونه مشخص کنید. نمی‌توان از وجود صف نتیجه گرفت هر کار ناموفق خودکار و با سیاست درست دوباره اجرا می‌شود؛ سیاست تلاش مجدد باید برای همان عملیات طراحی و آزموده شود.
حذف کارهای Failed فقط نشانه را از فهرست پاک می‌کند و ممکن است امکان پیگیری را از بین ببرد. پیش از پاک‌سازی، اثر عملیات، نیاز به جبران و سیاست نگهداری گزارش روشن شود. همچنین اجرای دستی یک کار موفق، اثبات نمی‌کند مسیر اجرای خودکار درست شده است؛ نوبت خودکار بعدی باید جدا مشاهده شود.
مثال فرضی: سفارش ثبت شده، انبار هنوز خبر ندارد
فرض کنید اتصال اختصاصی پس از پرداخت، یک کار برای ارسال سفارش به انبار می‌سازد. کار سر موعد شروع می‌شود، اما گزارش timeout دارد. ابتدا با شناسهٔ سفارش بررسی می‌شود که انبار قبلاً آن را ثبت کرده یا نه. اگر ثبت شده باشد، اتصال باید شناسهٔ مقصد را بازیابی و وضعیت محلی را اصلاح کند؛ اگر ثبت نشده باشد، ارسال دوباره طبق قاعدهٔ تکرار امن انجام می‌شود. اگر API مقصد امکان جست‌وجو یا جلوگیری از تکرار ندارد، مسیر رسیدگی انسانی باید مشخص شود.
آزمون پذیرش این سناریو شامل قطع ارتباط، ارسال مجدد و بررسی تعداد ثبت‌های مقصد است. این مثال فرضی است و قابلیت API خاص یا نتیجهٔ یک پروژهٔ واقعی را ادعا نمی‌کند. برای انتخاب مسیر دریافت رویداد، مقایسهٔ وبهوک و API دوره‌ای و برای قواعد موجودی، راهنمای اتصال انبار را بخوانید.
برای افزونهٔ اختصاصی چه معیارهایی سفارش دهیم؟
- تأخیر قابل قبول هر عملیات و روش اندازه‌گیری آن معلوم باشد.
- کار با شناسهٔ سفارش یا کالا و شناسهٔ مقصد قابل پیگیری باشد.
- خطای موقت و دادهٔ نامعتبر مسیر رسیدگی مشخص داشته باشند.
- تلاش مجدد محدود، قابل ثبت و در برابر تکرار آزموده شود.
- برای صف عقب‌مانده، مسئول هشدار و روش جبران تعیین شود.
- در آزمون تحویل، اجرای خودکار و نتیجهٔ واقعی مقصد هر دو بررسی شوند.
این موارد را به شرح نیاز پروژه اضافه کنید و در چک‌لیست تحویل افزونه ثبت کنید. پایش صف هم می‌تواند بخشی از برنامهٔ نگهداری افزونه باشد.
منابع و تاریخ بازبینی
مستندات زیر در ۲۰۲۶/۰۹/۳۰ بررسی شدند. جزئیات روش اجرای صف به نسخه و تنظیمات نصب بستگی دارد؛ چک‌لیست تشخیص و مثال مقاله پیشنهاد عملی برای بررسی پروژه‌اند.