تعطيل WP-Cron واستخدام cron الخاص بالنظام

ما هو wp-cron، ولماذا يستبدله cron الخاص بالنظام

WP-Cron هو مجدول المهام المضمّن في WordPress، ولا يعمل إلا عندما يطلب أحدهم صفحة. لا يوجد شيء داخل WordPress يوقظه تلقائياً. عند كل طلب لا يُخدَم من ذاكرة التخزين المؤقت، يقرأ WordPress قائمة المهام المجدولة. وإذا حان موعد إحدى المهام، يرسل طلب HTTP ثانياً إلى نفسه على /wp-cron.php لتنفيذها. يمنحك نقل هذه المهمة إلى cron الخاص بالنظام تشغيلاً واحداً يمكن التنبؤ به وفق جدول زمني ثابت، سواء زار الموقع ألف مستخدم في تلك الدقيقة أم لم يزره أحد.

ينفّذ العمل الفعلي سطران: ثابت في wp-config.php، وإدخال في crontab. أما كل ما تبقى في هذا الدليل، فيتناول الأمور التي لا يوضحها هذان السطران. أي مستخدم يجب أن يشغّل المهمة، وكيف تثبت أن الأحداث المجدولة نُفّذت فعلاً، والطرق الثلاث التي يفشل بها الإعداد من دون عرض أي شيء على الموقع.

تستخدم الأمثلة /srv/www/example.com بصفته مجلد WordPress، وwww-data بصفته مستخدم خادم الويب. استبدل المسارات والمستخدم بمساراتك ومستخدمك في كل موضع.

ما الزائر الذي تسبب في تكاليف cron على موقع مزدحم

تدفع كل مطالبة غير موجودة في ذاكرة التخزين المؤقت تكلفة التحقق. يحمّل WordPress الخيار cron، ويقارن الطوابع الزمنية، وعندما يحين موعد مهمة ما يستدعي spawn_cron()، الذي يرسل مطالبة loopback غير حاجبة إلى /wp-cron.php. لا ينتظر الزائر النتيجة. لكن أحد عمال PHP ينتظرها. على VPS صغير يشغّل PHP-FPM مع pm.max_children = 5، تشغل مهمة مجدولة بطيئة خُمس سعة PHP لديك طوال المدة التي تحتاج إليها، ومن المرجح جداً أن تُشغَّل خلال أكثر دقائقك ازدحاماً، لأن عدد تحميلات الصفحات يكون عندها في أعلى مستوى.

يحد WordPress من التكرارات. إذ يحصل على قفل يدوم WP_CRON_LOCK_TIMEOUT، أي 60 ثانية افتراضياً، حتى لا يبدأ الزوار المتزامنون تشغيل المهمة كلٌّ منهم. يحد القفل من التكرار. لكنه لا ينقل العمل خارج مسار الطلب.

احسب عدد مرات تشغيلها على خادمك قبل أن تقرر مدى أهميتها. تظهر كل مطالبة loopback في سجل وصول خادم الويب:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

يكتب Apache السجل في /var/log/apache2/access.log بدلاً من ذلك. ويمثل عدد بالآلاف يومياً تكلفة فعلية. وهذا نوع الأرقام الذي ينبغي أن تقيسه على خادمك، لا أن تقرأه في مقال، بالطريقة نفسها التي ستتبعها عند إجراء اختبار أداء لـVPS قبل أي تغيير آخر وبعده.

يغيّر التخزين المؤقت الصورة. إذا قدّمت ذاكرة التخزين المؤقت للصفحات معظم المطالبات بصيغة HTML ثابتة، فلن يعمل PHP لهذه المطالبات، ولذلك لن يحدث فحص cron. يبدأ الموقع المزدحم ذو التخزين المؤقت الفعّال في التصرف مثل الموقع الهادئ أدناه.

ما الزائر الذي شغّل مهام cron في موقع هادئ؟

لا يوجد زوار، فلا تُشغَّل مهام cron. الموقع الذي يستقبل عدداً قليلاً من الزيارات يومياً يشغّل مهامه المجدولة عدداً مماثلاً من المرات يومياً، وفي أوقات عشوائية تحددها لحظة وصول تلك الزيارات.

