Komentorivillä työskentely on aina nopeampaa kuin graafisella puolella, jos osaa komennot. Jos pitää siirtää jotain, niin rsync, curl ja wget ovat aina huomattavasti nopeampia kuin FTP. Terminaali, tai yleisemmin se varmaan tunnetaan nimellä shell, mahdollistaa myös sovellustasollakin usein asioita, joita ei pysty tai kannata tehdä HTML-puolella. Yksi tällainen on WordPress ja sille rakennettu komentorivipuoli WP-CLI. Se ei tule WordPressin mukana oletuksena, kuten Moodlessa heidän CLI, mutta ehkä joskus. WP-CLI nimittäin helpottaa määrättyjä rutiinihommia plus saattaa auttaa kun WordPress kaatuu.

Lyhyesti mainoslauseen mukaan, niin WP-CLI mahdollistaa komentoriviltä aivan kaiken saman kuin mitä WordPressin hallinta sallii adminille. Ja siihen vielä osan lisäosien tuomat mahdollisuudet päälle.

Itse kokeilin WP-CLI:n käyttöä asentaessani uuden WordPressin. Ei sen asentaminen suunnattoman työlästä ole perinteisinkään tavoin, mutta WP-CLI helpotti ja nopeutti, varsinkin kun se teki tietokannan ja asetti wp-config.php -tiedoston lennossa. Mutta ensimmäisen kerran koin sen aidosti hyödylliseksi, tai ainakin elämää helpottavaksi, yhden huonosti käyttäytyneen lisäosan kanssa, joka kaatoi koko asennuksen. Ennen avasin FTP:n, kirjauduin sisälle, hain esille pluginit ja poistin lisäosan. Nyt tein saman komentorivillä sekunnissa.

Minulla on muutama vieraan ihmisen WordPress-asennus omalla serverillä. He eivät päivitä järjestelmäänsä riittävän usein. Minulla ei ole pääsyä heidän sivustolleen, joten oman serveriturvallisuuteni nimissä päivitän lisäosat ja teemat WP-CLI:n avulla.

Aidosti käytännön tasolla tuo vaati turhan pitkän komentorotlan. Jos se pitäisi aina muistaa kirjoittaa, niin jäisi tekemättä. Siksi kopypeistaan. Joku fiksumpi tekisi bash-skriptin tai hyödyntäisi jotain alias-systeemiä, mutta minä en osaa. Mutta ylipäätään pitkät komentorivit koskevat kaikkia CLI-hommia, ja ovat myös suurin syy miksi hitaammat graafiset ympäristöt myyvät niin paljon paremmin.

WP-CLI ja asennus

WP-CLI ei asennu suoraan, koska sillä ei ole omaa repoa, eikä se löydy muistakaan. Mutta ei WP-CLI:n asentaminen mitenkään tuskaakaan ole. Ja taas olen root-tunnuksella liikkeellä. Joten sudo tai su on suotavaa, jos sinä et ole.

• Ensin haetaan paketti.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

• Testataan, että se tuli ehjänä perille.

php wp-cli.phar --info

• Jos saat järkevän näköistä syötettä, et virheilmoja, niin tehdään siitä ajettava ohjelma.

chmod +x wp-cli.phar

• Jotta sen saisi ajettua sellaisenaan, ilman polun antamista, niin siirretään se sellaiseen paikkaan, että löytyy.

mv wp-cli.phar /usr/local/bin/wp

Se oli siinä. Nyt antamalla komento wp plus määritteet perään, niin saat tehtyä kaikennäköistä WordPressille. Kokeillaan kuitenkin, että asennus toimii:

wp --info

Ainakin periaatteessa WP-CLI on nyt asennettu.

Webhotellit

Periaatteessa WP-CLI vaatii virtuaaliserverin ja root-oikeudet. Mutta vain periaatteessa. Jos webhotellisi tarjoaa sinulle SSH-yhteyden, niin täällä on asennusohjeet, jossa ei tarvita root-oikeuksia.

Jos sinulla ei ole pääsyä shelliin, komentoriville, niin et tietenkään voi käyttää WP-CLI:tä, koska se on komentorivilaajennus.

Useampi käyttäjä

WP-CLI:n logiikka käyttäjien suhteen on hieman omituinen, ainakin minulle. Toisaalta se sallii erilaiset asetukset käyttäjille. Varsinainen WP-CLI on tietysti kaikkien käytössä, koska se on /usr/local/bin hakemistossa. Mutta siihen yhtäläisyydet sitten loppuivatkin.

Aliakset ovat oikopolkuja eri WordPress-asennuksiin, eli sivustojen hakemistoihin. Ne ovat täysin käyttäjäkohtaisia. Toisaalta ihan loogista, koska käyttäjillä voi olla erilaisia oikeuksia päästä käsiksi eri sivustoihin. Aliakset löytyvät jokaisen kotihakemistossa olevan piilokansion takaa tiedostosta config.yml, joka on globaali asetustiedosto. Joten jos haluat sallia samat aliakset niin rootille kuin omalle tunnuksellesi, niin kopioi alias-tiedostot sinne. Silti on muistettava, että WP-CLI ja alias-lista eivät pysty ylittämään linuxin tiedosto-oikeuksia.

Tarkoittaa sitä, että se oma tunnus on oltava ainakin

• sudo-kelpoinen
• kuulua www-data -ryhmään (tai apache RHL-pohjaisissa)
• /var/www/html ei saa olla rootin omistuksessa, vaan www-data; et pysty siirtymään hakemistoon sudo komennollakaan, jos omistaja on root

Joten muistuksena.

• Sudo: kirjaudu rootina ja komenna

usermod -aG sudo tunnus

• Ryhmä: kirjaudu omalla tunnuksella ja komenna

sudo usermod -aG www-data $USER

Hakemisto: muutetaan omistajaksi ja ryhmäksi www-data:

chown -R www-data:www-data /var/www/html

Pystyt tarkistamaan mm. omistajuudet:

ls -li /var/www

Laajennukset (packages) ovat toinen ongelmallinen asia. Ne asennetaan aina käyttäjän kotihakemistoon ~/.wp-cli/packages/ . Koska kotihakemistot ovat, tietysti, käyttäjäkohtaisia, niin myös asennetut laajennukset ovat käyttäjäkohtaisia. Joskus tuo on haluttua, mutta jos serverillä hääräävät vain sinä ja oma root-tunnuksesi, niin on hieman liioittelua asentaa kaikki tuplasti. Tuon ratkaisuun on kaksi vaihtoehtoa.

Voit ohittaa WP-CLI:n normaalin toiminnan ladata käyttäjän kotihakemistosta.

nano /etc/environment

Lisää tämä:

export WP_CLI_PACKAGES_DIR=/usr/local/lib/wp-cli-packages

Jos olen oikein ymmärtänyt, niin laajennukset ovat kaikkien käytössä, mutta vain root voi asentaa niitä.

Tätä toiSTA tapaa en ole kokeillut, mutta sen pitäisi sallia niin yhteiset kuin henkilökohtaisetkin. Lue ohjeet täältä.

WP-CLI:n päivittäminen

WP-CLI ei päivity serverin normaalien apt update ja apt dist-upgrade kautta. Se täytyy erikseen muistaa päivittää.

Tämä asentaa viimeisen stable-päivityksen.

wp cli update

Jos haluat asentaa kaikista tuoreimman version ja ottaa riskin satunnaisista bugeista, niin komenna tämä.

wp cli update --nightly

Nyt täytyy muistaa, että kumpikaan ei asenna mitään automatiikkaa. Uusien päivitysten suhteen on muutama vaihtoehto.

• käydä vilkaisemassa täältä koska uusi versio on tullut
• laittaa Twitterissä seurantaan @wpcli
• tilata uutiskirje (jota itse en ole koskaan onnistunut tekemään, aina tulee virhe)
• tehdä cron

