Wordpress ja versioonihaldus

Kui endale blogi püsti panin, siis valisin platvormiks WordPressi. Olen korduvalt väitnud, et WP mingite keerukamate lahenduste (e-poed, spetsiifilise loogikaga veebilahendused jms) ei sobi ning jään sellele seisukohale kindlaks. Ent blogimootorina on ta väga hea.

Samuti tahtsin ennast kursis hoida, mis “maailma populaarseima sisuhaldusmootoriga” toimub. Ajast, mil viimati WP installisin, on paar aastat möödas. Nii et paras on end jälle kurssi viia.

Eelkõige tahtsin aga välja nuputada, kuidas WordPressile normaalset versioonihaldust (giti) külge saada. Nii et arendus oleks loogiline ja mõnus. Paistab, et sain selgust ka.

Mida versioonihaldusesse lisada

Sisuliselt on WordPressi ja versiooniahdluse puhul kolm levinud varianti:

Mingit repot ega versioonihaldust ei ole, muudatusi tehakse pahatihti otse lives (ning ka WP-admini enda koodiredaktoriga)
Versioonihalduses on kogu sait – core, pluginad, themed jne. Välja jäetud on heal juhul vaid /wp-content/uploads kaust
Versiooniahdluses on vaid theme

Seda, miks esimene variant halb on, ei ole vaja vast üldse seletada.

Teine lahendus iseenesest ju toimib, ent ei ole just esteetiliselt kõige kenam. Samuti tekib probleeme igasuguste uuendustega, ent neid võib WP puhul tekkida paratamatult.

Kolmanda lahenduse suurimaks miinuseks on see, et theme üksi ei tähenda mitte kui midagi. Juba erinevate WP versioonidega võib see toimida erinevalt. Pea alati on aga iga themega koos kasutusel n arv pluginaid. Neid oleks ju samuti teada vaja – tihtipeale on pluginastest sõltuv funktsionaalsus themesse sisse kirjutatud. Tõsi, WP lubab defineerida pluginad, mida antud theme nõuab. Ent nende haldamine käib ikka läbi admin-keskkonna, mis ei ole arenduse seisukohalt kõige mõnusam. Admin keskkond peaks olema lõppkasutajale.

Oluline on aru saada, et WordPress ise on samuti sisuliselt “plugin”. Ehk siis mingi osa koodist, mida ei tohi torkida. Kolmandate osapoolte poolt arendatud sõltumatu mootor.

Sisuliset kogu WordPressi arendus tehaks ära themes (ning pluginates). Seega oluliselt loogilisem oleks, kui WP struktuur oleks umbes selline:

wp-content  //Themed, pluginad jne
wp          //Wordpress core
index.php
wp-config.php

Õnneks on see võimalik ning WordPressi seadetes on võimalik määrata, et core asub mingis teises kaustas. WP enda juhend on siin, ent käin allpool kõik vajalikud sammud ka ise läbi. Siin näites valin WordPressi core kataloogiks “/wp”.

Niisiis, WP versioonihalduseks peaks olema mingi parem lahendus kui ülal mainitud kolm. Minu arust isegi on:

Sõltuvus juhi*

*tegu on Google Translate tõlkega fraasile “dependency manager”

Sisuliselt tähendab see, et veebilahenduse juures määratakse ära, millist sõltumatut koodi kasutatakse. Sõltumatut, ehk et sellist, mida projekti arendamiseks torkida ei ole vaja. WordPressi kontekstis core (ehk WP ise) ning pluginad.

PHP jaoks on lahenduseks Composer. Vaikimisi Radicenter ega Zone seda ei paku, ent mõlemasse saab selle kenasti installida. Teiste veebimajutuse pakkujate osas ei oska kommenteerida.

Pikemalt ma siinkohal Composeri installeerimisel peatuma ei hakka. Composeri enda lehel on kõik väga hästi lahti seletatud ning ülal viidatud link avab juhise Zone serveris kasutamiseks. Sisuliselt sama kehtib ka Radicenteri jaoks.

WordPress küll ise vaikimisi Composerit ei toeta, ent õnneks olemas ka WordPressile Composeri-sõbralik repo. Seda uuendatakse automaatselt iga 15 minuti tagant, nii et iga WP versiooniuuendus jõuab sisuliselt koheselt kohale.

Niisiis, et saada WordPress toimima, tuleks oma composer.json faili (see fail määrab ära, millist kolmandate osapoolte koodi kasutatakse) lisada:

{
  "require": {
    "johnpbloch/wordpress": ">=4.4"
  },
  "extra": {
    "wordpress-install-dir": "wp"
  }
}

See tähendab, et nõutakse WordPressi versiooni 4.4 või kõrgemat ning WP installitakse kausta /wp. “>=” tagab sisuliselt, et alati tõmmatakse uusim versioon, ent alati võib ka mingi kindla versiooni defineerida:

...
    "johnpbloch/wordpress": "4.4"
...

Nüüd ei ole sisuliselt muud, kui projekti kaustas käivitada:

composer install

Pärast seda on WP olemas; kusjuures kaustastruktuur on palju loogilisem, nagu eelpool mainitud.

Lehe avamine aga endiselt ei õnnestu. Miks?

WP ja custom kaustad

Nagu juba eelnevalt korra mainisin, tuleb WordPressile teada anda, et core soovitakse installida kuhugi mujale kausta.

Selle jaoks tuleb esmalt kopeerida /wp kaustast index.php, wp-config.php (kui tegu on uue installiga, siis wp-config-sample.php) ning .htaccess (kui see on olemas) juurkausta.

Kui sul oli wp-config-sample.php, siis nimeta see ümber wp-config.php

Seejärel ava juurkaustas index.php ning leia rida:

require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Muuda see ümber:

require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' );

/wp asemel võib olla muidugi midagi muud, kui kasutad core jaoks mingit teist kausta.

Seejärel ava wp-config.php ning sisesta oma andmebaasi andmed ning “Authentication Unique Keys and Salts” all olevad hashid, nagu teeksid tavalise WP installi puhul.

Nüüd leia failist

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

ning asenda see:

define('CORE_STRING', 'wp');
define('CONTENT_STRING', 'wp-content');

/** @var string WP_HOME The site's URL, no trailing slash */
define('WP_HOME', 'http://sinu_aadress.ee');

/** @var string WP_SITEURL WordPress core URL, no trailing slash */
define('WP_SITEURL', WP_HOME . '/' . CORE_STRING);

/** @var string CONTENT_DIR WordPress content directory, no trailing slash  */
define('WP_CONTENT_DIR', dirname(__FILE__) . '/' . CONTENT_STRING);

/** @var string CONTENT_DIR WordPress content URL, no trailing slash  */
define('WP_CONTENT_URL', WP_HOME . '/' . CONTENT_STRING);

/** @var string ABSPATH Absolute path to the WordPress core directory, with trailing slash */
if (!defined('ABSPATH')) {
    define('ABSPATH', dirname(__FILE__) . '/' . CORE_STRING . '/');
}

WP_HOME defineerimise juures kasuta ikka oma reaalset (või lokaalset) aadressi.

Ülalolev muudatus lahendab üsna mitu probleemi. Esiteks määrab ta custom core ning /wp-content kataloogide asukohad.

Teiseks kaotab ta vajaduse määrata saidi aadressi andmebaasis. See on üks igivana idiootsus, mis WordPressiga kaasas käib. WP sätete all on need väljad ikka olemas, ent reaalselt kasutatakse antud failis olevaid.

Pluginad

Nagu WordPress, ei ole ka selle pluginad üldjuhul Composeri-sõbralikud. Õnneks on siingi lahendus olemas – WordPress Packagist. Sisuliselt on tegu koopiaga kõigist WP ametlikest pluginatest, millele on lisatud Composeri jaoks vajalik info.

Kuna ma ise seda (veel) reaalselt kasutanud ei ole, siis ei hakka pikemalt peatuma. WP Packagist lehel on aga näidised olemas.

