Drupal Commerce - Mikor Veri Meg a Shopifyt

A Drupal Commerce a legtöbb webáruház számára rossz válasz. Ez nem a projekt bírálata, amely tizenöt éve jól megtervezett. Ez inkább arról szól, milyen a legtöbb bolt: néhány száz cikkszám, egy pénznem, lakossági vásárlók, a végén egy kártyás fizetés. Ilyen üzleti formánál egy üzemeltetett platform minden számottevő szempontból nyer, és a vita véget ér, mielőtt elkezdődne.

Van egy kisebbség, amelynél a számítás teljesen megfordul, és ez jövedelmező kisebbség. Konfigurálható termékek, amelyek nem írhatók le variánsrácsként. Kereskedelmi fiókok kialkudott árlistákkal. Olyan katalógus, amely egyben a szerkesztőségi tartalom is. Olyan ERP, amelyé a készlet és az ár, és amely a webhelyet megjelenítő felületnek tekinti. Ezekben a cégekben az üzemeltetett platform nem olcsóbb, hanem állandó adó, amelyet alkalmazásokban, kerülőmegoldásokban és meg nem változtatható dolgokban fizetnek meg.

Ez az írás megmutatja, hol húzódik valójában ez a határ, mindkét oldal számaival. Ha elolvassa a Shopifyról szóló részt, és ráismer a saját cégére, álljon meg ott. Rengeteg pénzt takarít meg, a cikk pedig elvégezte a dolgát.

Mikor veri meg a Drupal Commerce a Shopifyt? Amikor a termékei nem modellezhetők egyszerű variánsrácsként, amikor különböző vásárlók eltérő árat látnak ugyanarra a cikkszámra, amikor a katalógus és a szerkesztőségi tartalom ugyanaz, vagy amikor egy ERP az igazság forrása, és a bolt csak nézet rajta. Egyszerű lakossági katalógusnál, egy vagy két pénznemben, a Shopify három év alatt olcsóbb és jobban konvertál. A választóvonal a termék és az árazás összetettsége, nem a forgalom vagy az árbevétel.

Mi is valójában a Drupal Commerce

A Drupal Commerce nem bolttermék. Entitástípusok halmaza, amely a Drupal entitás- és mezőrendszerére épül, és minden további ebben a cikkben ebből a mondatból következik.

Egy termék a Drupal Commerce-ben bundle-lel rendelkező entitás, pontosan úgy, mint egy tartalomcsomópont. Ugyanez igaz a termékváltozatra, a rendelésre, a rendeléstételre, a fizetésre, az akcióra és a boltra. Mindegyik tetszőleges mezőket fogad, így egy változat hordozhat gyártási tételszámot, tanúsítványhivatkozást, munkanapokban megadott szállítási időt és olyan méretet, amelyből az ára kiszámítható. Ezek egyike sem rögzített sémára kívülről ráaggatott egyedi mező. Ez maga a séma.

A megvásárolható dolog a változat, nem a termék. A termék a megjelenítő burok, a változat pedig a cikkszámmal és árral rendelkező tétel, ahol az attribútumok állítják elő a választható kombinációkat. A terméktípus dönti el, milyen mezői vannak egy terméknek, a változattípus pedig azt, milyen attribútumokat hordoznak a változatai. Ez az elrendezés semmit sem feltételez ruházatról, fizikai árukról vagy a választási lehetőségek rögzített számáról.

Ebből következik, hogy a Drupal Commerce-nek szinte semmilyen véleménye nincs arról, mit árul. Ennek a szabadságnak az ára, hogy szinte semmilyen döntést sem hoz meg, és valakinek mindet meg kell hoznia.

Hol tart most a Drupal Commerce

A jelenleg ajánlott kiadás a Drupal Commerce 3.3.8, amely 2026. július 17-én jelent meg, és Drupal 10.3 vagy újabb, illetve Drupal 11 alatt működik. A stabil kiadásokra a Drupal biztonsági szabályzata vonatkozik, ami többet jelent, mint amennyinek hangzik: egy bejelentett sebezhetőség összehangolt kiadást kap, nem GitHub-hibajegyet.

A Drupal Commerce projektoldala 35 870 webhelyet jelez, amely használja a modult. A Commerce 3.0.0 volt a 3.x vonal első stabil kiadása 2025 januárjában, és megszüntette a Drupal 9 támogatását. Körülötte kicsi közösségi ökoszisztéma áll: a Commerce Shipping a 3.0.3 verziónál tart nagyjából 15 200 telepítéssel, az alább tárgyalt szakosodott modulok pedig néhány ezres nagyságrendben mozognak.

Vessük ezt össze a WooCommerce programmal, amely több mint 7 millió aktív telepítést jelez, és WordPress 6.9, valamint PHP 7.4 vagy újabb verziót igényel. A telepített bázist tekintve a Drupal Commerce nagyjából 200-szor kisebb.

Ez az arány a cikk legfontosabb száma, és figyelmeztetés, nem dicsekvés. Azt jelenti, hogy arra a kérdésre, hogy létezik-e már modul valamire, gyakran nem a válasz.

Az őszinte érvelés a Shopify mellett

A Shopify megoldja azt a négy problémát, amely a saját üzemeltetésű boltok többségét elsüllyeszti, és megoldja őket, mielőtt egyetlen sor kódot írna.

Üzemeltetett, így a rendelkezésre állás, a skálázás és a javítások megszűnnek költségtételnek lenni. Kezeli a kártyaadatokat, így a megörökölt megfelelőségi felület töredéke annak, ami egyébként lenne. A fizetési folyamatát olyan mennyiségű valós tranzakción tesztelték, amelyet ügynökség nem tud reprodukálni, és ekkora léptékben az apró konverziós különbségek többet érnek bármilyen architektúrapreferenciánál. Alkalmazás-ökoszisztémája pedig azt jelenti, hogy a legtöbb igény előfizetésként érkezik, nem projektként.

Néhány ezer cikkszámot, egy vagy két pénznemet és semmilyen kialkudott árat nem tartalmazó lakossági katalógusnál a később leírt előnyök egyike sem érvényes. Ügynökséget fizetne azért, hogy rosszabbul építse újra azt, amit most havi £65 összegért kap.

Mondjuk ki nyíltan, mert az írás többi része az ellenkezőjét állítja: a legtöbb boltnak meg kellene állnia a Shopifynál. Ha az öné is ilyen, a Shopify és az egyedi webáruház összevetése részletesebben tárgyalja a döntést, mint ez az oldal.

Mennyibe kerül a Shopify az Egyesült Királyságban

A Shopify fontban teszi közzé a brit árakat, így nincs szükség átváltásra. A Shopify árazási oldaláról 2026 szeptemberében leolvasva: a Basic havi £25 havi számlázással, illetve £19 éves számlázással, a Grow £65 vagy £49, az Advanced £344 vagy £259, a Plus pedig havi £1 800 összegtől indul. A POS Pro havonta és értékesítési helyenként £69 összeggel egészíti ki.

A kártyadíjak többet nyomnak a latban, mint az előfizetés. Az online kártyás díjak a Shopify Payments rendszerében a Basic csomagban 2 % plusz 25 p, a Grow csomagban 1,7 % plusz 25 p, az Advanced csomagban pedig 1,5 % plusz 25 p. A legtöbben azt a számot hagyják figyelmen kívül, amelyet a külső fizetési szolgáltatóért kell fizetni, ha nem a Shopify Payments rendszert használja: Basic esetén 2 %, Grow esetén 1 %, Advanced esetén 0,6 %, Plus esetén 0,2 %.

Ez a díj a saját fizetési átjárója díjára rakódik rá. Egy évi 1 millió font forgalmú boltnál, amely Advanced csomagon külső elfogadót használ, önmagában a külső szolgáltatói díj évi £6 000, azaz három év alatt £18 000, azért a kiváltságért, hogy ne a Shopify Payments rendszert használja.

Hol fogy ki a Shopify a helyből

A korlátok nyilvánosak és pontosak. A Shopify változatok hozzáadásáról szóló dokumentációja szerint minden termékhez legfeljebb három opció és legfeljebb 2 048 változat tartozhat, és bármelyik átlépése külső alkalmazást vagy olyan sablonkódot igényel, amely tételszintű tulajdonságokat rögzít.

A három opció az a mennyezet, amely elsőként szorít. Egy ablak, egy nyomtatott panel, egy méretre készült árnyékoló vagy egy konfigurált gép rendszerint hat vagy nyolc független választást tartalmaz, és amint túllép a hármon, a platform már nem modellezi a terméket, hanem közelíti.

A fizetési folyamat a második fal. A Shopify fizetési felületi bővítményei az adat-, szállítási és fizetési lépéshez csak a Plus csomagban érhetők el. A Plus alatt megjelenésében testre szabhatja a folyamatot, de logikát nem illeszthet bele, ami kizárja a szállítási idősáv választását, a kereskedelmi hitelvizsgálatot és a megfelelőségi kapukat pontosan ott, ahol szükség lenne rájuk.

A harmadik korlát a felhalmozódás. Minden hiányt egy alkalmazás tölt be, minden alkalmazás havidíj és frissítési függőség, és egy húsz alkalmazást futtató bolt karbantartási gondja feltűnően hasonlít arra, amely elől elmenekült.

A WooCommerce melletti érvelés, és hol feszül

A WooCommerce igazságosabb meghallgatást érdemel, mint amit rendszerint kap. Ingyenes, havi néhány tíz font értékű tárhelyen fut, az adatok az önéi, bővítménykínálata pedig messze a legnagyobb a webáruházak világában. Kicsi vagy közepes lakossági boltnál, ahol a csapat már ismeri a WordPresst, gyakran ez a helyes és a legolcsóbb válasz.

