WordPress Özel Modülünde wp_kses HTML Değişikliği Nasıl Test Edilir?

Kısa yanıt

WordPress özel modülünde wp_kses() kullanan bir akış varsa HTML ayrıştırıcısı değişmeden önce kayıt, görüntüleme ve düzenleme davranışını aynı içerik örnekleriyle test edin. Öncelik, kullanıcının gönderdiği HTML'nin güvenle süzülmesi ve beklenen içerik yapısının korunmasıdır. Yalnızca sayfanın açılması yeterli test değildir: Kaydedilen içerik ile sonradan görüntülenen çıktı arasında fark olabilir. WordPress çekirdek ekibi wp_kses() işleyişini HTML API üzerinde yeniden kurmayı değerlendiriyor; yayına alınacağı sürümü kesin kabul etmek yerine kullanılan çekirdek dalını ve değişiklik kaydını doğrulamak gerekir. Çekirdek ilerleme raporu bu hazırlığın kapsamını açıklıyor.

Bu test kimin için gerekli?

Özel alan, form, blok, editör uzantısı veya kullanıcıdan HTML alan bir eklenti geliştiriyorsanız akışınızı envantere alın. Yalnızca düz metin işleyen bir alanın aynı test yüküne ihtiyacı yoktur. İçerik editörü yapıştırılan biçimlendirmeyi korumayı bekliyorsa, bu beklentiyi tek tek öğeler düzeyinde yazın: bağlantı, liste, tablo, açıklama alanı ve izin verilen öznitelikler gibi. Böylece değişimi “sayfa bozuldu” gibi belirsiz bir şikâyetle değil, beklenen ve gerçekleşen çıktı karşılaştırmasıyla tartışabilirsiniz.

Özellikle ham HTML'nin veritabanına ne zaman yazıldığını ve hangi aşamada temizlendiğini ayırın. Bir proje girdiyi kaydederken süzebilir, diğeri çıktı üretirken süzebilir. Aynı örnek iki akışta farklı sonuç verebilir. Kodu inceleyip gerçek çağrı noktasını bulmadan güvenlik testini yalnızca editör ekranına bağlamayın. Bu çalışma, genel sürüm yükseltme planının içindeki tek bir davranış kontrolüdür; özel modül güncellemesinde staging ve geri dönüş planı daha geniş dağıtım sırasını ele alır.

Örnek içerik kümesini nasıl kurmalı?

Üretimde kişisel veri taşımayan temsilî örnekler hazırlayın. Her örneğe bir amaç ekleyin: normal paragraf ve bağlantı, bozuk kapanış etiketi, iç içe liste, görsel açıklaması, izin verilmeyen betik, beklenmedik öznitelik ve editörden yapıştırılmış karmaşık biçimlendirme. Beklenen sonucu elle tanımlayın. Güvenlik açısından kaldırılması gereken öğeyi “fark” diye otomatik hata saymayın; beklenmedik biçimde korunmasını da başarı saymayın. Normalleştirilen ama anlamı korunan HTML ile gerçekten kaybolan içerik birbirinden ayrılmalıdır.

Her vakada giriş değerini, uygulanan izinli HTML politikasını, temizlenmiş değeri ve tarayıcıda oluşan görünümü kaydedin. Karşılaştırma için iki ortamın aynı eklenti, tema ve PHP yapılandırmasına sahip olduğundan emin olun. Aksi halde görülen farkın çekirdek ayrıştırıcısından mı yoksa başka bileşenden mi kaynaklandığı belirsiz kalır. Ekran görüntüsü yardımcıdır; karar için asıl kanıt temizlenmiş HTML ve kullanıcıya görünen metindir.

Staging üzerinde uygulama sırası

Önce özel modülün HTML alanlarını listeleyin ve her biri için içerik sahipliği ile izinli öğeleri belirleyin. Ardından çekirdek değişikliğinin bulunduğu test dalını ayrı staging ortamında çalıştırın. Aynı örnekleri mevcut kararlı ortamda ve test ortamında girip çıktıları karşılaştırın. Çekirdek raporu, arayüzün yerinde korunmasının hedeflendiğini fakat önceki ayrıştırıcının kendine özgü davranışlarına bağlı kodlarda fark görülebileceğini söylüyor. Bu nedenle yalnızca fonksiyon imzasına bakarak uyumluluk kararı vermeyin.

