Yksi WordPressin hitautta aiheuttava tekijä on tietokanta itsessään. Mitä suurempi, niin sitä enemmän alkaa hidastelua esiintyä ja varsinkin admin-hallinnan puolella taustalla. Mutta se näkyy myös käyttäjille. Minulla on joskus ollut niin paisunut tietokanta, että sen saanut siirrettyä sitä webhotellin latausrajojen takia. Yksi selvä pullonkaula on wp_options -taulu, johon tallennetaan kaikkea mahdollista ja mahdotonta sivuston vaatimaa asiaa. Siellä on taasen yksi potentiaalinen hidastelija: autoload-kenttä.

WordPress on ns. dynaaminen järjestelmä. Jokainen sivu ja sen osa, tekstit, valikot, vimpaimet jne, on tietokannassa, josta PHP-koodit käyvät hakemassa omat palasensa ja liimaavat ne yhteen, jolloin saadaan se, jota sivuksi kutsutaan. Tämän monimutkaisen operaation takia on niin tärkeää, että käyttää välimuisteja:

• staattisia sivuja tekevä, kuten WP Rocket
• HTTP reverse proxy, eli serverillä oleva välimuisti käyttäjän ja verkkosivun välillä: Varnish
• välimuisti objekteille, eli esimerkiksi tietokantakutsuille: Redis

Nuo nopeuttavat selvästi WordPressiä, mutta jos hidastuminen johtuu ylipäätään siitä, että tietokanta kompuroi, niin mikään tuosta kolmikosta ei kykene ihmeisiin. Siksi tietokannan kuntoa seurataan.

Yksi tapa on optimoida tietokannan tauluja ja siivota roskat. Tuo on syytä tehdä säännöllisesti. Sen voi tehdä käsinkin, mutta helpoin on antaa lisäosan hoitaa moiset säännölliset rutiinihommat. Siihen löytyy tuhottomasti lisäosia, mutta WP Rocket pitää tuon toiminnallisuuden sisällään – ei kannata asentaa päällekkäisiä asioita.

wp_options

Taulussa wp_options on kaikki

• sivuston asetukset,
• lisäosien ja teemojen asetukset
• väliaikaista tauhkaa

wp_options eroaa yhdellä oleellisella tavalla muista WordPressin tauluista. Se on yksinään. Sillä ei ole relaatiota muihin tauluihin. wp_options ei osallistu sisällön tekemiseen, vaan siinä on sivuston ja multisiten verkon hallinta. Siksi tieto tulee siihen asennussivuilta, oli kyseessä sitten WordPress, lisäosat, widgetit tai teemat.

Jos pengot tietokantaasi vaikka phpMyAdminin avulla, niin sinulla se ei välttämättä ole wp_ -alkuinen. Se on se, jonka olet asennuksessa merkinnyt tietokannassa käytettäväksi tunnisteeksi – jos et muista, niin voit tarkistaa sen wp-config.php -tiedostosta. Ja jos sinulla tunniste on tietokannassa mallia wp_NUMERO_ niin sinulla on asennettuna, tai on joskus asennettu, multisite. Numero viittaa ”alisivuston” ID-tunnukseen (löydät sen multisiten asetuksista) ja ”pääsivuston” taulut ovat ilman numeroita.

 

Kuvakaappauksesta näkyy myös, että taulussa jm_options on päälle 22 417 riviä. Se on _options -taululle turhan paljon, mutta muutoin se ei ole tolkuttoman paljon. Saman sivuston postausten metatiedoissa on lähes 750 000 riviä ja hakutoimintoa pyörittävällä Relevanssilla on lähemmäs 350 000.

autoload

