PrestaShop-ന്റെ ഗ്ലോബൽ കോൺഫിഗറേഷൻ ടേബിൾ (global configuration table), ഒരു മോഡ്യൂളിന്റെ അൺഇൻസ്റ്റാൾ റൂട്ടീൻ (uninstall routine) തികച്ചും ബന്ധമില്ലാത്ത മറ്റ് എക്സ്റ്റൻഷനുകളുടെ സെറ്റിംഗുകൾ പോലും മായ്ച്ചുകളയാൻ എളുപ്പമാക്കുന്നു. Configuration::deleteByName('width') എന്ന ഒറ്റ കോൾ ഉപയോഗിച്ച് മറ്റൊരു ഷോപ്പിന്റെ കസ്റ്റം വിഡ്ത്ത് (width) വാല്യൂ പോലും മായ്ച്ചുകളയാൻ സാധിക്കും. ഇത് വ്യാപാരിയെ ആശയക്കുഴപ്പത്തിലാക്കുകയും, പ്രശ്നമുണ്ടാക്കിയ മോഡ്യൂൾ നിരുപദ്രവകാരിയാണെന്ന് തോന്നിപ്പിക്കുകയും ചെയ്യുന്നു.

എന്തുകൊണ്ടാണ് പങ്കിട്ട കോൺഫിഗറേഷൻ ടേബിൾ പ്രധാനമാകുന്നത്

PrestaShop ഓരോ മോഡ്യൂളിന്റെയും സെറ്റിംഗുകൾ ഒരു ടേബിളിൽ മാത്രമാണ് സൂക്ഷിക്കുന്നത്; ഇതിൽ ഒരു കീയും (key) വാല്യൂവും (value) മാത്രമേ ഉണ്ടാകൂ. ഏത് മോഡ്യൂളാണ് ഒരു റോ (row) നിർമ്മിച്ചതെന്ന് രേഖപ്പെടുത്തുന്ന ഒരു കോളം ഈ ടേബിളിൽ ഇല്ല, കൂടാതെ ഇത് പ്രത്യേകമായ ഒരു നെയിമിംഗ് കൺവെൻഷനും (naming convention) നിർബന്ധമാക്കുന്നില്ല. ഇതിന്റെ ഫലമായി, "width" അല്ലെങ്കിൽ "API_DATE_FROM" എന്നിങ്ങനെ ഒരേ കീ ഉപയോഗിക്കുന്ന രണ്ട് മോഡ്യൂളുകൾ ഒരേ ഡാറ്റാബേസ് റോ തന്നെ വായിക്കുകയും എഴുതുകയും ചെയ്യും. അവസാനമായി എഴുതപ്പെട്ട വാല്യൂ ആയിരിക്കും നിലനിൽക്കുക, കൂടാതെ പിന്നീട് നടത്തുന്ന ഏതൊരു ഡിലീറ്റും രണ്ട് മോഡ്യൂളുകളുടെയും റോ നീക്കം ചെയ്യും.

അൺഇൻസ്റ്റാൾ കോഡ് ഒരു ഡാറ്റാ-വൈപ്പിംഗ് ടൂളായി മാറുന്നപ്പോൾ

ഒരു സാധാരണ അൺഇൻസ്റ്റാൾ മെത്തേഡ് (uninstall method) ഇപ്രകാരമാണ്:

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

മോഡ്യൂളിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ ക്ലീൻ ചെയ്യുക എന്നതാണ് ഇതിന്റെ ഉദ്ദേശ്യം, എന്നാൽ കീ നെയിംസ്പേസ് (namespaced) ചെയ്തിട്ടില്ലാത്തതിനാൽ, "width" എന്ന് പേരുള്ള ഏതൊരു റോയും ഈ സ്റ്റേറ്റ്‌മെന്റ് നീക്കം ചെയ്യുന്നു. ഇതിന് മുന്നറിയിപ്പുകളോ എക്സെപ്ഷനുകളോ (exceptions) ലഭിക്കില്ല; ആ റോ വെറുതെ അപ്രത്യക്ഷമാകും. വ്യാപാരിയുടെ മറ്റ് മോഡ്യൂളുകൾക്ക് അവയുടെ സെറ്റിംഗുകൾ നിശബ്ദമായി നഷ്ടപ്പെടുകയും അവ വിചിത്രമായി പ്രവർത്തിക്കാൻ തുടങ്ങുകയും ചെയ്തേക്കാം.

