WordPress 7.1 iframe Post Editoru: Bloklarda Ne Kirilir

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ğunuz ne söylerse söylesin. Klasik temalar için son koşulları da kaldıran trunk PR’ı çoktan birleşti. Ajans işletiyorsanız ve müşterilerinizden 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üzdeki dört haftalık bir pencere var.

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ü.

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ız, bir sonraki majör sürümde altınızdan kayacak bir kod teslim ediyorsunuz.

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.

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ız 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ğunuz editör CSS’ini bu yolla kaydediyorsa, iframe tuvali onu asla göremez. Bunun yerine block.json içindeki editorStyle‘ı kullanın — dosya yolu iframe’in içine otomatik kopyalanır — ya da bir temadan add_editor_style() çağırın.

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ı istemezsiniz.

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’leyin. 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 elinizde olmasını istiyorsunuz.

İkinci tarama — yeniden üret. Ryan Welcher’ın Playground blueprint’lerinden birini açın, “kırık” sürümlerin el kitabının öngördüğü gibi başarısız olduğunu izleyin, sonra “düzeltilmiş” sürümlerin nasıl davrandığına bakın. Bunu müşteri koduna dokunmadan önce yapın. 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üretin. 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önderirseniz o kütüphanenin bakımcıları size teşekkür eder.

Dördüncü tarama — gerileme testi. Staging’e bir blok temayla WordPress 7.1 Beta 1 kurun, yamalı eklentinizi kurun ve müşterinin gerçekten kullandığı on gerçek sayfayı düzenleyin. Bir “Merhaba dünya” yazısına üç blok koyup test etmeyin. 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 eklemem. Bir eklenti bunu sunacak, iki hafta boyunca çekici olacak, sonra yükseltme yolu olmayan bir teknik borç olarak kalacak. Bloğu düzeltin, 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ız bir haftanızı yiyen türden bir değişiklik. Onunla staging’de kendi takviminizle karşılaşın, WordPress 7.1 yönettiğiniz 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.