تتشابه الأعراض جميعاً. يبقى منشور مجدول عند الساعة 09:00 في قائمة المنشورات مع وضع علامة Missed schedule عليه، إلى أن يحمّل أحدهم صفحة. وتتخطى إضافات النسخ الاحتياطي مهام الليل. وتتأخر عمليات التحقق من التحديثات، لذلك لا تعرض لوحة التحكم أي تحديثات، رغم صدور تحديث أمني بالفعل. وتُرسَل رسائل الطلبات وإشعارات التجديد وتحذيرات الانتهاء متأخرة.

لا يسجّل أي من ذلك خطأً. فمن منظور WordPress، لم تتأخر المهمة، لأنها لم تبدأ أصلاً.

الخطوة 1: عطّل مُشغِّل الزوار في wp-config.php

افتح /srv/www/example.com/wp-config.php وأضف الثابت:

define( 'DISABLE_WP_CRON', true );

ضعه فوق السطر الذي يحتوي على /* That's all, stop editing! Happy publishing. */، لأن السطر الموجود أسفل ذلك التعليق يتطلب wp-settings.php، وفي wp-settings.php يربط WordPress فحص cron بـ init. إذا عرّفت الثابت بعد ذلك السطر، فسيكون تعريفه متأخراً ولن يغيّر شيئاً، رغم أن الملف سيبدو صحيحاً بينما يستمر المُشغِّل في العمل.

تأكد من أن السطر موجود في الموضع المتوقع:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

لا يوقف هذا الثابت جدولة الأحداث. ستواصل الإضافات إضافة المهام إلى قائمة الانتظار كما في السابق تماماً. لكنه يوقف فقط تشغيل قائمة الانتظار عند تحميل الصفحات، وهذا يعني أن قائمة الانتظار لن تعمل إطلاقاً حتى تُكمل الخطوة 3.

كما أنه لا يمنع الطلبات المباشرة إلى /wp-cron.php. لا يزال بإمكان أي شخص طلب عنوان URL هذا، وهذا لا يسبب عادةً مشكلة لأن الملف يشغّل فقط المهام المستحقة. حظر هذا العنوان في إعدادات خادم الويب اختياري. إذا حظرته، فسيتوقف أيضاً البديل curl الموجود قرب نهاية هذا الدليل عن العمل.

الخطوة 2: تثبيت WP-CLI

WP-CLI هي أداة سطر الأوامر الرسمية الخاصة بـ WordPress. تحتاج إلى الملف التنفيذي لـPHP الخاص بسطر الأوامر، وهو حزمة منفصلة عن وحدة PHP الخاصة بخادم الويب.

php -v
sudo apt install -y php-cli

ثبّت WP-CLI من إصدار phar، فهذا ما يوصي به دليل التثبيت الرسمي:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

يطبع php wp-cli.phar --info مسار الملف التنفيذي لـPHP، وإصدار PHP، وإصدار WP-CLI. إذا طبع القيم الثلاث، فإن phar يعمل. اعتباراً من أغسطس 2026، يحدد دليل التثبيت PHP 7.2.24 كحد أدنى، بينما يأتي Ubuntu 24.04 مع PHP 8.3، لذلك يتجاوز خادم حديث هذا الحد بفارق واضح. حدّثه لاحقاً باستخدام sudo wp cli update.

شغّل WP-CLI كمستخدم الموقع، ولا تشغّله مطلقاً كـroot:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

عند تشغيله كـroot، يرفض WP-CLI البدء:

Error: YIKES! It looks like you're running this as root.

ويقترح --allow-root. لا تستخدم ذلك هنا. يوضّح نمط الفشل الأول أدناه السبب.

لاحظ أيضاً أن sudo -u www-data -i لا يعمل، لأن shell تسجيل الدخول لذلك الحساب هو /usr/sbin/nologin، وستحصل على This account is currently not available.. يؤدي تمرير الأمر مباشرة إلى sudo -u إلى تجاوز shell تسجيل الدخول، ولذلك يعمل الأمر بشكل صحيح.

