"There has been a critical error on this website" (ובאתר בעברית — הודעה על "שגיאה קריטית" באתר) היא ההודעה שוורדפרס מציג כשקוד PHP באתר נתקל בשגיאה פטאלית ונעצר. זה לא סוף העולם: בדרך כלל האשם הוא תוסף, תבנית או קוד מותאם שלא מסתדר עם גרסת PHP או עם רכיב אחר. החל מוורדפרס 5.2 המערכת אפילו עוזרת לכם לצאת מזה, עם "מצב שחזור" שנשלח במייל. במאמר הזה: מה ההודעה אומרת, איך משתמשים במצב השחזור, ומה עושים כשהמייל לא הגיע.
מה קורה מאחורי ההודעה
לפני וורדפרס 5.2, שגיאה פטאלית הציגה בדרך כלל "מסך לבן" — עמוד ריק, בלי שום הסבר. לפי ההודעה הרשמית של צוות הליבה על Fatal Error Recovery Mode, מגרסה 5.2 וורדפרס תופס את השגיאה, מציג לגולשים הודעה שהאתר חווה קשיים טכניים, ושולח מייל לכתובת המנהל עם תיאור התקלה ו"קישור סודי" למצב שחזור.
מצב השחזור עובד חכם: לחיצה על הקישור שומרת עוגייה בדפדפן שלכם, ורק עבורכם וורדפרס משהה את התוסף או התבנית שגרמו לשגיאה — כך שתוכלו להיכנס לממשק הניהול ולטפל בבעיה. שאר הגולשים ממשיכים לראות את הודעת השגיאה עד שהבעיה תתוקן בפועל.
הדרך המהירה: דרך המייל
- חפשו במייל של כתובת המנהל הודעה מהאתר על בעיה טכנית. היא מציינת בדרך כלל איזה תוסף או תבנית גרמו לשגיאה.
- לחצו על הקישור למצב השחזור והתחברו.
- בממשק תראו הודעה על הרכיב שהושהה. עדכנו אותו, החליפו אותו או השביתו אותו.
- צאו ממצב השחזור ובדקו שהאתר עולה גם לגולש רגיל (בחלון גלישה בסתר).
שימו לב: לפי צוות הליבה, היציאה ממצב השחזור מסירה את העוגייה — ואם הרכיב עדיין שבור, השגיאה תחזור.
המייל לא הגיע? זה נפוץ
יש שתי סיבות עיקריות שהמייל לא מגיע:
- הוא נשלח לכתובת הלא נכונה. וורדפרס שולח אותו לכתובת המנהל שמוגדרת בהגדרות הכלליות — שלפעמים היא עדיין הכתובת של מי שבנה את האתר לפני שנים.
- האתר לא שולח מיילים בצורה אמינה. שרתים רבים לא מוגדרים לשליחת דואר, או שהמיילים נופלים לספאם. על זה כתבתי במאמר מיילים נכנסים לספאם — ובאתר וורדפרס, שליחה דרך שירות SMTP פותרת את רוב הבעיות; ראו SMTP בוורדפרס.
בלי מייל: מוצאים את האשם ידנית
1. הפעילו יומן שגיאות
לפי התיעוד של וורדפרס ל-wp-config.php, ההגדרה WP_DEBUG_LOG כותבת את כל השגיאות לקובץ /wp-content/debug.log, והיא פועלת רק כש-WP_DEBUG מופעל. באתר חי, מפעילים את הרישום ללוג ומכבים את ההצגה על המסך:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
טענו שוב את העמוד, ופתחו את קובץ הלוג. השורה שמתחילה ב-PHP Fatal error תכלול את נתיב הקובץ — וממנו ברור איזה תוסף או תבנית אשמים. בסיום, כבו את הרישום: קובץ לוג פתוח שגדל בשקט הוא גם סיכון וגם בזבוז מקום.
2. השביתו את החשוד
אם אין גישה לממשק, אפשר להשבית תוסף דרך FTP או מנהל הקבצים של האחסון: משנים את שם התיקייה שלו בתוך wp-content/plugins, ווורדפרס מפסיק לטעון אותו. כשלא ברור מי האשם, משנים זמנית את שם תיקיית plugins כולה — אם האתר עולה, מחזירים תוספים אחד-אחד. עם WP-CLI זה מהיר יותר:
wp plugin deactivate plugin-name wp theme activate twentytwentyfive
הסיבות הנפוצות לשגיאה קריטית
| הסיבה | מתי זה קורה | מה עושים |
|---|---|---|
| עדכון תוסף או תבנית | מיד אחרי עדכון (גם אוטומטי) | חוזרים לגרסה הקודמת ומדווחים למפתח |
| שדרוג גרסת PHP | אחרי שינוי בשרת | מעדכנים או מחליפים רכיבים שלא תואמים; ראו גרסת PHP בוורדפרס |
| זיכרון שנגמר | בפעולות כבדות | ראו שגיאת memory limit |
| קוד מותאם שהודבק | אחרי עריכה ב-functions.php | מבטלים את השינוי דרך FTP |
| קבצים חסרים או פגומים | אחרי העלאה חלקית או פריצה | מחזירים מגיבוי נקי |
איך מונעים את הפעם הבאה
רוב השגיאות הקריטיות מתחילות בעדכון שנעשה ישר על האתר החי. סביבת בדיקות, גיבוי לפני כל עדכון ועדכונים מבוקרים — במקום "לעדכן הכל" בלחיצה — מונעים את רובן. פירטתי את השגרה הזו במאמרים עדכון וורדפרס וסביבת בדיקות.
שאלות נפוצות
האם אפשר לכבות את מנגנון השחזור?
כן. לפי צוות הליבה, הקבוע WP_DISABLE_FATAL_ERROR_HANDLER ב-wp-config.php מכבה את המנגנון לגמרי. ברוב האתרים אין סיבה לעשות זאת.
השגיאה מופיעה רק בממשק הניהול — זה אותו דבר?
כן, אותה שגיאה פטאלית, רק בקוד שרץ בממשק. הדרך לאבחן זהה: יומן השגיאות יגיד מאיפה היא מגיעה.
אם האתר שלכם מציג שגיאה קריטית ואין לכם גישה לממשק, כתבו לי. שגרת עדכונים בטוחה, גיבויים ובדיקה אחרי כל שינוי הם הבסיס של תחזוקת האתרים שאני מספק.
אהבתם את המאמר?
