Η Λευκή Οθόνη του Θανάτου στο WordPress, με απλά λόγια

Η λευκή οθόνη του θανάτου είναι ένα κρίσιμο (fatal) σφάλμα PHP που δεν μπορείς να δεις. Το WordPress έπεσε σε μη αναστρέψιμο σφάλμα στη μέση της απόδοσης της σελίδας, η PHP σταμάτησε, και επειδή η εμφάνιση σφαλμάτων είναι απενεργοποιημένη στους διακομιστές παραγωγής, η σελίδα επέστρεψε κενή αντί να τυπώσει τον λόγο. Η λύση σχεδόν ποτέ δεν είναι θέμα μαντεψιάς: ενεργοποίησε το αρχείο καταγραφής σφαλμάτων (debug log), άνοιξε το wp-content/debug.log και διάβασε την τελευταία γραμμή fatal. Ονομάζει το ακριβές αρχείο — σχεδόν πάντα κάποιο πρόσθετο ή θέμα — και αυτή η μία γραμμή είναι όλη η επιδιόρθωση.

Γιατί η οθόνη είναι κενή

Η PHP έχει μια ρύθμιση που λέγεται display_errors. Σε ένα μηχάνημα ανάπτυξης είναι συνήθως ενεργή, οπότε ένα fatal σφάλμα τυπώνει ένα stack trace στην οθόνη. Σε έναν πραγματικό διακομιστή φιλοξενίας είναι απενεργοποιημένη εξ ορισμού, γιατί η διαρροή διαδρομών αρχείων και σφαλμάτων στους επισκέπτες είναι ζήτημα ασφάλειας. Έτσι, όταν κάτι προκαλέσει fatal σφάλμα — μια κλήση σε συνάρτηση που δεν υπάρχει πια, μια κλάση που δεν έχει φορτωθεί, ένα συντακτικό λάθος σε μια ενημέρωση πρόσθετου — η PHP «πεθαίνει» και δεν στέλνει τίποτα. Ο browser σου αποδίδει ένα κενό έγγραφο. Αυτή είναι η «λευκή οθόνη».

Από το WordPress 5.2 και μετά υπάρχει ένας χειριστής κρίσιμων σφαλμάτων (WP_Fatal_Error_Handler) που προσπαθεί να τα πιάσει. Όταν λειτουργεί, δεν βλέπεις κενή σελίδα — βλέπεις «Παρουσιάστηκε ένα κρίσιμο σφάλμα στον ιστότοπό σας», μαζί με ένα email στη διεύθυνση του διαχειριστή που συχνά περιέχει το πραγματικό σφάλμα και έναν σύνδεσμο για τη Λειτουργία Ανάκτησης (Recovery Mode). Μια εντελώς κενή οθόνη σημαίνει συνήθως ότι το σφάλμα ενεργοποιήθηκε πριν προλάβει να τρέξει αυτός ο χειριστής: ένα σφάλμα ανάλυσης/σύνταξης (που πιάνεται κατά τη μεταγλώττιση), ένα χαλασμένο must-use πρόσθετο ή ένα fatal στο functions.php του ενεργού θέματος. Είτε έτσι είτε αλλιώς, η αιτία είναι γραμμένη κάπου. Απλώς πρέπει να ενεργοποιήσεις το γράψιμο.

Διόρθωσέ το, με τη σειρά

1. Ενεργοποίησε το log. Επεξεργάσου το wp-config.php μέσω SFTP και πρόσθεσε τα εξής πάνω από τη γραμμή /* That's all, stop editing! */:

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

Το WP_DEBUG_DISPLAY σε false κρατά τα σφάλματα εκτός της δημόσιας σελίδας, ενώ το WP_DEBUG_LOG τα γράφει στο wp-content/debug.log. Ανανέωσε μία φορά τη χαλασμένη σελίδα για να δημιουργηθεί μια φρέσκια εγγραφή.

2. Διάβασε το τελευταίο fatal. Άνοιξε το wp-content/debug.log και κοίτα στο κάτω μέρος:

tail -n 30 wp-content/debug.log