تحقق الآن من أن WordPress نفسه يقرأ الثابت من الخطوة 1:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

يطبع ذلك bool(true). يشير الخطأ الفادح المتعلق بثابت غير معرّف إلى أن السطر define() لم يُنفّذ، وهذا يعني عادةً أنه وُضع بعد السطر require.

الخطوة 3: أضف إدخال cron باستخدام المستخدم الصحيح

المستخدم الصحيح هو الذي يملك الملفات التي يكتب فيها PHP. تحقّق من الطرفين:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

في تثبيت Ubuntu الافتراضي، تكون الإجابتان www-data. إذا أنشأت تجمع PHP-FPM خاصاً بالموقع باستخدام مستخدم خاص به، وهو الوضع المعتاد عند إعداد حزمة LAMP على Ubuntu 24.04 لكل موقع، فاستخدم ذلك المستخدم في كل ما يلي.

أنشئ دليلاً للسجلات يمكن لذلك المستخدم الكتابة فيه:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

حرّر crontab لذلك المستخدم:

sudo crontab -u www-data -e

أضف سطراً واحداً:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

تفصيلاً. يشغّل */5 المهمة كل خمس دقائق. ينشئ flock -n ملف قفل ويتوقف فوراً إذا كانت عملية سابقة لا تزال تحتفظ به. يمثّل /usr/local/bin/wp المسار المطلق الذي يحتاج إليه cron. يتيح --path تشغيل الأمر من أي دليل عمل. يشغّل --due-now الأحداث التي حان وقتها فقط، بدلاً من تشغيل كل حدث في قائمة الانتظار. يرسل redirect المخرجات العادية والأخطاء إلى ملف واحد يمكنك قراءته.

هذا الـredirect ليس اختيارياً عملياً. يرسل cron مخرجات المهمة إلى مستخدمها عبر البريد، لكن معظم صور VPS لا تحتوي على mail transfer agent مثبت، ثم يسجّل cron (CRON) info (No MTA installed, discarding output) ويتخلص من المخرجات. يحافظ الملف على الأدلة.

تحقّق من حفظ الملف:

sudo crontab -u www-data -l

بالنسبة إلى عدة مواقع، استخدم سطراً لكل موقع مع توزيع الدقائق حتى لا تبدأ جميعها في الوقت نفسه:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

يكبر السجل بلا نهاية ما لم تدوّره. اكتب /etc/logrotate.d/wp-cron:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

تحقّق من صحة تحليله من دون تنفيذ أي شيء: sudo logrotate --debug /etc/logrotate.d/wp-cron.

الخطوة 4: تأكد من تنفيذ الأحداث المجدولة فعلاً

لا يثبت نجاح حفظ سطر crontab شيئاً. ابدأ بأقل الفحوص تكلفة، ثم انتقل إلى الفحص الذي يحسم الأمر فعلياً.

أولاً، هل شغّل cron الأمر؟ يكتب cron سجلاته في journal ضمن وحدته الخاصة:

journalctl -u cron.service --since "15 min ago" | grep wp

يبدو الإدخال السليم كما يلي، بعد حذف الطابع الزمني واسم المضيف من بدايته:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

يعني هذا السطر أن cron شغّل أمرك بصفة www-data. ولا يوضح ما إذا كان الأمر قد نجح.

ثانياً، هل نفّذ WordPress أي شيء؟ اقرأ ملف السجل:

sudo tail -n 20 /var/log/wp-cron/example.log

يطبع WP-CLI سطراً واحداً لكل حدث، ثم يطبع الإجمالي:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

تُكتب الأخطاء في الملف نفسه، وهذا هو الغرض من 2>&1. لن تكون هناك أحداث مستحقة في معظم عمليات التشغيل، ولذلك سيُكتب القليل جداً في الملف. اقرأ الملف بعد عملية تشغيل تعرف مسبقاً أن لديها عملاً بانتظار التنفيذ.

ثالثاً، أثبت التنفيذ من البداية إلى النهاية. جدْول حدثاً مؤشراً، وراقب اختفاءه:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