Itse asensin cronin. Minua ei kiinnosta mitkään nightly build kehitysversiot ja uusi stable-versio tulee harvakseltaan muutaman kerran vuodessa, niin cron komentaa päivityksen kerran kuukaudessa. Tämä yrittää asentaa uusimman vakaan version joka kuukauden 15. päivä puoleltaöin.

crontab -u root -e

0 0 15 * * wp cli update --stable --yes --quiet >dev/null 2>&1

• --stable huolii vain uusimman vakaan version
• --yes vastaa kysymyksiin kyllä
• --quiet ei näytä turhia tekstejä (aidosti en tiedä onko tämä oleellinen)
• >dev/null 2>&1 estää turhat ilmoitukset sähköpostiin; kaksipiippuinen juttu, koska tämä ajetaan niin harvoin

Löydät kaikki update -komennon määritteet täältä.

WP-CLI ja käyttö

Löydät kaikki oleelliset asiat näistä osoitteista:

• Komennot
• Quick start
• Shell friends: Esimerkkejä
• Asennusvaihtoehdot, jos täällä tarjottu ei toimi

Tutustu ja kokeile, se on paras tapa oppia.

Se, mikä oletetaan kaikkien oivaltavan, on että WP-CLI täytyy ajaa siinä WordPress-hakemistossa, johon sen toimet kohdistuvat. Eli /var/www/html hakemistossa ei voi ajaa asiaa, joka pitäisi suorittaa hakemistossa /var/www/example.com/html majailevaan toiseen WordPress-asennukseen.

Dokumenttien mukaan voidaan antaa polku käyttämällä vipua --path='var/www/html' mutta en ole saanut sitä toimimaan koskaan missään. Aina tulee virhe:

Error: This does not seem to be a WordPress installation. Pass --path=`path/to/wordpress` or run `wp core download`.

wp core download on ehdotuksena sarjaa aika turha idea. Se nimittäin lataa WordPressin. Ihan hyödyllinen uusasennuksissa, mutta kun yrittää asentaa vaikka jonkun lisäosan ja polku ei ole tiedossa, niin tuon tarjoaminen maallikolle on hyvin lähellä vittuilua.

Root

WP-CLI ei ole ollenkaan ilahtunut, jos on root-tunnuksella kirjautuneena konsolissa. Ja kaikkien kontrollifriikkien tapaan WP-CLI ei anna edes vaihtoehtoa sallia rootia pysyvästi. Tuohon on kuulemma ihan pätevä syy ja se perustuu WP-CLI:n tapaan käsitellä mm. wp-config.php -tiedostoa. Se sallisi hyökkääjän toimia root-tunnuksilla, silloin kun wp-komento ajetaan, jos on onnistunut wp-config.php:n miinoittamaan. On siis laitettava komentoon mukaan aina –-allow-root. Tuo on ihan pahuksen ärsyttävää.

Rootina shellissä ollessa pitäisi ajaa wp jonkun käyttäjän tunnuksilla. Silloin komennettaisiin ensimmäisellä kerralla:

sudo -u www-data -i -- wp komento

Paitsi että se ei toimi. Täytyy olla joku muu tunnus, kuten se ”oma”. Ongelmantynkää on siinä, että jos asentaa jotain, niin silloin muutetaan siltä osin niin tiedoston kuin mahdollisen hakemiston omistajuus sille tunnukselle pois www-data alta.

Yritin googlettaa miten tuo ratkaistaan, sitä ovat nimittäin muutkin kyselleet. Vastaukset ovat juuri sitä laatua, minkä takia puolittain vihaan koodareita:

• root-tunnuksella WP-CLI:n ajaminen on vaarallista; juujuu, mutta kun nyt kysytäänkin miksi tunnus www-data ei toimi
• kyseessä on yleinen ympäristöön kuuluva asia, ei WP-CLI -spesifinen, joten selvitä muuta kautta

