Elokuussa 2020 Automattic julkaisi kaksi isoa major-päivitystä peräkkäin. Ensin WordPressille 5.5 ja heti perään Woocommercelle version 4.4. Lopputuloksena ryhmät alkoivat täyttyä kyselyistä mitä tehdä kun sivusto on nurin ja verkkokauppa ei toimi. Aivan yhtä taattuun tapaan ongelma ei ollut päivityksissä, vaan käyttäjissä. Versioissa ei ollut mitään vikaa, vaan syy oli vanhentuneissa ja päivittämättömissä lisäosissa sekä teemoissa. Ja jos päivityksessä olisikin ollut jotain vikaa, niin mitäs asensit ilman kattavia varmuuskopioita. Suhtautuminen niin WordPressin/Woocommercen kehitysryhmältä kuin yleisellä tasolla Automatticin puolelta, oli jossain määrin jopa järkyttävä, vaikkakaan ei yllättävä. Mutta siitä opittiin. Yhtään ainutta päivitystä ei saa tehdä ilman mahdollisuutta palata ajassa taaksepäin.

Taatusti osassa tapauksissa ongelman ydin olivatkin päivittämättömät ja hylätyt lisäosat. Mutta se ei selitä miksi niin moni ajantasaisia maksullisia lisäosia ja premium-teemoja käyttävilläkin sivustot kaatuivat tai menivät rikki. Sen sijaan se, että Automattic tekee kiihtyvällä vauhdilla muutoksia itse haluamaansa suuntaan piittaamatta muista, selittää huomattavan paljonkin.

WordPressin yksi vahva valttikortti on aina ollut, että se on helppo eikä vaadi syvempää teknistä osaamista. Tehdyt strategisemmat ratkaisut kaatavat tuota kovaa vauhtia. REST API on taatusti elämää helpottava tekninen ratkaisu, mutta huomattavasti vähemmälle huomiolle jäi muistutus, että samalla vuoti jokaiselle kyselijälle tiedot jokaisesta, joka on kirjoittanut tai reagoinut sivustolla rekisteröityneenä käyttäjänä. Kuka haluaa esittää arvauksen kuinka monen sivuston ja verkkokaupan rekisteröityneiden perustiedot ovat valuneet koputtelijoille ja lisäosien tekijöille?

Jälkijuna ei ole kehitystä

Version 5.5 tuomia suuria mullistavia asioita oli esimerkiksi sivustokartan luominen. Ihan kiva uudistus vuonna 2020, kun jokainen WordPress-sivusto oli joutunut toteuttamaan sen vuosia ulkoisilla lisäosilla. Nyt päällekkäisyys, jota ei voinut kytkeä pois hallinnasta, rikkoi paikkoja.

Toinen samanlainen kehuttu parannus oli lazy load; kuvien lataaminen vasta, kun niitä tarvitaan – ja tuokin esiteltiin vuonna 2020. Jokainen asiaa miettinyt sivusto oli toteuttanut sen jo aikoja aiemmin lisäosilla tai teeman avustuksella. Nyt tuotiin teknisesti heikompi päällekkäinen ratkaisu, joka rikkoi toimintoja. Kiitos WordPressin ja Automatticin, maailma on tällä hetkellä täynnä sivustoja, joissa lazy load hidastaa, koska myös ensimmäiset kuvat, joiden pitäisi tulla näkyviin heti, tulevatkin lyhyellä viiveellä.

Lazy load -laajennokset tarjosivat myös erilaisia pikkujuttuja, kuten esikatselukuvan vaikka YouTube-upotuksiin. WordPressin ratkaisu ei sitä tarjoa, mutta rikkoi useitakin niitä lisäosia, jotka sen tarjosivat.

UX-rikos: Gutenberg

