WordPress on itsessään varsin vaatimaton ja yksinkertainen julkaisualusta. Oletuksena WordPressin mukana tulee karvalakkimallin käyttäjähallinta, mediakirjasto sekä kaksi sisältötyyppiä. WordPress on kuitenkin vuosi vuodelta kasvattanut suosiotaan myös laajojen ja monipuolisten sivustojen julkaisualustana. Tämä on ollut mahdollista, koska järjestelmä on helppo laajentaa lisäosilla ja muokata suuntaan jos toiseenkin.

Lisäosien kirjo on huomattava: niillä voi tehdä kaikkea sivuston välimuistituksesta aina monimutkaisempaan käyttäjähallintaan asti. Tätä kirjoittaessa pelkästään wordpress.orgista löytyy yli 50 000 ilmaista lisäosaa ja näiden lisäksi on myynnissä tuhansia maksullisia lisäosia eri internetin kauppapaikoissa. Tätä lisäosien paljoutta ja monipuolisuutta on yleensä pidetty WordPressin vahvuutena.

WordPress-toteutus ilman lisäosia on vähän kuin ostaisit 1970-luvun Ladan. Se saattaa olla ihan kiva, mutta ei ehkä kuitenkaan huvittaisi lähteä pitkälle lomareissulle ilman modernin auton mukavuuksia kuten ohjaustehostinta tai lohkolämmitintä. Toisaalta lohkolämmittimen rakentaminen itse ihan nollasta kuulostaa sekin vähän hullun hommalta. Lisäosien suhteen tilanne on samanlainen: moderni WordPress-sivusto tarvitsee lisäosia ja kaikkia lisäosia ei suinkaan kannata itse rakentaa nollasta. Mutta mitä se käytännössä tarkoittaa, että sivustolla käytetään 3. osapuolen lisäosia?

Edut

Parhaimmissa tapauksissa lisäosilla saadaan aikaan kustannustehokkuutta ja nopeutta verkkosivustoprojekteihin. Esimerkiksi kieliversioiden toteutus on yhtä helppoa kuin Polylang tai WMPL -lisäosan asennus ja käyttöönotto. Käden käänteessä sivustolla voi olla etusivu sekä suomeksi, ruotsiksi että englanniksi. Helppous johtuu siitä, että joku tai jotkut jossain on miettinyt ja toteuttanut valmiiksi pureskellun ratkaisun tarpeeseen, jonka itse olet juuri kohdannut. Lisäksi tässä on etuna se, että valmiiksi pureskeltu ratkaisu on monipuolisemmin ja laajemmin testattu kuin oma ratkaisu. Näin ollen lisäosa kestää paremmin erilaisia poikkeustilanteita, käyttäjän virheitä sekä muiden lisäosien olemassaoloa. Näin yleensä ideaalitapauksessa, jossa oma tarpeesi muistuttaa hyvin paljon lisäosan kehittäjien tarvetta. Mitä erilaisemmalta oma tarpeesi näyttää, sitä enemmän kolmannen osapuolen lisäosan käytössä tulee esiintymään myös haasteita.

Haasteet

Kolmannen osapuolen lisäosien haasteet liittyvät yleensä toiminnallisuuden muokkaamiseen sekä sovittamiseen Suomen oloihin ja johtuvat monesti halusta pitää lisäosan päivitysprosessi mahdollisimman helppona. Haasteiden syiden syvällisemmän ymmärtämisen vuoksi on tärkeää tietää, miten lisäosat itsessään laajentavat WordPressin toiminnallisuutta.

WordPressin ytimen (Coren) lähdekoodissa esiintyy tasaisin väliajoin liittymäkohtia ( engl. hook), joihin kehittäjä voi liittää oman koodinsa. Näin kehittäjä voi muokata muuttujien arvoja tai suorittaa omaa koodiansa tietyssä kohdassa WordPressin suoritusjärjestystä varsin helposti. Hyvä esimerkki tästä on some-jakamisen lisäosa, joka hyödyntää tiettyä ytimessä olevaa liittymäkohtaa. Tämä liittymäkohta suoritetaan heti sen jälkeen, kun artikkelin sisältö on ladattu sivulle. Näin välittömästi artikkelin sisällön loppuun saadaan ladattua some-jako -painikkeet ilman, että WordPressin ytimen kooditiedostoja joudutaan muuttamaan. Näin koodimuutoksia ei menetetä, kun ytimen tiedostoja kirjoitetaan uudestaan WordPress-päivityksen yhteydessä.

Lisäosan toiminnallisuuden muokkaus

Myös lisäosat voivat määrittää omia liittymäkohtia ja paras tapa muuttaa lisäosan toiminnallisuutta onkin näiden liittymäkohtien hyödyntäminen. Se on kohtuullisen nopeaa ja myös kestävää kehittämistä. Kuten WordPressin ytimen liittymäkohtien suhteen, lisäosan päivittyessä muutettu toiminnallisuus säilyy. Tämä siis sillä ehdolla, että lisäosan kehittäjä ei poista liittymäkohta. Mikään ei kuitenkaan pakota lisäosan kehittäjää säilyttämään tai edes tarjoamaan liittymäkohtia eikä varsinkaan siinä kohtaa koodin suoritusta, johon haluttaisiin päästä käsiksi.

