Helló 2020, helló új blogmotor - de hogyan is történt a váltás?

Végre egy új post, arról, hogy hogyan cseréltem ki a szoftvert, amivel a blog készül.

Igen, még emlékszem rá, hogy valaha írogattam ide. 😂 Ez a negyedik nagyobb nekifutás ennek a blogolásnak nevezett mókának. Több mint két év telt el az utolsó valamirevaló bejegyzés óta, és mostanra már nagyon erős bennem az érzés, hogy ezen változtatni kéne. De persze, ahogy ez IT-seknél lenni szokott, előtte egész egyszerűen muszáj volt mindent átalakítani. 😉 Ennek megfelelően a blog új motort kapott, a korábban használt Hexo lecserélődött Hugo-ra. Olvass tovább, ha kíváncsi vagy, hogy miért és hogyan történt ez!

A blogolás mindig elég jó indokot adott arra, hogy végtelen mennyiségű időt töltsek el webes technológiák pofozgatásával 😂 Még annak idején 2006-ban fogtam hozzá először, középiskolás fejjel, minimális webes tudással, az azóta megboldogult Freeblog platformon. 2012-ben, amikor a Freeblog végleg kezdte beadni a kulcsot, már lényegesen több webes tapasztalattal álltam neki WordPress-re átültetni az oldalt, ami viszonylag kényelmesen kiszolgált egészen 2016-ig. Addigra viszont elkezdtem kételkedni benne, mert egy csomó minden, amiben a WP előnyét látom, szerintem egyszerűen nem igazán éri meg, hogyha egy nem csapatostul írogatsz. Viszont cserébe behoz egy csomó fenntartási költséget:

  • plugineket kell frissítgetni,
  • komolyabb tárhelyet kell fenntartani (PHP, MySQL, …),
  • a dinamikus mivoltából eredően mindig támadási felületet jelent,

…röviden: egy csomó feleslegesnek tűnő meló van vele. Ekkor döntöttem úgy, hogy teszek egy próbát a statikus oldalgenerátorokkal, amikhez elég egy sokkal egyszerűbb hosting is. Átálltam a Hexo nevű, nagyban kínai fejlesztésű blogmotorra, a kiszolgálására pedig sikerült összelőnöm egy igen jó teljesítményű, mégis faék egyszerűségű AWS S3 + Cloudfront megoldást.

De ez az örömöm se tartott addig, ameddig szerettem volna, mert volt egy pár dolog, ami elvette a kedvem ettől a felállástól. Az egyik az volt, hogy a statikus motorra ugrással egy ideig elvesztettem azt a képességet, hogy bármelyik gépemről írjak. Nem volt meg a szükséges verziókövetés (ekkoriban vált elérhetővé az ingyenes privát repo GitHubon, máshova meg nem akartam volna tenni), emellett vacak volt felállítani a Hexo-t minden gépen stb. Ez egy olyan időszakban, amikor kb. ingázás közben lenne a legjobb esélyem blogolni, eléggé negatívum… Végülis ezt azzal oldottam meg pár hónappal ezelőtt, hogy a GitHub Actions segítségével a blog összeépítését, illetve tárhelyre feltöltését teljesen automatizáltam. (Ezt addig sikerült tolni, hogy ha PR-t küldök a blog GitHub repo-jába, egy teszt környezetbe tölti fel az oldalt, szóval külön URL-en ki tudom próbálni a nagyobb módosításokat… Nem jön rosszul 😂) De amikor ezt csináltam, akkor vált igazán szembetűnővé, hogy a Hexo igazából bizonyos szempontból nézve borzalmas. A következő bajaim lettek vele:

  • A Hexo dokumentációja hagy kívánnivalókat maga után; rengeteg részletet hamarabb tudsz meg elejtett Disqus kommentekből, mint a leírásokból.
  • A Hexo-val egyszerűen lehetetlenség normális többnyelvű blogot csinálni. Tekintve, hogy sok írásomat szívesen megmutatnám olyan kollégáimnak, akik nem beszélnek magyarul, ez elég elkeserítő. Persze, lehetne az angol nyelvű dolgokat más helyre vinni - Medium-ra, például, amivel futottam is egy kört -, de szerettem volna ezeket a személyesebb tartalmakat egy helyen tartani.
  • Ha Hexo-val építed fel a tartalmakat, az egészen irgalmatlanul lassú, még az én nem túl nagy mennyiségű tartalmammal is 30-40 másodperc, amíg összeáll a kész statikus tartalom.

