18.01.2021 katkestuse post-mortem

Esmaspäeva, 18. jaanuari õhtul lõpetas töö üks meie võrguseade, täpsemalt kommutaator ehk switch, mille kaudu käib mitmete serverite võrguühendus.

Tegemist oli seadmega, milles riskialtid komponendid dubleeritud, kuid mille riknemisi siiski esineb. Tavapäraselt oleme võrguseadme väljavahetamise ajakuluks arvestanud umbes 1 tunni. Selliste seadmete korralise väljavahetamise tsükkel on meil 5 aastat, uued täielikult dubleeritud seadmed olid seadistamise lõppfaasis.

Katkestus algas kell 17:15 ja mõjutas ca 40% Virtuaalserveritest ning 1/3 tavapärasest veebipäringute arvust. Klientide muud teenused nagu e-post, nimeserverid, ZoneCloud toimisid normaalselt.

Paraku ilmnes võrguseadme vahetamise järel, et tavapärase liiklusmahu korral kahaneb võrgukiirus olematuks.

Järgnes veaotsing, mille käigus prooviti läbi erinevad vea-hüpoteesid, paigaldati järgmine varuseade ja valmistuti ka võrgusegmendi üleviimiseks erinevale tehnoloogiale. Lõpuks tuvastati probleemina kommutaatori tarkvara viga, mis ilmnes reaalse koormuse tekkimisel ning mida ei olnud võimalik testkeskkonnas tuvastada. Probleemi lahendas vanema tarkvaraversiooni kasutuselevõtt, kõigi teenuste töö oli lõplikult taastunud kella 00:50ks.

Mida me teeme teenuste tõrkekindluse parandamiseks?

Kuna kõik Virtuaalservereid teenindavad serverid on meil test-rakenduse tasemel välises monitooringus jälgitavad, siis teame, et nende käideldavusnäitaja, milles sisalduvad ka korralised hooldused, on aasta lõikes 99,96-99,98%. Käesoleva katkestuse järel on mõjutatud serverite aastane näitaja tasemel 99,85%-99,89%. Meie eesmärk on alati olnud hoida oma teenustase koos hooldusakende arvestusega üle 99,9% käideldavusel ja hooldusaknaid välja jättes võimalikult lähedal 100%-le.

Nagu mainitud oli meil ettevalmistamisel võrguseadmete väljavahetamine ja täielik dubleerimine eesmärgiga selliseid riske maandada. Viime selle lõpuni lähinädalatel ja mõistagi öisel ajal, täpsest ajast teavitame kliente e-kirjaga.

Palume vabandust rikke põhjustatud ebamugavuste pärast ja panustame aastal 2021 veelgi enam sellesse, et kõik Zone teenused oleksid võrdselt töökindlad, ajaga kaasas käivad ja turvalised.

Ja kindlasti tänud neile, kes meie tehnikute tegevusele sotsiaalmeedias kaasa elasid – püüame olla oma tegevustes võimalikult läbipaistvad, kuvades nii tõrkeid kui plaanitud hooldusi zone.ee esilehel koos viitega status.zone.eu lehele, kust huvilistel on võimalik tellida ka teavitused e-postile. Samuti võite alati kindlad olla, et Zone süsteemid on 24/7/365 monitooritud ning sõltumata nädalapäevast või kellaajast ning riketega tegeletakse, kuni need on lõplikult lahendatud.

Tehniline taust

Tegemist oli võrgusegmendiga, kus oleme viis aastat kasutanud SDN (Software Defined Networking ehk programmeeritav võrgustus) tehnoloogiat, mis lahutab võrgu riistvara ja tarkvara üksteisest sõltumatumaks. Lihtsustades tähendab see, et kasutame Linuxil põhinevaid võrguseadmeid maailma juhtivatelt tootjatelt, mis on oma iseloomult suhteliselt lihtsad ja robustsed meie spetsialistidele seadistada, hallata jne.

Samuti on meil korraliste riistvarauuenduste käigus võimalik valida parim lahendus, olemata seotud ühe tarnijaga. Nagu eespool mainitud, olime ühte sellist vahetust just ette valmistamas, uued seadmekapid olid ette valmistatud ning lähinädalatel plaanis serverite üleviimine. Tavapäraselt olid nii põhi- kui varuseadmed seadistatud kasutama tarkvara värskeimat stabiilset versiooni ning testitud.

