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

מה המשמעות של "critical error"?

ההודעה הזו הופיעה כסטנדרט החל מוורדפרס 5.2. לפני כן, אותה תקלה הייתה מציגה "מסך לבן של מוות" (WSOD) בלי שום הסבר. כיום וורדפרס מזהה שגיאת PHP קריטית (Fatal Error), עוצר את טעינת הדף כדי לא לחשוף מידע רגיש, ומציג את ההודעה הגנרית. שגיאת 500 (Internal Server Error) היא לרוב אותו דבר מזווית השרת: משהו בקוד נכשל באמצע הריצה.

הגורמים הנפוצים, לפי שכיחות:

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

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

צעד 1: בדקו את המייל מוורדפרס

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

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

צעד 2: קראו את לוג השגיאות (debug.log)

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

define( 'WP_DEBUG', false );

מחליפים אותה בבלוק הבא (אם השורה לא קיימת, מוסיפים אותה לפני השורה /* That's all, stop editing! */):

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

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

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

צעד 3: recovery mode - הדרך הנקייה

וורדפרס כולל מנגנון "מצב התאוששות" (recovery mode) שמאפשר להיכנס לניהול גם כשהאתר נפל. הקישור מגיע במייל מצעד 1. כשנכנסים דרכו, וורדפרs מנטרל זמנית את הרכיב שגרם לשגיאה, ומאפשר לכם להיכנס ל-wp-admin בסביבה מבודדת.

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

צעד 4: אין גישה לניהול? משביתים תוספים ידנית

אם אין מייל ואין גישה ל-recovery mode, משביתים את התוספים ישירות מהשרת:

  1. התחברו ב-FTP או דרך מנהל הקבצים.
  2. נווטו ל-wp-content/.
  3. שנו את שם התיקייה plugins ל-plugins-off.

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

אם החלפת שם התיקייה לא עזרה, חוזרים על אותו תהליך עם התבנית: ב-wp-content/themes/, שנו את שם תיקיית התבנית הפעילה. וורדפרס יחזור אוטומטית לתבנית ברירת מחדל (כמו Twenty Twenty-Four), ואם זה פתר את הבעיה, התקלה בתבנית שלכם.

צעד 5: גרסת PHP וזיכרון

אם הלוג מצביע על שגיאות מסוג unsupported syntax או פונקציות שלא קיימות, ייתכן שחברת האחסון שדרגה את גרסת ה-PHP, ותוסף ישן לא תואם. בלוח הבקרה של האחסון (cPanel / Plesk) אפשר לשנות את גרסת ה-PHP. הורידו אותה זמנית לגרסה שעבדה, החזירו את האתר לאוויר, ואז תכננו עדכון מסודר של התוסף.

אם השגיאה היא Allowed memory size exhausted, מדובר בחריגת זיכרון. אפשר להעלות את המגבלה בקובץ wp-config.php עם השורה:

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

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

מתי זה לא סתם שגיאת קוד

לרוב, critical error היא תקלה טכנית תמימה. אבל יש מקרים שבהם היא תסמין של בעיה עמוקה יותר:

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

איך מונעים את זה מראש

רוב מקרי ה-critical error נמנעים בקלות:

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

איפה OCW נכנסת

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

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

שאלות נפוצות

האם critical error מוחקת לי תוכן מהאתר?

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

השביתי את כל התוספים והאתר עדיין נופל. מה עכשיו?

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

למה אני לא רואה את הקובץ debug.log?

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

האם אפשר לתקן בלי גישת FTP?

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