ഒരു വേർഷൻ അപ്‌ഗ്രേഡിംഗ് സമയത്താണ് ഈ പ്രശ്നം കൂടുതൽ സംഭവിക്കുന്നത്. വേർഷൻ 1.0-ൽ നിന്ന് 2.0-ലേക്ക് മാറുന്ന ഒരു ഡെവലപ്പർ MY_MODULE_WIDTH പോലുള്ള ഒരു പ്രിഫിക്സ് (prefix) ഉള്ള കീ ഉപയോഗിച്ച് വാല്യൂകൾ സേവ് ചെയ്യാൻ തുടങ്ങുന്നുണ്ടാകാം. പഴയ, പ്രിഫിക്സ് ഇല്ലാത്ത എൻട്രികൾ "ക്ലീൻ അപ്പ്" ചെയ്യാൻ വേണ്ടി, അവർ പഴയ ഡാറ്റ മാത്രം നീക്കം ചെയ്യുകയാണെന്ന് കരുതി അൺഇൻസ്റ്റാൾ റൂട്ടീനിൽ ഒരു ഡിലീറ്റ് കോൾ ചേർക്കുന്നു. എന്നാൽ യഥാർത്ഥത്തിൽ, അതേ ജനറിക് കീ ഉപയോഗിച്ച് മറ്റ് എക്സ്റ്റൻഷനുകൾ സൂക്ഷിച്ചിട്ടുള്ള വിവരങ്ങളും അവർ ഇല്ലാതാക്കുന്നു.

ഓഡിറ്റിൽ കണ്ടെത്തിയത്

57 പബ്ലിക് മോഡ്യൂൾ റിപ്പോസിറ്ററികളുടെ ഓഡിറ്റ് നടത്തിയപ്പോൾ ഒരു ആവർത്തന പാറ്റേൺ കണ്ടെത്തി:

  • പല മോഡ്യൂളുകളും മോഡ്യൂളിന്റെ പേരിൽ നിന്നുള്ള പ്രിഫിക്സ് ഇല്ലാതെ "width", "height", അല്ലെങ്കിൽ "API_DATE_FROM" പോലുള്ള ജനറിക് കീകൾ ഉപയോഗിക്കുന്നു.
  • പല അൺഇൻസ്റ്റാൾ മെത്തേഡുകളിലും ഈ ജനറിക് കീകൾ ലക്ഷ്യമിടുന്ന Configuration::deleteByName കോളുകൾ അടങ്ങിയിരിക്കുന്നു.
  • ഈ പ്രശ്നം ഒരു പ്രത്യേക ഡെവലപ്പരെയോ മോഡ്യൂളിനെയോ മാത്രം പരിമിതപ്പെടുത്തിയിട്ടില്ല; പങ്കിട്ട ടേബിൾ ഡിസൈൻ ഇതിനെ ഒരു സിസ്റ്റമിക് റിസ്ക് (systemic risk) ആക്കി മാറ്റുന്നു.

മറ്റൊരു മോഡ്യൂളിന്റെ കോൺഫിഗറേഷൻ നീക്കം ചെയ്യപ്പെട്ടുവെന്ന് ഷോപ്പ് ഉടമയെ അറിയിക്കുന്ന തരത്തിലുള്ള ലോഗുകളോ (logs) എറർ മെസ്സേജുകളോ ഓഡിറ്റിൽ കണ്ടെത്തിയില്ല. സെറ്റിംഗുകൾ പെട്ടെന്ന് നഷ്ടപ്പെടുക എന്നത് മാത്രമാണ് ഇതിന്റെ ലക്ഷണമായി കാണുന്നത്; വ്യാപാരി ഇത് ഒരു കാഷെ (cache) പ്രശ്നമായോ അല്ലെങ്കിൽ സ്വന്തം കോഡിലെ ബഗ്ഗായോ തെറ്റിദ്ധരിച്ചേക്കാം.

