· kaynak dev.to (home feed)
WordPress 7.1, klasik editörleri ve ACF bloklarını iframe dışı tutan çekirdek kontrolünü kaldırdı
Bir geliştiricinin bildirdiğine göre WordPress 7.1, ACF v2 blokları mevcut olduğunda editör tuvalini iframe dışı tutan çekirdek kontrolünü sessizce kaldırdı; bu da ACF alanlarını kenar çubuğuna taşıdı ve bazı sitelerde blok kaydetmeyi bozdu.

Ne bozuldu
dev.to'da Max Soskind tarafından yayınlanan bir gönderiye göre, WordPress 7.1'e yükseltme bir müşteri sitesinin editör deneyimini bozdu. Advanced Custom Fields (ACF) ile oluşturulmuş özel bloklar, alan kontrollerini bir anda tuvalden alıp kenar çubuğuna taşıdı ve bir sitede bloklar tamamen kaydedilmemeye başladı — kullanıcıya hiçbir hata gösterilmeden. Soskind'in teşhisi: sorun ACF'de değil, blok editörünün çekirdek JavaScript'inde yapılan bir değişiklikte.
Ortadan kaybolan davranış
Soskind'in açıkladığına göre 7.0.x serisi boyunca editör, yazı tuvalini yalnızca yazıdaki her blok block API sürüm 3 veya daha yüksek bildirdiğinde bir iframe içine sarıyordu. ACF blokları varsayılan olarak block API v2 kullandığından, yazının herhangi bir yerinde tek bir ACF bloğu bulunması tüm tuvalin iframe dışı kalması için yeterliydi. Klasik editör tarzı iş akışları ve satır içi alan düzenlemesi kullanan siteler bu davranışa — çoğu zaman bu bağımlılığın varlığından habersiz olarak — bel bağlıyordu.
7.1'de bu kapı kalktı. Yazar, disableIframe tanımlayıcısının artık wp-includes/js/dist/ altındaki hiçbir dosyada görünmediğini ve editor.js dosyasının artık shouldIframe: true değerini sabit kodlanmış olarak geçtiğini bildiriyor. Pratikteki etkisi, yazı hangi block API sürümlerini içerdiğine bakılmaksızın tuvalin her zaman iframe içine alınması.
On saniyelik bir tanılama
Bir kurulumu doğrudan kontrol etmek için gönderi tek bir komut öneriyor:
grep -rl "disableIframe" wp-includes/js/dist/
Soskind'in pratik kuralı şu: dört eşleşen dosya, sitenin 7.0.x üzerinde olduğu ve eski kapı mantığının sağlam olduğu anlamına gelir; sıfır eşleşme ise kontrolün kaldırıldığını ve ACF alan yerleşiminin değişeceğini gösterir. Bozulma sessiz olduğundan — etkilenen site hiçbir kaydetme hatası üretmediğinden — kurulu çekirdek dosyalarını bu şekilde kontrol etmek, editör arayüzü üzerinden hata ayıklamaktan daha hızlı olabilir.
ACF'yi güncellemek neden yardımcı olmuyor
Soskind, ACF'yi güncellemenin eski iş akışını geri getirmeyeceğini açıkça belirtiyor. ACF'nin v3 bloklarının, yazdığına göre, satır içi düzenlemeyi geri getirmek yerine yeni düzenleme modelini benimsediğini; dolayısıyla bir eklenti güncellemesinin bozuk davranışı iframe'siz tuvali geri döndürmek yerine farklı bir davranışla değiştirdiğini söylüyor. Gönderi, çekirdek diff'i ve bir düzeltmeyi ele alan daha uzun bir incelemeye işaret ediyor, ancak dev.to özetinde çözümün kendisi ayrıntılı olarak anlatılmıyor.
Neden önemli
Bozulma deseni, sadece bu yükseltmenin ötesinde önemli. Editör iç yapısının örtük ve belgelenmemiş bir davranışı — block API sürümlerine bağlı iframe kapı mantığı — bir sürüm yükseltmesinde ortadan kayboldu ve ortaya çıkan hatalar kafa karıştırıcı biçimlerde kendini gösteriyor: alan panellerinin kenar çubuğuna taşınması ve hiçbir şey yapmadan sessizce sonuçlanan kaydetme işlemleri. Uzun ömürlü müşteri yapılarını sürdüren ajanslar için ders şu: wp-includes/js/dist/ altındaki derlenmiş editör paketleri istikrarlı bir sözleşme değil. Yukarıdaki grep komutu ucuz bir ön kontrol olarak da işlev görüyor: bir WordPress güncellemesinden sonra çalıştırın ve eşleşme sayısı değiştiyse, üretime dokunmadan önce bir staging kopyasında ACF düzenlemeyi ve kaydetmeyi regresyon testinden geçirin.
- #wordpress
- #acf
- #javascript
- #cms
- #debugging
İlgili yazılar
- Next.js 16.3, Turbopack geliştirme belleğini yüzde 90'a kadar düşürüyor ve deneysel Instant Navigations özelliğini ekliyor
- df -h boş alan gösterdiği hâlde yazma işlemleri başarısız oluyor: inode tükenmesi için saha rehberi
- Elementor Pro açığı CVE-2026-32475, WordPress sitelerine PHP web shell yüklemek için kullanılıyor