WordPress on ehkä yleisin sisällöntuotto- ja sivustonhallintaohjelmisto eli CMS nykyään. Mutta se ei todellakaan ole ainoa. Sen suosio perustuu asennuksen ja käytön helppouteen, joka muuttuu vaikeammaksi vasta matkan myötä. WordPressin ongelma on sen jatkuva paisuminen ja raskas tietokantariippuvuus. Dynaamisuus näkyy hitautena. Kun ei ole ehdotonta tarvetta dynaamisuuteen – aidosti aika harvalla on – niin kannattaa ihmetellä muuta tarjontaa. Yksi vaihtoehto on Jekyll.

Kun WordPress on PHP-pohjainen ja koko sisältö on tietokannassa, niin Jekyll on tehty rubylla ja sivut ovat staattisia ilman tietokantaa. Toisin sanoen sivut luodaan tekovaiheessa valmiiksi asti ja siirretään sitten näkyville. Kun tehdään muutoksia, niin sama toistetaan. Se vaatii hieman enemmän käsitöitä, mutta lopputulos on usein layausajoiltaan nopeampi käyttäjille kuin WordPress koskaan – tietysti edellytyksellä, että ei latailla megaluokan kuvia tai tehdä muita hassuuksia.

Jekyllin suosiota rajoittaa fakta, että se ei ole helppo. Sitä käytetään enemmänkin yhteyksissä, joissa tehdään muutakin sellaista, jota voidaan kutsua kehitystyöksi. Jekylillä on jyrkempi ja korkeampi oppimiskäytä kuin muilla CMS-ympäristöillä, kuten WordPressillä tai Drupalilla. Käyrää nostaa myös se, että Jekyll vaatii perustaitoja enemmän ymmärrystä HTML:stä ja CSS:stä. Se ei ole missään nimessä aloittelijan blogiympäristö, vaikka sitä sellaisena aika ajoin mainostetaankin.

Lisäksi Jekyll vaatii käytännössä shellin, komentorivin. Toki asia voidaan ratkaista muillakin tavoilla, kuten vaikka Githubin kautta, tai koplaamalla WordPress Jekyllin kylkeen, mutta jokaisella säädöllä vaikeusaste kasvaa. Silti kannattaa pitää mielessä Jekyllin historia: se tehtiin nimenomaan kehittäjille sekä koodareille ja ajatuksella, että sisältö tehdään nimenomaan Githubissa.

Tavallisemmalle loppukäyttäjälle ajatus on vieras. Mutta se on itseasiassa vapaasti saataville sisältösivustoille harkitsemisen arvoinen ratkaisu – mutta lisää entisestään oppimiskäyrän jyrkkyyttä, koska täytyy opetella Jekyllin lisäksi miten versiointiin kehitetty git toimii sekä yksi niitä julkisesti tarjoava ympäristö Github käyttäytyy.

Mutta jos sinulla on perustietoja tai valmiutta opetella, ja jos sinulla on tarve saada nopea sivusto ilman WYSIWYG muokkausta, niin Jekyll on harkitsemisen arvoinen.

WordPress vs. Jekyll

Vertailu WordPressin ja Jekyllin kohdalla on aika hedelmätöntä. Ne ovat niin erilaisiin tarpeisiin tehtyjä, vaikka lopputulos on idealtaan samanlainen. Mutta vain siltä osin, että tarjoillaan kävijälle websivusto luettavaksi.

WordPress on helppo. Tai ainakin kohtuullisen helppo. Suurin osa saa sen asennettua ja nykyinen suuntaus on, että ei edes tarvitse asentaa – webhotellit myyvät niitä valmiina. Perusteiden omaksumiseen menee menee nettiummikolta ehkä tunti ja toimivan pohjan, jossa on edes suunnilleen haluttu ulkonäkö ja toiminnallisuuksia iso liuta, on pystyssä muutamasta päivästä viikkoon.

Vertailuksi – olen tapellut Jekyllin kanssa nyt kolmatta päivää, että saisin toimivan kirjoittaja-arkiston näkyviin.

Julkaisujen kirjoittaminen on käytännössä samaa kuin kirjoittaisi jutun missä tahansa tekstinkäsittelyssä – joten jos Word on tuttu, niin WordPressissä julkaisu ei vaadi sen kummallisempaa kuin juttuidean ja kirjoitustaidon.

Tosin WordPress on kovaa vauhtia rikkomassa helppouden konseptia panostaessaan vahvasti blokkieditoriinsa. Sen omaksuminen sitten viekin enemmän aikaa.

