WooCommerce hooldus

Miks WooCommerce vajab teistsugust hooldust

Tavalisel WordPressi saidil on halvim stsenaarium tavaliselt see, et leht näeb uuenduse järel veidi katki välja. E-poes on halvim stsenaarium see, et klient ei saa maksta — ja seda ei pruugi keegi märgata enne, kui vaatad läbi tellimuste arvu ja mõistad, et see langes järsult eile pärastlõunal, täpselt uuenduse ajal.

Seetõttu ei piisa WooCommerce'i puhul „uuenda ja vaata, kas avaleht laeb". Iga uuendus vajab testi, mis läbib päris ostuprotsessi otsast lõpuni: toote lisamine korvi, kupongikood, tarneviisi valik, makse ja kinnitusleht.

Checkout ja maksed

Eesti e-poodides käivad maksed tavaliselt läbi mõne kohaliku vahenduslahenduse — Maksekeskus, Montonio või Every-Pay — mõnikord lisaks ka Stripe rahvusvahelistele kaartidele. Iga selline liides on eraldi plugin, mis suhtleb API kaudu välise teenusega, ja see on täpselt see koht, kus WordPressi tuuma või PHP versiooni uuendus kõige valusamalt katki võib minna.

Meie checkout'i kontroll pärast igat uuendust:

• Test-tellimus otsast lõpuni, päris makselahendusega (testrežiimis, kui pakkuja seda toetab)
• Tagasisuunamine pärast makset — kas kinnituslehele jõutakse, kas tellimuse staatus uueneb
• E-kirja kinnitused kliendile ja poe omanikule
• Kupongikoodid ja tarneviiside arvutus, kui neid poes kasutatakse

WP-Cron ja taustaprotsessid

WordPress ei kasuta päris serveri cron'i, vaid oma WP-Cron mehhanismi, mis käivitub külastaja päringu peal — kui saidil käiakse harva, ei pruugi taustatööd üldse käivituda. WooCommerce'is toetub sellele mitu olulist protsessi:

• Ootel tellimuste automaatne tühistamine, kui makse jääb pooleli
• Laoseisu ja hinnamuudatuste sünkroniseerimine, kui pood on ühendatud mõne teise süsteemiga
• Meeldetuletus- ja teavituskirjad (nt hüljatud ostukorv, kui vastav plugin on kasutusel)

Suurema liiklusega poodides seadistame päris serveri cron'i (crontab), mis käivitab WP-Cron'i usaldusväärselt kindla intervalliga, selle asemel et sõltuda juhuslikest külastustest.

PHP versioon ja serveri ressursid

WooCommerce on PHP-mahukam kui tavaline WordPress — iga tootekaart, filter ja korvi arvutus lisab töötlemist. Kaks seadistust, mis kõige sagedamini liiga madalaks jäävad:

• memory_limit — kui see on liiga väike, katkeb suurte tellimuste või paljude toodetega lehtede laadimine valge lehega, ilma selge veateateta
• max_execution_time — liiga lühike aeg katkestab pikemad protsessid, näiteks suure toote-impordi või laoseisu massuuenduse

Samuti jälgime PHP versiooni ise: iga uus WordPressi ja WooCommerce'i versioon eeldab teatud PHP miinimumi, ja liiga vana PHP tähendab nii turvariski kui ka aeglust — uuemad versioonid on olulisel määral kiiremad, mitte ainult turvalisemad.

Andmebaas ja HPOS

E-poe andmebaas kasvab teisiti kui tavalisel saidil — iga tellimus, iga staatusemuutus ja iga logi jääb sinna alles. WooCommerce on viimastel aastatel liikumas HPOS-i (High-Performance Order Storage) peale, mis hoiab tellimusi eraldi, optimeeritud tabelites, mitte tavaliste postituste seas — see on märgatavalt kiirem suure tellimuste hulgaga poodides.

Üleminek HPOS-ile ei ole midagi, mida tuleks teha kontrollimatult: osad vanemad pluginad (eriti raamatupidamise- ja laoliidesed) ei pruugi seda veel täielikult toetada. Kontrollime enne üleminekut plugina-ühilduvuse ja teeme selle sammu koos täisvarukoopiaga.

Lisaks HPOS-ile käib tavapärane andmebaasi hooldus: vanade tellimuste ja logide koristus, revisjonide puhastus, indeksite kontroll — paisunud andmebaas aeglustab nii admini kui ka poe enda töökiirust.

Vahemälu ja e-pood

Tavaline lehekülje vahemälu (page cache) on e-poes ohtlik, kui see on valesti seadistatud — ostukorvi- ja checkout-lehed ei tohi kunagi vahemälust tulla, muidu näeb üks klient teise ostukorvi sisu või vana laoseisu. Õige seadistus:

• Ostukorv, checkout, „minu konto" ja tänulehed jäävad vahemälust täielikult välja
• Tootelehed ja kategooriad võivad olla vahemälus, aga peavad tühjenema laoseisu muutudes
• Fragment-vahemälu (nt korvi ikoon peamenüüs) uueneb AJAX-i teel, isegi kui ülejäänud leht on vahemälust

See on kõige levinum koht, kus näeme kiiruse pluginat ja WooCommerce'i konfliktis — kellegi tehtud „kiirem sait" osutub poeks, mis müüb toodet, mida enam laos ei ole. Vaata ka kiiruse optimeerimist laiemalt.

Pluginakonfliktid

E-poel on tavaliselt rohkem pluginaid kui infosaidil — makselahendus, tarneviisid, laohaldus, arveldus, mõnikord ka WPML. Iga lisaplugin tähendab rohkem kohti, kus üks uuendus võib teise lõhkuda. Meie protsess:

1. Täisvarukoopia enne iga uuendust — failid ja andmebaas
2. Uuendused tehakse esmalt testkeskkonnas suuremate poodide puhul
3. Checkout ja põhifunktsioonid testitakse käsitsi pärast uuendust
4. Kui midagi läheb katki, pööratakse tagasi ja probleem lahendatakse eraldi, mitte kiirustades

WPML ja mitmekeelsus

Paljud Eesti e-poed müüvad ka Soome, Läti või vene keeles ja kasutavad selleks WPML-i. Mitmekeelsetel poodidel on omaette murekohad: tõlgitud tooteversioonid lähevad tuuma- või plugina uuendusega mõnikord lahku, stringitõlked kaovad pärast teema uuendust, või valuutakursid jäävad uuendamata. Kui sinu poel on mitu keelt, kontrollime pärast igat uuendust, et ka tõlgitud versioonid töötaksid, mitte ainult põhikeel.

Turvalisus e-poes

E-poes liigub rohkem tundlikku infot kui tavalisel saidil — nimed, aadressid, tellimuste ajalugu. Oluline on aru saada tööjaotusest: maksekaardi andmeid ei näe ega salvesta WooCommerce ise — need liiguvad otse maksevahendaja (Maksekeskus, Montonio, Stripe) turvalise liidese kaudu, mis vastutab PCI-nõuete täitmise eest. Meie vastutame selle eest, mis jääb sinu serverisse:

• Kliendiandmete (nimed, aadressid, tellimuste ajalugu) turvaline hoiustamine
• Ligipääsuõiguste ülevaatus — kellel on adminõigused ja kas need on veel vajalikud
• Tulemüür ja pahavaraskann samamoodi nagu tavalisel WordPressi saidil — vaata WordPressi turvalisust

Mida meie WooCommerce hoolduses konkreetselt teeme

• Täisvarukoopia enne iga uuendust, failid ja andmebaas eraldi
• Checkout'i käsitsi test pärast igat uuendust — mitte ainult „leht laeb"
• WP-Cron'i toimimise kontroll, vajadusel serveripoolne cron
• PHP versiooni ja ressursipiirangute jälgimine
• Andmebaasi koristus ja HPOS-i ühilduvuse kontroll
• Vahemälu seadistus, mis ei riku ostukorvi ega laoseisu kuvamist
• Mitmekeelsete versioonide test, kui poes on kasutusel WPML

See kuulub meie Business paketi sisse — vaata täpset sisu ja hinda teenuselehelt . Kui sul on juba hoolduspartner, aga checkout katkeb ikka aeg-ajalt uuenduste järel, on hea esimene samm kiiruse audit — mõõdame, kus probleem täpselt on.

Korduma kippuvad küsimused

Kas tavaline WordPressi hooldus ei kata ka WooCommerce’i?

Osaliselt. Tuuma ja pluginate uuendamine käib samamoodi, aga e-poel on lisaks kihte, mida tavalisel infosaidil pole: makselahendus, ostukorv, laoseis, tellimuste andmebaas. Neid tuleb pärast igat uuendust eraldi testida.

Kas te toetate ka mõnda muud e-poe platvormi peale WooCommerce’i?

Meie fookus on WordPress ja WooCommerce — seal saame olla päriselt tehnilised, mitte pealiskaudsed. Kui sul on teine platvorm, küsi julgelt, aga täpsustame kohe, kas oskame aidata.

Kas HPOS (High-Performance Order Storage) tuleb sisse lülitada?

Uutel poodidel jah — see on WooCommerce’i enda soovitatud suund ja parandab jõudlust suure tellimuste hulga korral. Vanematel poodidel tuleb üleminek plaanida ja testida, sest osad pluginad ei toeta seda veel täielikult.

Mis saab, kui checkout läheb uuenduse järel katki?

Sellepärast me testime checkout’i iga uuenduse järel käsitsi, mitte ainult automaatse skriptiga. Kui midagi on katki, pöördume kohe eelmise versiooni juurde tagasi ja lahendame probleemi eraldi, enne kui uuesti proovime.