WordPressin syvin ongelma tuli kuitenkin jquerystä luopumisesta. Ehkä se on teknisesti perusteltua, ehkä ei, mutta kun aito syy moiseen oli halu poistaa tuki vanhalta editorilta ja painaa ihmisiä käyttämään Gutenbergiä, niin perustelu romahti. Valtaosa hajoinneista sivusta ei hajonnut siksi, että olisi käytetty päivittämättömiä, vanhentuneita ja hylättyjä lisäosia, kuten Automattic ja kehitystiimi niin diplomaattisesti asian ilmaisivat, vaan koska sivustolla käytettiin classic editoria, ei blokkeja.

Pidän mielenkiintoisena kehittäjien näkemystä, että classic editorin käyttö tarkoittaa päivittämättömän ja vanhan softan käyttämistä. Ja että se asennetasolla jollain tavalla siirtäisikin syyllisyyden päivityksen epäonnistumisesta käyttäjän harteilla; mitäs käytit, kun me haluamme, että käytät blokkeja.

Gutenbergista ollaan montaa mieltä. Yleensä jakolinja menee suhtautumisessa sisältöön ja layoutiin. Jos webmaster haikailee page buildereita siksi, että hän saa muokattua ulkonäköä ja tehtyä veikeitä rakenteita, niin Gutenberg helpottaa. Onhan se parempi ratkaisu kuin yliturvonneet ja sivustoja hidastavat page builderit, joista turhan suuri osa raiskaa koko sisällön lyhytkoodeilla.

Sen sijaan sisällön luomiselle, kirjoittamisessa, Gutenberg on, jos ei ihan suoraan helvetistä, niin vakava rikos käytettävyyttä vastaan kuitenkin.

Se, että WordPressin kehitys on päättänyt, että asiat tullaan toteuttamaan tulevaisuudessa, itseasiassa jo nyt, pelkästään blokkieditorilla, on aiheuttanut sisältöpuolella painetta luopua WordPressistä. Automattic menee eräällä tavalla samaa tietä, jonka IBM, Xerox ja Nokia ovat jo viitoittaneet.

Uuden käytännön sisäistäminen

Niin tai näin, niin jos aikaisemmin seilasi hieman tuurilla ja rohkeasti vaan painoi päivitä-nappulaa, niin ne ajat ovat menneet. Nyt viimeistään on opeteltava uudet toimintatavat, ja se tulee taatusti vähentämään WordPressin houkuttelevuutta. Totta toinen puoli. Ei ole ohjelman vika, jos siinä on oppimiskäyrä tai että osalle jo se päivitä-nappula on liian haastava tekninen asia. Mutta jos päivitysten tekemien vahinkojen estäminen vaatii enemmän aikaa, vaivaa ja osaamista kuin ohjelman asennus ja käyttö, niin alkaahan suunta olla huolestuttava.

Kaksi asiaa on heti sisäistettävä:

• päivityksiä ei tehdä heti; ei vaikka WordPress kuinka käskisi
• auto update sammutetaan, eikä sitä käytetä koskaan

Ennenkuin mitään päivitetään, niin tehdään kaksi asiaa, tavalla tai toisella:

1. otetaan tietokannasta varmuuskopio
2. kopioidaan koko sivusto turvaan

Vasta sen jälkeen päivitetään.

Tuosta kaksikosta tietokannan varmuuskopio on ehdottoman oleellinen. Jos jätät jotain tekemättä, niin se ei saa koskaan olla tietokannan varmuuskopiointi. WordPressin ydin, lisäosat ja teemat saa aina tavalla tai toisella palautettua (paitsi jos olet lopettanut premiumin maksut…), mutta jos tietokanta tuhoutuu, niin se oli sitten siinä. Takaan, että et halua alkaa palauttamaan sivustoasi Webarchivesta ja selaimesi välimuistista.

Ihmiset luulevat turhan usein, että päivityksiä on testattu pitkään ja hartaasti. Usein noin omalla tavallaan onkin, mutta se ei tarkoita, että niitä olisi sekuntiakaan testattu siinä ympäristössä ja sillä kokoonpanolla, joka sinulla on käytössä. Aidosti sen viimeisen testauksen tekevät alkuvaiheen käyttäjät. Joten jos haluat mennä riskillä ja olla ensimmäisiä, ja jos (turhan usein nykyään: kun) asiat eivät toimikaan, niin muista tehdä siitä ilmoitus.

