Yrityksien WordPress-sivujen laatu vaihtelee – valitettavan paljon.
Ideani tähän kirjoitukseen heräsi Digitoimisto Duden @rolle:n Twitter-päivityksestä:
Taas pohdin…
– onko alalla tosiaan niin paljon huonoja tekijöitä
– miten ei tajuta että halpa != hyvä
– miten ei ymmärretä että vanhan parsiminen on kalliimpaa ja vaivalloisempaa kuin uuden tekeminen? näin siltikin, vaikka sivusto olisi juuri rakennettu, valitettavasti. #wpfi https://t.co/ZSupEHhqtu— Roni Laukkarinen (@rolle) August 20, 2018
Halpa on eri asia kuin (!=) hyvä
Yleensä ongelmat alkavat siitä, että sivuston toimittaja valitaan puhtaasti hinnan takia. Toimittajalla on hyvin rajallinen WP-osaaminen ja sivuston rakennukseen käytetään netistä ostettua valmisteemaa. Kun valmisteema ei tarjoakaan enää sitä, mitä asiakas on vailla, ollaan ongelmissa – kun sivusto on koodattu omituisilla purkkaviritelmillä, niiden korjaajalle normaalisti 1-2h työn tekeminen vaatii moninkertaisen ajan.
Päivittäisitkö sivuasi mieluummin näin?
Vai näin?
Mistä sitten voi tietää, että toimittaja osaa asiansa? Toimittajan sivuilla voi olla lukuisia WP-referenssejä, mutta et voi kuitenkaan tietää, miten sivut on teknisesti toteutettu.
Google Chrome selaimella on helppo tehdä ns. pikatarkistus, jolla saa hieman osviittaa sivun teknisestä laadusta: mene halutulle sivulle ==> klikkaa hiiren oikeaa nappia ==> Inspect ==> Audits ==> Run audits ==> jos sivun performance arvosana on luokkaa 0-20, sivulla on jotain pahasti pielessä. Joko sivusto on koodattu kehnosti ja/tai se pyörii surkealla kahden euron jaetulla palvelimella. Lighthouse-työkalulla saa sivustosta irti myös SEO- ja saavutettavuus-mielessä tärkeitä seikkoja. Valitettavasti Lighthouse-työkalu ei kerro mitään spesifisiä tietoja sivuston WordPress-toteutuksen laadusta, tämän saa selville vasta lähdekoodia tutkimalla.
Esim. luuptek.fi performance-arvo vaihtelee 80-85/100 välissä, siitä voi kokeilla laittaa paremmaksi.
Mutta reteilystä sikseen… ohessa lista virheistä, joita WP-sivustosi toimittaja saattaa tehdä.
1. Pääkuvat (tai kuvat yleensäkin) ja useasti päivitettävät tekstit kovakoodataan sivuston teemaan
Tämä on joko laiskuutta tai osaamattomuutta. Sivut pitää ehdottomasta rakentaa niin, että kuva- ja tekstimuutoksia ei tarvitse tehdä koodiin, vaan suoraan WP-hallinnan kautta.
Toki tämä voi olla myös puhtaasti bisnesmielessä keplottelua, jolla asiakkaalta saadaan helpot rahat pois pienistä kuva-ja tekstimuutoksista.
2. Ei käytetä buildaustyökaluja
Buildaustyökaluilla tarkoitan työkaluja, joilla esim. SASS-tiedostoista rakennetaan minifioitu CSS-tyylitiedosto. Valitettavan paljon näkee sivustoja, joissa sivuston tyylit kirjoitetaan suoraan CSS:ksi ja ehkä manuaalisesti minifioidaan erillisessä työkalussa.
Buildaustyökalut kasvattavat kehitysnopeutta huomattavasti, ja säästävät selvää rahaa varsinkin isommissa sivustoissa, joissa erilaisia tyylejä luodaan paljon.
* Muutamat suomalaiset WP-osaajat tarjoavat open source -teemapohjaa, jossa buildaustyökalut ovat valmiina. Esim. Luuptek (eli me!!), Dude ja Aucor. Suosittelen tutustumaan.
3. Ei käytetä versionhallintaa eikä deploy-prosessia
Eli käytännössä koodi on säilössä kehittäjän koneella ja palvelimella. Koodi siirretään SFTP:llä drag&drop-tyyppisesti palvelimelle. Tämä tapa on kömpelö, hidas ja riskialtis.
* Parempi tapa on käyttää versionhallintaa eli gittiä. Esim. Luuptek käyttää sekä Githubia että Bitbucketia koodin säilömiseen. Tällöin koodi on valmiina ”pilvessä” ja kuka tahansa voi tehdä siihen helposti muutoksia.
* Kun aletaan kunnolla hifistelemään, luodaan deploy-prosessi (eli tapa, jolla koodi siirretään palvelimelle), jolla viimeisin koodi versionhallinnasta saadaan palvelimelle yhdellä komentorivin käskyllä.
4. Ei käytetä WordPressin tarjoamia funktioita
Ehkäpä räikein vastaantullut huono esimerkki on ison kansainvälisen toimijan nettisivusta, joka oli rakennettu alusta lähtien päin mäntyä. Esimerkiksi simppelit sivukyselyt oli rakennettu räätälöityinä SQL-kyselyinä, kun mahdollisuutena olisi ollut esimerkiksi käyttää WordPressin tarjoamaa WP_Query -luuppia. Tai julkaisun metatiedot tallennettiin räätälöitynä SQL-kysenä wp_options -tauluun eikä metatietoina. Luonnollisesti saitti jouduttiin koodaamaan alusta asti täysin uusiksi.
* WordPress tarjoaa oman coren kautta lukemattomia eri funktioita erilaisiin käyttötapauksiin. Niitä on niin paljon, että kukaan ei varmastikaan kaikkia osaa ulkoa. Googlettaminen kuitenkin yleensä auttaa…
5. Filttereitten (add_filter) ja koukkujen (add_action) käyttämättömyys
Tämä liittyy osittain edelliseen. WordPress tarjoaa devaajalle huikean määrän erilaisia filttereitä (filter) ja koukkuja (hook), joista osa on dokumentoitu, osa taas ei.
Filtterit ja koukut ovat periaatteessa sama – niillä voi muuttaa WP:n omien funktioiden toimintaa pienellä koodipätkällä.
* Luuptekissa paljon käytetty on pre_get_posts-koukku, jolla voi muuttaa SQL-kyselyä eri sivupohjissa.
6. Sivupohjien kömpelö käyttäminen
WP-devaajalle pitäisi olla päivänselvää, mitä eroa on page.php, single.php, archive.php, taxonomy.php, category.php ja index.php tiedostoilla. Jos perusrakennetta ei tiedä, niin tällöin menetetään kyseisten tiedostojen automaattinen hyödyntäminen esimerkiksi referenssien näyttämisessä. Toki joskus on parempi tehdä ihan oma räätälöity arkistopohja vrt. archive.php käyttäminen.
+ Käytetään huonolaatuisia ja vanhentuneita (tai paljon) lisäosia
Nyrkkisääntönä voisi sanoa, että asenna vain sellaisia lisäosia, jotka:
- ovat saaneet hyviä arvosteluja wordpress.org:ssa
- on päivitetty useasti viimeisen vuoden aikana
Tällä nyrkkisäännöllä pääsee jo pitkälle. Lisäosa tuskin rikkoo toiminnallisuutta päivittyessään ja mahdolliset WP-coren päivityksen aiheuttamat yhteensopivuusongelmat korjataan nopeasti.
Luonnollisesti mitä vähemmän lisäosia on sivullesi asennettu, sen pienempi riski on siihen, että sivustosi tietoturvaa uhataan vanhentuneen lisäosan vuoksi. Tai että jokin sivusi avaintoiminnallisuus (joka on rakennettu plugarilla) ei enää toimikaan WP-core päivityksen jälkeen.
Jos sivustollasi on paljon huonolaatuisia lisäosia, se vaikuttaa negatiivisesti sivuston suorituskykyyn.
+ WordPress-ydintä ei päivitetä
Uuden sivuston julkaisun jälkeen WordPress-ytimen päivitys jätetään heitteille, koska ei ole sovittuna vastuutahoa, jonka päivitykset pitäisi hoitaa. Jos ydin jätetään päivittämättä pitkäksi aikaa, heikkenee sivustosi tietoturva huomattavasti.
* Päivityksiin kannattaa käyttää ammattilaista, jolla varmistetaan se, että sivustolla ei hajoa mikään päivityksen yhteydessä. WP-ydin on turvallista päivittää, mutta ongelmana ovat lisäosat, jotka voivat aiheuttaa koko sivuston kaatumisen päivityksen yhteydessä.
* Luuptek käyttää pääsääntöisesti omissa projekteissaan WP-palvelua hoitamaan päivitykset automaattisesti.
—
Jäikö jotain oleellista puuttumaan? Tägää Twitteriin @luuptek.
