Πού βρίσκεται το debug log του WordPress και πώς να το μετακινήσετε

Το WordPress γράφει το debug log του στο wp-content/debug.log από προεπιλογή — με απόλυτη διαδρομή /path/to/your/site/wp-content/debug.log στον δίσκο. Το αρχείο δεν υπάρχει μέχρι να καταγραφεί όντως κάτι, και γράφεται μόνο εφόσον η WP_DEBUG είναι true και η WP_DEBUG_LOG ενεργοποιημένη μέσα στο wp-config.php. Αυτή η προεπιλεγμένη θέση είναι επίσης πραγματικό πρόβλημα ασφαλείας, γιατί στους περισσότερους παρόχους οποιοσδήποτε μπορεί να το κατεβάσει από τον browser.

Οι τρεις σταθερές και τι κάνει η καθεμία

Και οι τρεις μπαίνουν στο wp-config.php, πάνω από τη γραμμή που γράφει /* That's all, stop editing! Happy blogging. */. Οτιδήποτε προστίθεται κάτω από αυτή τη γραμμή εκτελείται αφού έχει ήδη ξεκινήσει το WordPress και αγνοείται.

Σταθερά	Προεπιλογή	Τι κάνει
WP_DEBUG	false	Κεντρικός διακόπτης. Ανεβάζει την αναφορά σφαλμάτων της PHP ώστε να δείχνει notices, προειδοποιήσεις και καταργήσεις. Τίποτα άλλο σε αυτή τη λίστα δεν λειτουργεί χωρίς αυτήν.
WP_DEBUG_LOG	false	Στέλνει τα σφάλματα σε αρχείο. Το true σημαίνει wp-content/debug.log. Ένα string αντιμετωπίζεται ως η διαδρομή του αρχείου εγγραφής.
WP_DEBUG_DISPLAY	true	Τυπώνει τα σφάλματα μέσα στο HTML της σελίδας, ορατά σε κάθε επισκέπτη.

Η εξάρτηση είναι το σημείο που ο κόσμος μπερδεύει. Η WP_DEBUG_LOG διαβάζεται μέσα στο τμήμα του κώδικα εκκίνησης του WordPress που ελέγχει τη WP_DEBUG. Αν η WP_DEBUG είναι false, το να ορίσετε τη WP_DEBUG_LOG σε true δεν κάνει απολύτως τίποτα — κανένα αρχείο, κανένα σφάλμα, καμία προειδοποίηση. Αν προσθέσατε τη WP_DEBUG_LOG και δεν εμφανίστηκε log, ελέγξτε πρώτα τη WP_DEBUG.

Μια ρύθμιση που δουλεύει σε ζωντανό ιστότοπο:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Αν η WP_DEBUG ορίζεται ήδη πιο πάνω στο αρχείο — συνήθως ορίζεται, με τιμή false — επεξεργαστείτε εκείνη τη γραμμή αντί να προσθέσετε δεύτερη define(). Ο διπλός ορισμός της ίδιας σταθεράς προκαλεί προειδοποίηση PHP, η οποία σε ιστότοπο με ενεργή εμφάνιση σφαλμάτων προσγειώνεται ακριβώς στην κορυφή της σελίδας σας.

Γιατί η WP_DEBUG_DISPLAY πρέπει να είναι false σε παραγωγή

Με την εμφάνιση ανοιχτή, τα σφάλματα PHP τυπώνονται μέσα στην απάντηση HTML. Μία μόνο ειδοποίηση κατάργησης από ένα θέμα τυπώνει την απόλυτη διαδρομή του συστήματος αρχείων σας σε κάθε επισκέπτη. Ένα σφάλμα βάσης δεδομένων τυπώνει ονόματα πινάκων και τμήματα ερωτημάτων. Χειρότερα, έξοδος που εμφανίζεται πριν σταλούν οι κεφαλίδες χαλάει τις ανακατευθύνσεις, χαλάει τις απαντήσεις REST και AJAX που περιμένουν καθαρό JSON, και μπορεί να παραγάγει τη λευκή οθόνη που ο κόσμος μετά χρεώνει σε κάποιο πρόσθετο.

