Optistream ने त्यांच्या एक हजार सार्वजनिक पेजेससाठीचे SEO न गमावता, बारा कस्टम WordPress प्लगइन्स एकाच कोडबेसमध्ये एकत्रित केले.
हे विलीनीकरण का महत्त्वाचे होते
एक सामान्य WordPress साइटवर काही प्लगइन्स असतात; परंतु मोठी साइट एखाद्या तारांनी भरलेल्या वर्कशॉपसारखी दिसते, जिथे प्रत्येक तार कार्यरत असते पण कोणतीही सहजपणे काढता येत नाही. Optistream च्या साइटवर बारा विशेष (bespoke) प्लगइन्स चालत होते जे स्ट्रीमर प्रोफाइल्स, ईस्पोर्ट्स टीम्स आणि गेम डेटा हाताळत होते. या प्लगइन्समुळे एक हजार इंडेक्स करण्यायोग्य (indexable) पेजेस तयार होत होते. त्या URL सुरक्षित ठेवणे अत्यंत आवश्यक होते—कोणत्याही बदलामुळे हे स्थलांतर (migration) अयशस्वी ठरले असते.
जुनी रचना कशी होती
ते बारा प्लगइन्स प्रत्येकी स्वतःच्या फोल्डरमध्ये होते, स्वतःचा कस्टम पोस्ट टाईप रजिस्टर करत होते आणि वेगवेगळ्या ठिकाणी WordPress शी जोडलेले (hooked) होते. समस्या वाढत गेल्या:
- हुक्स (Hooks) आणि ॲसेट्स विखुरलेले होते, ज्यामुळे कोणता कोड कधी रन होईल याचा अंदाज घेणे कठीण झाले होते.
- राउटिंग लॉजिक अनेक वेगवेगळ्या फाईल्समध्ये होते, त्यामुळे एकाच URL वर अनेक प्लगइन्सचा परिणाम होऊ शकत होता.
- CSS फाईल्स अनपेक्षित क्रमाने लोड होत होत्या, ज्यामुळे स्टाईलमध्ये संघर्ष (clashes) होत होते.
- डीबगिंगसाठी बारा वेगवेगळ्या डिरेक्टरीज उघडाव्या लागत्या, ज्यामुळे डेव्हलपरचा बराच वेळ वाया जात असे.
उद्दिष्ट फाईल्सची संख्या कमी करणे हे नव्हते; तर संपूर्ण सिस्टमला एकच लाइफसायकल आणि डिपेंडेंसीज (dependencies) व्यवस्थापित करण्यासाठी एकच ठिकाण देणे हे होते.
स्थलांतराचे (migration) नियोजन कसे केले गेले
टीमने पब्लिक इंटरफेस—URLs, टेम्पलेट्स आणि मेटा डेटा—यांना एका कराराप्रमाणे (contract) मानले ज्याचे उल्लंघन करता येणार नाही. फ्रंट एंडवर काहीही बदलले तर ते अपयश मानले जाणार होते. हा नियम लक्षात घेऊन त्यांनी प्रत्येक टप्प्यानंतर तपासण्यासाठी एक चेकलिस्ट तयार केली.
1. पब्लिक कॉन्ट्रॅक्ट्सची यादी करा
प्रत्येक URL पाथ त्याचा पोस्ट टाईप, रीराईट स्लग (rewrite slug), टेम्पलेट फाईल आणि त्यावर अवलंबून असलेल्या मेटा कीज (meta keys) सह लिहून काढले गेले. ही स्प्रेडशीट नियमावली बनली: जर एखादा मॉड्यूल हलवल्यानंतर URL बदलली, तर स्थलांतर (migration) मागे (roll back) घेतले जाई.
2. एक साधा लोडर तयार करा
एक छोटी बूटस्ट्रॅप (bootstrap) फाईल तयार करण्यात आली. पूर्वीचे प्रत्येक प्लगइन आता एका अंदाजित फंक्शन नावाद्वारे एकच "content domain" रजिस्टर करते. लोडर काहीही क्लिष्ट काम करत नाही—गरज असेल तेव्हा योग्य मॉड्यूल WordPress मध्ये खेचण्यासाठी ते पुरेसे आहे. साधेपणामुळे त्रुटी स्पष्टपणे लक्षात येतात.
3. डेटा सुरक्षित ठेवा
मेटा कीजचे (meta keys) नाव बदलल्यामुळे कोडमधील बदल हे डेटा मायग्रेशनमध्ये रूपांतरित झाले असते, ज्यामुळे अनावश्यक धोका निर्माण झाला असता. जुन्या कीज तशाच ठेवल्या गेल्या; नवीन हेल्पर फंक्शन्स त्यांना वेढतात (wrap), ज्यामुळे डेटाबेस स्कीमा स्थिर राहतो.
4. CSS मालकी (ownership) निश्चित करा
स्टाईलिंगमधील संघर्ष तीन उपायांनी सोडवले गेले:
- मॉड्यूल CSS फाईल्स उच्च प्राधान्याने (high priority) एनक्यू (enqueue) केल्या जातात जेणेकरून त्या शेवटी लोड होतील.
- सर्व सिलेक्टर्स (selectors) प्रत्येक मॉड्यूलसाठी एका अद्वितीय रॅपर क्लाससाठी (unique wrapper class) मर्यादित (scoped) केले आहेत.
- स्टाईलशीट बदलल्यास ब्राउझर कॅशे (cache) क्लिअर करण्यासाठी एनक्यू करताना
filemtime()चा वापर केला जातो.
5. सुरक्षित लूप वापरा
स्थलांतर एका वेळी एक मॉड्यूल याप्रमाणे पुढे गेले. एक मॉड्यूल हलवल्यानंतर, टीमने पुढच्या मॉड्यूलला हात लावण्यापूर्वी पोस्ट-टाईप रजिस्ट्रेशन, राउटिंग आणि मोबाईल लेआउटची पडताळणी केली. मूळ प्लगइन्स इन्स्टॉल पण निष्क्रिय (inactive) स्थितीत ठेवले होते, ज्यामुळे त्वरित रोलबॅक करण्याचा मार्ग उपलब्ध होता.
प्रोडक्शन चेकलिस्ट
प्रत्येक मॉड्यूल बदलल्यानंतर टीमने खालील गोष्टींची पडताळणी केली:
- प्रत्येक कंटेंट-टाईप URL 200 HTTP स्टेटस रिटर्न करते का.
- कॅनोनिकल (canonical) URL हेडर मूळ URL शी जुळते का.
- पेज टायटल्स आणि मेटा डिस्क्रिप्शनमध्ये कोणताही बदल झालेला नाही ना.
- सर्व इमेजेस तुटलेल्या लिंक्सशिवाय (broken links) लोड होतात का.
- मोबाईल स्क्रीनवर कोणताही हॉरिझॉन्टल ओव्हरफ्लो (horizontal overflow) दिसत नाही ना.
- ब्राउझर कन्सोलमध्ये शून्य JavaScript किंवा CSS एरर्स दिसत आहेत ना.
चेकलिस्ट पूर्णपणे यशस्वी झाल्यावरच टीमने जुने प्लगइन कायमचे निष्क्रिय केले.
नवीन प्लगइन काय प्रदान करते
परिणामी सिंगल प्लगइनमुळे कोडबेस लहान होत नाही; ते फक्त सीमा (boundaries) स्पष्ट करते. आता सर्व बारा कार्यात्मक क्षेत्रे एकच लाइफसायकल, हुक्सचा एक संच आणि डिपेंडेंसीज व्यवस्थापित करण्यासाठी एकच ठिकाण वापरतात. नवीन प्लगइनने सिस्टम लहान केली नाही, तर तिचे घटक स्पष्ट केले. प्लगइन्सची संख्या कमी करण्यापेक्षा हे अधिक उपयुक्त ठरले.
जोखीम आणि प्रतिवाद
Optistream चे प्रकरण दर्शवते की शिस्तबद्ध 'कॉन्ट्रॅक्ट-फर्स्ट' दृष्टिकोन आणि टप्प्याटप्प्याने केलेली अंमलबजावणी जोखीम नियंत्रणात ठेवू शकते.
पुढे काय पाहावे
जर तुम्ही अशाच प्रकारच्या एकत्रीकरणाचा विचार करत असाल, तर या दोन स्तंभांपासून सुरुवात करा:
- URL स्थिरता – कोडची एक ओळ लिहिण्यापूर्वी प्रत्येक सार्वजनिक पाथ मॅप करा.
- डेटा स्थिरता – जोपर्यंत तुम्ही पूर्ण मायग्रेशनसाठी तयार नसाल, तोपर्यंत डेटाबेस फील्ड्सची नावे बदलणे टाळा.
तिथून पुढे, एक छोटा लोडर तयार करा, CSS स्कॉप्ड (scoped) ठेवा आणि कडक प्रोडक्शन चेकलिस्ट पाळत असताना एकेक मॉड्यूल हलवत जा.