WordPress Blok Redaktoru Yüklənmir Problemini Həll Edin

Əksər hallarda yüklənməyən WordPress blok redaktoru bir JavaScript xətasıdır — plagin və ya mövzudan gələn bir zədəli skript bütün React tətbiqini dayandırır və redaktor heç vaxt tam yüklənmir. Brauzerinizin developer konsolunu açın (F12 və ya Mac-da Cmd+Option+I), redaktə ekranını yenidən yükləyin və qırmızı xətanı oxuyun. Demək olar ki, həmişə xətanı verən faylın adını göstərir. Həmin bir sətir sizə hansı plagini deaktiv etməli olduğunuzu deyir və adətən beş dəqiqədən az müddətdə yenidən yazmağa qayıda bilərsiniz. WordPress-i yenidən qurmaq, PHP yaddaş limitini artırmaq və Klassik Redaktora keçmək internetdə ən çox rast gəlinən üç məsləhətdir və bu üçü də adətən səhv addımdır.

Redaktor niyə məhz bu cür sınır

Blok redaktor (Gutenberg) wp-admin/post.php və post-new.php daxilində işləyən tək səhifəli React tətbiqidir. WordPress bir sıra skript paketlərini növbəyə qoyur — wp-blocks, wp-element, wp-editor, wp-edit-post — və tətbiq wp.domReady() vasitəsilə işə düşür. JavaScript ilk tutulmamış istisnada icranı dayandırır. Beləliklə, növbəyə qoyulmuş hər hansı skript redaktor işə düşərkən xəta verirsə, ondan sonrakı hər şey onunla birlikdə ölür. Diqqətlə yazdığınız yazı sahəniz boş ağ panelə və ya “Redaktor gözlənilməz bir xəta ilə üzləşdi” mesajına çevrilir.

Standart olaraq WordPress həmçinin admin skriptlərini daha az sorğuya birləşdirir. Bu o deməkdir ki, bir plaginin zədəli JS-i eyni paketdə yüklənən əlaqəsiz skriptləri də aşağı çəkə bilər, ona görə də təqsirkar yalnız davranışa baxaraq həmişə aydın olmur. Konsol aydın göstərir.

İkinci sınma forması fərqli görünür: redaktor yüklənir, lakin yadda saxlayanda “Yeniləmə uğursuz oldu. Cavab keçərli JSON cavabı deyil.” xətasını verir. Bu JavaScript problemi deyil. Redaktor /wp-json/wp/v2/ ünvanındakı REST API ilə əlaqə saxlayır və təmiz JSON gözləyir. Əgər bir plagin və ya mövzunuzun functions.php faylı JSON-dan əvvəl PHP bildirişi, xəbərdarlığı və ya fatal xəta verirsə — və ya təhlükəsizlik plagini REST marşrutunu bloklayırsa, yaxud yönləndirmə plagini URL-i yenidən yazırsa — cavab çirklənir və redaktor onu təhlil edə bilmir.

Necə həll etməli, ən sürətlisi əvvəldə

1. Konsolu oxuyun. DevTools açıq olarkən nasazlığı yenidən yaradın. Uncaught TypeError ... some-plugin/build/index.js kimi bir xəta birbaşa problemli plagini göstərir. Bu tək addım halların çoxunu həll edir və sizi kor-koranə bölmə axtarışından xilas edir.

2. Brauzeri istisna edin. Sərt yeniləmə edin (Cmd/Ctrl+Shift+R), sonra genişləndirmələr söndürülmüş inkoqnito pəncərəsində yoxlayın. Reklam blokerləri və məxfilik genişləndirmələri bəzən admin skriptlərini kəsir. Əgər inkoqnitoda işləyirsə, problem brauzer genişləndirməsi və ya köhnəlmiş keşdir, saytınız deyil.

3. REST API-ni birbaşa yoxlayın, əgər “keçərli JSON deyil” mesajını görmüsünüzsə. Brauzerdə https://yoursite.com/wp-json/ ünvanını ziyarət edin. Bir divar dolusu JSON almalısınız. Əgər HTML, 500 xətası və ya giriş yönləndirməsi alırsınızsa, sizin xətanız budur — bir plagin REST cavabını sındırır, redaktorun özünü deyil.

