WordPress poikkeaa monista sisällönhallintajärjestelmistä siinä, että sen voi päivittää todella helposti. Päivitys onnistuu muutamalla klikkauksella, eikä mitään kooditietämystä tai vastaavaa tarvita operaation suorittamiseksi. Koska prosessi toimii yleensä kuin se kuuluisa junan vessa, monesti päivityksen yhteydessä jätetään välistä tärkeitä asioita, jotka auttavat siinä kohtaa kun junan vessa ei toiminutkaan. Tällä kertaa käymme läpi, miten WordPress kannattaisi aina päivittää.

Video-oppaassa olemme jo käyneet läpi, miten päivityksen voi suorittaa muutamalla klikkauksella. Videolla jo mainitsin, että päivityksen yhteydessä tulisi ottaa huomioon muutamia asioita, jotka monesti jätetään huomiotta.

Itse suosin yhden tai kahden viikon päivityssyklejä, mutta päivityssyklit riippuvat myös hyvin paljon siitä, kuinka paljon päivitettävää on. Jos lisäosia ei ole montaa, voi olla että päivityksiä ei edes kovin usein tule.

WordPress-ytimen päivitys kannattaa joskus tehdä mahdollisimman nopeasti, sillä niissä on usein tietoturvakorjauksia. Ydinpäivitysten kanssa kannattaa kuitenkin olla erityisen tarkkana, sillä vaikka ne pyritäänkin tekemään taaksepäin yhteensopiviksi, lisäosien tai teemojen tekijät eivät aina ole testanneet tuotettaan tulevalla WordPress-versiolla. Tämä taas joskus saattaa johtaa siihen, ettei lisäosa toimi uudella versiolla.

WordPress kehittyy koko ajan eteenpäin. Artikkelin kirjoituksen jälkeen WordPressin versio 3.7 toi mukanaan ytimen automaattiset päivitykset. Jatkossa WordPress päivittää itsensä pienversiosta toiseen automaattisesti (esim. 3.7 -> 3.7.1), mutta isommat päivitykset pitää tehdä käsin (esim. 3.7->3.8). Isommatkin päivitykset on mahdollista automatisoida, mutta isompien muutoksien automatisoinnissa piilee aina omat vaaransa.

Tuotantopäivityksen ajankohta kannattaa tietenkin ajoittaa mahdollisimman ruuhkattomaan hetkeen.

Päivitysrutiini

Kun päivityksiä päätetään ajaa, päivitysrutiinin tulisi mennä seuraavalla tavalla:

  1. Testaa päivitys testiympäristössä, joka mielellään vastaa mahdollisimman paljon tuotantoa.
    1. Ympäristö voi olla paikallisella koneella tai ihan netissäkin toisessa osoitteessa (esim. dev.verkkotunnus.fi)
  2. Jos päivitys onnistui mukisematta, ota tuotantosivustosta varmuuskopio ennen päivitystä.
    1. Olen käynyt aiemmin jo läpi, miten varmuuskopioita voi ottaa Dropboxiin.
  3. Kun varmuuskopio on otettu, tee päivitys tuotantoon.

Jos päivitys epäonnistuu ensimmäisessä kohdassa, se ei haittaa sillä olemme testiympäristössä ja voimme rauhassa selvittää, mistä epäonnistuminen johtui. Jos päivitys epäonnistuu kaikesta huolimatta kolmannessa kohdassa, tällöin voimme palauttaa varmuuskopiosta juuri ennen päivitystä olleen version. Palautus onnistuu puolessa tunnissa.

Ongelma monesti on vain se, että päivitykset tehdään hyppäämällä suoraan kolmannen kohdan ”Tee päivitys tuotantoon” kohtaan. Useimmiten tämä toimii ok, mutta mitä sitten kun se ei toimikaan? Sitten on yleensä kunnon soppa käsissä ja tukifoorumilla alkaa huuto, että kaikki on lisäosan tai teeman tekijän syytä. Onko tilanne tosiaan näin? Osiltaan kyllä, mutta jos päivitys tehtäisiin ylläolevalla prosessilla, se olisi tyssännyt ensimmäisen kohdan jälkeen, eikä mitään olisi tapahtunut tuotantoympäristöön. Ongelma olisi voitu rauhassa selvittää hyvin mielin ilman että on tulenpalava kiire saada oma tuotantosivusto taas toimimaan.

Kannattaa muistaa, että näitä asioita koodaavat ihmiset. Virheitä sattuu.

Suurin osa lisäosista on ilmaisia. Ennen kuin tukifoorumille menee puhisemaan pää punaisena, kannattaa myös miettiä, olisitko itse valmis uhraamaan parhaimmillaan tuhansia tunteja ilmaisen lisäosan kehittämiseen ja tukemiseen? Lisäosia on tämän artikkelin kirjoitushetkellä olemassa yli 25 000 kappaletta. Vaikka kehittäjänä kuinka haluaisin, että tekemäni lisäosa toimii kaikkien muiden lisäosien kanssa yhteen, se on yksinkertaisesti täysin mahdotonta volyymin takia.

Mutta kun siihen menee niin paljon aikaa ja vaivaa

Pitää paikkansa, että kuvattu päivitysrutiini vie enemmän aikaa ja rahaakin, kuin jos päivityksen tekee vain suoraan tuotantoon, eikä mitään testiympäristöä ole. Mutta mietipä paljonko se vie esimerkiksi yritykseltäsi myyntiä, jos verkkosivut ovat epäonnistuneen päivityksen takia kumossa parikin päivää? Minkälaisen kuvan tämä antaa kävijöille, jotka sivuille pyrkivät?

Saattaa kuulostaa ihan naurettavalta, että sivut olisivat monta päivää jojossa, mutta kaikki on mahdollista, jos varmuuskopioita ei ole ja päivitys on jättänyt järjestelmän epäonnistuneeseen tilaan.

Kirjoittaja Timo Leiniö

Olen WP-oppaan perustaja ja päätoimittaja. Työskentelen päivittäin erilaisten verkkosovelluksiin liittyvien haasteiden parissa Sofokuksella. Vapaa-ajalla minut löytää todennäköisesti kalastamasta tai pelaamasta biljardia.

Keskustele ja kysy

  • samikeijonen sanoo:

    Onneksi WP päivittyy nykyään automaattisesti, poislukien isommat versiot. Esim. 3.8 — 3.9. Tämä ei toki poista varmuuskopioiden tärkeyttä.

    • timoleinio sanoo:

      Näin on. Artikkeli on kirjoitettu ennen kuin tämä ominaisuus tuli WordPressiin, joten päivitin artikkelia.

      Isompienkin päivitysten automatisointi on mahdollista, mutta itse en sitä suosittele.

Lisää uusi kommentti

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *