Açılmayan WordPress Blok Editörünü Düzeltin

Çoğu zaman açılmayan bir WordPress blok editörünün nedeni bir JavaScript hatasıdır — bir eklenti ya da temadan gelen tek bir bozuk script tüm React uygulamasını durdurur ve editör bir türlü yüklenmesini tamamlayamaz. Tarayıcınızın geliştirici konsolunu açın (F12 ya da Mac’te Cmd+Option+I), düzenleme ekranını yeniden yükleyin ve kırmızı hatayı okuyun. Bu hata neredeyse her zaman soruna yol açan dosyanın adını verir. O tek satır, hangi eklentiyi devre dışı bırakmanız gerektiğini söyler ve genellikle beş dakikadan kısa sürede yazmaya geri dönebilirsiniz. İnternette en sık önerilen üç çözüm WordPress’i yeniden kurmak, PHP memory limit değerini artırmak ve Klasik Editör’e geçmektir; ve bu üçü de genellikle yanlış hamledir.

Editör neden bu şekilde bozulur

Blok editörü (Gutenberg), wp-admin/post.php ve post-new.php içinde çalışan tek sayfalık bir React uygulamasıdır. WordPress bir dizi script paketini kuyruğa alır — wp-blocks, wp-element, wp-editor, wp-edit-post — ve uygulama wp.domReady() üzerinden başlatılır. JavaScript, yakalanmayan ilk istisnada çalışmayı durdurur. Yani editör başlatılırken kuyruğa alınmış herhangi bir script hata fırlatırsa, ondan sonrası da onunla birlikte ölür. Özenle hazırladığınız yazı alanı bomboş beyaz bir panele ya da “Editör beklenmeyen bir hatayla karşılaştı” mesajına dönüşür.

WordPress ayrıca varsayılan olarak yönetici scriptlerini daha az istekte birleştirir. Bu da bir eklentinin bozuk JS’inin, aynı paket içinde yüklenen alakasız scriptleri de aşağı çekebileceği anlamına gelir; işte bu yüzden suçlu, yalnızca davranışa bakarak her zaman anlaşılmaz. Ama konsola bakarak anlaşılır.

İkinci arıza türü ise farklı görünür: editör yüklenir, ama kaydederken “Güncelleme başarısız oldu. Yanıt geçerli bir JSON yanıtı değil.” hatası fırlatır. Bu bir JavaScript sorunu değildir. Editör, /wp-json/wp/v2/ adresindeki REST API ile konuşur ve geriye temiz bir JSON bekler. Bir eklenti ya da temanızın functions.php dosyası JSON’dan önce bir PHP notice, warning ya da fatal üretirse — veya bir güvenlik eklentisi REST rotasını engellerse, ya da bir yönlendirme eklentisi URL’yi yeniden yazarsa — yanıt kirlenir ve editör bunu ayrıştıramaz.

Nasıl düzeltilir, en hızlısı önce

1. Konsolu okuyun. DevTools açıkken hatayı yeniden oluşturun. Uncaught TypeError ... some-plugin/build/index.js gibi bir hata, doğrudan sorunlu eklentiyi işaret eder. Bu tek adım vakaların çoğunu çözer ve sizi körlemesine deneme yanılmadan kurtarır.

2. Tarayıcıyı eleyin. Sayfayı zorla yenileyin (Cmd/Ctrl+Shift+R), sonra eklentileri kapalı bir gizli pencerede deneyin. Reklam engelleyiciler ve gizlilik eklentileri bazen yönetici scriptlerini kesip atar. Gizli pencerede çalışıyorsa, sorun sitenizde değil, bir tarayıcı eklentisinde ya da bayat önbellektedir.

3. REST API’yi doğrudan kontrol edin — eğer “geçerli bir JSON değil” mesajını gördüyseniz. Tarayıcıda https://yoursite.com/wp-json/ adresini ziyaret edin. Karşınıza bir yığın JSON çıkmalı. Eğer HTML, bir 500 hatası ya da bir giriş yönlendirmesi görüyorsanız, hatanız işte budur — bir eklenti editörün kendisini değil, REST yanıtını bozuyordur.