انتظر فترة زمنية واحدة، ثم شغّل أمر القائمة مرة أخرى. يختفي الـhook لأن الحدث الذي يُنفَّذ مرة واحدة يُزال من قائمة الانتظار عند تشغيله. لا يسجّل أي plugin دالة callback على اسم ذلك الـhook، لذلك لا يؤدي تشغيله إلى أي إجراء آخر في الموقع. إذا ظل الـhook مدرجاً بعد فترتين زمنيتين، فهذا يعني أن قائمة الانتظار لا تُشغَّل. ويحدد الفحصان الأولان ما إذا كانت المشكلة في cron أو WP-CLI.

لا تستخدم wp cron test لهذا الغرض. يتحقق ذلك الأمر مما إذا كان إنشاء العمليات الذي يطلقه الزائر يعمل، ويُظهر خطأ عندما تكون DISABLE_WP_CRON صحيحة. في الخادم المُعدّ إعداداً صحيحاً، يكون الخطأ هو الناتج المتوقع، وليس عطلاً.

بديل مؤقت systemd

إذا كانت الأعمال المجدولة الأخرى على الخادم تعمل بالفعل بصيغة خدمات ومؤقتات systemd، فأضف WordPress إليها أيضاً. عندئذٍ يظهر كل تشغيل في systemctl list-timers، ويُرسل الناتج إلى السجل بدلاً من ملف تحتاج إلى تدويره.

اكتب /etc/systemd/system/wp-cron-example.service:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

ثم /etc/systemd/system/wp-cron-example.timer:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

لن يشغّل systemd نسختين من الخدمة نفسها في الوقت ذاته، لذلك لا يحتاج هذا الإصدار إلى flock. ويجعل Persistent=true الخدمة تلحق بالتشغيل الذي فات أثناء إيقاف تشغيل الجهاز، وهو ما لا يستطيع إدخال crontab فعله.

اختر crontab أو المؤقت. يؤدي تشغيل كليهما للموقع نفسه إلى تفريغ قائمة الانتظار مرتين، وستظهر عمليات التشغيل المكررة لمهمة البريد الإلكتروني أو الطلبات لعملائك.

لماذا يجب ألا تعمل مهمة cron بحساب root

هذه أولى الطرق الثلاث التي يفشل بها الإعداد. إذا أضفت المهمة إلى crontab الخاص بـ root، يتوقف WP-CLI قبل تنفيذ أي إجراء:

Error: YIKES! It looks like you're running this as root.

لا تعمل قائمة الانتظار أبداً. وإذا لم تكن قد أعدت توجيه المخرجات، فلن ترى الرسالة. الحل الخطير هو إضافة --allow-root، لأن كل ملف يكتبه أحد الإضافات أثناء تلك التشغيلية سيصبح مملوكاً لـ root. وسيعمل طلب الويب التالي بحساب www-data، ولن يتمكن من الكتابة إلى تلك المجلدات. عندها يبدأ الموقع في عرض رسائل مثل:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

أصلح الملكية، ثم انقل المهمة:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

إن crontab الخاص بـ root وcrontab الخاص بـ www-data ملفان منفصلان، لذلك لا يؤدي حذف السطر من أحدهما إلى تعديل الآخر. تحقّق من كليهما:

sudo crontab -u root -l
sudo crontab -u www-data -l

لماذا يعرض cron wp: not found

هذا هو الفشل الثاني. يمنح cron مهام المستخدم قيمة PATH قصيرة جداً، /usr/bin:/bin. يُثبَّت WP-CLI في /usr/local/bin، وهذا المسار غير موجود في تلك القائمة. تبدأ المهمة، ثم تفشل خلال جزء من الثانية، ولا يحتوي السجل إلا على سطر واحد:

/bin/sh: 1: wp: not found

اعرض بيئة cron بنفسك بدلاً من التخمين. أضف سطراً مؤقتاً:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

اقرأ /tmp/cron-env.txt بعد مرور فترة واحدة، ثم احذف السطر. قيمة PATH= في ذلك الملف هي بالضبط القيمة التي تحصل عليها مهمتك.

هناك حلّان. استخدم المسار المطلق /usr/local/bin/wp، كما في الخطوة 3. أو اضبط PATH مرة واحدة في أعلى crontab، فوق كل سطر مهمة:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

