איך לבטל wp-cron ולהפעיל משימות דרך system cron

מהו wp-cron ומדוע system cron מחליף אותו

WP-Cron הוא מתזמן המשימות המובנה ב־WordPress, והוא פועל רק כאשר מישהו מבקש דף. שום רכיב בתוך WordPress אינו מעיר אותו באופן עצמאי. בכל בקשה שאינה מוגשת ממטמון, WordPress קורא רשימה של משימות מתוזמנות, ואם אחת מהן הגיעה למועד הביצוע, הוא שולח בקשת HTTP שנייה לעצמו אל /wp-cron.php כדי לבצע את המשימה. העברת המשימה אל system 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 לפני שינוי אחריו.

שמירה במטמון משנה את התמונה. אם page cache מגיש את רוב הבקשות כ־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. קבוע שמוגדר אחרי פקודת ה־require הזו מוגדר מאוחר מדי, ולכן אינו משנה דבר. הקובץ ייראה תקין, אך הטריגר ימשיך לפעול.

ודאו שהשורה נמצאת במקום הצפוי:

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 build, כפי שממליך מדריך ההתקנה הרשמי:

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 פועל. נכון ל־August 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 אינו פועל, משום ש־login shell של החשבון הוא /usr/sbin/nologin ומתקבלת השגיאה This account is currently not available. העברת הפקודה ישירות ל־sudo -u עוקפת את ה־login 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 מפעיל רק אירועים שהגיע מועד ההפעלה שלהם, במקום את כל האירועים שבתור. ההפניה כותבת את הפלט הרגיל ואת השגיאות לאותו קובץ, שאפשר לקרוא ממנו את התוצאות.

בפועל, ההפניה הזו אינה אפשרות. cron שולח את הפלט של משימה למשתמש שלה בדואר, ברוב תמונות ה־VPS לא מותקן סוכן להעברת דואר, ואז 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.

אימות שהאירועים המתוזמנים אכן הופעלו

שורת 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 נעלם, משום שאירוע חד־פעמי מוסר מהתור לאחר הפעלתו. שום תוסף אינו רושם callback בשם ה־hook הזה, ולכן הפעלתו אינה מבצעת פעולה נוספת באתר. אם ה־hook עדיין מופיע לאחר שני מרווחי זמן, התור אינו מעובד. שתי הבדיקות הראשונות יראו לכם אם הבעיה היא ב־cron או ב־WP-CLI.

אל תשתמשו ב־wp cron test לצורך הבדיקה הזו. פקודה זו בודקת אם הפעלה על ידי מבקר פועלת, והיא מחזירה שגיאה כאשר DISABLE_WP_CRON הוא true. בשרת שהוגדר כראוי, השגיאה היא הפלט הצפוי ולא תקלה.

החלופה של systemd timer

אם שאר המשימות המתוזמנות בשרת כבר מופעלות באמצעות שירותים ו־timers של systemd, הוסיפו גם את WordPress לשם. כל הרצה תופיע לאחר מכן ב־systemctl list-timers, והפלט יישלח ל־journal במקום לקובץ שעליכם לבצע לו סבב.

כתבו את /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 או ב־timer. הפעלה של שניהם מול אותו אתר גורמת לריקון התור פעמיים, והרצות כפולות של משימת דוא״ל או הזמנה יהיו גלויות ללקוחות שלכם.

מדוע משימת 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, או בכך שה־kernel מחסל את PHP כדי לפנות זיכרון. אפשר לאשר זאת באמצעות sudo dmesg -T | grep -i 'killed process'.

WP-CLI מפעיל ישירות את ה־callbacks של האירועים, במקום לבקש wp-cron.php. לכן נעילת 60 השניות ש־WordPress משתמש בה כדי למנוע יצירה כפולה של תהליכים אינה חלה כאן. flock -n ברשומה של שלב 3 הוא שמונע כעת חפיפה בין הרצות. הרצה שדולגה מסתיימת מיד ובשקט, בהתאם לתכנון. חפיפה היא בעיה שעליכם לפתור ב־crontab, ולא בעיה שה־kernel של השרת פותר עבורכם. אפילו שיבוץ משימות מודע ל־cache שנוסף ב־Linux kernel 7.2 קובע רק באיזו ליבה התהליך יפעל, ולא כמה תהליכים כאלה הפעלתם.

