Optistream نے اپنے ایک ہزار عوامی صفحات (public pages) کے لیے SEO کو متاثر کیے بغیر بارہ کسٹم WordPress پلگ انز کو ایک ہی کوڈ بیس (codebase) میں ضم کر دیا۔

اس انضمام (merge) کی اہمیت کیوں تھی

ایک عام WordPress سائٹ پر چند پلگ انز ہوتے ہیں؛ لیکن ایک بڑی سائٹ تاروں سے بھرے ورکشاپ کی طرح نظر آتی ہے، جہاں ہر تار سے آواز تو آ رہی ہوتی ہے لیکن کسی کو الگ کرنا آسان نہیں ہوتا۔ Optistream کی سائٹ پر بارہ مخصوص (bespoke) پلگ انز چل رہے تھے جو اسٹریمر پروفائلز، esports ٹیموں اور گیم ڈیٹا کو سنبھالتے تھے۔ ان پلگ انز نے ایک ہزار انڈیکس ہونے والے صفحات (indexable pages) تیار کیے تھے۔ ان URLs کو برقرار رکھنا ناگزیر تھا—کسی بھی قسم کی تبدیلی مائیگریشن کو ناکام بنا سکتی تھی۔

پرانا سیٹ اپ کیسا تھا

بارہ پلگ انز میں سے ہر ایک اپنے الگ فولڈر میں موجود تھا، اپنا کسٹم پوسٹ ٹائپ (custom post type) رجسٹر کرتا تھا، اور مختلف مقامات پر WordPress کے ساتھ منسلک (hook) ہوتا تھا۔ مسائل بڑھتے گئے:

  • Hooks اور assets بکھرے ہوئے تھے، جس کی وجہ سے یہ اندازہ لگانا مشکل تھا کہ کون سا کوڈ کب چلے گا۔
  • Routing logic بہت سی الگ الگ فائلوں میں موجود تھی، اس لیے ایک ہی URL کئی پلگ انز سے متاثر ہو سکتا تھا۔
  • CSS فائلیں غیر متوقع ترتیب میں لوڈ ہوتی تھیں، جس سے اسٹائلز میں ٹکراؤ (clashes) پیدا ہوتا تھا۔
  • ڈیبگنگ (Debugging) کے لیے بارہ مختلف ڈائریکٹریز کھولنا پڑتی تھیں، جو کسی بھی ڈویلپر کے لیے وقت کا ضیاع تھا۔

مقصد فائلوں کی تعداد کم کرنا نہیں تھا؛ بلکہ پورے سسٹم کو ایک واحد لائف سائیکل (lifecycle) اور ڈیپینڈنسیز (dependencies) کو مینیج کرنے کے لیے ایک ہی جگہ فراہم کرنا تھا۔

مائیگریشن کی منصوبہ بندی کیسے کی گئی

ٹیم نے عوامی انٹرفیس—URLs، ٹیمپلیٹس اور میٹا ڈیٹا—کو ایک ایسے معاہدے (contract) کے طور پر لیا جسے توڑا نہیں جا سکتا تھا۔ فرنٹ اینڈ پر ہونے والی کوئی بھی تبدیلی ناکامی تصور کی جاتی۔ اسی اصول کو ذہن میں رکھتے ہوئے انہوں نے ہر مرحلے کے بعد عمل کرنے کے لیے ایک چیک لسٹ تیار کی۔

1. عوامی معاہدوں (public contracts) کی فہرست بنائیں

ہر URL پاتھ کو اس کے پوسٹ ٹائپ، ری رائٹ سلگ (rewrite slug)، ٹیمپلیٹ فائل اور ان میٹا کیز (meta keys) کے ساتھ لکھا گیا۔ یہ اسپریڈ شیٹ ایک قواعد نامہ بن گئی: اگر کوئی ماڈیول منتقل ہونے کے بعد URL تبدیل ہوتا، تو مائیگریشن کو واپس (roll back) کر لیا جاتا۔

2. ایک سادہ لوڈر (loader) بنائیں

ایک چھوٹی سی بوٹ اسٹریپ (bootstrap) فائل بنائی گئی۔ اب ہر سابقہ پلگ ان ایک قابلِ پیش گوئی فنکشن کے نام کے ذریعے ایک واحد "کنٹینٹ ڈومین" (content domain) رجسٹر کرتا ہے۔ لوڈر کوئی پیچیدہ کام نہیں کرتا—صرف اتنا کہ ضرورت پڑنے پر صحیح ماڈیول کو WordPress میں لا سکے۔ سادگی ناکامیوں کو واضح کر دیتی ہے۔

3. ڈیٹا کا تحفظ کریں