മോഡ്യൂൾ ഡെവലപ്പർമാർക്കായി സുരക്ഷിതമായ രീതികൾ

  1. എല്ലാ കീകുകളും നെയിംസ്പേസ് ചെയ്യുക – ഓരോ കോൺഫിഗറേഷൻ കീക്കും മുന്നിലായി മോഡ്യൂളിന്റെ ടെക്നിക്കൽ പേര് ചേർക്കുക (ഉദാഹരണത്തിന്, my_module_width). ഇത് ഒരു പ്രത്യേക ഓണർഷിപ്പ് കോളം ഇല്ലാതെ തന്നെ ഒരു യുണീക് ഐഡന്റിഫയർ (unique identifier) സൃഷ്ടിക്കുന്നു.
  2. പഴയ, പ്രിഫിക്സ് ഇല്ലാത്ത കീകൾ ഡിലീറ്റ് ചെയ്യുന്നത് ഒഴിവാക്കുക – ടേബിളിൽ കുറച്ച് പഴയ റോകൾ നിലനിർത്തുന്നത് സ്റ്റോറേജ് ഉപയോഗത്തിൽ വലിയ മാറ്റമുണ്ടാക്കില്ല, കൂടാതെ ഇത് അപ്രതീക്ഷിതമായ നാശനഷ്ടങ്ങൾ ഒഴിവാക്കാനും സഹായിക്കും.
  3. ഡിലീറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഉടമസ്ഥാവകാശം പരിശോധിക്കുക – ഡിലീറ്റ് ചെയ്യേണ്ടത് അത്യന്താപേക്ഷിതമാണെങ്കിൽ, ആ കീയുടെ വാല്യൂ നിങ്ങളുടെ കോഡ് തന്നെയാണോ സെറ്റ് ചെയ്തതെന്ന് ആദ്യം പരിശോധിക്കുക (ഉദാഹരണത്തിന്, നിങ്ങളുടെ മോഡ്യൂളിന് മാത്രം അറിയാവുന്ന ഒരു മാർക്കർ വാല്യൂ സൂക്ഷിക്കുക).
  4. അൺഇൻസ്റ്റാൾ മെത്തേഡുകൾ ഓഡിറ്റ് ചെയ്യുക – കോഡ്ബേസിൽ deleteByName കോളുകൾക്കായി തിരയുക. ഓരോ തവണയും കീ യുണീക് ആയി നെയിംസ്പേസ് ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ പരിശോധിക്കേണ്ടതുണ്ട്.
  5. നെയിമിംഗ് കൺവെൻഷൻ ഡോക്യുമെന്റ് ചെയ്യുക – മോഡ്യൂളിന്റെ README ഫയലിൽ ഒരു ചെറിയ മാർഗ്ഗനിർദ്ദേശം ഉൾപ്പെടുത്തുക, അതുവഴി ഭാവിയിൽ ഈ പ്രോജക്റ്റിൽ പ്രവർത്തിക്കുന്നവർക്ക് പ്രിഫിക്സ് ഉള്ള കീകൾ ഉപയോഗിക്കേണ്ടതിന്റെ പ്രാധാന്യം മനസ്സിലാക്കാൻ സാധിക്കും.

അപ്രതീക്ഷിതമായ ക്രോസ്-മോഡ്യൂൾ ഡിലീഷനുകൾ പരിശോധിക്കാൻ

ഒരു ലൈവ് ഷോപ്പിൽ എത്തുന്നതിന് മുമ്പ് ഈ ബഗ്ഗ് കണ്ടെത്താനുള്ള പ്രായോഗികമായ വഴി:

  • മറ്റൊരു മോഡ്യൂളിന്റേതായ ഒരു കീ ഉപയോഗിച്ച് കോൺഫിഗറേഷൻ ടേബിൾ സീഡ് (seed) ചെയ്യുക (ഉദാഹരണത്തിന്, other_module_setting => test).
  • ഒരു നിയന്ത്രിത സാഹചര്യത്തിൽ (controlled environment) മോഡ്യൂളിന്റെ അൺഇൻസ്റ്റാൾ റൂട്ടീൻ പ്രവർത്തിപ്പിക്കുക.
  • അൺഇൻസ്റ്റാൾ പൂർത്തിയായ ശേഷവും ആ കീ നിലനിൽക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക (Assert).

