PrestaShop'ın küresel yapılandırma tablosu, bir modülün kaldırma (uninstall) rutininin tamamen ilgisiz eklentilere ait ayarları silmesini kolaylaştırıyor. Configuration::deleteByName('width') şeklindeki tek bir çağrı, başka bir mağazanın özel genişlik değerini silebilir; bu da satıcıyı şaşkına çevirirken, soruna neden olan modülün zararsız görünmesine yol açar.

Paylaşılan yapılandırma tablosu neden önemlidir

PrestaShop, her modülün ayarlarını yalnızca bir anahtar (key) ve bir değer (value) tutan tek bir tabloda saklar. Tabloda, hangi satırı hangi modülün oluşturduğunu kaydeden bir sütun yoktur ve herhangi bir isimlendirme kuralı zorunlu tutulmaz. Sonuç olarak, tesadüfen aynı anahtarı kullanan —örneğin "width" veya "API_DATE_FROM"— iki modül, aynı veritabanı satırını okuyup yazacaktır. Son yazılan geçerli olur ve daha sonra yapılan herhangi bir silme işlemi her iki taraf için de satırı kaldırır.

Kaldırma kodunun bir veri silme aracına dönüştüğü durumlar

Tipik bir kaldırma (uninstall) yöntemi şuna benzer:

public function uninstall()
{
    return Configuration::deleteByName('width');
}

Amaç modülün kendi yapılandırmasını temizlemektir, ancak anahtar isimlendirilmiş bir alana (namespace) sahip olmadığı için bu ifade "width" adlı herhangi bir satırı siler. Hiçbir uyarı günlüğe kaydedilmez, hiçbir hata (exception) fırlatılmaz; satır sadece yok olur. Satıcının diğer modülü sessizce ayarını kaybeder ve tuhaf davranmaya başlayabilir.

Sorun, özellikle bir sürüm yükseltmesi sırasında riskli hale gelir. 1.0 sürümünden 2.0 sürümüne geçen bir geliştirici, MY_MODULE_WIDTH gibi ön ekli (prefixed) bir anahtar altında değerler kaydetmeye başlayabilir. Eski, ön eksiz girişleri "temizlemek" için, sadece eski verileri sildiklerini düşünerek kaldırma rutinine bir silme çağrısı eklerler. Gerçekte ise, aynı genel anahtar altında saklanan diğer tüm eklentileri de silmiş olurlar.

Denetim neyi ortaya çıkardı

57 halka açık modül deposunun denetimi, tekrarlanan bir kalıbı ortaya çıkardı:

  • Birçok modül, modül adından türetilen herhangi bir ön ek kullanmadan "width", "height" veya "API_DATE_FROM" gibi genel anahtarlar kullanıyor.
  • Birçok kaldırma yöntemi, bu genel anahtarları hedef alan Configuration::deleteByName çağrıları içeriyor.
  • Sorun tek bir geliştirici veya belirli bir modül türüyle sınırlı değil; paylaşılan tablo tasarımı bunu sistemsel bir risk haline getiriyor.

Denetim, bir mağaza sahibini başka bir modülün yapılandırmasının kaldırıldığı konusunda uyaracak herhangi bir günlük veya hata mesajı bulamadı. Tek belirti, satıcının bir önbellek (cache) sorununa veya kendi kodundaki bir hataya bağlayabileceği ayarların aniden kaybolmasıdır.

Modül geliştiricileri için daha güvenli uygulamalar

  1. Her anahtarı isimlendirilmiş bir alana (namespace) dahil edin – her yapılandırma anahtarının başına modülün teknik adını ekleyin (örneğin, my_module_width). Bu, ayrı bir sahiplik sütununa güvenmeden benzersiz bir tanımlayıcı oluşturur.
  2. Eski, ön eksiz anahtarları silmekten kaçının – tabloda birkaç eski satır bırakmanın depolama açısından neredeyse hiçbir maliyeti yoktur ve yan hasar riskini ortadan kaldırır.
  3. Silmeden önce sahipliği doğrulayın – eğer silme işlemi gerçekten gerekliyse, önce anahtar değerinin kendi kodunuz tarafından ayarlanıp ayarlanmadığını kontrol edin (örneğin, yalnızca modülünüzün bildiği bir işaretleyici değer saklayın).
  4. Kaldırma yöntemlerini denetleyin – kod tabanında deleteByName çağrılarını arayın. Anahtarın benzersiz bir şekilde isimlendirildiğini teyit etmek için her kullanım incelenmelidir.
  5. İsimlendirme kuralını belgeleyin – gelecekteki katkıda bulunanların ön ekli anahtarların önemini anlamaları için modülün README dosyasına kısa bir kılavuz ekleyin.

Yanlışlıkla modüller arası silmeleri test etme

Bir hatayı canlı bir mağazaya ulaşmadan yakalamanın pratik bir yolu:

  • Yapılandırma tablosuna farklı bir modüle ait bir anahtar ekleyin (örneğin, other_module_setting => test).
  • Modülün kaldırma rutinini kontrollü bir ortamda çalıştırın.
  • Kaldırma işlemi tamamlandıktan sonra eklenen anahtarın hala mevcut olduğunu doğrulayın (assert).

Bu kontrolün modülün birim test (unit-test) paketinde otomatikleştirilmesi, gelecekteki herhangi bir değişikliğin yanlışlıkla bir deleteByName çağrısı getirmesi durumunda testin başarısız olmasını ve bir inceleme yapılmasını sağlar.

Mağaza sahipleri nelere dikkat etmeli

Mağaza sahipleri veritabanı satırlarını nadiren görürler, ancak belirtiyi fark edebilirler: bir modülü devre dışı bıraktıktan veya kaldırdıktan sonra, başka bir eklenti aniden varsayılan ayarlara döner. Eğer bu gerçekleşirse, geliştiriciden modülün kaldırma kodunun küresel yapılandırma tablosuna saygı duyup duymadığını doğrulamasını isteyin. Modülün kullandığı tüm yapılandırma anahtarlarının bir listesini talep edin; net bir ön eki olmayan her anahtar bir risk işaretidir (red flag).

Özet

PrestaShop’un tasarımı, yapılandırma tablosunu paylaşılan bir kaynak haline getirir ve dikkatsiz bir kaldırma rutini, başka bir modülün ayarlarını iz bırakmadan silebilir. Anahtarları ad alanlandırarak, agresif temizlemeden kaçınarak ve yabancı girişleri koruyan basit bir test ekleyerek geliştiriciler, sessiz veri kaybını önleyebilir ve satıcıların mağazalarını kararlı tutabilir. Gereken çaba minimaldir, ancak kaybedilen bir ayarın maliyeti —müşteri şikayetleri, destek talepleri ve zedelenen itibar— çok daha yüksek olabilir.