Vlastní podmínky pravidla WooCommerce pro vývojáře

Pokud jste vývojář WooCommerce, který rozšiřuje propagační plugin na podporu obchodní logiky specifické pro klienta, jsou obvykle podmínky vlastních pravidel tam, kde je složitost. Standardní podmínky pravidel dodávané s většinou BOGO a zásuvných modulů pro slevy zvládají běžné vzorce – minimální celkový počet košíků, konkrétní SKU produktu, role zákazníků, rozsahy dat – ale trvale nedosahují podmíněné logiky, kterou vyžaduje skutečná práce klienta. Vývojář vytvářející pravidlo, které uplatňuje slevu pouze v případě, že historie objednávek zákazníka ukazuje, že byl konkrétní produkt zakoupen, nebo pouze během konkrétní přepravní zóny nebo pouze tehdy, když úroveň zákazníka odpovídá vlastní taxonomii, rychle narazí na limity standardních modulů pravidel.

Tento příspěvek je určen vývojářům WooCommerce a technickým vedoucím, kteří potřebují rozšířit logiku propagačních pravidel nad rámec toho, co poskytují zásuvné moduly. Projdeme si, jak jsou podmínky vlastních pravidel obvykle implementovány v moderních propagačních architekturách WooCommerce, kde na architektonických rozhodnutích záleží z hlediska udržovatelnosti a co se změní, když základní propagační plugin odkryje čistý povrch rozšíření pro vlastní logiku podmínek, místo aby vyžadoval vidlice nebo hacknutá řešení.

Proč jsou vlastní podmínky pravidel architektonicky důležité

Strukturální problém motorů s pevnými pravidly spočívá v tom, že skutečná klientská práce trvale převyšuje podmínky, se kterými je motor dodáván. Velkoobchodní klient B2B chce slevy pouze pro zákazníky s aktivními velkoobchodními smlouvami uloženými v meta uživatelském meta. Obchod založený na předplatném chce odlišnou logiku slev pro zákazníky s aktivním předplatným oproti zákazníkům bez. Prodejce na tržišti chce logiku slev, která respektuje minima specifická pro dodavatele a prahové hodnoty úrovní. Standardní podmínky „minimální celkový počet košíků“ a „specifické produkty“ nestačí, protože obchodní logika je skutečně složitější, než mohou tato primitiva vyjádřit.

Průzkum McKinsey týkající se analýzy cen a promoakcí soustavně zjišťuje, že maloobchodníci podceňují hodnotu koordinované analýzy promo akcí. Stejné podcenění ovlivňuje způsob, jakým vývojáři WooCommerce přistupují k rozšiřitelnosti pravidel – předpoklad, že „plugin zvládá standardní případy“ skrývá realitu, že produkční obchody běžně potřebují podmíněnou logiku, která přesahuje standardní případy. Architektonická flexibilita pro vlastní podmínky je základem, který určuje, zda se vývojář může rozšířit čistě, nebo musí bojovat s pluginem, aby splnil požadavky klienta.

Údaje o opuštění košíku z Baymard Institute, založené na 50 samostatných studiích opuštění košíku, udávají celosvětový průměr 70,22 %. Podmínky vlastních pravidel jsou důležité pro opuštění košíku, protože špatné podmínky mohou způsobit opuštěné vozíky, kde zákazník očekával slevu, která se nevztahuje. B2B zákazník, který očekával velkoobchodní slevu, ale nedostal ji, protože modul pravidel nezkontroloval jejich velkoobchodní smlouvu, opustí košík. Předplatitel, který očekával nabídku pouze pro předplatitele, ale neviděl ji, protože modul pravidel nerozuměl stavu předplatného, ​​opouští. Logika podmínek ovlivňuje skutečné výsledky konverze.

Jak vypadají moderní architektury vlastních pravidel WooCommerce

Architektonický vzor, ​​který se přizpůsobuje podmínkám vlastních pravidel, je čistý povrch rozšíření, kde mohou vývojáři registrovat vlastní podmínky prostřednictvím zdokumentovaných háčků, spíše než interních záplatování zásuvných modulů nebo údržby fork. Vlastní podmínka se obvykle zaregistruje jako volatelná, která přijme kontext košíku a zákaznický kontext a vrátí logickou hodnotu označující, zda má pravidlo platit. Plugin vyvolává registrované podmínky během výpočtu košíku, vyhodnocuje booleovské výsledky a podle toho aplikuje logiku pravidla.

