WordPress 7.2 SQL Oturum Modu Özel Modülde Nasıl Test Edilir?

Kısa yanıt: neyi test etmek gerekiyor?

WordPress 7.2 hazırlığında NO_BACKSLASH_ESCAPES SQL modunu kullanan özel eklenti veya veritabanı bağlantılarını test etmek gerekir. WordPress çekirdeğinin wpdb bağlantısı artık bu modu kendi oturumundan çıkaracak; sunucunun genel ayarı değişmeyecek. Bu nedenle kontrolün odağı yalnızca sitenin açılması olmamalı. Özel sorgular, sipariş ve teklif kayıtları, arama filtreleri ve WordPress dışından açılan ayrı bağlantılar aynı örnek verilerle sınanmalı. WordPress Core geliştirici notu değişikliğin kapsamını açıkça tanımlar.

Bu konu, genel bir WordPress yükseltme listesi değildir. Özel modül güncellemesinde staging ve geri dönüş planı genel yayın kontrolünü ele alır. Burada belirli bir SQL oturum davranışının uygulama verisine etkisini ölçmek için ayrı bir test tasarlanır.

Değişiklik neden özel yazılımı ilgilendirir?

WordPress, sorgularda özel karakterlerin kaçışında ters eğik çizgiden yararlanır. NO_BACKSLASH_ESCAPES etkin olduğunda MySQL bu karakteri kaçış karakteri gibi yorumlamaz. Resmî açıklama bu durumda bazı sorguların başarısız olabileceğini veya yanlış veri döndürebileceğini söyler. WordPress 7.2 ile wpdb::set_sql_mode() bu modu WordPress bağlantısının oturum listesinden çıkarır.

Bir kurumsal sitede sorun genellikle tek bir görünür hata mesajından ibaret değildir. Teklif formu başarı bildirimi gösterebilir; buna rağmen özel bir eklentinin ayrı bağlantıda yaptığı kayıt beklenen biçimde oluşmayabilir. Yönetim ekranındaki filtre, metninde tırnak veya ters eğik çizgi bulunan kayıtları farklı gösterebilir. Bunlar belirli bir müşteride yaşanmış olay iddiası değil, kabul testine alınması gereken olası hata örnekleridir.

Önce bağlantı haritasını çıkarın

İlk adım, sitenin veritabanıyla konuşan parçalarını yazmaktır. Çekirdek wpdb kullanımını, özel eklentinin doğrudan mysqli veya başka sürücüyle açtığı bağlantıyı ve harici uygulamanın kullandığı bağlantıyı ayrı satırlarda tutun. Her satır için bağlantıyı hangi kodun açtığını, oturum SQL modunun nerede belirlendiğini ve hangi iş verisini işlediğini kaydedin.

WordPress değişikliği yalnızca kendi veritabanı bağlantısının oturumunu etkiler; sunucu genelindeki SQL modunu değiştirmez. Dolayısıyla ayrı bağlantının otomatik olarak aynı davranışı alacağını varsaymayın. Bağlantı sayısı birden fazla olduğunda, her birinde etkin oturum modunu yetkili teknik kişiyle doğrulayın. Bu, gereksiz sunucu yapılandırması değişikliğini de önler.

Haritayı iş akışıyla bağlayın: ürün arama, üyelik kaydı, teklif talebi, sipariş notu, rapor dışa aktarma gibi işlemler hangi bağlantıyı kullanıyor? Teknik değişikliği kullanıcı sonucuna bağlamadan yapılan kontrol, yalnızca sunucu ayarının okunmasına dönüşür.

Staging ortamında kabul senaryosu kurun

Üretim verisini kopyalarken kişisel veriyi ve erişim anahtarlarını güvenli biçimde ayırın. Test için takma adlarla oluşturulmuş örnek kayıtlar yeterlidir. Her senaryoda giriş verisini, beklenen kayıt durumunu ve yönetim ekranında görülecek sonucu yazın. Özellikle tek tırnak, çift tırnak, ters eğik çizgi, Türkçe karakter ve boş değer içeren girdilere bakın. Bunlar yeni bir açık bulunduğu iddiası değildir; karakter işleme farkını görünür kılan sınır durumlarıdır.

