מסך המוות הלבן של וורדפרס

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

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

לפני הכל – האם מדובר במסך מוות לבן "אמיתי"?
לפעמים לא רואים כלום בגלל CSS\JS שמתפרע או שינוי כלשהו בדפדפן. הדבר הראשון שאני עושה הוא "הצגת קוד המקור" – באמצעות הקיצור ctrl + u. אם אתם לא רואים כלום – סימן שבאמת מדובר במסך מוות לבן אמיתי. אם אתם רואים שם קוד – יש מצב שמדובר במשהו אחר – מפריצה לאתר ועד תוסף JS/CSS שמתפרע ואז הטיפול הוא אחר. אם יש לכם ידע בתכנות, אתם יודעים כבר לבד מה לעשות – בדיקת ה-CSS וה-JS היא התחלה טובה. אם אין לכם ידע בתכנות – במקרה הזה דברו עם מתכנת, או נסו להחליף תבנית/ לכבות את התוסף שאחראי לזה.

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

שלב ראשון – בדיקת גרסת ה-PHP

מאוד רלוונטי לאנשים שמשתמשים ב-shared hosting מפוקפק משהו או שמישהו שהם לא סומכים עליו במאה אחוז יכול לגעת בהגדרות. ברוב המקומות ניתן לקבוע באמצעות פאנל הניהול את גרסת ה-PHP. שינוי שלה לגרסה ישנה יחסית יכול לגרום לתקלות בלתי צפויות. איך בודקים? הולכים לפאנל הניהול אל PHP Configuration ומוודאים שגרסת ה-PHP היא מה שהיה שם קודם. לא תאמינו כמה מסכי מוות לבנים נגרמים מזה שהאדמינים של השרת שינו את הגרסאות פתאום. אם אתם לא בטוחים והגרסה שלכם יותר נמוכה מ-5.3, שנו את זה ל-5.3 או 5.4. אבל זה המקום הראשון שבו בודקים במיוחד אם מסך המוות הלבן מתקבל לפתע פתאום בלי אזהרה.

שלב שני – בדיקת ה-htaccess.

נסו להיכנס אל /wp-admin או כל כתובת אחרת שמוצגת כדף עצמאי: כמו למשל mysite.com/about-us. האם אתם מצליחים להגיע ולקבל מסך מוות לבן או שאתם נתקלים בשגיאה ללא עיצוב של: "Not Found"?

במידה ואתם מקבלים שגיאה כזו, סביר להניח יש לכם בעיה עם ה-htaccess – ייתכן שבגלל תוסף שהיתה לו גישה אליו וחירבש אותו (לא חסרים תוספים שעושים את זה כמו ithemes security למשל). חשוב לתקן את ה-htaccess לפני שממשיכים הלאה. איך מתקנים? ניגשים לאתר הרשמי של וורדפרס, מורידים את גרסת הוורדפרס האחרונה, מעתיקים את ה-htaccess המקורי שנמצא שם ואז מעלים אותו אל השרת באמצעות ה-FTP. כל דרך אחרת מועדת לכשלון! במיוחד אם אתם לחוצים וזועמים גם ככה.

שלב שלישי – בדיקת התוספים

גשו אל האתר באמצעות ה-FTP. גשו אל הנתיב wp-content/plugins ושנו את שם התיקיה אל plugins_ (קו תחתון לפני ה-plugins). נסו להעלות את האתר עכשיו. אם כשמרפרשים רואים שהאתר עולה (מחורבש ככל שיהיה בלי כל התוספים כמובן) יש בעיה עם אחד התוספים. איזה? משנים את שם התיקיה חזרה ל-plugins ומתחילים לשנות שם של כל תיקית תוסף לשמו המקורי וקו תחתון. השינוי הזה משבית את התוסף הספציפי הזה. אחרי כל שינוי מרפרשים. האתר עעדיין לא עולה? סימן שהתוסף הזה חף מפשע. האתר עולה? סימן שהתוסף הזה בעייתי ויש להחליפו. או בגרסה חדשה יותר של התוסף או בתוסף אחר בעל פונקציונליות זהה או לדבג את התוסף, לפתור את הבעיה ולדחוף את התיקון כדי שכולם יהנו.

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

שלב רביעי – בדיקת התבניות

אם התוספים לא אשמים, יש מצב שתבנית האתר אשמה. גשו באמצעות מנהל הקבצים אל האתר, גשו אל הנתיב wp-content/themes ושנו את שם התבנית שלכם לשם המקורי כולל קו תחתון. רפרשו את האתר. רואים את האתר בתבנית ברירת המחדל? מעולה. סימן שיש בעיה בתבנית. מאה אחוז שבקובץ ה-functions.php שלכם. תתחילו לדבג. לא יודעים קוד? פנו למתכנת שיודע לעשות את זה או החליפו תבנית.

שלב חמישי – החלפת קוד המקור של האתר

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

שלב שישי – בדיקת ה-wp-config.php

אם זה לא התוספים, לא התבניות ולא קוד המקור, יש מצב שה-wp-config.php אחראי לבעיות. הקובץ הזה מכיל את הגדרות לחיבור למסד הנתונים של האתר וכן הגדרות בסיסיות נוספות. מוודאים שהקובץ הזה מקודד לפי UTF8 ללא BOM. מוודאים גם שאין לו סגירה של תגית PHP. במידה וזה לא עוזר. מכניסים את כל הפרטים שיש ב-wp-config.php אל הקובץ wp-config-sample.php ושומרים אותו כ-wp-config.php.

שלב שביעי – הדיבוג

במידה וכל השלבים הקודמים לא עוזרים, סימן שיש בעיה אחרת. בדרך כלל יותר חמורה. איך פותרים? ראשית באמת מוודאים שלא מדובר בבעיה של גרסת PHP שעליה פירטתי ממש בהתחלה. אם התעצלתם ולא בדקתם – זה הזמן לבדוק! במידה וכן בדקתם. יש להכניס אל ה-wp-config.php את הקוד:

define( 'WP_DEBUG', true );

הפעלת מוד הדיבאגינג מאפשר לכל השגיאות והאזהרות של ה-PHP שאנו מקבלים להיות מודפסות על המסך. חשוב להתעלם מה-notice וה-warnings ולהתמקד ב-errors. אם הגעתם לשלב הזה, עליכם להיות בעלי ידע סביר ומעלה בתכנות על מנת להבין ולפתור את הבעיה או להעזר במישהו כזה. בדרך כלל הטיפול בבעיה הזו מצריך הורדה של האתר לשרת בדיקות. בכל הקריירה שלי נתקלתי בבעיה כזו רק פעמים ספורות. זה נבע בדרך כלל מהגדרות לקויות ב-wp-config.

סיכום

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