Üks selline varuseade võeti kasutusele ning alglaadimise järel tundus kõik andmekeskuses olevatele tehnikutele toimivat, aga kaughaldust tegeval meeskonnal oli probleeme ligipääsuga serveritele. ping toimis kenasti, aga ssh oli probleemne, staatiline sait HTTP peal toimis aga HTTPS keeldus kätlemast, andmebaasiserveriga ei saadud ühendust jne.

Kogu võrguseadmete konfiguratsioon käidi ridahaaval läbi, et tuvastada erisusi kõrval töötavate seadmetega. Katsetati kõiki võimatuid ja võimalikke riistvaraga seotud teooriaid alates AOC (Active Optical Cable) kaabliriketest, lõpetades võimalike anomaaliateni DDoS kaitses jne.

Vea tuvastamise protsessi käigus toodi meie teisest andmekeskusest kohale kolmas sarnane võrguseade välistamaks võimalust, et esimene asendusseade on vigane. Jällegi, läbiti tavapärane protseduur selle seadistamiseks ja paigaldamiseks, kuid kahjuks jõuti kõikide muudatuste tulemusena täpselt samasse punkti välja. Kõik töötab, aga seadmesse sisenedes kahaneb andmeside olematuks – nagu autol rakenduks puhtal sirgel teel veojõukontoll.

Lõpuks jõudsime tegeliku juurprobleemini. Mis nii kurioosne kui see ei ole, oli seotud selle võrguseadme eesootava asendusega. Nagu öeldud, siis SDN puhul on tihti kasutusel arhitektuur, kus võrgu riistvara on ühelt tootjalt (nö “white box”) ja selle nutikus tuleb Linux operatsioonil põhineva tarkuse kaudu mujalt. Selgus, et meie tehnikud kasutasid rikkis võrguseadmele asenduse paigaldamisel Linuxi versiooni, mida nad olid juba kasutanud uute võrguseadmete ettevalmistamisel. See oli aga mõne väljalaske võrra uuem, kui see mis varasemasse seadmesse oli paigaldatud. Uus tarkvaraversioon sisaldas seni täpselt tuvastamata viga ning probleem lahenes vanema tarkvaraversiooni paigaldamisega.

Järgmisel päeval suutsid tehnikud laboritingimustes probleemi reprodutseerida. Me ei tea veel milline tarkvara “bugi” või ”uus featuur” täpselt seda põhjustas, aga ASIC erikiipidel toimuv superkiire TCP/IP pakettide edastamine lülitati seadmes välja ja nende edastamine läks üle CPU-le ehk protsessorile, mis andmeside kontekstis on võrgu jõudlusele sisuliselt surmahoop. Paraku ei täheldanud me sedapuhku ka CPU koormusnäitajate märkimisväärset tõusu. Nimelt on selles samas tarkvaras ka loogika, mis piirab protsessorile edastatavate pakettide arvu ülekoormust ennetavalt ära.

Takkajärgi sündmuste ahelat läbi vaadates tundub kõik muidugi lihtne, aga reaal-ajas tähendas see paljudele seda, et esmaspäeval tuli tööpäevale teine ja keskmisest stressirohkem otsa. Tegutseme edasi selle nimel, et 24/7/365 käideldavus oleks saavutatav rahulikult 9st 17ni riske maandades :.)

Need 5 veidrat trikki teevad su WordPressi kiiremaks

Aidates iga nädal aeglaselt avanevaid ja otsirobotite koorma all ägavaid veebe elule äratada hakkavad mõned asjad korduma. 5 peamist nippi sai Tallinn WordPress meetup’i tarbeks ka ettekandeks vormistatud.

Ja ei ole need trikid tegelikult nii veidrad midagi – kui korra ära õpid ei saa enam ilma hakkama. Alustama peame aga natuke kaugemalt, sest mistahes probleemi lahendamine algab selle olemuse mõistmisest ja veebiserveri puhul ei saa me läbib logide ja serveri koormuse uurimiseta. Ning selleks on abiks võtta kasutusele SSH … ehk käsurida.