Három kiszámítható ponton feszül. Az első az adatmodell: a termékek WordPress-bejegyzéstípusok, amelyek attribútumai sorosított metaadatként tárolódnak, így egy nagy, attribútumokban gazdag katalógus szűrése kulcs-érték tábla lekérdezését jelenti valódi oszlopok helyett. Ez 1 000 terméknél elviselhető, 50 000-nél fájdalmas.

A második a változatszám melletti teljesítmény, messze a leggyakoribb oka annak, hogy egy WooCommerce-bolt lassúnak érződik. Ennek működését részletesen bemutattuk abban az írásunkban, amely arról szól, miért lassú egy WooCommerce-bolt, a rövid válasz pedig az, hogy a változatos termékek a lekérdezéseket sokszorozzák, nem a sorokat.

A harmadik a bővítményburjánzás. A WooCommerce úgy old meg problémákat, hogy telepít valamit, és négy év múltán a boltot harminc szállító kiadási ütemterve határozza meg, nem az öné.

Összetett termékmodellezés: az első valódi választóvonal

A legvilágosabb érv a Drupal Commerce mellett az olyan termék, amelyet konfigurálnak, nem pedig kiválasztanak. Méterre árult anyag vágási díjjal. Üvegezés, amelynek ára a szélesség és a magasság szorzata, minimális díjjal. Nyolc opciócsoportot tartalmazó gép, amelyben egyes csoportok kizárnak másokat. Nyomdai munka mennyiségi árlépcsővel és munkánkénti beállítási díjjal.

Ezek egyike sem variánsrács. Üzemeltetett platformon alkalmazással és tételszintű tulajdonságokkal közelítik őket, ami azt jelenti, hogy a vásárlónak mutatott árat a platform saját árlogikáján kívül számolják ki, és később egyeztetni kell.

A Drupal Commerce-ben az árat az ön által írt kód oldja fel. Egy árfeloldó megkapja a változatot, a mennyiséget és az aktuális környezetet, és árat ad vissza. Ebben semmi különleges nincs, és azt jelenti, hogy a konfigurált ár mindenhol a valódi ár: a kosárban, a rendelésben, az adószámításban és az ERP-exportban.

Az alkalmazandó próba egyszerű. Ha a katalógusát táblázatként meg tudja írni úgy, hogy minden megvásárolható dolog egy sor, akkor erre nincs szüksége. Ha nem tudja, a cikk minden további része fontossá válik.

B2B árazás, árlisták és kialkudott feltételek

A második választóvonal az, hogy két vásárló lát-e valaha eltérő árat ugyanarra a cikkszámra. A lakossági boltok nemmel felelnek. A kereskedő cégek igennel, és ez a válasz rendszerint az egész üzletük.

A Shopifynak van B2B megoldása, és a csomagonkénti B2B funkciókról szóló dokumentációja megerősíti, hogy elérhető Basic, Grow, Advanced és Plus csomagban. A részlet a korlátokban rejlik: a Plus alatt legfeljebb három aktív katalógust kap az összes B2B piacra, a közvetlen céges katalógusok csak Plus alatt érhetők el, és az előlegek, a részfizetések, valamint a teljesítésenkénti fizetési kérések szintén csak Plus alatt. Három katalógus elég három árszinthez, és használhatatlan negyven kialkudott fiókhoz.

Drupal oldalon a megfelelője a Commerce Price List modul, jelenleg 8.x-2.16 verzión, nagyjából 1 662 bejelentett telepítéssel és biztonsági csapati lefedettséggel. Felhasználónként vagy szerepkörönként állít árat, támogatja a mennyiségi sávokat és a dátumtartományokat, és CSV-ből importál.

Ez az utolsó pont a gyakorlati. Egy negyven ügyfélfiókot kezelő nagykereskedő, ahol mindegyik a saját megállapodott listáján van, és negyedévente frissül az ERP-ből, CSV-importálási feladat, nem platformmigráció.

Több bolt, több pénznem és többnyelvűség egyetlen kódbázisból

A bolt elsőrangú entitás a Drupal Commerce-ben, és a termékeket azokhoz a boltokhoz rendelik, amelyek eladhatják őket. Kicsi tervezési döntés, nagy következménnyel: több üzletfelület oszthat meg egy katalógust, egy rendelési folyamatot és egy adminisztrációt, miközben eltérő pénznemet, adóbeállítást, fizetési átjárókat és szállítási szabályokat hordoz.

A szokásos alak egy brit webhely, egy uniós webhely és egy kereskedői portál, mind egyetlen telepítésből. A termékadatokat egyszer viszik be. Az árlista csak a kereskedői boltra érvényes. Az adó boltonként oldódik fel, mert a bolt hordozza a saját számlázási országát és a saját nyilvántartásba vételeit.