Μια λεπτομέρεια που αξίζει να γνωρίζετε: το να ορίσετε τη WP_DEBUG_DISPLAY σε null δεν είναι το ίδιο με false. Το null λέει στο WordPress να αφήσει ήσυχη τη ρύθμιση display_errors της PHP και να κληρονομήσει ό,τι έχει ρυθμίσει ο διακομιστής. Το false την απενεργοποιεί ενεργά. Σε παραγωγικό ιστότοπο χρησιμοποιήστε false και προσθέστε και τη γραμμή ini_set παραπάνω ως δεύτερη δικλείδα, καθώς ένα πρόσθετο μπορεί να ξαναανοίξει το display_errors αργότερα μέσα στο ίδιο αίτημα.

Η προεπιλεγμένη θέση είναι δημόσια προσβάσιμη

Το wp-content/debug.log βρίσκεται μέσα στο web root. Τίποτα σε μια στάνταρ εγκατάσταση WordPress δεν μπλοκάρει τα απευθείας αιτήματα προς αυτό. Σε τυπική εγκατάσταση Apache ή nginx, το https://yoursite.com/wp-content/debug.log επιστρέφει το αρχείο ως απλό κείμενο. Τα debug logs περιέχουν απόλυτες διαδρομές διακομιστή, εσωτερικά στοιχεία προσθέτων και θεμάτων, σφάλματα βάσης δεδομένων με πραγματικό κείμενο ερωτημάτων, και ενίοτε τιμές που περνούσαν από συναρτήσεις που απέτυχαν. Είναι δωρεάν αναγνώριση εδάφους για όποιον μαντέψει το URL — και είναι από τα πρώτα URL που δοκιμάζουν οι αυτοματοποιημένοι σαρωτές.

Δύο τρόποι να το αντιμετωπίσετε. Ο καλύτερος είναι να μετακινήσετε το log.

Μετακινήστε το log με μια διαδρομή

Από το WordPress 5.1 και μετά, η WP_DEBUG_LOG δέχεται διαδρομή αρχείου ως string αντί για boolean. Στρέψτε την κάπου εκτός του document root:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Τρεις κανόνες για αυτή τη διαδρομή. Χρησιμοποιήστε απόλυτη διαδρομή — μια σχετική επιλύεται ως προς τον φάκελο εργασίας της PHP, ο οποίος αλλάζει ανά αίτημα και ανά διακομιστή, οπότε θα χάσετε το ίχνος του αρχείου. Ο φάκελος πρέπει να υπάρχει ήδη· η PHP δεν τον δημιουργεί, και αν δεν μπορέσει να ανοίξει το αρχείο αποτυγχάνει σιωπηλά. Και ο φάκελος πρέπει να είναι εγγράψιμος από τον χρήστη της PHP, ο οποίος σε κοινόχρηστη φιλοξενία δεν είναι ο ίδιος λογαριασμός με αυτόν που συνδέεστε μέσω SFTP.

Αν η φιλοξενία σας σάς περιορίζει μέσα στο web root και δεν υπάρχει πουθενά από πάνω να γράψετε, κρατήστε την προεπιλεγμένη διαδρομή και μπλοκάρετε την πρόσβαση σε επίπεδο διακομιστή. Σε Apache:

<Files "debug.log">
  Require all denied
</Files>

Αυτό μπαίνει σε ένα αρχείο .htaccess μέσα στο wp-content, όχι σε εκείνο της ρίζας — το WordPress ξαναγράφει το .htaccess της ρίζας όταν αποθηκεύετε τους μόνιμους συνδέσμους και μπορεί να σβήσει την προσθήκη σας. Σε nginx το .htaccess δεν κάνει απολύτως τίποτα· χρειάζεστε ένα location block στις ρυθμίσεις του διακομιστή, που στη διαχειριζόμενη φιλοξενία σημαίνει συνήθως ότι πρέπει να ζητήσετε βοήθεια από την υποστήριξη.

Να είστε ειλικρινείς για το τι σας δίνει το μπλοκάρισμα: το αρχείο εξακολουθεί να βρίσκεται στον δίσκο, μέσα σε φάκελο που σερβίρει ο web server. Ένα σφάλμα path traversal σε οποιοδήποτε πρόσθετο μπορεί ακόμα να το διαβάσει. Η μετακίνησή του εκτός του web root είναι η ισχυρότερη λύση.