Jekyll on aivan päinvastainen. Asennus vie omaa aktiivista aikaa vähemmän kuin WordPress – tosin taustatöihin viittavaa komentokehoitetta sai tuijotella kahvipaussin verran, mutta se saattoi toki johtua testipenkkinä olleen Raspberryn raudan vajavaisuuksistakin. Mutta ennen kuin pääsee niin pitkälle, että voi edes asentaa Jekyllin, on joutunut uhraamaan aika paljon aikaa ja vaivaa virtuaaliserverin tai jonkun muun (linux)boksin asentamiseen ja opetteluun.

Kun joku päättää, ilman tavallista arjen tietoteknistä osaamista kummallisemmilla kyvyillä, pistää pystyy WordPressin, niin hän saa tunnissa Hello World tyyppisen pohjan ja päivästä muutamaan toimivan version. Samalla osaamistaustalla ei saada koskaan Jekylliä pystyyn. Mutta tässä on se perustavanlaatuinen ero: WordPress on nimenomaan tehty aloittelijoille kaupalliseen ympäristöön, ja Jekyll on tehty ilmaiseen kulttuuriin koodausta osaavien käyttöön.

Kun on päästy yli teknishumanistisista vaatimuksista, niin lopputulos eroaa ns. taustatoimintojen suhteen hyvinkin radikaalisti. Kyse on aika pitkälle dynaamisesta ratkaisusta vastaan staattinen ympäristö, ja mitä se tuo mukanaan. WordPress sallii paljon erilaisia asioita, koska se käyttää PHP:n työkaluja yhdessä tietakannasta parsittujen osien kanssa. Jekyll on riippuvainen rubyn gemeistä (jotka on ideologialtaan kuin PHP:n ohjelmat) ja siitä mitä on käsipelillä mahdollistettu Jekyllille lopputuloksen parsimiseen.

WordPress käyttää moneen javascriptiä. Toki Jekyll-ympäristöönkin voi javascriptiä ympätä, mutta ei helposti – ihan siksi, että Jekyll pyrkii tekemään puhtaan HTML-sivuston. WordPress taasen muokkaa ja rakentaa jokaisen sivun aina erikseen kävijän pyyntöjjen mukaan. Sellainen pikkujuttu kuin kävijäseurannan asettaminen tai mainosten esittäminen on WordPressissä noin minuutin rutiinijuttu. Mediaa pyörittävät bannerit ovat vakioina lähes jokaisessa teemassa ja jos ei ole, niin lisäosan asentamiseen menee sekunteja. Jekyllissä Google Analyticsiä varten tarvitaan erillinen gem, enkä vielä kolmen päivän jälkeen ole oivaltanut miten tuon asioita <head>-tagin alle.

Hieman sivuasiaa, mutta välimuistien käyttäytyminen kertoo ympäristöjen eroista aika paljonkin, ja taas ollaan tilanteessa dynaaminen vastaan staattinen.

WordPressin sivutason välimuistit, kuten WP Rocket, pyrkivät mahdollisuuksin mukaan eroon dynaamisesta ympäristöstä tekemällä staattisia sivuja – eli samaa kuin mitä Jekyll tekee luontaisesti. Mutta heti kun kuvaan tulee mukaan ehdottomasti pakollinen dynaaminen osa, kuten vaikka verkkokaupan kassasivu, niin aivan jokainen cache on hampaaton – muuttuvaa sisältöä ei vaan voida viedä välimuistiin (kyllä, mikro-caching on poikkeus, mutta aniharva saa siitä mitään etua).

Jekyllin sisältö sen sijaan paukahtaa välittömästi välimuistiin. Itseasiassa ollaan tilanteessa, että välimuisti saattaa jopa muuttua einen tarpeettomaksi – mutta vain einen, koska serveritason välimuistit, kuten Varnish, on aina nopeampi tarjoilemaan sivusisällön kuin webserveri. Kysymys on lähinnä siitä, että Jekyllin kohdalla Varnish ei pysty tasoittamaan sitä hitautta, joka tulee dynaamisen sivun PHP-toiminnoista ja tietokantatoiminnoista – koska niitä ei ole.

Oleellisin ero WordPressin ja Jekyllin välillä voidaan kiteyttää muutamaan kohtaan:

• jos tarvitsee aitoa dynaamisuutta (verkkokaupat, kohdennettu sisältö jne), niin WordPress on ainoa järkevä vaihtoehto
• jos sisältö on todellisuudessa staattista, niin Jekyll saattaa olla toimivampi
• jos haluat tehdä sisältöä, et tekniikkaa, niin valitset WordPressin
• jos haluat tehdä tekniikkaa tekniikan takia, niin ehdottomasti otat käyttöön Jekyllin

