למה האתר שלכם נשבר אחרי עדכון תוסף, ואיך מונעים את זה בפעם הבאה?
העדכון רץ בשלוש לפנות בוקר, אוטומטית, בלי שאף אחד ביקש. בשמונה וחצי מגיעה ההודעה הראשונה מלקוח שהטופס לא נשלח, ובתשע מתברר שחצי מהעמודים נראים כמו טקסט בלי עיצוב. מבחינת התחושה, האתר נשבר בגלל תוסף. מבחינת המנגנון, זה כמעט אף פעם לא מדויק. תוסף בודד ששוחרר בגרסה חדשה הוא לרוב הטריגר, לא הסיבה. הסיבה היא ששני רכיבים באתר מנסים לשלוט על אותו דבר, והעדכון רק שינה מי מהם מדבר אחרון. ההבחנה הזאת לא אקדמית, היא משנה בדיוק מה תעשו בשעה הקרובה ומה תעשו כדי שזה לא יחזור. במאמר הזה תמצאו איך נראית התנגשות מבפנים, אילו רכיבים מתנגשים הכי הרבה, מה עושים בשלושים הדקות הראשונות לפני שנוגעים בכלום, מתי חזרה לגרסה קודמת בטוחה ומתי היא מסוכנת בפני עצמה, ומה באמת מונע את החזרה של האירוע.
תוכן העניינים 7 פרקים
העדכון הוא הטריגר, לא הסיבה
אתר וורדפרס הוא לא אוסף של תוספים שיושבים זה לצד זה. כל תוסף נרשם לנקודות התערבות בתוך אותה מערכת אחת, ומבקש להיכנס בשלב מסוים ובעדיפות מסוימת. כשהכול עובד, זה בגלל שהסדר יצא במקרה נוח, לא בגלל שמישהו תכנן אותו. עדכון משנה את הסדר הזה: הוא יכול לשנות את העדיפות שבה התוסף נכנס, להוסיף נקודת התערבות חדשה, או להעלות גרסה של ספרייה משותפת שתוסף אחר עדיין מצפה לגרסה הישנה שלה.
לכן ההיגיון של להאשים את התוסף שהתעדכן אחרון מוביל לפעמים לפתרון הלא נכון. הסרתם אותו, האתר חזר, ואתם נשארים בלי תכונה שהייתה לכם, כשההתנגשות עדיין רדומה במקום ותתפוצץ בעדכון הבא.
יש גם משפחה שלמה של מקרים שבהם התוספים לא אשמים בכלל: חברת האחסון העלתה את גרסת ה-PHP בשרת, ותוסף ותיק שלא תוחזק שנים לא מסתדר עם התחביר החדש. התסמין זהה לגמרי, הפתרון שונה לחלוטין.
איך התנגשות נראית מבפנים
ארבעה דפוסים מכסים כמעט את הכול, וכדאי לזהות אותם כי כל אחד מתנהג אחרת:
שניים שמנסים להיות אחרונים. שני תוספים מתערבים באותו פלט, למשל שניהם כותבים תגיות תיאור לעמוד. התוצאה היא לא קריסה אלא כפילות שקטה, ואתם מגלים אותה רק כשמישהו מסתכל על קוד המקור.
שניים שטוענים ספרייה משותפת. שני תוספים מביאים איתם עותק של אותה ספריית קוד בגרסאות שונות. מי שנטען ראשון קובע, והשני מקבל פונקציות שהוא לא מכיר. זה הדפוס שגורם לשגיאה קטלנית ולמסך לבן.
שתי שכבות אופטימיזציה. תוסף מטמון אחד ותוסף איחוד וכיווץ קבצים שני, כל אחד מטפל באותם קבצי עיצוב וסקריפט. התוצאה היא עמוד שמקבל קובץ חצי מעובד, ומכאן הטקסט בלי עיצוב.
שכבת אבטחה שחוסמת רכיב פנימי. חומת אש או תוסף אבטחה חוסמים בקשה שהאתר עושה לעצמו, ורכיב שהיה תלוי בבקשה הזאת מפסיק לעבוד בלי שום הודעת שגיאה גלויה.
שימו לב שרק אחד מארבעת הדפוסים מייצר מסך לבן. שלושת האחרים מייצרים אתר שנראה חי ולא עובד, וזה בדיוק מה שהופך אותם ליקרים: אף אחד לא מגלה אותם בבוקר, אלא אחרי שבוע של פניות שלא הגיעו.
הרכיבים שבהם התנגשויות קורות הכי הרבה
הרשימה הזאת היא מפת החום שלי כשאני נכנס לאתר לא מוכר. אם באתר שלכם יש שני תוספים באותה שורה, שם הייתי מתחיל לחפש:
- מטמון, כיווץ קבצים והאצת טעינה. השורה הצפופה ביותר, ולרוב מספיק אחד.
- קידום אורגני ותגיות תיאור. שני תוספי SEO באתר אחד הם תמיד תקלה שמחכה לקרות.
- טפסים, בעיקר כשיש גם תוסף טפסים וגם טופס שמובנה בבונה העמודים.
- קופה ותשלומים בחנות, כולל תוספי חישוב משלוח ומע״מ.
- טעינה עצלה של תמונות מול גלריות וסליידרים.
- הפניות וקישורים קבועים, כשיש גם תוסף הפניות וגם כללים ידניים בשרת.
- אבטחה, כשמותקן גם תוסף אבטחה וגם שכבת הגנה מצד חברת האחסון.
- שדות מותאמים ובוני עמודים, שנשענים על אותם נתונים.
כלל פשוט שחוסך הרבה: בכל אחת מהשורות האלה מחזיקים תוסף אחד. לא כי השני גרוע, אלא כי שניים באותו תפקיד יתנגשו במוקדם או במאוחר.
שלושים הדקות הראשונות: לקרוא לפני שנוגעים
הפיתוי הוא להתחיל לכבות תוספים אחד-אחד עד שמשהו חוזר. זו שיטה שעובדת, והיא גם הדרך האיטית והמסוכנת ביותר, כי בכל כיבוי אתם משנים את מצב האתר החי ומאבדים את מצב הפתיחה.
הסדר שאני עובד לפיו:
- לתעד את מה שקורה. צילום מסך, הכתובת המדויקת של עמוד שנשבר, והשעה. אם יש הודעת שגיאה, את הטקסט המלא שלה.
- לבדוק מה בדיוק התעדכן ומתי. וורדפרס מתעד עדכונים, וגם המייל שמודיע על עדכון אוטומטי הוא ראיה. רשמו לעצמכם את שם התוסף ואת שתי הגרסאות, לפני ואחרי.
- להפעיל רישום שגיאות ולקרוא את השורה האחרונה. זה הצעד היחיד שנותן תשובה ודאית במקום ניחוש. שגיאה קטלנית מציינת את שם הקובץ המדויק, וממנו נגזר שם התוסף. אתם יודעים בוודאות מי נפל, ולא בערך.
- לגבות את המצב הנוכחי, קבצים ומסד נתונים, לפני התיקון הראשון.
- ורק אז לפעול, ובפעולה אחת בכל פעם, עם בדיקה אחרי כל שינוי.
אם התוצאה של האירוע היא מסך לבן לגמרי, קריאת הלוג היא עוד יותר קריטית, כי בלעדיה אין שום מידע על המסך. הרחבתי על זה בנפרד בתיקון מסך לבן בוורדפרס, שמתומחר מ-₪350 לתקלה לפני מע״מ.
חזרה לגרסה קודמת, ומתי היא מסוכנת
וורדפרס לא שומר לכם את הגרסה הקודמת של תוסף. ברגע שהעדכון רץ, הקבצים הישנים נמחקו. לכן חזרה לאחור דורשת מקור: גיבוי, ארכיון גרסאות ישנות של התוסף, או תוסף שמנהל חזרות. אם אין שום מקור, אין חזרה, וזה שווה לבדוק לפני שמבטיחים למישהו שהאתר יחזור תוך חצי שעה.
הדרך המעשית ביותר כשהניהול נעול היא דרך FTP: להוריד את הגרסה הקודמת, למחוק את תיקיית התוסף הנוכחית ולהעלות במקומה את הישנה. זה עוקף לגמרי את הצורך בגישה לניהול, ולכן זו השיטה שאני משתמש בה כשהאתר לא נותן להיכנס. גם כאן, הפעולה מחייבת את פרטי הגישה לשרת שלכם, כלומר בעלות מוכחת על האתר.
ועכשיו האזהרה שרוב המדריכים משמיטים. חלק מהעדכונים מבצעים שינוי מבנה במסד הנתונים, למשל הוספת טבלה או המרה של פורמט נתונים ישן. חזרה לגרסה הקודמת מחזירה את הקוד, אבל לא מחזירה את המבנה. התוצאה יכולה להיות תוסף ישן שמסתכל על נתונים בפורמט שהוא לא מכיר, וזה מצב גרוע יותר מהמצב ההתחלתי. הכלל: בתוספים שנוגעים לנתונים, בעיקר בחנויות, במערכות הזמנות ובמערכות חברים, חזרה לאחור נעשית עם שחזור מסד הנתונים מאותו רגע, לא רק בהחלפת קבצים.
אצלי פתרון התנגשויות תוספים וחזרה לגרסה קודמת מתחיל ב-₪350 לתקלה, לפני מע״מ, וכולל גם את הבידוד של התוסף האחראי וגם את סגירת העדכון האוטומטי שלו כדי שהאירוע לא יחזור באותה צורה.
מה באמת מונע את זה בפעם הבאה
| הרגל | מה הוא מונע | כמה עבודה זה |
|---|---|---|
| גיבוי מלא רגע לפני כל עדכון, נשמר מחוץ לשרת | את המצב שבו אין לאן לחזור | אוטומטי אחרי הגדרה חד-פעמית |
| עדכון אחד בכל פעם, עם טעינת עמוד מפתח אחרי כל אחד | את חוסר היכולת לדעת מי שבר | עשר דקות לסבב |
| לכבות עדכון אוטומטי בתוספים שנוגעים לקופה, לטפסים ולתשלומים | שבירה בשלוש לפנות בוקר בלי שאף אחד רואה | הגדרה חד-פעמית |
| להשאיר עדכוני אבטחה פעילים | פער אבטחה שנפתח בזמן שאתם מחכים לחלון נוח | ללא |
| עותק בדיקה נפרד לאתרים מורכבים | גילוי התנגשות על האתר החי | הקמה ראשונית, ואז שגרתי |
| לתעד את מספרי הגרסאות לפני העדכון | חיפוש ארוך של הגרסה שאליה חוזרים | שתי דקות |
| לעדכן בשעה שבה אדם ער ומסתכל | שעות של אתר שבור בלי שאף אחד יודע | ללא |
השורה הרביעית חשובה במיוחד, כי היא מאזנת את השלישית. כיבוי גורף של כל העדכונים האוטומטיים הוא לא זהירות, הוא דחיית סיכון לכיוון אחר. ההפרדה הנכונה היא בין עדכוני תיקון קטנים, שכדאי שירוצו לבד, לבין מעבר לגרסה ראשית חדשה, שנעשה ביד ובזמן שנוח לכם.
ההרגלים האלה הם בדיוק מה שאני מכניס לתחזוקת אתר וורדפרס: גיבויים בשתי שכבות, סבב עדכונים מבוקר, ניטור זמינות ודוח חודשי. התמחור שם הוא ₪250-₪950 חודשי, לפני מע״מ, לפי גודל האתר ורמת הליווי.
מתי ההשקעה במניעה מוצדקת ומתי לא
לא כל אתר צריך את אותה רמת הגנה, ולא הייתי מוכר לכם עותק בדיקה נפרד אם אין לו הצדקה. אתר תדמית עם שמונה תוספים, שלושה עמודים סטטיים וטופס יצירת קשר, יסתדר יפה עם גיבוי אוטומטי טוב וסבב עדכונים חודשי. מקרה שבירה שם עולה שעה של עבודה, וזה כל הסיפור.
המשוואה מתהפכת כשמתקיים אחד מאלה: יש חנות שמייצרת הכנסה יומית, יש מערכת הרשמה או אזור לקוחות, מותקנים יותר מעשרים תוספים, או שהאתר מחובר למערכות חיצוניות כמו מערכת ניהול לקוחות או מערכת דיוור. בכל אחד מהמצבים האלה שעת השבתה עולה יותר מהתחזוקה החודשית, והחשבון פשוט.
ויש גם תשובה שלישית שאני נותן לא מעט: לפעמים הבעיה היא לא איך מעדכנים אלא כמה תוספים יש. אתר שנשען על שלושים תוספים כדי לעשות מה שאפשר לעשות בשנים-עשר הוא אתר שיישבר שוב, ותחזוקה טובה רק תעכב את זה. במקרה כזה ניקוי והחלפה של רכיבים כפולים שווה יותר מכל חבילה.
אם האתר שלכם שבור עכשיו, אל תתחילו לכבות תוספים באקראי. שלחו לי את כתובת האתר, את שם התוסף שהתעדכן אם אתם יודעים אותו, ואת הודעת השגיאה המדויקת אם יש כזאת. ברוב המקרים בידוד ההתנגשות והחזרה לגרסה יציבה הם עבודה של שעה, ואני מנהל את התהליך מהאבחון ועד הבדיקה שהאתר חזר לתפקד. אפשר לתפוס אותי בWhatsApp גם כדי לשאול רק אם מה שאתם מתכננים לעשות בטוח. דברו איתי בוואטסאפ ←