Me muut, joilla on enemmänkin tavoite saada toimiva sivusto kuin hehkuttaa uusimmalla uudella, odotamme. Kun tulee ns. minor-päivitys, esimerkiksi bugikorjaus tai turvapäivitys, niin ne on usein syytä asentaa nopeasti. Ne tunnistaa esimerkiksi versionumerosta x.x.1. Mutta niissäkin kannattaa usein odottaa päivä tai kaksi – ellei bugikorjaus lupaa korjata sellaisen vian, joka vaivaa sinua.

Sen sijaan jokainen major-päivitys, kun versionumero hyppää suuremmaksi ja mainostetaan uusia toiminnallisuuksia, jätetään kypsymään. WordPressin ja Woocommercen kohdalla odotetaan aina ja poikkeuksetta ensimmäistä minor-päivitystä. Niissä on korjattu ne viat, jotka ovat ilmenneet (vaikka niitähän ei ollut… Woocommercelle tuli ensimmäinen korjaus 4.4.1 parissa päivässä).

Odottamisella saa myös varmistettua, ainakin hiukan, että myös lisäosat ja teemat pysyvät vauhdissa mukana.

Tuo sama periaatte koskee myös teemojen ja lisäosien isoja päivityksiä, ei pelkästään WordPressiä ja Woocommercea.

Varmuuskopiointi WordPressissä

Varmuuskopiointi tehdään niillä työkaluilla jotka ovat käytössä. Siihen vaikuttaa myös kuinka suuren riskin työmäärästä haluaa ottaa.

Helpoin tapa on mennä siihen lisäosaan, joka ylipäätään hoitaa varmuuskopiot (onhan sinulla sellainen, onhan?). Minä käytän WordPresseissä taustalla UpdraftPlussaa. En ota kantaa siihen onko se paras tai  jotain muuta, mutta ilmaisversio on toiminut minulla riittävän hyvin – ja olen onnistuneesti palauttanut sillä sivustoja – masentavaa on se, että palauttamisen perustoiminnallisuus ei ole ollenkaan niin kirkossa kuulutettua backup-lisäosissa.

Olen aikoinaan törmännyt sellaiseenkin viritykseen, joka teki backupit ilman mitään ongelmia. Mutta kun yritit palauttaa, niin olisi pitänyt maksaa – eikä tuota muistettu kovinkaan selvästi kertoa, kuin ei myöskään sitä, että heidän tapansa oli muokattu niin, että muiden ohjelmien käyttö palautukseen oli mahdollisimman vaikeaa. Hieman samaa siis kuin export/import- maailmassa, niin export toki onnistuu, mutta ei enää import – jota kuitenkin jaetaan ilmaisena erillisenä lite-versiona.

Käytetty ohjelma tai lisäosa ei ole sinällään merkityksellinen. Pääasia on lopputulos: sinulla on kopio tietokannasta ja tiedostoista. Miten siihen päästään, on aivan makuasia.

Osaathan ylipäätään tehdä palautuksen? Varmuuskopio on aika turha muutoin.

Updraftplus kertoo koska seuraava varmuuskopiointi tapahtuu. Mutta nyt tarvitaan nappulaa, jolla varmuuskopiointi tehdään heti.

Kun varmuuskopiointi on tehty, niin kaikki on palautettavissa – tavalla tai toisella. Mutta silti kannattaa vilkaista logi, että virheitä ei tullut.

Palauttaminen on käänteinen temppu. Klikataan palauta-nappulaa, valitaan mitä palautetaan ja ohjelma hoitaa loput. Helppoa kuin heinänteko – paitsi että nyt jo koneemmat tietävät mikä on kysymysmerkkinä.

Backend ei aukene

