Huomio: tämä kirjoitus koskee edellistä yritystäni Sivututkaa, jota luotsasin vuosina 2013-2022.
WordPress verkkosivujen kehitystyötapoja on yhtä monia kuin on tekijöitäkin. Yksi tyyli ei välttämättä ole toista parempi. Tässä kirjoituksessa avaan meidän WordPress kehityksen työtapoja ja tekniikoita.
Varoituksen sana: kirjoitus sisältää väkevää teknistä jargonia. Asiakkaanamme sinun ei koskaan tarvitse kuulla meidän selittävän Sass prosessoinnista tai git versionhallinnasta, vaan nämä asiat tapahtuvat piilossa taustalla.
Tämän kirjoituksen tarkoitus on avoimuuden nimissä avata meidän kehitysprosesseja, työtapoja ja työkalupakkia yhteistyökumppaneille ja rekryttäville WP kehittäjille. Jos hommat kuulostaa omaan kehitysprosessiisi sopivilta, niin pölli ihmeessä.
Miksi työtapojen kehittäminen on tärkeää?
- Webbi ja WordPress kehittyvät niin kovaa tahtia, että paikalleen jämähtäminen tarkoittaisi hitaasti verkkosivupajojen hautuumaalle siirtymistä.
- Työteho ja kehitystyön nopeus paranee, joka tarkoittaa asiakkaalle nopeampia toimituksia ja järkevämpää hintaa. Omatkin katteet paranevat.
- Kehitystyö on mukavampaa, kun hommat luistaa ja tylsät työt automatisoidaan. Kehittäjän mielenterveys kohenee.
Työtapojen kehittäminen tulisikin olla meidän koodipajojen prioriteettien kärkikahinoissa. Kehityksen kuuluu kehittyä.
Kehitysympäristöt ja kehityksen kulku Sivututkalla
Moderniin WP kehitykseen tuntuu olevat jo vakiintunut kolmen eri kehitysympäristön käyttäminen:
- lokaali (dev)
- näyttöpalvelimen kehitysympäristö (staging)
- tuotanto (production).
Meilläkin käytetään tätä hyväksi havaittua kehityspolkua. Käytännössä homma menee näin:
- Kehittäjät työstävät sivustoa lokaalisti omilla laitteillaan
- Työstettävät tiedostot työnnetään kehittäjille jaettuun GitHub repositorioon, josta tavara kopioidaan automaattisesti näyttöpalvelimelle jokaisen pushin jälkeen.
- Kun tulee aika julkaista sivusto, niin se kopioidaan näyttöpalvelimelta tuotantoon.
Jos (kun) tuotannossa olevaan sivustoon tarvitsee tehdä uusia toimintoja tai muuta jatkokehitystä, niin ensisijaisesti tuotannosta tehdään kopio lokaaliin. Lokaalista sivusto taas työnnetään stagingiin ja hyväksynnän jälkeen tuotantoon. Pienempien sivustojen kevyet koodimuutokset voi tehdään suoraan tuotantoon, aluksi vain kirjautuneiden WP käyttäjien nähtäville.
Lokaali kehitysympäristö ja projektin aloittaminen
Lokaaliin kehitykseen meillä käytetään Local by Flywheel -työkalua. MAMPiin tai Vagrantiin verrattuna Local:n WP ympäristö on ihanan helppo ja nopea pystyttää.
Ensimmäisellä asennuskerralla luodaan WordPressistä malliasennus. Tämän jälkeen uuden WP-projektin voi pystyttää samoilla asetuksilla ja sisällöllä parin napin klikkauksella. Helppoa ja hauskaa!
Jaettu tietokanta
WordPress yhteisössä kehityksen ikuisuuskysymyksenä tuntuu olevan tietokannan kanssa säätäminen. Mitä tehdä tietokannan kanssa, kun näyttöpalvelimella ja jokaisella kehittäjällä on omat WordPress asennuksensa?
Monet ovat ratkaisseet ongelman manuaalisilla tietokannan import & export härveleillä. Aika kuormittavaa ja virhealtista touhua, jos useampi kehittäjä jumppailee tietokantoja pitkin työpäivää.
Meillä homma on ratkaistu jaetulla tietokannalla. Staging- eli näyttöympäristön tietokanta on jaettu kaikille projektin kehittäjille. Tällöin muutokset tietokantaan näkyvät kehittäjien lokaaliympäristöissä reaaliajassa. Ja kaikki tämä ilman yhtäkään import & export säätöä.
Tämä tarkoittaa, että kehittäjät voivat vaikkapa lisäillä ACF kenttiä sivuille samaan aikaan, kun suunnittelija hakkaa sisältöjä sisään. Melkoista hunajaa!
Suorat yhteydet tietokantaan ovat tuoteturvasyistä estetty, joten homma vaatii pientä palomuurin säätämistä. Tuotannon tietokanta on luonnollisesti erillään kehitys- ja näyttöympäristöistä.
Automatisointi
Yksi kehittäjän monista murheista on usein toistuvien ja tylsien tehtävien jatkuva suorittaminen. Onneksi nykyään useat tällaiset tehtävät voi webbikehityksessä automatisoida ns. Task runnereille.
Meillä Gulp.js task runneri hoitaa mm. tällaiset asiat automaattisesti:
- Sass prosessointi ja muuntaminen CSS-tiedostoiksi
- CSS-prefixien lisääminen vanhempia selaimia varten
- Tiedostojen yhdistäminen ja minifiointi
- Sivuston uudelleenlataus selaimessa tiedoston tallentamisen jälkeen
Kehitystyön nopeuttamisen lisäksi automatisoinnin tavoitteena on säästää kehittäjän mielenterveyttä. Varsinkin manuaalinen sivuston refreshaaminen jokaisen pikku muutoksen jälkeen käy pidemmän päälle raskaaksi, joka saadaan automatisoinnilla fiksattua.
Sass
CSS tyylien kirjoittaminen ei ole kovin monen webbikehittäjän lempipuuhaa. Sass laajennos tekee hommasta kuitenkin mukavampaa jatkamalla CSS:n toiminnallisuutta kaivattuun suuntaan.
Syntactically Awesome Style Sheets:lla hoituvat mm:
- Muuttujien käyttäminen
- Tyylien ”nesting”, eli selektorit voidaan laittaa sisäkkäin, jolloin ei tarvitse kirjoittaa jokaista child-selektoria erikseen
- Tyylitiedostojen jakaminen loogisiin osiin 5000-rivisten CSS-tiedostojen sijaan
- Laskutoimitukset ja muu perus ohjelmointilogiikka
Sass on siis CSS supervoimilla boostattuna. Sass tuntuu olevan ainakin WP kehityksessä melko standardisoitunut härveli ja sitä kautta myös meillä kovalla käytöllä.
Aloitusteema
Meillä ei koskaan tunkata täyteen ”ominaisuuksia” ahdettuja ja jäykkiä valmisteemoja. Jokaiseen WP projektiin käytetään itse kehittämäämme aloitusteemaa, joka toimii lähtöpisteenä sivuston toteutukselle.
Aloitusteemamme pohjautuu suosittuun Underscores startteriin, joka on WordPressinkin taustalla vaikuttavan Automattic-firman kehittämä pohjateema. Underscoresia on muokattu meille sopivaksi ja turboahdettu automatisoinnilla.
Sivututkan aloitusteemassa ei ole mitään ylimääräistä, vaan sen tarkoituksena on toimia parhaana mahdollisena ja minimalistisena lähtöpisteenä erilaisille WP sivustoille. Tällä tavalla koodi on clutter-vapaata ja perusjutut paikallaan.
Kun lähtöpisteessä on työkalut ja WP säädöt valmiiksi paikallaan, niin startteri säästää ainakin 100 tuntia kehitystyötä projektilta nollista lähtemiseen verrattuna.
Aloitusteema on tietysti jatkuvan kehityksen kohteena. Toimintoja viilaillaan ja uusia tekniikoita otetaan käyttöön vanhojen poistuessa. Sivututka Starter 1.0 on tarkoitus laittaa avoimen lähdekoodin periaatteella julkiseksi WordPress yhteisön ihmeteltäväksi ja käytettäväksi tässä tämän vuoden aikana.
Versionhallinta, Git ja GitHub
Käytämme versionhallintaan Gitiä ja repositoriot säilötään GitHubiin. Asiakasprojektit julkaistaan private repositorioon, jonne on pääsy vain Sivututkan tiimillä.
Hyvien käytäntöjen mukaisesti committeja tehdään tiheään ja ne pushataan pienienkin toiminnallisuuksien valmistuttua. Jos projektia työstää useampi kehittäjä, niin jokaisella jantterilla on oma branchinsä.
Uusien toiminnallisuuksien valmistuttua kehittäjät puskevat koodin GitHubin remote repositorioon. Sieltä tiedostot taas työnnetään automaattisesti näyttöpalvelimelle stagingiin, continuous deployment -periaatteen mukaisesti.
Työkalut ja lisäosat
Kehittäjä saa meillä valita itse editorinsa. Itse suosin VS Codea, joka on myös tämän hetken suosituin kapistus. Indenttinä käytetään tabia.
WordPress kehityksessä pyritään lähtökohtaisesti välttämään ylimääräisten lisäosien käyttöä. Yksinkertaiset toiminnallisuudet rakennetaan itse. Moniin tehtäviin löytyy kuitenkin hyväksi todettuja valmiita ratkaisuja, joilla vältetään pyörän uudelleen keksimisen vaiva:
- Polylang: jos kieliä
- WooCommerce: jos verkkokauppa
- Advanced Custom Fields Pro: sisältökenttiin ja modulaarisuuteen, käytössä lähes jokaisessa projektissa
- Yoast SEO: useimmille sivustoille SEO hallintaan
- Gravity Forms: jos lomakkeita
- Mailgun: lomakkeiden viestien välittämiseen
- WP Fastest Cache: välimuistitukseen
Tapauskohtaisesti voidaan harkita myös muita lisäosia, kunhan ne ovat hyvin arvosteltuja, suosittuja ja luotettavan tahon ylläpitämiä.