Sorun Giderme

WordPress Düzenleyici Beklenmeyen Bir Hatayla Karşılaştı

7 dk okuma

Kısa cevap"Düzenleyici beklenmeyen bir hatayla karşılaştı" mesajı, blok düzenleyicinin (Gutenberg) sunucuyla REST API üzerinden konuşurken geçerli bir yanıt alamadığı anlamına gelir. En sık nedenler eklenti çakışması, bozuk kalıcı bağlantılar, güvenlik duvarının isteği engellemesi ve sunucunun JSON yerine hata metni döndürmesidir. Tarayıcı konsolundaki ağ isteğine bakmak, nedeni tahmin etmeden bulmanızı sağlar.

WordPress düzenleyici beklenmeyen bir hatayla karşılaştı uyarısı genellikle bir yazıyı kaydederken, yayımlarken ya da yeni bir sayfa açarken çıkar. Mesajın kendisi bilgi vermez, ama arkasındaki mekanizma basittir: blok düzenleyici, içeriği kaydetmek ve okumak için sitenizin /wp-json/ adresine istek atar. Bu istek başarısız olursa ya da yanıt bozuksa düzenleyici "Yanıt geçerli bir JSON yanıtı değil" gibi bir ayrıntıyla birlikte hata verir. Aşağıda önce teşhis yöntemini, sonra nedenlere göre sıralı çözümleri bulacaksınız. Önce teşhis edip sonra müdahale etmek, eklentileri körlemesine kapatmaktan çok daha az risklidir.

Düzenleyici neden beklenmeyen bir hatayla karşılaşır?

Blok düzenleyici bir React uygulamasıdır ve sunucuyla konuşmak için WordPress REST API'sini kullanır. Kaydet düğmesine bastığınızda tarayıcı, /wp-json/wp/v2/posts/ID gibi bir adrese JSON gönderir ve JSON bekler. Bu zincirde şu noktalar kırılabilir:

  • REST API erişilemiyor: kalıcı bağlantı kuralları bozuk, .htaccess eksik ya da bir güvenlik katmanı isteği reddediyor (403, 404).
  • Sunucu hatası: PHP'de ölümcül hata ya da bellek yetersizliği nedeniyle yanıt 500 dönüyor.
  • Bozuk JSON: yanıt 200 dönüyor ama başına ya da sonuna PHP uyarısı, boşluk karakteri veya HTML ekleniyor. Bu, hata gösterimi açıkken bir eklentinin uyarı üretmesiyle olur.
  • Eklenti veya tema çakışması: editör betiklerini bozan bir eklenti ya da eski bir tema.
  • Adres uyuşmazlığı: WordPress adresi ile site adresi farklıysa (örneğin biri http, diğeri https) istekler yanlış adrese gider.

Hatanın kaynağını konsoldan nasıl bulurum?

Hatayı yeniden üretmeden önce tarayıcınızın geliştirici araçlarını açın (F12). "Network" (Ağ) sekmesinde "Fetch/XHR" filtresini seçin, sonra düzenleyicide Kaydet'e basın. Kırmızı görünen isteğe tıklayın ve üç şeye bakın: durum kodu, yanıt gövdesi ve istek adresi. Her sonuç farklı bir yöne işaret eder.

GördüğünüzAnlamıÖnce bakılacak yer
403 ForbiddenGüvenlik duvarı (WAF), ModSecurity ya da Cloudflare kuralı isteği engelliyorHosting güvenlik günlüğü, Cloudflare Security Events
404 Not FoundREST rotası bulunamıyor, kalıcı bağlantı kuralları bozukAyarlar > Kalıcı Bağlantılar, .htaccess
500 Internal Server ErrorPHP ölümcül hatası ya da bellek yetersizliğidebug.log, hosting hata günlüğü
200 ama yanıt HTML ya da uyarı metniJSON bozuk, çıktıya fazladan metin karışmışHata gösterimi ve eklenti uyarıları
Failed / CORS hatasıİstek başka bir adrese gidiyor, http/https veya www uyuşmazlığıAyarlar > Genel, adres alanları

Konsol sekmesinde (Console) ayrıca Uncaught TypeError gibi JavaScript hataları görürseniz, sorun REST yerine editör betiğini bozan bir eklentidir. Hata satırında geçen dosya yolu (wp-content/plugins/eklenti-adi/...) çoğu zaman suçlu eklentiyi doğrudan söyler.

REST API çalışıyor mu, nasıl test ederim?