Jos päivitys rikkoo vain frontendin, eli sivuston näkyvän osan, tai jos päivitys rikkoo jotain toiminnallisuuksia, niin kaikki on hyvin ja nopeasti palautettavissa. Turhan usein päivitys kuitenkin aiheuttaa sen, että hallinnan puolelle, sinne adminin backendiin, ei enää pääse. On jollain tapaa turhauttavaa ajatella, että on kaikki varmuuskopiot olemassa, mutta koska niiden palauttaminen vaatii toimivan WordPressin, niin se sitten siitä. Onneksi se ei ole kuitenkaan siinä.

Yksi tapa on asentaa kokonaan uusi WordPress ja jyrätä vanha. Ensimmäinen ja ainoa asennettava lisäosa olisi käyttämäsi backup-ohjelma, minulla se olisi Updraftplus – ja sitten palautetaan. Tuo on aika radikaali toimenpide, mutta mahdollinen ja se kannattaa pitää mielessä eräällä tavalla viimeisenä oljenkortena.

Toinen tapa on etsiä varmuuskopio, purkaa niiden zip-paketit ja sitten siirtää ne FTP:llä paikalleen. Sen jälkeen puretaan tietokannan gzip-paketit ja palautetaan cPanelin kautta tietokanta. Nopeampi, mutta vaatii hieman enemmän osaamista. Jos osaamista ei ole ja gz-pakkauksen avaamisen selvittämiseen menee tunti, niin samassa ajassa olisi jo asentanut uuden WordPressin ja palauttanut sitä kautta.

Koska molemmat vaativat määrättyä osaamista, niin ensimmäiseksi, ennen palautusta, tehdään se mikä WordPressissä aina tehdään ongelmissa: nimetään plugins-hakemisto uudestaan joksikin muuksi ja jätetään teemoihin näkyviin vain joku WordPressin omista perusteemoista. Sitten kokeillaan uudestaan. Jos kaatuminen, kuoleman valkoinen sivu, error 5xx tai jokin muu hallintaan pääsyn estävä virhe poistui, niin ollaan taas voiton puolella ja siirrytään vanhaan proseduuriin:

• otetaan haluttu teema käyttöön ja katsotaan mitä tapahtuu
• otetaan lisäosa kerrallaan käyttöön ja katsotaan mitä tapahtuu

Kun konfliktin toinen osapuoli löytyy, niin sitten mietitään kumpi kannattaa tehdä. Luopuako sen lisäosan tai teeman käytöstä vai palauttaa koko systeemi ja jäädä odottamaan tuoko joku seuraava päivitys avun.

cPanel toimii aina

Hyvä nyrkkisääntö on, että varmuuskopioita ei ole koskaan liikaa. Toki dynaamisella sivustolla jotkut vuosia, tai jopa viikkoja, vanhat varmuuskopiot ovat liioittelua, mutta sen hetkisiä ja lyhyellä aikavälillä menneisyyteen ulottuvia varmuuskopioita ei ole liikaa. Enemmän on parempi. Silloin saa hieman erityyppisiä paketteja talteen ja pienen turvan ohjelmavirheitä ja korruptoituneita tiedostoja vastaan – eivät ne kaikki voi olla pilalla (ellei lähde ole pilalla, mutta se on eri asia).

Vaikka tekeekin WordPressissä varmuuskopiot, niin cPanel on se paikka, johon kannattaa suunnata. Sieltä löytyy tietokantaa varten raskaan laaja työkalu, phpMyAdmin (jolla saa yhtä paljon vahinkoa aikaiseksi, kuin mitä voi korjata) ja jos hallitset sen, niin ehkä se on valintasi tietokannan backupiin ja palauttamiseen. Muut klikkaavat välilehden Backup auki.

Toki aika ajoin ehkä kannattaa ottaa koko tilistä full backup, mutta se mitä nyt tarvitaan, on varmuuskopiot home-hakemistosta ja MySQL-tietokannasta.

Riippuen sivustosi koosta ja varsinkin nettiyhteydestäsi, niin lataus saattaa kestää kauankin

