WordPress veritabanında serileştirilmiş veri neden düz metin değiştirmeyle bozulabilir?

WordPress veritabanındaki bazı dizi ve nesneler, PHP’nin serileştirme biçimiyle tek bir metin alanında saklanır. Bu alanın içindeki metni SQL ile veya editörde doğrudan değiştirmek, serileştirilmiş veride tutulan metinlerin bayt uzunluklarını güncellemediği için veriyi okunamaz hâle getirebilir. Bu nedenle düz metin değiştirme yerine veriyi PHP ile açıp değiştirmek, ardından yeniden serileştirmek gerekir.

Serileştirilmiş veri nasıl çalışır?​

PHP, bir dizinin yalnızca değerlerini değil, veri türünü ve uzunluğunu da kaydeder. Basitleştirilmiş bir örnek şöyledir:

a:1:{s:4:"city";s:5:"Paris";}

Buradaki s:5, Paris değerinin 5 bayt uzunluğunda olduğunu belirtir. Paris yerine İstanbul yazılırsa değer 9 UTF-8 baytına çıkar (8 karakterdir; büyük İ iki bayttır). Yalnızca metni değiştirip s:5 bölümünü aynı bırakırsanız PHP, verinin nerede bittiğini yanlış hesaplar ve seriyi çözemeyebilir.

Uzunluk bilgisi yalnızca değerlerde bulunmaz. Dizi anahtarları, iç içe diziler ve bazı nesne özellikleri de aynı kurala bağlı olabilir. Türkçe karakterlerde karakter sayısı ile bayt sayısı da her zaman aynı değildir; bu yüzden uzunluğu elle düzeltmek güvenilir bir çözüm değildir.

Somut varsayımsal örnek​

Bir eklenti ayarının wp_options tablosunda şu şekilde tutulduğunu varsayalım:

a:2:{s:4:"name";s:5:"Paris";s:5:"theme";s:4:"blue";}

Veritabanında doğrudan Paris kelimesini İstanbul ile değiştirirseniz, ilgili uzunluk hâlâ s:5 olarak kalır. WordPress ayarı okurken unserialize() işlemi başarısız olabilir. Bunun sonucu ayarın varsayılan değere dönmesi, eklentinin hata vermesi veya ilgili seçeneğin tamamen kullanılamaması olabilir.

Aynı risk, bir URL’nin alan adını değiştirmede de vardır. URL serileştirilmiş bir dizinin içindeyse yalnızca SQL REPLACE() kullanmak uzunluk alanlarını bozar.

Tercih edilen WordPress yolu get_option ile değeri uygulama türünde almak, ilgili alanı değiştirip update_option ile kaydetmektir; meta için ilgili get/update_post_meta API’si kullanılır. Bu yardımcılar serileştirmeyi yönetir; değeri önce elle serialize edip update_option’a vermek çift serileştirmeye yol açabilir. Genel URL değişiminde kapsamı denetlenmiş WP-CLI search-replace --dry-run kullanılabilir.

Güvenli değiştirme yöntemi​

İşleme başlamadan önce veritabanı yedeğinin geri yüklenebilir olduğunu ve değişikliğin hangi tablo, seçenek veya meta kaydında yapılacağını belirleyin. Uygulanacak genel yöntem şöyledir:

1. Değişiklik yapılacak kaydı kesin olarak belirleyin. Aynı kelime başka eklenti ayarlarında veya içeriklerde de bulunabileceği için tüm veritabanında körlemesine arama yapmayın.
2. Serileştirilmiş değeri veritabanından olduğu gibi okuyun ve PHP ile seriden çıkarın. Güvenilir uygulama kaydı için WordPress’in veri API’lerini tercih edin. Güvenilmeyen kullanıcı girdisini doğrudan unserialize etmeyin; allowed_classes=false de bunu genel olarak güvenli hâle getiren bir garanti değildir.
3. Değişikliği artık dizi ya da nesne üzerinde uygulayın. Örneğin bir URL değerini dizinin ilgili anahtarında değiştirin; ham serileştirilmiş metni düzenlemeyin.
4. Güncellenen yapıyı yeniden serileştirin ve aynı kayda yazın. PHP bu aşamada yeni uzunluk bilgilerini kendisi üretir.
5. Değişiklikten sonra WordPress’in ilgili ayarı okuyabildiğini, eklentinin hata vermediğini ve beklenen değerin yönetim ekranında veya sitede göründüğünü kontrol edin.

Karar vermeyi kolaylaştırmak için değişiklik türlerini şöyle değerlendirebilirsiniz:


Bu ayrım önemlidir: Her veritabanı metni serileştirilmiş değildir. Basit bir başlık veya düz bir seçenek alanında düz metin değişikliği çalışabilir; ancak alanın içinde a:1:{, s:... gibi PHP serileştirme işaretleri görülüyorsa ham değişiklik yapmayın.

Sık yapılan hatalar​

1. Uzunluk bilgisini elle düzeltmeye çalışmak: Özellikle Türkçe karakterlerde bayt hesabı kolayca yanlış yapılır.
2. Tüm veritabanında sınırsız değiştirme yapmak: Aynı ifade farklı eklentilerde, önbelleklerde veya bağımsız metinlerde bulunabilir.
3. Yedeği doğrulamadan işlem yapmak: Bozulmuş bir seçeneği düzeltmek için geri dönüş yolu bulunmalıdır.
4. Yalnızca yönetim ekranına bakmak: Eklenti ayarı önbellekten geliyor olabilir; ilgili işlevi ve PHP hata kaydını da kontrol etmek gerekir.
5. Bozuk veriyi tekrar tekrar değiştirmek: Seri açılamıyorsa önce yedekten veya sağlam kaynaktan geri dönmek, bozuk metni zorla düzeltmeye çalışmaktan daha güvenlidir.

Kaynaklar​

• PHP: serialize
• PHP: unserialize güvenlik sınırı
• WordPress: update_option

Sık sorulan sorular​

Bir alanın serileştirilmiş olup olmadığını nasıl anlarım?​

Tek başına görünüş kesin kanıt değildir. Alanı uygulama üzerinden okuyup türünü kontrol etmek en güvenlisidir. Ham değerde PHP serileştirme biçimine benzeyen tür ve uzunluk işaretleri bulunması uyarı işaretidir; yine de bunu doğrulamadan SQL ile değiştirme yapmayın.

Düz değiştirmeden sonra eklenti ayarı kaybolduysa ne yapmalıyım?​

Önce yeni değişikliği durdurun ve ilgili kaydı yedekten geri yükleyin. Ardından değişikliği serileştirme-aware bir yöntemle, veriyi açıp yeniden kaydederek uygulayın. Hata devam ederse PHP hata kaydında serileştirme veya veri türü hatalarını kontrol edin.