Vältä WordPress-sivuston posahtaminen näillä devaajan teeseillä
Jokaisen fronttikehittäjän sisällä asustaa taiteilija tai vähintään intohimoinen insinööri. Välillä tekisi mieli kaivertaa syvemmällä uralla omaa kädenjälkeä sivustokoodiin, mutta liian luova WordPressin ja sen lisäosien taivuttaminen voi johtaa varsinaiseen ylläpitopainajaiseen.
Osaava kehittäjä säästää omaa tulevaa työtään toteuttamalla asioita dokumentaation mukaisesti ja lisäosia hyödyntäen, jolloin käsintehtyjen koodiviritelmien määrä jää minimaaliseksi. Tässä blogitekstissä käyn läpi fiksun tekemisen esimerkkejä WordPressin, sen lisäosan Advanced Custom Fieldsin sekä sisältöeditori Gutenbergin osalta.
Sisällön tallennus suoraan kantaan vai renderöiminen dynaamisesti attribuuttien avulla?
Omaa työtä pidemmällä aikavälillä säästäviä valintoja tehdään jo sivustokehittämisen perustasolla. WordPressin modulaarisen sivustorakenteen sisältö tallennetaan lohkokohtaisesti, mutta tulisiko HTML-koodi tallentaa suoraan kantaan vai generoida dynaamisesti sivun näyttämisen yhteydessä?
Kun lohko tallennetaan suoraan tietokantaan, kaikki HTML-merkkaus on luettavissa sieltä myös suoraan. PHP:n ei tarvitse renderöidä lohkoa erikseen, mikä säästää joitakin millisekunteja. Toisaalta tietokantaan joudutaan tallentamaan enemmän dataa, joten nopeuden osalta vastaus ei ole yksiselitteinen.
Kääntöpuolena on koodin ylläpidettävyys, eli jo tietokantaan tallennettu HTML ei päivity tekemisen mukana vaan ainoastaan uusien lisättävien elementtien osalta tai vanhoja erikseen muokatessa.
Tässä kuvioon tulevat attribuutit, joiden avulla voimme kuvata asioita ottamatta yksityiskohtaisemmin kantaa siihen, että miten lohko käyttäytyy. Attribuuttien avulla muutosten päivittäminen on helppoa, niin sivuston rakennusvaiheessa kuin jatkokehityksessä. PHP-frontin avulla muotoiltuja lohkoja voidaan hyödyntää myös sivuilla, joita ei ylläpidetä sisältöeditorin kautta, esimerkiksi arkistosisällöissä.
Turha kikkailu on turhaa lohkojen hyödyntämisessä
Sivuston peruselementtien, kuten otsikon, palstan tai painikkeen, merkkauksen osalta käytämme WordPressin core-lohkoja. Tarvittaessa räätälöimme niiden ulkoasua CSS:llä.
Toteutuksen yhdenmukaistamisessa kannattaa käyttää peruslohkojen osalta hyväksi havaittuja pohjia, joiden päälle sivustoa rakennetaan. Meillä MEOMilla lohkojen luurangot luodaan MEOM Blocksilla. Uutta WordPress-sivustoa luodessa rakennamme editorinäkymän JavaScript Reactilla ja frontti renderöidään PHP:llä. Lohkot pyritään pitämään yksinkertaisina, asetusten määrä tarkoituksenmukaisen rajallisina ja mahdolliset muutokset toteutetaan CSS-luokkien kautta. Tämä ansiosta itse HTML pysyy siistinä, kun emme puljaa monimutkaisten ehtolauseiden kanssa.
Emme kuluta Reactilla tehtäviin lohkoihin ylettömästi aikaa kikkailemalla turhaan, vaan perusta on tehokkaassa aiemman työn hyödyntämisessä ja parhaissa käytännöissä.
Tietokenttien meren liplatus ei ole kaikkien mieleen
Advanced Custom Fields -lisäosa tarjoaa vaihtoehdon lohkojen luomiseen. Sen avulla määritetään, mitä tietokenttiä WordPress-lohko sisältää. Ulkoasu kirjoitetaan PHP/HTML:llä. WP:n sisältöeditorissa sisällön ylläpitäjällä on tämän tuloksena joukko kenttiä, joita voi täyttää.
Käytämme ACF:iä etupäässä silloin, jos meidän on renderöitävä sivustolle automaattisesti päivittyvää sisältöä, kuten vaikkapa ajankohtaisten sisältöjen syötettä. Monimutkaisempana esimerkkinä voisi olla jokin “asetushirviö”, jossa on paljon pieniä tietokenttiä ja jonka tekemiseen natiivilohkoilla menisi iäisyys – ja etenkin jos tätä lohkohärveliä käytetään vain yhdessä kohtaa sivustoa ja se ei vaadi jatkuvaa sisällön päivittämistä.
Meillä uudelleenkäytettäväksi ACF-lohkoksi on vakiintunut artikkelinosto-lohko, johon liittyvät renderöinti PHP:llä sekä JSON-muotoinen kuvaus lohkon kentistä. MEOM Blocksin puitteissa olemme parantaneet tämän monistettavan lohkon käyttökelpoisuutta.
Perinteisesti JSON-muotoisen kenttätiedon siirtäminen paikasta toiseen on ollut vaivalloista, mutta MEOM Blocksin avulla voimme komentorivin kautta luoda pohjasta itsellemme uuden ACF-lohkon, joka kopioi automaattisesti myös kenttien tiedot ja säästymme paljolta käsipelillä tehtävältä klikkailulta.
Kaikki ei ole kuitenkaan auvoa ACF:lläkään. Monimutkaisemmat lohkot tietokenttä-rykelmineen ovat aika insinöörimäinen tapa toteuttaa sivuston sisällön ylläpitoa ja monet asiakkaat ovat kokeneet nämä himmelit hankaliksi käyttää. Tässä apuun saapuu InnerBlocks, jonka avulla lohkon sisään voidaan lisätä lohkoja. Voimme siis pilkkoa ison kokonaisuuden pienemmiksi palasiksi, joita voidaan hyödyntää myös muualla sivustolla.
Mielipiteitä jakava lohkoeditori WP-käytettävyyden kärkenä
Siinä missä ACF tarjoaa kehittäjille mielekkään tavan rakentaa tietokenttiä ja esittää sisältöä verkkosivulla, auttaa Gutenberg sivuston sisällön ylläpitäjiä tekemään asioita helpommin ja intuitiivisemmin.
Gutenberg ei edelleenkään ole täydellinen apuväline, mutta se on kehittynyt paljon julkaisunsa jälkeen. Monille asiakkaillemme uudistunut sisältöeditori on ollut mahtava juttu ja moni hankalan epälooginen sisällönsyötön vaihe on nyt historiaa.
Emme ole lähteneet ylikirjoittamaan Gutenbergin perustoimintaa tai paikkaamaan sen toiminnassa olevia puutteita, mutta olemme muokanneet loppukäyttäjän editoriin tarjottavia oletusasetuksia.
Tällä hetkellä meillä on kehitteillä “lisäosan lisäosa”, jolla saisi pois päältä automaattisesti turhat Gutenbergin lisäominaisuudet, kuten vaikkapa painikkeiden kulmien pyöristykset. Ajatuksena on siis se, että mitä vähemmän nippeleitä editorissa on näkyvillä, sitä helpompi sitä on oppia käyttämään.
Kaikkia turhia ominaisuuksia ei pysty poistamaan dokumentaation puitteissa, vaan joudutaan turvautumaan Googlen syövereistä löytyviin ratkaisuihin. Lisäosan avulla muutokset kyettäisiin ajamaan kaikkien asiakkaiden verkkosivustoille kerralla, jos esimerkiksi jokin kikka ei ole enää tulevaisuudessa tuettu.
Natiiveihin Gutenberg-lohkoihin on mahdollista lisätä ominaisuuksia, kuten vaihtoehtoisia tyylejä painikkeille ja listoille. Niitä voidaan käyttää rinnan Gutenbergin oletustyylien kanssa, tai niiden korvaajana.
Syleilemme Gutenbergiä jalat maassa
Käytettävyyden toteuttamisessa painotamme devaajien omaa harkintaa. Mikään lisäosa itsessään ei vapauta tästä tai pakota tähän. Hyödynnämme edelleen ACF:ää siellä, missä se on tarpeen.
Käytettävyyden miettiminen sisällön ylläpitäjän vinkkelistä voi olla front end -kehittäjälle , hankalaa. Oma insinöörimäinen ajattelutapa voi ohjata eri linjoille käyttäjien tarpeiden kanssa. Käyttäjäpalaute sekä designerin tuki ovat tässä tärkeitä. Kehittäjälle oleellista on tuntea perusteet ja ettei lähde liikaa soveltamaan, jotta vältetään sivuston räjähtäminen seuraavassa päivityksessä.
Kokonaisuuden kannalta on hyvä pysyä kärryillä Gutenbergin muutoksista. Tässä auttaa pitkälle dokumentaation mukainen tekeminen, eli sitä mukaa kun editori muuttuu, pysymme lähellä kotipesää ja kykenemme notkeammin reagoimaan päivityksiin.
Vastaavasti esimerkiksi ACF auttaa toteuttamaan räätälöityjä asioita dokumentaation mukaisesti, ilman tarvetta custom-koodaukseen. Jos kehittäjällä on paloa omiin kooditoteutuksiin, voi omaa luovuuttaan suunnata avoimen lähdekoodin pohjalta toimivan WordPressin yhteisölle. Parhaassa tapauksessa se oma idea päätyy WP:n seuraavaan versioon kaikkien hyödyksi.