A Drupal alaprendszere ezen felül igazán erős többnyelvű réteget hoz, nyelvenkénti URL-aliasokkal, fordított entitásokkal és alternatív nyelvi hivatkozásokkal, ezért van a Drupalnak ilyen erős jelenléte a felsőoktatásban és a közszférában.

A Shopify Markets mára ebből jó sokat lefed, de a kontextusfüggő fizetési folyamat és az üzletfelület testreszabása a Markets révén az Advanced és a Plus csomagra korlátozódik, így az összevetés legalább havi £259 összeggel történik, nem £25 összeggel.

Amikor a katalógus szerkesztőségi tartalom

Egyes katalógusok tartalmak. Az a szaküzlet, amelynek termékoldalain vásárlási útmutatók, összehasonlító táblázatok, műszaki magyarázatok és egy tesztelő jegyzetei szerepelnek, kiadványt működtet, amely mellékesen fizetést is elfogad.

Üzemeltetett platformon ez két rendszer. A tartalomkezelő tartja a cikket, a bolt tartja a cikkszámot, és egy hivatkozás meg egy éjszakai export köti össze őket. A szerkesztők két helyen dolgoznak, a keresés kétszer indexel, az URL-szerkezeten pedig varrat fut végig.

A Drupal Commerce-ben a termék ugyanabban a rendszerben lévő entitás, mint bármelyik cikk, így közös a szerkesztőségi folyamat, a verziótörténet, a taxonómiaszótárak, a médiatár, a keresési index és a jogosultsági modell. Egy termékoldal hivatkozhat három cikkre, egy cikk pedig kilenc termékre, mindkét irányban valódi entitáshivatkozásként, nem beillesztett linkként.

Ez az az érv, amely a leggyakrabban indokolja a Drupalt olyan cégnél, amely egyébként kényelmesen elférne a Shopifyn, és ez az, amit a leggyakrabban söpörnek félre kellemes ráadásként, egészen addig, amíg egy szerkesztőség egy évet le nem dolgozik két adminisztrációs felületen.

Szabályozott és sok attribútumot hordozó termékek

A megfelelőségi adatokat hordozó termékek a negyedik eset. Vegyi anyagok biztonsági adatlapokkal. Orvostechnikai eszközök tanúsítványszámokkal és lejárati dátumokkal. Élelmiszerek allergénmátrixokkal. Elektromos áruk megfelelőségi nyilatkozatokkal. Minden, ami gyártásitétel-követést vagy korlátozott értékesítési jelzést igényel.

A követelmény nem pusztán az, hogy tárolja ezeket az értékeket. Az, hogy ellenőrizze, verziózza, a vásárló által ténylegesen megkapott tételhez tartozót mutassa, és utólag bizonyítsa, mi volt közzétéve egy adott napon. A Drupal mezőrendszere és verziókezelése azért képes erre, mert tartalomirányításra épült, nem árusításra.

A kikényszerítés oldala ugyanennyit számít. Egy rendelésfeldolgozó elutasíthat olyan fizetést, amely korhatáros terméket küldene olyan országba, ahol tilos, vagy amely két, együtt nem szállítható terméket kapcsolna össze, és ezt a rendelési folyamaton belül teheti meg, nem egy sablonban.

Üzemeltetett platformon minden ilyen ellenőrzés egy alkalmazás, az alkalmazások pedig nem állnak össze. Két alkalmazás, amely mindkettő módosítja a kosarat, két olyan alkalmazás, amely előbb vagy utóbb nem ért egyet.

Amikor az ERP az igazság forrása

Az ötödik eset szerkezeti. Egy nagykereskedelmi vagy gyártó cégben az ERP birtokolja a készletet, az árakat, a vevői hitelkeretet és a rendelés állapotát, a webhely pedig megjelenítő felület, kosárral kiegészítve. A kérdés nem az, mire képes a bolt, hanem az, milyen olcsón tartható összhangban azzal a rendszerrel, amely valójában irányít.

A Drupal Commerce itt jól érzi magát, mert az integráció a saját folyamatában fut. A sor-API kezeli az aszinkron munkát, a migrációs API az ismételhető, idempotens importokat, és nincs közvetítő, amely rekordonként számláz vagy fojtja a szinkronizálási ablakot. Egy éjszakai, 200 000 soros ár- és készletimport egyszerű ütemezett feladat.

Üzemeltetett platformon ugyanez az integráció vagy alkalmazás-, vagy köztesréteg-előfizetés, és a platform hívásszámkorlátai részlet helyett olyan architekturális korláttá válnak, amely köré tervezni kell. Ez működőképes, és sok cégnél ez a helyes kompromisszum. Akkor szűnik meg helyesnek lenni, amikor a szinkronizálás egyszerre nagy, gyakori és üzletileg kritikus.

