PrestaShop کا گلوبل کنفیگریشن ٹیبل کسی ماڈیول کے ان انسٹال روٹین (uninstall routine) کے لیے ان سیٹنگز کو مٹانا آسان بنا دیتا ہے جو مکمل طور پر غیر متعلقہ ایکسٹینشنز سے تعلق رکھتی ہیں۔ Configuration::deleteByName('width') کا ایک واحد کال کسی دوسری شاپ کی کسٹم 'width' ویلیو کو ختم کر سکتی ہے، جس سے تاجر الجھن کا شکار ہو جاتا ہے اور متعلقہ ماڈیول بظاہر بے ضرر نظر آتا ہے۔

شیئرڈ کنفیگریشن ٹیبل کیوں اہم ہے

PrestaShop ہر ماڈیول کی سیٹنگز کو ایک ہی ٹیبل میں محفوظ کرتا ہے جس میں صرف ایک 'key' اور ایک 'value' ہوتی ہے۔ اس ٹیبل میں کوئی ایسا کالم نہیں ہے جو یہ ریکارڈ کرے کہ کون سا ماڈیول ایک مخصوص رو (row) بنا رہا ہے، اور نہ ہی یہ کسی نام رکھنے کے اصول (naming convention) پر عمل درآمد کرتا ہے۔ نتیجے کے طور پر، اگر دو ماڈیولز اتفاقاً ایک ہی 'key' استعمال کریں—مثلاً "width" یا "API_DATE_FROM"—تو وہ ایک ہی ڈیٹا بیس رو کو پڑھیں گے اور اس میں لکھیں گے۔ آخری بار جو ڈیٹا لکھا جائے گا وہی برقرار رہے گا، اور بعد میں ہونے والا کوئی بھی ڈیلیٹ (delete) دونوں فریقین کے لیے اس رو کو ختم کر دے گا۔

جب ان انسٹال کوڈ ڈیٹا مٹانے والے ٹول میں بدل جائے

ایک عام ان انسٹال میتھڈ (uninstall method) کچھ اس طرح نظر آتا ہے:

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

مقصد ماڈیول کی اپنی کنفیگریشن کو صاف کرنا ہوتا ہے، لیکن چونکہ 'key' نیم اسپیسڈ (namespaced) نہیں ہوتی، اس لیے یہ سٹیٹمنٹ "width" نامی کسی بھی رو کو ختم کر دیتی ہے۔ کوئی وارننگ لاگ نہیں ہوتی، کوئی ایکسیپشن (exception) نہیں آتی؛ وہ رو بس غائب ہو جاتی ہے۔ تاجر کا دوسرا ماڈیول خاموشی سے اپنی سیٹنگ کھو دیتا ہے اور شاید عجیب و غریب طریقے سے کام کرنا شروع کر دے۔

یہ مسئلہ ورژن اپ گریڈ کے دوران خاص طور پر سنگین ہو جاتا ہے۔ ایک ڈویلپر جو ورژن 1.0 سے 2.0 پر منتقل ہو رہا ہو، وہ شاید MY_MODULE_WIDTH جیسی پری فکسڈ (prefixed) کی (key) کے تحت ویلیوز محفوظ کرنا شروع کر دے۔ پرانی، بغیر پری فکس والی انٹریز کو "صاف" کرنے کے لیے، وہ ان انسٹال روٹین میں ایک ڈیلیٹ کال شامل کر دیتے ہیں، یہ سمجھتے ہوئے کہ وہ صرف پرانا ڈیٹا (legacy data) ہٹا رہے ہیں۔ حقیقت میں، وہ ان تمام دیگر ایکسٹینشنز کا ڈیٹا بھی ڈیلیٹ کر رہے ہوتے ہیں جنہوں نے اسی عام (generic) کی (key) کے تحت ڈیٹا محفوظ کیا ہوتا ہے۔

آڈٹ سے کیا انکشاف ہوا

57 عوامی ماڈیول ریپوزٹریز (repositories) کے آڈٹ سے ایک بار بار دہرایا جانے والا پیٹرن سامنے آیا:

  • بہت سے ماڈیولز ماڈیول کے نام سے اخذ کردہ کسی بھی پری فکس کے بغیر "width"، "height"، یا "API_DATE_FROM" جیسی عام کیز (keys) استعمال کرتے ہیں۔
  • کئی ان انسٹال میتھڈز میں Configuration::deleteByName کی ایسی کالز شامل ہیں جو ان عام کیز کو نشانہ بناتی ہیں۔
  • یہ مسئلہ کسی ایک ڈویلپر یا کسی خاص قسم کے ماڈیول تک محدود نہیں ہے؛ شیئرڈ ٹیبل کا ڈیزائن اسے ایک نظامی خطرہ (systemic risk) بنا دیتا ہے۔

آڈٹ میں کوئی ایسا لاگ یا ایرر میسج نہیں ملا جو دکان کے مالک کو خبردار کر سکے کہ کسی دوسرے ماڈیول کی کنفیگریشن ہٹا دی گئی ہے۔ اس کی واحد علامت سیٹنگز کا اچانک ختم ہو جانا ہے، جسے تاجر کیش (cache) کے مسئلے یا اپنے کوڈ میں کسی بگ (bug) کا نتیجہ سمجھ سکتا ہے۔