Sissejuhatus – kasuta SSHd

Käsurealt saad reaal-ajas vaadata aktiivseid protsesse, andmebaasi- ja veebi-päringuid, samuti otsida huvipakkuvaid mustreid kuitahes suurtest logifailidest, mille FTPga alla-lohistamine võtaks aega ja mis tavapärased tekstiredaktorid kokku jooksutaks.

Millest pihta hakata? Kui kasutad Mac OSi või Linuxit on mugavaim õpetus GitHubi Generating a new SSH key and adding it to the ssh-agent, mina googeldan abi vajades alati “github ssh key“… aga kui soovid Windowsi, PuTTY ja Zone-spetsiifilisemat abi, siis leiad ka meie abitekstidest juhise SSH ühenduse loomine.

Ma olen täiesti kindel, et kui õpid alljärgnevate supervõimete nimel SSHd kasutama… siis järgmine kord kohtudes teed mulle (oma eelistusest lähtuvalt) välja koogi või õlle 🙂

Trikk #0 – vaata logisid!

Nii, mis meil siin serveris siis toimub?

cd domeenid/www.example.com/logs/
tail -f apache.ssl.access.log | grep-php

Käsk tail kuvab faili lõppu ja -f värskendab väljundit jooksvalt, | grep-php otsib tulemusest päringuid, mis käivitasid PHP ehk veebirakenduse:

Nagu näha käib pidev lammutamine wp-login.php kallal, lisaks hakkavad silma wp-cron.php ehk ajastatud tegevused ja hulk erinevaid (otsi)roboteid: Yandex, Bing, DuckDuckGo, Ahrefs, Semrush… Õnneks on minu veebis rea lõpus olev ajakulu suurusjärgus 0.02-0.15 sekundit ehk olematu, aga kui aeg hakkab olema üle sekundi… siis võivad botid kergesti kurja teha.

grep-php, grep-phpslow ja grep-phpveryslow on Zone serverites seadistatud aliased, mis aitavad leida PHP- või aeglase PHP-päringuid. Kui tahad neid seadistada oma arvutis või mujal, siis käsk alias näitab retsepti 🙂

Trikk #1 – asenda wp-cron.php süsteemse cronjob’iga

Aga proovime ühte teist saiti ja grep-phpslow annab sellise tulemuse:

Ouch! 10-50 sekundit töötav cron-päring hõivab ühe veebi teenindamiseks mõeldud PHP-protsessidest… mõistlikum oleks seadistada süsteemne CRONTAB.

Sellest räägib eraldi help.zone.eu artikkel WordPressi cron-tööde seadistamine.

Trikk #2 – piira robots.txt abil botte

Kuigi robots.txt on rangelt soovituslik tuleb nentida, et suur hulk logides silma hakkavaid botte käituvad igati viisakalt ehk loevad vähemalt kord nädalas robots.txt faili ja arvestavad selle suunistega.

Minul on tavaks soovitada kõigil robotitel mitte pärida sagedamini kui 10 sekundi takka ning keelata päringud, milles sisaldub ? ehk millele on lisatud mingid parameetrid, olgu selleks siis s=otsisõna või color=pink&size=42 kujul e-poe filtrid.

