Jedwali la usanidi la kimataifa la PrestaShop linafanya iwe rahisi kwa utaratibu wa kuondoa moduli (uninstall routine) kufuta mipangilio inayomilikiwa na nyongeza (extensions) zisizo na uhusiano kabisa. Wito mmoja tu wa Configuration::deleteByName('width') unaweza kufuta thamani ya upana (width) iliyorekebishwa ya duka lingine, na kumwacha mfanyabiashara akiwa amechanganyikiwa huku moduli inayohusika ikionekana haina madhara.

Kwa nini jedwali la pamoja la usanidi ni muhimu

PrestaShop huhifadhi mipangilio ya kila moduli katika jedwali moja ambalo linafungia funguo (key) na thamani (value) pekee. Jedwali hilo halina safu (column) inayorekodi ni moduli gani iliyounda mstari (row), na halilazimishi utaratibu wowote wa majina. Matokeo yake, moduli mbili zinazotumia funguo sawa—kwa mfano “width” au “API_DATE_FROM”—zitasoma na kuandika mstari uleule wa kanzidata. Andiko la mwisho ndilo linaloshinda, na ufunguaji wowote wa baadaye unaondoa mstari huo kwa pande zote mbili.

Wakati kodi ya kuondoa (uninstall) inapogeuka kuwa chombo cha kufuta data

Njia ya kawaida ya kuondoa (uninstall) inaonekana hivi:

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

Nia ni kusafisha usanidi wa moduli yenyewe, lakini kwa sababu funguo hiyo haina jina maalum (namespaced), amri hiyo huondoa mstari wowote uitwao “width”. Hakuna onyo linalorekodiwa, hakuna hitilafu (exception) inayotolewa; mstari huo unapotoweka tu. Moduli nyingine ya mfanyabiashara inapoteza mipangilio yake kimyakimya na inaweza kuanza kufanya kazi kwa njia isiyo ya kawaida.

Tatizo hili linakuwa la kuvutia hasa wakati wa kuongeza toleo (version upgrade). Msanidi programu anayehama kutoka toleo la 1.0 hadi 2.0 anaweza kuanza kuhifadhi thamani chini ya funguo yenye kiambishi awali (prefix) kama vile MY_MODULE_WIDTH. Ili "kusafisha" viingilio vya zamani visivyo na kiambishi awali, wanaongeza wito wa kufuta kwenye utaratibu wa kuondoa, wakiamini kuwa wanaondoa tu data za zamani. Kiuhalisia, wanafuta pia nyongeza nyingine yoyote iliyohifadhiwa chini ya funguo hiyo ya jumla.

Kile ambacho ukaguzi uligundua

Ukaguzi wa ghala (repositories) za moduli za umma 57 ulionyesha mfumo unaojirudia:

  • Moduli nyingi hutumia funguo za jumla kama “width”, “height”, au “API_DATE_FROM” bila kiambishi awali chochote kinachotokana na jina la moduli.
  • Njia kadhaa za kuondoa zina wito wa Configuration::deleteByName unaolenga funguo hizi za jumla.
  • Tatizo hili halijafungwa kwa msanidi programu mmoja au aina fulani ya moduli; muundo wa jedwali la pamoja unaifanya kuwa hatari ya kimfumo.

Ukaguzi haukupata kumbukumbu (logs) au ujumbe wa hitilafu ambao ungemtahadharisha mmiliki wa duka kwamba usanidi wa moduli nyingine umefutwa. Dalili pekee ni upotevu wa ghafla wa mipangilio ambao mfanyabiashara anaweza kuukusudia kuwa tatizo la cache au hitilafu (bug) katika kodi yake mwenyewe.

Taratibu salama zaidi kwa wasanidi programu wa moduli

  1. Weka jina maalum (Namespace) kwa kila funguo – ongeza jina la kiufundi la moduli kwenye kila funguo ya usanidi (mfano, my_module_width). Hii inatengeneza utambulisho wa kipekee bila kutegemea safu tofauti ya umiliki.
  2. Epuka kufuta funguo za zamani zisizo na kiambishi awali – kuacha mistari michache iliyopitwa na wakati kwenye jedwali hakugharimu karibu kitu katika hifadhi na huondoa hatari ya uharibifu wa pembeni.
  3. Thibitisha umiliki kabla ya kufuta – ikiwa kufuta ni lazima kweli, kwanza hakikisha kuwa thamani ya funguo hiyo iliwekwa na kodi yako mwenyewe (kwa mfano, hifadhi thamani ya alama ambayo moduli yako pekee ndiyo inayojua).
  4. Kagua njia za kuondoa (uninstall methods) – tafuta wito wa deleteByName kwenye kodi. Kila tukio linapaswa kuchunguzwa ili kuthibitisha kuwa funguo hiyo ina jina maalum la kipekee.
  5. Weka kumbukumbu ya utaratibu wa majina – jumuisha mwongozo mfupi kwenye README ya moduli ili wachangiaji wa baadaye waelewe umuhimu wa funguo zenye viambishi awali.

Kujaribu kwa ajili ya kufuta kwa bahati mbaya kati ya moduli

Njia ya vitendo ya kukamata hitilafu hiyo kabla haijafika kwenye duka linalofanya kazi:

  • Weka data awali (Seed) kwenye jedwali la usanidi kwa funguo inayomilikiwa na moduli tofauti (mfano, other_module_setting => test).
  • Endesha utaratibu wa kuondoa wa moduli katika mazingira yanayodhibitiwa.
  • Hakikisha (Assert) kwamba funguo hiyo iliyowekwa bado ipo baada ya uondoaji kukamilika.

Kuweka utaratibu huu wa ukaguzi kiotomatiki katika seti ya majaribio ya moduli (unit-test suite) kunahakikisha kuwa mabadiliko yoyote ya baadaye yatakayoleta wito wa deleteByName utashindwa katika jaribio, na hivyo kusababisha ukaguzi.

Vile ambavyo wamiliki wa maduka wanapaswa kuzingatia

Wamiliki wa maduka mara chache huona mistari ya ndani ya kanzidata, lakini wanaweza kutambua dalili: baada ya kuzima au kuondoa moduli, nyongeza nyingine ghafla hurudi kwenye mipangilio ya awali. Ikiwa hilo litatokea, mwombe msanidi programu athibitishe kwamba kodi ya kuondoa ya moduli inaheshimu jedwali la usanidi la kimataifa. Omba orodha ya funguo zote za usanidi ambazo moduli inazitumia; funguo yoyote isiyo na kiambishi awali cha wazi ni ishara ya hatari.

Muhtasari

Muundo wa PrestaShop unafanya jedwali la usanidi kuwa rasilimali inayoshirikiwa, na utaratibu wa kuondoa moduli usio wa uangalifu unaweza kufuta mipangilio ya moduli nyingine bila kuacha alama. Kwa kutumia namespacing kwa funguo, kuepuka usafishaji mkali, na kuongeza jaribio rahisi linalolinda rekodi za nje, watengenezaji wanaweza kuzuia upotevu wa data usioonekana na kuweka maduka ya wafanyabiashara katika hali thabiti. Jitihada zinazohitajika ni kidogo, lakini gharama ya kupoteza mpangilio—malalamiko ya wateja, tiketi za msaada, na kuharibika kwa sifa—inaweza kuwa kubwa zaidi.