ביטול wp-cron ומעבר ל-system cron ב-WordPress

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

WP-Cron הוא מתזמן המשימות המובנה בתוך WordPress, והוא פועל רק כאשר מישהו מבקש דף באתר. שום דבר בתוך WordPress לא מתעורר מעצמו. בכל בקשה שאינה מוגשת מתוך מטמון (cache), WordPress קורא רשימה של משימות מתוזמנות, ואם הגיע זמן הביצוע של אחת מהן, הוא שולח בקשת HTTP שנייה לעצמו ב-/wp-cron.php כדי לבצע את העבודה. העברת המשימה הזו ל-system cron מעניקה לכם הרצה אחת צפויה לפי לוח זמנים קבוע, ללא קשר לשאלה אם היו באתר אלף מבקרים באותה דקה או אף לא אחד.

שתי שורות מבצעות את העבודה בפועל: קבוע (constant) ב-wp-config.php, וערך ב-crontab. כל השאר במדריך זה הוא החלק ששתי השורות הללו לא מציינות. באיזה משתמש המשימה חייבת לרוץ, כיצד להוכיח שהאירועים המתוזמנים אכן הופעלו, ושלוש הדרכים שבהן ההגדרה נכשלת מבלי להדפיס דבר באתר.

הדוגמאות משתמשות ב-/srv/www/example.com כספריית ה-WordPress וב-www-data כמשתמש של שרת האינטרנט. החליפו את הנתיבים ואת המשתמש שלכם בכל מקום.

איזה מבקר מפעיל את עלויות ה-cron באתר עמוס

כל בקשה שאינה עוברת דרך מטמון (cache) משלמת את מחיר הבדיקה. WordPress טוענת את האופציה cron, משווה חותמות זמן, וכאשר משימה מתוזמנת לביצוע היא קוראת ל-spawn_cron(), אשר שולחת בקשת loopback לא חוסמת ל-/wp-cron.php. המבקר אינו ממתין לתוצאה, אך תהליך PHP worker כן. בשרת VPS קטן המריץ PHP-FPM עם pm.max_children = 5, משימה מתוזמנת איטית אחת תופסת חמישית מקיבולת ה-PHP שלכם למשך זמן הביצוע שלה, והיא צפויה להתרחש דווקא בדקה העמוסה ביותר שלכם, שכן זהו הזמן שבו מתרחשים הכי הרבה טעינות דפים.

WordPress אכן מגבילה כפילויות. היא לוקחת מנעול (lock) שזמן החיים שלו הוא WP_CRON_LOCK_TIMEOUT, כברירת מחדל 60 שניות, כך שמבקרים בו-זמניים לא יפעילו כל אחד ריצה משלו. המנעול מגביל כפילות, אך הוא אינו מוציא את העבודה מנתיב הבקשה.

ספרו כמה פעמים התהליך מופעל בשרת שלכם לפני שתחליטו אם מדובר בבעיה. כל בקשת loopback מופיעה בלוג הגישה של שרת האינטרנט:

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

Apache כותב במקום זאת ל-/var/log/apache2/access.log. ספירה של אלפים ביום מהווה עלות ממשית, וזהו סוג הנתון שעליכם למדוד בשרת שלכם במקום להסתמך על מאמרים, בדיוק כפי שהייתם מבצעים benchmark ל-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. קבוע שמוגדר לאחר ה-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. הוא זקוק לקובץ ה-binary של 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 מדפיס את הנתיב ל-binary של 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). שגיאה קריטית (fatal error) לגבי קבוע לא מוגדר משמעותה שהשורה 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. אם הקציתם לאתר pool ייעודי של 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) שולחת פלט רגיל ושגיאות לקובץ אחד שניתן לקרוא.

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

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

החלופה של systemd timer

אם שאר המשימות המתוזמנות בשרת כבר רצות כ-systemd services and timers, העבירו גם את 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.

התור לעולם לא ירוץ, ואם לא ביצעתם הפניה מחדש (redirect) לפלט, לעולם לא תראו את ההודעה. התיקון המסוכן הוא הוספת --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

במקרה כזה, קראו למפרש (interpreter) במפורש, לדוגמה /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 הוא מה שמונע חפיפה כעת. הרצה שנדלגה מסתיימת מיד ובשקט, כפי שתוכנן.

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

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 stack:

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

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

• הריצה מוגבלת על ידי ה-timeouts של שרת ה-web ושל PHP-FPM, לכן משימה ארוכה עלולה להיקטע באמצע.
• התעודה חייבת להיות בתוקף, אחרת curl יעצור עם SSL certificate problem; לכן ודאו שחידוש התעודות עובד כראוי בעזרת Certbot on nginx.
• מנגנון ה-page caching לא אמור לשמור ב-cache את wp-cron.php, אחרת בקשות ה-cron יקבלו תגובה שמורה והמשימות לא ירוצו.
• לא תקבלו פלט עבור כל אירוע, לכן הראיה היחידה לכך שמשימה רצה היא התוצאה שהיא הפיקה.

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

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

ברגע ש־system cron מנהל את התור של WordPress, כדאי לרכז את שאר משימות התחזוקה השוטפות של השרת באותו מקום, שבו תוכל לראות אותן. עדכוני אבטחה של מערכת ההפעלה צריכים להתבצע באמצעות unattended upgrades ולא באמצעות שורת 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 job של WordPress?

המשתמש שבבעלותו הקבצים ש-PHP כותב, שהוא www-data בהתקנת Ubuntu סטנדרטית. בדקו זאת באמצעות stat -c '%U %G' /srv/www/example.com/wp-content/uploads והשוו זאת לשורת ה-user = בקובץ התצורה של ה-pool ב-PHP-FPM. הרצת המשימה כ-root תגרום ל-WP-CLI להיעצר עם שגיאת YIKES, וכפייה שלה באמצעות --allow-root תשאיר קבצים בבעלות root בתוך wp-content ששרת האינטרנט לא יוכל לכתוב אליהם לאחר מכן.

באיזו תדירות מערכת ה-cron צריכה להריץ את ה-cron של WordPress?

כל חמש דקות מתאים לרוב האתרים. התאימו את המרווח ללוח הזמנים הקצר ביותר שאתם באמת מסתמכים עליו, ושמרו עליו בטווח בטוח מעל הזמן שלוקחת ריצה בודדת, אותו ניתן למדוד על ידי הוספת time לפני פקודת ה-WP-CLI. מרווחים של דקה אחת יערמו ריצות זו על גבי זו באתר עמוס, אלא אם כן flock מגן עליהן.

מדוע wp cron test נכשל לאחר שאני מבטל את WP-Cron?

מכיוון שפקודה זו בודקת יצירת אירועים המופעלת על ידי מבקרים, והיא מדווחת על שגיאה כאשר DISABLE_WP_CRON מוגדר כ-true. זו התוצאה הנכונה בשרת המוגדר בצורה זו. בדקו במקום זאת את נתיב ה-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 דרך שרת האינטרנט, והוא מוגבל על ידי זמן הקצוב לבקשה (timeout). WP-CLI מריץ את האירועים בתהליך PHP של שורת פקודה ללא הגבלת זמן של שרת אינטרנט, ומדפיס שורה אחת לכל אירוע עם משך הזמן שלו, כך שהלוג מראה לכם בדיוק מה רץ וכמה זמן זה לקח.