Ha az integrációs munka teszi ki a projekt nagyobb részét, nem maga a bolt, akkor az szoftverfejlesztési megbízás, amelyhez üzletfelület tartozik, és már az elején így kell körülhatárolni.

Az adózásnál szűnik meg az üzemeltetett platformok olcsósága

Az adózás a határon átnyúló webáruházak csendes költséghelye, és itt kezd félrevezetni a havidíjak összevetése. Két küszöbérték dönti el a legtöbbet.

A brit áfaregisztrációs küszöb

A GOV.UK útmutatója arról, mikor kell áfaregisztrációt kérni, £90 000 teljes adóköteles árbevételnél húzza meg a küszöböt. Két külön próba váltja ki a regisztrációt: egy gördülő, tizenkét hónapos próba, amelynél annak a hónapnak a vége után 30 napon belül regisztrálnia kell, amelyben az árbevétel átlépte a £90 000 határt, és egy előretekintő próba, amelynél akkor kell regisztrálnia, amint felismeri, hogy az árbevétel a következő 30 napban meghaladja a £90 000 összeget.

Az előretekintő próba az, amely a növekvő boltokat elkapja, mert a regisztráció napja az, amikor felismerte, nem az, amikor a pénz megérkezett.

Uniós áfa és az egyablakos rendszer

Az Európai Bizottság útmutatója a teljesítés helyéről EUR 10 000 összegű, együttes éves küszöböt szab, amely a Közösségen belüli távértékesítést és a távközlési, műsorszolgáltatási és elektronikus szolgáltatásokat együtt fedi le. Ez alatt a teljesítés helye ott van, ahol a feladás vagy a fuvarozás megkezdődik. Fölötte az adóztatás oda kerül, ahol a fuvarozás véget ér, vagyis a vásárló országának kulcsához.

Az egyablakos rendszer lehetővé teszi, hogy mindezt egyetlen bevallásban, egyetlen tagállamban vallja be, negyedévente benyújtva, április, július, október és január végi határidőkkel. Az importra vonatkozó egyablakos rendszer az Unión kívülről behozott árukra vonatkozik, olyan küldeményekben, amelyek nem haladják meg az EUR 150 összeget.

Mit tesz ezzel a Drupal Commerce alapból

A Commerce az Európai Unió áfájára vonatkozó adómodult az alaprendszerben szállítja, nem kiegészítőként. Mind a 27 tagállam kulcsait hordozza Monacóval együtt, megkülönbözteti az általános, a kedvezményes, a köztes, a nagyon kedvezményes és a nulla kulcsot, és kezeli azokat a különleges területeket, amelyeken a lapos kulcstáblák elbuknak, köztük Korzikát, az Azori-szigeteket, Madeirát, a görög szigeteket és az ausztriai Jungholz exklávét.

A kulcsokon túl a szabályokat is alkalmazza: rendeltetési hely szerinti adózás a digitális termékekre, és nulla kulcsos Közösségen belüli vállalatközi értékesítés, ha érvényes adószámot adnak meg. Üzemeltetett platformon ez a viselkedés jellemzően tranzakciónként fizetendő alkalmazás.

Fizetések, PCI DSS és az, hogyan veszi át a kártyát

Az, ahogyan a kártyaszámot begyűjti, eldönti a megfelelőségi terhét, és a szabályok nemrég olyan módon változtak, amelyet széles körben félreértenek.

A PCI Security Standards Council pontosítása a SAQ A jogosultsági feltételeiről elmagyaráz egy feltételt, amely 2025. április 1-jén lépett hatályba. A kereskedőknek meg kell erősíteniük, hogy webhelyük nem sebezhető olyan szkriptes támadásokkal szemben, amelyek befolyásolhatják a kereskedő webáruházi rendszereit, és ez vagy a PCI DSS 6.4.3 és 11.6.1 követelményében szereplő technikák bevezetésével, vagy a fizetési szolgáltatótól kapott megerősítéssel teljesíthető, hogy annak beágyazott megoldása tartalmazza ezeket a védelmeket.

A pontos hatókör az, amit a legtöbben elrontanak. Ez a feltétel kizárólag azokra a kereskedőkre vonatkozik, akiknek az oldala beágyazza a szolgáltató fizetési űrlapját, jellemzően iframe-ben. A Council kimondja, hogy nem vonatkozik azokra a kereskedőkre, akik átirányítják a vásárlót a szolgáltatóhoz, akár HTTP-átirányítással, akár meta refresh megoldással vagy JavaScripttel, és azokra sem, akik teljes egészében kiszervezik a fizetési funkciókat.

Az üzemeltetett átirányítás tehát kicsin tartja a felületet. A beágyazott mezők, amelyek jobban konvertálnak, és amelyeket valójában szinte mindenki szeretne, a fizetési oldalán futó minden szkript sértetlenségét bevonják a megfelelőségi beszélgetésbe.

