Tabel konfigurasi global PrestaShop memudahkan rutinitas uninstall sebuah modul untuk menghapus pengaturan yang milik ekstensi lain yang sama sekali tidak terkait. Satu panggilan ke Configuration::deleteByName('width') dapat menghapus nilai lebar kustom toko lain, membuat pedagang bingung dan modul yang bermasalah tampak tidak berbahaya.

Mengapa tabel konfigurasi bersama itu penting

PrestaShop menyimpan pengaturan setiap modul dalam satu tabel yang hanya berisi kunci (key) dan nilai (value). Tabel tersebut tidak memiliki kolom yang mencatat modul mana yang membuat baris tersebut, dan tidak menerapkan konvensi penamaan apa pun. Akibatnya, dua modul yang kebetulan menggunakan kunci yang sama—misalnya “width” atau “API_DATE_FROM”—akan membaca dan menulis baris database yang sama. Penulisan terakhir yang menang, dan penghapusan apa pun setelahnya akan menghapus baris tersebut bagi kedua belah pihak.

Ketika kode uninstall berubah menjadi alat penghapus data

Metode uninstall yang umum terlihat seperti ini:

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

Tujuannya adalah untuk membersihkan konfigurasi modul itu sendiri, tetapi karena kuncinya tidak menggunakan namespace, pernyataan tersebut menghapus setiap baris bernama “width”. Tidak ada peringatan yang dicatat, tidak ada pengecualian (exception) yang dilemparkan; baris tersebut hilang begitu saja. Modul lain milik pedagang kehilangan pengaturannya secara diam-diam dan mungkin mulai berperilaku aneh.

Masalah ini menjadi sangat menjebak selama peningkatan versi (version upgrade). Seorang pengembang yang berpindah dari versi 1.0 ke 2.0 mungkin mulai menyimpan nilai di bawah kunci dengan awalan (prefix) seperti MY_MODULE_WIDTH. Untuk "membersihkan" entri lama yang tidak memiliki awalan, mereka menambahkan panggilan hapus ke rutinitas uninstall, dengan keyakinan bahwa mereka hanya menghapus data lama (legacy data). Kenyataannya, mereka juga menghapus ekstensi lain apa pun yang disimpan di bawah kunci generik yang sama.

Apa yang diungkap oleh audit

Audit terhadap 57 repositori modul publik mengungkapkan pola yang berulang:

  • Banyak modul menggunakan kunci generik seperti “width”, “height”, atau “API_DATE_FROM” tanpa awalan apa pun yang berasal dari nama modul.
  • Beberapa metode uninstall berisi panggilan Configuration::deleteByName yang menargetkan kunci-kunci generik ini.
  • Masalah ini tidak terbatas pada satu pengembang atau jenis modul tertentu; desain tabel bersama menjadikannya risiko sistemik.

Audit tersebut tidak menemukan log atau pesan kesalahan apa pun yang akan memperingatkan pemilik toko bahwa konfigurasi modul lain telah dihapus. Satu-satunya gejala adalah hilangnya pengaturan secara tiba-tiba yang mungkin dianggap pedagang sebagai masalah cache atau bug dalam kode mereka sendiri.

Praktik yang lebih aman bagi pengembang modul

  1. Gunakan namespace untuk setiap kunci – tambahkan nama teknis modul di depan setiap kunci konfigurasi (misalnya, my_module_width). Ini menciptakan pengenal unik tanpa bergantung pada kolom kepemilikan terpisah.
  2. Hindari menghapus kunci lama yang tidak memiliki awalan – membiarkan beberapa baris usang di dalam tabel hampir tidak memakan biaya penyimpanan dan menghilangkan risiko kerusakan tambahan (collateral damage).
  3. Verifikasi kepemilikan sebelum penghapusan – jika penghapusan benar-benar diperlukan, periksa terlebih dahulu apakah nilai kunci tersebut diatur oleh kode Anda sendiri (misalnya, simpan nilai penanda yang hanya diketahui oleh modul Anda).
  4. Audit metode uninstall – cari panggilan deleteByName di dalam basis kode. Setiap kemunculan harus diperiksa untuk memastikan bahwa kunci tersebut memiliki namespace yang unik.
  5. Dokumentasikan konvensi penamaan – sertakan panduan singkat dalam README modul agar kontributor di masa mendatang memahami pentingnya kunci dengan awalan.

Pengujian untuk penghapusan lintas-modul yang tidak disengaja

Cara praktis untuk menangkap bug sebelum mencapai toko yang aktif:

  • Isi (seed) tabel konfigurasi dengan kunci yang milik modul berbeda (misalnya, other_module_setting => test).
  • Jalankan rutinitas uninstall modul di lingkungan yang terkendali.
  • Pastikan (assert) bahwa kunci yang diisi tersebut masih ada setelah proses uninstall selesai.

Mengotomatiskan pemeriksaan ini dalam rangkaian unit-test modul memastikan bahwa setiap perubahan di masa mendatang yang memperkenalkan panggilan deleteByName yang tersesat akan menggagalkan pengujian, sehingga memicu peninjauan.

Apa yang harus diperhatikan oleh pemilik toko

Pemilik toko jarang melihat baris database internal, tetapi mereka dapat melihat gejalanya: setelah menonaktifkan atau menghapus modul, ekstensi lain tiba-tiba kembali ke pengaturan default. Jika itu terjadi, mintalah pengembang untuk memverifikasi bahwa kode uninstall modul menghormati tabel konfigurasi global. Mintalah daftar semua kunci konfigurasi yang digunakan modul; kunci apa pun tanpa awalan yang jelas adalah tanda bahaya (red flag).

Kesimpulan

Desain PrestaShop membuat tabel konfigurasi menjadi sumber daya bersama, dan rutinitas uninstall yang ceroboh dapat menghapus pengaturan modul lain tanpa jejak. Dengan melakukan namespacing pada kunci, menghindari pembersihan yang agresif, dan menambahkan pengujian sederhana yang melindungi entri asing, pengembang dapat mencegah hilangnya data secara diam-diam dan menjaga stabilitas toko merchant. Upaya yang diperlukan sangat minimal, namun biaya dari pengaturan yang hilang—keluhan pelanggan, tiket dukungan, dan reputasi yang rusak—bisa jauh lebih tinggi.