Ha jól emlékszem, az egyik kollégám, Boros Gábor tanácsolta még anno a Hugo-t, amire aztán a fent leírt problémák miatt váltottam. A Hugo normálisan támogatja a többnyelvűséget, remek a dokumentációja és van értelmes felhasználói közössége, ami eléggé jól jön, főleg ha épp egy ilyen migrációval vackolsz… Ezen felül a Node.js-re alapuló Hexo-t a Go-alapú Hugo sebességben is lekörözi: a jelenlegi blog tartalmak mellett ez a 30-40 másodperces build helyett fél másodperces buildet jelent.

Az ilyen migráció mindig fájdalmas, főleg azért is, mert az új rendszerre való átállás általában megpiszkálja a tartalmaidat is, az oldalad megjelenését is, és az összes komponenst, ami összeköti a kettőt… Végül nekem a következő munkafolyamat vált be nagyjából:

  1. Kezdd el nulláról felépíteni a blogot az új rendszerrel, konfiguráld be úgy, hogy amennyire lehet, hasonlítson a korábbi rendszer beállításaira, és próbáld meg összelőni azokkal az új feature-ökkel, amiket szeretnél.

    Itt nekem főleg azzal gyűlt meg a bajom, hogy megértsem, hogy a Hugo hogyan kezeli a permalinkeket. Az már viszonylag hamar kiderült, hogy nem lehet teljesen ugyanarra a működésre rávenni, mint a Hexo-t, viszont ez azt jelentette volna, hogy elbukom a meglevő cikkek URL-jeit! Ez SEO szempontból nem lett volna remek, mert az AWS-es felállással nem lett volna túl egyszerű átirányításokat beállítani. (Na nem mintha akkora forgalmam lenne, hogy ezen szét kéne aggódnom magam, de akkor is…) A másik, amit viszonylag sokat kellett próbálgatni, az a többnyelvűség, kellett némi játszadozás, amíg rájöttem, hogy lehet majd magyar+angol nyelvű kombinált post-okat létrehozni. Ez a tartalmak kategorizálását is érinti, mert a tartalmi címkék is fordításra kerülnek.

  2. Válassz ki több theme-t, próbáld ki őket, hogy melyiket tudod használni majd.

    Egy ilyen komplex migrációban általában nem jó ötlet még egy teljesen új theme írását is bevállalni - van szerintem elég bajunk enélkül is… De ettől még elég jónak kell lennie a theme-nek ahhoz, hogy hozzá tudj nyúlni. Nekem a választásom a Meme témára esett végül, mert nagyban hasonlított a layout arra, amit akarok (szeretem, ha viszonylag zavarmentesek, szövegközpontúak a blogok), és elég sok konfigurálási lehetőséget meg jópofa trükköt (pl. éjszakai mód) tud. Ami szintén elég fontos volt, a példa konfigurációjában voltak utalások arra, hogy mit is kéne a többnyelvűséghez pontosan csinálni, amire nem találtam túl sok példát máshol. Addig viszont, amíg eljutottam a Meme-ig, vagy 4 másik theme-et ki kellett próbálnom, el kellett kezdeni kalapálni őket, csak hogy belássam, nem lesznek jó választás…

  3. Ha eljutottál addig, hogy van egy elfogadható prototípus kereted, próbáld meg elkezdeni átmozgatni a tartalmakat, és próbáld meg script-ben rögzíteni a szükséges átalakításokat.

    Rengeteg lépést igényel a tartalmak átalakítása két rendszer között, például amivel egész biztos meggyűlik a baja az embernek, az a shortcode-ok kezelése. Én 8-10 különböző shortcode-ot használok, és ebből egy pár eléggé ráépül a rendszer trükkjeire. (Az a shortcode-om, amivel a képeket beszúrom, például most már ki tudja használni a Hugo saját képméretezési képességeit, amit annak idején a Hexo-val csak egy közepesen borzalmas Gulp toolinggal tudtam még megoldani.) Szóval ebben a fázisban jött az az ötlet, hogy jobb lesz, ha inkább elkezdem egy shell script-ben automatizálni ezeknek a keresés-cseréjét. Nyilván a tartalmak strukturálása is más a két rendszer között, más a mapparendszer, mások a fájlok nevei… szóval ezt nagyon jó, ha egy script-tel tudod próbálgatni, mert kismilliószor kell majd nekifutnod, mire mindent el fogsz tudni találni. Ebből a szempontból még az is vicces lehet, ha például a két rendszer nem egészen ugyanolyan módon értelmezi a Markdown-t, amire sikerült rá is szaladnom ügyesen…

    Ennek a fázisnak akkor van sikeresen vége, amikor a shell scripted lefut, és a végeredményt megnézve már nem igazán találsz hibákat. Ehhez csomószor végig kellett olvasnom az össze nyavalyás post-omat, mert nem igazán volt ötletem, hogy mégis hogyan lehetne automatizálva tesztelni ezeket. De egy idő után csak elfogytak a hibák. Ha nagyon profi vagy, akkor csinálhatod azt is, hogy egy először egy külön teszt fájlba összerakod az összes tartalmi trükköt, amit valaha csináltál (minden shortcode-ot, formázást), és indulásképp csak azt próbálod meg megoldani, utána haladsz a rendes tartalmakra.

  4. Ezek után már csak az utolsó finomhangolások vannak hátra, mint például, hogy fel tudd tölteni az új motorral előállított kimenetet.

    Ez nálam azt jelentette, hogy a korábbi Git repo-ba át kellett vinni a módosításokat, illetve át kellett írni a GitHub Action-öket. Szerencsére az action-ök - pont a Hugo egyszerűbb kezelhetősége és jobb támogatottsága miatt - lényegesen leegyszerűsödtek, tulajdonképpen főleg csak törölnöm kellett…