Fark bulduğunuzda onu üç sınıfa ayırın: güvenlik bakımından beklenen temizlik, sunumda kabul edilebilir normalleştirme ve kullanıcı işini bozan kayıp. Son sınıfta giriş örneğini küçülterek tekrar üretin; sonra özel modülün izinli öğe listesini ve filtrelerini inceleyin. Bir düzeltmeyi üretime taşımadan editörün kaydetme, yeniden açma ve yayınlama adımlarını aynı örnekte yeniden deneyin. Tek seferlik başarılı kaydetme, sonraki düzenlemede içeriğin aynı kalacağını göstermez.

Riskli kısa yollar ve hata senaryoları

Temizleyiciyi tümüyle devre dışı bırakmak, istenmeyen HTML'yi içeriğe taşıyabilir. Geniş bir istisna listesi eklemek de izin sınırını anlaşılmaz hâle getirir. Bunun yerine gerçekten gerekli öğeyi belirleyin ve küçük, gözden geçirilebilir bir kuralla test edin. Çekirdek raporunda geçici eski ayrıştırıcı filtresi anılsa da bunun kalıcı bir uyumluluk sözleşmesi olmadığını aynı kaynak açıkça belirtiyor. Bu filtreyi uzun vadeli mimari olarak planlamayın.

Bir başka hata, tüm farkları yeni çekirdeğe atfetmektir. Eklenti filtresi, editörün serileştirmesi veya tema çıktısı sonucu değiştirebilir. Farkı çağrı noktasında ve son çıktı katmanında ayrı ayrı gözlemleyin. Kullanıcı metni kayboluyorsa, içerik örneğini ve beklenen sonucu geliştiriciye iletin; gerçek müşteri içeriğini herkese açık hata kaydına koymayın. WordPress geliştirici özeti de wp_kses() yeniden inşasını o ayın geliştirici gündemine alıyor.

Kabul kararı ve geri dönüş

Yayına geçiş için ölçüt, temsilî içeriklerin korunması, tehlikeli öğelerin süzülmesi ve kritik editör görevlerinin tamamlanmasıdır. Sonucu alan bazında kaydedin; “tüm site uyumlu” gibi geniş bir hüküm vermeyin. Canlıya alınacak WordPress sürümünde ilgili değişikliğin gerçekten bulunduğunu dağıtım gününde yeniden kontrol edin. Değişiklik henüz sürüme girmediyse test kaydını hazırlık olarak saklayın ve çekirdek duyurularını izleyin. Geri dönüş noktası, veritabanı yedeği ve modül sürümü dağıtımdan önce belirlenmelidir.

Webinle ile kapsam belirleme

Özel modülün HTML giriş ve çıktı yolları belirsizse, önce küçük bir içerik örnek kümesi ve kabul tablosu hazırlayın. Webinle web yazılım hizmeti üzerinden modülün çağrı noktaları, staging testi ve dağıtım sınırı için kapsam görüşmesi isteyebilirsiniz. Görüşmeye modül adı, kullanılan WordPress sürümü, anonimleştirilmiş örnek girdi ve beklenen görünümü getirmeniz, sorunu somutlaştırır. Bu kontrol sıralama vaadi değil; içerik bütünlüğü ile güvenli HTML işleme için teknik kabul çalışmasıdır.

Ekip içinde teslim edilecek kayıt

Testin sonunda her içerik örneği için kısa bir karar satırı oluşturun: alan adı, girişin amacı, önceki çıktı, yeni çıktı, farkın sınıfı, sorumlu kişi ve çözüm durumu. Farkı kabul ettiyseniz bunun neden güvenli ve kullanıcı açısından anlaşılır olduğunu yazın. Çözüm gerekiyorsa yalnızca ekran görüntüsü paylaşmak yerine yeniden üretim adımlarını ekleyin. Böyle bir kayıt, çekirdek sürümü değiştiğinde aynı testin tekrar edilmesini kolaylaştırır. Ayrıca editör ekibine hangi biçimlendirme davranışının değiştiğini açıkça duyurabilirsiniz.

Test içeriklerinin kalıcı canlı yazılara dönüşmesini engelleyin. Staging ortamında örnek hesabın yetkilerini sınırlayın ve test sonunda anonim örnekleri temizleyin. Geçiş gününde birkaç gerçek fakat gizli tutulan içerik tipini de yayın sonrası gözle kontrol edin. Burada amaç bütün site için kesin bir uyumluluk iddiası kurmak değil, kritik HTML yollarında değişimin etkisini görünür kılmaktır.