PrestaShopનું ગ્લોબલ કોન્ફિગરેશન ટેબલ મોડ્યુલના અનઇન્સ્ટોલ રૂટિન માટે સંપૂર્ણપણે અસંબંધિત એક્સ્ટેન્શનના સેટિંગ્સ ભૂંસી નાખવાનું સરળ બનાવે છે. Configuration::deleteByName('width') નો એક સિંગલ કોલ અન્ય શોપના કસ્ટમ વિડ્થ (width) વેલ્યુને ભૂંસી શકે છે, જેનાથી વેપારી મૂંઝવણમાં મુકાઈ જાય છે અને દોષિત મોડ્યુલ દેખીતી રીતે નિર્દોષ લાગે છે.
શા માટે શેર કરેલું કોન્ફિગરેશન ટેબલ મહત્વનું છે
PrestaShop દરેક મોડ્યુલના સેટિંગ્સ એક જ ટેબલમાં સ્ટોર કરે છે જેમાં ફક્ત એક 'key' અને 'value' હોય છે. આ ટેબલમાં એવો કોઈ કોલમ નથી જે રેકોર્ડ કરે કે કયા મોડ્યુલે રો (row) બનાવી છે, અને તે કોઈપણ નેમિંગ કન્વેન્શન (naming convention) લાગુ કરતું નથી. પરિણામે, જો બે મોડ્યુલ ભૂલથી સમાન કી (key) નો ઉપયોગ કરે—ધારો કે “width” અથવા “API_DATE_FROM”—તો તેઓ એક જ ડેટાબેઝ રો વાંચશે અને લખશે. છેલ્લે જે લખવામાં આવે તે જ માન્ય રહેશે, અને પછીથી કરવામાં આવેલ કોઈપણ ડિલીટ બંને પક્ષો માટે તે રો ને દૂર કરી દેશે.
જ્યારે અનઇન્સ્ટોલ કોડ ડેટા-વાઇપિંગ ટૂલમાં ફેરવાઈ જાય
એક સામાન્ય અનઇન્સ્ટોલ મેથડ આ મુજબ દેખાય છે:
public function uninstall()
{
return Configuration::deleteByName('width');
}
હેતુ મોડ્યુલના પોતાના કોન્ફિગરેશનને સાફ કરવાનો છે, પરંતુ કી (key) ને નેમસ્પેસ (namespaced) કરવામાં ન હોવાને કારણે, આ સ્ટેટમેન્ટ “width” નામની કોઈપણ રો ને દૂર કરે છે. કોઈ ચેતવણી લોગ થતી નથી, કોઈ એક્સેપ્શન (exception) આવતું નથી; તે રો ફક્ત ગાયબ થઈ જાય છે. વેપારીનું બીજું મોડ્યુલ શાંતિથી તેનું સેટિંગ ગુમાવે છે અને વિચિત્ર રીતે વર્તવાનું શરૂ કરી શકે છે.
વર્ઝન અપગ્રેડ દરમિયાન આ સમસ્યા ખાસ કરીને જોખમી બની જાય છે. જે ડેવલપર વર્ઝન 1.0 થી 2.0 પર જાય છે તે MY_MODULE_WIDTH જેવી પ્રીફિક્સ કરેલી કી હેઠળ વેલ્યુ સેવ કરવાનું શરૂ કરી શકે છે. જૂની, અન-પ્રીફિક્સ કરેલી એન્ટ્રીઓને "સાફ" કરવા માટે, તેઓ અનઇન્સ્ટોલ રૂટિનમાં ડિલીટ કોલ ઉમેરે છે, એવું માનીને કે તેઓ ફક્ત જૂનો (legacy) ડેટા જ દૂર કરી રહ્યા છે. વાસ્તવમાં, તેઓ તે જ જનરિક કી હેઠળ સ્ટોર કરેલી અન્ય એક્સ્ટેન્શનની વિગતો પણ ડિલીટ કરી રહ્યા હોય છે.
ઓડિટમાં શું બહાર આવ્યું
57 પબ્લિક મોડ્યુલ રિપોઝીટરીના ઓડિટમાં એક વારંવાર બનતો પેટર્ન જોવા મળ્યો:
- ઘણા મોડ્યુલ્સ મોડ્યુલના નામ પરથી મેળવેલા કોઈપણ પ્રીફિક્સ વગર “width”, “height”, અથવા “API_DATE_FROM” જેવી જનરિક કીનો ઉપયોગ કરે છે.
- કેટલાક અનઇન્સ્ટોલ મેથડ્સમાં
Configuration::deleteByNameકોલ્સ હોય છે જે આ જનરિક કીને ટાર્ગેટ કરે છે. - આ સમસ્યા માત્ર કોઈ એક ડેવલપર અથવા ચોક્કસ પ્રકારના મોડ્યુલ પૂરતી મર્યાદિત નથી; શેર કરેલ ટેબલ ડિઝાઇન તેને સિસ્ટમિક જોખમ બનાવે છે.
ઓડિટમાં એવા કોઈ લોગ્સ અથવા એરર મેસેજ મળ્યા નથી જે શોપ ઓનરને ચેતવણી આપે કે અન્ય મોડ્યુલનું કોન્ફિગરેશન દૂર કરવામાં આવ્યું છે. એકમાત્ર લક્ષણ સેટિંગ્સનું અચાનક ગુમ થવું છે, જેને વેપારી કેશ (cache) સમસ્યા અથવા તેમના પોતાના કોડમાં બગ (bug) હોવાનું માની શકે છે.
મોડ્યુલ ડેવલપર્સ માટે સુરક્ષિત પદ્ધતિઓ
- દરેક કીને નેમસ્પેસ કરો – દરેક કોન્ફિગરેશન કીની આગળ મોડ્યુલનું ટેકનિકલ નામ ઉમેરો (દા.ત.,
my_module_width). આ અલગ ઓનરશિપ કોલમ પર આધાર રાખ્યા વિના એક યુનિક આઈડેન્ટિફાયર બનાવે છે. - જૂની, અન-પ્રીફિક્સ કરેલી કી ડિલીટ કરવાનું ટાળો – ટેબલમાં થોડી જૂની (obsolete) રો રાખવાથી સ્ટોરેજમાં લગભગ કંઈ જ ખર્ચ થતો નથી અને આડઅસરનું જોખમ પણ દૂર થાય છે.
- ડિલીટ કરતા પહેલા ઓનરશિપ તપાસો – જો ડિલીટ કરવું ખરેખર જરૂરી હોય, તો પહેલા તપાસો કે કીની વેલ્યુ તમારા પોતાના કોડ દ્વારા સેટ કરવામાં આવી હતી કે નહીં (દાખલા તરીકે, એક માર્કર વેલ્યુ સ્ટોર કરો જે ફક્ત તમારું મોડ્યુલ જ જાણે છે).
- અનઇન્સ્ટોલ મેથડ્સનું ઓડિટ કરો – કોડબેઝમાં
deleteByNameકોલ્સ શોધો. દરેક કિસ્સાની તપાસ થવી જોઈએ જેથી ખાતરી કરી શકાય કે કી યુનિકલી નેમસ્પેસ કરેલી છે. - નેમિંગ કન્વેન્શનનું ડોક્યુમેન્ટેશન કરો – મોડ્યુલના README માં ટૂંકી માર્ગદર્શિકા સામેલ કરો જેથી ભવિષ્યના કન્ટ્રીબ્યુટર્સ પ્રીફિક્સ કરેલી કીનું મહત્વ સમજી શકે.
અકસ્માતવશ ક્રોસ-મોડ્યુલ ડિલીશન માટે ટેસ્ટિંગ
લાઇવ શોપ સુધી ભૂલ પહોંચે તે પહેલા તેને પકડવાનો વ્યવહારુ રસ્તો:
- કોન્ફિગરેશન ટેબલમાં અન્ય મોડ્યુલની કી સાથે ડેટા ઉમેરો (દા.ત.,
other_module_setting=>test). - કંટ્રોલ્ડ એન્વાયરમેન્ટમાં મોડ્યુલનું અનઇન્સ્ટોલ રૂટિન ચલાવો.
- અનઇન્સ્ટોલ પૂર્ણ થયા પછી પણ સીડ કરેલી કી અસ્તિત્વમાં છે તેની ખાતરી કરો.
મોડ્યુલના યુનિટ-ટેસ્ટ સ્યુટમાં આ ચેકને ઓટોમેટ કરવાથી એ સુનિશ્ચિત થાય છે કે ભવિષ્યમાં કોઈપણ ફેરફાર જે ભૂલથી deleteByName કોલ લાવે છે તે ટેસ્ટમાં નિષ્ફળ જશે, જેનાથી રિવ્યુ કરવાની જરૂરિયાત ઊભી થશે.
શોપ ઓનર્સએ શું ધ્યાન રાખવું જોઈએ
સ્ટોર ઓનર્સ ભાગ્યે જ આંતરિક ડેટાબેઝ રો જુએ છે, પરંતુ તેઓ લક્ષણો ઓળખી શકે છે: કોઈ મોડ્યુલને ડિસેબલ અથવા અનઇન્સ્ટોલ કર્યા પછી, અન્ય એક્સ્ટેન્શન અચાનક ડિફોલ્ટ સેટિંગ્સ પર પાછું જતું રહે છે. જો આવું થાય, તો ડેવલપરને મોડ્યુલના અનઇન્સ્ટોલ કોડ દ્વારા ગ્લોબલ કોન્ફિગરેશન ટેબલનું પાલન થાય છે કે નહીં તે તપાસવા માટે કહો. મોડ્યુલ જે તમામ કોન્ફિગરેશન કીનો ઉપયોગ કરે છે તેની યાદી માંગો; સ્પષ્ટ પ્રીફિક્સ વગરની કોઈપણ કી એ જોખમની નિશાની (red flag) છે.
મુખ્ય તારણ
PrestaShop ની ડિઝાઇન કોન્ફિગરેશન ટેબલને એક સહિયારું સંસાધન બનાવે છે, અને જો અનઇન્સ્ટોલ રૂટિન બેદરકાર હોય, તો તે અન્ય મોડ્યુલના સેટિંગ્સને કોઈપણ નિશાન વગર ભૂંસી શકે છે. કીઝ (keys) ને નેમસ્પેસિંગ દ્વારા અલગ કરીને, આક્રમક ક્લીનઅપ ટાળીને અને અન્ય એન્ટ્રીઓને સુરક્ષિત કરે તેવો એક સરળ ટેસ્ટ ઉમેરીને, ડેવલપર્સ ડેટાનું છૂપી રીતે થતું નુકસાન અટકાવી શકે છે અને વેપારીઓની દુકાનોને સ્થિર રાખી શકે છે. આ માટે જરૂરી પ્રયત્નો ન્યૂનતમ છે, પરંતુ ખોવાયેલ સેટિંગની કિંમત—ગ્રાહકોની ફરિયાદો, સપોર્ટ ટિકિટો અને ક્ષતિગ્રસ્ત પ્રતિષ્ઠા—ખૂબ જ વધારે હોઈ શકે છે.