Pažangios kuponų taisyklės neperrašant WooCommerce.

KODĖL VIENAS TIESOS ŠALTINIS

Kuponas neturi tapti dviem skirtingais objektais vien todėl, kad į jį žiūri skirtingas ekranas.

WooCommerce jau valdo kupono kodą, sumą, panaudojimo limitus, galiojimą, produktų apribojimus, klientui rodomą aprašymą ir galutinį nuolaidos skaičiavimą. Jei PerkRule tuos pačius laukus kopijuotų pas save, atsirastų sinchronizavimo problemos: WooCommerce pakeitimas galėtų nesutapti su akcijų įskiepio būsena, trečiųjų šalių integracijos matytų skirtingus duomenis, o išjungus įskiepį parduotuvėje liktų antras pusiau autoritetingas kupono modelis. Todėl PerkRule natyvų kuponą išplečia, o ne pakeičia.

KĄ PRIDEDA PERKRULE

PerkRule saugo tik tas akcijų sąvokas, kurių WooCommerce pati neturi.

PerkRule metaduomenys aprašo Auto Apply režimą, pažangias taisykles, prioritetą, stacking elgesį, sudėtingesnį planavimą ir kampanijų konfigūraciją. Natyvus aprašymas, publish/draft būsena ir galiojimo pabaiga sąmoningai lieka WooCommerce. Tai mažiau efektinga nei išrasti visiškai naują akcijos objektą, bet daug saugiau ekosistemai, paprasčiau migracijoms ir gerokai lengviau suprasti gedimo atveju.

Jokios paralelinės kuponų duomenų bazės

Kuponų duomenys lieka ten, kur jų tikisi WooCommerce ir visa jos ekosistema.

Pažangios sąlygos aplink kuponą

Krepšelio, kliento, vietos, mokėjimo ir pristatymo faktai gali spręsti, kada natyvus kuponas galioja.

Nuolaidą vis dar skaičiuoja WooCommerce

PerkRule planuoja tinkamumą ir konfliktus nekeisdamas natyvios nuolaidų matematikos.

KONFIGŪRACIJA ≠ NUOSAVYBĖ

Auto Apply nustatymas nesuteikia PerkRule nuolatinės teisės valdyti tą kuponą krepšelyje.

Auto Apply yra tik politika, leidžianti tinkamą natyvų kuponą pritaikyti automatiškai. Nuosavybė atsiranda tik po to, kai PerkRule pats sėkmingai atliko tą pakeitimą. Jei klientas vėliau tą patį kuponą įveda ranka, arba automatiškai valdytas kuponas pašalinamas ir vėliau vėl įvedamas rankiniu būdu, runtime neturi supainioti konfigūracijos su nuosavybe ir ištrinti kliento veiksmo per kitą reconciliation ciklą.

MINIMALŪS PAKEITIMAI

Pirmiausia nusprendžiamas tinkamumas; WooCommerce gauna tik galutinį apply/remove skirtumą.

PerkRule nemėto kuponų į gyvą krepšelį vien tam, kad pažiūrėtų, kas prilips. Jis randa ribotą kandidatų rinkinį, validuoja taisykles, išsprendžia konfliktus ir palygina norimą valdomą būseną su dabartiniu krepšeliu. Galima pašalinti tik pasenusius, aiškiai PerkRule valdomus kuponus ir pritaikyti tik pasirinktus trūkstamus. Pats pakeitimas vyksta per viešas WooCommerce kuponų API, todėl paskutinį žodį vis tiek turi natyvus validavimas.

PLANAS PRIEŠ PAKEITIMUS

Resolveris atsako, kas turi laimėti, dar prieš paliesdamas gyvą krepšelį.

Jei keli tinkami kuponai būtų taikomi ta pačia tvarka, kuria juos grąžino užklausa, galutinis rezultatas priklausytų nuo atsitiktinės eilės, hook laiko ar to, kas jau buvo krepšelyje. PerkRule sudaro deterministinį pasirinkimo planą pagal aiškų prioritetą ir stacking politiką. Vienodi prioritetai turi stabilų tie-breaker, exclusivity yra kieta sąlyga, o suderinami žemesnio prioriteto kuponai gali likti pasirinkti.

BEST DEAL YRA RIBOTAS

Best Deal renka laimėtoją aiškioje grupėje, o ne bando visas įmanomas visų kuponų kombinacijas.

Visų galimų akcijų poaibių paieška labai greitai tampa eksponentinė ir checkout aplinkoje būtų bloga architektūra. PerkRule Best Deal apriboja aiškiomis tarpusavyje nesuderinamomis grupėmis ir skaičiuoja tik tuos kandidatus, kuriuos iš tikrųjų reikia palyginti. Vertinimas vyksta su WooCommerce totals logika izoliuotoje krepšelio kopijoje, o ne eksperimentuojant su kliento gyvu krepšeliu. Jei saugiai įvertinti nepavyksta, procesas sustoja prieš mutaciją.

SERVERIS YRA AUTORITETAS

Classic checkout, Blocks ir headless klientai turi klausti to paties akcijų variklio to paties klausimo.

Akcijos tinkamumas turi būti sprendžiamas serveryje, nes serveris valdo krepšelį ir galiausiai priima užsakymą. Atskiros naršyklės taisyklės sukurtų kelias tiesos versijas: vieną klasikiniams template, kitą Blocks, kitą Store API ir dar vieną custom headless frontendui. PerkRule taisyklių vertinimą ir kuponų validavimą laiko WooCommerce serverio lifecycle, todėl prezentacijos sluoksniai gali skirtis neperrašydami verslo logikos.

SUDERINAMUMO RIBA

UI adapteriai gali skirtis, bet akcijos prasmė neturi keistis.

Blocks, builderiai ir headless parduotuvės gali reikalauti skirtingo UI, pranešimų ar refresh elgesio, tačiau tie adapteriai neturi spręsti, ar kuponas galioja. Architektūra palieka atskiras integracijų ribas, o branduolį išlaiko serverio autoritetu. Taip naujai frontend aplinkai reikia adapterio aplink tą patį sprendimą, o ne antro akcijų variklio, kuris ilgainiui pradėtų elgtis kitaip.