Hieman nopeampi tapa on ottaa varmuuskopio vain tietokannasta, ja kopioida sivuston tiedostot talteen webhotellin sisällä. Esimerkkikuva on hieman huono, koska sivustolla ei ole WordPressiä, mutta ymmärtänet idean.

• Avataan File Manager
• Valitaan haluttu hakemisto
• Valitaan copy
• Annetaan juureen uuden varmuuskopiohakemiston nimi eli se alkaa kenoviivalla / – älä tee varmuuskopiota /tmp hakemistoon, ne häviävät sieltä

Jos päivitys menee pieleen, niin sitten vaan kopioidaan sivuston tiedostot takaisin ja palautetaan tietokanta. Tämä on ehdottomasti nopein tapa webhotelleissa – ja monella tapaa myös turvallisin.

Turhan usein kylläkin ongelmaksi nousee tilanpuute. Palvelusta riippumatta levytila on kovimmin veloitettua ja kitsaimmin jaettua, joten aika monet pyörittävät sivustoaan eräällä tavalla yksiössä, kun tarve olisi kolmiolle. Mutta silloin ladataan varmuuskopio omalle koneelle ja hyväksytään FTP:n hitaus.

Virtuaaliserverin tehokkuus

Virtuaalipalvelimilla työkaluja on paljon enemmän ja niillä saa asiat tehtyä huomattavasti helpommin. Täytyyhän kovemmalle kuukausiveloitukselle vastinetta saada. Ylipäätään VPS-käyttäjät ovat jo joutuneet opettelemaan perusteita enemmän ja heillä on käsitys miten varmuuskopiointi kannattaa tehdä. Tai ainakin pitäisi olla.

Ylivoimaisesti paras tapa on ottaa WP CLI käyttöön. Se on itseasiassa niin tehokas työkalu, että mitään muuta ei tarvita – ainakaan tietokannan suhteen.

• wp db export joku-nimi ja tietokanta on kopioitu
• wp db import joku-nimi ja tietokanta on palautettu

Tai jos mieluummin käytät MySQL:n omia komentoja:

• mysqldump --allow-keywords --opt -uroot -p TIETOKANTA > TIETOKANTA.sql tekee kopion
• mysql -u root -p TIETOKANTA < TIETOKANTA.sql palauttaa kopion

Aikaa meni sekunteja.

WP CLI ei ole tiedostonsiirron protokolla, eikä sen tarvitsekaan olla. Sitä varten aivan jokaisella linuxissa on rsync.

• rsync -a /var/www/sivusto/public_html/ /var/www/sivusto/backup/

Se oli siinä.

Virtuaaliservereillä elämä on niin helppoa, että jos jättää backupit tekemättä ja homma osuu omaan nilkkaan sen takia, niin myötätuntoa ei oikein heru – kyse on puhtaasta laiskuudesta ja viitsimättömyydestä, ei teknisesti vaikeudesta tai työmäärästä.

Moni on taatusti joskus saanut kuningasidean poistaa isomman hakemiston FileZillalla. Se on yleensä sarjaa tolkuttoman huono idea, ellei ole paljon joutilasta aikaa. Virtuaaliserverin maaginen rm -rf /var/www/sivusto/public_html/ tekee saman silmänräpäyksessä. Backup-hakemiston nimen muuttaminen takaisin muotoon public_html vie kaksi silmänräpäystä. Se siitä urakasta.

Jos haluaa alkaa selvittämään mikä sivuston kaatoi, minkä lisäosan tai teeman kanssa oli konflikti, niin WP CLI helpottaa urakkaa aika paljon. Yhdellä asiakkaalla kaatui sivusto juurikin 5.5 päivityksen takia. Tietokannan palautus ei auttanut, koska WordPress hermostui tilanteesta, jossa tietokanta julisti eri versiota kuin mitä WordPress oli. On useitakin tapoja rollata takaisin vanhaan versioon, mutta WP CLI:n avulla se vei pari sekuntia. Sivusto saatiin pystyyn ja kriisi oli siltä osin selätetty.