See lahendus kahjuks ei toimi nende pluginate jaoks, mida WP kataloogis pole. Näiteks mingid tasulised või custom pluginad.

Nende jaoks võid kas ise (privaatse) repo üles seda või siis lisada need oma projekti alla. Mina kasutasin hetkel viimast varianti, kuigi see just kõige ilusam ei ole.

WordPress ja git

Kui oleme lõpuks nii kaugele jõudnud, saab hakata ka versioonihaldusele mõtlema.

Eeldan taaskord, et git ei ole võõras ning täpsemalt sellel siinkohal peatuma ei hakka.

Olles giti repo üles seadnud, lisasin oma .gitignore faili:

/vendor
/wp
wp-config.php

!wp-content/

wp-content/*
!wp-content/themes/
!wp-content/plugins/

wp-content/plugins/*
!wp-content/plugins/mingi_custom_plugin

Hakates rida-realt lugema:

/vendor ja /wp on core, mida me mingil juhul torkida ei taha.

wp-config.php käsib ingoreerida confi faili ning seda tõesti tavaliselt kuhugi reposse üles lasta ei taha. Kui turvalisus on suva, siis kasvõi seetõttu, et local ja live conf on üldjuhul erinevad.

See tähendab muidugi, et kui lehe kuhugi üles paned, siis pead käsitsi laadima ka wp-config.php faili.

!wp-content/ ütleb, et ära /wp-content kausta ignoreeri.

wp-content/* ei ütle, antud kausta kohta midagi, ent käsib ignoreerida selle sisu (kõiki kaustas olevaid faile ning alamkatalooge).

!wp-content/themes/ ning !wp-content/plugins/ tühistavad osaliselt eelmise käsu, lubades jälgida kaustu wp-content/themes (seal toimibki ju peamine arendus) ning ning wp-content/plugins (kuna minu theme kasutab mingeid custom pluginaid).

Viimased kaks rida ütlevad, et ignoreeri kogu wp-content/plugins kausta sisu, välja arvatud kausta mingi_custom_plugin.

Nii on mul võimalik osa pluginaid laadida Composeri abil, ent osa hoida ka muu lehe koodiga koos ühes repos.

Veidi täpsemalt .gitignore ning kaustareeglite kohta saab lugeda siit.

Miks see hea on

Tõsi, sellisel moel install võttis kauem aega, kui WP kuulus 5 minuti install. Tegelikult pakuvad ju enamus eesti hostingupakkujaid ka oma halduspaneelis paari klikiga installi, mis oleks veelgi kiirem olnud.

Samas on mul nüüd mugav ülevaade nii oma uuendustest kui ka koodist üldse. Ning ka uuenduste tegemine on lihtne.

WP versiooni uuendamiseks (kuna kasutan composer.json failis “>=” tingimust) piisab

composer update

käsust.

Ning kood, mida ma ise ei kirjuta, asubki minu repost väljas. Kui muidugi välja arvata custom pluginad, mille jaoks mingit composeri-varianti ei ole.

Seades nüüd oma lokaalses arenduskeskkonnas lehe üles, piisab kahest käsust (git pull ja composer update), ent kõik vajalik (ning sama versioon, mis liveski) olemas oleks.

Puudused

Esiteks on jama see, et WP ise ametlikult Composeri tuge ei paku. Samuti puudub see enamus pluginatele.

Teiseks andmebaasi haldus. Igasugused core ja pluginate uuendused võivad andmebaasi muudatusi kaasa tuua. Kuidas aga neid mugavalt hallata on muidugi juba üldisem probleem, mitte ainult WP oma.

Laravelil on tegelikult baasi muudatuste jaoks väga hea lahendus olemas. Kuna ma ise seda päriselt kasutanud ei ole, ainult proovinud, siis ei hakka väga põhjalikult kiitma. Aga esmapilgul tundub küll üks parimaid lahendusi üldse.

Loe lisaks

Lehed, millest ise abi sain:

Päise foto: http://7blog.7host.com/the-importance-of-increasing-the-safety-of-a-website-in-wordpress/