Jekyllin perusvaikeus oppimiseen

WordPressin takana on (nykyään) puhdas liiketoiminta Automatticin kautta. Samaten lisäosien ja teemojen puolella on huomattavan paljon myyntiä. Suosio ja asennusten määrät generoivat suoraan myös liiketoimintaa.

Jos unohdetaan idealistiset suhtautumiset, niin liiketoimintatausta tarkoittaa kahta huomattavan tärkeää asiaa:

• kehitykselle on jatkuvuutta
• dokumentointia ja julkaisuja on pilvin pimein

Jatkuvuus on tärkeää. Onko sellainen serverin valvontatyökalu Munin tuttu? Se oli kymmenkunta vuotta sitten scenessä pieni hype ja pöhinä. Se oli puhtaasti ilmainen viritys, eikä sen ympärille rakentunut liiketoimintaa – eräällä tavalla avoimen ympäristön toiveuni. Ilmaisuus toi mukanaan sen, että kehitys oli täysin vapaaehtoisten käsissä. Kun vapaaehtoiset kyllästyivät, niin kehitys loppui siihen.

Nyt Munin on auttamattoman rikki ja vajaa – käyttö edellyttää, että osaa koodata, joka tuo mukanaan sen, että yksikään edes einen ammattimainen ympäristö ei panosta moiseen sekentiäkään työaikaa, koska parempia, nopeampia ja helpompia vaihtoehtoja on saatavilla. Silloin koko homma rakentuu sille, että joku jossain joskus viitsii julkaista jonkun scriptin pätkän Githubiin – joka vanhentuu hetken kuluttua, koska tekijän mielenkiinto on suuntautunut toisaalle.

Netdata tekee periaatteessa aivan samaa. Paremmin ja mukavammin – mutta sen takana on liiketoimintamalli, joka sallii myös ilmaisversion.

En väitä, että Jekyll on menossa samaa tietä. Sille on olemassa määrätty vakiintunut käyttäjäkunta – mutta hekin vanhenevat ja kysymys kuuluu, että onko Github Pages käyttäjiä vielä muutamankin vuoden päästä riittävästi ja onko heillä viitsimistä ja ideologiaa ylläpitää ilmaista järjestelmää. Tätä kirjoitettaessa Jekylillä on bugin tapainen ongelma Bundlen kanssa – tosin käytännössä merkityksetön – jonka korjaamisesta on kyselty paljon. Silti kukaan aktiiveista ei ole sitä korjannut asennuspakettiin.

Jekylliin löytyy melkoisestikin dokumentteja – mutta suurimman osan laatu on sirpaleista. Sirpaleisuus pätee Jekylliin omaankin dokumentointiin. Ymmärrän syyn siihen, koska moisten luominen on työlästä. Plus tekijät ovat osaavia, jotka kirjoittavat toisille osaajille kuvitellen, että tekevät aloittelijatason materiaalia. En todellakaan pysty heittämään ensimmäistä kiveä aiheessa varsinaisen leipätyöni takia, joka on kouluttamista ja opastamiseen liittyvän sisällön tuottamista, mutta sen sijaan (tai siitä syystä) tunnistan kuitenkin ongelman.

Perussyy on taas kerran kaupallisuuden puute. Jos joku tekisi rahaa, niin hänellä olisi suurempi motivaatio saada käyttäjiä, jotka pysyvät käyttäjinä. Idealistisessa open source, free skies ympäristössä motivaatio on heikompi. Aivan samaa kuin minulla. En minä näitä aidosti teille kirjoita, vaan omaan tarpeeseen ja se näkyy sisällön valikoitumisessa.

Faktanomainen totuus on, että Jekyllin maailmalla oleva dokumentointi ei ole aina selvintä mahdollista, eikä edes helppoa. Ja tuo on universaali totuus, joka pätee kaikessa vain ilmaisuuteen perustuvassa tarjossa.

Jutun ympäristö

Minä asennan Jekyllin Raspberry Pi:hin, jota käytän eräänlaisena kehitys- ja testipenkkinä. Se kuitenkin asentuu kaikkiin linux-ympäristöihin samalla tavalla. Asentuu se Windows- ja Mac-koneisinkin, mutta niiden suhteen joudut googlettamaan lisää.