בחרו את המרווח לפי לוח הזמנים הקצר ביותר שאתם באמת תלויים בו, ומדדו תחילה הרצה אחת:

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

חמש דקות הן ברירת מחדל סבירה: פוסט שתוזמן לשעה 09:00 יתפרסם עד 09:05. חמש עשרה דקות מתאימות לאתר שאין בו דבר קריטי מבחינת זמן. מרווח של דקה אחת מתאים לחנויות ולתוספים מונעי־תור שבאמת זקוקים לכך, ורק לאחר שווידאתם שההרצה מסתיימת בתוך כמה שניות.

אם אינכם יכולים להתקין את WP-CLI

חלק מספקי האירוח חוסמים כלי shell. בקשת HTTP רגילה אל wp-cron.php מפעילה את אותו תור, אך דרך כל מחסנית ה־Web:

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

על מה מוותרים, באופן ברור:

• ההרצה מוגבלת לפי פסקי הזמן של שרת ה־Web ושל PHP-FPM, ולכן משימה ארוכה עלולה להיפסק באמצע.
• האישור חייב להיות תקף, אחרת curl נעצר עם SSL certificate problem. לכן חשוב לוודא שחידושי האישורים באמצעות Certbot ב־nginx ממשיכים לפעול.
• מטמון הדפים אינו יכול לשמור במטמון את wp-cron.php, אחרת בקשות cron יקבלו תגובה מהמטמון ושום דבר לא יורץ.
• לא מתקבל פלט נפרד לכל אירוע, ולכן הראיה היחידה לכך שמשימה רצה היא ההשפעה שלה.

-sS משאיר את curl שקט במקרה של הצלחה, אך עדיין מדפיס שגיאות. זהו ההתנהגות הרצויה במשימת cron.

מה עוד צריך להיכלל בלוח הזמנים של השרת

לאחר ש־system cron מנהל את התור של WordPress, השאירו את שאר משימות התחזוקה השגרתיות של השרת באותו מקום, כדי שיהיה אפשר לראות ולנהל אותן. עדכוני האבטחה של מערכת ההפעלה שייכים ל־שדרוגים ללא השגחה, ולא לשורת cron שאתם מתחזקים ידנית. עדכון תוספים וערכות עיצוב של WordPress הוא החלטה נפרדת: wp plugin update --all ב־crontab עלול להשבית אתר פעיל בשעה 3 לפנות בוקר, בלי שאיש יפקח עליו. לכן הפעילו עדכונים אלה באופן יזום, או רק לאחר שלב staging וגיבוי.

FAQ

האם השבתת WP-Cron מונעת מפרסומים מתוזמנים להתפרסם?

לא, כל עוד תהליך אחר מריץ את התור. DISABLE_WP_CRON מונע רק מטעינת דפים להפעיל את התור. האירועים עדיין מתוזמנים בדיוק כפי שהיו קודם. פוסט שהוגדר לשעה 09:00 יתפרסם בהרצת ה־cron הראשונה לאחר 09:00, ולכן מרווח של חמש דקות יפרסם אותו עד 09:05. אם תגדירו את הקבוע ולא תוסיפו את רשומת ה־cron, הפוסט יישאר ברשימה כשהוא מסומן Missed schedule, עד שתהליך כלשהו יריץ את התור.

איזה משתמש צריך להריץ את משימת ה־cron של WordPress?

המשתמש שהוא הבעלים של הקבצים ש־PHP כותב אליהם, ובמכונת Ubuntu שמותקנת כברירת מחדל זהו www-data. בדקו באמצעות 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 משורת הפקודה, ללא פסק זמן של שרת האינטרנט, ומדפיס שורה אחת לכל אירוע יחד עם משך ההרצה שלו. כך הלוג מציג בדיוק מה הורץ וכמה זמן נמשך.