WordPress 7.1 iframe Post Editoru: Bloklarda Ne Kirilir

🇬🇧 English: Read this in English →

Yazı editörü iki yıldır sessiz sedasız tam iframe’e doğru sürükleniyordu. 15 Temmuz’da bu sürüklenme takvime bağlandı. WordPress 7.1 Beta 1 yayınlandı ve her blok temada iframe zorunlu hâle geldi — bloğun ne söylerse söylesin. Klasik temalar için son koşulları da kaldıran trunk PR’ı çoktan birleşti. Ajans işletiyorsan ve müşterilerinden biri window ya da document‘a uzanan özel bir bloğa bel bağlıyorsa, nelerin kırıldığını öğrenmek için önümüzde dört haftalık bir pencere var. Bu pencereyi boşa harcama.

Bu filmi daha önce izledim. Meta kutular, WordPress 5.0 çıkar çıkmaz “sorunsuz çalışıyor”dan “lütfen bize üç ay verin, o eklentiyi düzeltelim”e geçmişti. iframe geçişi de kafiyeli: uzun süre sessiz, sonra bir anda değil. Bu sefer farkı, WordPress’in olağandışı yüksek sesle konuşmuş olması — Kasım 2025’te bir geliştirici notu, Şubat 2026’da bir tane daha, Gutenberg 22.6’da deneysel bir zorunluluk bayrağı, 6.9’da tarayıcı konsolunda uyarı, güncellenmiş bir block.json şeması ve şimdi de Ryan Welcher’ın 17 Temmuz’da yayınladığı, her hata kalıbının kırık ve düzeltilmiş sürümünü yan yana gösteren demo eklentili saha rehberi.

19 Ağustos’ta şaşıracak olanlar bunların hiçbirini okumamış olanlar. Geri kalanımızın bu hafta yapacak işi var.

Gerçekten yeni olan ne

Ella van Durpe’nin açtığı Gutenberg PR #74042 — “Post editor: always iframe” — 10 Temmuz 2026’da birleşti ve Gutenberg 23.6 ile yayınlandı; bu da WordPress 7.1 Beta 1’e geri taşınan eklenti sürümü. PR, editör tuvalini anlık olarak iframe modu içine ve dışına çevirip duran tema ve apiVersion koşullarını siliyor, EditorInterface içindeki artık ölü disableIframe prop’unu kaldırıyor ve switchToLegacyCanvas()‘ı işlevsiz bırakıyor.

Gerekçe PR’da yazıyor: “iframe ile iyi çalışmayan bloklardan çok, tutarsızlığın kendisi bozulmaya yol açıyor.” Bir kullanıcı eski bir blok eklediği anda kendisini sessizce iframe modundan çıkaran bir tuval, her zaman iframeli ve öngörülebilir bir tuvalden çok daha kötü. Bence bu doğru karar — belirsizlik, kötü ama tutarlı bir davranıştan her zaman daha pahalıdır.

Sürüm sorumlusu, 19 Ağustos’taki 7.1 GA için daha yumuşak bir inişe imza attı: blok temalar Beta 1’de tam iframe zorunluluğu görüyor, klasik temalar bir döngü daha WordPress 7.0 kurallarında kalıyor. Anne McCarthy bunun “bir döngü daha” için bir sabır süresi olduğunu, kalıcı bir muafiyet olmadığını açıkça söyledi. Bugün müşteriye klasik bir tema satıyorsan, bir sonraki majör sürümde altından kayacak bir kod teslim ediyorsun.

Yörünge Aki Hamano’nun 12 Kasım 2025 tarihli geliştirici notunda, Ella van Durpe’nin 24 Şubat 2026 tarihli notunda ve resmi Blok Editörü El Kitabı taşıma rehberinde izleniyor. Ryan Welcher’ın 17 Temmuz’da yayımladığı iframe-editor-examples eklentisi, hata kalıplarını çalışır bir sitede görmenin en hızlı yolu — her demo blok kırık ve düzeltilmiş bir çift olarak geliyor, üstelik iki Playground blueprint’i sayesinde hiç kimsenin herhangi bir şey kurması gerekmiyor.

Bunu daha önce gördüm: sandbox’ın dışına elini uzatamazsın

Bu iframe hikâyesindeki “kodun artık ana belgeyi göremiyor” cümlesi bana çok tanıdık geldi. Flash’ın actionscript’li günlerinde bir SWF, tarayıcıda kendi kapalı kutusunda çalışırdı. İçeriden dışarıdaki HTML sayfasının DOM’una öylece uzanamazdın; sayfayla konuşman gerekiyorsa ExternalInterface ya da eski fscommand üzerinden düzgün bir kapıdan geçerdin. O sınırı ilk öğrenişim acı vericiydi — “neden document’a erişemiyorum” diye saatlerce baktığımı hatırlıyorum, çünkü film kendi dünyasında oturuyordu, sayfanın değil.

iframe tuvali tam olarak aynı ders. Bloğun artık yönetici sayfasının içinde değil, kendi belgesinde yaşıyor. window ve document‘a çıplak elle uzandığında, komşu evin penceresinden bakıp neden kendi mutfağını göremediğine şaşırıyorsun. Otuz yıl önce sandbox bir Flash filmiydi; bugün bir iframe. Kural değişmedi: dışarıyla konuşacaksan doğru köprüyü kullan, duvarı yok saymaya çalışma.

WordPress ve WooCommerce dünyası için neden önemli

Şimdiye kadar staging’de gördüğüm hemen her kırılmayı beş hata kalıbı açıklıyor. Hiçbiri egzotik değil.