Distrona on Ubuntu 20.04 serveriasennuksena ilman graafisia lisäkilkkeitä, mutta jakeluhan vaikuttaa vain joihinkin paikallisiin komentoihin malliin apt install – osannet muokata ne tarpeidesi mukaan. Jos oikein olen ymmärtänyt, niin ruby itsessään toimii tismalleen samoin kaikissa ympäristöissä.

Asennettava Jekyllin versio on 4.1.1, joten jos myöhäisemmät versiot muuttavat jotain oleellista, niin sellaista se on.

Ruby

Minä ymmärrän rubysta vähemmän kuin PHP:stä, enkä tiedä siitäkään paljoa. Mutta ruby (rubiini) käyttää gem-nimisiä juttuja (jalokivi) ja ne lienevät suunnilleen samankaltaisia kuin PHP:n komennot – eli pieniä ohjelmakoodeja. Niitä joudutaan hieman säätämään ja vääntämään, mutta itse joudun silloin turvautumaan puhtaasti kopypeistaus-mentaliteettiin.

Joten jos siltä osin jokin neuvoni ajaa sinut turmioon, niin minä en kanna siitä moraalista enkä juridista vastuuta – koska minäkään en osaa. Mutta suunnilleen kaikki kerrottu on asioita, jotka olen itse tehnyt.

Jekyllin asennus

Asennetaan ensin vaadittavat lisäasiat:

sudo apt install ruby-full build-essential zlib1g-dev

Siirry sitten sille käyttäjätunnukselle, jolla aiot sivustoa rakentaa ja anna nämä neljä komentoa. Ne asettavat tiedostoon ~/.bashrc rubyn vaatimat polut:

echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc
echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc
. ~/.bashrc

Sitten asennetaan Jekyll:

gem install jekyll bundler

Tuossa hukkaantuu aika kauan aikaa. Hitaus saattoi hyvinkin johtua Raspberrystä, mutta ehdin käydä tupakalla ja vastata pariin Facebookin juttuun, ennen kuin tuo oli valmis.

Nyt Jekyll on periaatteessa valmiina käyttöön

Palomuuri

Jekyll on kehitysympäristö, jossa tehdään staattisia sivuja. Se ei siis ole se ympäristö, jossa sisältö esitetään, kuten WordPress tai vaikka Drupal. Siksi Jekyll esimerkiksi asettaa sivuston työhakemistot kotihakemistoon (tai mihin ne sitten haluatkin, muista antaa polku sivustoa luodessasi), ei webserverin käyttämään.

Sivuston tekeminen on kuitenkin perin vaikeaa, jos aina muutosten jälkeen pitäisi siirtää generoitu sivusto webserville, että näkisi mitä on tullut tehtyä. Sitä varten Jekyllissä on oma sisäänrakennettu kevytversion webserveri. Ja kuten aina, niin serveri tarvitsee portin itselleen. Oletuksena Jekyllin ympäristö käyttää porttia 4000, joten avataan se. Itse käytän UFW:tä mutta jos olet iptables-ihmisiä, niin osannet tehdä saman itsekin:

ufw allow 4000

Minulla Raspberry Pi pyörii sisäverkon suojissa, joten minun ei tarvitse sen enempää rajoittaa harhailijoiden pääsyä. Jos teet töitä esimerkiksi virtuaaliserverilllä (DigitalOcean on hyvä vaihtoehto), niin silloin ehkä halutaan varmistaa, että koko maailma ei näe keskeneräistä työtä. Tosin on muistettava, että Jekyllin ikioma webserveri ei ole päällä koko ajan, vaan ainoastaan erikseen pyydettynä – joten ehkä se ei ole niin suuri asia? Tietysti jos työtapasi on, että vaikka screen pitää hereillä Jekyllin ”esikatseluserveriä” ja toisessa istunnossa teet töitä, niin pientä hidastetöyssyä ehkä kaivataan.

Itse rajoittaisin pääsyn porttiin 4000 IP-osoitteen mukaan. Ja koska oma koti-IP on mallia vaihtuva, niin ainoa toimiva ratkaisu on ottaa (oma) VPN käyttöön.

En ole tätä tehnyt, kiitos sisäverkon, mutta pitäisi toimia:

sudo iptables -I INPUT -p tcp -s 0.0.0.0/0 --dport 4000 -j DROP
sudo iptables -I INPUT -p tcp -s 11.22.33.44 --dport 4000 -j ACCEPT

• Ensimmäinen sääntö päästää halutun IP-osoitteen ja toinen sääntö tipauttaa muut. Ja nuo on annettava juurikin tuossa järjestyksessä, koska listan ensimmäinen pätee. Jos annat toisinpäin, niin ensimmäiseksi voimaan tulee kaikkien estäminen, myös halutun IP:n.