Tarayıcıda https://siteadresiniz.com/wp-json/ adresini açın. Çalışan bir sitede uzun bir JSON metni görürsünüz. 404 sayfası, boş sayfa veya HTML görüyorsanız REST API sorunu doğrulanmış demektir. Kalıcı bağlantılar sorunluysa şu alternatif adres de çalışır: https://siteadresiniz.com/?rest_route=/. Bu adres JSON döndürüp ilki 404 veriyorsa sorun kesin olarak yeniden yazma (rewrite) kurallarındadır.

WordPress'in kendi denetimini de kullanabilirsiniz. Araçlar > Site Sağlığı ekranı, REST API ve döngü (loopback) isteklerinin başarısını sınar. Orada "REST API bir hata ile karşılaştı" ya da "Siteniz bir döngü isteğini tamamlayamadı" gibi bir uyarı varsa, düzenleyici hatasının nedeni büyük olasılıkla sunucu ya da güvenlik katmanıdır. Bu ekranın bütün uyarılarını Site Sağlığı rehberinde ayrı ayrı anlattık.

Çözümü hangi sırayla denemeliyim?

En az riskli ve en çok işe yarayandan başlayıp ilerleyin. Her adımdan sonra düzenleyiciyi yenileyip tekrar kaydetmeyi deneyin.

  1. 1Tarayıcı ve önbelleği temizleyin. Gizli pencerede deneyin. Cloudflare veya bir önbellek eklentisi kullanıyorsanız önbelleği boşaltın. Eski, önbellekten gelen bir betik yeni WordPress sürümüyle çakışabilir.
  2. 2Kalıcı bağlantıları yeniden kaydedin. Ayarlar > Kalıcı Bağlantılar sayfasına gidin ve hiçbir şeyi değiştirmeden Değişiklikleri Kaydet'e basın. Bu işlem yeniden yazma kurallarını sıfırdan oluşturur ve 404 kaynaklı REST sorunlarının büyük bölümünü çözer. WP-CLI ile aynı işlem: wp rewrite flush.
  3. 3Adresleri kontrol edin. Ayarlar > Genel'de WordPress Adresi ile Site Adresi aynı şemayı (https) ve aynı alan adını (www ya da www'suz) kullanmalı.
  4. 4Eklentileri dışlayın. Düzenleyiciyi etkileyecek tek eklentiyi bulmak için hepsini devre dışı bırakıp tek tek açın. Yönetim paneline girebiliyorsanız eklenti sayfasından, giremiyorsanız FTP ile wp-content/plugins klasörünün adını değiştirerek yapabilirsiniz. Klasörü eski adına çevirmeden önce Eklentiler sayfasını (plugins.php) bir kez açın, yoksa WordPress eklentileri yeniden etkin sayar (ayrıntısı güncelleme sonrası site bozuldu rehberinde).
  5. 5Temayı değiştirin. Varsayılan bir temaya (Twenty Twenty-Five gibi) geçici olarak geçip sorunun sürüp sürmediğine bakın.
  6. 6Bellek limitini artırın. Konsolda 500 görüyorsanız ve günlükte bellek hatası varsa, wp-config.php dosyasına limiti ekleyin (aşağıda).
  7. 7Güvenlik duvarını kontrol edin. 403 alıyorsanız hosting panelinden ModSecurity günlüğüne ya da Cloudflare panelinde Security > Events bölümüne bakın, engelleyen kuralı bulun.
define( 'WP_MEMORY_LIMIT', '256M' );

Bu satırı /* That's all, stop editing! */ yorumundan önce ekleyin. WordPress belgelerine göre varsayılan limit tek siteli kurulumda 40 MB'tır, bazı ağır editör kullanımlarında bu sınıra çarpmak mümkündür. Sunucunun kendi PHP limiti daha düşükse bu satır tek başına yetmez, hostinginizden memory_limit değerini yükseltmesini isteyin.

"Yanıt geçerli bir JSON yanıtı değil" hatası ne anlama gelir?

Bu ayrıntı mesajı, sunucunun 200 döndürdüğü ama gövdenin geçerli JSON olmadığı durumdur. Tipik sebep, PHP uyarılarının (notice, warning) ekrana basılması ve bunların JSON'un başına eklenmesidir. Hata ayıklama modu açık ve hata gösterimi etkinse bir eklentinin ürettiği tek bir "Deprecated" satırı bütün yanıtı bozar.

Çözüm, hataları ekrana yazdırmayı kapatıp dosyaya yönlendirmektir. wp-config.php içinde şu satırları kullanın ve ardından günlükte asıl uyarının hangi eklentiden geldiğine bakın:

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

