Διόρθωση: Ο επεξεργαστής μπλοκ του WordPress δεν φορτώνει

Τις περισσότερες φορές, ένας επεξεργαστής μπλοκ του WordPress που δεν φορτώνει οφείλεται σε σφάλμα JavaScript — ένα χαλασμένο script από κάποιο πρόσθετο ή θέμα σταματάει ολόκληρη την εφαρμογή React, και ο επεξεργαστής δεν ολοκληρώνει ποτέ την απόδοσή του. Ανοίξτε την κονσόλα προγραμματιστή του browser (F12, ή Cmd+Option+I σε Mac), κάντε επαναφόρτωση της οθόνης επεξεργασίας και διαβάστε το κόκκινο σφάλμα. Σχεδόν πάντα κατονομάζει το αρχείο που το προκάλεσε. Αυτή η μία γραμμή σας λέει ποιο πρόσθετο να απενεργοποιήσετε, και συνήθως μπορείτε να επιστρέψετε στη συγγραφή σε λιγότερο από πέντε λεπτά. Η επανεγκατάσταση του WordPress, η αύξηση του ορίου μνήμης της PHP και η μετάβαση στον Classic Editor είναι οι τρεις πιο συνηθισμένες προτάσεις που θα βρείτε online, και συνήθως και οι τρεις είναι λάθος κίνηση.

Γιατί ο επεξεργαστής χαλάει με αυτόν τον τρόπο

Ο επεξεργαστής μπλοκ (Gutenberg) είναι μια εφαρμογή React μονής σελίδας που τρέχει μέσα στα wp-admin/post.php και post-new.php. Το WordPress φορτώνει (enqueue) μια στοίβα από πακέτα script — wp-blocks, wp-element, wp-editor, wp-edit-post — και η εφαρμογή ξεκινάει μέσω της wp.domReady(). Η JavaScript σταματάει να εκτελείται στην πρώτη μη διαχειρισμένη εξαίρεση. Έτσι, αν οποιοδήποτε φορτωμένο script προκαλέσει σφάλμα ενώ ο επεξεργαστής αρχικοποιείται, όλα όσα ακολουθούν πεθαίνουν μαζί του. Η προσεκτικά γραμμένη περιοχή του άρθρου σας καταρρέει σε ένα λευκό κενό πλαίσιο ή στο μήνυμα «Ο επεξεργαστής αντιμετώπισε ένα απροσδόκητο σφάλμα».

Από προεπιλογή, το WordPress συνενώνει επίσης τα script της διαχείρισης σε λιγότερα αιτήματα. Αυτό σημαίνει ότι το χαλασμένο JS ενός πρόσθετου μπορεί να παρασύρει άσχετα script που φορτώνονται στο ίδιο bundle, γι’ αυτό και ο ένοχος δεν είναι πάντα προφανής μόνο από τη συμπεριφορά. Η κονσόλα, όμως, είναι.

Ο δεύτερος τρόπος αστοχίας μοιάζει διαφορετικός: ο επεξεργαστής φορτώνει, αλλά η αποθήκευση προκαλεί το σφάλμα «Η ενημέρωση απέτυχε. Η απόκριση δεν είναι έγκυρη απόκριση JSON». Αυτό δεν είναι πρόβλημα JavaScript. Ο επεξεργαστής επικοινωνεί με το REST API στο /wp-json/wp/v2/ και περιμένει να λάβει καθαρό JSON πίσω. Αν κάποιο πρόσθετο ή το functions.php του θέματός σας εκπέμψει ένα notice, warning ή fatal της PHP πριν το JSON — ή αν κάποιο πρόσθετο ασφαλείας μπλοκάρει τη διαδρομή REST, ή κάποιο πρόσθετο ανακατεύθυνσης ξαναγράψει το URL — η απόκριση μολύνεται και ο επεξεργαστής δεν μπορεί να την αναλύσει.

Πώς να το διορθώσετε, από το ταχύτερο πρώτα

1. Διαβάστε την κονσόλα. Αναπαράγετε την αστοχία με τα DevTools ανοιχτά. Ένα σφάλμα όπως Uncaught TypeError ... some-plugin/build/index.js δείχνει κατευθείαν το προβληματικό πρόσθετο. Αυτό το μοναδικό βήμα επιλύει την πλειονότητα των περιπτώσεων και σας γλιτώνει από το τυφλό ψάξιμο με διχοτόμηση.

2. Αποκλείστε τον browser. Κάντε σκληρή ανανέωση (Cmd/Ctrl+Shift+R), και μετά δοκιμάστε ένα παράθυρο ανώνυμης περιήγησης με τις επεκτάσεις απενεργοποιημένες. Οι ad blockers και οι επεκτάσεις προστασίας απορρήτου κάποιες φορές αφαιρούν τα script της διαχείρισης. Αν δουλεύει σε ανώνυμη περιήγηση, το πρόβλημα είναι κάποια επέκταση του browser ή παλιά cache, όχι ο ιστότοπός σας.

3. Ελέγξτε το REST API απευθείας αν είδατε το μήνυμα «not a valid JSON». Επισκεφθείτε το https://yoursite.com/wp-json/ σε έναν browser. Θα πρέπει να δείτε έναν τοίχο από JSON. Αν λάβετε HTML, ένα σφάλμα 500 ή μια ανακατεύθυνση σύνδεσης, αυτό είναι το bug σας — κάποιο πρόσθετο χαλάει την απόκριση REST, όχι ο ίδιος ο επεξεργαστής.