Itt van a Shopify valódi előnye, mert a fizetési folyamat az övék, és a rajta futó szkriptek is az övék. A Drupal Commerce-ben a fizetési folyamat az öné, tehát a választ meg kell tervezni: szigorú tartalombiztonsági szabályzat, alerőforrás-integritás, leltár a fizetési oldalon futó minden szkriptről, és változásfigyelés, ha valamelyik elmozdul. Ez a munka se nem nehéz, se nem elhagyható, és a költségvetésben a helye, nem egy auditon felfedezve.

Az akadálymentesség jogi és üzleti kockázat

A webáruházi akadálymentességi hibák a fizetési folyamatban sűrűsödnek, vagyis pontosan ott, ahol minden hiba közvetlenül pénzbe kerül.

A vonatkozó hivatkozás a WCAG 2.2, amely 2024. december 12-én megjelent W3C-ajánlás. A boltban valóban harapó feltételek konkrétak. Az 1.3.5 Identify Input Purpose AA szinten a cím- és kártyamezők automatikus kitöltését fedi le. A 3.3.7 Redundant Entry A szinten mindannyiszor sérül, amikor egy fizetési folyamat újra begépelteti a szállítási címet a fizetési lépésnél. A 3.3.8 Accessible Authentication AA szinten a fiók létrehozását és a bejelentkezést szabályozza. A 2.5.8 Target Size AA szinten a mennyiségléptetőket és a kosárból eltávolító vezérlőket fogja meg, az 1.4.3 Contrast pedig AA szinten azt a kiszürkített gombot, amely valójában aktív.

Két további a rendelés körül helyezkedik el: a 3.3.1 Error Identification A szinten, valamint a 3.3.4 Error Prevention a jogi, pénzügyi és adatügyleteknél AA szinten, ami pontosan a rendelés leadásáról szól.

A brit jogi helyzetet gyakran eltúlozzák. Magánkereskedőt nem köt olyan törvény, amely WCAG-megfelelőségi szintet nevezne meg. Ami érvényes, az az Equality Act 2010 20. szakaszából fakadó kötelezettség, hogy ésszerű lépéseket tegyen a fogyatékossággal élők jelentős hátrányának elkerülésére, ideértve a segédeszközök biztosítását is. Azok a rendeletek, amelyek megfelelőségi szintet neveznek meg, vagyis a Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, közszférabeli szervezetekre vonatkoznak, nem boltokra.

Az üzleti érv élesebb a jogi érvnél. Üzemeltetett sablonon nem mindig tudja kijavítani azt, amit egy alkalmazás beleinjektál a fizetési folyamatba. Olyan platformon, amelyet ön irányít, meg tudja tenni.

Mennyibe kerül valójában három év

A szokásos összevetés a havi előfizetést állítja szembe a havi tárhellyel, ami a táblázat legkevésbé jelentős sora. A kiépítés költsége és a karbantartás uralja a képet, nagy forgalomnál pedig a tranzakciós százalékok.

Az alábbi sávok a Mecanik saját becslései egy brit középkategóriás boltra, kivéve a Shopify előfizetési és díjszámait, amelyek fontban, pontosan úgy szerepelnek, ahogy a Shopify közzéteszi őket. Minden más az, amit várhatóan ajánlanánk, és az egy soron belüli szórás nagyobb, mint a platformok közötti különbség az alsó végen.

Mit vesz meg valójában a táblázat egy-egy sora

Prózában: a Shopify Advanced három év alatt £9 324 és £12 384 közötti előfizetési díjba kerül attól függően, vállal-e éves elköteleződést, és tartalmazza a tárhelyet, viszont alkalmazás-előfizetéseket ad hozzá, amelyek ugyanebben az időszakban reálisan £5 400 és £14 400 között mozognak. A WooCommerce semmit sem fizet a platformért és £3 600 és £14 400 közötti összeget a tárhelyért, a bővítmények pedig a három év alatt £3 000 és £9 000 közé esnek. A Drupal Commerce semmit sem fizet a licencért, a tárhelyre költi a legtöbbet, £5 400 és £21 600 között, mert a három közül ez a legnehezebb alkalmazás, és a kiegészítőkre a legkevesebbet, a semmi és nagyjából £3 000 között, mert a megfelelői közösségi modulok, nem kereskedelmiek.

A kiépítés költsége választja szét a platformokat. Egy £8 000 és £25 000 közötti Shopify-kiépítés sablonozott boltot ad a szokásos integrációkkal, szemben a WooCommerce £10 000 és £35 000 közötti értékével. Ugyanaz a feladatkiírás Drupal Commerce-en £35 000 és £120 000 között van, mert a fizetési folyamatot, az árlogikát és az integrációkat mind megírják, nem beállítják. A karbantartás ugyanezt az alakot követi, a Shopifynál évi £3 000 és £9 000 között, a WooCommerce-nél £4 000 és £12 000 között, a Drupal Commerce-nél £12 000 és £30 000 között, ami a nagyjából £600 és £900 közötti brit ügynökségi napidíjakat tükrözi, amelyeket a Drupal-fejlesztői díjszabásról szóló útmutatónkban tárgyalunk.

