WordPress 7.1’de Özel HTML Bloğu Artık Düzenlenebilir

🇬🇧 English: Read this in English →

Özel HTML bloğu uzun süre blok editörünün “editörden vazgeçtiğin” köşesi oldu. İşaretlemeyi yapıştırırdın, önizleme için bir iframe alırdın ve tek bir kelimeyi değiştirmek isteyen her editörün kod kipini açması gerektiğini kabullenirdin. Gömülü araçlar ve üçüncü taraf parçacıkları için bu yeterliydi. Ama bir dil modeli hem tasarım işaretlemesini hem de müşterinin haftaya düzenlemek isteyeceği metni aynı bölümde üretmeye başladığı an, bu çözüm çöktü. Açık konuşayım: kara kutu bir bloğun içine yazılan içerik, bir hafta sonra destek talebine dönüşen içeriktir.

Ekip bu sorunun etrafında neredeyse bir yıldır dönüyor ve nedeni önemli. WordPress’te yapay zekâ destekli içeriğin bir gösteriden fazlası olması için, modelin yazdığı biçim, insanın aynı arayüzde, aynı kilitler ve izinlerle düzenleyebileceği bir şey olmak zorunda. Yoksa ajansın her salı bir talep almaya başlar. Ya yapay zekâ çıktısının kara kutu bir blok içine yazıldığını kabul edersin, ya da statik sarmalayıcıların ve düzenlenebilir yuvaların aynı düğümde yaşamasının bir yolunu bulursun. WordPress 7.1 ikinci yolu seçti.

Bu, alan rehberinde küçük görünecek ama bir yıl sonra üç dört iş akışını yeniden şekillendirecek sessiz geliştirici notlarından biri. Beta 4 yüzeyi sabitlemeden önce dikkatli okumaya değer.

Aslında ne değişti

23 Temmuz 2026’da Riad Benguella, Make/Core üzerinde Editable Blocks Inside the Custom HTML Block notunu yayımladı. Özdeki değişiklik şu: core/html bloğu artık gerçek iç blokların statik HTML işaretlemesiyle iç içe geçtiği içerikleri tutabiliyor. Statik sarmalayıcı hem tuvalde hem ön yüzde etkisiz (inert) görüntüleniyor. İç bloklar yerinde düzenleniyor ama kilitli — taşınamıyor, silinemiyor, yanına kardeş blok eklenemiyor. Serileştirme birebir aynı kalıyor, dolayısıyla veritabanındaki mevcut içeriğin etkilenmiyor.

Altyapı, Gutenberg PR #79115‘de yaşıyor; Riad Benguella tarafından açıldı, 29 Haziran 2026’da Gutenberg 23.6 kilometre taşına birleştirildi. PR, innerContent adında yeni bir blok desteği tanıtıyor: her null değerinin bir iç blok konumunu işaretlediği, statik HTML parçalarından oluşan bir dizi. Ayrıştırıcı bu diziyi ayrıştırılmış blokta tutuyor, serileştirici save çağırmak yerine parçaları serileştirilmiş iç bloklarla iç içe geçiriyor, yeni ve özel bir InnerContent editör bileşeni de statik işaretlemeyi etkisiz kılarak iç blokları kendi konumlarındaki <wp-inner-block-slot> yer tutucularına portalıyla taşıyor. Özel HTML bloğu aynı PR’da innerContent‘i koşulsuz benimsiyor — eski content özniteliği kalkıyor, tuvaldeki SandBox iframe’i yeni bileşenle değiştiriliyor ve kod kipi güncellemede yeniden ayrıştırılıyor; yapıştırdığın <!-- wp:* --> parçaları kipi bir sonraki kapatışında düzenlenebilir iç bloklara dönüşüyor.

İki hafta sonra, yine aynı yazarın PR #79659‘u innerContent‘i blok varyantlarına taşıdı; 2 Temmuz 2026’da yine Gutenberg 23.6’ya birleştirildi. core/html‘in varyantları artık kendi statik sarmalayıcısını ve düzenlenebilir yuvalarını tanımlayabiliyor. 22 Temmuz tarihli Gutenberg 23.6 sürüm yazısı her iki PR’ı listeliyor ve tamamlayıcı bir düzeltme (#79887) blok Grup veya Sütunlara dönüştürüldüğünde innerContent‘i koruyor. Tüm bu yüzey, 15 Temmuz’da sabitlenen ve 19 Ağustos 2026’da genel sürüme çıkacak Beta döngüsü üzerinden WordPress 7.1’e taşınıyor.