4. Διχοτομήστε τα πρόσθετά σας. Απενεργοποιήστε τα όλα, επιβεβαιώστε ότι ο επεξεργαστής φορτώνει, και μετά ενεργοποιήστε τα ένα-ένα μέχρι να χαλάσει ξανά. Αν έχετε κλειδωθεί εντελώς έξω από το wp-admin, κάντε το μέσω SFTP μετονομάζοντας τον φάκελο:

mv wp-content/plugins wp-content/plugins_off

Το WordPress απενεργοποιεί τα πάντα όταν ο φάκελος εξαφανίζεται. Μετονομάστε τον πίσω, και μετά μετακινήστε τα πρόσθετα μέσα και έξω ένα-ένα.

5. Δοκιμάστε το θέμα. Αλλάξτε στο Twenty Twenty-Four. Ένα θέμα που φορτώνει χαλασμένο JS του επεξεργαστή ή προκαλεί σφάλμα PHP στο functions.php παράγει τα ίδια συμπτώματα.

6. Ενεργοποιήστε το log και διαβάστε το πραγματικό σφάλμα. Ειδικά για τις αστοχίες REST/JSON, ενεργοποιήστε τον εντοπισμό σφαλμάτων στο wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Το fatal γράφεται στο wp-content/debug.log με το ακριβές αρχείο και τον αριθμό γραμμής. Αν αυτό το stack trace είναι πυκνό — ονόματα κλάσεων με namespace, αλυσίδες require, ένα fatal θαμμένο κάτω από δέκα γραμμές trace — επικολλήστε το στον αποκωδικοποιητή αρχείων καταγραφής σφαλμάτων WordPress για να δείτε, με απλά λόγια, ποιο πρόσθετο και ποια γραμμή το προκάλεσε στην πραγματικότητα. Αυτή είναι η διαφορά μεταξύ του «κάτι έχει χαλάσει» και του «η γραμμή 214 αυτού του συγκεκριμένου πρόσθετου έχει χαλάσει».

Αν υποψιάζεστε ότι η συνένωση των script κρύβει τον πραγματικό ένοχο, αναγκάστε κάθε script να φορτώνει ξεχωριστά ώστε το σφάλμα της κονσόλας να δείχνει σε ακριβώς ένα αρχείο:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

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

Μην εγκαταστήσετε το πρόσθετο Classic Editor και το θεωρήσετε λυμένο. Δεν διορθώνει τίποτα — απλώς κρύβει τον επεξεργαστή μπλοκ ώστε να σταματήσετε να βλέπετε το σφάλμα. Το χαλασμένο JavaScript ή η χαλασμένη απόκριση REST είναι ακόμα εκεί, και θα σας ταλαιπωρήσει ξανά στον επεξεργαστή ιστότοπου, στα widgets, ή την επόμενη φορά που θα κάνετε ενημέρωση. Διαγνώστε πρώτα· καταφύγετε στον Classic μόνο αν έχετε πάρει τη συνειδητή απόφαση να σταματήσετε να χρησιμοποιείτε μπλοκ.

Μην αυξήσετε το όριο μνήμης της PHP από αντανακλαστικό. Είναι η αγαπημένη copy-paste λύση του internet, αλλά ένας κενός επεξεργαστής σπάνια οφείλεται σε εξάντληση μνήμης. Η πραγματική εξάντληση προκαλεί ένα συγκεκριμένο fatal — «Allowed memory size of N bytes exhausted» — που θα το δείτε στο debug.log. Αν αυτή η γραμμή δεν υπάρχει, περισσότερη μνήμη δεν αλλάζει τίποτα.

Μην επανεγκαταστήσετε τον πυρήνα του WordPress. Τα αρχεία του πυρήνα είναι byte-πανομοιότυπα σε κάθε εγκατάσταση. Αν έφταιγε ο πυρήνας, κάθε ιστότοπος WordPress στον πλανήτη θα είχε χαλασμένο επεξεργαστή αυτή τη στιγμή. Το σφάλμα βρίσκεται σχεδόν πάντα στα πρόσθετα ή στο θέμα σας, και η επανεγκατάσταση του πυρήνα ρισκάρει να αντικαταστήσει πράγματα χωρίς να διορθώσει τίποτα.

Μην καθαρίσετε ή απενεργοποιήσετε τυφλά το πρόσθετο cache ως πρώτο βήμα. Η επιθετική minification και συνένωση JS μπορεί να χαλάσει τον επεξεργαστή, οπότε αξίζει να το δοκιμάσετε — αλλά ελέγξτε την κονσόλα προτού αρχίσετε να αδειάζετε caches στην τύχη. Το μάντεμα είναι ο τρόπος με τον οποίο μια διόρθωση πέντε λεπτών μετατρέπεται σε ολόκληρο απόγευμα.

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

Αν η κονσόλα είναι καθαρή, το REST API επιστρέφει έγκυρο JSON, και μια πλήρης διχοτόμηση πρόσθετων και θέματος αφήνει τον επεξεργαστή νεκρό, η απάντηση σχεδόν πάντα βρίσκεται στο debug.log. Ενεργοποιήστε το WP_DEBUG_LOG, αναπαράγετε την αστοχία μία φορά, και περάστε το fatal που θα προκύψει μέσα από τον αποκωδικοποιητή αρχείων καταγραφής σφαλμάτων. Το stack trace κατονομάζει το αρχείο — ξεκινήστε από εκεί.