WordPressin päivittäminen on helppoa. Painat nappulaa ja se siitä. Plugineissa on kovempi työ. Täytyy rastittaa päivityslistasta ne, jotka haluaa päivittää. Kun tuolla kokemuksella siirtyy Moodleen, niin meinaa tulla itku. Ainoastaan lisäosien päivitys on joltisenkin inhimillistä, mutta siinäkin mennään parin mutkan kautta. Jos on ostanut teeman, niin päivitys edellyttää, että poistetaan asennus, asennetaan uusi versio ja käydään Moodlelle kertomassa missä yhteyksissä teemaa saa käyttää. Mutta Moodlen oman version päivitys… se onkin oma tarinansa.

Ohjeet ovat hyvin yksinkertaisia. Päivitä systeemi

• Moodlen oman CLI:n, komentorivin, kautta
• päivitä käyttämällä git:iä
• lataa Moodlen uusi versio ja kopioi paikalleen

Tuo kaikki on periaatteessa aika suoraviivaista. Suoraviivaisuus vain loppuu siihen, kun ohjeet toteavat kuinka päivitys tapahtuu sekunneissa ja sitten ei tarvitse kuin yksitellen palauttaa paikalleen jokainen asennettu lisäosa ja teema. Kun tuota alkaa tekemään FTP:llä yrittäen selvittää missä hakemistossa mikäkin lisäosa piilee, niin aikaa kuluu tunti poikineen; kahvia palaa ja tupakkaa meni kuppi tolkulla.

Ongelma on siinä, että yhdessäkään webin ohjeessa ei kerrota, miten hakemistojen ja tiedostojen kopiointi kuuluu tehdä. Usko pois, olen taatusti mennyt melkoisen osan webin tarjonnasta, jotka ovat toinen toisiaan kopioivoa juttuja. Itse asiassa uskon, että valtaosa juttujen kirjoittajista ei ole eläessään tehnyt sitä mitä neuvovat.

Siihen on olemassa helppo keino. Ehkä se sitten on niin simppeliä perusasiaa, että kaikki muut tietävät sen, mutta minä en. Käytetään joko cp-komennolla oikeaa vipua, tai otetaan työkalupakista esille rsync.

Mennään vaihtoehdot läpi. Ja taas kerran: kaikki esimerkit ovat root-tunnuksella. Muista sudo tai su, jos root ei ole sinulle vaihtoehto.

Tee varmuuskopio

Tietokannasta varmasti ajatkin kopioita säännönmukaisesti, ja luultavasti koko kurssirakenteestakin. Niistä palauttaminen on vaan hieman työlästä ja kun ollaan tilanteessa, että juuri nyt ja tässä pitää palauttaa tilanne, joka oli ennen päivitystä, niin ns. virallisten backuppien käyttäminen ei ole fiksuinta. Kokeile joskus palauttaa niistä, niin tiedä mikä on työmäärä ja paljonko aikaa palaa.

Minä olen DigitalOceanin asiakas, joten otan koko serveristä snapshotin. Jos homma menee pieleen, niin palautan siitä koko serverin tilanteeseen ennen päivitystä. Tuo ei tietenkään toimi, jos samalla lohkolla toimii vaikka aktiivinen verkkokauppa ja kommentointeja keräävä blogi. Minulla on pelkästään Moodle, niin ongelmaa ei ole.

Ennenkuin päivität, niin laita Moodle aina huoltotilaan. Toki sillä on merkitys käyttäjäystävällisyydenkin kanssa, mutta suurin syy sillä on siinä, että aina joskus hajoaa evästeet ja pari muutakin session-juttua, ja jopa admin jää rannalle ruikuttamaan yrittäessään kirjautua.

Tee tietokantadumppi.

mysqldump --allow-keywords --opt -uroot -p TIETOKANTA > TIETOKANTA.sql

Kopioi Moodlen hakemisto johonkin turvaan.

mkdir /var/www/moodle.bak

rsync -avh /var/www/html/ /var/www/moodle.bak/

Jos sinun täytyy palauttaa, niin poista vanha hakemisto.

[bash]rm -rf /var/www/html

mkdir /var/www/html

Palauta tietokanta.