Joten virtuaalipalvelin ja WP CLI yhdessä eivät tee ainoastaan varmuuskopioinnista helpompaa, vaan antavat toimivat työkalut korjata rikkoutunut.

WP CLI ei ole sinällään pelkästään virtuaalipalvelinten yksinomaisuutta, mutta se vaatii mahdollisuuden komentokehoitteeseen, shelliin. Sitä ei suuremmin enää webhoteilleissa ole saatavilla, jolloin komentorivityökalu jää vain heidän iloksi, joilla on komentorivi – ja se tarkoittaa VPS-asiakkaita.

Woocommercen vaikeus

Verkkokauppa mutkistaa tilannetta paljon ja vielä vähän enemmän. Woocommerce on esimerkkinä vain siksi, että se on suurin. Samat ongelmat koskevat silti aivan kaikkia, oli kyseessä vaikka Easy Digital Downloads tai muu verkkokauppaohjelmisto.

Kyse on dynaamisuudesta. Siitä, että verkkokaupan pitäisi olla auki ja ostoksia tapahtuu, mielellään koko ajan ja vielä hiukan useammin. Katkoksia ei haluta, eikä niitä saisi olla.

Jos EksisONE kaltainen sivusto kaatuu, niin ei se mikään maailmanloppu ole. Ärsyttävää kylläkin, mutta ei sen enempää. Sen sijaan jos jokin KatiskaStoren kaltainen verkkokauppa kaatuu, niin se näkyy lompakossa aika äkkiä. Ja jos kauppaa ei saa nopeasti takaisin linjoille, niin sattuu vielä enemmän.

Verkkokauppojen kohdalla ei pitäisi edes keskustella aiheesta tehdäänkö kattava varmuuskopiointi ennen päivitystä vai ei. Se pitäisi olla selviö.

Sopivan päivitysajan miettiminen tarkoittaa useimmiten sitä, että omista yöunistaan saa einen tinkiä. Ainakin, jos sivusto on suunnattu Suomen markkinoille. Päivityksen ajaksi sivusto on suljettava. Jos sisältösivustolla voi tehdä alustavat varmuuskopionnit itselleen sopivana aikana etukäteen, kunhan ei julkaise mitään sillä välin, ja suorittaa päivityksen hiljaisempana aikana, niin verkkokaupassa tehdään toisin.

• Valitaan hiljaisin aika, Suomessa yleensä aamuyöllä
• Laitetaan sivusto huoltotilaan
• Tehdään varmuuskopioinnit
• Tehdään päivitys
• Tehdään nopea testaus
• Poistetaan huoltotila

Vaikka huoltotilaan laitto saattaakin katkaista jonkun ostokset, niin se on pienempi paha kuin hukata useampi ostos siksi, että sivusto ei toipunutkaan päivityksestä.

Stage ja testisivusto

Jos haluaa olla huolellinen, niin päivitysten toimivuudesta pitäisi varmistua testisivustolla. Oikeammin, kyse ei ole halusta, vaan useimmin kyvystä ja mahdollisuudesta. Stage-sivuston tekeminen ei nimittäin ole aivan niin läpihuutojuttu kuin annetaan ymmärtää. Myöskään asioiden testaaminen ei ole mikään pieni urakka.

Useimmiten esteenä stagen käytössä on niin tuttu asia kuin raha. Se maksaa. WordPressiin löytyy lite-versioita ilmaiseksi, mutta ne ovat hyvin lähellä turhaa. Löytyy useitakin lisäosia, jota tekevät stage-version ja hinnat ovat noin alkaen 80 euroa ja ylöspäin. Kannattaa muistaa, että – taaskaan – lifetime ei lisensöinnissä tarkoita päivitysten saamista, vaan käyttöoikeutta. Jos haluat päivitykset, niin hinta on vuotuinen.