Hákový vzor rozšíření vytváří tři architektonické výhody. Za prvé, vývojářova vlastní logika podmínek žije v kódu specifickém pro klienta spíše než ve vidlicích pluginů, což znamená, že aktualizace pluginů nenaruší přizpůsobení klienta. Zadruhé, logiku vlastních podmínek lze testovat izolovaně, protože se jedná o čistou funkci v kontextu košíku a zákazníka – nejsou potřeba žádné interní doplňky. Zatřetí, vlastní podmínky se stanou opakovaně použitelnými v celém portfoliu klientů vývojáře, protože stejnou logiku podmínek, která funguje pro velkoobchodní kontrolu klienta A, lze upravit pro kontrolu předplatného klienta B s minimálními úpravami.

Alternativní architektura – vnitřní zásuvné moduly pro záplatování opice nebo údržbové větve – vytváří tři architektonické problémy. Za prvé, aktualizace zásuvných modulů přeruší práci klienta, protože záplaty předpokládají vnitřní struktury zásuvných modulů, které může upstreamový zásuvný modul bez upozornění změnit. Za druhé, vlastní logiku nelze testovat samostatně, protože ke spuštění vyžaduje úplný kontext pluginu. Zatřetí, vlastní logika není znovu použitelná napříč klienty, protože je přivařena k interním prvkům jedné konkrétní verze pluginu.

Co poskytuje GT BOGO Engine pro podmínky vlastních pravidel

GT BOGO Engine je celosvětově první automatizační systém Buy X Get Y na podnikové úrovni vytvořený speciálně pro WooCommerce. Platforma zahrnuje 47 superschopností, které automaticky fungují uvnitř WooCommerce, plus 200 předpřipravených balíčků kampaní v 19 odvětvích a navíc čistý povrch rozšíření pro vlastní podmínky pravidel prostřednictvím zdokumentovaných háčků a filtrů. Vývojáři mohou rozšířit modul pravidel bez rozvětvení zásuvného modulu nebo vnitřních záplatování opice. Pro použití zaměřené konkrétně na vývojáře jsou důležité čtyři funkce pro provozní realitu vytváření logiky vlastních pravidel na platformě.

Za prvé, modul pravidla odhaluje registraci stavu prostřednictvím standardních háčků filtru WordPress. Vývojáři registrují volatelné položky s vlastní podmínkou, které přijímají kontext košíku a kontext zákazníka jako parametry a vrací boolean. Platforma vyvolá registrované podmínky během výpočtu košíku a vyhodnotí booleovské výsledky, aby určila, zda platí každé pravidlo. Rozšíření založené na háku znamená, že vlastní podmínky žijí v kódu specifickém pro klienta a čistě přežívají aktualizace pluginů.

Za druhé, vrstva inteligence zákazníků odhaluje stav zákazníka jako strukturované rozhraní API, na které se mohou dotazovat vlastní podmínky. Úroveň zákaznické LTV, zákaznické segmenty, stav výročí, stav narozenin, stav předplatného a historie nákupů jsou dostupné prostřednictvím zdokumentovaných metod, nikoli vyžadováním vlastních dotazů proti databázi WooCommerce. Strukturované API znamená, že logika přizpůsobených podmínek může využít zákaznickou inteligenci platformy, aniž by bylo nutné znovu implementovat práci na segmentaci. Další informace o vrstvě inteligence zákazníků naleznete v WooCommerce pluginu pro hodnocení LTV.

Za třetí, kontext košíku odhaluje strukturovaný přístup k obsahu košíku, použitým pravidlům, informacím o zákaznících a výběru dopravy. Vlastní podmínky mohou prozkoumat celý stav košíku pomocí zdokumentovaných metod, což znamená, že logika vlastních podmínek může implementovat obchodní pravidla, která závisí na kombinacích obsahu košíku, stavu zákazníka a kontextu dopravy. Strukturovaný kontext košíku nahrazuje křehký vzor analýzy struktur košíku přímo a narušuje se, když aktualizace WooCommerce změní vnitřní reprezentace košíku.

Za čtvrté, testovací nástroje platformy odhalují kontexty simulovaného košíku a zákazníků, které mohou vývojáři použít v jednotkových testech. Vlastní logiku podmínek lze testovat izolovaně poskytnutím kontextů testovacího vozíku a zákazníků a ověřením, zda logické výstupy odpovídají očekávanému chování. Díky testovacím utilitám jsou vlastní podmínky skutečně testovatelné, místo aby vyžadovaly úplné integrační testy WordPress pro každou změnu podmínek. Další informace o testovacích přístupech naleznete v části developer WooCommerce testovací staging.