Taulun wp_options kokoluokalla ja mitä kaikkea sinne on tallennettu, on merkitystä sivuston toiminnalle. Mutta yksi selvä pullonkaula löytyy kentästä autoload. Sillä on kaksi arvoa: yes ja no. Se määrittää ladataanko asia aivan jokaisella sivulatauksella vai ei. Ongelmaa on siinä, että osa lisäosien tekijöistä om hyvinkin vakuuttuneita siitä, että heidän ainoastaan yhdellä sivulla toimivansa lisäosa on ehdottomasti oltava mukana ladattavien joukossa aivan jokaikisellä sivulla. Vielä hullummaksi asia muuttuu, kun kyseessä on poistettu lisäosa tai teeman osa. Sitä ei edes ole enää ja silti se ladatuttaa asioita aivan jokaisella sivulla. Joku voisi kutsua moista jopa pahuksen huonoksi koodaukseksi.

Mutta on muistettava, että silti suurimman osan lisäosien ja teemojen koodareista osaa hommansa. Joku lomakelisäosa on ladattava joka paikassa, koska sitä voidaan käyttää ihan missä vain.

Tuota voidaan hieman penkoa. Se voidaan tehdä maanmainiolla Worpdressin komentokehotelaajennuksella WP-CLI. Jos sinulla ei ole sitä vielä, niin asenna ihmeessä. Toinen työkalu on raskaampaa sarjaa ja mainstreamiä: phpMyAdmin. Mennään molemmat läpi.

Mutta ennen kuin teet yhtään mitään, niin ota tietokannasta varmuuskopio haluamallasi tavalla. WP-CLI on ehdottomasti helpoin, koska riittää:

wp db export NIMI.sql

Jos jokin menee pieleen ja haluat palauttaa tietokannan varmuuskopion, niin se ei ole tätä vaikeampaa:

wp db import NIMI.sql

WP-CLI

Ensiksi tarvitaan yksi laajennus lisää, vaikka komennolla wp db tehdään suurin osa työstä. Asennetaan WP Doctor:

wp package install wp-cli/doctor-command

Voit vilkaista mitä se tarjoaa:

wp doctor list

Tutkitaan paljonko autoload on kerännyt dataa:

wp doctor check autoload-options-size

Kaikki mikä menee yli megan, on paljon. Puhumattakaan, kun sitä alkaa olla päälle kahdeksan megaa, kuten minulla oli Katiskassa. Mutta pelkkä koko ei kerro muuta kuin, että on tarvetta penkoa lisää. Täytyy tietää mitkä ovat vastuussa datan kertymisestä.

Saat TOP-10 rohmut selville tällä:

wp db query "SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM $(wp db prefix --allow-root)options WHERE autoload='yes' UNION SELECT 'autoloaded data count', count(*) FROM $(wp db prefix --allow-root)options WHERE autoload='yes' UNION (SELECT option_name, length(option_value) FROM $(wp db prefix --allow-root)options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)"

Joudut hieman miettimään omassa listassasi mitä mikäkin on. Osa on selviä, kuten että rewrite_rules on uudelleenohjauksia malliin 301 ja sen saa pienenemään poistamalla ainakin osan vanhemmista redirecteistä, tai siirtämällä ne .htaccess-tiedostoon. Saman kokoluokan paisuttaja on lisäosa WordPress Popular Posts, joka on tunnettu resurssisyöppö. Kannattaa miettiä tarvitseeko sitä aidosti.

Mutta kaksi nousee yli muiden ja pahin oli woothemes-sensei-upgrades. Kyseessä on Automatticin tekemä Learning Management System eli LMS – tai tutummin, verkkokoulutuslisäosa. Se, että se lataa itsensä joka kerta, on omalla tavallaan perusteltua. Verkkokursseja ja niihin liittyviä asioita voidaan esittää joka sivulla vimpaimina. Mutta hauskinta, tai pahinta, on se, että olen kokeillut Senseitä vuonna 2015, huonoksi todennut ja poistanut. Kokeilin sitä uudestaan vuosi sitten pari tuntia, edelleen huonoksi totesin ja poistin. Tätä kirjoitettaessa olen roikottanut pahimmillaan yli neljä vuotta tietokannassani jokaisella sivulatauksella hidastavaa lähes kuuden megan ylipainoa.