Nuo lisäosat ovat pakollisia vain, jos ei ole shell-pääsyä, komentoriviä, eikä saa siirrettyä sivustoa jonnekin muualle. Jos shell löytyy, niin stage-lisäosille ei tee mitään. Saman saa tehtyä käsin. Ne tekevät tismalleen saman kuin jos muuttaisit sivustosi jonnekin muualle, ja hakemisto sekä url muuttuu. Sen tekee itsekin muutamassa minuutissa.

Yksi asia on ehdottomasti pidettävä mielessä koko ajan. Muista millä sivustolla olet milloinkin! Tuo saattaa tuntua itsestäänselvyydeltä, mutta ei se, että tekee vääriä asioita väärässä paikassa, ole aivan poikkeuksellista.

API ja asennusmäärät

Stagessa on yksi oleellinen ongelma ja se tulee muutamista lisäosista.

Kaupalliset lisäosat on sidottu lisensointinsa kautta määrätylle määrälle sivustoja. Yksi muistisääntö on, että jos lisensoinnin API asetetaan urlille www.example.com, niin lisäosa ei toimi osoitteessa stage.example.com ja on aivan tuurista kiinni laskeeko myyjä urlin www.example.com/stage uudeksi asennukseksi, koska se www.example.com löytyy myös käytettävien joukosta.

Sen sijaan useimmat lisäosat, jotka ovat kiinnostuneita vain domainista, kuten example.com, sallivat myös alidomainit, eikä ongelmia tule. Yksi tapa selvittää tuota on kaivaa esille lisäosan toimiminen ilman ylimääräistä rahaa MU-ympäristössä. Jos se toimii multi sitessa, niin se toimii myö alidomainissa (koska alidomaineja multi sitet käyttävät).

On toinenkin potentiaalinen paikka, joka saattaa mennä rikki – CDN. CDN on aidosti välimuisti ja koska stage muuttaa ”masterin” urlin, niin CDN:n sisältö joudutaan usein tekemään uusiksi. Joten jos käytät lisäosaa, joka veloittaa kuvissa per operaatio, tai käytät CDN-palvelinta, joka veloittaa per tallennustila, niin saatat saada ikävän yllätyksen. Hinnoittelusta sitten riippuu, että onko se vain huokaustasoa vai aletaanko keskustelemaan aidoista rahoista.

Tämä on asia, joka on selvitettävä etukäteen. Harva asia saa ärsyyntymään yhtä paljon kuin ostaa ensin satanen vuosi maksavan stage-lisäosan ja sitten huomata, että lisensointia on laajennettava tusinan lisäosan kohdalla 300 euroa vuosi maksavaan lisenssiin vain siksi, että saa varmistettua rikkooko WordPressin päivitys paikat vai.

Ne on ostettava, sillä testi, jossa ei lisensoinnin takia ole mukana kaikkia käytössä olevia lisäosia, on totaalista ajanhukkaa. Silloin on parempi hypätä pää edellä samantien sameaan veteen ja hoitaa jälkikorjaus backupien kanssa.

Summissa aletaan liikkumaan sellaisella tasolla, että kannattaa harkita virtuaaliserverin hankkimista. Tai ostaa satasella Raspberry Pi ja tehdä testit kotona.

Panostuksen koko ja hyväksyttävä työmäärä riippuu tietysti kokoluokasta. Jos tahkoat verkkokaupalla puolen miljoonan tuottoa, niin muutaman satasen säästö olemalla tekemättä testiympäristöä on yksiselitteisen typerää ja piheyttä pahinta laatua. Mutta jos olet kuin tyypillinen yksinyrittäjä, eli ansiot ovat alle köyhyysrajan, tai pyörität harrastussivustoa tavallisessa tuloluokassa, niin kannattaa laskea tarkkaan mihin kannattaa rahojaan sijoittaa.

Testaamisen vaikeus

Testaaminen ei ole aivan läpihuutojuttu. On testattava vähintään perusasiat, kuten