User-Agent: *
Crawl-delay: 10
Disallow: /*?*

User-agent: AhrefsBot
User-agent: AhrefsSiteAudit
User-agent: SEMrushBot
User-agent: SemrushBot
User-agent: SemrushBot-SA
User-agent: MJ12bot
Disallow: /

Täiendavalt võib keelata meie jaoks väärtust mitte omavad botid, nt kui me ei kasuta Ahrefs ja Semrush SEO-tööriistu on kogu nende tekitatav koormus vesi vaid konkurentide veskile… ja miks neid nuumata?

robots.txt puhul tuleks meeles pidada, et tühi reavahetus ei ole ilu pärast vaid eristab erinevatele bottidele suunatud plokke ja User-Agent: * reegel kehtib vaid neile, kes endale sobilikku plokki ei leia.

Trikk #3  – kiireks ja jõuliseks piiramiseks kasuta .htaccess’i

Vahel ei pruugi aga robots.txt piisav olla, sest seda kontrollitakse periooditi samas kui sinu koormuse-probleem on valus just täna. Kuna viisakad botid panevad oma nime User-Agent’isse kirja, siis saab veebiserverile anda korralduse neile sobilikku veateadet näidata.

Selleks tuleb veebi juurkataloogis olevasse .htaccess faili lisada nimekiri soovimatutest User-Agent’itest ning lubada neile ligipääs ainult robots.txt’ile – lootuses, et nad tulevikus sellega arvestama hakkavad:

RewriteEngine On
RewriteCond %{REQUEST_URI} !/robots.txt$
RewriteCond %{HTTP_USER_AGENT} Semrush [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsSiteAudit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC]
RewriteRule .* - [R=503,L]

Trikk #3b – piira hiinabottide ligipääs

Kohati kohtab aga eriti agressiivseid botte, mis tulevad hulgalt erinevatelt IPdelt, ei huvitu robots.txt’ist ega evi äratuntavat UserAgent’it.

Aga sageli tulevad nad Hiina IP-aadressidelt. Zones on veebiserver seadistatud nii, et igal päringul on automaatslet küljes IP-aadressile vastav maakood, miska on lihtne lisada .htaccess faili järgmine plokk:

SetEnvIf MM_COUNTRY_CODE ^(CN) countryBlock
Deny from env=countryBlock

Ehk kui maakood algab CN’iga, siis Deny.

Vähendab kindlasti olulisel määral müüki Hiinasse, aga küllap tulevad hiinlaste hordid Helsinki lennujaama ja Talsinki tunneli kaudu peagi ise kohale, seega no harm done.

Trikk #3c – brauseri-cache ilma pluginata

Kui see .htacces juba editoris lahti on… teeks veel ühe pisiparanduse. Nimelt saab väga lihtsalt brauseritele öelda, et ei ole vaja igal lehekuvamisel käia küsimas kas mõni pilt või CSS on muutunud:

<IfModule mod_mime.c>
# Add mime types that might be missing from server conf
    AddType font/woff2 .woff2
</IfModule>

<IfModule mod_expires.c>
# Enable expirations
  ExpiresActive On
# Default directive
  ExpiresDefault                 "access plus 1 day"
# HTML
  ExpiresByType text/html        "access plus 0 seconds"
# Data
  ExpiresByType text/xml         "access plus 0 seconds"
  ExpiresByType application/xml  "access plus 0 seconds"
  ExpiresByType application/json "access plus 0 seconds"
# Favicon
  ExpiresByType image/x-icon     "access plus 1 year"
# Images
  ExpiresByType image/gif        "access plus 1 month"
  ExpiresByType image/png        "access plus 1 month"
  ExpiresByType image/jpg        "access plus 1 month"
  ExpiresByType image/jpeg       "access plus 1 month"
  ExpiresByType image/webp       "access plus 1 month"
# CSS
  ExpiresByType text/css         "access plus 1 hour"
# Fonts
  ExpiresByType font/woff        "access plus 1 year"
  ExpiresByType font/woff2       "access plus 1 year"
# Javascript
  ExpiresByType application/javascript "access plus 1 year"
</IfModule>

Trikk #4 – vaata, mis wp_options tabelis toimub

WordPressi puhul võiks edasi liikuda mitmes suuna – pagebuilder? WPML? turvaplugin? megamenüü? … aga jätame need hilisemaks. Kogenud koristaja võtab esimes asjana ette wp_options tabeli, sest:

  • sinna salvestatakse vaikimisi kogu “ajutine” kraam nn transient’idena;
  • transientide suurus võib olla kuni 100 megabaiti – ja seda siis üks kirje!
  • neid kirjeid või olla kümneid tuhandeid;
  • ja isegi kui progejad on arvestanud aegumise järel kustutamisega… võib see käia wp-cron’ile üle jõu;
  • seal on veerg autoload mis ei ole indekseeritud, ehk igal lehekuvamisel peab SQL otsima kümnete tuhandete ridade hulgast neid, mille indekseerimata väärtus on yes;
  • kirjeid võidakse uuendada igal päringul või ajastatud toimingul, mille tulemusena kasvab andmebaas kontrollimatult (à la 1 ööga 100 gigabaiti).

Ehk kui wp_options on suurem kui ca 1500 kirjet ja kirje sisu üle … ütleme, et üle max mõnesaja kilobaidi, siis on tegemist olulise probleemiga.

Trikk #5 – vaata, mida kood teeb

… see blogipostitus on olnud mustandi olekus täpselt 3 kuud – sest ma ei jõudnud 5nda triki kirjutamiseni esimese hooga. Aga ma arvan, et ma tahtsin kirjutada oma varasema Miks mu veeb aeglane on? Vaata BlackFire abil järgi! artikli lihtsamaks.

Kahjuks… seda lihtsamaks kirjutada väga ei anna. Sest kõige olulisem oleks pikk nimekiri “kuidas tõlgendada/lahendada olukoda X?” … ja meie mõlema jaoks oleks mõistlikum aja/rahakasutus kui ma konkreetse juhtumi (raha eest) ette võtaks ja arendajale juhised annaks.

Trikk #6 – tule Pop-up Helpdeski!

Enamvähem igal esmaspäeval kell 15-19 olen ma SpringHub’is ja aitan kõiki, kes viitsivad kohale tulla ja küsida.

Kontrolli igaks juhuks Zone FB lehelt ürituste sakist konkreetse kuupäeva toimumine järgi (sest vahel olen ma lähetuses või esinen mõnes teises kohas) ja võimaluse korral anna oma tulekust enne teada (ma olen kõigis sotsmeediakanalites petskratt), siis oskan aega planeerida.

Milleks on kasulikud WordPressi laetud meedia alternatiivtekst, pealkiri, allkiri, kirjeldus jne?

WordPressi meediateegis tekitab segadust hulk infolahtreid: Alternatiivtekst, Pealkiri, Allkiri ja Kirjeldus. Kas ja mida sinna kirjutada?

Alustame vahest kõige olulisemast – Alternatiivtekst kirjeldab pilti ning seda näeb kui vaadata lehe HTMLi või WordPressi redaktoris sakki Tekst:

Ekraanilaks ekraanilaksust WordPressi redaktori teksti-sakis

Vaegnägijale loeb ekraaniluger selle teksti ette, seega võiks sisu olla ennekõike pilti kirjeldav. Lisaks jälgivad alt-teksti ka otsimootorid, ehk hästi kirjeldatud pilt on abiks ka SEO vaatest. Aga see ei ole veel kõik: alt-teksti kuvavad brauserid siis, kui pildifail mingil põhjusel ära kaob:

Ekraanilaks katkisest pildist brauseris

Tähtsuselt järgmine on pildi Allkiri ehk inglise keeles caption: see on pildi all kuvatav tekstilõik, kuhu sobib pikem selgitus, foto autor jms info. Nagu ülevalt koodinäitest näha on see realiseeritud [caption] koodiga ning teemades on enamasti paika pandud ka sobilik kujundus:

Ekraanilaks WordPressi meediateegist
See on pildi allkiri, ingl. k caption. Ekraanilaksu autor: Peeter Marvet

Pealkiri ja Kirjeldus on mõeldud manuselehe jaoks – nimelt tekitab WordPress iga üles laetud meedia-faili kohta alamlehe, millel kuvatakse Pealkiri, meedia ja Kirjeldus. Ülaloleva ekraanilaksu manuseleht on näiteks https://blog.zone.ee/2019/10/23/wordpressi-meedia-alternatiivtekst-pealkiri-allkiri-kirjeldus-jne/wp-pildi-kirjeldus/.

Manuseleht ei pruugi aga otsimootorist tulevate külastajate jaoks olla parimaks maandumisleheks – mina näiteks tahaks, et WordPressi meedia kirjeldamist puudutavate otsingute puhul saaks parima positsiooni see blogipostitus, mitte mõni ükskik ekraanilaks.

Selleks on näiteks Yoast SEO pluginas olemas võimalus suunata manuselehed automaatselt edasi pildifailile ehk sisuliselt ära kaotada:

Ekraanilaks: Yoast SEO plugina seaded

Ja ära unusta, et SEO jaoks omab lisaks alt-tekstile tähendust ka faili nimi. Siin artiklis olevad ekraanilaksud ilmselt ise-seisvat väärtust ei oma, aga toote-foto võiks muuhulgas Google pildi-otsingus välja tulla nii kirjeldava (“pink t-shirt powerpuff girl”) kui tootekoodi-otsinguga.

WordPressi haakimiskohad ehk konksud ja filtrid

Haak või kõrvalepõige on nagu nõudepeatus või küsimus “kas astun töölt koju tulles poest läbi?” ehk kellegi poolt kirjutatud koodi on taotluslikult jäetud võimalus selle kulgu mõjutada.

WordPressis on kahte sorti haakimiskohti:

  • hook e. konks on nagu nagi, kuhu igaüks saab riputada oma täitmist vajavad funktsioonid;
  • filter võimaldab huvilistel andmeid mudida, reeglina enne väljastamist.

Konksudest ja filtritest räägib kolmapäeval, 09.10.2019 kell 19 algaval WordPressi meetupil ka Arūnas Liuiza.
Tule kohale kuulama ja küsima!

Konks

Selle illustreerimiseks sobib alamteemade postituses olev näide, kus lisasin Google Analytics’i header.php koodi:

Kuna header.php sai kopeeritud alamteema kataloogi tuleb sellise laiendamise puhul arvestada, et kui põhiteemas see fail uueneb on vaja neid a) märgata b) käsitsi alamteemasse üle tuua.

Jätkusuutlikum lahendus on päise konks:

<?php wp_head(); ?>

See teeb täpselt ühte asja – kutsub välja kõik ennast wp_head konksu külge haakinud funktsioonid:

function wp_head() {
/**
* Prints scripts or data in the head tag on the front end.
*
* @since 1.5.0
*/
	do_action( 'wp_head' );
}