Jak vývojáři implementují podmínky vlastních pravidel v praxi

Vzor implementace pro podmínku vlastního pravidla se řídí standardním vývojovým pracovním postupem WordPress. Vývojář vytvoří vlastní zásuvný modul nebo přidá kód do zásuvného modulu MU specifického pro klienta, zaregistruje vlastní podmínku prostřednictvím zdokumentovaného háčku filtru, implementuje logiku podmínky jako callable, která vrací boolean, a otestuje logiku podmínky proti očekávaným scénářům košíku a zákazníků. Vlastní plugin žije odděleně od GT BOGO Engine, což znamená, že aktualizace pluginu neovlivňují vlastní logiku.

U velkoobchodní kontroly B2B se vlastní podmínka dotáže metadat uživatele zákazníka na příznak velkoobchodní smlouvy a vrátí hodnotu true pouze tehdy, když je příznak přítomen a smlouva je aktivní. Vlastní podmínka se pak připojí ke konkrétním pravidlům, kde by měla platit velkoobchodní logika, a modul pravidel vyhodnotí vlastní podmínku během výpočtu košíku. Výsledkem je, že velkoobchodní zákazníci vidí velkoobchodní pravidla uplatňovaná automaticky, zatímco nevelkoobchodní zákazníci vidí standardní maloobchodní pravidla.

Při kontrole stavu předplatného se vlastní podmínka dotáže rozhraní API pluginu WooCommerce Subscriptions na stav aktivního předplatného zákazníka a vrátí hodnotu true, když má zákazník aktivní předplatné, které odpovídá konkrétním kritériím. Vlastní podmínka se připojí k pravidlům specifickým pro předplatné a modul pravidel podle toho vyhodnotí. Vrstva inteligence zákazníků platformy již poskytuje detekci předplatného, ​​což znamená, že jednoduché kontroly předplatného nemusí vyžadovat vlastní podmínku – ale podrobnější kontroly (konkrétní produkty předplatného, ​​způsobilost úrovně předplatného, ​​rozsahy dat předplatného) obvykle těží z vlastní logiky podmínek.

Při kontrole dodavatele na tržišti se vlastní podmínka dotazuje na obsah košíku pro produkty od konkrétních dodavatelů a vrátí hodnotu true, když jsou splněna minima a prahové hodnoty pro konkrétní dodavatele. Vlastní podmínka se připojí k pravidlům specifickým pro dodavatele a modul pravidel vyhodnotí obsah košíku během výpočtu. Výsledkem je, že prodejci na tržišti dostanou automaticky aplikovanou propagační logiku specifickou pro dodavatele, aniž by došlo k porušení výpočtu košíku, když jsou v košíku také produkty jiných prodejců.

Srovnání: Standardní moduly s pravidly vs moduly s rozšiřitelnými pravidly

| Schopnost | Standardní motory | Rozšiřitelné moduly pravidel (GT BOGO Engine) | |---|---|---| | Vestavěné podmínky | Omezená primitiva | Komplexní primitiva | | Vlastní registrace stavu | Vidličky nebo opice-patching | Zdokumentované filtrační háčky | | Bezpečnost aktualizace pluginu | Přerušuje zakázkovou práci | Zachovává zakázkovou práci | | Vlastní testovatelnost stavu | Vyžaduje úplné integrační testy | Jednotka testovatelná v izolaci | | Stav zákazníka přístup | Vlastní databázové dotazy | Strukturované rozhraní API pro zákazníky | | Kontextový přístup košíku | Přímá analýza košíku | API strukturovaného kontextu košíku | | Opakovaná použitelnost mezi klienty | Přivařeno k verzi pluginu | Přenositelné mezi verzemi pluginu | | Povrch dokumentace | Omezená | Komplexní | | Údržba | Vysoká v průběhu času | Stabilní v čase | | Roční cena licence | Různé | 199 $/rok byt |

Příklady podmínek vlastního pravidla v reálném světě