Elég sok tanulsága volt ennek az átállásnak, főleg, ami a megfelelő komponensek, rendszerek kiválasztását illeti. (Mostani fejjel azt hiszem, ez már egy stabilabb megoldás lesz, mondjuk ugyanilyen valószínűséggel előfordulhat az is, hogy négy év múlva visszaolvasom ezt a bejegyzést, hogy megtervezhessem a következő átállást.) 🤣 Az egyik fő tanulság, hogy muszáj készen állni arra, hogy bash script-eket írjon az ember, még ha nem is használom ezt általában a mindennapi munkámban. Ez a fajta felhasználás nem igényel túl komoly ismereteket, de sok apróság pokollá tudja tenni a hatékony munkát. Személyes példa: ráfutottam arra, hogy macOS-en az alap BSD sed helyett jobban megérné a GNU sed-et használni, meg hát a find/xargs kombinációval is jobban meg kellett ismerkedni.

Mindent egybevetve, most viszonylag elégedett és lelkes vagyok. Remélem ez megmarad, és persze az is jó lenne, ha ki is tudnám használni, hogy van ez a blog. Ötleteim arról, hogy miről is kéne beszámolnom nektek, egyre több van, úgyhogy “csak” írni kell. Mindenesetre, egy kis biztatás jól jönne, úgyhogy ha úgy vagy vele, örömmel venném a visszajelzéseidet 😊

comments powered by Disqus
Hugo használatával készült
A Stack dizájnt Jimmy tervezte