Optistream தனது ஆயிரம் பொதுப் பக்கங்களுக்கான SEO-வை இழக்காமல், பன்னிரண்டு தனிப்பயன் WordPress plugins-களை ஒரே codebase-ஆக இணைத்தது.
இந்த இணைப்பின் முக்கியத்துவம் என்ன
ஒரு சாதாரண WordPress தளம் சில plugins-களைக் கொண்டிருக்கும்; ஆனால் பெரிய தளங்கள், பல ஒயர்கள் நிறைந்த ஒரு பட்டறை போல இருக்கும்—ஒவ்வொன்றும் இயங்கிக் கொண்டிருக்கும், ஆனால் எதையும் எளிதாகத் துண்டிக்க முடியாது. Optistream தளம் streamer profiles, esports teams மற்றும் game data ஆகியவற்றைக் கையாளும் பன்னிரண்டு பிரத்யேக plugins-களைப் பயன்படுத்தியது. அந்த plugins ஆயிரம் indexable பக்கங்களை உருவாக்கின. அந்த URLs அப்படியே இருப்பதை உறுதி செய்வது மிக முக்கியமானது—ஏதேனும் மாற்றம் ஏற்பட்டால் அது migration திட்டத்தையே தோல்வியடையச் செய்திருக்கும்.
பழைய அமைப்பு எப்படி இருந்தது
அந்த பன்னிரண்டு plugins ஒவ்வொன்றும் தனித்தனி கோப்புறைகளில் (folder) இருந்தன, ஒவ்வொன்றும் தனக்கென ஒரு custom post type-ஐப் பதிவு செய்தன, மேலும் WordPress-ன் வெவ்வேறு புள்ளிகளில் hook செய்திருந்தன. இதனால் பல சிக்கல்கள் உருவாயின:
- Hooks மற்றும் assets சிதறிக்கிடந்தன, இதனால் எந்தக் குறியீடு (code) எப்போது இயங்கும் என்பதைக் கணிப்பது கடினமாக இருந்தது.
- Routing logic பல தனித்தனி கோப்புகளில் இருந்ததால், ஒரு single URL பல plugins-ஆல் பாதிக்கப்பட வாய்ப்பிருந்தது.
- CSS கோப்புகள் கணிக்க முடியாத வரிசையில் ஏற்றப்பட்டதால், style clashes ஏற்பட்டன.
- Debugging செய்ய பன்னிரண்டு வெவ்வேறு கோப்பகங்களைத் (directories) திறக்க வேண்டியிருந்தது, இது எந்தவொரு developer-க்கும் நேர விரயத்தை ஏற்படுத்தியது.
கோப்புகளின் எண்ணிக்கையைக் குறைப்பதே இலக்கு அல்ல; மாறாக, முழு அமைப்பிற்கும் ஒரு ஒற்றை lifecycle மற்றும் dependencies-களை நிர்வகிக்க ஒரு ஒற்றை இடத்தைக் கொடுப்பதே இலக்கு.
migration எவ்வாறு திட்டமிடப்பட்டது
பொது இடைமுகம் (public interface)—அதாவது URLs, templates மற்றும் meta data—எந்த வகையிலும் மாற்ற முடியாத ஒரு ஒப்பந்தமாக அந்தத் குழு கருதியது. front end-இல் ஏதேனும் மாற்றம் ஏற்பட்டால் அது தோல்வியாகக் கருதப்படும். அந்த விதியைக் கருத்தில் கொண்டு, ஒவ்வொரு படிநிலைக்குப் பிறகும் சரிபார்க்க ஒரு checklist-ஐ அவர்கள் தயாரித்தனர்.
1. பொது ஒப்பந்தங்களைப் பட்டியலிடுதல்
ஒவ்வொரு URL பாதையும் அதன் post type, rewrite slug, template file மற்றும் அது சார்ந்த meta keys ஆகியவற்றுடன் எழுதப்பட்டது. இந்த spreadsheet ஒரு விதிமுறைப் புத்தகமாக மாறியது: ஒரு module மாற்றப்பட்ட பிறகு URL மாறினால், migration உடனடியாகத் திரும்பப் பெறப்பட்டது (rolled back).
2. ஒரு எளிய loader-ஐ உருவாக்குதல்
ஒரு சிறிய bootstrap file உருவாக்கப்பட்டது. முன்பு இருந்த ஒவ்வொரு plugin-உம் இப்போது ஒரு கணிக்கக்கூடிய function name மூலம் ஒரு ஒற்றை “content domain”-ஐப் பதிவு செய்கிறது. இந்த loader மிகவும் சிக்கலான வேலைகளைச் செய்யாது—தேவைப்படும்போது சரியான module-ஐ WordPress-க்குள் கொண்டு வருவதற்கே போதுமானது. எளிமை என்பது தோல்விகளைத் தெளிவாகக் காட்டும்.
3. தரவைப் பாதுகாத்தல்
Meta keys-களை மறுபெயரிடுவது, ஒரு code மாற்றத்தை தரவு இடமாற்றமாக (data migration) மாற்றி, தேவையற்ற ஆபத்தை அதிகரித்திருக்கும். பழைய keys மாற்றப்படாமல் அப்படியே இருந்தன; புதிய helper functions அவற்றைப் போர்த்தியபடி (wrap) செயல்பட்டு, database schema-வை நிலையாக வைத்திருந்தன.
4. CSS உரிமையைக் கையாளுதல்
Styling மோதல்கள் மூன்று நடவடிக்கைகளின் மூலம் தீர்க்கப்பட்டன:
- Module CSS கோப்புகள் அதிக முன்னுரிமையுடன் (high priority) enqueued செய்யப்படுகின்றன, இதனால் அவை கடைசியாக ஏற்றப்படுகின்றன.
- அனைத்து selectors-களும் ஒவ்வொரு module-க்கும் ஒரு தனித்துவமான wrapper class-க்குள் வரையறுக்கப்படுகின்றன (scoped).
- stylesheet மாறினால் browser cache-களைத் தவிர்க்க, enqueuing செய்யும்போது
filemtime()பயன்படுத்தப்படுகிறது.
5. பாதுகாப்பான சுழற்சியைப் பயன்படுத்துதல்
migration ஒவ்வொரு module ஆகத் தொடர்ந்தது. ஒரு module-ஐ மாற்றிய பிறகு, அடுத்ததைத் தொடங்குவதற்கு முன் post-type registration, routing மற்றும் mobile layout ஆகியவற்றைத் team சரிபார்த்தது. அசல் plugins நிறுவப்பட்டிருந்தாலும் செயலிழந்த நிலையில் (inactive) இருந்தன, இது உடனடியாகத் திரும்பப் பெறுவதற்கான (rollback) வழியை வழங்கியது.
Production checklist
ஒவ்வொரு module மாற்றத்திற்குப் பிறகும் team சரிபார்த்தவை:
- ஒவ்வொரு content-type URL-உம் 200 HTTP status-ஐத் தருகிறதுவா?
- Canonical URL header அசல் URL-உடன் ஒத்துப்போகிறதா?
- Page titles மற்றும் meta descriptions மாற்றப்படாமல் உள்ளனவா?
- அனைத்துப் படங்களும் broken links இல்லாமல் ஏற்றப்படுகின்றனவா?
- மொபைல் திரைகளில் horizontal overflow எதுவும் தோன்றுகிறதா?
- Browser console-இல் JavaScript அல்லது CSS பிழைகள் ஏதும் இல்லை என்பதை உறுதி செய்தல்.
checklist முழுமையாகச் சரிபார்க்கப்பட்ட பின்னரே, team பழைய plugin-ஐ நிரந்தரமாக முடக்கியது (deactivate).
புதிய plugin என்ன வழங்குகிறது
இதன் விளைவாக உருவான ஒற்றைப் plugin codebase-ஐச் சுருக்குவதில்லை; அது எல்லைகளைத் தெளிவாகக் காட்டுகிறது. பன்னிரண்டு செயல்பாட்டுப் பகுதிகளும் இப்போது ஒரே lifecycle, ஒரே set of hooks மற்றும் dependencies-களை நிர்வகிக்க ஒரே இடத்தைப் பகிர்ந்து கொள்கின்றன. புதிய plugin அமைப்பைக் குறைக்கவில்லை. அது எல்லைகளைத் தெளிவாகக் காட்டியது. இது குறைவான plugins வைத்திருப்பதை விட அதிக பயனுள்ளதாக அமைந்தது.
அபாயங்கள் மற்றும் எதிர்வாதங்கள்
ஒரு ஒழுக்கமான contract-first அணுகுமுறை மற்றும் படிப்படியான rollout முறையைப் பின்பற்றுவதன் மூலம் அபாயங்களைக் கட்டுப்படுத்த முடியும் என்பதை Optistream வழக்கு காட்டுகிறது.
அடுத்து கவனிக்க வேண்டியவை
நீங்கள் இதே போன்ற ஒரு ஒருங்கிணைப்பைக் கருதுகிறீர்கள் என்றால், இந்த இரண்டு தூண்களுடன் தொடங்குங்கள்:
- URL stability – ஒரு வரியைக் கூடக் குறியீடாக (code) எழுதுவதற்கு முன், ஒவ்வொரு பொதுப் பாதையையும் (public path) வரைபடமாக்குங்கள் (map).
- Data stability – முழுமையான தரவு இடமாற்றத்திற்கு (full migration) நீங்கள் தயாராக இல்லையென்றால், database fields-களை மறுபெயரிடுவதைத் தவிர்க்கவும்.
அங்கிருந்து, ஒரு சிறிய loader-ஐ உருவாக்கி, CSS-ஐ scoped ஆக வைத்துக்கொண்டு, ஒரு முறையான production checklist-ஐப் பின்பற்றி ஒவ்வொரு module ஆக மாற்றவும்.