נכנסים לאתר, ובמקום העמוד מקבלים מסך לבן ריק. אין שגיאה, אין הודעה, רק לובן. התופעה הזו נקראת WSOD (White Screen of Death), והיא אחת התקלות המתסכלות ביותר בוורדפרס, בדיוק כי היא לא מסבירה את עצמה. החדשות הטובות: ברוב המקרים הסיבה מצומצמת למספר חשודים מוכרים, והתוכן שלכם שלם וממתין מתחת לפני השטח. המאמר הזה עובר על האבחון והתיקון שלב אחר שלב.

למה המסך לבן ולא מופיעה שגיאה?

מסך לבן הוא בדרך כלל סימן לשגיאת PHP חמורה (fatal error) שעוצרת את טעינת העמוד. כברירת מחדל, וורדפרס בסביבת ייצור לא מציג שגיאות למבקרים מטעמי אבטחה, ולכן במקום הודעת שגיאה מתקבל פשוט עמוד ריק. הצעד הראשון תמיד יהיה לגרום לאתר לדבר: להפעיל מצב דיבוג שיחשוף מה באמת קורה מאחורי הקלעים.

לעיתים תקבלו דווקא הודעת "There has been a critical error on this website" במקום מסך לבן מוחלט. זו אותה משפחת תקלות, וטיפלנו בה בנפרד במאמר על שגיאת critical error ו-500 בוורדפרס.

הסיבות הנפוצות למסך לבן

לפני שצוללים לאבחון, כדאי להכיר את ארבעת החשודים העיקריים:

  1. תוסף או תבנית שגרמו לקונפליקט. הסיבה הנפוצה ביותר. עדכון תוסף, התקנה חדשה, או אי-תאימות בין תוסף לגרסת PHP מפילים את האתר. אם המסך הלבן הופיע מיד אחרי עדכון, זה כמעט תמיד המקור. הרחבנו על התרחיש הזה במאמר אתר קרס אחרי עדכון תוסף.
  2. מיצוי זיכרון PHP. אתר שגדל, תוספים כבדים או תהליך שצורך הרבה זיכרון יכולים לחרוג ממגבלת ה-memory limit, וטעינת העמוד נעצרת באמצע.
  3. שגיאת קוד ב-functions.php או בקובץ תבנית. תו אחד חסר, סוגר לא סגור או קטע קוד שהודבק לא נכון לקובץ התבנית גורמים לשגיאת PHP פטאלית מיידית.
  4. גרסת PHP לא תואמת. מעבר של השרת לגרסת PHP חדשה (למשל מ-7.4 ל-8.x) יכול לשבור תוסף או תבנית ישנים שאינם תואמים לה.

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

שלב 1: הפעלת מצב דיבוג כדי לראות את השגיאה האמיתית

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

define( 'WP_DEBUG', false );

מחליפים אותה בשורות הבאות:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

ההגדרה הזו כותבת את כל השגיאות לקובץ wp-content/debug.log במקום להציג אותן למבקרים. מרעננים את העמוד הבעייתי, פותחים את קובץ הלוג, והשורה האחרונה בדרך כלל מצביעה במדויק על הקובץ והתוסף שגרמו לקריסה. לדוגמה, שורה שמפנה ל-wp-content/plugins/some-plugin/ מסגירה איזה תוסף אשם.

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

שלב 2: שלילת תוספים ותבנית

אם הלוג הצביע על תוסף, או אם אין לכם גישה לאזור הניהול בכלל, אפשר לאבחן בשיטת השלילה:

  1. כיבוי כל התוספים בבת אחת. דרך FTP, שנו את שם התיקייה wp-content/plugins ל-plugins_off. וורדפרס "יאבד" את כל התוספים וינטרל אותם. אם האתר חזר לפעול, אחד התוספים אשם.
  2. איתור התוסף הבעייתי. החזירו את שם התיקייה ל-plugins, ואז כבו את התוספים אחד-אחד (שינוי שם של תיקיית התוסף הבודד) עד שהאתר חוזר. התוסף שאחרי כיבויו האתר חזר הוא המקור.
  3. בדיקת התבנית. אם כיבוי התוספים לא עזר, החשוד הוא התבנית. עברו זמנית לתבנית ברירת מחדל של וורדפרס (כמו Twenty Twenty-Four). אם אין גישה לניהול, אפשר לשנות את שם תיקיית התבנית הפעילה ב-wp-content/themes כדי לאלץ מעבר לתבנית ברירת מחדל.

ברוב המקרים אחד משני השלבים האלה מאתר את האשם תוך דקות.

שלב 3: העלאת מגבלת הזיכרון

אם הלוג מצביע על שגיאת "Allowed memory size exhausted", הבעיה היא זיכרון. מוסיפים ל-wp-config.php, לפני השורה /* That's all, stop editing! */, את השורה:

define( 'WP_MEMORY_LIMIT', '256M' );

אם זה לא מספיק או שהשרת מתעלם מההגדרה, ייתכן שיש להעלות את מגבלת הזיכרון ברמת השרת (php.ini או הגדרות PHP בלוח הבקרה). באחסון משותף לעיתים נדרשת פנייה לתמיכת חברת האחסון. אם אתם נתקלים שוב ושוב במגבלות זיכרון, ייתכן שהאתר פשוט גדל מעבר לחבילת האחסון, ושווה לשקול שדרוג או העברת האתר לשרת מתאים יותר.

שלב 4: בדיקת קובץ functions.php וגרסת PHP

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

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

Case אמיתי מ-OCW

באחד האתרים שטיפלנו בהם, הלקוח דיווח על מסך לבן מוחלט בדף הבית בלבד, בעוד שאר העמודים נטענו כרגיל. הפעלת WP_DEBUG חשפה שגיאת PHP פטאלית בקובץ functions.php של תבנית-הבת: שורה אחת הכילה }; מיותר שהוכנס בעריכה קודמת ושבר את כל הקובץ. התיקון היה הסרת התו הבודד דרך FTP, אחרי הרצת בדיקת php -l שאישרה שהתחביר תקין. האתר חזר לאוויר תוך דקות, בלי אובדן תוכן. הלקח: מסך לבן נראה דרמטי, אבל לרוב מדובר בכשל נקודתי שניתן לבודד במהירות עם הכלים הנכונים.

איך מונעים את הקריסה הבאה

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

  1. גיבוי אוטומטי לפני כל שינוי. עם גיבוי תקין, כל קריסה הופכת לשחזור של דקה. הסבר מלא בגיבוי אוטומטי לוורדפרס.
  2. סביבת בדיקה (staging). עדכונים ושינויי קוד נבדקים על עותק של האתר לפני שמעלים לייצור.
  3. תחזוקה שוטפת. עדכונים מבוקרים, ניטור והתאמת גרסאות PHP מונעים את רוב הקונפליקטים מראש.

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

שאלות נפוצות

מסך לבן בוורדפרס - האם איבדתי את התוכן שלי?

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

למה דווקא חלק מהעמודים לבנים והשאר עובדים?

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

הפעלתי WP_DEBUG אבל אין קובץ debug.log, מה עכשיו?

ודאו ש-WP_DEBUG_LOG מוגדר ל-true ושלתיקיית wp-content יש הרשאות כתיבה. אם עדיין אין לוג, ייתכן שהשגיאה מתרחשת עוד לפני שוורדפרס נטען (למשל ב-wp-config עצמו), ואז בדקו את לוג השגיאות של השרת בלוח הבקרה של האחסון.

מתי כדאי למסור את זה למומחה?

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