میٹا کیز (meta keys) کا نام بدلنے سے کوڈ کی تبدیلی ایک ڈیٹا مائیگریشن میں بدل جاتی، جس سے غیر ضروری خطرہ بڑھ جاتا۔ پرانی کیز کو برقرار رکھا گیا؛ نئی ہیلپر فنکشنز انہیں لپیٹ (wrap) لیتی ہیں، جس سے ڈیٹا بیس اسکیما (database schema) مستحکم رہتا ہے۔

4. CSS کی ملکیت کا مسئلہ حل کریں

اسٹائلنگ کے تنازعات کو تین اقدامات سے حل کیا گیا:

  • ماڈیول CSS فائلیں زیادہ ترجیح (high priority) کے ساتھ ان کیو (enqueue) کی جاتی ہیں تاکہ وہ آخر میں لوڈ ہوں۔
  • تمام سلیکٹرز کو ہر ماڈیول کے لیے ایک منفرد ریپر کلاس (wrapper class) تک محدود (scope) کر دیا گیا ہے۔
  • اسٹائل شیٹ تبدیل ہونے کی صورت میں براؤزر کیش (cache) کو ختم کرنے کے لیے ان کیو کرتے وقت filemtime() کا استعمال کیا جاتا ہے۔

5. ایک محفوظ لوپ (loop) کا استعمال کریں

مائیگریشن ایک وقت میں ایک ماڈیول کے حساب سے آگے بڑھی۔ ایک ماڈیول منتقل کرنے کے بعد، ٹیم نے اگلے ماڈیول کو چھونے سے پہلے پوسٹ ٹائپ رجسٹریشن، روٹنگ اور موبائل لے آؤٹ کی تصدیق کی۔ اصل پلگ انز انسٹال ہی رہے لیکن غیر فعال (inactive) رہے، تاکہ فوری طور پر واپس (rollback) جانے کا راستہ موجود رہے۔

پروڈکشن چیک لسٹ

ہر ماڈیول کی تبدیلی کے بعد ٹیم نے تصدیق کی:

  • ہر کنٹینٹ ٹائپ URL 200 HTTP اسٹیٹس واپس کرتا ہے۔
  • کینونیکل (canonical) URL ہیڈر اصل URL سے مطابقت رکھتا ہے۔
  • پیج ٹائٹلز اور میٹا ڈسکرپشنز تبدیل نہیں ہوئے۔
  • تمام تصاویر بغیر کسی ٹوٹے ہوئے لنک (broken links) کے لوڈ ہوتی ہیں۔
  • موبائل اسکرینوں پر کوئی ہوریزونٹل اوور فلو (horizontal overflow) نظر نہیں آتا۔
  • براؤزر کنسول میں زیرو JavaScript یا CSS ایررز نظر آتے ہیں۔

جب چیک لسٹ مکمل طور پر کلیئر ہو گئی، تب ہی ٹیم نے پرانے پلگ ان کو مستقل طور پر غیر فعال کیا۔

نیا پلگ ان کیا فراہم کرتا ہے

نتیجے کے طور پر بننے والا واحد پلگ ان کوڈ بیس کو چھوٹا نہیں کرتا؛ بلکہ یہ صرف حدود کو واضح کرتا ہے۔ اب تمام بارہ فنکشنل ایریاز ایک ہی لائف سائیکل، ہکس (hooks) کا ایک سیٹ اور ڈیپینڈنسیز کو مینیج کرنے کے لیے ایک ہی جگہ استعمال کرتے ہیں۔ نئے پلگ ان نے سسٹم کو چھوٹا نہیں کیا، بلکہ اس کی حدود کو واضح کر دیا۔ یہ پلگ انز کی تعداد کم کرنے سے زیادہ مفید ثابت ہوا۔

خطرات اور جوابی دلائل

Optistream کا کیس ظاہر کرتا ہے کہ ایک نظم و ضبط کے حامل 'کنٹریکٹ فرسٹ' (contract-first) طریقہ کار اور مرحلہ وار رول آؤٹ (rollout) خطرات کو قابو میں رکھ سکتے ہیں۔

آگے کیا دیکھنا چاہیے

اگر آپ اسی طرح کے انضمام (consolidation) پر غور کر رہے ہیں، تو ان دو ستونوں سے آغاز کریں:

  1. URL استحکام – کوڈ کی ایک لائن لکھنے سے پہلے ہر عوامی پاتھ (public path) کا نقشہ بنائیں۔
  2. ڈیٹا کا استحکام – ڈیٹا بیس کے فیلڈز کا نام تبدیل کرنے سے گریز کریں جب تک کہ آپ مکمل مائیگریشن کے لیے تیار نہ ہوں۔

وہاں سے، ایک چھوٹا لوڈر بنائیں، CSS کو اسکوپ (scope) میں رکھیں، اور ایک سخت پروڈکشن چیک لسٹ چلاتے ہوئے ایک وقت میں ایک ماڈیول منتقل کریں۔