Tällöin jää kaksi vaihtoehtoa, jotka molemmat ovat automaattisten päivitysten kannalta huonoja. Ensimmäinen vaihtoehto on lähettää muutokset lisäosan kehittäjälle ja toivoa, että ne otettaisiin mukaan seuraavaan versioon. Riippuen lisäosan kehittäjästä tämä voi tapahtua viikossa, kuukaudessa tai ei koskaan. Toinen vaihtoehto on tehdä lisäosasta oma kopio, jolloin vastuu lisäosan jatkokehittämisestä tietoturvan ja yhteensopivuuden osalta siirtyy kopion tekijälle. Kummassakin tapauksessa muutokset joudutaan tekemään suoraan lisäosan koodiin.

Näistä syistä johtuen muutokset pyritään aina toteuttamaan liittymäkohtien avulla. Näiden ”sattumanvaraisen” määrän vuoksi se mitä voidaan ja ei voida tehdä vaihtelee riippuen lisäosasta. Paljon voidaan liittymäkohtien avulla toteuttaa, mutta aina ei haluttuja muutoksia saada tehtyä ilman lisäosan tai WordPressin ytimen kooditiedostojen muokkausta. Mainosten hienot lauseet WordPressin helposta laajennettavuudesta ovat totta siis vain tiettyyn rajaan asti. Mikäli tuo raja halutaan ylittää, alkaa yleensä kivikkoinen ja työläs taival. Jos ei vielä kehitysvaiheessa, niin viimeistään sivuston ylläpitovaiheessa.

Lisäosan lokalisointi

Toinen haaste liittyy lisäosan käyttöliittymän ja toiminnallisuuden sovittamiseen Suomen oloihin eli hienosti sanottuna lisäosan lokalisointiin. Näkyvin ja selkein piirre lokalisoinnissa on käyttöliittymän kääntäminen suomeksi. WordPressin maailmassa tämä tapahtuu GNU gettext -ohjelmistokirjaston avulla. Käytännössä suomeksi voidaan kääntää vain ne merkkijonot, jotka lisäosan kehittäjä on määrittänyt käännettäväksi. Koska suurin osa WordPressin lisäosista tehdään englanninkielistä maailmaa ajatellen, käännettäväksi tarjottuja merkkijonoja on joskus todella vaikea (ellei mahdotonta) kääntää suomeksi ilman että käännöksestä tulee kapulakieltä.

Esimerkiksi eräässä tapahtumakalenteri -lisäosassa on merkkijono “No upcoming %s”, missä %s:n tilalle tulee automaattisesti tapahtuma-sisältötyypin monikko eli “tapahtumat”. Tätä merkkijonoa on todella vaikea kääntää niin, ettei se kuulostaa siltä, että teksti ( “Ei tulevia tapahtumat”) olisi vedetty vain Google-kääntäjän läpi ja lähdetty kahville sen enempää asiaa miettimättä.

Kapulakielen lisäksi lisäosan käyttöliittymä voi olla muuten sekava ja epälooginen sivuston muuhun kokonaisuuteen verrattuna. Lisäosaa tehtäessä suurin huomio yleensä kiinnittyy itse toiminnallisuuteen, jolloin käyttöliittymän suunnittelu jää vähemmälle huomiolle. Tämän lisäksi lisäosa voi sisältää sellaisia ominaisuuksia, joille Suomen kontekstissa on todella vaikea keksiä mitään käyttöä. Nämä ominaisuudet ovat suomalaisten käyttäjien näkökulmasta turhaan kuluttamassa arvokasta tilaa ruudulla. Näin useamman lisäosan myötä hallintapaneelista voi tulla sekava ja vaikeasti käytettävä vaikka muuten WordPressiä onkin kehuttu helppokäyttöiseksi ja selkeäksi.

Tasapainoilua

Kolmannen osapuolen lisäosiin liittyvät haasteet tulevat omassa työssäni vastaan lähes viikoittain. Toisaalta kaikkien toiminnallisuuksien rakentaminen itse käsin ilman valmiita lisäosia nostaisi projektien hinnat taivaisiin. Mielekäs WordPress-projekti on aina tasapainoilua valmiiden ja itse tehtyjen ratkaisujen välillä.

Itse olen pitänyt ohjenuorana sitä, että pitkässä juoksussa kaikki pienet ja yksinkertaiset jutut kannattaa tehdä itse, kun taas isommat ja monipuolisemmat toiminnallisuudet kannattaa rakentaa kolmannen osapuolen lisäosien varaan. Näin laajojen sivustokokonaisuuksien hinta saadaan pysymään maltillisella tasolla, mutta sivusto kohtuullisen helppokäyttöisenä ja toiminnoiltaan haluttuna. Käytettävät lisäosat tulee kuitenkin valita huolellisesti.