cd /var/www

mysql -u root -p TIETOKANTA < TIETOKANTA.sql

Jos sinun milloinkaan täytyy siirtää esimerkiksi backup-hakemisto niin, että siirretään vain sellaiset tiedostot ja hakemistot, joita ei kohteesta löydy, eli ei ylikirjoiteta olevia, niin se onnistuu tällä:

rsync -av --ignore-existing lähde/ kohde/

Lataa Moodle ja asenna

Tämä on vähiten tekniikkaa vaativa tapa päivittää Moodle. Teen sen ehkä parin turhan mutkan kautta, mutta tunnen olosi turvallisimmaksi niin.

Tehdään ensin hakemisto Moodlen päivityspaketille.

cd /var/www

mkdir update

Siirretään päivitys. Kun Moodlessa Sivuston hallinta > Ilmoitukset kertoo päivityksestä, niin siinä on mukana myös linkki. Kopioi se – hiiren oikea korva on kaverisi. Esimerkki toimii niin kauan kun ollaan 3.8.x sarjassa – tosin, jos logiikka ei muutu, niin osannet hahmottaa mitä kuuluu versiokohtaan laittaa. Jotta Moodlen kehittäjäporukat eivät tekisi elämästä liian helppoa, niin uuden sarjan aloitus nimetään sen sijaan malliin moodle-latest-39.tgz – tosin, ensimmäistä versiotahan ei koskaan kannata asentaa (paitsi jos teet neitseellistä asennusta).

cd /var/www/update

wget https://download.moodle.org/download.php/direct/stable38/moodle-latest-3.8.1.tgz

Puretaan paketti.

tar xvzf moodle-latest-3.8.1.tgz

Poistetaan vanha versio – olethan tehnyt varmuuskopion jonnekin muualle, olethan… ja kuten aina rm -rf komennon kanssa, niin tarkistetaan mitä poistetaan ja mistä, se ei varoittele.

 rm -rf /var/www/html

Tehdään html-hakemisto uudestaan:

mkdir /var/www/html

Kopioidaan uusi versio. Rsyncissä piste tarkoittaa hakemistoa, jossa ollaan. Ei sinun ole mikään pakko aina siirtyä hakemistoihin, kunhan muistat vaan aina laittaa kaikkeen polun.

cd /var/www/update/moodle

rsync -avh . /var/www/html/

Kopioidaan vanhan version varmuuskopiosta tyylit, lisäosat ja muut asiat, jotka eivät tule uuden paketin mukana:

rsync -av --ignore-existing /var/www/moodle.bak/ /var/www/html/

Siirry Moodleen ja hoida päivityksen vaatimat asiat kuntoon, eli painelet ok:ta, annat tehdä muutokset tietokantaan jne. Käy katsomassa, että paikat ovat suunnilleen kunnossa ja ota huoltotila pois päältä. Päivitys on valmis.

Siivotaan vielä tehdyt backupit ja väliaikaishakemistot. Ja kuten aina, niin rm -rf komennon kanssa ollaan hereillä, että se kohdistuu oikeaan hakemistoon.

cd /var/www

rm -rf update/

rm -rf moodle.bak/

rm tietokanta.sql

Suunnilleen seuraavan päivänä tuhoan DigitalOceanissa olevan snapshotin. Ihan siksi, että tikittää euroja laskutukseen koko ajan.

Mixed Moodle versions detected, upgrade cannot continue

Moodlen uuden version jälkeen saatat saada otsikon mukaisen tylsän ilmoituksen. Minulle se on tullut aika säännöllisesti, kun olen siirtynyt aina suurempaan versioon, kuten vaikka muutto versiosta 2.x versioon 3. Mutta sain saman myös vaihtaessani versiosta 3.7 versioon 3.8.

En ole keksinyt mitään keinoa kiertää tuota, vaan olen aina joutunut menemään ns. pitkän kaavan mukaan.