Anteeksi, mutta haistakaa pitkät.

Joten kierretään tuo, turvatonta tai ei.

nano ~/.bash_aliases

alias wp='wp --allow-root'

Annetaan komento . ~/.bashrc , niin root-tunnuksesta urputus loppuu. Täältä voit lukea lisää aiheesta bash ja aliakset – niistä on nimittäin jelppiä huonomuistiselle.

Multisite

WP-CLI on multisite -yhteensopiva. Mutta saada tarvittaessa komento osumaan oikeaan sivustoon, vaatii yhden vipstaakin lisää. On annettava URL.

wp --url=blog.example.com
wp --url=www.example.com/blog

Muutama esimerkki

Oletuksena wp tekee töitään kuin uloskirjautunut tuntematon käyttäjä. Minulle ei ole ihan selvinnyt, että miten uloskirjautunut voi esimerkiksi asentaa lisäosia, mutta ilmeisesti olen ymmärtänyt jotain väärin. Mutta jos on tarvetta komentaa jotain kuin sen tekisi aito käyttäjä, niin se onnistuu. Tämä saattaa olla pieni turvallisuusongelma, joka kannattaa pitää mielessä.

• Saat täydellisen listan käyttäjätunnuksista ja sähköpostiosoitteista

wp user list

• Asennetaan ja otetaan käyttöön lisäosa

Asensin serverille Redisin. Yksi siellä majaileva domain ja sen WordPress-asennus ei ole minun hallussani, enkä saanut keskellä yötä sen ylläpitäjää kiinni. Olisi nimittäin pitänyt asentaa Redis Object Cache -lisäosa ja ottaa se käyttöön. Hyödynsin WP-CLI:tä.

Asennetaan ja aktivoidaan.

wp plugin install redis-cache --activate

Sinun täytyy vain tietää lisäosan slug ja sehän on sama kuin tiedostonimen alku ilman versiota.

• Lisätään käyttäjä

Joskus tarvitsee nopeasti käyttäjän. Vaikka testaamiseen tai pitämään asiakas tyytyväisenä. Tai kuten edellisessä esimerkissä, olisin voinut lisätä itseni adminina, hoitaa lisäosahomman perinteisesti ja sitten poistaa käyttäjä (joka on kylläkin täysin turha mutka, mutta niin voisi tehdä).

Esimerkiksi näin.

wp user create tunnus email@example.com --role=administrator

WP-CLI tekee käyttäjätunnuksen ja luo salasanan. Jos missasin salasanan, niin voin vaihtaa sen helpommin muistettavaksi.

wp user update email@example.com --user_pass=uusi-salasana

WP-CLI:n poistaminen

Itse harkitsin pariinkiin kertaan WP-CLI:n poistamista alkuvaiheessa, kun mikään ei tuntunut toimivan. Minulla oli hieman vaikeuksia ymmärtää mitä hyötyä moisesta olisi. Mutta kun jatkoin googlettamista ja minulle selvisi miten WP-CLI:tä ylipäätään käytetään (perustasolla), niin sai jäädä. Ja hyvä että jäi, sillä nykyään käytän sitä melkoisen usein.

Silti on hyvä tietää miten siitä pääsee eroon.

Ensimmäiseksi täytyy tietää mihin WP-CLI asennusvaiheessa kopioitiin. Jos teit sen tämän ohjeen mukaan, niin lunttaa alusta. Mutta asennuspaikaan saa selvitettyäkin.

which wp

Koska WP-CLI:n asennus aidosti oli vain tiedoston kopioiminen uuteen paikkaan, niin se poistuu poistamalla tiedosto.

rm -f /usr/local/bin/wp

Jos asensit WP-CLI:n toista kautta, esimerkiksi git:stä, niin silloin joudut poistamaan koko hakemiston, jossa wp on.

rm -rf /hakemisto/jossa/on/wp-cli/