4. Eklentilerinizi ikili aramayla test edin. Hepsini devre dışı bırakın, editörün yüklendiğini doğrulayın, sonra tekrar bozulana kadar teker teker etkinleştirin. wp-admin’e tamamen kilitlendiyseniz, bunu SFTP üzerinden klasörü yeniden adlandırarak yapın:

mv wp-content/plugins wp-content/plugins_off

Klasör ortadan kalkınca WordPress her şeyi devre dışı bırakır. Klasörün adını geri değiştirin, sonra eklentileri teker teker içeri alıp çıkarın.

5. Temayı test edin. Twenty Twenty-Four’e geçin. Bozuk editör JS’i kuyruğa alan ya da functions.php içinde PHP hatası fırlatan bir tema da aynı belirtileri üretir.

6. Logu açın ve gerçek hatayı okuyun. Özellikle REST/JSON arızaları için wp-config.php içinde debug’ı etkinleştirin:

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

Fatal hata, tam dosya ve satır numarasıyla birlikte wp-content/debug.log dosyasına yazılır. Eğer o stack trace karmaşıksa — isim uzayına sahip sınıf adları, require zincirleri, on satır trace altına gömülmüş bir fatal — hangi eklenti ve satırın gerçekten tetiklediğini sade bir dille görmek için bunu WordPress error log decoder aracımıza yapıştırın. İşte “bir şeyler bozuk” ile “şu eklentinin 214. satırı bozuk” arasındaki fark budur.

Script birleştirmenin gerçek suçluyu gizlediğinden şüpheleniyorsanız, konsol hatasının tam olarak tek bir dosyayı işaret etmesi için her scriptin ayrı ayrı yüklenmesini zorlayın:

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

Yapılmaması gerekenler

Klasik Editör eklentisini kurup işi bitmiş saymayın. Bu hiçbir şeyi düzeltmez — sadece blok editörünü gizler, böylece hatayı görmeyi bırakırsınız. Bozuk JavaScript ya da bozuk REST yanıtı hâlâ oradadır ve site editöründe, widget’larda ya da bir sonraki güncellemenizde sizi yine ısırır. Önce teşhis edin; blokları kullanmayı bırakma kararını bilinçli olarak verdiyseniz Klasik’e geçin.

PHP memory limit değerini refleksle artırmayın. İnternetin en gözde kopyala-yapıştır çözümüdür, ama boş bir editörün nedeni nadiren bellek tükenmesidir. Gerçek bellek tükenmesi belirli bir fatal fırlatır — “Allowed memory size of N bytes exhausted” — ve bunu debug.log içinde görürsünüz. O satır orada yoksa, daha fazla bellek hiçbir şeyi değiştirmez.

WordPress çekirdeğini yeniden kurmayın. Çekirdek dosyaları her kurulumda bayt bayt aynıdır. Sorun çekirdekte olsaydı, dünyadaki her WordPress sitesinin editörü şu anda bozuk olurdu. Kusur neredeyse her zaman eklentilerinizde ya da temanızdadır ve çekirdeği yeniden kurmak, hiçbir şeyi düzeltmezken bir şeylerin üzerine yazma riski taşır.

Önbellek eklentinizi körü körüne temizlemeyin ya da devre dışı bırakmayın — hele ki ilk adım olarak. Agresif JS küçültme ve birleştirme editörü bozabilir, o yüzden test etmeye değer — ama önbellekleri rastgele boşaltmaya başlamadan önce konsolu kontrol edin. Tahmin yürütmek, beş dakikalık bir çözümü koca bir öğleden sonraya çevirmenin yoludur.

Hâlâ takılı mı kaldınız?

Konsol temizse, REST API geçerli JSON döndürüyorsa ve eklenti ile temayı baştan sona ikili aramayla elediğiniz hâlde editör hâlâ ölüyse, cevap neredeyse her zaman debug.log içinde durmaktadır. WP_DEBUG_LOG’u etkinleştirin, hatayı bir kez yeniden oluşturun ve ortaya çıkan fatal’ı error log decoder aracından geçirin. Stack trace dosyanın adını verir — oradan başlayın.