PrestaShop-ன் உலகளாவிய உள்ளமைவு அட்டவணை (global configuration table), ஒரு மாட்யூல் (module) நீக்கப்படும் போது (uninstall routine), முற்றிலும் தொடர்பில்லாத பிற விரிவாக்கங்களின் (extensions) அமைப்புகளை எளிதாக அழித்துவிடும் சூழலை உருவாக்குகிறது. Configuration::deleteByName('width') என்ற ஒரு அழைப்பு, மற்றொரு கடையின் தனிப்பயன் அகல மதிப்பையும் (custom width value) அழித்துவிடக்கூடும். இதனால் வணிகர் குழப்பமடைவார், அதே சமயம் அந்த மாட்யூல் எந்தத் தவறும் செய்யாதது போலத் தோன்றும்.
ஏன் பகிரப்பட்ட உள்ளமைவு அட்டவணை முக்கியமானது
PrestaShop ஒவ்வொரு மாட்யூலின் அமைப்புகளையும் ஒரு அட்டவணையில் சேமிக்கிறது; இதில் ஒரு 'key' மற்றும் ஒரு 'value' மட்டுமே இருக்கும். எந்த மாட்யூல் ஒரு வரிசையை (row) உருவாக்கியது என்பதைக் குறிக்க அந்த அட்டவணையில் எந்தத் தூணும் (column) இல்லை, மேலும் அது எந்தப் பெயரிடும் முறையையும் (naming convention) கட்டாயப்படுத்தவில்லை. இதன் விளைவாக, ஒரே மாதிரியான 'key'-களைப் பயன்படுத்தும் (உதாரணமாக “width” அல்லது “API_DATE_FROM”) இரண்டு மாட்யூல்கள், ஒரே தரவுத்தள வரிசையை (database row) வாசிப்பதும் எழுதுவதும் செய்யும். கடைசியாக எழுதப்பட்ட தரவே இறுதியானது, மேலும்ப் பின்னரே செய்யப்படும் எந்த ஒரு நீக்கமும் (delete) இரு தரப்பினருடைய வரிசையையும் நீக்கிவிடும்.
எப்போது நீக்கும் குறியீடு (uninstall code) தரவை அழிக்கும் கருவியாக மாறுகிறது
ஒரு பொதுவான நீக்கும் முறை (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'-ன் கீழ் மதிப்புகளைச் சேமிக்கத் தொடங்கலாம். பழைய, முன்னொட்டு இல்லாத பதிவுகளை "சுத்தம் செய்ய", அவர்கள் பழைய தரவை மட்டுமே நீக்குகிறோம் என்று நம்பி, நீக்கும் முறைக்கு (uninstall routine) ஒரு 'delete' அழைப்பைச் சேர்க்கிறார்கள். உண்மையில், அவர்கள் அதே பொதுவான 'key'-ன் கீழ் சேமிக்கப்பட்ட இதர விரிவாக்கங்களின் தரவுகளையும் சேர்த்து அழித்துவிடுகிறார்கள்.
தணிக்கையில் (audit) கண்டறியப்பட்டவை
57 பொது மாட்யூல் களஞ்சியங்களின் (repositories) தணிக்கை ஒரு தொடர்ச்சியான முறையை வெளிப்படுத்தியது:
- பல மாட்யூல்கள் மாட்யூலின் பெயரிலிருந்து பெறப்பட்ட எந்த முன்னொட்டும் (prefix) இன்றி “width”, “height” அல்லது “API_DATE_FROM” போன்ற பொதுவான 'key'-களைப் பயன்படுத்துகின்றன.
- பல நீக்கும் முறைகளில் (uninstall methods), இந்த பொதுவான 'key'-களை இலக்காகக் கொண்ட
Configuration::deleteByNameஅழைப்புகள் உள்ளன. - இந்தப் பிரச்சனை ஒரு தனி டெவலப்பருக்கோ அல்லது ஒரு குறிப்பிட்ட வகை மாட்யூலுக்கோ மட்டும் உரியதல்ல; பகிரப்பட்ட அட்டவணை வடிவமைப்பு இதை ஒரு முறையான இடர் (systemic risk) ஆக்குகிறது.
மற்றொரு மாட்யூலின் உள்ளமைவு நீக்கப்பட்டதை ஒரு கடை உரிமையாளருக்குத் தெரிவிக்கும் வகையில் எந்தத் தரவுகளோ (logs) அல்லது பிழைச் செய்திகளோ (error messages) தணிக்கையில் காணப்படவில்லை. இதன் ஒரே அறிகுறி, அமைப்புகள் திடீரெனத் தொலைந்து போவதுதான்; இதை வணிகர் ஒரு கேச் (cache) பிரச்சனை அல்லது தனது சொந்தக் குறியீட்டில் உள்ள பிழை என்று நினைக்கக்கூடும்.
மாட்யூல் டெவலப்பர்களுக்கான பாதுகாப்பான நடைமுறைகள்
- ஒவ்வொரு 'key'-க்கும் ஒரு பெயரிடப்பட்ட பகுதியை (Namespace) உருவாக்குங்கள் – ஒவ்வொரு உள்ளமைவு 'key'-க்கும் முன்னால் மாட்யூலின் தொழில்நுட்பப் பெயரைச் சேர்க்கவும் (எ.கா.,
my_module_width). இது ஒரு தனி உரிமையாளர் தூணைச் (ownership column) சார்ந்து இருக்காமல், ஒரு தனித்துவமான அடையாளத்தை உருவாக்குகிறது. - பழைய, முன்னொட்டு இல்லாத 'key'-களை நீக்குவதைத் தவிர்க்கவும் – அட்டவணையில் சில காலாவதியான வரிசைகளை அப்படியே விடுவது சேமிப்புத் திறனைப் பாதிக்காது மற்றும் எதிர்பாராத பாதிப்புகளைத் தவிர்க்கும்.
- நீக்குவதற்கு முன் உரிமையைச் சரிபார்க்கவும் – நீக்குவது உண்மையிலேயே அவசியமென்றால், அந்த 'key'-ன் மதிப்பு உங்கள் சொந்தக் குறியீட்டால் அமைக்கப்பட்டதா என்பதை முதலில் சரிபார்க்கவும் (உதாரணமாக, உங்கள் மாட்யூலுக்கு மட்டுமே தெரிந்த ஒரு அடையாள மதிப்பைச் சேமித்து வைக்கலாம்).
- நீக்கும் முறைகளைத் தணிக்கை செய்யுங்கள் – குறியீட்டுத் தொகுப்பில் (codebase)
deleteByNameஅழைப்புகளைத் தேடுங்கள். ஒவ்வொரு முறையும் அந்த 'key' தனித்துவமான பெயரிடப்பட்ட பகுதியில் (uniquely namespaced) உள்ளதா என்பதை உறுதிப்படுத்த ஆய்வு செய்ய வேண்டும். - பெயரிடும் முறையைப் பதிவு செய்யுங்கள் – மாட்யூலின் README கோப்பில் ஒரு சிறிய வழிகாட்டுதலைச் சேர்க்கவும், இதன் மூலம் வருங்காலப் பங்களிப்பாளர்கள் முன்னொட்டுடன் கூடிய 'key'-களின் முக்கியத்துவத்தைப் புரிந்துகொள்வார்கள்.
தற்செயலான மாட்யூல் இடையேயான நீக்கங்களைக் கண்டறிய சோதனை செய்தல்
ஒரு நேரடித் தளத்திற்கு (live shop) செல்வதற்கு முன்பே பிழையைக் கண்டறிய ஒரு நடைமுறை வழி:
- உள்ளமைவு அட்டவணையைத் தயார் செய்யவும் (Seed) – மற்றொரு மாட்யூலுக்குச் சொந்தமான ஒரு 'key'-ஐக் கொண்டு (எ.கா.,
other_module_setting=>test) அட்டவணையைத் தயார் செய்யவும். - ஒரு கட்டுப்பாட்டுச் சூழலில் (controlled environment) மாட்யூலின் நீக்கும் முறையை இயக்கவும்.
- நீக்கும் செயல்முறை முடிந்த பிறகும், அந்தத் தயார் செய்யப்பட்ட 'key' இன்னும் இருக்கிறதா என்பதை உறுதிப்படுத்தவும் (Assert).
மாட்யூலின் யூனிட்-டெஸ்ட் தொகுப்பில் (unit-test suite) இந்தச் சரிபார்ப்பைச் தானியக்கமாக்குவதன் மூலம், எதிர்காலத்தில் ஏதேனும் ஒரு மாற்றம் தற்செயலாக deleteByName அழைப்பைச் சேர்த்தால், அது சோதனையில் தோல்வியடைந்து, ஒரு மறுஆய்வுக்கு வழிவகுக்கும்.
கடை உரிமையாளர்கள் எவற்றைக் கவனிக்க வேண்டும்
கடை உரிமையாளர்கள் தரவுத்தளத்தின் உட்புற வரிசைகளை (internal database rows) அரிதாகவே பார்ப்பார்கள், ஆனால் அறிகுறிகளைக் கண்டறிய முடியும்: ஒரு மாட்யூலை முடக்கிய பிறகு அல்லது நீக்கிய பிறகு, மற்றொரு விரிவாக்கம் திடீரென அதன் இயல்புநிலை அமைப்புகளுக்கு (default settings) மாறினால், அதை கவனிக்க வேண்டும். அவ்வாறு நடந்தால், மாட்யூலின் நீக்கும் குறியீடு உலகளாவிய உள்ளமைவு அட்டவணையைச் சரியாகப் பின்பற்றுகிறதா என்பதைச் சரிபார்க்க டெவலப்பரிடம் கேட்கவும். மாட்யூல் பயன்படுத்தும் அனைத்து உள்ளமைவு 'key'-களின் பட்டியலைக் கோரவும்; தெளிவான முன்னொட்டு இல்லாத எந்தவொரு 'key'-ம் ஒரு எச்சரிக்கை அறிகுறியாகும் (red flag).
முக்கியக் கருத்து
PrestaShop-ன் வடிவமைப்பு, அதன் உள்ளமைவு அட்டவணையை (configuration table) ஒரு பகிரப்பட்ட வளமாக மாற்றுகிறது, மேலும் கவனக்குறைவான நீக்கும் நடைமுறை (uninstall routine), மற்றொரு மாட்யூலின் அமைப்புகளை எந்தத் தடயமும் இன்றி அழித்துவிடக்கூடும். கீ-களை (keys) நேம்ஸ்பேசிங் (namespacing) செய்வதன் மூலமும், தீவிரமான சுத்திகரிப்பு நடவடிக்கைகளைத் தவிர்ப்பதன் மூலமும், மற்றும் பிற உள்ளீடுகளைப் பாதுகாக்கும் ஒரு எளிய சோதனையைச் சேர்ப்பதன் மூலமும், டெவலப்பர்கள் அமைதியான தரவு இழப்பைத் தடுக்கவும் வணிகர்களின் கடைகளைத் நிலையாக வைத்திருக்கவும் முடியும். இதற்குத் தேவைப்படும் முயற்சி மிகக் குறைவு, ஆனால் ஒரு அமைப்பை இழப்பதன் விளைவுகள்—வாடிக்கையாளர் புகார்கள், ஆதரவு டிக்கெட்டுகள் மற்றும் சேதமடைந்த நற்பெயர்—மிகவும் அதிகமாக இருக்கலாம்.