മോഡ്യൂളിന്റെ യൂണിറ്റ്-ടെസ്റ്റ് സ്യൂട്ടിൽ (unit-test suite) ഈ പരിശോധന ഓട്ടോമേറ്റ് ചെയ്യുന്നത് വഴി, ഭാവിയിൽ അബദ്ധവശാൽ ഒരു deleteByName കോൾ വന്നാൽ ടെസ്റ്റ് പരാജയപ്പെടുകയും അത് പരിശോധിക്കാൻ പ്രേരിപ്പിക്കുകയും ചെയ്യും.

ഷോപ്പ് ഉടമകൾ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

ഷോപ്പ് ഉടമകൾ ഡാറ്റാബേസിലെ റോകൾ നേരിട്ട് കാണാറില്ല, എന്നാൽ ലക്ഷണങ്ങൾ തിരിച്ചറിയാൻ അവർക്ക് സാധിക്കും: ഒരു മോഡ്യൂൾ ഡിസേബിൾ ചെയ്യുകയോ അൺഇൻസ്റ്റാൾ ചെയ്യുകയോ ചെയ്തതിന് ശേഷം മറ്റൊരു എക്സ്റ്റൻഷൻ പെട്ടെന്ന് അതിന്റെ ഡിഫോൾട്ട് സെറ്റിംഗുകളിലേക്ക് മാറുന്നുണ്ടെങ്കിൽ അത് ശ്രദ്ധിക്കുക. അങ്ങനെ സംഭവിക്കുകയാണെങ്കിൽ, മോഡ്യൂളിന്റെ അൺഇൻസ്റ്റാൾ കോഡ് ഗ്ലോബൽ കോൺഫിഗറേഷൻ ടേബിളിനെ ബാധിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ ഡെവലപ്പറോട് ആവശ്യപ്പെടുക. മോഡ്യൂൾ ഉപയോഗിക്കുന്ന എല്ലാ കോൺഫിഗറേഷൻ കീകളുടെയും ലിസ്റ്റ് ചോദിക്കുക; വ്യക്തമായ പ്രിഫിക്സ് ഇല്ലാത്ത ഏതൊരു കീയും ഒരു അപകടസൂചനയാണ് (red flag).

ചുരുക്കം

PrestaShop-ന്റെ ഡിസൈൻ കോൺഫിഗറേഷൻ ടേബിളിനെ ഒരു പങ്കിട്ട റിസോഴ്‌സ് (shared resource) ആക്കി മാറ്റുന്നു, അതിനാൽ അശ്രദ്ധമായ ഒരു അൺഇൻസ്റ്റാൾ നടപടി മറ്റൊരു മോഡ്യൂളിന്റെ സെറ്റിംഗുകൾ യാതൊരു അടയാളവും അവശേഷിപ്പിക്കാതെ മായ്ച്ചുകളയാൻ ഇടയാക്കും. കീകൾ നെയിംസ്‌പേസ് (namespacing) ചെയ്യുന്നതിലൂടെയും, അമിതമായ ക്ലീനപ്പ് ഒഴിവാക്കുന്നതിലൂടെയും, മറ്റ് എൻട്രികളെ സംരക്ഷിക്കുന്ന ലളിതമായ ഒരു ടെസ്റ്റ് ചേർക്കുന്നതിലൂടെയും ഡാറ്റാ നഷ്ടം തടയാനും വ്യാപാരികളുടെ ഷോപ്പുകൾ സുസ്ഥിരമായി നിലനിർത്താനും ഡെവലപ്പർമാർക്ക് സാധിക്കും. ഇതിനായി വേണ്ട പരിശ്രമം വളരെ കുറവാണ്, എന്നാൽ ഒരു സെറ്റിംഗ് നഷ്ടപ്പെടുന്നതിലൂടെ ഉണ്ടാകുന്ന പ്രത്യാഘാതങ്ങൾ—ഉപഭോക്തൃ പരാതികൾ, സപ്പോർട്ട് ടിക്കറ്റുകൾ, സൽപ്പേടിന് സംഭവിക്കുന്ന കളങ്കം എന്നിവ—വളരെ വലുതായിരിക്കും.