Hova érkeznek a hároméves összegek

A hároméves összegek nagyjából £32 000 és £79 000 közé érkeznek a Shopifynál, £29 000 és £94 000 közé a WooCommerce-nél és £76 000 és £235 000 közé a Drupal Commerce-nél. A kártya- és átjáródíjak mindhármon felül jelentkeznek, és a forgalommal együtt nőnek, ezért ér az Advanced csomagon a Shopify 0,6 %-os külső átjáródíja három év alatt £18 000 összeget egy évi 1 millió font forgalmú boltnál.

Olvassa a táblázatot őszintén, és a Drupal Commerce két-háromszor annyiba kerül. Ez csak akkor indokolt, ha az alternatíva valójában nem áll rendelkezésre, ami az öt megelőző szakasz teljes lényege.

Headless és szétcsatolt Drupal Commerce

A Drupal Commerce szétcsatolása szűk esetkörben valódi követelmény, a többiben pedig divat. Az őszinte próba az, hogy a webhelyen kívül másnak is szüksége van-e ugyanarra a katalógusra.

Valódi követelmény, amikor egy natív mobilalkalmazásnak és egy webhelynek közös termék- és ármodellen kell osztoznia, amikor egy másik csapat által épített meglévő felületet nem cserélnek le, amikor kasszaterminálok vagy kioszkok ugyanazt a kosarat használják, vagy amikor a designrendszer a projekten kívül van, és nem fejezhető ki Twigben. Ilyenkor az API a termék, a tartalomkezelő pedig szándékosan láthatatlan.

Divat, amikor a felhozott indok a teljesítmény. Egy jól gyorsítótárazott hagyományos Drupal-felület a peremhálózatról szolgálja ki a névtelen termékoldalakat, és a megjelenítés módja ritkán az, ami lassúvá tesz egy lassú boltot.

A költség egyetlen helyen sűrűsödik. A Drupal alaprendszere beállítás nélkül teszi közzé a tartalmat JSON:API felületen, a Commerce Cart API modul pedig REST felület mögé teszi a kosarakat, így a katalógus olvasása és a kosár összeállítása szinte ingyen van. A fizetési folyamat nem. A címkezelést, az adómegjelenítést, a szállításválasztást, az akciókat, a fizetési elem beépítését és a rendelés visszaigazolását mind újra kell építeni a felületen, és ez rendszerint a teljes kiépítés 40 %-a vagy több.

Az ötperces döntési szabály

Válaszoljon hat kérdésre a saját katalógusáról. Minden igen egy pontot ér.

Igényel-e bármelyik terméke háromnál több opciót vagy 2 048-nál több megvásárolható kombinációt? Fizet-e két különböző vásárló valaha eltérő árat ugyanazért a cikkszámért? Értékesít-e egynél több országba eltérő áfakezeléssel, vagy számít arra, hogy OSS-bevallást nyújt be? A katalógus egyben olyan szerkesztőségi tartalom is, amelyet ugyanaz a csapat ír és gondoz? Egy ERP vagy egy PIM a hiteles forrás az árra és a készletre, a bolt pedig lejjebb helyezkedik el? Kell-e saját logikát illesztenie a fizetési folyamatba, nem csupán a megjelenését igazítania?

Nulla vagy egy pontnál válassza a Shopifyt. A cikkben leírt előnyök nem érintik önt, és azért fizetne, hogy újraépítse azt, amit most bérel.

Két pontnál a döntés valóban nyitott, és gyakran a WooCommerce a jobb középút, különösen ha a csapat már WordPresst üzemeltet.

Három vagy több pontnál érdemes rendesen beárazni a Drupal Commerce-t, mert a máshol szükséges kerülőmegoldások három év alatt többe kerülnek, mint maga a platform. Öt vagy hat pontnál az üzemeltetett platform nem olcsóbb választás, hanem másik termék, amely nem végzi el a feladatot.

Hol szoktak elromlani a Drupal Commerce projektek

A leggyakoribb kudarc az, hogy rossz okból választják. Az, hogy már futtatunk Drupalt, nem kereskedelmi követelmény. Egy tartalomoldal és egy tranzakciós oldal rendelkezésre állási elvárásai, tesztelése és a hibás élesítés következményei eltérőek, és a bolt kezelése a meglévő webhely újabb rovataként az az út, amelyen egy kicsi webáruházprojekt nem tervezett platformcsapatot szerez.