Ψάχνεις μια γραμμή σαν αυτή:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Η διαδρομή ονομάζει τον ένοχο: plugins/some-addon. Αυτή είναι η απάντησή σου. Αν το trace είναι μεγάλο ή το μήνυμα κρυπτικό (Allowed memory size exhausted, Cannot redeclare, ένα όνομα κλάσης που δεν αναγνωρίζεις), επικόλλησέ το στον αποκωδικοποιητή αρχείων καταγραφής σφαλμάτων — αφαιρεί τον θόρυβο, σου λέει σε ποιο πρόσθετο ή θέμα δείχνει η διαδρομή, και εξηγεί τι σημαίνει ο συγκεκριμένος τύπος σφάλματος.

3. Απενεργοποίησε το κατονομαζόμενο στοιχείο. Δεν μπορείς να φτάσεις στο /wp-admin, οπότε κάν’ το μέσω SFTP. Μετονόμασε τον φάκελο του προβληματικού πρόσθετου, π.χ. some-addon → some-addon.off. Το WordPress δεν μπορεί να φορτώσει έναν φάκελο που δεν βρίσκει, οπότε απενεργοποιεί το πρόσθετο και ο ιστότοπος επανέρχεται. Αν το log δείχνει στο θέμα σου, άλλαξε σε ένα προεπιλεγμένο θέμα μετονομάζοντας τον φάκελο του ενεργού θέματος — το WordPress επιστρέφει σε ένα ενσωματωμένο twentytwentysomething.

4. Αν το log δεν γράφεται, το wp-content δεν είναι εγγράψιμο ή το σφάλμα βρίσκεται σε επίπεδο διακομιστή. Έλεγξε αντ’ αυτού το αρχείο καταγραφής σφαλμάτων PHP του host:

find . -name "error_log" -newermt "-1 hour"

Ίδια πληροφορία, διαφορετικό αρχείο. Οι στοίβες cPanel/Apache συχνά αφήνουν ένα error_log στη ρίζα του ιστότοπου ή στον κατάλογο που αποτυγχάνει.

Τι να μην κάνεις

Μην ανεβάζεις απλώς το όριο μνήμης. Η πιο πολυδιαδεδομένη συμβουλή στο διαδίκτυο είναι να αυξήσεις το WP_MEMORY_LIMIT σε 256M ή 512M. Αυτό διορθώνει τη WSOD μόνο αν το log όντως λέει Allowed memory size of N bytes exhausted. Αν το σφάλμα είναι Call to undefined function, περισσότερη μνήμη δεν κάνει τίποτα — άλλαξες μια ρύθμιση στην τύχη και η οθόνη είναι ακόμα λευκή. Διάβασε πρώτα το log, και μετά αύξησε τη μνήμη μόνο αν η μνήμη είναι το δηλωμένο πρόβλημα.

Μην καθαρίζεις την cache και το θεωρείς διάγνωση. Η λευκή οθόνη είναι η PHP που πεθαίνει στον διακομιστή πριν υπάρξει καθόλου HTML. Ένα παλιό στοιχείο στην cache δεν μπορεί να προκαλέσει κενό έγγραφο. (Ένα χαλασμένο πρόσθετο caching μπορεί — αλλά το log θα το κατονομάσει, που είναι και το ζητούμενο.)

Μην επεξεργάζεσαι ή επανεγκαθιστάς τον πυρήνα του WordPress. Το fatal σχεδόν ποτέ δεν βρίσκεται στο wp-includes ή στο wp-admin· βρίσκεται στο πρόσθετο ή στο θέμα που δείχνει το log. Η επανεγκατάσταση του πυρήνα είναι αργή, ριψοκίνδυνη και αντιμετωπίζει ένα σύμπτωμα που δεν έχεις επιβεβαιώσει.

Μην απενεργοποιείς όλα τα πρόσθετα και τα ξαναενεργοποιείς ένα-ένα στα τυφλά. Η μέθοδος της διχοτόμησης λειτουργεί, αλλά είναι ο αργός δρόμος. Το log σού λέει τον ακριβή φάκελο σε ένα βήμα. Κατέφυγε στη μέθοδο «σβήσε τα όλα» μόνο όταν δεν υπάρχει καθόλου αναγνώσιμο σφάλμα.

Μην αφήνεις το display_errors ενεργό στην παραγωγή. Μόλις ο ιστότοπος επανέλθει, αφαίρεσε τα defines του debug (ή γύρισε το WP_DEBUG πίσω σε false). Τα σφάλματα που τυπώνονται στους επισκέπτες εκθέτουν τις διαδρομές σου.

Ακόμα κολλημένος;

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