1. Siirrä FTP:llä tai shellissä oleva asennus johonkin muualle turvaan
2. Laita paikalleen uusi Moodlen versio edellä olevia ohjeita mukautten
3. Kopioi takaisin config.php
4. Mene selaimella Moodlen admin-hakemistoon https://www.domain.tld/admin/ ja aloita päivitys
5. Kun pääset lisäosakohtaan, niin ohita ilmoitukset puuttuvista lisäosista ja käske päivittää Moodlen tietokanta. Voit toki antaa Moodlen päivittää sellaiset puuttuvat lisäosat, joihin löytyy päivitys, koska silloin ne asennetaan takaisin. Jos sinulla näkyy vain painonappula download, eli ei ole kohtaa install per puuttuva lisäosa, tai sinulla ei ole vastaavaa ”massa-asennus” valintaa ennen lisäosalistaa, niin Moodlen hakemiston oikeudet kannattaa vaihtaa: chmod -R 777 /var/www/html
6. Kun päivitys on valmis ja olet Moodlen hallinnassa, niin mene valikkokohtaan sivuston hallinta > Moduulit > Moduulien yhteenveto. Löydät punaisella merkittynä puuttuvat lisäosat.
7. Vaihda sivuston kieli englanniksi
8. Puuttuvan lisäosan hakemistosta saat vinkin sen suhteen minkä otsikon alla se on, ja moduulin varsinainen hakemisto on sen nimen mukainen ilman mod_ tai vastaavaa etuliitettä. Joskus etuliite kertoo missä alihakemistossa se on. Kun olet löytänyt vanhasta asennuksesta oikean kansion, niin kopio se uuteen vastaavaan paikkaan. Joskus joutuu hieman penkomaan mistä mikäkin löytyy, kuten että editorin Atto pluginit löytyvätkin hakemistosta lib/editor/atto/plugins, koska lib ei näy nimissä. Näppärä tekee tuon komentorivillä, mutta minä luotan FTP:hen.
9. Päivitä Moodlen tietokanta, kun sitä pyydetään

Jostain syystä rsync ei ole koskaan toiminut – ehkä minulla on väärä komento ja saa vinkata kommenteissa toimivan. Ja kyllä, olen sitä mieltä, että Moodlen päivittäminen on niin syvältä varhais-keskiajalta, että ei mitään määrää. Sama koskee montaa muutakin Moodlen teknistä ratkaisua, kuten niinkin perusasiaa kuin kääntäminen omalle kielelle, mutta se onkin oman juttunsa aihe.

Moodlen päivitys: CLI ja git

Suomi on rikas kieli, mutta aina välillä englannin vaihtelevuus ylittää ensimmäisen kotimaisen.

• update on olemassaolevan päivitys, esimerkiksi 3.7.1 sisällä tai siirtymistä 3.7.2
• upgrade on päivitystä uudempaan ”pääversioon”, kuten muutos 3.7 > 3.8

Mitään muuta syytä sille, että en ole koskaan onnistunut päivittämään Moodlea CLI:n kautta tai git:llä, ei keksi. Kun Moodle kertoo, että on tullut uusi versio, niin kumpikin tapa loihtii, että kaikki on hienosti ja Moodle on ihan ok. Ja edelleen admin saa urputusta, että voisi tämänkin päivittää.

Mutta mennään nämäkin läpi, koska Moodlen oma dokumentaation kautta nämä ovat kaikista tehokkaimpia, nopeimpia ja turvallisimpia tapoja. Nopeita taatusti, koska mitään ei ole koskaan tapahtunut.

CLI

CLI (command line interface) tarkoittaa komentoliittymää. Itseasiassa kun mennään PuTTY:llä (tai iPadillä/iPhonella Blink, joka on kallis, mutta kannattava hankinta) hallintaan, niin käytössä on CLI. Joten CLI tunnetaan myös nimillä shell, konsoli, terminaali, komenrivi tai SSH (joka on kylläkin vain protokolla, jolla tietoa siirretään).

CLI on kuitenkin muuttunut tarkoittamaan määrätyn ohjelman omaa komentoriviltä ajettavia asioita. WordPressissä sellainen on WP-CLI ja Moodlessa CLI löytyy admin-hakemiston takaa, jokainen komento eri paikasta – mitä sitä asioita helpoksi tekemään. Esimerkkejä CLI:n käytöstä löydät moodle.org -sivustolta.

Moodlen CLI-komennot ajetaan sitten web-serverinä. Joten alkuun aina

sudo -u www-data

(tai esim. apache, riippuen järjestelmästä), vaikka olisikin root-tunnuksella liikenteessä.

Jos yrität päivitystä tätä kautta, niin laitetaan ensin Moodle huoltotilaan, jos et ole sitä jo tehnyt.

cd /var/www/html

sudo -u www-data /usr/bin/php admin/cli/maintenance.php --enable

Haetaan päivitys.

git pull

Tuosta seuraan kaksi vaihtoehtoa, ainakin minulle:

• Jos ja kun sinulla ei ole git-repoa asennettuna, niin ei onnistu:

fatal: not a git repository (or any of the parent directories): .git

• Ja tähän kohtaan minulla aina homma pysähtyy, vaikka git olisikin käytössä;

Already up to date

Tarkoittaa sitä, että Moodlen kehuma CLI:llä päivitys itseasiassa on vain git:n laajennos.

Seuraavia en ole koskaan itse kokeillut, vaan mennään Moodlen dokumentaation mukaan. Ehkä sinulla onnistuu.

Jos git ei saa haettua mitään, niin syy saattaa olla, tai olla olematta, että sinulla ei ole sopivaa porttia auki. Aukaistaan se palomuuriin.

ufw allow 9418

Toinen vaihtoehto olisi, että sinun pitää ensin asentaa git-klooni. En tiedä, koska minulla on aina ollut git roikkumassa mukana, eikä dokumentaatio kerro.

Asennetaan päivitys.

sudo -u www-data /usr/bin/php admin/cli/upgrade.php

Poistetaan huoltotila.

sudo -u www-data /usr/bin/php admin/cli/maintenance.php --disable

Nyt sinulla sitten pitäisi olla päivitetty versio Moodlesta. Kannattaa käydä adminina vilkaisemassa onko urputus päivityksestä hävinnyt.

Git

git on omituinen systeemi, joka on taatusti hyödyllinen, jos kehittää jotain. Yksinkertaistaen siinä käydään Moodlelta hakemassa kaikkien versioiden kaikki tiedot omalle koneelle ja sitten päivitellään.

Sama juttu tässäkin. En ole koskaan onnistunut aidosti tekemään päivitystä, mutta ehkä sinulla on parempi tuuri. Tai ymmärrät enemmän.

Git:iä voi käyttää joko suoraan omanaan, jos pystyy vaikuttamaan serverin portteihin. Jos ei pysty, niin sitten käyttää http-versiota. Mutta aukaistaan git:lle reitti ulkomaailmaan.

ufw allow 9418

Ruvetaan töihin, sillä ensin täytyy ottaa git käyttöön.

cd /var/www/html

Kloonataan koko Moodlen versiohistoria. Se laitetaan uuteen alihakemistoon moodle. Sen nimi on sitten ihan oikeasti moodle, eli se ei ole mikään esimerkinomainen kuten websaittisi juurihakemisto /var/www/html – jos muuten koskaan Let’s Encrypt tai mikään muu haluaa tietää mikä on webroot niin se on juurikin se hakemisto, jossa sivustosi on, kuten esimerkiksi tällä sivustolla se on /var/www/eksis.one/public_html.

git clone git://git.moodle.org/moodle.git

Jos sait ilmoituksen connection refused, niin git ei saanut yhteyttä portin 9418 kautta tai jokin muu hakkaa vastaan. Kokeile silloin http:tä.

git clone

https://github.com/moodle/moodle.git

Siirtoon menee oma aikansa. Minulla meni ehkä puoli minuuttia, en kellottanut. Kun se on valmis, niin siirrytään äsken luotuun hakemistoon.

cd moodle

Halutessasi voit listata mitä siirtyi, mutta pakko ei ole.

git branch -a

Nuolella pääset listaa alaspäin ja q päästää sinut pois.

Jos oikein olen ymmärtänyt, niin nyt luodaan paikallinen haara versiolle ja synkataan se kloonin kanssa. Joten kun git päivittää version, niin muutokset siirretään tähän. Koska versionumerot muuttuvat ajan mukaan, niin totta ihmeessä muutat tämän sopivaksi – nimeämislogiikka on selvä. Sitä en sitten tiedä, että jos haluaa päivittää Moodlen ns. isompaan versioon, niin riittääkö, kun ajaa tämän uudestaan, mutta uudelle versiolle.