A második a karbantartás alulfinanszírozása. A 35 870 telepítéssel az ökoszisztéma elég kicsi ahhoz, hogy maroknyi karbantartóval bíró modulokat használjon, és valakinek az ön oldalán figyelnie kell a biztonsági közleményeket és ütemeznie a frissítéseket. Az a Drupal Commerce webhely, amelyért ezen a téren senki nem felel, késleltetett biztonsági incidens, amit részletesebben azon tárhelykövetelmények mellett tárgyalunk, amelyeket a Drupal valóban támaszt.

A harmadik az a feltételezés, hogy létezik modul. Nézze meg, mielőtt árajánlatot ad. Ha nincs, a munka egyedi webhelyfejlesztés, és valódi becslést igényel, nem egy tételsort.

A negyedik a főverziós fegyelem. A Commerce 3 Drupal 10.3 vagy újabb verziót igényel, és az a webhely, amely lemarad az alaprendszertől, egyszer csak azt találja, hogy a kereskedelmi moduljai nélküle mentek tovább. A 2026-os Drupal-fejlesztésről szóló útmutatónk és a migrációs költségekről és határidőkről szóló írásunk egyaránt kitér erre a ciklusra.

A helyes döntés meghozatala

A választást a termék és az árazás összetettsége dönti el, nem a forgalom, az árbevétel vagy az ízlés. Modellezze először a katalógusát papíron, minden opcióval, minden kialkudott árral és minden olyan integrációval, amelynek összhangban kell maradnia valami mással. Ha ez a modell elfér egy variánsrácsban, vegye meg az üzemeltetett platformot, a megspórolt keretet pedig költse marketingre.

A Mecanik mindkét boltfajtát építi és karbantartja, és megmondjuk, a vonal melyik oldalán áll, mielőtt bármit is beáraznánk. Ha a válasz a Drupal Commerce, a munka jelentős integrációs résszel bíró webhelyfejlesztési megbízás; ha az ERP-munka meghaladja az üzletfelületet, akkor inkább a szoftverfejlesztés körébe tartozik. Ha a válasz a Shopify, azt megmondjuk, és inkább most mondjuk meg, mint tizennyolc hónappal egy újraépítés kezdete után.

Gyakran ismételt kérdések

Jobb a Drupal Commerce a Shopifynál? A legtöbb bolt esetében nem. A Shopify három év alatt olcsóbb, kezeli a PCI-megfelelőséget és a tárhelyet, és olyan léptéken tesztelt fizetési folyamata van, amelyet ügynökség nem tud utolérni. A Drupal Commerce szűk esetkörben nyer: háromnál több opciót vagy 2 048 változatot igénylő termékeknél, ügyfélre szabott kialkudott áraknál, olyan katalógusoknál, amelyek egyben szerkesztőségi tartalmak, és olyan boltoknál, ahol az ERP birtokolja az árat és a készletet.

Mennyibe kerül egy Drupal Commerce kiépítés az Egyesült Királyságban? Számítson £35 000 és £120 000 közötti kezdeti kiépítésre és évi £12 000 és £30 000 közötti karbantartásra, nagyjából £600 és £900 közötti brit ügynökségi napidíjak mellett. Három év alatt egy Drupal Commerce bolt tárhellyel együtt jellemzően £76 000 és £235 000 közé esik, szemben a Shopify Advanced nagyjából £32 000 és £79 000 közötti értékével. Ezek saját becslések, nem ajánlatok.

Melyik Drupal Commerce verziót érdemes használni? A Drupal Commerce 3 jelenleg a 3.3.8 verziónál tart, amely 2026. július 17-én jelent meg. Drupal 10.3 vagy újabb, illetve Drupal 11 alatt működik, és a stabil kiadásaira a Drupal biztonsági szabályzata vonatkozik. A Commerce 2 a Drupal 9 és 10 verziót támogatta, és az előző kiadási ciklus, tehát az új projekteknek a 3.x vonalon érdemes indulniuk.

Kezeli a Drupal Commerce az uniós áfát és az OSS-t? Az adószabályok a Commerce alaprendszerébe épültek, nem kiegészítőként árulják őket. Az Európai Unió áfamodulja mind a 27 tagállam kulcsait hordozza Monacóval együtt, megkülönbözteti az általános, a kedvezményes, a köztes, a nagyon kedvezményes és a nulla kulcsot, kezeli a különleges területeket, rendeltetési hely szerinti adózást alkalmaz a digitális termékekre, és nullázza a Közösségen belüli vállalatközi értékesítést érvényes adószám mellett. Az OSS-bevallás benyújtása továbbra is könyvelési feladat.

Mikor éri meg a headless Drupal Commerce? Amikor a webhelyen kívül más is ugyanazt a katalógust használja, például natív alkalmazás, kasszaterminál vagy egy másik csapat tulajdonában lévő felület. Pusztán a sebességért nem éri meg, mert egy gyorsítótárazott hagyományos felület már így is gyors. Tervezze be a fizetési folyamat újraépítését, amely rendszerint egy szétcsatolt kiépítés 40 %-a vagy több.