Praktikas haagivad ennast sinna kõik skriptid-CSSid-metaväljad jne (seejuures mõned nt JS ja CSS kasutades  spetsiaalseid konkse, mis ennast wp_head külge haagivad).

Sama analüütika-koodi saaksime lisada alamteema functions.php faili nii:

function petskratt_analytics() {
?>
	<!-- Global site tag (gtag.js) - Google Analytics -->
	<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx-1"></script>
	<script>
	  window.dataLayer = window.dataLayer || [];
	  function gtag(){dataLayer.push(arguments);}
	  gtag('js', new Date());
	
	  gtag('config', 'UA-xxxxxx-1');
	</script>
<?php
}

add_action('wp_head', 'petskratt_analytics', 1);

Kirjeldan funktsiooni ning haagin ta nime pidi add_action abil sobilikku kohta, viimane parameeter on prioriteet ehk vastavalt Google Analytics’i soovitusele tahaks nende jupp olla võimalikult <head> alguses. Päris esimeseks ei saa, aga need eelnevad meta-väljad ei ole ka kuidagi probleemiks.a

Nüüd võin ka Twenty Nineteen’i julgesti uuendada, minu alamteema muudab põhiteema ja WordPressi käitumist vastavalt parimale tavale.

Selliseid konkse on WordPressis umbes 800 – ja lisaks 1700 filtrit.

