תחזוקה 7 במאי 2026

קובץ debug.log ענק בוורדפרס: זיהוי המקור והניקוי הנכון

debug.log גדול מסמן שהאתר זורק שגיאות PHP בכמויות. כך מאתרים את התוסף או התבנית האשמים ומונעים את החזרה.

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

למה זה משנה

כל שגיאה ש-PHP זורק - אפילו Notice קל - דורשת מהשרת לבנות stack trace, להמיר ל-string ולכתוב לדיסק. בלוג שמתמלא במהירות זה מתחיל לעלות במונחי I/O. ראינו אתרים שעושים פעמיים יותר עבודת disk רק כדי לכתוב Deprecated warnings על קוד שלא משפיע על כלום. בנוסף, debug.log גדול מקשה מאוד על debugging אמיתי - כשמופיע משהו רציני, הוא קבור תחת אלפי שורות חוזרות. ולבסוף, חלק מתוספי האבטחה והגיבוי כוללים את הקובץ בגיבויים - וגיבוי של 200MB log הוא בזבוז רוחב פס.

הסיבה הנפוצה לתופעה: תוסף או תבנית ישנה עם syntax לא תואם הגרסת PHP החדשה. ב-PHP 8.1 ובעיקר 8.2, הרבה תכונות שהיו Deprecated בעבר נהפכו ל-Warning או Fatal: Creation of dynamic property, passing null to non-nullable parameter, ועוד. תוספים שלא עודכנו לתאימות PHP 8 ימלאו את הלוג מבלי לשבור את האתר ויזואלית.

איך לזהות

פתח את wp-content/debug.log דרך FTP, File Manager של ספק האחסון, או SSH. הסתכל על השגיאות - לרוב יש דפוס: אותה שגיאה חוזרת מאות פעמים. שורת השגיאה מכילה נתיב מלא:

PHP Deprecated: Creation of dynamic property in /home/user/public_html/wp-content/plugins/old-plugin/lib/foo.php on line 42

הנתיב /wp-content/plugins/old-plugin/ מזהה את התוסף האשם. אפשר גם להריץ:

grep -oE "plugins/[^/]+" wp-content/debug.log | sort | uniq -c | sort -rn | head

זה מציג את התוספים שהכי מופיעים בלוג, ממוין לפי שכיחות.

איך לתקן

  1. זהה את התוסף או התבנית הראשית שמייצרת את השגיאות (ראה למעלה).
  2. אם יש עדכון לתוסף - עדכן. רוב הסיכויים שהמפתח כבר תיקן את התאימות.
  3. אם התוסף לא מתוחזק (עדכון אחרון לפני שנתיים+) - מצא חלופה ובצע migration. תוסף לא מתוחזק הוא גם סיכון אבטחתי.
  4. אם זו תבנית מסחרית, גש לאזור התמיכה של המפתח ובקש עדכון. עד אז, צור תבנית ילד והעתק את הקבצים הבעייתיים אליה כדי לתקן ידנית בלי לאבד שינויים בעדכון הבא.
  5. אחרי תיקון, רוקן את הלוג: echo "" > wp-content/debug.log או דרך FTP מחק והעלה קובץ ריק.
  6. בייצור, עדיף לכבות לוג שגיאות לחלוטין: ב-wp-config.php הגדר WP_DEBUG_LOG ל-false ו-WP_DEBUG_DISPLAY ל-false. הפעל debug רק בעת חקר תקלה.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

טעויות נפוצות

  • השארת WP_DEBUG פעיל בייצור: זה כותב כל warning קטנה לדיסק תמיד. הפעל debug רק כשבעצם מנסים לתפוס באג.
  • מחיקת debug.log בלי לתקן את הסיבה: הקובץ ימולא שוב בעוד יום. תקן את המקור.
  • השתקה גורפת של שגיאות בקוד: הוספת error_reporting(0) ב-functions.php מסתירה הכל - כולל באגים אמיתיים. עדיף לסנן רק רמות מסוימות: error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);.
  • WP_DEBUG_DISPLAY=true בפרודקשן: זה גם מציג שגיאות לכל גולש - וקטור חשיפה של נתיבי שרת ופרטי DB.

בדיקה לאחר תיקון

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

טיפ: תוסף Query Monitor (חינמי) מציג את כל השגיאות בזמן אמת בתחתית הדף לאדמין בלבד. הוא מאפשר זיהוי הרבה יותר מהיר מאשר חיפוש ב-debug.log, ולא כותב לדיסק.
עוד בקטגוריה זו ← חזרה לכל המדריכים