Ensikokeilu

Jekyllin käyttö vaatii enemmän työtä ja sille on omat juttunsa. Mutta on silti hyvä kokeilla, että asennus toimii. Joten tehdään ensimmäinen testisivusto ja katsotaan miltä se näyttää.

Tehdään testisivusto:

jekyll new stage/testi

• polun voi antaa absoluuttisena tai sitten suhteellisena, jolloin se rakennetaan siihen hakemistoon, jossa olet. Koska annoin komennon omassa kotihakemistossani, niin Jekyll teki hakemiston stage ja sen alle sivuston kehitysversion testi.

Vielä ei ole mitään katsottavaa, koska Jekyll asensi kehitys- ja rakennusympäristön, mutta kun annat seuraavan komennon, niin Jekyll rakentaa demosisällöstä sivuston hakemistoon _site. Samalla käynnistetään Jekyllin oma webserveri, johon pääset antamallasi IP-osoitteella porttiin 4000. Koska minä asensin Jekyllin sisäverkossa asustavaan Raspberryyn, niin joudun antamaan sen IP-osoitteen tai host nimen, mutta localhost toimii myös, jos olet paikallisesti liikkeellä.

Siirry ensin kehitysversion hakemistoon, minulla se olisi:

cd ~/stage/testi

Generoidaan sivusto ja käynnistetään webserveri:

jekyll serve --host=192.168.100.49

Avaa selaimeen antamasi url porttiin 4000. Minulla se olisi http://192.168.100.49:4000. Kun olet valmis uuden sivuston ihmettelemisessä, niin serveri pysähtyy näppäinyhdistelmällä ctrl+c.

Nyt sinulla on sinällään toimiva Jekyll asennettuna valmiina rakentamaan uuden sivuston. Se vaatiikin hieman enemmän ohjeiden lukemista. OIkeastaan aika paljon, koska aivan kaikki joudutaan rakentamaan käsin.

Sivuston siirtäminen

Jekyll parsii, tai generoi, kehityssivustosi käytettävään muotoon komennolla jekyll serve. Se ilmestyy hakemistoon _site. Kannattaa muistaa, että mikään mitä olet tehnyt _site hakemistoon käsin, ei siirry takaisinpäin kehitysversioon ja ylikirjoitetaan kun seuraavan kerran generoit sivustosi.

Sivusto on sellaisenaan käyttökelpoinen, mutta koska _site ei ole webhakemisto, niin siihen ei pääse julkisesti käsiksi. Sivusto täytyy siirtää sellaiseen hakemistoon, jota webserveri osaa käyttää. Erilaisia tapoja on useita, mutta ehdottomasti fiksuin (tai ainakin yleisin) on rsync.

Jos siirrät saman virtuaaliserverin sisällä:

rsync -ar ~/stage/sivusto/testi/_site/ /var/www/sivusto/public_html/

Jos siirrät verkon yli muualle:

rsync -avz --progress2 -e ssh ~/stage/sivusto/_site/ root@kohde-ip:/var/www/sivusto/public_html/

Mitä seuraavaksi?

Seuraavaksi alkaa melkoinen opintie. Vaikka sinulla olisi taustaa websivustojen tekemisessä, niin suurella todennäköisyydellä joudut opettelemaan täysin uudia asioita ja täysin uuden toimintatavan. Oleva tausta auttaa ymmärtämään miksi asioita tehdään niinkuin tehdään ja mitä tarvitaan.

Mutta jos olet täysin ummikko HTML-tagien ja CSS-säätöjen kanssa, niin… jätä väliin, ellet ehdottomasti halua oppia uutta. Mutta jos tavoite on tehdä kulutettavaa sisältöä, niin palaa takaisin WordPressiin ja yritä selvittää itsellesi miten siellä sisältö tehdään mahdollisimman helposti välimuistitettavaksi.

Selaa täällä Jekyll-kategorian sisältöä. Sillä pääset alkuun. Sen jälkeen Googlen hakutulokset alkavat valtaamaan selaimen välilehtiä, koska taatusti tarvitset lisää neuvoja, vinkkejä ja selityksiä.

Ensimmäinen paikka aloittaa syvempi penkominen on Jekyllin oma sivusto.

Jos sinulla on koodaustausta, niin haluat ehkä lähteä liikkeelle nollapisteestä, Me muut googlettelemme Jekyllin teemoja ja asennamme yhden – koska sinällään valmiissa ympäristössä on helpompi lähteä säätämään.

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.

Profiili: Jakke Lehtonen