Toki voi todeta, että hyvä vaan, koska jos nyt asentaisin Sensein, niin saisin takaisin kaikki yli neljä vuotta sitten tekemäni kokeilujen asetukset – paitsi että tuo haiskahtaa kylläkin päivityksen jäljiltä jääneeksi roskaksi. Ammattinsa osaava koodari olisi laittanut joko option poistaa data uninstallissa tai edes ottaa autoload-kytkimen pois päältä. Mutta yritys, joka on onnistunut hidastamaan suurinta osaa maailman wordpress-sivustoista Jetpackin avulla, ei tullut moista ajatelleeksi. Tai ei ole piitattu. Tai ei ole osattu. Lopputulos on kuitenkin sama.

Ennenkuin tehdään radikaalimpi liike, niin vilkaistaan mitä woothemes-sensei-upgrades pitää sisällään. Kopioidaan se tekstitiedostoksi. Vaihda tilalle sinulla suurin tilanviejä (jos sellaista edes on, voihan sinulla olla kaikki hyvinkin).

wp option get woothemes-sensei-upgrades > /tmp/sensei.txt

Vilkaisuani tiedostoa, niin kyseessä oli versiopäivitykseen liittyvä asia. Joka on vielä pahempi, kuin että jos kyseessä olisi ollut verkkokurssin sisältöjä. Missään nimessä se ei tarvitse autoload='yes'. Joten muutetaan se arvoon no. Saman voi tehdä muillekin, jos olet aivan varma, että niitä ei tarvita jokaisella sivulla. Vaihda tilalle oikea nimi.

wp db query "UPDATE $(wp db prefix --allow-root)options SET autoload='no' WHERE option_name='woothemes-sensei-upgrades'"

Kun arvo muutetaan, niin riviä ei poisteta. Sitä ei vain ladata enää automaattisesti. Se kannattaa myöhemmin poistaa kokonaan, koska nyt se kasvattaa koko tietokannan kokoa. Mutta se on isompi projekti. Pystyt käyttämään SQL-lausekkeita wp db -komennon kanssa (jos osaat). Itse en luota niin paljoa omiin taitoihini, että alkaisin hahmottamaan komentoriviltä mitä tehdä ja mitä ei. Siinä tarvitsen graafisen liittymän, joka tarkoittaa phpMyAdminia.

Pidä kuitenkin mielessä, että poistat vain sellaisia, joita ei ole enää asennettuna. Ei edes päältä pois otettuina. Nimittäin pluginin tai teeman sammuttaminen ei ole poistamista ja koodari on sallinut tietokannan siivoaminen, niin se tehdään vasta kuin lisäosa tai teema poistetaan lopullisesti.

Ensiapuavaihe oli siinä. Seuraava vaihe olisi siivota ylipäätään turhat tietokannasta, ei pelkästään wp_options taulusta.

phpMyAdmin

Homma hoituu taulun wp_options kanssa hyvin samalla tavalla kuin WP CLI:n kanssa, mutta suoraan tietokannassa ja SQL-komennoilla.

Valitse tietokanta ja SQL-välilehdessä anna tämä (vaihda tunniste wp_ jos sinulla on jokin muu):

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

 

Paina nappia Go ja saat autoloadin koon.

Minulla se on tällä hetkellä 2,6 megaa, koska poistin edellisessä vaiheessa WP CLI:n avulla yhden turhakkeen.

Tehdään TOP-10 lista.

Valitse taas tietokanta, klikkaa SQL-välilehteä, anna tämä komento (muista wp_ joka riviltä jos tarpeen) ja ja paina Go:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

 

Omassa listassani suurin on _wp_session_list jolle en voi tässä tehdä mitään. Sen on oltava autoload='yes'.

 

Listassa on edelleen mukana turha, tosin pieni, sillä redux_builder_amp kuuluu lisäosalle Better AMP. Se on ainoa kohtuullisesti toimiva AMP-lisäosa, mutta sekin antoi virheitä. Ja koska en ollenkaan niin varma, että edes haluan AMP-sivuja, ellei Google tee siitä ehdotonta pakkoa, niin poistin sen. Silloin olisi myös AMP-sivut tehneet Reduxin pitänyt häipyä autoload-listasta – vaan ei hävinnyt. Koska on kuitenkin riskinä, että asennan sen myöhemmin uudestaan, enkä ole varma mitä tuon poistaminen autoloadista vaikuttaisi, niin pysykööt.

Sen sijaan aioseop_options. Se kuuluu aikaisemmin käyttämälleni All In One SEO -lisäosalla. Sen ei todellakaan kuulu olla tuolla enää, koska olen poistanut sen – tyypillinen esimerkki taas miten roskaa jää. Korvasin sen paljon paremmalla Math Rank SEO:lla. Joten jatketaan sen kanssa, vaikka se kooltaan aika merkityksetön onkin.

Löytyy toinenkin samanlainen, fusion_options. Sen on jättänyt Fusion page builder, jota käyttää mm. teema Avada – jota myös kokeilin aikoinaan.

Tässä vaiheessa tein testin. Muutin edellisessä komennossa määrän sataan. Ehdottomasti suurin osa oli jo poistetuista teemoista ja lisäosista, osa vuosia vanhoja. Ne ovat pieniä toki, mutta jokainen on liikaa. Täytyy mennä lista läpi jossain vaiheessa paremmalla ajalla.

Siivotaan wp_options

Palataan hieman taaksepäin. Klikkaa tietokantaa, avaa SQL-välilehti, laita tämä ja paina Go:

SELECT * FROM `wp_options` WHERE `autoload` = 'yes'

Saat listauksen aivan kaikista wp_options taulun riveistä, joilla autoload on arvossa yes. Niitä voi olla aika monta. Saattaa olla ehkä helpompaa, jos kasvatat yhdellä sivulla näytettävien osumien määrä oletuksesta 25 sopivan suureen. Itse laitoin 500.

Ennenkuin jatketaan, niin olethan aivan varmasti ottanut tietokannasta varmuuskopion?

Saat muokattua riviä joko edit-nappulan kautta, tai helpommin klikkaamalla arvoa ja muuttamalla sen käsin muotoon no, jos haluat vain estää autoloadin.

Voit muuttaa suoraan autoload-arvon muotoon no, jos sitä ei tarvitse todellakaan ladata joka sivulla. Mutta silloin sinun täytyy kehittää keino ladata se oikealla sivulla. Siksi kannattaa jättää rauhaan sellaiset, jotka ovat toiminnassa ja säätää asioita myöhemmin jollain sopivammalla tavalla – kuten asentaa jokin plugin, joka säätää muiden lisäosien toimintaa. Toinen vaihtoehto on muokata lisäosan koodia, eikä se on sarjaa hyvät ideat.

Voit poistaa rivin kokonaan, jos siihen viittavaa lisäosaa tai teemaa ei enää ole. Klikkaa vain kohtaa delete ja vahvista, että haluat poistaa.

Nyt kannattaa kuitenkin hetki hengähtää ennen urakkavauhtia. On nimittäin mahdollista, että lisäosan/teeman omissa asetuksissa oli ohjeet miten poistaminen täytyy tehdä – kuten laittaa rasti ruutuun, ennen kuin pysäyttää ja poistaa. Jos se on poistettu käyttäjän puolelta väärin, niin sitten muihin tauluihin jää roskaa. Joten kannattaa tehdä pieni (no, ei se ole pieni, jos niitä on monta) googletuskierros ensin.