Filter

Konks on abiks, kui tahad ise midagi väljastada – aga mida teha juhul, kui tahaksid muuta mõne teise funktsiooni poolt väljastatavat? Näiteks prooviks postituse sisu kuvada AINULT SUURTÄHTEDEGA … või veel parem (jaburam) SuvaLIsE SuuRUsEGA.

Tegevuste ahel on selline:

  1. teema kutsub sobilikus kohas välja funktsiooni the_content()
  2. the_content() leiab andmebaasist postituse sisu, valmistab selle kuvamiseks ette… aga enne kuvamist pakub võimalust the_content filtri külge haakinud funktsioonidele seda muuta
  3. sinu funktsioon haagib ennast the_content filtri külge, teeb mida tahab ja tagastab tulemuse
add_filter( 'the_content', 'petskratt_rAndOmcASe' );
 
function petskratt_rAndOmcASe( $content ) {

	$str = str_split( strtolower( $content ) );

	foreach ( $str as &$char ) {
		if ( rand( 0, 1 ) ) {
			$char = strtoupper( $char );
		}
	}

	return implode( '', $str );
}

Ja tulemus näeb välja selline:

Fuksi värvi pealkiri on postitusest Kuidas kohandada WordPressi teemat ehk alamteema (child theme) kasutamine.