git branch --track MOODLE_37_STABLE origin/MOODLE_37_STABLE

Sitten kytketään edellä tehty käyttöön.

git checkout MOODLE_37_STABLE

Mitään ei ole vielä päivitetty. Tai sitten on, mutta ei ainakaan live-versiota. Kaikk

Päivitysten ajaminen on helppo homma.

Mennään git-hakemistoon (nyt jo ollaan siellä, mutta tulevaisuudessa tuskin näin on).

cd /var/www/html/moodle

git pull

Ja tässä kohtaa aivan kaikki dokumentaatiot totevat intoa puhkuen, että nyt on päivitys tehty, maailma hymyilee ja pallokin on pyöreämpi. Paitsi että ei ole. Hakemistossa /var/www/html/moodle oleva kopio on ehkä päivitetty, mutta se ei ole sama kuin live-versio.

Ongelma on taas kerran kahdessa:

• git on tyytyväinen versioon, jonka Moodle kuitenkin haluaisi päivittää
• dokumentaatio ei kerro missä hakemistossa aidosti git pull kuuluisi ajaa

Ohjeet sanovat, että siirry hakemistoon /path/to/your/moodle/ komentamaan git pull. Aiemmin samoissa ohjeissa se on tarkoittanut git:n luomaa moodle-hakemistoa web-juuren alle. Mutta toisaalla se tarkoittaa myös hakemistoa, johon Moodle on asennettu. Ota näistä sitten selvää, mutta minulle riittää se, että koskaan en ole onnistunut saamaan aikaiseksi sellaista, johon toimiva Moodle olisi ollut tyytyväinen – paitsi tekemällä päivityksen käsin ensimmäisen ohjeen mukaan.

Mutta jos haluat siirtää moodle-hakemistossa olevan version liven päälle, niin se onnistuu rsyncillä.

rsync -avh /var/www/html/moodle/ /var/www/html/

Ainoastaan muuttuneiden tiedostojen pitäisi päivittyä, joten config.php ja omat lisäosat sekä tyylit säilyvät.

Kun ei onnistu

Olen aina onnistunut viimein päivittämään järjestelmän, vaikka välillä siihen on kulunut aikaa, kahvia, tupakkaa ja hermoja. Kunhan pitää huolen siitä, että vanhan version varmuuskopio – niin hakemistot kuin tietokantakin – ovat aina koskemattomina tallessa. Joten jos joudut siirtämään käsin moduuleita vanhasta uuteen, niin tee vanhasta toinenkin kopio, että sinulla on taatusti toimiva versio tallessa.

Useimmiten ongelmat tulevat päivityksen jälkeen. Sivusto on pyllyllään, ei pääse kirjautumaan, ulkonäkö on rikki tai lisäosat eivät toimi. Minulle on käynyt aivan jokainen kerta noin isommissa päivityksissä – version sisällä pienet päivitykset ovat taasen aina toimineet. Siitä huolimatta yritin päivittää versiosta 3.7.x versioon 3.8, koska uusi versio oli jo pari kuukautta vanha. Tein kaksi virhettä:

• en käynyt katsomassa Moodlen foorumilta mitä ongelmia ihmisillä on ollut
• en odottanut versioon 3.8.1

Aivan kuten WordPressin kanssa, niin Moodlea ei päivitetä koskaan ensimmäisten joukossa, ellei päivityksen luvata korjaavan jonkun elämääsi vaikeuttavan virheen.

Niin tai näin, niin Google tulee erittäin tutuksi, kun etsii Moodleen ratkaisuja. Ongelma on siinä, että ratkaisuja löytyy turhan vähän. Liian moni Moodle-asennus on isoissa taloissa, kuten korkeakouluissa, joten heillä on aivan toisenlaiset resurssit eikä tarvetta jakaa ratkaisujaan julkisesti.

Sanon taas kerran. Jos sinulla ei ole aikaa ja kykyjä omatoimiseen ongelmien ratkomiseen, niin älä asenna Moodlea.