Klient distribuce B2B potřebuje propagační logiku, která závisí na limitech objemu specifických pro jednotlivé vrstvy zákazníka. Vývojář implementuje vlastní podmínku, která se dotazuje na úroveň zákaznického účtu z metadat uživatele a na výpočet objemu specifického pro úroveň košíku. Podmínka se vrátí na hodnotu true, když objem košíku dosáhne prahové úrovně zákaznického účtu, což znamená, že zákazníci úrovně A automaticky uvidí jiné prahové hodnoty objemu než zákazníci úrovně B. Vlastní podmínka je přibližně 25 řádků kódu, žije v modulu plug-in pro konkrétního klienta a je jednotkově testována podle reprezentativních scénářů košíku a zákazníků.

Klient wellness založený na předplatném potřebuje propagační logiku, která vylučuje produkty s předplatným z rozsáhlých slev a zároveň uplatňuje speciální nabídky pro zákazníky s předplatným na doplňkové produkty. Vývojář implementuje vlastní podmínky, které kontrolují jak obsah košíku (vyjma předplatitelských produktů z výpočtu slevy), tak stav zákazníka (identifikace aktivních předplatitelů pro speciální nabídky). Podmínky se integrují se schopností detekce předplatného platformy a přidávají logiku specifickou pro klienta, kterou platforma neposkytuje hned po vybalení. Další informace o zpracování předplatného najdete v WooCommerce předplatné BOGO nabídky.

Klient tržiště s více dodavateli potřebuje propagační logiku, která respektuje minima na jednotlivé dodavatele a prahové hodnoty na úrovni jednotlivých dodavatelů. Vývojář implementuje vlastní podmínku, která zkoumá obsah košíku podle dodavatele, vypočítává součty podle dodavatele a vyhodnocuje logiku prahových hodnot podle dodavatele. Podmínka vrátí hodnotu true pouze tehdy, když logika jednotlivých dodavatelů naznačuje, že pravidlo by se mělo vztahovat na produkty konkrétního dodavatele. Výsledkem je, že propagační logika tržiště funguje správně napříč vozíky od více dodavatelů, aniž by došlo k porušení, když se produkty prodejců smíchají ve stejném košíku.

Cesta migrace pro existující logiku vlastních pravidel

Migrace je nedestruktivní, protože GT BOGO Engine koexistuje s existujícími propagačními pluginy bez konfliktů. Vývojáři mohou nainstalovat GT BOGO Engine vedle aktuálního propagačního systému, postupně přenášet logiku vlastních pravidel na novou architekturu a ověřovat chování před ukončením staršího systému. To řeší standardní obavy vývojářů z rizika narušení během přechodů platformy.

Sekvence pragmatické migrace má čtyři fáze po dobu dvou až tří měsíců pro typické portfolio vlastních pravidel. Nejprve proveďte audit stávající logiky vlastních pravidel a zjistěte, jaké vlastní podmínky existují, na jakých vnitřních součástech pluginu závisí a jak vypadá testovací pokrytí. Audit vytvoří nevyřízenou migraci s každou vlastní podmínkou uvedenou pro portování. Za druhé, nejprve portujte nejjednodušší vlastní podmínky, abyste ověřili vzor migrace a vybudovali odborné znalosti vývojářů na nové architektuře. Za třetí, přeneste zbývající vlastní podmínky v pořadí priority na základě dopadu na klienta a složitosti.

Za čtvrté, ověřte migrované vlastní podmínky podle reprezentativních klientských scénářů a po ověření parity odeberte starší systém. Fáze ověřování obvykle používá pracovní prostředí se snímky produkčních dat k ověření, že migrovaná logika vytváří ekvivalentní chování jako starší logika. Většina portfolií vlastních pravidel dokončí migraci během jednoho čtvrtletí, přičemž nejjednodušší vlastní podmínky migrují do dnů a složitější podmínky zaberou každý jeden až dva týdny. Další informace o pracovních postupech stagingu najdete v tématu developer WooCommerce testování staging.

Ceny a licenční struktura pro vývojáře

GT BOGO Engine PRO je 199 $ za rok na klientský obchod bez cenových úrovní pro jednotlivé funkce. Za schopnost rozšíření pravidel, zákaznické rozhraní API, kontextové rozhraní API košíku, testovací nástroje ani žádné funkce platformy pro vývojáře se neplatí žádný příplatek. Jednotlivé balíčky PRO specifické pro dané odvětví jsou za 39,99 $. Tři úrovně balíčků nabízejí úspory pro klienty s více odvětvími: Starter Bundle (149 $ za 5 balíčků, ušetříte 50,95 $), Growth Bundle (299 $ za 9 balíčků, ušetřete 60,91 $) a Kompletní arzenál (399 $ za 15 balíčků, ušetřete 200,85 $).

