אירעה שגיאה קריטית באתר זה: מה זה בעצם אומר ואיך מתקנים

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

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

מה באמת קורה כאן

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

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

מה שאתם רואים	איפה	מה זה מלמד אתכם
”אירעה שגיאה קריטית באתר זה.”	חזית האתר, ללא התחברות	התרחשה שגיאה פטאלית, בלי פרטים נוספים
אותה שורה בתוספת “מידע נוסף על פתרון בעיות ב-WordPress”	חזית האתר או wp-admin	אותה שגיאה, ‏WordPress מציע לכם את עמוד המדריך
”…נא לבדוק את תיבת הדואר של מנהל האתר לקבלת הוראות.”	חזית האתר	המנגנון חשב שהוא שלח מייל שחזור

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

שלב 1: בדקו את מייל מצב השחזור

‏WordPress שולח את קישור השחזור לכתובת המייל של מנהל האתר — זו שמוגדרת בהגדרות, כללי — שלרוב אינה הכתובת שאיתה אתם מתחברים. בדקו את התיבה הזו, ובדקו גם בספאם.

המייל מכיל קישור ארוך שמסתיים במשהו כמו ?action=enter_recovery_mode. פתיחה שלו מכניסה אתכם ל-wp-admin במצב שחזור, שבו התוסף או ערכת העיצוב הבעייתיים מושהים ומסומנים בהודעה אדומה בראש המסך. משם אפשר לנטרל אותם כרגיל.

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

אם אתם רוצים שהמייל יגיע לכתובת שאתם באמת קוראים, הגדירו אותה במפורש בקובץ wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

שלב 2: קראו את השגיאה האמיתית

זה השלב שהופך אתר שבור לתיקון של חמש דקות. הוסיפו את השורות האלה ל-wp-config.php, מעל השורה שמבקשת להפסיק לערוך:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

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

רעננו את העמוד השבור פעם אחת, ואז פתחו את wp-content/debug.log. הרשומה האחרונה תיראה בערך כך:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

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

אם debug.log לא מופיע, ייתכן שאין הרשאות כתיבה לתיקייה, או שתוסף אבטחה העביר את הרישום למקום אחר. במקרה כזה פנו ליומן שגיאות ה-PHP של חברת האחסון — לרוב לוחות הבקרה יש קטגוריית “Error Log” או “Logs”, ואותה שגיאה פטאלית תופיע שם עם חותמת זמן.

הדביקו את הרשומה אל מפענח יומן השגיאות של WordPress כדי לתרגם את הניסוח של PHP למשמעות המעשית שלו ולקובץ שכדאי לפתוח ראשון.

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

שלב 3: לחזור אל wp-admin

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

mv wp-content/plugins wp-content/plugins-off

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

1. החזירו את שם התיקייה ל-plugins. הכול יישאר מנוטרל — ‏WordPress רשם את התוספים כלא פעילים.
2. הפעילו תוספים אחד-אחד, וטענו את חזית האתר אחרי כל הפעלה.
3. זה שמחזיר את השגיאה הוא האשם.

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

שלוש הסיבות שכדאי להכיר

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

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

מיצוי זיכרון. ביומן כתוב “Allowed memory size of X bytes exhausted”. העלאת המגבלה בקובץ wp-config.php היא צעד סביר:

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

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

עצות שאפשר להתעלם מהן בשקט

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

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

“תכבה את מנגנון הטיפול בשגיאות פטאליות.” קיים קבוע שמכבה אותו, והתוצאה היא שהשגיאה הגולמית מודפסת באתר הציבורי שלכם במקום להיתפס. זה חושף נתיבי קבצים למבקרים. השתמשו ב-WP_DEBUG_LOG עם WP_DEBUG_DISPLAY כבוי במקום — אותו מידע, בלי החשיפה.

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

עדיין תקועים?

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