Özel sorgu hazırlayan kodu ayrıca gözden geçirin. Değeri SQL metnine elle ekleyen yeri, güvenli parametreleme kullanan yerden ayırın. Testin amacı yalnızca sorgunun hata vermemesi değildir: kaydedilen değer geri okunduğunda aynı mı, filtre doğru kaydı buluyor mu, aynı işlem ikinci kez çalıştığında beklenen sonuç oluşuyor mu? Test sonucunu giriş ve çıktı örneğiyle kaydedin.

WordPress geliştirici blogu, 7.2 için test penceresini ve bu değişikliğin wpdb oturumuna etkisini Ekim 2026 özetinde açıklıyor. Bu yazı hazırlanırken 7.2'yi bütün canlı sitelerde kurulu bir sürüm olarak ele almıyoruz. Test ortamındaki çekirdek sürümünü ve kullanılan barındırma ayarını kayıt altına alın.

İstisna gerektiğinde karar nasıl verilir?

Bir özel iş akışının gerçekten NO_BACKSLASH_ESCAPES moduna dayandığı doğrulanırsa önce bu bağımlılığın neden var olduğunu açıklayın. Sorguyu güvenli ve WordPress ile uyumlu biçimde yeniden düzenlemek mümkünse kalıcı çözüm bunu değerlendirmektir. Sırf eski davranışı korumak için bütün siteye ayar uygulamak, hatayı başka akışa taşıyabilir.

WordPress Core, modu koruma gereksinimi için incompatible_sql_modes filtresinin db.php drop-in içinden kullanılabileceğini belirtir. Normal eklenti ve mu-plugin bu aşama için geç yüklenir. Aynı resmî not, çekirdeğin bu mod açıkken doğru çalışmayabileceği uyarısını yapar. Bu yüzden istisna bir varsayılan kurulum adımı değil, ölçülmüş bağımlılık ve kapsamlı regresyon testi sonrasında verilmiş geçici teknik karardır.

İstisna kararı alınırsa kim onayladı, hangi ortamda denendi, hangi sorgular kapsandı ve ne zaman kaldırılacağı yazılı olmalı. Üretimdeki sunucu genel ayarını değiştirmeden önce diğer uygulamaların aynı sunucuyu kullanıp kullanmadığı da belirlenmeli.

Hata olursa nasıl ayırırsınız?

Form gönderimi başarısızsa önce HTTP yanıtı, uygulama kaydı ve veritabanına yazılan değeri aynı işlem kimliğiyle karşılaştırın. Kayıt var ama yanlış görünüyorsa kaçış ve okuma sorgularını ayrı inceleyin. wpdb ile çalışan yol doğru, doğrudan açılan bağlantı hatalıysa iki oturumun SQL modunu karşılaştırın. Tersi durumda bağlantıyı değiştirmeden önce test sürümünün, eklenti kodunun ve örnek verinin eşit olduğuna bakın.

Bir hata yalnızca özel karakterli girişte görünüyorsa bunu genel performans sorunu gibi yorumlamayın. İşlem zincirindeki karakter dönüşümlerini kaydedin. Bir hata yalnızca dış entegrasyonda görünüyorsa WordPress çekirdeğinin davranışını bütün sistemin davranışı saymayın. Bu ayrım, çözümü doğru kod parçasına yöneltir.

Yayın kararı ve sonraki adım

Yayın öncesi kabul ölçütü somut olmalı: temel akışlar örnek girdilerle tamamlanmış, veriler geri okunmuş, ayrı bağlantıların oturum modu doğrulanmış, hata kayıtları incelenmiş ve geri dönüş adımı hazırlanmış olmalı. Değişiklikten sonra aynı senaryoları tekrar çalıştırın. Sonuçlar eşleşmiyorsa sürüm yükseltmesini erteleyip farkı teknik kayıtla çözün.

Özel modül, sipariş veya teklif akışınız varsa Webinle'nin kurumsal web yazılım hizmeti üzerinden mevcut bağlantı haritasını ve test kapsamını paylaşabilirsiniz. Böylece görüşme genel bir “WordPress güncellemesi” yerine hangi veri akışının korunacağı üzerinden ilerler.