יש שגיאה קריטית באתר שלך? כך מתקנים את השגיאה בוורדפרס

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: ההודעה "There has been a critical error on this website" (יש שגיאה קריטית באתר) מופיעה כשקוד PHP של תוסף, תבנית או קובץ ליבה קורס בשגיאה קטלנית (Fatal Error). מאז וורדפרס 5.2, האתר שולח למייל המנהל קישור למצב שחזור (Recovery Mode), שמשבית את הרכיב התקול רק אצלכם, כדי שתוכלו להיכנס ולתקן. ברוב המקרים התיקון לוקח 10–20 דקות: מוצאים את הרכיב ביומן השגיאות, משביתים אותו, ומעדכנים או מחליפים.

⏱ זמן תיקון: 10–20 דקות · רמת קושי: בינוני · נבדק לאחרונה: 07.11.2026 מול קוד הליבה של וורדפרס 7.1.4 ומול האתר שלנו

מה זו השגיאה הקריטית בוורדפרס?

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

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

בקוד של וורדפרס 7.1.4 בדקנו ארבעה נוסחים של ההודעה. הגולש הרגיל רואה "There has been a critical error on this website", ומי שמחובר עם הרשאות מנהל רואה תוספת שמפנה לבדוק את המייל או את מסכי התוספים והתבניות.

איך מתקנים עם מייל מצב השחזור?

זו הדרך המהירה, כשהמייל הגיע. כל השלבים נעשים מתוך לוח הבקרה, בלי FTP.

1. חפשו בתיבת המייל של מנהל האתר הודעה בנושא "Your Site is Experiencing a Technical Issue". בדקו גם בספאם.
2. קראו במייל איזה תוסף או תבנית גרמו לשגיאה, ובאיזה קובץ ושורה.
3. לחצו על הקישור למצב שחזור והתחברו עם משתמש מנהל.
4. במסך התוספים תראו את הרכיב המושהה, עם הסיבה. השביתו אותו.
5. צאו ממצב השחזור בכפתור שבסרגל העליון, ובדקו את האתר בחלון גלישה בסתר.
6. עדכנו את התוסף לגרסה מתוקנת או החליפו אותו, ורק אז הפעילו מחדש.

מה עושים כשהמייל של מצב השחזור לא הגיע?

זה קורה הרבה, כי רוב השרתים לא שולחים מייל אמין בלי SMTP מוגדר. בקלאודוויז (Cloudways), למשל, אין שרת מייל, ובלי תוסף SMTP או תוסף מייל הודעות כאלה עלולות לא להגיע. במקרה כזה משביתים את התוסף ידנית:

1. מצאו את האשם ביומן השגיאות. בקלאודוויז: Application, ואז Monitoring, Logs ו-Error Logs. סננו לפי Fatal error. לפי התיעוד של קלאודוויז, שם מוצגות 1,000 השורות האחרונות. ההסבר המלא במדריך הלוגים בקלאודוויז.
2. התחברו לקבצים עם SFTP או מנהל הקבצים, ופתחו את התיקייה wp-content/plugins.
3. שנו את שם התיקייה של התוסף מהיומן, למשל מ-plugin-name ל-plugin-name.off. וורדפרס תשבית אותו אוטומטית.
4. אם האשמה בתבנית, שנו את שם התיקייה שלה ב-wp-content/themes. וורדפרס תעבור לתבנית ברירת מחדל אם יש אחת מותקנת.
5. בדקו את האתר, ואז החזירו את השם המקורי רק אחרי עדכון או החלפה.

כדי שהמייל יגיע בפעם הבאה, הגדירו SMTP. השלבים במדריך WP Mail SMTP.

מה גורם לשגיאה קריטית בוורדפרס?

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

מה כתוב ביומן	הסיבה הנפוצה	מה עושים
TypeError, Uncaught Error, Call to undefined function	תוסף לא תואם לגרסת PHP החדשה, או לגרסת וורדפרס	עדכנו את התוסף, או החזירו זמנית גרסת PHP קודמת
Allowed memory size exhausted	התוסף או התהליך צרכו יותר זיכרון מהמותר	הגדילו memory_limit, ובדקו מה צורך כל כך
Parse error / syntax error	שינוי ידני בקוד, למשל ב-functions.php	החזירו את הקובץ מגיבוי, או תקנו את השורה
Cannot redeclare function	שני תוספים, או תוסף ותבנית, עם אותה פונקציה	השביתו אחד מהם
Failed opening required	קובץ חסר אחרי עדכון שנקטע	התקינו את התוסף מחדש

דוגמה מהשטח: ב-7.11.2026, בזמן שבדקנו את ההגדרות של האתר הזה, הרצנו פיסת PHP קטנה שהעבירה מספר לפונקציה count(). ב-PHP 8.4 זה לא מתקבל, והתוצאה הייתה TypeError: count(): Argument #1 ($value) must be of type Countable|array, int given. זו בדיוק השגיאה שתוסף ישן גורם לה אחרי שדרוג PHP. שינוי גרסת PHP בקלאודוויז מוסבר במדריך החלפת גרסת PHP.

מה ראינו בהגדרות של האתר שלנו?

בדקנו ב-7.11.2026, בקריאה בלבד, את ההגדרות של cw-servers.co.il שרץ על קלאודוויז. אלה ההגדרות שקובעות מה הגולש רואה בזמן שגיאה:

הגדרה	הערך אצלנו	המשמעות
גרסת וורדפרס / PHP	7.1.4 / 8.4	מנגנון מצב השחזור פעיל
WP_DEBUG	false	פרטי השגיאה לא מוצגים לגולשים
display_errors (PHP)	כבוי	הגולש רואה רק את ההודעה הכללית
log_errors (PHP)	פעיל	הפרטים נכתבים ליומן השגיאות
WP_DISABLE_FATAL_ERROR_HANDLER	לא מוגדר	מצב השחזור לא כובה
מייל שחזור אחרון שנשלח	11.4.2023	גם אצלנו זה קרה פעם

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

איך מונעים את השגיאה הקריטית בפעם הבאה?

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

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

אם האתר מחזיר שגיאת 500 בלי הודעה של וורדפרס, הבעיה כנראה ברמת השרת או ב-.htaccess. ראו מדריך שגיאה 500.

שאלות נפוצות

מדריכים קשורים

• מסך לבן בוורדפרס
• לוגים וניפוי באגים בקלאודוויז
• שגיאה 500
• הגדרות PHP בקלאודוויז
• סקירת קלאודוויז
• כל המדריכים בתחום: פתרון תקלות

מקורות

• Fatal Error Recovery Mode in 5.2 – Make WordPress Core
• Debugging in WordPress – WordPress Developer Resources
• How to View Application Logs Using the Cloudways Platform – Cloudways Knowledge Base
• How to Resolve 500 Internal Server Error – Cloudways Knowledge Base
• קוד הליבה של וורדפרס 7.1.4 (class-wp-fatal-error-handler, class-wp-recovery-mode, class-wp-recovery-mode-email-service) והגדרות האתר שלנו – נקרא ב-07.11.2026, בקריאה בלבד

מקור רשמי: Fatal Error Recovery Mode in 5.2 ו-How to View Application Logs (Cloudways Knowledge Base). המדריך נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

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