Korábban a Psono.com-ot az Odoo v11 hajtotta. Az Odoo kiváló CMS, ám ahogy megtapasztaltuk, a frissítések nehézkesek. Különösen a weboldal modulja okozott sok problémát a tesztelés során. Az Odoo v11 2020 végén éri el életciklusa végét, így kénytelenek voltunk megoldást keresni.
Több lehetőségen is gondolkodtunk: akár frissítjük Odoo v13-ra és kézzel átvisszük az összes tartalmat és testreszabást, akár megbízunk valakit a migrációval, vagy teljesen új CMS-re váltunk. Úgy döntöttünk, hogy teljesen elhagyjuk a Psono.com-on az Odoo-t, és a v11-et tűzfal mögött üzemeltetjük tovább, később pedig migráljuk (erről még nem döntöttünk).
Döntésünk okai:
- Nagyon kevés tartalom van, amit migrálnunk kellene a Psono.com-ra. Főleg néhány blogposzt.
- Az Odoo v13-ra váltás ugyanezt a problémát okozná két éven belül, amikor a v13 is eléri az EOL-ját – ráadásul akkorra már sokkal több lenne az átvivendő adat.
- Nem voltunk elégedettek az Odoo v11 weboldalainak testreszabási lehetőségeivel sem. Minden rendkívül bonyolult, a sablonok az adatbázisban vannak tárolva.
- Az árak. Ha mással csináltatnánk meg a migrációt, legalább 5000 USD-be kerülne, de inkább többe.
- Bár az Odoo közössége kezdetben nagyon aktív volt, az utóbbi években a licencváltásokkal, a funkciók és bővítmények fizetőssé tételével és azzal, hogy mindent fizetős fal mögé toltak, gyakorlatilag meghalt a közösség.
- A Psono.com főleg statikus oldal, statikus tartalommal. Ha mégis dinamikus tartalom kellene, azt API-kkal is be tudnánk húzni.
Az út
Miután eldöntöttük, hogy váltunk, ki kellett választani a keretrendszert. Klasszikus keretrendszerek is vannak, például a hugo, amit már használtunk, de ezek funkcionalitása korlátozott. Alternatívát keresve a node / react világban is szétnéztünk.
Ide szívesen írtam volna azt, hogy „kiváló megoldások”, de ha őszinte vagyok: a frontend fejlesztés jelenlegi, törött állapotában semmi sem érdemli ki ezt a címet. Hogyhogy törött? Emlékszel még azokra az időkre, mikor a fejlesztők egy index.html-lel és egy script taggel, ami betölti a jquery-t, már nekiállhattak weboldalt készíteni? Most már npm vagy yarn kell, érteni kell a package.json-hoz, webpack scriptekhez, modern keretrendszerekhez (mint angular vagy react), amelyek mind hozzáadják a saját kliensüket. JSX vagy typescript, funkciók, mint a hot reloading, nem megbízhatóak (fájl nem figyelt, egyes módosításokhoz teljes újraindítás kell, vagy a hot reloading túl korán indul, úgyhogy úgyis kézzel kell frissíteni) így végül gyakran le kell állítani a fejlesztőszervert, és percekig várni, amíg újra elindul (legalábbis nagyobb projektekben). (Hiányzik az az idő, amikor csak F5-öt kellett nyomni, és minden ott is volt gond nélkül!) Arról nem is beszélve, hogy fél évente új keretrendszer vagy eszköz jelenik meg, a régieket meg naponta dobnak ki. Oldalakat tudnék megtölteni a frontend fejlesztés jelenlegi helyzetével kapcsolatos panaszkodással… De térjünk vissza a fő témára.
Értelmes alternatívák híján a legjobb opciók (ebben az időben) a next.js és a gatsby voltak. Legalábbis ezt mondták egyes cikkek. Mindkettő egyformán népszerű, ha a Github csillagokat vagy a commitokat nézzük. Az egyetlen különbség, amit gyors tesztelés alapján észrevettünk, hogy a next.js-hez szükség van egy szerver komponensre, míg a gatsby statikus oldalakat hoz létre (ne lőjetek le, ha van lehetőség next.js-t is szerver nélkül futtatni! :D).
Játszottunk egy kicsit a Gatsby-vel, és megfelelőnek tűnt. A következő lépés az volt, hogy témát keressünk. A Gatsby „új” eszköz, ezért az összes elérhető téma még nagyon kezdetleges állapotban volt. Harminc perc és harminc dollár után volt egy vizuálisan tetszetős témánk, ami lefedte a főbb elemeket, és elkezdtük átalakítani.
A tárhelyszolgáltató kiválasztásakor manapság több lehetőség van: például Firebase, netlify, Cloudflare, Vercel, egyszerű GCP Cloud tároló vagy AWS Cloudfront, saját szerverek, docker konténerek Kubernetes-en (ezt muszáj volt megemlítenem!), ... (Emlékszel még azokra az időkre, amikor havi 5 dollárért béreltél egy webtárhelyet PHP-val és MySQL adatbázissal? :D ... na de ez egy másik cikk témája...)
Összehasonlítottuk őket, olvastunk véleményeket, megnéztük a lehetséges kombinációkat (pl. Cloudflare a Firebase előtt), és először a Cloudflare-rel próbálkoztunk. Nagy rajongói vagyunk a szolgáltatásuknak, így természetes választásnak tűnt, de sajnos a wrangler eszközük problémákat okozott. Folyton hibát dobott, és nem tudtunk hitelesíteni … Az első hibák másnapra eltűntek (talán az új bash segített), de a hitelesítési probléma maradt. Valószínűleg elkövettem valami hibát, de pár óra dokumentáció-olvasás és kísérletezés után feladtam.
A Netlify volt a következő jelölt, de ott vagy csatolni kell egy git tárhelyhez, és rájuk bízni az építést (mi GitLab CI-t akartunk használni), vagy kézzel feltölteni a build kimenetet. Lehet, hogy valahol van lehetőség API-n keresztül feltölteni a kimenetet, de nem találtam ilyet. Alternatíva lehetett volna, ha egy másik repóban tároljuk a build kimenetet, de ez túl bonyolultnak tűnt… Másik problémám volt az árképzésük is. Tagonként (!!) viszonylag magas összeget kérnek. Ne feledd: ez egy statikus weboldalhoz. Az olyan megfogalmazások, mint a „4× sávszélesség” rossz emlékeket ébresztettek bennem a „fair use webhosting” időkből, amikor könnyen kirakhattak, ha „túl sokat” használsz…
Negyedik lehetőségként a Firebase-t próbáltuk ki (ami egyébként ingyenes a cél sávszélesség és lekérések mellett), és itt minden elsőre működött. Korlátozottak a redirect lehetőségeik, így a régi URL-ek újakra irányítása kicsit fárasztó volt, de néhány átirányításregula után mindent működőképes lett. Az árképzésük is ésszerűnek tűnik, szerver erőforrás alapján számláznak. Érdemes elkerülni a plusz szolgáltatásaikat a vendor lock-in miatt, de nekünk csak a tárhely kellett.
A Vercelt is megnéztük röviden, de ott kötelező a Github fiókkal való bejelentkezés, és a „Cselekedjen a nevemben” jogosultság még a regisztráció előtt elriasztott.
A blog migrálása volt a legnehezebb. Végül manuálisan másoltuk át minden tartalmat. Ezt nagyobb blognál semmiképp nem javaslom, de nálunk összesen tizenöt poszt volt. A Gatsby több mechanizmust is támogat, de valami olyat akartunk, amit akár technikai háttér nélküli ember is használhat új blogposzt írásához. A markdown mellett döntöttünk, így meg kellett tanulnunk, hogyan mondjuk meg a Gatsby-nek, hogy olvassa be a markdown oldalakat. Maga a mechanizmus úgy fél napot vett igénybe a képek kezelésével együtt. Egy szép blogposzt téma és a képek további fél nap alatt kész is lettek.
Miután minden tartalmat átmigráltunk, és a témát is erősen módosítottuk, a Gitlab CI-vel automatizáltuk a telepítést, tehát egy egyszerű push máris elindítja a build folyamatot és minden kikerül Firebase-re.
Miért Gitlab és nem Github? A Github történelmi okokból vezet, jelenleg legalább a fejlesztők és projektek 80%-a ott van. A Gitlab viszont sokkal több funkciót kínált. Ezért döntöttünk régebben a Gitlab mellett, mivel a Github évekig semmit sem fejlesztett a funkcióit illetően. Ez azonban drasztikusan megváltozott, mióta a Microsoft megvette a Github-ot, és a Github Actions mérföldkő lett, de még hosszú út áll előttük, ha versenyezni akarnak a Gitlabbal. A mi összes projektünk viszont Gitlabon van, így természetes volt, hogy ezt a projektet is ott menedzseljük.
A végkövetkeztetés
És most itt tartunk:
- Gatsby mint CMS
- Kereskedelmi téma
- Markdown alapú blog
- Gitlab CI az automatikus telepítésekhez
- Firebase tárhely
Nagyon elégedettek vagyunk az eredménnyel, és az új weboldal sokkal jobban néz ki!
