PrestaShop च्या ग्लोबल कॉन्फिगरेशन टेबलमुळे (global configuration table), एखाद्या मॉड्यूलच्या अनइन्स्टॉल प्रक्रियेमुळे (uninstall routine) पूर्णपणे असंबंधित एक्स्टेंशन्सचे (extensions) सेटिंग्ज सहजपणे पुसले जाऊ शकतात. Configuration::deleteByName('width') या एका कॉलमुळे दुकानाच्या दुसऱ्या कस्टम 'width' व्हॅल्यूचा डेटा पुसला जाऊ शकतो, ज्यामुळे व्यापारी गोंधळून जातो आणि तो मॉड्यूल निरुपद्रवी वाटू शकतो.
शेअर केलेल्या कॉन्फिगरेशन टेबलचे महत्त्व का आहे
PrestaShop प्रत्येक मॉड्यूलचे सेटिंग्ज एकाच टेबलमध्ये साठवते, ज्यामध्ये फक्त 'key' आणि 'value' असते. या टेबलमध्ये कोणती रो (row) कोणत्या मॉड्यूलने तयार केली आहे, हे नोंदवणारा कोणताही कॉलम नसतो आणि ते कोणत्याही नेमिंग कन्व्हेन्शनचे (naming convention) पालन करत नाही. परिणामी, जर दोन मॉड्यूल्सनी चुकून एकच की (key) वापरली—उदा. “width” किंवा “API_DATE_FROM”—तर ते एकाच डेटाबेस रोला वाचतील आणि त्यात बदल करतील. जो शेवटचा बदल (write) होईल तो ग्राह्य धरला जातो, आणि त्यानंतर होणारी कोणतीही 'delete' क्रिया दोन्ही मॉड्यूल्ससाठी ती रो काढून टाकते.
जेव्हा अनइन्स्टॉल कोड डेटा पुसण्याचे साधन बनतो
एक सामान्य अनइन्स्टॉल पद्धत (uninstall method) अशी दिसते:
public function uninstall()
{
return Configuration::deleteByName('width');
}
याचा उद्देश मॉड्यूलचे स्वतःचे कॉन्फिगरेशन स्वच्छ करणे हा असतो, परंतु की (key) नेमस्पेस केलेली (namespaced) नसल्यामुळे, ही कमांड “width” नावाचा कोणताही रो काढून टाकते. यासाठी कोणताही इशारा (warning) दिला जात नाही किंवा कोणतीही एरर (exception) येत नाही; ती रो फक्त गायब होते. व्यापाऱ्याचे दुसरे मॉड्यूल शांतपणे आपले सेटिंग गमावते आणि विचित्रपणे वागू लागते.
व्हर्जन अपग्रेड (version upgrade) दरम्यान ही समस्या अधिक गंभीर होते. जो डेव्हलपर व्हर्जन 1.0 वरून 2.0 वर जातो, तो MY_MODULE_WIDTH सारख्या प्रीफिक्स असलेल्या की (prefixed key) अंतर्गत व्हॅल्यूज सेव्ह करण्यास सुरुवात करू शकतो. जुन्या, प्रीफिक्स नसलेल्या एन्ट्रीज "स्वच्छ" करण्यासाठी, ते अनइन्स्टॉल रूटीनमध्ये 'delete' कॉल जोडतात, असा त्यांचा विश्वास असतो की ते फक्त जुना (legacy) डेटा काढत आहेत. प्रत्यक्षात, ते त्याच जेनेरिक की अंतर्गत साठवलेले इतर एक्स्टेंशन्सचा डेटा देखील डिलीट करत असतात.
ऑडिटमध्ये काय समोर आले
५७ सार्वजनिक मॉड्यूल रिपॉझिटरीजच्या (repositories) ऑडिटमध्ये एक वारंवार आढळणारा पॅटर्न दिसून आला:
- अनेक मॉड्यूल्स मॉड्यूलच्या नावावरून कोणताही प्रीफिक्स न वापरता “width”, “height”, किंवा “API_DATE_FROM” सारख्या जेनेरिक की (generic keys) वापरतात.
- अनेक अनइन्स्टॉल पद्धतींमध्ये
Configuration::deleteByNameकॉल आहेत जे या जेनेरिक की ला लक्ष्य करतात. - ही समस्या केवळ एका डेव्हलपरपुरती किंवा विशिष्ट प्रकारच्या मॉड्यूलपुरती मर्यादित नाही; शेअर केलेल्या टेबल डिझाइनमुळे हा एक प्रणालीगत धोका (systemic risk) बनला आहे.
ऑडिटमध्ये असे कोणतेही लॉग्स किंवा एरर मेसेज आढळले नाहीत, जे दुकान मालकाला हे सूचित करतील की दुसऱ्या मॉड्यूलचे कॉन्फिगरेशन काढून टाकले गेले आहे. याचे एकमेव लक्षण म्हणजे सेटिंग्ज अचानक गमावणे, ज्याचे कारण व्यापारी कॅशे (cache) समस्या किंवा त्यांच्या स्वतःच्या कोडमधील बग मानू शकतात.
मॉड्यूल डेव्हलपर्ससाठी सुरक्षित पद्धती
- प्रत्येक की (key) नेमस्पेस करा – प्रत्येक कॉन्फिगरेशन की च्या सुरुवातीला मॉड्यूलचे तांत्रिक नाव जोडा (उदा.
my_module_width). यामुळे वेगळ्या ओनरशिप कॉलमवर अवलंबून न राहता एक युनिक आयडेंटिफायर तयार होतो. - जुन्या, प्रीफिक्स नसलेल्या की डिलीट करणे टाळा – टेबलमध्ये काही जुन्या रो (rows) राहिल्याने स्टोरेजवर कोणताही परिणाम होत नाही आणि अनपेक्षित नुकसानीचा धोकाही टळतो.
- डिलीट करण्यापूर्वी मालकी तपासा – जर डिलीट करणे खरोखर आवश्यक असेल, तर प्रथम ती की व्हॅल्यू तुमच्या स्वतःच्या कोडद्वारे सेट केली गेली आहे की नाही हे तपासा (उदाहरणार्थ, एक मार्कर व्हॅल्यू साठवा जी फक्त तुमच्या मॉड्यूलला माहित असेल).
- अनइन्स्टॉल पद्धतींचे ऑडिट करा – कोडबेसमध्ये
deleteByNameकॉल शोधा. प्रत्येक वेळी की युनिकली नेमस्पेस केलेली आहे की नाही हे तपासण्यासाठी त्याची पडताळणी करा. - नेमिंग कन्व्हेन्शनचे दस्तऐवजीकरण करा – मॉड्यूलच्या README मध्ये एक छोटी मार्गदर्शक सूचना समाविष्ट करा, जेणेकरून भविष्यातील योगदानकर्त्यांना प्रीफिक्स असलेल्या की चे महत्त्व समजेल.
चुकून होणाऱ्या क्रॉस-मॉड्यूल डिलीशनसाठी टेस्टिंग
लाइव्ह शॉपपर्यंत पोहोचण्यापूर्वी बग पकडण्याचा एक व्यावहारिक मार्ग:
- कॉन्फिगरेशन टेबलमध्ये दुसऱ्या मॉड्यूलची की 'सीड' (seed) करा (उदा.
other_module_setting=>test). - नियंत्रित वातावरणात (controlled environment) मॉड्यूलचे अनइन्स्टॉल रूटीन चालवा.
- अनइन्स्टॉल पूर्ण झाल्यानंतर ती सीड केलेली की अजूनही अस्तित्वात आहे याची खात्री करा.
मॉड्यूलच्या युनिट-टेस्ट सुईटमध्ये (unit-test suite) ही तपासणी स्वयंचलित केल्यामुळे, भविष्यात कोणताही बदल ज्यामुळे चुकून deleteByName कॉल येईल, तो टेस्टमध्ये फेल होईल आणि रिव्ह्यूसाठी प्रवृत्त करेल.
दुकान मालकांनी काय लक्ष दिले पाहिजे
स्टोअर मालकांना अंतर्गत डेटाबेस रो क्वचितच दिसतात, परंतु ते लक्षण ओळखू शकतात: एखादे मॉड्यूल डिसेबल किंवा अनइन्स्टॉल केल्यानंतर, दुसरे एक्स्टेंशन अचानक डिफॉल्ट सेटिंग्जवर येते. असे घडल्यास, डेव्हलपरला मॉड्यूलचा अनइन्स्टॉल कोड ग्लोबल कॉन्फिगरेशन टेबलचा आदर करतो की नाही हे तपासण्यास सांगा. मॉड्यूल वापरत असलेल्या सर्व कॉन्फिगरेशन की ची यादी मागा; ज्या की ला स्पष्ट प्रीफिक्स नाही, ती धोक्याची घंटा (red flag) आहे.
मुख्य निष्कर्ष
PrestaShop ची रचना कॉन्फिगरेशन टेबलला एक सामायिक संसाधन (shared resource) बनवते, आणि अनियंत्रित अनइन्स्टॉल प्रक्रिया (uninstall routine) दुसऱ्या मॉड्यूलची सेटिंग्ज कोणताही पुरावा न सोडता पुसून टाकू शकते. कीजना (keys) नेमस्पेसिंग करून, आक्रमक क्लीनअप टाळून आणि परकीय नोंदींचे (foreign entries) संरक्षण करणारी एक साधी चाचणी जोडून, डेव्हलपर्स डेटाचे गुप्त नुकसान टाळू शकतात आणि व्यापाऱ्यांची दुकाने स्थिर ठेवू शकतात. यासाठी लागणारा प्रयत्न नगण्य आहे, परंतु सेटिंग्ज गमावल्यामुळे होणारे नुकसान—ग्राहकांच्या तक्रारी, सपोर्ट तिकीट आणि खराब झालेली प्रतिष्ठा—अत्यंत जास्त असू शकते.