Kuidas kohandada WordPressi teemat ehk alamteema (child theme) kasutamine

Avatud lähtekoodiga tarkvara puhul on lihtne võtta ette mistahes koodifail ja sinna muudatusi teha. Aga… stopp! Kuidas jääb siis tulevaste (turva)uuendustega?

Paljudel WordPressi kujundus-teemadel on olemas seadistuste paneel, mis lubab valida värve ja fonte, seadistada logo ja lehel kuvatavate tulpade arvu otse haldusliideses, ilma koodi puutumata. Vahel on aga vaja teha suuremaid muudatusi, mida on mõistlikum teha teema CSSi või lehe-templiite muutes.

Nii tasulised kui tasuta teemad saavad aga pidevalt uuendusi: parandatakse vigu kujunduses või lisatakse uute HTML+CSS standardite tugi, paigatakse turva-auke ja viiakse kood sobilikuks uuemate PHP versioonidega. Teema uuendus tähendab aga sisuliselt seda, et teema kustutatakse ja paigaldatakse uuesti ning selle käigus lähevad kõige kaduva teed ka failides tehtud muudatused.

Samal teemal räägib kolmapäeval, 09.10.2019 kell 19 algaval WordPressi meetupil Arūnas Liuiza.
Tule kohale kuulama ja küsima!

Selliste probleemide vältimiseks ongi loodud WordPressi alamteema ehk child theme funktsionaalsus. Toimib see nii:

  1. sul on paigaldatud teema, näiteks Twenty Nineteen
  2. ning sellele lisaks alamteema, mille päises on on viide põhiteemale
  3. aktiveerid alamteema
  4. WordPress otsib vajalikke faile kõigepealt alamteemast, kui ei leia siis põhiteemast

Ja sina saad muudatusi teha nii:

  1. kopeerid vajaliku faili põhiteema kataloogist alamteema kataloogi
  2. teed alamteema kataloogis vajalikud muudatused
  3. magic happens 🙂

Näiteks võiks teha järgmise alamteema, luues wp-content/themes alla kataloogi twentynineteen-child ja sinna sisse faili style.css:

/*
 Theme Name:   Twenty Nineteen Child
 Description:  A kind of pink child theme for Twenty Nineteen 
 Template:     twentynineteen
 Version:      1.0.0
*/

@import url("../twentynineteen/style.css");

h2 {
	color: fuchsia;
}

See viitab alustuseks põhiteema CSSile ning muudab seejärel kõik H2 pealkirjad roosaks.

Ja oletame, et järgmise asjana tahaks lisada lehe HTMLi päisesse Google Analyticsi koodijupi ja teha seda ilma liigseid pluginaid lisamata. See käib nii:

  1. kopeerid faili header.php põhiteema twentynineteen kataloogist alamteema kataloogi twentynineteen-child
  2. lisad vajalikud read:

Ja … toimibki!

Kui tahad proovida, siis twentynineteen-child.zip sisaldab ülalkirjeldatud alam-teemat (tõsi, header.php pead ise kopeerima) mille saad paigaldada WordPressile nii, nagu ikka: Välimuse haldusmenüüst või ise lahti pakkides ja FTP-ga üles laadides.

Loodetavasti tekib sellega mängides ka küsimus: “Aga mis siis, kui Twenty Nineteen põhiteemas header.php uueneb?”. Tõepoolest, sinu alamteema jääb kasutama ise muudetud versiooni ning muudatused tuleb käsitsi üle tuua, aga:

  1. alamteema all on õnneks mugavalt näha kõik komponendid, mida oled muutnud
  2. on üks teine, veel parem nipp: kasutades WordPressi haake ehk hooke ja filtreid, sellest räägib järgmine postitus WordPressi haakimiskohad ehk konksud ja filtrid