Bu ayarların güvenli kullanımını ve günlüğün nasıl okunacağını WP_DEBUG rehberinde ayrıntılı anlattık. Bir diğer nadir sebepwp-config.php ya da tema functions.php dosyasının sonundaki fazladan boşluk veya ?> sonrası satır sonudur. Çıktıya karışan tek bir boş satır bile JSON'u bozabilir.

Acil yazı yayımlamam gerekiyor, geçici yol var mı?

Evet. Nedeni bulana kadar klasik düzenleyiciye dönebilirsiniz. Eklentiler > Yeni Ekle'den "Classic Editor" eklentisini kurup etkinleştirin. Alternatif olarak, temanın functions.php dosyasına ya da küçük bir eklentiye şu filtreyi ekleyebilirsiniz:

add_filter( 'use_block_editor_for_post', '__return_false' );
Bunu kalıcı çözüm saymayın
Klasik düzenleyici blok içeriğini bozmaz ama REST API sorunu ortadan kalkmış olmaz. Aynı sorun yönetim panelindeki diğer bölümleri, mobil uygulamaları ve entegrasyonları da etkiliyor olabilir. Sorun çözülünce filtreyi kaldırın.

Düzeltirken siteyi bozmamak için ne yapmalıyım?

Eklenti kapatmak, wp-config.php düzenlemek ve kalıcı bağlantı kurallarını yeniden yazmak küçük işlerdir ama canlı sitede hata payı bırakır. Başlamadan önce güncel bir yedeğiniz olsun. Hata bir güncellemenin hemen ardından başladıysa güncelleme sonrası site bozulduğunda izlenecek adımlar da işinize yarar. Sorunlu eklentiyi bulduysanız önceki sürüme dönmeyi eklenti güncellemesini geri alma rehberinden öğrenebilirsiniz. Düzenleyici değil de tüm site çöktüyse kritik hata sayfasına bakın.

Watch Your WP'nin "Güvenli güncelle" seçeneği güncellemeden önce yedek alır ve sorun çıkarsa dosyaları tek tıkla önceki sürüme çeker. Böylece bir güncellemenin düzenleyiciyi bozması durumunda geri dönüş yolunuz hazır olur. Bu özellik ücretsizdir.

Sık sorulan sorular

Hata yalnızca belirli bir yazıda çıkıyorsa ne olabilir?

Sorun genellikle o yazıdaki bir bloktan ya da çok büyük bir içerikten kaynaklanır. Yazıyı "Kod düzenleyici" görünümünde açıp şüpheli blokları kaldırmayı deneyin. Çok büyük gömülü görseller ya da uzun tablolar da isteği güvenlik duvarının boyut sınırına takabilir.

Cloudflare kullanıyorum, hata ona bağlı olabilir mi?

Olabilir. Cloudflare WAF kuralları veya bot koruması /wp-json/ isteklerini bazen engeller. Geçici olarak geliştirme modunu açıp önbelleği temizleyin ve Security > Events bölümünde engellenen isteklere bakın. Engelleyen kural görünüyorsa o rota için istisna tanımlayabilirsiniz.

Kalıcı bağlantıları kaydetmek içeriğime zarar verir mi?

Hayır, hiçbir şeyi değiştirmeden kaydetmek yalnızca yeniden yazma kurallarını yeniler. Ancak daha önce yapı değiştirdiyseniz URL'ler değişebilir, bu yüzden yapı seçimine dokunmayın.

Sorun hosting kaynaklıysa kime başvurmalıyım?

Konsolda 403 veya 500 görüyor ve eklentileri kapatmak işe yaramıyorsa hosting desteğine istek adresini, zamanını ve durum kodunu verin. Sunucu günlüğünde engelleme kuralı ya da PHP hatası aynı zaman damgasıyla görünecektir.

Güncelleme düzenleyiciyi bozduğunda geri dönün

Güvenli güncelle, güncellemeden önce yedek alır ve sorun çıkarsa dosyaları tek tıkla önceki sürüme çeker. Tamamen ücretsizdir ve sınırsız site için kullanılabilir.

Ücretsiz araç: sitenizi kontrol edin
Sitenizin SSL süresini, WordPress sürümünü, güvenlik başlıklarını ve yanıt süresini kayıt olmadan saniyeler içinde görün: ücretsiz WordPress site kontrolü.
Paylaş
Erdinç

Erdinç

Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.

LinkedIn