Geliştirici notundaki kayıt şöyle görünüyor:

wp.blocks.registerBlockVariation( 'core/html', {
  name: 'testimonial-card',
  title: 'Testimonial Card',
  icon: 'format-quote',
  innerContent: [ '<div class="testimonial-card">', null, '</div>' ],
  innerBlocks: [
    [ 'core/paragraph', { content: 'İlham verici bir alıntı.' } ],
  ],
} );

Sarmalayıcı tanımlandığı gibi kalıyor. İçindeki paragraf yerinde düzenleniyor. Bir editör paragrafı yeniden yazarsa varyant tanımlanabilir kalmaya devam ediyor çünkü statik işaretleme değişmedi. Biri statik işaretlemeyi düzenlerse varyant devre dışı bırakılıyor — PR açıklamasına göre bu bilinçli bir tercih. Bence de doğru tercih: sözleşmeyi bozan editöre sessizce izin vermek yerine, açıkça “artık bu varyant değil” demek uzun vadede daha az sürpriz üretir.

İşin özü: kod ile içeriği aynı düğümde ayırmak

Bir dakikalığına manşetten geri çekilip mekanizmaya bakalım, çünkü asıl kıymetli olan orada. Yıllardır bir kartın “sabit kalması gereken kabuğu” ile “editörün dokunacağı içi” iki ayrı dünyada yaşadı. Kabuğu bir özel bloğa, bir kısa koda, bir sayfa oluşturucu modülüne gömerdin; içi ise ya ayrı bir alanda ya da editörün asla bulamadığı bir ACF kutusunda dururdu. innerContent‘in yaptığı şey bu ikisini tek serileştirilmiş düğümde, ama farklı yetkilerle bir arada tutmak. Kabuk etkisiz, iç düzenlenebilir ama kilitli. Bu ayrımı doğru kurmak kulağa küçük geliyor, ama bir editör arayüzünün en zor problemlerinden biridir.

Ben olsam bunu “yeni bir blok tipi” diye değil, “editöre güvenle ne kadar alan bırakabileceğimin ayarı” diye okurdum. Fazla alan bırakırsan editör tasarımı bozar; az bırakırsan her küçük değişiklik için sana gelir. innerContent, o ayarı ilk kez çekirdek düzeyinde, tahmine dayanmayan bir sözleşmeyle veriyor.

WordPress ve WooCommerce ekipleri için neden önemli

7.1 çıktığı gün üç somut şey kolaylaşıyor.

Birincisi, yapay zekâ üretimi sayfa bölümleri artık salt okunur olmaktan çıkıyor. Bir referans kartı, ürün vurgusu veya iki sütunlu bir özellik bloğu üretmesi istenen bir model, keyfi işaretlemeyi müşterinin ileride yeniden yazmak isteyeceği metinlerin düzenlenebilir yuvalarıyla karıştıran tek bir Özel HTML bloğu üretebiliyor. Özel blok geliştirmek yok, ACF alan bağlantısı yok, kısa kod sarmalayıcısı yok. Sadece registerBlockVariation ve modelin hedefleyeceği bir JSON tanımı. WordPress çekirdeğinin bir dil modelinin güvenle içine yazabileceği ve editörün dokunamayacağı yetim kod üretmeyeceği bir şekil edinmesi ilk kez oluyor.

İkincisi, ajanslar bir müşteri her hafif markalanmış kart istediğinde özel blok üretmek zorunda kalmıyor. Tasarım sistemi işaretlemesi varyantta yaşıyor, editörler tam olarak dokunmaları gereken alanları görüyor ve tüm yapı veritabanında tek bir blok olarak serileştiriliyor. Özel bloktan varyanta geçiş yolu artık bir yönde önemsiz (varyantlar, salt sarmalayıcı ve yuva tabanlı özel blokların yerini alıyor) ve diğer yönde değişmemiş kalıyor (gerçek etkileşimli bloklar hâlâ gerçek blok hak ediyor).