Minulla oli vuosia sitten ensimmäisenä verkkokauppana WordPress eStore. Oli aikoinaan ihan näppärä ja itseasiassa digitaalisten tuotteiden myymisessä paljon parempi kuin Woocommerce (joka siihen aikaan oli… ei niin hyvä). Mutta Woocommerce kehittyi ja laajeni, eStore ei. Nykyäänhän Woocommerce on ainoa järkevä vaihtoehto. Easy Digital Downloads on hyvä nimenomaan digitaalisten tuotteiden myymiselle, mutta sille ei ole samaa laajennettavuutta – mutta se tulee perässä ja on hyvä vaihtoehto.

Vaihtaessani eStoreen se jätti itsensä tietokantaan. Rehellisyyden nimissä en muista oliko se siihen aikaan haluttua, koska en ollut varma pysynkö Woocommercessa ja vanhojen tilausten siirto oli silloin maallikolle mahdottomuus – joten saatoin hyvinkin jättää itselleni takaportin. Lopputulos on kuitenkin se, että nyt vuosien jälkeen se on vain painolastia.

Joten mennään läpi miten suodatetaan vain halutut näkyviin.

Muuta komentoon itsellesi sopivat:

SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%eStore%'

Minä sain 33 riviä, joista jokainen lisäksi oli autoload='yes'.

Tarkistin, että kaikki löydetyt rivit olivat sellaisia, jotka halusin pudottaa. Sivun alareunasta sain merkittyä kaikki valituiksi, painoin delete-nappulaa ja hyväksyin poiston. Se oli siinä.

Jos sivusto on ollut kauemmin pystyssä, ja on kokellut tai joskus jopa käyttänyt kaikennäköistä, joista on sittemmin luopunut, niin wp_options on taatusti rajusti ylikansoitettu. Sen siivoamiseen saa varata reippaasti aikaa. Mutta se aika kannattaa itselleen varata.

_wp_session_

Minulla on ongelma _wp_session_ -rivien kanssa. Niitä on 16489 riviä tätä kirjoitettaessa ja paisuttavat huomattavasti wp_options taulun kokoa – enkä tiedä aivan varmasti mitä niille pitäisi tehdä. Tosin, googletuksen perusteella osalla voi olla satoja tuhansia, joka miljoonia rivejä, eivätkä ne sinällään haittaa – ellei jokin lisäosa, jonka virhetoiminto tuollaiset määrät generoi, aiheuta ongelmia.

Nähdäksesi paljonko sinulla on _wp_session_ -rivejä, niin komenna tämä:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

En aidosti tiedä mitä _wp_session_ -sisältää. Ilmeisesti evästeiden tietoja ja niiden pitäisi sitten ajan myötä hävitä cronin avustuksella.

Kysymys kuuluu: paljonko on liikaa ja mitä tapahtuu, jos poistan ne? En tiedä vastausta, mutta jos ne liittyvät jotenkin evästeisiin, niin voisin kuvitella, että ainakin kirjautuneet lentävät ulos. Koska känsöittyneet kantapäät ovat paras tapa opetella asioita, niin kokeilen.

Ensin backuppasin tietokannan ja nyt ajan tämän:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Katsotaan mitä tapahtuu.

Ei tapahtunut yhtään mitään. Tai tapahtui, sillä tietysti wp_options taulun koko sekä varsinkin autoload-osan koot romahtivat. Ilmeisesti _wp_session_ kannattaa siivota aika ajoin, sillä melkoisen helposti löytää ohjeet, jolla tyhjennyksen saa automatisoitua.

Mutta sivusto ei myöskään nopeutunut silmämääräisesti yhtään, joten ei tuolla suurtakaan mitattavaa hyötyä ollut. Tosin admin-puolellahan näiden pitäisikin eniten vaikuttaa ja ehkä se hiukan nopeutui. Mutta onpahan siivottu nyt.

index ja autoload

Autoload ei ole ideksoitu. Indeksi on ikäänkuin tietokannan sisäinen sisällysluettelo. Kun index puuttuu, niin haettaessa joudutaan menemään kaikki rivit läpi. Ja se vie sitten einen aikaa, varsinkin jos rivejä on paljon. Siksi viisaammat ovat sanoneet, että indeksi on syytä lisätä.