• aukeaako jokainen mahdollinen artikkelimuoto luettavaksi, muokattavaksi ja uutena editoriin, sekä saako ne tallennettua
• pystyykö verkkokaupassa tekemään kaikki mahdolliset tilaukset ja ostokset, sekä toimiiko rahaliikenne (joka vaatii omat hiekkalaatikkoasetuksensa)

Sen lisäksi täytyy mennä läpi lomakkeet – voiko formin lähettää ja vastaanottaa – onnistuuko sähköpostien lähettäminen, saako salasanan palautettua, toimiiko mediakirjasto jne.

Tuohon uppoaa yllättävän paljon aikaa. Itseasiassa niin paljon, että se on ehkä yleisin syy dumpata stagen käyttö, vaikka ajatus on ollut kaunis alunperin.

Asiat ovat jo rikki

Jos olet tilanteessa, että olet päivittänyt, asiat menivät rikki eikä varmuuskopioita ole, niin minulla ei ole oikein tarjota sinulle muuta kuin sympatiaa. Arkirealismin faktoja on, että kun maljakko tipahtaa lattialle, niin sitä on vaikea saada edes liimalla kasaan.

Jos pääset hallinnan puolelle, niin selvitä onko jokin lisäosa tai teemasi ongelma. Jos on, niin siirrä se FTP:llä muualle sivustosi hakemistoista. Jos ongelman ydin on WordPressin (tai Woocommercen) päivitys, niin voit yrittää palata takaisin vanhaan versioon (Googlen hakusanat ovat wordpress+roll+back) ja pidät kädet ristissä, että tietokanta ei suutu.

Jos et pääse backendiin, FTP:llä lisäosien siivous ei auttanut eikä sinulla ole shelliä käytössä… toivottavasti korjauspäivitys tulee nopeasti. Seuraa kuitenkin kansainvälisiä WordPressin ryhmiä, Facebookissa käytännössä. Jos et kuulu vähemmistöön, niin joku muukin on samassa nesteessä ja saattaa saada apua. Itsekin voi kysellä, mutta se vaatii siedettävää kolmannen kotimaisen taitoa tai sitten hätäpäissään kääntää Googlen translatella – ei haittaa, suurin osa kirjoittaa vielä huonompaa englantia.

Vilkaise myös tämä juttu, vaikka se onkin suurelta osin tämän artikkelin toistoa:

https://www.eksis.one/ohjeet/wp-cli/wp-cli-palauta-vanha-versio/

Kun vihdoin päivität

Kun vihdoin päivität kaiken, ja sinulla on ajantasaiset varmuuskopiot kaikesta mahdollisesta ja mahdottomasta, niin marssijärjestys on:

1. tyhjennä kaikki sivuston välimuistit
2. ensin päivitetään lisäosat ja käytössä oleva teema
3. sitten päivitetään WordPress/Woocommerce
4. viimeiseksi päivitetään WordPressin omat teemat
5. tyhjennä taas kaikki mahdolliset välimuistit, myös käyttämäsi selaimen sivustoosi kohdistuvat evästeet ja cachen

Sitten testataan taas, ainakin perusasiat ja siltä osin kuin se ei häiritse sivuston toimintaa – maksutapojen toimivuuden testaaminen on aika mahdotonta live-sivustolla.

Pidä muutama päivä silmällä logeja. Jos kävijämäärissä tulee notkahdus, tai kauppaa ei synnykään toivotulla tavalla, niin aletaan etsimään vikaavikaa. Itse en julkaise sisältösivustoilla mitään ennenkuin olen vakuuttunut, että kaikki toimii suunnilleen kuten kuuluukin. Jos ongelmia tulee, niin voin edelleen palata muutamankin päivän vanhaan varmuuskopioon, eikä mikään mene rikki.

Verkkokaupoissa sen sijaan on hankalampaa, varsinkin jos kuitenkin jotain kauppaa on syntynyt. Silloin vaan yritetään löytyy varsinainen virheen aiheuttaja ja lähteä sitä kautta huutamaan apua.

Sitten elämä rauhoittuu. Seuraavaan major-päivitykseen asti.

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