Optistream iliunganisha programu nyongeza (plugins) kumi na mbili za WordPress zilizoundwa mahususi kuwa kanuni moja (single codebase) bila kupoteza SEO kwa kurasa zake elfu moja za umma.

Kwa nini muunganisho huo ulikuwa muhimu

Tovuti ya kawaida ya WordPress huishia kuwa na programu nyongeza chache; tovuti kubwa zaidi huonekana kama karakana iliyojaa nyaya, kila moja ikitoa mwangwi lakini hakuna rahisi kuichomoa. Tovuti ya Optistream ilikuwa ikitumia programu nyongeza kumi na mbili zilizoundwa mahususi zilizoshughulikia wasifu wa watangazaji (streamer profiles), timu za esports na data za michezo. Programu hizo zilitoa kurasa elfu moja zinazoweza kuorodheshwa (indexable pages). Kuweka URL hizo bila mabadiliko haikuwa jambo la kujadili—mabadiliko yoyote yangeharibu uhamisho huo.

Jinsi mpangilio wa zamani ulivyokuwa

Programu hizo kumi na mbili kila moja ilikuwa katika folda yake, ilisajili aina yake ya chapisho (custom post type), na kuunganishwa (hooked) kwenye WordPress katika sehemu tofauti. Matatizo yalijirundika:

  • Hooks na rasilimali (assets) zilikuwa zimesambaa, na kufanya iwe vigumu kutabiri ni kanuni gani iliyofanya kazi lini.
  • Mantiki ya uelekezaji (routing logic) ilikuwa katika faili nyingi tofauti, hivyo URL moja ingeweza kuathiriwa na programu nyongeza kadhaa.
  • Faili za CSS zilipakia kwa mpangilio usiotabirika, na kusababisha migongano ya mitindo (style clashes).
  • Kutafuta makosa (debugging) kulihitaji kufungua miongozo (directories) kumi na mbili tofauti, jambo lililopoteza muda kwa msanidi programu yeyote.

Lengo halikuwa kupunguza idadi ya faili; lilikuwa ni kuipa mfumo mzima mzunguko mmoja wa maisha (lifecycle) na sehemu moja ya kusimamia utegemezi (dependencies).

Jinsi uhamisho ulivyopangwa

Timu ilichukulia kiolesura cha umma—URL, kiolezo (templates) na data za meta—kama mkataba usiooweza kuvunjika. Kitu chochote kilichobadilika upande wa mbele (front end) kingehesabiwa kama kufeli. Kwa kuzingatia sheria hiyo, waliandaa orodha ya ukaguzi (checklist) ya kufanya baada ya kila hatua.

1. Orodhesha mikataba ya umma

Kila njia ya URL iliandikwa pamoja na aina yake ya chapisho, rewrite slug, faili la kiolezo na funguo za meta (meta keys) ambazo ilitegemea. Jedwali hili likawa kitabu cha sheria: ikiwa URL ingebadilika baada ya moduli kuhamishwa, uhamisho huo ungelazimika kurudishwa nyuma.

2. Jenga kichaji (loader) rahisi

Faili ndogo ya bootstrap iliundwa. Kila programu nyongeza ya awali sasa inasajili "content domain" moja kupitia jina la kazi (function name) linalotabirika. Kichaji hicho hakifanyi jambo lolote la kiakili—kinatosha tu kuvuta moduli sahihi kwenye WordPress inapohitajika. Urahisi hufanya makosa yaonekane wazi.

3. Linda data

Kubadilisha majina ya funguo za meta kungebadilisha mabadiliko ya kanuni kuwa uhamisho wa data, na kuongeza hatari isiyo ya lazima. Funguo za zamani zilibaki bila kuguswa; kazi saidizi (helper functions) mpya zinazifunika, na kuweka muundo wa kanzi data (database schema) kuwa thabiti.

4. Rekebisha umiliki wa CSS

Migongano ya mitindo ilitatuliwa kwa hatua tatu:

  • Faili za CSS za moduli zinawekwa kwenye foleni (enqueued) kwa kipaumbele cha juu ili zipakie mwisho.
  • Vichaguzi (selectors) vyote vimefungwa (scoped) kwenye darasa la kizuizi (wrapper class) la kipekee kwa kila moduli.
  • filemtime() inatumiwa wakati wa kuweka kwenye foleni ili kusafisha kumbukumbu za kivinjari (browser caches) ikiwa mtindo (stylesheet) utabadilika.

5. Tumia mzunguko salama

Uhamisho uliendelea moduli moja baada ya nyingine. Baada ya kuhamisha moduli, timu ilithibitisha usajili wa aina ya chapisho, uelekezaji (routing) na mpangilio wa simu kabla ya kugusa inayofuata. Programu nyongeza za awali zilibaki zikiwa zimewekwa lakini hazijawashwa, zikitoa njia ya haraka ya kurudisha hali ya awali.

Orodha ya ukaguzi wa uzalishaji

Baada ya kila kubadilisha moduli, timu ilithibitisha:

  • Kila URL ya aina ya maudhui inarudisha hali ya HTTP ya 200.
  • Kichwa cha URL cha kanonika (canonical URL header) kinafanana na URL ya awali.
  • Vichwa vya kurasa na maelezo ya meta hayajabadilika.
  • Picha zote zinapakia bila viungo vilivyovunjika.
  • Hakuna mwingiliano wa mlalo (horizontal overflow) unaotokea kwenye skrini za simu.
  • Konsoli ya kivinjari inaonyesha makosa ya JavaScript au CSS sifuri.

Ni pale tu orodha ya ukaguzi ilipokamilika ndipo timu ilizima programu nyongeza ya zamani moja kwa moja.

Kile programu nyongeza mpya inachotoa

Programu nyongeza moja iliyopatikana haipunguzi kanuni (codebase); inafanya tu mipaka ionekane wazi. Maeneo yote kumi na mawili ya utendaji sasa yanashiriki mzunguko mmoja wa maisha, seti moja ya hooks na sehemu moja ya kusimamia utegemezi. Programu nyongeza mpya haikufanya mfumo uwe mdogo. Ilifanya mipaka ionekane. Hilo lilithibitika kuwa na manufaa zaidi kuliko kuwa na programu nyongeza chache.

Hatari na hoja za kinyume

Kisa cha Optistream kinaonyesha kuwa mbinu ya nidhamu inayozingatia mkataba kwanza na utekelezaji wa hatua kwa hatua inaweza kudhibiti hatari.

Nini cha kuzingatia baadaye

Ikiwa unafikiria kuunganisha kwa namna inayofanana, anza na nguzo hizi mbili:

  1. Utulivu wa URL – panga kila njia ya umma kabla ya kuandika mstari wowote wa kanuni.
  2. Utulivu wa data – epuka kubadilisha majina ya nyanja za kanzi data (database fields) isipokuwa kama uko tayari kwa uhamisho kamili.

Kutoka hapo, jenga kichaji kidogo, weka CSS ikiwa imefungwa (scoped), na uhamishe moduli moja baada ya nyingine huku ukitekeleza orodha thabiti ya ukaguzi wa uzalishaji.