توجد المشكلة نفسها على مستوى أدنى. يبدأ ملف phar wp بـ #!/usr/bin/env php، لذلك يجب أن يتمكن shell من العثور على php أيضاً. إذا كان PHP موجوداً خارج /usr/bin، كما يحدث مع الإصدارات المخصّصة وإصدارات لوحات التحكم، فستحصل على:

/usr/bin/env: 'php': No such file or directory

استدعِ المفسّر صراحةً في هذه الحالة، مثل /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

لماذا يعيد الفاصل الزمني البالغ دقيقة واحدة إنشاء المشكلة الأصلية

هذا هو الفشل الثالث. يبدو * * * * * أكثر أماناً من خمس دقائق، لكنه يعيدك إلى نقطة البداية في المواقع المزدحمة. إذا استغرق أحد التنفيذات وقتاً أطول من الفاصل الزمني، يبدأ التنفيذ التالي بينما لا يزال الأول قيد التشغيل. بعد عشر دقائق، تصبح هناك عشر عمليات PHP، ولكل منها ذاكرتها الخاصة واتصالها الخاص بقاعدة البيانات.

ابحث عن التراكم مباشرةً:

ps -eo etimes,user,args | grep '[c]ron event run'

يمثل etimes عمر العملية بالثواني. يكون السطر الواحد طبيعياً. أما ظهور عدة أسطر بأعمار تتجاوز الفاصل الزمني بكثير فيعني أن التنفيذات تتراكم. وفي VPS صغير، ينتهي ذلك بخطأ Too many connections من MySQL، أو بإنهاء النواة لعملية PHP لاستعادة الذاكرة. يمكنك تأكيد ذلك باستخدام sudo dmesg -T | grep -i 'killed process'.

يشغّل WP-CLI عمليات callback للأحداث مباشرةً بدلاً من طلب wp-cron.php، ولذلك لا ينطبق قفل WordPress البالغ 60 ثانية، والمستخدم لمنع إنشاء عمليات مكررة، هنا. ما يمنع التداخل الآن هو flock -n في إدخال الخطوة 3. يخرج التنفيذ الذي جرى تخطيه فوراً وبصمت، حسب التصميم.

اختر الفاصل الزمني استناداً إلى أقصر جدول تعتمد عليه فعلياً، وقِس مدة التنفيذ أولاً:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

تُعد خمس دقائق قيمة افتراضية مناسبة: تُنشر التدوينة المجدولة في 09:00 بحلول 09:05. ويُعد 15 دقيقة مناسباً لموقع لا يحتوي على مهام حساسة للوقت. أما دقيقة واحدة فتناسب المتاجر والإضافات المعتمدة فعلياً على قوائم الانتظار، وفقط بعد التأكد من أن التنفيذ يكتمل خلال بضع ثوانٍ.

إذا تعذر عليك تثبيت WP-CLI

تحظر بعض الاستضافات أدوات shell. يرسل طلب HTTP عادي إلى wp-cron.php المهام نفسها، لكنه يمر عبر طبقة الويب كاملة:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

ما ستفقده بوضوح:

• يقيّد خادم الويب وPHP-FPM مدة الطلب، لذلك قد تُقطع مهمة طويلة في منتصف تنفيذها.
• يجب أن تكون الشهادة صالحة، وإلا يتوقف curl مع ظهور SSL certificate problem. لذلك حافظ على عمل التجديدات باستخدام Certbot على nginx.
• يجب ألا تخزّن ذاكرة التخزين المؤقت للصفحات wp-cron.php، وإلا ستحصل طلبات cron على استجابة مخزنة مؤقتاً ولن يُنفَّذ شيء.
• لا تحصل على مخرجات لكل حدث، لذلك يكون الأثر الذي خلّفته المهمة هو الدليل الوحيد على تشغيلها.

يجعل -sS curl صامتاً عند النجاح، مع الاستمرار في طباعة الأخطاء، وهذا هو السلوك المطلوب في مهمة cron.

ما الذي ينبغي إدراجه أيضاً في جدول مهام الخادم