4. Plaginlərinizi bölmə üsulu ilə yoxlayın. Hamısını deaktiv edin, redaktorun yükləndiyini təsdiqləyin, sonra yenidən sınana qədər bir-bir aktivləşdirin. Əgər wp-admin-dən tamamilə kənarda qalmısınızsa, bunu SFTP üzərindən qovluğu adını dəyişərək edin:

mv wp-content/plugins wp-content/plugins_off

Qovluq yox olduqda WordPress hər şeyi deaktiv edir. Adını geri qaytarın, sonra plaginləri bir-bir daxil və xaric edin.

5. Mövzunu test edin. Twenty Twenty-Four-ə keçin. Zədəli redaktor JS-i növbəyə qoyan və ya functions.php-də PHP xətası verən mövzu eyni simptomları yaradır.

6. Jurnalı aktivləşdirin və əsl xətanı oxuyun. Xüsusilə REST/JSON nasazlıqları üçün wp-config.php-də sazlamanı aktivləşdirin:

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

Fatal xəta dəqiq fayl və sətir nömrəsi ilə wp-content/debug.log-a yazılır. Əgər həmin stek izi sıxdırsa — ad sahəsi ilə sinif adları, require zəncirləri, on sətirlik iz altında basdırılmış fatal xəta — onu bizim WordPress error log decoder alətinə yapışdırın ki, sadə dillə hansı plaginin və sətrin əslində onu tetiklədiyini görəsiniz. Bu “nəsə sınıb” ilə “bu konkret plaginin 214-cü sətri sınıb” arasındakı fərqdir.

Əgər skript birləşdirilməsinin əsl təqsirkarı gizlətdiyindən şübhələnirsinizsə, hər skriptin ayrıca yüklənməsini məcbur edin ki, konsol xətası dəqiq bir fayla işarə etsin:

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

Nə etməməli

Klassik Redaktor plaginini quraşdırıb “həll olundu” deməyin. O heç nəyi düzəltmir — blok redaktoru gizlədir ki, siz xətanı görməyəsiniz. Zədəli JavaScript və ya sınmış REST cavabı hələ də oradadır və sayt redaktorunda, vidjetlərdə və ya növbəti dəfə yeniləmə edəndə yenidən sizi vuracaq. Əvvəlcə diaqnoz qoyun; yalnız bloklardan istifadəni dayandırmaq barədə şüurlu qərar verdinizsə Klassikə keçin.

PHP yaddaş limitini refleks olaraq artırmayın. Bu internetin ən sevimli kopyala-yapışdır həllidir, lakin boş redaktor nadir hallarda yaddaş tükənməsidir. Əsl tükənmə konkret bir fatal xəta verir — “Allowed memory size of N bytes exhausted” — bunu siz debug.log-da görəcəksiniz. Əgər həmin sətir orada yoxdursa, daha çox yaddaş heç nəyi dəyişmir.

WordPress nüvəsini yenidən quraşdırmayın. Nüvə faylları hər quraşdırmada bayt-bayt eynidir. Əgər problem nüvədə olsaydı, yer üzündəki hər WordPress saytının indi sınmış redaktoru olardı. Nasazlıq demək olar ki, həmişə plaginlərinizdə və ya mövzunuzdadır və nüvəni yenidən quraşdırmaq heç nəyi düzəltmədən nəyisə üzərinə yazmaq riski daşıyır.

Keş plagininizi ilk addım kimi kor-koranə təmizləməyin və ya söndürməyin. Aqressiv JS minifikasiyası və birləşdirilməsi redaktoru sındıra bilər, ona görə də test etməyə dəyər — amma təsadüfi keş təmizləməyə başlamazdan əvvəl konsolu yoxlayın. Təxmin etmək beş dəqiqəlik həllin bir günortaya çevrilməsinin yoludur.

Hələ də ilişmisiniz?

Əgər konsol təmizdirsə, REST API keçərli JSON qaytarırsa və plagin və mövzunun tam bölmə yoxlaması hələ də redaktoru ölü buraxırsa, cavab demək olar ki, həmişə debug.log-da oturur. WP_DEBUG_LOG-u aktivləşdirin, nasazlığı bir dəfə yenidən yaradın və nəticədə yaranan fatal xətanı error log decoder alətindən keçirin. Stek izi faylın adını göstərir — oradan başlayın.