Jos olet tarpeeksi kauan pyörittänyt WordPressiä, niin olet taatusti törmännyt tilanteeseen, että lisäosan tai teeman päivitys rikkoo sivuston. Yksi syy siihen, miksi ei koskaan päivitetä heti, vaan odotetaan ainakin viikko. Jos kuitenkin käy noin, niin on kaksi vaihtoehtoa. Palautetaan koko sivusto backupista tai palataan takaisin vanhaan versioon. Kumpikin voi olla haastavaa, varsinkin backup.
Kysymys on lähinnä yhdestä asiasta: pääsetkö WordPressin hallintaan. Jos et pääse ja backup on rakennettu jollain pluginilla, joka vaatii pääsyn itse lisäosaan, niin olet ns. nesteessä. Silloin kannattaa ensimmäisenä googlettaa, että tarjoaako varmuuskopiointiin käytetty lisäosa natiivisti CLI:tä. Jos tarjoaa, niin jotain saattaa olla tehtävissä. Yleisesti käytetty UpdraftPlus tarjoaa WP CLI -laajennoksen ainostaan rahalla. Ei se päättömän kallis ole, noin 15 euroa vuosi, mutta sekin tuntuu oudolta. Se ei nimittäin tarjoa sen enempää kuin ilmainen plugin.
Jos et pääse backuppeihin käsiksi WP CLI:n kautta, niin sinulla on yksi vaihtoehto:
- jyrätä koko WordPress-asennus ja asentaa se uudestaan
- asentaa backup-lisäosa
- palauttaa varmuuskopio (ja toivottavasti olit backupannut myös kuvat ja lisäosat)
Se on sen verran ekstriimi operaatio, että ei sitä ihan ensimmäiseksi kannata tehdä. Mutta jos kyseessä on ollut Worpdressin tai Woocommercen iso päivitys, niin pelkästään kummankaan palauttaminen edelliseen versioon ei auta, koska tietokantaa on muokattu. Silloin sinun pitää palauttaa vanhaan versioon niin järjestelmä kuin tietokantakin.
Usein homma korjaantuu ihan sillä, että poistat huonosti käyttäytyvän teeman tai lisäosan. Joko hoidat homman FTP:llä, perinteiseen tapaan shellissä tai sitten WP-CLI:llä.
Hoidetaan esimerkinomaisesti työ WP-CLI:llä, koska se on usein helpoin ja nopein. Jos sinulla ei ole WP CLI:tä, niin se täytyy ensin asentaa – joten toivottavasti sinulla on pääsy SSL:ään, jota myös terminaaliksi tai shelliksi kutsutaan.
Muista siirtyä ensin sivuston hakemistoon.
cd /var/www/html
Lisäosan tai teeman poistaminen
Ensin sinun täytyy selvittää poistettavan teeman tai lisäosan slug. Se on sama kuin wordpress.org repossa tiedostonimi ilman versiota. Mutta löydät sen myös sivustoltakin.
Voit etsiä sitä nimen osalla. Jos etsit teemaa, niin vaihda aina plugin muotoon theme. Käytän vain esimerkkinä lisäosaa gutenberg, joten toki vaihdat sen tarvitsemaasi.
wp plugin search gutenberg
Tai voit listata kaikki.
wp plugin list
Kenttä name on sama kuin slug. Nyt voidaan ottaa lisäosa pois päältä.
wp plugin deactivate gutenberg
Kokeile jos se jo auttoi. Jos ei, niin voit poistaa lisäosan tai teeman kokonaan.
wp plugin delete gutenberg
Lisäosa aiheuttaa konfliktin
Lisäosat eivät läheskään aina toimi toistensa kanssa yhdessä. Tai teemojen kanssa. Kun jokin ei toimi, niin ensimmäinen mikä tehdään on
- ottaa kaikki lisäosat pois päältä,
- ottaa ns. perusteema käyttöön (esimerkiksi 2019) ja
- alkaa kytkemään niitä yksitellen päälle
Jos jokin lisäosa ei tee sitä mitä pitäisi, ja epäilet riitaa muiden kanssa, niin jätä tarvitsemasi päälle ja sammuta muut. Jos se ei edelleenkään toimi, niin lisäosa/teema itsessään on rikki. Jos se toimii, niin sitten alat kytkemään asioita yksi toisensa jälkeen päälle. Jossain vaiheessa testaamasi lisäosa tai teema lakkaa toimimasta. Silloin olet löytänyt konfliktin. Sen jälkeen joudut päättämään kumpi on tärkeämpi pitää päällä ja kumman kehittäjälle lähetät sähköpostia korjaustarpeesta. Sitten joudut vielä riitelemään, koska kummankin kehittäjä syyttää toista virhetilanteesta, mutta se on oma tarinansa.
Lisäosien sammuttaminen ja käynnistäminen on aika tylsää hommaa. Joskus myös todetaan, että lisäosahakemisto täytyy kokonaan poistaa, joka on tosiaan se nopein tapa sammuttaa kaikki kerralla. Ongelmantynkää on vain siinä, että kaikki lisäosat eivät hallitse moista tilannetta. Esimerkiksi muutoin kohtuullisen toimiva lisäosa Woocommerce Follow-Up hukkaa moisessa kaikki sähköpostilistansa. Sen voi sammuttaa, mutta ei poistaa – ja jos poistat, niin muista ottaa CSV:nä ensin kaikki postilistatiedot talteen.
Sammuttamista ja käynnistämistä voi helpottaa WordPressissä WP-CLI:n avulla. Ja hyvinkin oleellista, jos et edes pääse admin-hallintaan.
Ensin sammutetaan kaikki lisäosat. Kokeile jos virhe poistui. Jos kyllä, niin ongelma on jossain lisäosassa.
wp plugin deactivate --all
Jos kokeilet jotain käynnistettyä lisäosaa vastaan, niin käynnistä se uudelleen.
wp plugin activate PLUGIN-SLUG
Vaihdetaan teema. Jos virhe poistui, niin ongelma on teemassa.
wp theme activate twentynineteen
Otetaan listaus sammutetuista lisäosista ja tehdään niistä lista.
wp plugin list --status=inactive --field=name > pluginlista
Tehdään pieni koodi.
nano testi.sh
Kopioi tiedostoon tämä.
while read -r PLUGIN; do
echo "Activating ${PLUGIN}"
wp plugin activate ${PLUGIN} --allow-root
read -p "Paina enter jatkaakseni" </dev/tty
done < pluginlista
Tallenna. Aja koodi.
bash testi.sh
Nyt käynnistetään jokainen lisäosa kerrallaan enteriä napauttamalla. Joten jokaisen enterin jälkeen käy kokeilemassa, onko virhe poistunut.
Lisäosan tai teeman palauttaminen vanhaan versioon
Jos asiat menevät pieleen päivityksessä, niin yleensä on tiedossa minkä lisäosan tai teeman päivitys rikkoi paikat. Silloin on päätettävä, että pystyykö olemaan ilman sitä. Jos pystyy, niin pitää syyllisen sammutettuna, käy tekemässä bugi-ilmoituksen ja odottaa uutta versiota. Jos lisäosa/teema on pakollinen sivuston toimivuudelle, niin sitten on vaihtoehdot hyvin rajalliset: asennetaan vanha versio takaisin.
Tuohon on olemassa lisäosa. Itselläni on siitä vain huonoja tai hyvin huonoja kokemuksia, mutta aika moni sanoo saaneensa sen avulla avun. Se on yksi vaihtoehto, jos backend toimii. Mutta jos admin-sivuille ei pääse, niin ei siinä paljoa lisäosat auta.
https://fi.wordpress.org/plugins/wp-rollback/
Rollbackissä on yksi ongelma. Se täytyy olla päällä koko ajan ja toimii käytännössä vain yleisesti saatavien versioiden kanssa. Ostetuissa lisäosissa ja teemoissa on syytä olla itsellä tallella vähintään viimeinen toimiva versio. Kun tekijä tuo saataville uuden version, niin lähes aina vanha versio poistuu. Ainoa tapa ladata se, on pyytää tekijältä. Kokemuksesta väitän. että melkoinen osa ei vastaa koskaan ja ne jotka vastaavat, reagoivat viiveellä. Ja auta armias, jos jokin hajoaa perjantaina… silloin alkaa tapahtumaan aikaisintaan maanantaina.
Jos saisin päättää, niin ainoat sallitut päivät julkaista päivitys on maanantai tai tiistai ja silloinkin vain aikoina, jolloin julkaisijalla ei ole pyhäpäiviä tai lomakautta.
Yleensä vanha versio on löydettävissä backupeista. Joten hyödynnä siitä – ja säilytä useampi, ei ne niin paljoa maksullista tilaa vie.
WP-CLI pystyy myös palauttamaan vanhan version. Hankaluus tulee siinä, että sinun pitää tavalla tai toisella tietää mikä se edellinen versio oli. Siihen on usein helpoin käyttää listausta, jonka nimi changelog. Toinen tapa on etsiä version history. Löydät sen useimmiten lisäosan tai teeman sivuilta, google on ystäväsi.
Jos palautat vanhempaan versioon jotain yleisesti saatavaa, niin se onnistuu periaatteessa aivan samalla tavalla kuin päivittäminen, mutta annetaan versionumero:
wp plugin update gutenberg --version=6.1.0
Jos olet poistanut pluginin, niin voit asentaa ja aktivoida sen samalla tavalla.
wp plugin install gutenberg --version=6.1.0 --activate --force
Jos sinulla on vanhemman version zip-paketti tallella, niin tipauta se web-sivun juurihakemistoon ja komenna:
wp plugin install gutenberg.6.1.1.zip --activate --force
Ja jos haluat ensin varmistua, että kaikki on menossa niin kuin olet ajatellut, niin laita loppuun --dry-run niin näet mitä saat vastaukseksi, jos asentaisit oikeasti.
WordPressin downgrade
Olen joutunut joskus aikoja sitten tilanteeseen, jossa WordPressin päivitys rikkoi koko systeemin. SIlloin ei ollut erillisiä työkaluja edes yrittää palautusta ja ylipäätään backup oli niin työlästä, ettei sitä tullut tehtyä. Lopputulos oli, että rakensin koko sivuston uusiksi tietokantadumpista kopypeistaamalla. Onneksi ei ollut kuin muutama sata artikkelia, mutta jos nyt joutuisin samaan tilanteeseen, niin antaisin olla. Sen verran surkea urakka se oli.
Nykyään vastaavaa ei pitäisi sattua, mutta toisaalta – Suomessa pitäisi olla uusi toimiva ydinvoimala ja halvempi metro pääkaupunkiseudulla, mutta ei ole. Kaikki on siis mahdollista.
Jos WordPressin päivitys rikkoo itse järjestelmän, niin oikeastaan ainoa järkevä liike on palauttaa koko sivusto backupeista. On olemassa yksi edes siedettävän hyvin toimiva backrollaaja WordPressille, kunhan muistaa ensin poistaa käytöstä kaikki lisäosat. Kysymys on vain siitä, että sen käyttö edellyttää pääsyä WordPressin hallintaan. On hyvinkin oletettavaa, että jos WordPress menee niin rikki päivityksessä, että sen palauttaminen edelliseen versioon kannattaa, niin silloin ei edes pääse hallintaan.
Yksi vaihtoehtoinen skenaario on, että WordPressiin tulee huomattavan iso major-päivitys, että se itse sinällään toimii, mutta lisäosat ei. Ja varmuus konfliktista tulee hivenen liian ,myöhään ja esimerkiksi verkkokauppa on silloin myynyt jo sen verran, että palautus päivän tai päivien vanhaan tietokantaan ei ole mahdollista.
Fiksuhan hoitaisi tilanteen stage-sivustolla ja testaamalla päivityksen, ennen kuin päästää sen tuotantoversioon. Mutta tuo on isojen poikien pelikenttää ja heillä on omat työkalunsa korjata asioita. Eli se palkattu IT-osasto.
Stagessa on sama ongelma kuin 10 vuotta sitten backupeissa. Moisen toteuttaminen niin, että se on helppo hallita tai olisi edes toimiva, on niin työlästä, että harvempi sitä tekee. Maksullisten lisäosien toimimattomuus on tolkuttoman iso hidaste. Mitä tekee kehitysversiolla, jos aito klooni ei toimi siinä? Toki yksi mahdollisuus on ostaa useamman lisenssin sopimus, mutta aidosti tuo on melkoisen kallis vakuutus sille, että jos vaikka WordPress hajoaa.
Itselläni on WP Staging Pro sekä testimielessä rakennettu viritelmä toiseen DigitalOceanilla olevaan dropletiin. Ensimmäistä käytän erilaisiin teemakokeiluihin, eikä siitä ihan äkkiä olisi palautettavaksi versioksi. DO:n systeemi ei ole automatisoitu jatkuvasti ajantasalla oleva peilaus, mutta suunnittelen sitä sellaiseksi – mutta paljon sekin auttaisi, jos varsinainen versio menee rikki ja se kopioituu heti varaversioon.
Mutta jos sinulla on tarvetta yrittää downgradeta WordPress vanhaan versioon, niin kokeile tätä:
https://wordpress.org/plugins/wp-downgrade/
Sen sijaan jos sinulla on WP CLI käytössä, niin palauttaminen WordPressin vanhempaan versioon on huomattavan helppoa. Se tapahtuu aivan samalla tavalla kuin rollaaaminen vanhempaan lisäosan versioon, mutta komento tehdään corelle. Komennat vain:
wp core update --version=5.2.2
Ainoa asia, joka sinun täytyy tietää, on vanha versionumero, jonka vaihdat esimerkissä olevan 5.2.2 tilalle. WordPressin versiot löydät Codexista.