Starschema Inc.

2019 január végén keresett meg a Starschema képviselője (a korábbi együttműködés pozitív tapasztalataira alapozva), hogy szeretnének egy új weboldalt készíteni. Egyértelmű volt, hogy a korábbi WordPress oldalukat kukázzuk, és nulláról húzunk fel egy teljesen újat. Az is egyértelmű volt számomra, hogy a feszített tempóban egy kiszámítható, engedelmes és flexibilis CMS-re van szükségem, amivel gyorsan lehet haladni, ezért Craft CMS-sel álltam neki a feladatnak.

A fejlesztés során meglehetősen sok iteráción keresztül jutottunk el a véglegesnek szánt dizájnhoz, ebben nagy könnyebbséget jelentett az egyes dizájnelemek komponensekre bontása és a Twig templating engine. Az arculaton és a dizájnon Fekete Balázs és csapata dolgoztak, bennük egy kompetens és nagyon türelmes csapatot ismertem meg - innen is pacsi nekik! :)

Author Experience & Design

A weboldalon található minden tartalom grafikus ("kattintgatós") felületről szerkeszthető. Az egyes aloldalakon szokásosan használt elemekre itt is szükség volt (szöveg, kép, HTML elem, sütikezelés), az alábbiakban azonban néhány említésre méltó és szokatlannak számító feature-t és megoldást szeretnék kiemelni.

Animált hero image

A főoldalon található elem teljes mértékben testreszabható az admin felületről: a háttérhez képet választhatunk, a szöveges részeket pedig szövegmezőkön keresztül tudjuk frissíteni. A legérdekesebb az animáció kérdésköre: ebben az esetben elég csak egy JSON fájlt feltölteni az admin felületen keresztül, melyet a grafikustól kapunk, és a kiválasztását követően már az ebben a fájlban található információk alapján rajzolja meg és animálja az ábrákat a felület Lottie.js-el. Természetesen ezek a fájlok az admin felületről később is újra kiválaszthatóak, így az idő előrehaladtával egy szép animáció-gyűjteményt tudhatunk magunkénak.

Call-to-action elemek

Az oldalakon szétszórva erre gyakran van szükség, azonban az nem gyakori, hogy ezeket "sablonként" elmentjük a tartalomkezelőbe. Ebben az esetben azonban ez történt: a különféle CTA elemek saját "channel"-t kaptak az admin felületen belül, ahol teljesen szabadon lehetett kialakítani a szükséges mezőket, majd ezek alapján lekódolni a megjelenésüket. Innentől ha egy cím-alcím-gombszöveg-gombfeladat kombinációt újra szeretnénk használni, nem kell újra és újra beírni ugyanazokat az adatokat, hanem csak egyszerűen kiválasztjuk a már elkészültek közül, és a weboldalon a kívánt helyen ezek megjelennek.

Videó

Az oldalra feltöltött videót ugyanott tároljuk, ahol az összes többi assetet, méghozzá egy DigitalOcean Spaces bucket-ben (erről részletesebben kicsit később). A megjelenítéshez a sima HTML5 <video> tag-et használom, a tartalomszerkesztőnek pedig csak annyi a dolga, hogy kiválasztja a megjelenítendő videót - a többiről gondoskodik a sablonrendszer.

Knowledge base elemek

A közelmúlt egy fontos fejlesztése a Knowledge Base, ahol többféle formátumú, típusú és megjelenésű bejegyzések között böngészhet az érdeklődő. Bizonyos tartalmi elemek azonban csak azt követően érhetőek el, hogy a látogató az adott elemhez tartozó űrlapot kitöltötte. Az űrlap ismétlődhet az egyes KB elemek között, de akár ugyanazt is használhatja a szerkesztő, egy egyszerű legördülő menüből kiválasztva. Ezentúl az egyes bejegyzésekhez egy dátumot is rendelhetünk: ezt megelőzően megjelenik a kiválasztott form, a határidő elteltét követően azonban már szabadon letölthető az addig védett anyag.

Craft CMS vs WordPress

Egy gyors kitérő és néhány ábra annak, aki esetleg megütközött volna a WordPress kukázásán: az alábbi képernyőképeken az látható, hogy az élesítés előtt üzemelő, Avadát használó, "összekattintgatott" oldal mennyi adatforgalmat bonyolított, jóval alacsonyabb funkcionalitás mellett, és ez hogyan változott az élesítést követően, az új, egyedi frontendet használó Craft-tal.

Persze tudom, hogy lehet hatékony frontendet összerakni WordPress-el is (ahogyan Excelben is lehet festeni), de általánosságban sokkal kisebb a hatékony frontenddel rendelkező WordPress oldalak aránya, mint az egyedi fejlesztésű oldalak esetében. Hogy ezt mi okozza, az egy külön bejegyzés témája lehetne - itt és most csak a képeket szerettem volna megosztani, mert látványos a javulás. :)

Plugin fejlesztés

Medium.com Meta Tag Parser for Feed Me

A "céges blogok" a Medium.com-on futnak, a blogbejegyzéseket onnan importáljuk automatikusan a Feed Me nevű plugin segítségével. Az importáláshoz a Medium.com RSS feed-jét használjuk, azonban abban az alapvető adatokon (szerző, cím, bevezető) kívül nem található több információ - a dizájn miatt azonban szükségünk lett volna legalább a bejegyzések kiemelt képére. Egy kezdetleges plugincsírát követően elkészült a Medium.com Meta Tag Parser for Feed Me rövid nevű plugin, mely az RSS feed-ben visszakapott bejegyzéseken végigmegy, meglátogatja az egyes bejegyzések URL-jét, és ott a <head>-ben található meta mezőkkel és azok értékeivel kibővíti az importálható adatok listáját. A plugin ingyenesen elérhető a fenti linken, vagy a composer require webmenedzser/medium-com-meta-tag-parser-for-feed-me parancs kiadásával egyszerűen telepíthető.

Infrastruktúra

Nem szeretem ezt a szólást, de igaz: "egy kép többet mond ezer szónál" - az alábbi képen látható a weboldalt futtató infrastruktúra sematikus ábrája:

Tekintsük át, hogy milyen szolgáltatásokat használunk a weboldalhoz:

• DigitalOcean VPS (8GB, just in case :) )
  • Docker konténerekben a következő szolgáltatások futnak:
    • nginx reverse proxy, ami a forgalom megfelelő irányításáért felel,
    • egy companion image, ami a Let's Encrypt-es tanúsítványok kiállítását hivatott elvégezni,
    • nginx webszerver, ami a reverse proxytól továbbadott kéréseket dolgozza fel
    • php konténer, ez futtatja ténylegesen a Craft-ot,
    • adatbázis szerver + Redis a DB-ből érkező válaszok gyorsítótárazására
• DigitalOcean Spaces
  • Backupok,
  • Feltöltött fájlok (képek, videók, PDF-ek, stb.)
• Amazon SES
  • Levélküldés a weboldalról (tranzakcionális e-mailek, mint pl. a felhasználói fiók létrehozásáról szóló)

Continuous Delivery

A weboldalhoz tartozó frissítéseket a GitLab által biztosított CI/CD rendszer segítségével küldöm ki - persze kézzel is van lehetőség az újabb kód szerverre juttatására, azonban ez sokkal kényelmesebb és kevésbé hibaérzékeny.

A folyamat a következő:

1. Fejlesztés a helyi gépen, a staging branchen.
2. Git commit, melyben beszédesen leírjuk a commit tartalmát.
3. npm version major/minor/patch parancs kiadása, amivel verziószámot léptet a lokális build rendszer, és elkészíti a JS és CSS fájlokból az új kiadást. Ezenkívül generál egy CHANGELOG.md fájlt is, hogy ne nekem kelljen összeszedni fejből, mi az újdonság a kiadásban.
4. A kódot a build rendszer automatikusan push-olja a git repository-ba, ahol elindul egy automatikus deployment a staging szerverre.
5. Tesztelést követően a staging branch beolvasztása a master-be, ami automatikusan beindítja a deploymentet az éles szerverre. A deployment folyamán a következő lépéseket végzi el a rendszer:
   1. SSH a GitLab rendszeréből a szerverre,
   2. változások lehúzása git pull-lal,
   3. a függőségek és változott/frissített csomagok telepítése/eltávolítása a Composer-rel,
   4. a Docker containerek újraépítése,
   5. a Craft migrációk végrehajtása,
   6. a Project Config-ban létrejött változások automatikus átvezetése az éles rendszerre,
   7. Craft gyorsítótárak ürítése
   8. a Craft kötetekben a képek pretranszformálása

Láthatjuk, hogy ez nem kevés feladat, azonban mindezt néhány kattintást követően elvégzi a rendszer.

Összegzés

A fentiekben az oldal néhány, említésre méltó képességét szerettem volna bemutatni - természetesen a funkciólista nem teljeskörű. :)

A Craft CMS nagyon jól vizsgázott, ez volt az eddigi legösszetettebb oldal, amit ezzel a rendszerrel készítettem. A fejlesztés során nem állt az utamban, nem "díváskodott", így arra tudtam koncentrálni, amire kellett: hogy minél hatékonyabban valósítsam meg a megrendelő elképzelését.