Üçüncüsü sıkıcı ama gerçek: Özel HTML bloğu tuval önizlemesinde artık betik çalıştırmıyor. Eski SandBox iframe’i gitti, yerine satır içi olay dinleyicilerini soyan ve betik yürütmeyi engelleyen etkisiz bir görüntüleyici geldi. Editör içinde canlı üçüncü taraf betiklerinin önizlemesine bel bağlayan her iş akışının 7.1 genel sürümünden önce Playground’da denenmesi gerekiyor. Sitelerin çoğu farkı hissetmeyecek. Bir avuç eski panel hissedecek.

WooCommerce çerçevesi küçük ama not etmeye değer. Woo bugün Özel HTML’ye yaslanan bir blok göndermiyor, ancak pek çok mağaza ürün açıklama sayfalarında gömülü garanti tabloları, teknik özellik sayfaları ve yasal alt bilgiler için bu bloğu kullanıyor. Bunlar çalışmaya devam ediyor — mevcut içerik için serileştirme bayt bayt aynı — ve artık o teknik özellik tabloları kısa kod icat etmeden tek bir düzenlenebilir fiyat hücresine sahip olabilecek. 28 Temmuz’daki WooCommerce 11.0 penceresi ile 19 Ağustos’taki WordPress 7.1 penceresini ayrı tut; ikisini aynı sıralama kuyruğuna koyma.

Ne yapardım, ne yapmazdım

Bu hafta, Gutenberg 23.6 veya bir WordPress 7.1 Beta yapısıyla hazırlanmış bir hazırlık ortamında üç hızlı denetim çalıştır.

Bir, her eklenti ve temayı @wordpress/components‘ten alınan SandBox içe aktarımı ve Özel HTML tuval önizlemesinin JavaScript çalıştıracağını varsayan tüm editör betikleri için tara. Eski bir analitik paneli veya gömme parçacığı bu davranışa güveniyorsa şimdi yamala veya 7.1 genel sürümünden itibaren editörlerde bozuk bir önizlemeyi kabul et. Ön yüz etkilenmiyor.

İki, aslında sarmalayıcı artı bir iki RichText alanından ibaret olan bir özel bloğu al ve onu bir Özel HTML varyantına dönüştür. Farkı ölç. 300 satır JavaScript artı bir derleme adımı, 40 satır varyant kaydına düşüyorsa bu, tasarım sisteminin geri kalanı için göç sinyalindir. Her şeyi göç ettirmeye acele etme — önce en düz olan durumları seç.

Üç, yol haritanda yapay zekâ destekli bir yazım entegrasyonu varsa, üzerine inşa edilecek yüzey burası. Modele kayıtlı varyantlardan oluşan küçük bir kütüphane ver, ayrıştırıcının yakalayacağı blok sınırlayıcılı çıktı üretmeyi ona öğret ve iyi biçimlendirilmiş özel bloklar üretmesi için ikna etmeye çalışmayı bırak. Varyant sözleşmesi daha dar ve doğrulaması daha kolay.

Ne yapmam: halka açık depolara elli hazır pişirilmiş Özel HTML varyantı gönderen bir eklenti yayımlamak. Yüzey bir haftalık, ekleyicideki blok varyantı keşif arayüzü 5 Ağustos’taki RC 1’den önce yine değişecek ve bugün kaydettiğin herhangi bir varyant alan rehberinde çıkacak olana göre yeniden gözden geçirilmek zorunda kalacak. Yayımlamak istediğin her şey için RC 1’i bekle, hazırlık ortamındaki çalışmayı sürdür.

Yirmi yıl sonra da WordPress’i güncel tutan örüntü, gösterişli yeni blok değil. Platformun sessizce kod olması gerekenle içerik olması gereken arasındaki doğru dikişi bulup ikisinin de aynı dosyada yaşamasına izin vermesi. Bu hafta o dikiş bir tık daha ileri gitti, ve yapay zekâ üretimi içerik nihayet ona saygı gösteren bir şekle kavuştu.