Kuten aina, niin tähänkin löytyy lisäosa. Mutta sen voi tehdä käsinkin.

WP-CLI

Katsotaan, että indeksiä ei ole asetettu.

wp db query "SHOW INDEX FROM $(wp db prefix --allow-root)options;"

Jos Column_name sarakkeessa on autoload ja sille on ideksiarvo, niin index on jo asetettu ja kaikki on siltä osin kunnossa sekä valmiina. Mutta jos sitä ei näy, niin indeksi puuttuu ja se olisi asetettava.

Vaikka indeksiä hehkutetaankin, niin siitä on ilmeisesti hyötyä vain, jos arvoja autoload='no' on iso osa suhteessa arvoon yes. Tai jos autoload on ylipäätään iso, google antaa erilaisia näkemyksiä, mutta jopa pienilläkin, vain muutaman sadan rivin autoload-määrillä on saatu tehostettua MySQL:n toimintaa – joka tarkoittaa, että kuorma on pienentynyt. Peukalosääntö no-arvojen määrälle on kuitenkin 60 -80 %, että index tarvitaan. Selvitetään se.

Katsotaan ensin paljonko on arvolla yes:

wp db query "SELECT COUNT(CASE WHEN autoload = 'yes' THEN 1 END) FROM $(wp db prefix --allow-root)options; --allow-root"

–allow-root on esimerkissä mukana, jos olet root-tunnuksella, ja on helpompi laittaa molemmat mukaan kuin muistuttaa mihin ne kuuluvat. Jos olet omalla tunnuksella, niin ne eivät haittaa.

Vaihdetaan arvoksi no ja katsotaan niiden määrä:

wp db query "SELECT COUNT(CASE WHEN autoload = 'yes' THEN 1 END) FROM $(wp db prefix --allow-root)options; --allow-root"

Omassa esimerkissäni arvo no on noin 60 %, joten indeksin lisääminen olisi perusteltua. Jos olen oikein ymmärtänyt, niin kun autoload='yes' on alempi, niin index ei haittaa, mutta siitä ei ole hyötyäkään.

Lisätään index.

wp db query "CREATE INDEX autoloadindex ON $(wp db prefix --allow-root --skip-plugins --skip-themes)options(autoload, option_name);" --allow-root

Jos joskus haluat indeksin pois, niin se tehdään tällä:

wp db query "DROP INDEX autoloadindex ON $(wp db prefix --allow-root)options" --allow-root

MySQL

En selitä vaiheita sen enempää, vaan laitan ainoastaan vastaavat esimerkit. Muista vaihtaa wp_ sinulle oikeaksi, jos on tarpeen.

Tarkistetaan onko index asennettu:

SHOW INDEX FROM wp_options

Katsotaan yes määrät:

SELECT COUNT(CASE WHEN autoload = 'yes' THEN 1 END) FROM wp_options;

Katsotaan no määrät:

SELECT COUNT(CASE WHEN autoload = 'no' THEN 1 END) FROM wp_options;

Asetetaan indeksi:

CREATE INDEX autoloadindex ON wp_options(autoload, option_name);

Ja indeksin saa pois näin:

DROP INDEX autoloadindex ON wp_options

Koodareista

Olen pariinkin kertaan arvostellut koodareita ja kehittäjiä siitä, että tietokanta paisuu. En muuta näkemystäni sen suhteen, mutta ymmärrän osaksi ongelman taustalla.

Jos kaikki poistetaan, kun lisäosa tai teema poistetaan, niin ollaan ongelmissa hyvinkin nopeasti erittäin yleisessä tilanteessa; kun selvitetään lisäosien tai teemojen välisiä konflikteja. Moni poistaa vakavimmissa tilanteissa rutiinisti plugins-hakemiston muuttamalla sen nimen ja kirjautumalla uudestaan WordPressiin. Siinä vaiheessa sivusto on sitä mieltä, että lisäosat on poistettu. Jos siitä seuraisi, että kaikki tiedot häviäisivät samalla tietokannasta, niin uudelleenkäynnistyksessä oltaisiin kuin ihkauuden asennuksessa – joutuisi antamaan lisenssit ja laittamaan kaikki asetukset uudestaan. Ei sekään toimiva ratkaisu ole.