Bezplatný základní plugin zahrnuje schopnost rozšíření pravidel a zdokumentované háky filtrů, což znamená, že vývojáři mohou ověřit architekturu rozšíření předtím, než se zapojí do PRO. Většina vývojářů používá bezplatnou vrstvu pro počáteční ověření architektury a portování prototypů a poté upgraduje na PRO, když klientské nasazení zahrnuje knihovnu balíčků kampaní, vrstvu inteligence zákazníků a e-mailový systém životního cyklu, což jsou funkce pouze PRO.

Často kladené otázky od vývojářů WooCommerce

Jaký je zdokumentovaný háček filtru pro registraci vlastních podmínek?

Platforma vystavuje háky filtru pro registraci stavu, které se řídí standardními vzory WordPress. Přesná jména háčků a podpisy jsou zdokumentovány v příručce pro vývojáře. Vzor se řídí konvencí WordPress pojmenovaných háčků filtru, proti kterým vlastní pluginy registrují callable, přičemž platforma vyvolává registrované callable během výpočtu košíku. Zdokumentované háčky zůstávají stabilní napříč verzemi zásuvných modulů, přičemž chování zpětné kompatibility je zachováno, když se háčky vyvíjejí. Další informace o architektuře vývojáře naleznete v příručce pro vývojáře GT BOGO Engine.

Jak platforma řeší konflikty mezi vlastními podmínkami a integrovanými podmínkami?

Vlastní podmínky a vestavěné podmínky se vyhodnocují nezávisle, přičemž modul pravidla kombinuje booleovské výsledky podle logiky podmínek pravidla (všechny podmínky musí být pravdivé, jakákoli podmínka musí být pravdivá atd.). Mezi vlastními a vestavěnými podmínkami není žádný konflikt, protože jsou vyhodnocovány jako paralelní booleovské kontroly spíše než jako překrývající se logika. Vývojáři konfigurují pravidla s kombinacemi vlastních a vestavěných podmínek, aby vyjádřili komplexní obchodní logiku.

Mohou vlastní podmínky přistupovat k datům pluginů třetích stran?

Ano. Vlastní podmínky se spouštějí ve standardním kontextu požadavku WordPress, což znamená, že mají přístup k jakýmkoli datům dostupným prostřednictvím standardních rozhraní API WordPress a WooCommerce. WooCommerce Data předplatného, ​​vlastní uživatelská meta, data pluginů třetích stran a externí volání API jsou přístupná z vlastních callables podmínek. Vývojáři by měli mít na paměti dopady na výkon, když vlastní podmínky provádějí externí volání API, protože podmínky se spouštějí během výpočtu košíku.

Jak platforma zpracovává zpětnou kompatibilitu pro vlastní podmínky?

Zdokumentované háky filtrů pro registraci vlastních podmínek se řídí konvencemi sémantického verzování. Zpětně kompatibilní změny probíhají volně; ke zpětně nekompatibilním změnám dochází při přechodech hlavních verzí s dokumentovanými cestami migrace. Vlastní podmínky napsané proti zdokumentovanému háku v jedné hlavní verzi nadále fungují v následujících menších a opravných vydáních bez úprav.

Jaká je typická doba vývoje pro portování logiky vlastních pravidel ze staršího pluginu?

Většina vlastních logických portů pravidel se přenáší ve dnech spíše než v týdnech, protože architektonický vzor je konzistentní napříč modulem pravidel. Jednoduché vlastní podmínky (booleovské kontroly proti košíku nebo údajům zákazníka) port v hodinách. Složité vlastní podmínky (vícekroková logika s externími závislostmi) port ve dnech. Celková doba portování pro typické klientské portfolio trvá jeden až dva týdny na vývojáře, přičemž hlubší práce spočívá na testování a ověřování spíše než na samotném portování. Širší kontext o architektuře vývojáře naleznete v tématu architektura bez konfliktů pro vývojáře.

GT BOGO Engine vytvořil GRAPHIC T-SHIRTS, skutečný obchod WooCommerce s více než 1200 originálními návrhy běžícími ve velkém měřítku. Navštivte stránku gtbogoengine.com a stáhněte si bezplatný základní plugin, vyhodnoťte architekturu rozšíření pravidel a rozhraní API pro vývojáře a rozhodněte, zda rozšiřitelnost platformy ospravedlňuje migraci na vaší časové ose. Pro širší kontext viz WooCommerce vysvětlené propagační zpravodajství.