Mit tartalmaz egy WooCommerce webáruház karbantartása?

Amikor a bolt elkészül, működik a kosár és megérkeznek az első rendelések, könnyű azt hinni, hogy a munka neheze lezárult. Egy WooCommerce webáruház karbantartása egy rendszeres feladat, ami sokkal többről szól, mint időnként rákattintani egy frissítés gombra. Nézzük végig, mi minden tartozik bele a gyakorlatban, és hol dől el, hogy a bolt hónapokig gördülékenyen fut, vagy egy rossz reggelen egyszer csak nem enged fizetni a vásárlóknak.

Miért nem „kész” soha egy webáruház?

A legtöbb félreértés abból ered, hogy a kész oldalt statikus dolognak látjuk. Betölt, működik, tehát rendben van. A háttérben viszont folyamatosan mozgásban van egy meglehetősen összetett gépezet. Egy WooCommerce webáruház nem egyetlen program, hanem egymásra épülő rétegek sora: legalul a WordPress alaprendszer, arra épül a WooCommerce, mellette futnak a fizetési és szállítási bővítmények, a sablon, és jellemzően még egy tucatnyi kisebb plugin. Ezek külön fejlesztők kezében vannak, külön ütemben kapnak frissítést, és folyamatosan hatnak egymásra. Ez az összefonódás az oka, hogy a karbantartás nem egyszeri feladat, hanem rendszeres odafigyelés kérdése.

A frissítés nem opció, de a vak frissítés kockázat

A frissítéseket sokan halogatják, mert nem látszik belőlük semmi, és jónak tűnik a „ha működik, ne nyúlj hozzá” elv. A baj az, hogy egy webáruháznál ez pont fordítva igaz. A régi, frissítetlen bővítmények a leggyakoribb támadási felület, mert az ismert biztonsági réseket a fejlesztők épp a frissítésekkel foltozzák be. Ha kihagyod őket, nem stabil maradsz, hanem sebezhető.

Amit érdemes pontosítani, hogy nem a frissítés maga a kockázat, hanem a tesztelés, ellenőrzés nélkül, élesben futtatott frissítés. Egy WooCommerce nagyverzió időnként hozzányúl az adatbázis szerkezetéhez, egy bővítmény új verziója pedig összeakadhat egy másikkal vagy a sablonnal. Ilyenkor fordul elő, hogy ami tegnap hibátlanul vitte a rendeléseket, ma fehér képernyőt vagy hibás pénztárt mutat. Ezért jó az a gyakorlat, hogy a frissítés nem az éles boltban történik először, hanem egy másolaton vagy tesztkörnyezetben, és csak azután kerül élesre, hogy ott lefutott. Utána pedig jön a kézzel fogható ellenőrzés: betölt-e a termékoldal, a kosárba tétel, a pénztár és a fizetés. Fontos az is, hogy a PHP verziója, amin a szerver fut, összhangban legyen azzal, amit a WooCommerce aktuális kiadása elvár, különben az egyébként hibátlan frissítés is elhasalhat.

Amit nem mentesz el visszaállítható módon, azt elveszítheted

Tegyük fel, hogy egy frissítés mégis félresikerül, vagy egy támadó bejut a rendszerbe. Ilyenkor egyetlen dolog számít: van-e friss mentésed, amit tényleg vissza is tudsz állítani. A biztonsági mentésnél ugyanis nem elég, hogy létezik egy fájl valahol. Egy WooCommerce boltnál a rendelések, a vásárlói adatok és a beállítások jó része az adatbázisban él, míg a képek, a sablon és a bővítmények a fájlrendszerben. Egy használható mentés mindkettőt tartalmazza, összehangolt állapotban, különben visszaálláskor épp a friss rendelések vagy a beállítások hiányoznak majd.

A gyakoriság sem mindegy. Ha egy féléves mentést állítasz vissza, minden azóta beérkezett rendelés és feltöltött termék eltűnik, ami egy élő boltnál kész katasztrófa. Egy napi, automatikus, a szervertől külön helyen, felhőben tárolt mentéssel viszont a legrosszabb esetben is csak néhány órányi adat vész el, nem hónapok munkája. És mivel a mentés a szervertől függetlenül is elérhető, akkor is megvan, ha magával a tárhellyel van a baj.

Mitől lassul be egy webshop, és miért drága ez?

A sebesség nem esztétikai kérdés, hanem közvetlenül a bevételről szól. Ha egy termékoldal lassan tölt be, a vásárló általában nem ír panaszos emailt, egyszerűen visszalép és a következő boltnál vásárol. A Google emellett a betöltési élményt (a Core Web Vitals mutatókat, például a legnagyobb tartalmi elem megjelenési idejét) rangsorolási tényezőként is figyeli, tehát a lassú bolt nemcsak a meglévő látogatót veszíti el, hanem nehezebben is talál új vásárlót.

A gond az, hogy a webshop magától lassul be. Ahogy gyűlnek a termékek és a képek, ahogy szaporodnak a bővítmények, és ahogy az adatbázis tele lesz lejárt átmeneti adatokkal, elhagyott kosarakkal és régi napló-bejegyzésekkel, az oldal fokozatosan elnehezül anélkül, hogy egy pillanatnyi változást látnál. Ezért kell a sebességet rendszeresen mérni, nem csak induláskor, és időről időre karban tartani: takarítani az adatbázist, optimalizálni a képméreteket, és rendben tartani a gyorsítótárazást. Van azonban a sebességnek egy rétege, ami már nem a bolton múlik, hanem a szerveren, amin fut. A Sybell Hostingnál például a szerverek LiteSpeed alapon működnek, ami épp a WordPress és a WooCommerce gyors kiszolgálására van kihegyezve, és a hozzá tartozó gyorsítótárazással sokat behoz abból, amit egyébként kézzel kellene optimalizálni. Ez az az alap, amire aztán a saját munkád érdemben ráépülhet.

A csendben elromló részletek: SSL, linkek, fizetés

Eddig a nagy, jól látható dolgokról volt szó. A karbantartás nehezebb fele viszont pont az, ami csendben romlik el, gyakran úgy, hogy napokig nem tudsz róla. Ilyen az SSL tanúsítvány, ami a titkosított kapcsolatot és a címsorban a lakatot adja. A mai tanúsítványok jellemzően rövid, néhány hónapos érvényűek és automatikus megújításra vannak állítva, de ez az automatizmus időnként elakad. Ha lejár és nem újul meg, a látogató egy „nem biztonságos” figyelmeztetést kap, ami egy webshopnál a bizalom azonnali elvesztése. Rokon probléma a kevert tartalom is, amikor a titkosított oldalon egy régi, titkosítatlan hivatkozáson keresztül tölt be egy kép vagy szkript, és emiatt panaszkodik a böngésző. Ide tartoznak a törött linkek is, amelyek egy termék törlése, egy átalakítás vagy egy megváltoztatott hivatkozás után keletkeznek, és 404-es zsákutcába vezetik a vásárlót meg a keresőt egyaránt.

És ide tartozik a legérzékenyebb pont, a fizetési kapu. Ez nemcsak akkor romolhat el, ha maga a szolgáltatás áll le, hanem akkor is, ha a fizetési szolgáltató visszahívása, vagyis a sikeres tranzakciót visszaigazoló háttérüzenet nem ér célba, és emiatt a rendelés fizetettként sem rögzül. A baj természete pont az, hogy nem kapsz róla riasztást, csak a kimaradt bevételen látod utólag.

Összefoglalva: a karbantartás nem esemény, hanem folyamat

Ha végignézünk a fentieken, egy dolog rajzolódik ki tisztán. Egy WooCommerce webáruház karbantartása nem egyszeri feladat, amit letudsz egy délután, hanem folyamatos állapot. A boltnak folyamatosan karban kell lennie tartva, figyelve kell rá lenni, és rendszeresen ellenőrizni kell a részeit: lefutottak-e a frissítések, működik-e utánuk a pénztár, megvan-e a friss mentés, él-e az SSL, nincs-e törött link. Ezek egyenként pár perces mozdulatok, együtt viszont havonta visszatérő, figyelmet igénylő rutin, amit nem lehet elfelejteni anélkül, hogy előbb-utóbb meg ne bosszulná magát.

És itt jön a lényeg, amiről kevesen beszélnek. Ez a rutin időigényes, és őszintén szólva nem a vállalkozás vezetőjének a dolga. Neked a termékkel, a vásárlókkal és a bevétellel kell foglalkoznod, nem azzal, hogy egy plugin frissítése után miért fehér a pénztár oldala. A karbantartás olyan feladat, amit érdemes átadni valakinek, aki ezt csinálja nap mint nap, és aki akkor is figyel a boltra, amikor neked épp máshol jár az eszed.

Bízd ránk, és a webáruház magától is jó kezekben van

Pontosan ezért vezettük be karbantartási szolgáltatásunk. Ebben mi vigyázunk az oldalra: rendszeresen frissítjük a WordPress alaprendszert, a WooCommerce-t és a bővítményeket, minden frissítés után teszteljük a bolt fontos részeit, a termékoldaltól a pénztárig, rendszeresen mentést készítünk felhőbe, és ha valahol hiba lép fel, kijavítjuk, mielőtt az a bevételbe kerülne. A lényeg, hogy nem neked kell fejben tartanod, mikor mit kell ellenőrizni, mert ezt mi levesszük a válladról.

Így a boltod nem attól működik, hogy neked épp van időd figyelni rá, hanem mert tényleg figyel rá valaki. Te a vállalkozásodra koncentrálsz, a többit pedig nyugodtan ránk bízhatod.