Global window ve document başvuruları. Bir edit fonksiyonunda window.innerWidth okuyan bir blok, artık tuvalin değil yönetici sayfasının genişliğini okuyor. Aynı şey window.addEventListener('resize', …) için de geçerli. 2019 ile 2024 arasında bir müşteri için yazdığın duyarlı önizleme aracının içinde büyük ihtimalle bunlardan biri var.

Belge düzeyinde olay dinleyicileri. Klasik “dışarı tıklayınca kapat” kalıbı yönetici document‘ına bağlanır. iframe içinde kullanıcı farklı bir belgeye tıklıyor. Açılır menü asla kapanmıyor. Müşteri “menü çalışmıyor” başlığıyla bir hata bildiriyor.

Yanlış belgeye yüklenen editör stilleri. enqueue_block_editor_assets stilleri yönetici sayfasına yükler. Bloğun editör CSS’ini bu yolla kaydediyorsa, iframe tuvali onu asla göremez. Bunun yerine block.json içindeki editorStyle‘ı kullan — dosya yolu iframe’in içine otomatik kopyalanır — ya da bir temadan add_editor_style() çağır.

Yönetici seçicilerini hedefleyen eski CSS. .wp-admin, #wpadminbar ya da .block-editor-page üzerinden yazılmış kurallar iframe içinde eşleşmiyor. Yönetici kenar çubuğunun genişliğini varsayan görüntü alanına dayalı hesaplar da öyle. Eskiden çalışan bir calc(100vw - 160px) şimdi taşıyor, çünkü iframe kendi görüntü alanını ölçüyor, yöneticininkini değil.

Üçüncü taraf kütüphaneler. İçe aktarma anında document.querySelector çağıran ya da window‘a uzanan her şey — eski sürükle-bırak kütüphaneleri, bazı grafik kütüphaneleri, birkaç tarih seçici — sessizce yönetici belgesine bakıp hiçbir şey bulamayacak. Teşhis etmesi bir tam gün yiyen hata bu, çünkü blok görünüşte çiziliyor, sadece yapması gereken etkileşimli işi yapmıyor.

WooCommerce mağazaları için risk daha çok dolaylı. Sepet ve Ödeme zaten iframe uyumlu. Endişe yönetici tarafında: ücretli bir eklentiden gelmiş, blok editörü öncesi JavaScript taşıyan ürün editörleri; 2020’de aceleyle yapılıp bir daha dokunulmayan özel alan arayüzleri; yazarı ortadan kaybolmuş bir pazarlama eklentisinin gönderdiği yönetici widget’ları. WooCommerce 11.0, 28 Temmuz’da düşüyor; WordPress 7.1, 19 Ağustos’ta düşüyor; ve iki geçişin aynı öncelik kuyruğunda oturmasını istemezsin.

Ne yapardım (ya da yapmazdım)

Bu hafta, sırayla dört tarama.

Birinci tarama — envanter. Her özel eklenti ve temayı window., document., document.body, document.querySelector; document ya da window üzerinde çağrılan addEventListener; ve block.json üzerinden değil de kayıt yapan her enqueue_block_editor_assets hook’u için grep’le. Her isabet bir aday. Her aday kırılmıyor — editor.php‘de çalışıp tuvale hiç dokunmayan bir global sorun değil — ama listenin elinde olmasını istiyorsun.

İkinci tarama — yeniden üret. Ryan Welcher’ın Playground blueprint’lerinden birini aç, “kırık” sürümlerin el kitabının öngördüğü gibi başarısız olduğunu izle, sonra “düzeltilmiş” sürümlerin nasıl davrandığına bak. Bunu müşteri koduna dokunmadan önce yap. Buradaki yarım saat, sonrasında “bu benim bloğum mu yoksa 7.1 mi” gününü kurtarır.

Üçüncü tarama — düzeltme kalıbı. Düzeltme neredeyse her zaman aynı: globallere uzanmak yerine bağlamı bloğun kendi DOM elemanından türet. document yerine element.ownerDocument. window yerine element.ownerDocument.defaultView. Çıplak bir useEffect yerine @wordpress/compose‘dan gelen useRefEffect, çünkü tuval yeniden bağlandığında ref’ler değişebiliyor. Eleman kabul etmeyen inatçı bir üçüncü taraf kütüphane için patch-package meşru bir kaçış kapısı — düzeltmeyi yukarı gönderirsen o kütüphanenin bakımcıları sana teşekkür eder.

Dördüncü tarama — gerileme testi. Staging’e bir blok temayla WordPress 7.1 Beta 1 kur, yamalı eklentini kur ve müşterinin gerçekten kullandığı on gerçek sayfayı düzenle. Bir “Merhaba dünya” yazısına üç blok koyup test etme. Hatalar kesişimlerde yaşıyor — anasayfadaki bir kaydırıcı, Hakkımızda sayfasındaki bir yorum bloğuyla CSS paylaşıyor; bir pazarlama eklentisi editör betiğini eski usul kaydettiği için bir geri sayım bloğu bozulmuş.

Yapmayacağım şey: Editörü zorla iframe modundan çıkaran bir filtre eklemek. Bir eklenti bunu sunacak, iki hafta boyunca çekici olacak, sonra yükseltme yolu olmayan bir teknik borç olarak kalacak. Bloğu düzelt, platformu değil. 7.1 Beta 1’i doğrudan üretimdeki bir WooCommerce mağazasında ya da bu ay gerçek kullanıcılara giden herhangi bir sitede de çalıştırmam. Beta 1 staging içindir.

iframe geçişi, sürüm notlarında küçük görünen ama soğuk karşılarsan bir haftanı yiyen türden bir değişiklik. Onunla staging’de kendi takviminle karşılaş, WordPress 7.1 yönettiğin her site için 19 Ağustos’un olaysız geçmesine dönüşür — ki bu döngü için hedeflenecek sonuç tam olarak bu.