Jadual konfigurasi global PrestaShop memudahkan rutin nyahpasang (uninstall) sesuatu modul untuk memadam tetapan yang milik sambungan (extension) lain yang tidak berkaitan sama sekali. Satu panggilan kepada Configuration::deleteByName('width') boleh memadam nilai lebar tersuai kedai lain, menyebabkan peniaga keliru dan modul yang menyebabkan masalah itu kelihatan tidak berbahaya.

Mengapa jadual konfigurasi kongsi ini penting

PrestaShop menyimpan tetapan setiap modul dalam satu jadual yang hanya memegang kunci (key) dan nilai (value). Jadual tersebut tidak mempunyai lajur yang merekodkan modul mana yang mencipta sesuatu baris, dan ia tidak menguatkuasakan sebarang konvensyen penamaan. Akibatnya, dua modul yang kebetulan menggunakan kunci yang sama—contohnya “width” atau “API_DATE_FROM”—akan membaca dan menulis baris pangkalan data yang sama. Penulisan terakhir akan menang, dan sebarang pemadaman kemudiannya akan memadam baris tersebut untuk kedua-dua pihak.

Apabila kod nyahpasang menjadi alat pemadam data

Kaedah nyahpasang tipikal kelihatan seperti ini:

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

Tujuannya adalah untuk membersihkan konfigurasi modul itu sendiri, tetapi kerana kunci tersebut tidak mempunyai ruang nama (namespace), pernyataan tersebut memadam sebarang baris yang dipanggil “width”. Tiada amaran dicatat, tiada pengecualian (exception) dicetuskan; baris tersebut hilang begitu sahaja. Modul peniaga yang lain kehilangan tetapan secara senyap dan mungkin mula berkelakuan pelik.

Masalah ini menjadi sangat berisiko semasa naik taraf versi. Seorang pembangun yang beralih dari versi 1.0 ke 2.0 mungkin mula menyimpan nilai di bawah kunci berawalan (prefixed key) seperti MY_MODULE_WIDTH. Untuk "membersihkan" entri lama yang tidak berawalan, mereka menambah panggilan pemadaman ke dalam rutin nyahpasang, dengan kepercayaan bahawa mereka hanya membuang data lama (legacy data). Hakikatnya, mereka juga memadam apa sahaja sambungan lain yang disimpan di bawah kunci generik yang sama.

Apa yang didedahkan oleh audit

Audit terhadap 57 repositori modul awam mendedahkan corak yang berulang:

  • Banyak modul menggunakan kunci generik seperti “width”, “height”, atau “API_DATE_FROM” tanpa sebarang awalan yang diambil daripada nama modul.
  • Beberapa kaedah nyahpasang mengandungi panggilan Configuration::deleteByName yang menyasarkan kunci generik ini.
  • Isu ini tidak terhad kepada pembangun tunggal atau jenis modul tertentu; reka bentuk jadual kongsi menjadikannya risiko sistemik.

Audit tersebut tidak menemui sebarang log atau mesej ralat yang akan memberi amaran kepada pemilik kedai bahawa konfigurasi modul lain telah dibuang. Satu-satunya simptom adalah kehilangan tetapan secara tiba-tiba yang mungkin dianggap oleh peniaga sebagai masalah cache atau pepijat (bug) dalam kod mereka sendiri.

Amalan yang lebih selamat untuk pembangun modul

  1. Gunakan ruang nama (namespace) untuk setiap kunci – letakkan nama teknikal modul di hadapan setiap kunci konfigurasi (contohnya, my_module_width). Ini mewujudkan pengenal pasti unik tanpa bergantung pada lajur pemilikan yang berasingan.
  2. Elakkan memadam kunci lama yang tidak berawalan – membiarkan beberapa baris usang dalam jadual hampir tidak memerlukan kos storan dan menghapuskan risiko kerosakan sampingan.
  3. Sahkan pemilikan sebelum pemadaman – jika pemadaman benar-benar perlu, semak terlebih dahulu sama ada nilai kunci tersebut ditetapkan oleh kod anda sendiri (sebagai contoh, simpan nilai penanda yang hanya diketahui oleh modul anda).
  4. Audit kaedah nyahpasang – cari panggilan deleteByName dalam kod sumber. Setiap kemunculan harus diperiksa untuk mengesahkan bahawa kunci tersebut mempunyai ruang nama yang unik.
  5. Dokumentasikan konvensyen penamaan – sertakan garis panduan ringkas dalam README modul supaya penyumbang masa hadapan memahami kepentingan kunci berawalan.

Menguji pemadaman silang-modul yang tidak disengajakan

Cara praktikal untuk menangkap pepijat ini sebelum ia sampai ke kedai yang sedang beroperasi:

  • Sediakan (seed) jadual konfigurasi dengan kunci yang milik modul berbeza (contohnya, other_module_setting => test).
  • Jalankan rutin nyahpasang modul dalam persekitaran yang terkawal.
  • Pastikan (assert) bahawa kunci yang disediakan itu masih wujud selepas proses nyahpasang selesai.

Mengautomasikan semakan ini dalam suite ujian unit (unit-test suite) modul memastikan sebarang perubahan masa hadapan yang memperkenalkan panggilan deleteByName yang tersasar akan menyebabkan ujian gagal, sekali gus mencetuskan semakan.

Apa yang perlu diperhatikan oleh pemilik kedai

Pemilik kedai jarang melihat baris pangkalan data dalaman, tetapi mereka boleh mengesan simptomnya: selepas menyahaktifkan atau menyahpasang sesuatu modul, sambungan lain tiba-tiba kembali ke tetapan lalai (default). Jika itu berlaku, minta pembangun untuk mengesahkan bahawa kod nyahpasang modul menghormati jadual konfigurasi global. Minta senarai semua kunci konfigurasi yang digunakan oleh modul tersebut; sebarang kunci tanpa awalan yang jelas adalah tanda amaran (red flag).

Rumusan

Reka bentuk PrestaShop menjadikan jadual konfigurasi sebagai sumber kongsi, dan rutin nyahpasang yang cuai boleh memadam tetapan modul lain tanpa dikesan. Dengan melakukan namespacing pada kunci, mengelakkan pembersihan yang agresif, dan menambah ujian ringkas yang melindungi entri asing, pembangun boleh mencegah kehilangan data secara senyap dan mengekalkan kestabilan kedai pedagang. Usaha yang diperlukan adalah minimum, tetapi kos akibat tetapan yang hilang—aduan pelanggan, tiket sokongan, dan reputasi yang terjejas—boleh menjadi jauh lebih tinggi.