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');
}
ਇਰਾਦਾ ਮੋਡਿਊਲ ਦੀ ਆਪਣੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਹੈ, ਪਰ ਕਿਉਂਕਿ 'ਕੀ' (key) ਨੂੰ ਨੇਮਸਪੇਸ (namespaced) ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਹ ਸਟੇਟਮੈਂਟ “width” ਨਾਮ ਦੀ ਕੋਈ ਵੀ ਰੋਅ ਨੂੰ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਕੋਈ ਚੇਤਾਵਨੀ (warning) ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ, ਕੋਈ ਐਕਸੈਪਸ਼ਨ (exception) ਨਹੀਂ ਆਉਂਦੀ; ਰੋਅ ਬਸ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਵਪਾਰੀ ਦਾ ਦੂਜਾ ਮੋਡਿਊਲ ਚੁੱਪਚਾਪ ਆਪਣੀ ਸੈਟਿੰਗ ਗੁਆ ਲੈਂਦਾ ਹੈ ਅਤੇ ਅਜੀਬ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਸਮੱਸਿਆ ਵਰਜ਼ਨ ਅੱਪਗ੍ਰੇਡ (version upgrade) ਦੌਰਾਨ ਖਾਸ ਤੌਰ 'ਤੇ ਉਭਰਦੀ ਹੈ। ਇੱਕ ਡਿਵੈਲਪਰ ਜੋ ਵਰਜ਼ਨ 1.0 ਤੋਂ 2.0 'ਤੇ ਜਾ ਰਿਹਾ ਹੈ, ਉਹ MY_MODULE_WIDTH ਵਰਗੀ ਪ੍ਰੀਫਿਕਸਡ (prefixed) ਕੀ ਦੇ ਅਧੀਨ ਵੈਲਯੂਜ਼ ਸੇਵ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਪੁਰਾਣੀਆਂ, ਬਿਨਾਂ ਪ੍ਰੀਫਿਕਸ ਵਾਲੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ "ਸਾਫ਼" ਕਰਨ ਲਈ, ਉਹ ਅਨਇੰਸਟਾਲ ਰੁਟੀਨ ਵਿੱਚ ਇੱਕ ਡਿਲੀਟ ਕਾਲ ਜੋੜ ਦਿੰਦੇ ਹਨ, ਇਹ ਮੰਨ ਕੇ ਕਿ ਉਹ ਸਿਰਫ਼ ਪੁਰਾਣਾ ਡੇਟਾ ਹਟਾ ਰਹੇ ਹਨ। ਅਸਲ ਵਿੱਚ, ਉਹ ਉਹ ਸਭ ਕੁਝ ਵੀ ਡਿਲੀਟ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਜੋ ਹੋਰ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨੇ ਉਸੇ ਜੈਨਰਿਕ ਕੀ ਦੇ ਅਧੀਨ ਸਟੋਰ ਕੀਤਾ ਹੋਇਆ ਹੈ।
ਆਡਿਟ ਵਿੱਚ ਕੀ ਸਾਹਮਣੇ ਆਇਆ
57 ਪਬਲਿਕ ਮੋਡਿਊਲ ਰਿਪੋਜ਼ਟਰੀਆਂ (repositories) ਦੇ ਆਡਿਟ ਨੇ ਇੱਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲਾ ਪੈਟਰਨ ਸਾਹਮਣੇ ਲਿਆਂਦਾ:
- ਕਈ ਮੋਡਿਊਲ ਮੋਡਿਊਲ ਦੇ ਨਾਮ ਤੋਂ ਪ੍ਰਾਪਤ ਕਿਸੇ ਵੀ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਬਿਨਾਂ “width”, “height”, ਜਾਂ “API_DATE_FROM” ਵਰਗੀਆਂ ਜੈਨਰਿਕ ਕੀਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
- ਕਈ ਅਨਇੰਸਟਾਲ ਮੈਥਡ ਵਿੱਚ
Configuration::deleteByNameਕਾਲ ਸ਼ਾਮਲ ਹਨ ਜੋ ਇਹਨਾਂ ਜੈਨਰਿਕ ਕੀਜ਼ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ। - ਇਹ ਸਮੱਸਿਆ ਕਿਸੇ ਇੱਕ ਡਿਵੈਲਪਰ ਜਾਂ ਕਿਸੇ ਖਾਸ ਕਿਸਮ ਦੇ ਮੋਡਿਊਲ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੈ; ਸਾਂਝੀ ਟੇਬਲ ਡਿਜ਼ਾਈਨ ਇਸਨੂੰ ਇੱਕ ਸਿਸਟਮਿਕ ਜੋਖਮ (systemic risk) ਬਣਾਉਂਦੀ ਹੈ।
ਆਡਿਟ ਵਿੱਚ ਕੋਈ ਅਜਿਹੇ ਲੌਗਸ (logs) ਜਾਂ ਐਰਰ ਮੈਸੇਜ ਨਹੀਂ ਮਿਲੇ ਜੋ ਦੁਕਾਨ ਦੇ ਮਾਲਕ ਨੂੰ ਇਹ ਸੂਚਿਤ ਕਰਨ ਕਿ ਕਿਸੇ ਹੋਰ ਮੋਡਿਊਲ ਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹਟਾ ਦਿੱਤੀ ਗਈ ਹੈ। ਇਕਲੌਤਾ ਲੱਛਣ ਸੈਟਿੰਗਾਂ ਦਾ ਅਚਾਨਕ ਗੁਆਚ ਜਾਣਾ ਹੈ, ਜਿਸਦਾ ਕਾਰਨ ਵਪਾਰੀ ਕੈਸ਼ (cache) ਦੀ ਸਮੱਸਿਆ ਜਾਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਬੱਗ (bug) ਮੰਨ ਸਕਦਾ ਹੈ।
ਮੋਡਿਊਲ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਅਭਿਆਸ
- ਹਰ ਕੀ (key) ਨੂੰ ਨੇਮਸਪੇਸ ਕਰੋ – ਹਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕੀ ਦੇ ਅੱਗੇ ਮੋਡਿਊਲ ਦਾ ਤਕਨੀਕੀ ਨਾਮ ਲਗਾਓ (ਜਿਵੇਂ ਕਿ
my_module_width)। ਇਹ ਇੱਕ ਵੱਖਰੇ ਮਾਲਕੀ ਕਾਲਮ 'ਤੇ ਨਿਰਭਰ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਵਿਲੱਖਣ ਪਛਾਣਕ (unique identifier) ਬਣਾਉਂਦਾ ਹੈ। - ਪੁਰਾਣੀਆਂ, ਬਿਨਾਂ ਪ੍ਰੀਫਿਕਸ ਵਾਲੀਆਂ ਕੀਜ਼ ਨੂੰ ਡਿਲੀਟ ਕਰਨ ਤੋਂ ਬਚੋ – ਟੇਬਲ ਵਿੱਚ ਕੁਝ ਪੁਰਾਣੀਆਂ ਰੋਅਜ਼ ਨੂੰ ਰਹਿਣ ਦੇਣ ਨਾਲ ਸਟੋਰੇਜ ਵਿੱਚ ਲਗਭਗ ਕੁਝ ਵੀ ਖਰਚ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਜੋਖਮ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ
ਮੁੱਖ ਨੁਕਤੇ
PrestaShop ਦਾ ਡਿਜ਼ਾਈਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਟੇਬਲ ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਸਰੋਤ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਲਾਪਰਵਾਹੀ ਭਰਪੂਰ ਅਨਇੰਸਟਾਲ ਪ੍ਰਕਿਰਿਆ ਦੂਜੇ ਮੋਡਿਊਲ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਨਿਸ਼ਾਨ ਦੇ ਮਿਟਾ ਸਕਦੀ ਹੈ। ਕੀਜ਼ (keys) ਨੂੰ ਨੇਮਸਪੇਸਿੰਗ (namespacing) ਕਰਕੇ, ਹਮਲਾਵਰ ਕਲੀਨਅੱਪ ਤੋਂ ਬਚ ਕੇ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਜੋ ਬਾਹਰੀ ਐਂਟਰੀਆਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਜੋੜ ਕੇ, ਡਿਵੈਲਪਰ ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੇ ਡੇਟਾ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ ਅਤੇ ਵਪਾਰੀਆਂ ਦੀਆਂ ਦੁਕਾਨਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਲੋੜੀਂਦੀ ਕੋਸ਼ਿਸ਼ ਬਹੁਤ ਘੱਟ ਹੈ, ਪਰ ਇੱਕ ਗੁੰਮ ਹੋਈ ਸੈਟਿੰਗ ਦੀ ਕੀਮਤ—ਗਾਹਕਾਂ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ, ਸਪੋਰਟ ਟਿਕਟਾਂ, ਅਤੇ ਖ਼ਰਾਬ ਹੋਈ ਸਾਖ—ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ।