WooCommerce kuponų stacking

Akcijų konfliktai turi turėti planą, o ne atsitiktinį rezultatą.

Kai tam pačiam krepšeliui tinka keli kuponai, PerkRule pirmiausia išsprendžia aiškias prioriteto ir stacking taisykles ir tik tada pradeda keisti gyvą WooCommerce krepšelį.

PRIORITETAS

Stabili tvarka ir deterministiniai vienodi prioritetai.

Didesnis aiškiai nurodytas prioritetas laimi. Vienodas prioritetas išsprendžiamas pagal stabilią kupono tapatybę, o ne pagal atsitiktinę iteravimo tvarką.

AIŠKUS PRIORITETAS

Didesnis prioritetas laimi, o vienodas prioritetas vis tiek turi deterministinį atsakymą.

PerkRule priority laiko ribotame integer diapazone, o trūkstamą reikšmę traktuoja kaip nulį. Kai du kandidatai turi tą patį efektyvų prioritetą, stabilus kupono ID tampa tie-breaker vietoj DB iteravimo eilės ar timing. Tai atrodo kaip smulkmena, bet būtent tokios smulkmenos leidžia tą patį cart ir tą pačią konfigūraciją atkartoti: laimėtojas neturi keistis vien todėl, kad kandidatai atėjo kita tvarka.

PRIORITETAS NĖRA EXCLUSIVITY

Aukštesnio prioriteto kuponas automatiškai neišmeta visų žemesnio prioriteto kuponų.

Priority atsako už eilę ir pasirinkimą konflikto metu; stacking politika atsako už suderinamumą. Įprastos stackable akcijos gali likti kartu net turėdamos skirtingus prioritetus. Taip priority netampa netyčiniu globaliu 'winner takes all'. Tik realūs apribojimai — native individual-use, PerkRule exclusive, conflict santykis ar Best Deal grupė — nusprendžia, kada tinkamos akcijos negali egzistuoti kartu.

STACKING REŽIMAI

Stack, exclusive, conflict group arba Best Deal.

Stacking konfigūracija aprašo ryšį tarp tinkamų akcijų nesusilpnindama natyvaus WooCommerce individual-use elgesio.

STACK

Suderinamos akcijos gali veikti kartu vien todėl, kad PerkRule valdo abi, jos netampa konkurentėmis.

Stack yra numatytasis santykis, kai nėra griežtesnės konfigūracijos. Jis neapeina natyvių WooCommerce apribojimų; jis tik pasako, kad pats PerkRule neprideda tarpusavio draudimo. Taip policy sluoksnis lieka additive: WooCommerce gali kombinaciją atmesti dėl savo native priežasčių, o PerkRule prideda griežtesnį santykį tik tada, kai parduotuvė jo aiškiai paprašo.

EXCLUSIVE / GROUPED

Exclusive ir conflict-group aprašo skirtingus nesuderinamumus ir abu išsprendžiami prieš mutaciją.

Exclusive yra kieta PerkRule sąlyga aplink konkrečią akciją. Conflict group modeliuoja žinomą akcijų rinkinį, kuris negali visas išlikti kartu. Best Deal prideda palyginimą tarpusavyje nesuderinamoje grupėje vietoj vien priority. Šie santykiai normalizuojami į policy duomenis prieš resolverį, todėl sugadinta aiški konfigūracija padaro automatinį kandidatą netinkamą, o ne tyliai pavirsta permissive default.

BEST DEAL

Ribotas pasirinkimas, o ne eksponentinė paieška.

Best Deal grupės renkasi tik aiškiose ribotose grupėse. Variklis vengia neribotų kombinacijų ir vertina per natyvų WooCommerce totals elgesį.

JOKIOS POWERSET PAIEŠKOS

PerkRule nebando kiekvienos įmanomos visų tinkamų akcijų kombinacijos ieškodamas teorinio globalaus optimumo.

Toks algoritmas auga eksponentiškai ir būtų bloga checkout priklausomybė. Best Deal veikia tik aiškiose ribotose grupėse, kuriose reikia vieno laimėtojo. Kandidatai už ginčijamos Best Deal grupės ribų neskaičiuojami vien dėl skaičiavimo. Funkcija taip gauna aiškią prasmę ir ribotą kainą vietoj atviro optimizavimo uždavinio, kurio runtime priklausytų nuo to, kiek kuponų parduotuvė sukaupė.

NATYVUS SCORE

Ginčijamas kandidatas palyginamas per WooCommerce totals logiką izoliuotoje klonuotoje būsenoje.

Scoreris pradeda nuo to paties apsaugotų kuponų baseline, prideda vieną kandidatą ir sukuria natyvius cart totals kopijoje. Lyginama kandidato native discount reikšmė kartu su discount tax WooCommerce precision vienetais. Gyvas krepšelis, session ir notice queue neliečiami. Free-shipping Best Deal kol kas nelaikomas išspręstu; ši riba paliekama aiški vietoj išgalvoto piniginio score, kurio implementacija negali pagrįsti.

PLANAS PIRMA

Pirmiausia nuspręsk, tada liesk gyvą krepšelį.

Resolveris pirmiausia sudaro minimalų taikymo planą. Pasenę automatiniai kuponai šalinami, o pasirinkti taikomi tik po konfliktų sprendimo.

PIRMIAUSIA NORIMA BŪSENA

Conflict resolution sudaro norimą valdomų kuponų rinkinį prieš bet kokį apply ar remove.

Taip mutacija tampa mažu sinchronizavimo žingsniu, o ne sprendimo algoritmo dalimi. Reconcileris gali palyginti dabartinius automatiškai valdomus kuponus su pasirinktu rinkiniu, stabilia tvarka pašalinti tik pasenusius owned kodus ir policy tvarka pritaikyti tik trūkstamus. Jau teisinga būsena tampa no-op. Pure planas taip pat leidžia resolverį testuoti be WordPress ar WooCommerce ir aiškiau suprasti dalinius gedimus.

SUSTOTI PRIEŠ LIEČIANT CART

Jei reikalingo score ar policy sprendimo negalima gauti saugiai, reconciliation sustoja dar prieš gyvo krepšelio pakeitimą.

Pavojinga alternatyva būtų pašalinti kelis kuponus, tada viduryje selection aptikti klaidą ir bandyti atkurti, ką klientas turėjo prieš tai. PerkRule stumia neapibrėžtumą į pradžią: validuoja definicijas, užfiksuoja protected state, gauna reikalingus score ir išsprendžia pilną planą. Tik tada atliekamas minimalus mutation diff. Tai nepadaro išorinių WooCommerce mutacijų neklystančių, bet gerokai sumažina sprendimų kiekį po state pakeitimo.

Perskaityk inžinerinį įrodymą.

Pažiūrėk, kodėl deterministinis planavimas yra PerkRule produkto standarto dalis.

Atidaryti inžineriją

PerkRule pagalbos erdvė

Tikra pagalba veikia geriau, kai galima normaliai pasikalbėti.

PerkRule Discord bus tiesioginė vieta diegimo klausimams, klaidų pranešimams, suderinamumo pastaboms ir išleidimų aptarimui. Naudingi atsakymai neturi dingti privačiuose ticketuose — pasikartojančios problemos galės virsti dokumentacija ir Inžinerijos užrašais.

Discord atsidarys artėjant Produkto 001 išleidimui