بعد أن يتولى cron النظامي قائمة انتظار WordPress، ضع بقية المهام الدورية للخادم في المكان نفسه، حيث يمكنك رؤيتها. يجب أن تتولى الترقيات غير المتزامنة تصحيحات أمان نظام التشغيل، بدلاً من إدارتها عبر سطر cron تصونه يدوياً. أما تحديثات إضافات WordPress وقوالبه فهي قرار مختلف: سيعمل wp plugin update --all في crontab على تعطيل موقع حي بسهولة عند الساعة 3 صباحاً من دون أن يراقبه أحد، لذلك نفّذ هذه التحديثات عمداً، أو بعد مرحلة تجريبية ومع أخذ نسخة احتياطية.

FAQ

هل يؤدي تعطيل WP-Cron إلى إيقاف نشر المنشورات المجدولة؟

لا، ما دام هناك شيء آخر يشغّل قائمة الانتظار. لا يؤدي DISABLE_WP_CRON إلا إلى منع تحميل الصفحات من تشغيل قائمة الانتظار. وتبقى الأحداث مجدولة كما كانت تماماً. تُنشر المشاركة المحدد لها الوقت 09:00 في أول تشغيل لـ cron بعد 09:00، لذلك ينشرها الفاصل الزمني البالغ خمس دقائق بحلول 09:05. إذا عيّنت الثابت ولم تضف إدخال cron، فتبقى المشاركة في القائمة مع وسم Missed schedule إلى أن يشغّل شيء ما قائمة الانتظار.

أي مستخدم يجب أن يشغّل مهمة cron الخاصة بـ WordPress؟

المستخدم الذي يملك الملفات التي يكتب فيها PHP، وهو www-data في تثبيت Ubuntu الافتراضي. تحقّق باستخدام stat -c '%U %G' /srv/www/example.com/wp-content/uploads وقارن النتيجة بسطر user = في إعدادات مجموعة PHP-FPM. يؤدي تشغيل المهمة بصلاحيات root إلى إيقاف WP-CLI مع خطأ YIKES، بينما يؤدي فرض تشغيلها باستخدام --allow-root إلى إنشاء ملفات مملوكة لـ root داخل wp-content، ولا يستطيع خادم الويب الكتابة فيها بعد ذلك.

كم مرة يجب أن يشغّل system cron مهمة cron الخاصة بـ WordPress؟

كل خمس دقائق تناسب معظم المواقع. طابق الفاصل الزمني مع أقصر جدول تعتمد عليه فعلياً، واجعله أطول بهامش مريح من المدة التي يستغرقها تشغيل واحد، ويمكنك قياس ذلك بوضع time قبل أمر WP-CLI. تؤدي الفواصل الزمنية التي تبلغ دقيقة واحدة إلى تراكب عمليات التشغيل في المواقع المزدحمة، ما لم يحْمِها flock.

لماذا يفشل wp cron test بعد تعطيل WP-Cron؟

لأن هذا الأمر يختبر تشغيل المهام الناتج عن زيارات المستخدمين، ويبلّغ عن خطأ عندما تكون قيمة DISABLE_WP_CRON مضبوطة على true. هذه هي النتيجة الصحيحة على خادم مُعدّ بهذه الطريقة. افحص مسار system cron بدلاً من ذلك: اقرأ /var/log/wp-cron/example.log، أو جدولة حدث بعلامة باستخدام wp cron event schedule، وتأكد من اختفائه من wp cron event list بعد التشغيل التالي.

هل أحتاج إلى WP-CLI، أم يكفي استخدام curl مع wp-cron.php؟

يعمل curl، وهو الخيار المناسب عندما لا يمكنك تثبيت WP-CLI. لكنه أبطأ لأنه يحمّل WordPress عبر خادم الويب، كما أنه مقيّد بمهلة الطلب. يشغّل WP-CLI الأحداث ضمن عملية PHP من سطر الأوامر من دون مهلة ويب، ويطبع سطراً واحداً لكل حدث مع مدته، لذلك يوضح السجل بالضبط ما الذي تم تشغيله والمدة التي استغرقها.