Ανάγνωση και παρακολούθηση του αρχείου

Μέσω SSH, παρακολουθήστε το ζωντανά όσο αναπαράγετε το σφάλμα:

tail -f wp-content/debug.log

Αναπαράγετε το σφάλμα σε άλλη καρτέλα και οι νέες γραμμές εμφανίζονται καθώς γράφονται. Για να δείτε μόνο τα πρόσφατα, ή για να φιλτράρετε σε ένα πρόσθετο:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

Η PHP προσθέτει στο τέλος του αρχείου, οπότε διαβάζετε από κάτω προς τα πάνω. Κάθε εγγραφή φέρει χρονοσήμανση σε UTC, η οποία δεν θα ταιριάζει με τη ρύθμιση ζώνης ώρας του WordPress σας — μην αφήσετε αυτό να σας κάνει να νομίσετε ότι βλέπετε παλιές εγγραφές.

Με το WP-CLI μπορείτε να αλλάξετε τις σταθερές χωρίς να επεξεργαστείτε το αρχείο στο χέρι:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Η σημαία --raw έχει σημασία — χωρίς αυτήν η τιμή γράφεται ως το string "true" και όχι ως boolean. Για τη μορφή με διαδρομή, παραλείψτε το --raw ώστε να γραφτεί ως string σε εισαγωγικά.

Χωρίς SSH; Κατεβάστε το αρχείο μέσω SFTP ή ανοίξτε το στον διαχειριστή αρχείων του παρόχου σας. Αποφύγετε τα πρόσθετα που εμφανίζουν το log μέσα στο wp-admin εκτός αν τα εμπιστεύεστε απόλυτα· δίνετε σε ένα πρόσθετο δικαίωμα ανάγνωσης σε ένα αρχείο γεμάτο εσωτερικά στοιχεία του διακομιστή.

Αν θέλετε το ακριβές μπλοκ wp-config για τη δική σας εγκατάσταση, μαζί με ασφαλή διαδρομή εκτός ρίζας και τον αντίστοιχο κανόνα διακομιστή, η γεννήτρια debug log για WordPress θα το φτιάξει για εσάς.

Κλείστε το όταν τελειώσετε

Τίποτα στον πυρήνα του WordPress δεν εναλλάσσει ούτε περικόπτει το debug.log. Σε έναν ιστότοπο που παράγει ένα notice σε κάθε φόρτωση σελίδας, μεγαλώνει χωρίς όριο και μπορεί να γεμίσει τον δίσκο — κάτι που ρίχνει τον ιστότοπο πιο άσχημα από το σφάλμα που κυνηγούσατε. Ενεργοποιήστε την καταγραφή, αναπαράγετε το πρόβλημα, διαβάστε το log και μετά επαναφέρετε τη WP_DEBUG σε false.

Για να αδειάσετε το αρχείο χωρίς να το διαγράψετε:

: > wp-content/debug.log

Όταν το log μένει άδειο

Δουλέψτε με αυτή τη σειρά. Η WP_DEBUG είναι false — η πιο συχνή αιτία, και απενεργοποιεί σιωπηλά όλα τα υπόλοιπα. Η σταθερά βρίσκεται κάτω από τη γραμμή «stop editing» μέσα στο wp-config.php. Δικαιώματα αρχείων — η PHP δεν μπορεί να γράψει στο wp-content, ή στον προσαρμοσμένο φάκελο που ορίσατε. Ένα fatal error πριν ολοκληρωθεί η φόρτωση του wp-config, όπως ένα συντακτικό λάθος μέσα στο ίδιο το αρχείο ρυθμίσεων, συμβαίνει πολύ νωρίς για να το πιάσει η καταγραφή του WordPress· αυτά καταλήγουν στο PHP error log του ίδιου του διακομιστή. Ο πάροχός σας το παρακάμπτει — ορισμένες διαχειριζόμενες πλατφόρμες καρφώνουν τη ρύθμιση error_log της PHP ή δρομολογούν την καταγραφή στον δικό τους πίνακα, οπότε οι σταθερές σας είναι σωστές και η έξοδος βρίσκεται απλώς αλλού. Ελέγξτε τον προβολέα log του παρόχου πριν υποθέσετε ότι φταίει η ρύθμισή σας.