בפוסט קצר זה נראה מה הדרך הנכונה לנטר שגיאות PHP באתרי וורדפרס באמצעות WP_DEBUG_LOG. כמו במרבית הדברים הקשורים לפיתוח וורדפרס, ניתן לומר כי הדרך הטובה ביותר להבין פונקציה מסוימת היא פשוט לחפש את אותה פונקציה בקבצי הליבה של וורדפרס ולתת מבט בקוד.
הנה הקוד של הפונקציה wp_debug_mode. החלק החשוב והרלוונטי מופיע ב wp-include/load.php :
function wp_debug_mode() {
if ( WP_DEBUG ) {
error_reporting( E_ALL );
if ( WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 1 );
elseif ( null !== WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 0 );
if ( in_array( strtolower( (string) WP_DEBUG_LOG ), array( 'true', '1' ), true ) ) {
$log_path = WP_CONTENT_DIR . '/debug.log';
} elseif ( is_string( WP_DEBUG_LOG ) ) {
$log_path = WP_DEBUG_LOG;
}
if ( isset( $log_path ) ) {
ini_set( 'log_errors', 1 );
ini_set( 'error_log', $log_path );
}
} else {
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}
if ( defined( 'XMLRPC_REQUEST' ) || defined( 'REST_REQUEST' ) || ( defined( 'WP_INSTALLING' ) && WP_INSTALLING ) || wp_doing_ajax() || wp_is_json_request() ) {
ini_set( 'display_errors', 0 );
}
}
נחסוך את ההסברים על כל שורה, אך בעיקרו של דבר אם תקבעו כי WP_DEBUG_LOG פעיל, WP_DEBUG_DISPLAY לא פעיל ו WP_DEBUG גם כן פעיל, התוצאה תהיה שכל שגיאות ה PHP יירשמו לקובץ debug.log שייווצר בתיקיית wp-content אך לא יוצגו שגיאות php ברמת הדפדפן (ב frontend).
בכדי להגדיר אלו בצורה שתיארנו השתמשו בקוד הבא:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
@ini_set( 'display_errors', 0 );הקפידו למקם קבועים אלו בקובץ wp-config.php שלכם מעל השורה /* That's all, stop editing! */. לעולם אל תפעילו WP_DEBUG באתרי ייצור (Production).
אך מדוע לעשות זאת? הנה שלוש סיבות מדוע עדיף להשתמש ב WP_DEBUG_LOG על פני WP_DEBUG:
הודעות שגיאה נסתרות
אתם רגילים לראות הודעות שגיאה של PHP ברמת הדפדפן אך האם אתם בטוחים שאתם רואים את כולן? מה לגבי אלמנטים שנסתרים ב CSS ומה לגבי קריאות AJAX?
ממשק המשתמש (User Interface) אינו מקום אמין לתפוס את כל הודעות השגיאה. קובץ ה-PHP Log לעומת זאת מראה את כולן ולא תפספסו.
הודעות שגיאה חסרות
אולי אתם אוהבים להשתמש בתוספים כגון Debug Bar או Query Monitor על מנת לנטר ולקבל את הודעות השגיאה. אלו תוספים נהדרים.
עם זאת, נתקלתי במקרים בהם הם מפספסים שגיאות. זה קורה מפני שאלו בסופו של דבר תוספים ויכול להיות שיש תוספים שנטענים לפניהם.
ניתן לשנות את סדר טעינת התוספים באמצעות תוספים כגון Plugin Organizer אך מה בקשר לתוספים הנמצאים בספריית ה MU plugins או שגיאות בקבצי הליבה של וורדפרס עצמה?
עד כמה שתוספים אלו נוחים, זוהי טעות לסמוך עליהם בלבד בכדי לגלות את כל שגיאות ה-PHP באתר וורדפרס שלכם.
PHP בפני עצמה היא המקור האמין ביותר לדיווח שגיאות, וזאת תקבלו באמצעות הקובץ debug.log.
תוספים צד שלישי
אם הקוד שכתבתם בעייתי וזורק הודעות שגיאה, תוכלו לתקן זאת. אך מה תעשו כשתוספים חיצוניים שהתקנתם זורקים הודעות שגיאה והערות על כל הממשק שלכם?
כאשר WP_DEBUG פעיל הוא מציג את כל השגיאות ללא יוצא מן הכלל. זה יכול להיות מאוד קשה לעבוד כאשר הודעות שגיאה והערות רצות על כל המסך, במיוחד כשתוספים מסוימים פעילים.
ניתן כמובן לבטל את אותם תוספים סוררים, אך מה אם הם הכרחיים לתהליך הפיתוח שלכם ואינכם יכולים לבטל אותם? בעבר פשוט ביטלתי את WP_DEBUG במקרים כאלו אך זו בטח לא הדרך הנכונה לעבוד…
בשלב זה כבר הוספתם את אותן שורות ל-wp-config.php ואתם מנטרים את השגיאות באמצעות קובץ ה-debug.log. הנה דוגמה לכיצד נראות השגיאות בקובץ זה:
[18-Dec-2017 09:18:08 UTC] PHP Fatal error: Call to undefined function get_slocale() in /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/includes/home.php on line 9
[18-Dec-2017 09:18:08 UTC] PHP Stack trace:
[18-Dec-2017 09:18:08 UTC] PHP 1. {main}() /Users/roeeyossef/Sites/startapp/index.php:0
[18-Dec-2017 09:18:08 UTC] PHP 2. require() /Users/roeeyossef/Sites/startapp/index.php:17
[18-Dec-2017 09:18:08 UTC] PHP 3. require_once() /Users/roeeyossef/Sites/startapp/wp-blog-header.php:19
[18-Dec-2017 09:18:08 UTC] PHP 4. apply_filters() /Users/roeeyossef/Sites/startapp/wp-includes/template-loader.php:73
[18-Dec-2017 09:18:08 UTC] PHP 5. WP_Hook->apply_filters() /Users/roeeyossef/Sites/startapp/wp-includes/plugin.php:203
[18-Dec-2017 09:18:08 UTC] PHP 6. call_user_func_array:{/Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286}() /Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286
[18-Dec-2017 09:18:08 UTC] PHP 7. thesis_skin->_skin() /Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286
[18-Dec-2017 09:18:08 UTC] PHP 8. thesis_skin->_template() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin.php:1003
[18-Dec-2017 09:18:08 UTC] PHP 9. thesis_html_body->html() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin.php:1065
[18-Dec-2017 09:18:08 UTC] PHP 10. thesis_box->rotator() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin/boxes.php:604
[18-Dec-2017 09:18:08 UTC] PHP 11. call_user_func_array:{/Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/box.php:389}() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/box.php:389
הנתיבים המוזרים שאתם רואים הם מפאת הפיתוח על סביבת וורדפרס לוקאלית.
נתיב קובץ לוג מותאם אישית
מאז וורדפרס 5.1, ניתן להעביר נתיב קובץ מותאם אישית ל-WP_DEBUG_LOG במקום רק true:
define( 'WP_DEBUG_LOG', '/path/outside/webroot/debug.log' );זה שימושי לאחסון קובץ הלוג מחוץ לתיקיית ה-web root הנגישה לציבור, מה שמהווה שיטת אבטחה מומלצת.
קבועי Debug נוספים
מעבר לשלושת הקבועים המרכזיים, וורדפרס מציעה שניים נוספים שימושיים בזמן פיתוח:
SCRIPT_DEBUG מאלץ את וורדפרס להשתמש בגרסאות הפיתוח (לא ממוזערות) של קבצי CSS ו-JavaScript של הליבה:
define( 'SCRIPT_DEBUG', true );זה מועיל כשצריכים לדבג או לשנות סקריפטים וסגנונות של הליבה.
SAVEQUERIES שומר את כל שאילתות מסד הנתונים, יחד עם זמן הביצוע והפונקציה הקוראת, למערך גלובלי:
define( 'SAVEQUERIES', true );ניתן לבדוק את השאילתות באמצעות $wpdb->queries. שימו לב שלזה יש השפעה על הביצועים ויש להשתמש בזה רק בזמן פיתוח.
אבטחת קובץ debug.log
כברירת מחדל, קובץ ה-debug.log נוצר בתוך תיקיית wp-content ונגיש לציבור. כל מי שיודע את ה-URL יכול לקרוא אותו, מה שעלול לחשוף מידע רגיש כמו נתיבי קבצים, שאילתות מסד נתונים ופרטי תוספים.
הגנו תמיד על קובץ ה-debug.log שלכם. אחסנו אותו מחוץ ל-web root באמצעות נתיב מותאם אישית, או חסמו גישה אליו דרך קובץ ה-.htaccess או הגדרות השרת.
לחסימת גישה באמצעות .htaccess, הוסיפו את הכלל הבא לקובץ .htaccess בתיקיית wp-content:
<Files debug.log>
Order allow,deny
Deny from all
</Files>לטיפים נוספים בנושא אבטחת וורדפרס, עיינו במדריך הייעודי שלנו.
ניתן גם למנוע הצגת שגיאות PHP לחלוטין באתר הייצור שלכם.
שאלות נפוצות
שאלות נפוצות בנושא WP_DEBUG_LOG:
סיכום
שימוש ב-WP_DEBUG_LOG במקום להסתמך על WP_DEBUG בלבד הוא שיטה מומלצת לפיתוח וורדפרס. הוא לוכד את כל שגיאות ה-PHP – כולל אלו המוסתרות בקריאות AJAX, תגובות REST API וטעינת תוספים מוקדמת – מבלי להעמיס על הדפדפן.
שלבו אותו עם WP_DEBUG_DISPLAY מוגדר ל-false, ותקבלו חוויית פיתוח נקייה עם רישום שגיאות מלא. זכרו להגן על קובץ הלוג מגישה ציבורית ולעולם אל תשאירו מצב דיבוג פעיל באתרי ייצור.
This post was translated from a post on deliciousbrains.com


מאמר יפה, טוב שמצאתי אותו. איפה אפשר למצוא הסבר איך פותרים את השגיאות? PHP Notice ו-PHP Warning אלה בעיות שיכולות להפיל אתר?
מאיפה מגיע הקובץ error_log? קיבלתי אתר שהקובץ הזה מגיע למאות MB, זה יכול להפיל את האתר?
היי רוב, ישנן המון סוגי שגיאות… בד״כ כאשר אני נתקל באחת ואיני יודע על מה מדובר אנו פשוט נעזר בגוגל. ברוב המקרים רק PHP Error יפיל את האתר. גודל קובץ ה Log לא ישפיע על האתר…
תודה, הבעיה שאין שגיאות אלא רק מה שכתבתי והקבצים האלה שיש רק בשורש וגם ב-Admin מגיעים לגודל עצום וגם משגעים את mysql ואחרי שאני מוחק אותם האתר חוזר לעבוד.