Kada je WooCommerce-u potrebna custom logika, a kada nije

Beleška s terena / Odluke u prodavnici

Većina prodavnica treba dobro da podesi WooCommerce i osloni se na jedan dobro održavan plugin. Custom kod zaslužuje svoje mesto tek kada je pravilo specifično za način na koji taj biznis radi i kada mora da bude tačno na svakoj porudžbini. Odlučujuće pitanje nikada nije „može li to da se iskodira”, nego „da li je ovo poslovno pravilo koje nikada ne sme da se raziđe sa onim što sajt obećava, ili preferencija u prikazu koje bismo se mirno odrekli sledeće sezone”.

Sve ostalo je računica i iskrenost. Slede pitanja koja u praksi rešavaju odluku, onim redom kojim ih postavljamo kada vlasnik prodavnice dođe sa pravilom koje WooCommerce podrazumevano ne pokriva.

Poslovno pravilo ili preferencija u prikazu?

Poslovno pravilo odlučuje o novcu ili o pravu na kupovinu: ko plaća dostavu, koje porudžbine traže dodatnu proveru, koji kupac vidi koju cenu, sme li porudžbina uopšte da prođe. Preferencija u prikazu odlučuje kako nešto izgleda: oznaka na kartici proizvoda, redosled načina plaćanja, još jedan red u korpi.

Razlika je bitna zato što poslovno pravilo mora da bude zapisano na jednom mestu. Čim isto pravilo živi na dva mesta, kao rečenica na stranici o dostavi i kao broj ukucan u podešavanja plugina, ono počinje da se razilazi. Neko izmeni stranicu tokom kampanje, niko ne dira podešavanje, i prodavnica sada obećava jedno, a naplaćuje drugo. Svaki sat podrške posle toga plaća prodavnica, a kupac pamti nesklad, ne izvinjenje.

Preferencije u prikazu ne nose taj rizik. Ako je oznaka pogrešna, kupac vidi pogrešnu oznaku. To se rešava u template-u, pluginu ili opciji teme. Ništa u tome ne opravdava pisanje custom logike na naplati.

Prebrojte plugine, pa prebrojte godine

Plugin deluje jeftinije nego što jeste, jer je licenca jedini broj koji se pojavi na fakturi. Stvarni trošak čine licenca, sati potrošeni na proveru i podešavanje, još jedan pokretni deo koji može da pukne kada izađe novo izdanje WooCommerce-a i trajna zavisnost od tuđeg plana razvoja. Ništa od toga ne znači da su plugini loša ideja. Znači samo da plugin nije besplatan podrazumevani izbor, nego odluka koja ima svoju cenu.

Ono što najbolje predviđa buduće probleme jeste broj plugina koje pravilo zahteva:

• Jedna aktivno održavana ekstenzija pokriva celo pravilo: kupite je i idite dalje.
• Dve, pri čemu druga postoji uglavnom da ispravi ponašanje prve: dobro pogledajte pre nego što se obavežete.
• Tri ili više, sa podešavanjima koja protivreče jedno drugom i ishodom koji zavisi od redosleda učitavanja: pravilo je sada posledica vaše liste plugina i niko ne može da ga predvidi.
• Ekstenzija čije je poslednje izdanje starije od vaše verzije WooCommerce-a: to nije rešenje, to je zakazani incident.

Druga osa je obnova licence. Licenca je godišnja odluka koju donosite dokle god pravilo postoji, a cenu obnove određuje neko drugi. Custom kod ima jednokratni trošak izrade i mali trajni trošak održavanja. Tokom tri ili četiri godine te se dve linije ukrste češće nego što vlasnici prodavnica očekuju, naročito kada je pravilo stabilno, a plugin nije.

Katalog ili naplata: gde pravilo mora da važi?

Pravilo koje oblikuje samo katalog jeste problem prikaza. Ako je pogrešno, neko vidi pogrešan filter, pogrešan redosled, pogrešnu oznaku. Pravilo na naplati je sasvim druga stvar: ono odlučuje o iznosu, dostavi, porezu, pravu na kupovinu i o trajnom zapisu onoga što je kupac pristao da kupi. To je granica na kojoj custom logika na naplati prestaje da bude pogodnost i postaje pitanje tačnosti.

Pravila na toj granici pripadaju serveru, na podržanim WooCommerce hook-ovima. Ne u JavaScript-u na stranici, jer se svakom browseru može reći da ga ignoriše. Ne u kopiranom template fajlu, koji će tiho prestati da se izvršava onog dana kada se tema ažurira i povući pravilo sa sobom.

U JC Jewelers WooCommerce prodavnici besplatna dostava preko 1.999 dolara i verifikacija identiteta preko 1.000 dolara nisu tekst na stranici, nego komercijalna pravila. Žive u logici naplate, a tekst na sajtu čita iste vrednosti, pa broj koji kupac vidi i broj koji se primeni na porudžbinu ne mogu da se raziđu.

// Pragovi su deklarisani jednom, u jednom fajlu sa imenom.
const MS_FREE_SHIPPING_FROM = 1999;
const MS_ID_CHECK_FROM      = 1000;

// Naplata ih primenjuje na serveru, na podržanom hook-u.
add_action('woocommerce_checkout_process', function () {
    $subtotal = WC()->cart->get_displayed_subtotal();

    if ($subtotal >= MS_ID_CHECK_FROM && ! ms_customer_is_verified()) {
        wc_add_notice(__('Ova porudžbina zahteva verifikaciju identiteta.'), 'error');
    }
});

// Obaveštenje o dostavi čita istu konstantu, nikada prekucan broj.
add_shortcode('free_shipping_from', fn () => wc_price(MS_FREE_SHIPPING_FROM));

Desetak linija ovakvog koda nije ponovna izgradnja WooCommerce-a. To je mesto na kome je pravilo zapisano jednom, pa se prodavnica, stranica o dostavi i zapis porudžbine slažu, a da niko ne mora da pamti da ih usklađuje.

Ko ovo održava za dve godine?

Plugin dolazi sa proizvođačem, changelog-om i adresom za podršku. Custom kod dolazi sa onim ko ga je napisao i sa onim što se potrudio da zapiše. Ta asimetrija je najjači pošten argument za kupovinu, a istovremeno i ono što custom rad čini odbranjivim kada je urađen kako treba.

Custom kod koji preživi primopredaju izgleda ovako: mali poseban plugin sa jasnim imenom umesto još jednog bloka nakalemljenog na functions fajl teme; dokumentovani hook-ovi umesto izmena jezgra ili kopiranih template-a; kratak komentar koji poslovnim jezikom kaže koje pravilo kod sprovodi, a ne samo šta kod radi; i pravilo zapisano tamo gde vlasnik prodavnice može da ga pročita bez otvaranja editora.

Ako niko u prodavnici ne ume da kaže koja su pravila custom, ta prodavnica se ne održava, nego je ukleta. Svaki naredni developer nepoznat kod tretira kao noseći zid i ne usuđuje se da ga dira, a upravo tako privremeno rešenje staro tri godine postane trajno.

Pravilo koje niko ne ume da imenuje, niko ne može ni da održava.

Šta se dešava na dan kada izađe nova verzija WooCommerce-a?

Oba pristupa nose rizik pri ažuriranju. Samo je vrsta rizika različita. Sa pluginom je rizik prenet: manje posla za vas, manje kontrole, a ako proizvođač napusti proizvod, problem ionako nasleđujete, obično u najgorem trenutku. Sa custom kodom je rizik vaš: neko mora da prati napomene uz izdanja, da ostane na dokumentovanim tačkama proširenja i da prihvati da je svako zastarevanje njegov problem onog dana kada se pojavi.

Oba pristupa postaju podnošljiva uz istu kratku rutinu. Držite staging sajt koji verno preslikava produkciju, zajedno sa listom plugina. Vodite zapisanu listu pravila za porudžbine, sa očekivanim ishodom za svako od njih. Zatim, pre nego što bilo koje izdanje stigne do kupaca, napravite probne porudžbine koje prelaze svaki prag sa obe strane: jednu tik ispod, jednu tik iznad, jednu sa kuponom, jednu sa nezgodnom zonom dostave. Prodavnica koja je testirana samo na srećnom scenariju zapravo nije ni testirana.

Iskren podrazumevani izbor

Prvo podesite. Zatim plugin. Tek onda kod. Za većinu prodavnica proces staje na drugom koraku: podešavanja WooCommerce-a, zone dostave i jedna ozbiljna ekstenzija pokriće pravilo, a ostatak budžeta bolje je uložiti u fotografije, robu ili oglase.

Custom kod postaje ispravan odgovor kada su istovremeno tačne četiri stvari. Pravilo je specifično za način na koji taj biznis radi. Mora da bude tačno na svakoj porudžbini, a ne na većini njih. Živi na naplati, tamo gde novac menja ruke. I postojalo bi i da prodavnica sledeće godine promeni platformu. JC Jewelers je čist primer sva četiri uslova. Katalog od 527 komada u pet kategorija, sa cenama od 745 do 20.295 dolara, ne ponaša se kao polica sa identičnim proizvodima. Pravila vezana za vrednost porudžbine zapisana su jednom, umesto da se ponavljaju po tekstu, a upit za izradu po narudžbini radi pored standardne korpe, jer prsten koji još ne postoji ne može da se doda u nju.

To je ceo test za odluku o prilagođavanju WooCommerce-a. Sve ostalo, a sve ostalo je većina slučajeva, jeste pitanje podešavanja prerušeno u budžet za razvoj. Ako i sami vagate plugin naspram custom koda za neko svoje pravilo, naš razvoj WooCommerce prodavnica počinje upravo tim razgovorom, a često se i završava zaključkom da ne treba napisati ništa.