Joskus lisäosa otetaan muista syistä pois pidemmäksi aikaa ja siihen palataan joskus uudestaan. Kun tiedot ovat valmiina tietokannassa, niin jatketaan siitä mihin aikoinaan on jääty,

Tuo kaikki ei kuitenkaan poista sitä tosiasiaa, että käyttäjällä täytyy olla vaihtoehto poistaa kaikki niin, että roskaa ei jää. Ollaan aika kestämättömässä tilanteessa jos aktiivisen sivuston wp_options taulu on suurempi kuin artikkelit 10 vuoden jälkeen. Eikä kyse ole pelkästään tietokannasta. Vilkaistaan hakemistopuolta, niin wp-content alkaa olla hassun paljon täynnä kansioita, joita lisäosat eivät tuhoa poistossa.

Osassa lisäosia on nykyään optio poistaa kaikkia, jos luopuu sen käytöstä. Silloin on käyttäjän vastuulla muistaa rastittaa se ennen poistoa. Jos sen unohtaa, niin voivoi eikä paljoa myötätuntoa heru – ymmärrystä kylläkin hiukan.

Osalla lisäosista on dokumentoitu miten oikeaoppinen poisto täytyy tehdä. Vilkaiskaa joskus vaikka All In One SEO:n ohjeita ja sanokaa vakavalla naamalla, että se on käyttäjäystävällinen tapa. Automattic on myös varmistanut, että Woocommerce ei ihan hevillä poistu systeemistä. Jetpack jättää aivan tolkuttomasti itsestään tietokantaan poiston jälkeen – ja uudelleenasennuksessa on kuitenkin käyttäytyvinään kuin oltaisiin uusia tuttavuuksia.

Tuo kaikki on huonoa koodausta ja surkeaa UX:ää.

Lopuksi

Pelkästään tietokannan optimoinnilla ei saada hitailla sivustoilla nopeutta lisää. Yleensä syyt ovat perustasolla, kuten

• hitaassa teemassa,
• liioissa lisäosissa
• liian isoissa kuvissa
• miettivässä serverissä

mutta tietokanta on kuitenkin merkityksellinen ja kun kaikki muu on tehty, niin se siivotaan ja optimoidaan. Merkitys on selvin nimenomaan admin-puolen vauhdille. Siellä kannattaa muuten olla esittämättä ohjausnäkymässä kaikkia mahdollisia tilastoja, niistä jokainen hidastaa.

wp_options taulu on tärkeä yksittäinen, mutta orpoja poistettujen lisäosien ja teemojen roskia löytyy muistakin tauluista. Niidenkin kohdalla täytyy muistaa, että poista vain jos et koskaan tarvitse vanhoja tietoja ja asetuksia.

Saat tehtyä siivouksen muissa tauluissa toki wp db -komeinnoilla tai phpMyAdmin avulla, mutta helpoin ja näppärin lienee kääntyä lisäosien puoleen. Tämä on ollut tehokas:

https://fi.wordpress.org/plugins/advanced-database-cleaner/

Ai niin.

En minä ole koodari, enkä devaaja. Tietokannoista tiedän aina välttämättömimmät perusteet. Olen tehnyt kaikki esittelemäni asiat useammallekin live-sivustolle, mutta en todellakaan ole keksinyt niitä.

Tämä juttu on rajusti velkaa näille kahdelle:

• Kinsta: Kuinka siivota wp_options-taulukko ja automaattisesti ladattu data
• WP Bullet: Using WP-CLI doctor Command to Fix Large wp_options autoload Data