ماڈیول ڈویلپرز کے لیے محفوظ طریقے

  1. ہر کی (key) کو نیم اسپیس (Namespace) کریں – ہر کنفیگریشن کی کے شروع میں ماڈیول کا تکنیکی نام شامل کریں (مثلاً my_module_width)۔ اس سے علیحدہ ملکیت والے کالم پر انحصار کیے بغیر ایک منفرد شناختی نمبر (unique identifier) بن جاتا ہے۔
  2. پرانی، بغیر پری فکس والی کیز کو ڈیلیٹ کرنے سے گریز کریں – ٹیبل میں چند پرانی (obsolete) روز کو رہنے دینے سے اسٹوریج پر تقریباً کوئی بوجھ نہیں پڑتا اور یہ غیر ضروری نقصان کے خطرے کو ختم کر دیتا ہے۔
  3. ڈیلیٹ کرنے سے پہلے ملکیت کی تصدیق کریں – اگر ڈیلیٹ کرنا واقعی ضروری ہو، تو پہلے یہ چیک کریں کہ کی (key) کی ویلیو آپ کے اپنے کوڈ کے ذریعے سیٹ کی گئی تھی (مثلاً ایک ایسا مارکر ویلیو محفوظ کریں جسے صرف آپ کا ماڈیول جانتا ہو)۔
  4. ان انسٹال میتھڈز کا آڈٹ کریں – کوڈ بیس میں deleteByName کی کالز تلاش کریں۔ ہر واقعے کا جائزہ لیا جانا چاہیے تاکہ اس بات کی تصدیق ہو سکے کہ کی (key) کو منفرد طور پر نیم اسپیس کیا گیا ہے۔
  5. نام رکھنے کے اصول (naming convention) کو دستاویز کریں – ماڈیول کی README فائل میں ایک مختصر گائیڈ لائن شامل کریں تاکہ مستقبل کے معاونین (contributors) پری فکسڈ کیز کی اہمیت کو سمجھ سکیں۔

حادثاتی طور پر کراس ماڈیول ڈیلیشنز کی جانچ پڑتال

لائیو شاپ تک پہنچنے سے پہلے اس بگ کو پکڑنے کا ایک عملی طریقہ:

  • کنفیگریشن ٹیبل میں ڈیٹا ڈالیں (Seed) ایک ایسی کی (key) کے ساتھ جو کسی دوسرے ماڈیول سے تعلق رکھتی ہو (مثلاً other_module_setting => test)۔
  • ایک کنٹرول شدہ ماحول میں ماڈیول کے ان انسٹال روٹین کو چلائیں۔
  • اس بات کی تصدیق (Assert) کریں کہ ان انسٹال مکمل ہونے کے بعد بھی وہ کی (key) موجود ہے۔

ماڈیول کے یونٹ ٹیسٹ سویٹ (unit-test suite) میں اس چیک کو خودکار (automate) بنانے سے یہ یقینی بنتا ہے کہ مستقبل میں کوئی بھی تبدیلی جو غلطی سے deleteByName کی کال متعارف کرواتی ہے، وہ ٹیسٹ میں ناکام ہو جائے گی، جس سے اس کا جائزہ لینے کی ضرورت پڑ جائے گی۔

دکان کے مالکان کو کن چیزوں پر نظر رکھنی چاہیے

دکان کے مالکان شاذ و نادر ہی ڈیٹا بیس کی اندرونی روز (rows) دیکھتے ہیں، لیکن وہ علامت کو پہچان سکتے ہیں: کسی ماڈیول کو ڈس ایبل یا ان انسٹال کرنے کے بعد، اگر کوئی دوسری ایکسٹینشن اچانک ڈیفالٹ سیٹنگز پر واپس آ جائے، تو یہ ایک علامت ہے۔ اگر ایسا ہو، تو ڈویلپر سے کہیں کہ وہ تصدیق کرے کہ ماڈیول کا ان انسٹال کوڈ گلوبل کنفیگریشن ٹیبل کا احترام کرتا ہے۔ ماڈیول کے استعمال کردہ تمام کنفیگریشن کیز (keys) کی فہرست طلب کریں؛ بغیر کسی واضح پری فکس کے کوئی بھی کی (key) ایک خطرے کی گھنٹی (red flag) ہے۔

خلاصہ

PrestaShop کا ڈیزائن کنفیگریشن ٹیبل کو ایک مشترکہ وسیلہ بنا دیتا ہے، اور ان انسٹال کا ایک غیر ذمہ دارانہ طریقہ کار دوسرے ماڈیول کی سیٹنگز کو بغیر کسی نشان کے مٹا سکتا ہے۔ کیز (keys) کو نیم اسپیسنگ (namespacing) کے ذریعے الگ کر کے، جارحانہ صفائی سے گریز کر کے، اور ایک سادہ ٹیسٹ شامل کر کے جو بیرونی اندراجات کی حفاظت کرے، ڈویلپرز خاموش ڈیٹا کے نقصان کو روک سکتے ہیں اور تاجروں کے اسٹورز کو مستحکم رکھ سکتے ہیں۔ اس کے لیے درکار کوشش بہت کم ہے، لیکن ایک سیٹنگ کے ضائع ہونے کی قیمت—صارفین کی شکایات، سپورٹ ٹکٹس، اور ساکھ کو پہنچنے والا نقصان—بہت زیادہ ہو سکتی ہے۔