איך לאבחן פרסום מתוזמן שהתפספס ב-WordPress לפני שמחליפים את WP-Cron

מאמר מתוזמן שהתפרסם באיחור לא מחייב אוטומטית תוסף תזמון חדש. תחילה בדקו אם הייתה ל-WordPress הזדמנות להפעיל את המשימה, אם המשימה נכשלה ואם מועד הפרסום באמת הגיע באזור הזמן שהוגדר באתר. אלו בעיות שונות שמובילות לתיקונים שונים.

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

מבררים מה היה אמור לקרות

תעדו את תאריך ושעת התזמון, את אזור הזמן של האתר ואת השעה שבה מישהו הבחין בעיכוב. השעון במחשב של כותב אינו ראיה מספקת לשעת הפרסום שהאתר התכוון אליה. אם עורכים עובדים במדינות שונות, הסכימו איזה שעון קובע את הפרסום והציגו זאת בבירור ברשימת הבדיקה המערכתית.

לאחר מכן ודאו שהמאמר נשאר במצב מתוזמן, ולא כטיוטה, בהמתנה לאישור או כפרטי. בדקו את השינוי המערכתי האחרון ואת תוספי תהליך העבודה המעורבים. פוסט שממתין לאישור אינו אירוע cron שנכשל. שמרו את המצב המיועד לפני פרסום ידני, כדי שפתרון זמני לא ימחק מידע שנחוץ לאבחון.

חשבו על מאמר היפותטי שתוזמן לבוקר סוף שבוע שקט. אם הפרסום חופף לביקור הראשון שהגיע מאוחר יותר, היעדר הפעלה הופך להסבר סביר. אם משימות אחרות הופעלו בזמן ורק המאמר הזה נכשל, צריך לצמצם את הבדיקה לפוסט או לפונקציה שמטפלת בו. כתבו את ההסברים המתחרים לפני התקנה כלשהי.

בודקים את התור לפני שמפעילים אותו

מדריך הבדיקות הרשמי מתאר פקודות WP-CLI להצגת אירועים ולהפעלתם. איש תחזוקה טכני יכול להתחיל בפקודת הקריאה בלבד wp cron event list בסביבת האתר הנכונה. זהו את ה-hook הרלוונטי, השעה והתדירות בלי למחוק את התור או להפעיל אותו.

אל תפעילו את כל האירועים שהגיע זמנם כקיצור דרך כללי לאבחון. בהתאם לתוספים, משימות עשויות לשלוח דוא״ל, לחדש גישה, לסנכרן רשומות או לבצע פעולות בעלות השלכות אחרות. לפני הפעלה ידנית של אירוע מסוים, זהו מה הוא עושה, בדקו אם כבר הופעל במקום אחר והסכימו כיצד תוודאו את התוצאה.

השוו את התור ליומני היישום והאחסון סביב השעה הצפויה. חפשו שגיאות הקשורות לפעולה, מגבלות משאבים או בקשות שלא הסתיימו. הופעת משימה ברשימה מוכיחה שהיא מתוזמנת, לא שהפונקציה שלה יכולה להסתיים בהצלחה. תעדו את השגיאה המדויקת במקום להציג כל כשל כבעיית cron כללית.

בודקים את ההפעלה ואת המתזמן החלופי

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

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

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

מתקנים שכבה אחת ובודקים תזמון אמיתי

כאשר ראיות תומכות בהיעדר הפעלה, קבעו הסדר תזמון שנתמך בידי ספק האחסון ומתאים לעומס האתר. כאשר פונקציה נכשלת, תקנו את התוסף או החיבור האחראי במקום להגביר תדירות. הפעלה תכופה יותר של משימה תקולה יכולה להוסיף עומס בלי לפרסם מאמר. מנגנונים שונים דורשים תיקונים שונים.

בדקו מאמר מתוזמן רגיל ובעל סיכון נמוך בסביבה מתאימה, וודאו גם את התוצאה המערכתית וגם את רישום ההפעלה. אם הבדיקה נעשית בייצור, התוכן צריך להתאים לפרסום ציבורי ולקבל אישור מערכתי רגיל. אל תשתמשו במאמר ציבורי מזויף רק כדי ליצור סימן גלוי להצלחה.

עקבו אחר יותר ממחזור תזמון אחד, כולל תקופה עם מעט גלישה. ודאו שאותו אירוע אינו מופעל פעמיים לאחר החלפת המתזמן. שמרו את ערכי התצורה הישנים והחדשים ברישום התחזוקה, עם שם האחראי לבדיקה הבאה. תיקון צריך להמשיך לעבוד גם לאחר שמי שביצע אותו עוזב.

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