Drupal Commerce - Când Învinge Shopify

Drupal Commerce este răspunsul greșit pentru majoritatea magazinelor online. Nu este o critică la adresa proiectului, care este bine construit de cincisprezece ani. Este o constatare despre ce sunt majoritatea magazinelor: câteva sute de coduri de produs, o singură monedă, clienți persoane fizice, o plată cu cardul la final. Pentru o afacere de forma aceasta, o platformă găzduită câștigă pe fiecare axă care contează, iar discuția se încheie înainte să înceapă.

Există o minoritate pentru care calculul se inversează complet, și este o minoritate profitabilă. Produse configurabile care nu încap într-o grilă de variante. Conturi de comerț cu liste de prețuri negociate. Un catalog care este în același timp conținutul editorial. Un ERP care deține stocul și prețurile și tratează site-ul ca pe o suprafață de afișare. În aceste companii, platforma găzduită nu este mai ieftină, ci o taxă permanentă plătită în aplicații, ocolișuri și lucruri pe care nu aveți voie să le schimbați.

Acest articol arată unde cade de fapt linia aceea, cu cifrele de ambele părți. Dacă citiți secțiunea despre Shopify și vă recunoașteți propria afacere, opriți-vă acolo. Veți economisi foarte mulți bani, iar articolul își va fi făcut treaba.

Când învinge Drupal Commerce platforma Shopify? Când produsele nu pot fi modelate ca o simplă grilă de variante, când clienți diferiți văd prețuri diferite pentru același cod de produs, când catalogul și conținutul editorial sunt același lucru, sau când un ERP este sursa de adevăr, iar magazinul doar o vedere asupra lui. Pentru un catalog obișnuit de retail în una sau două monede, Shopify costă mai puțin pe trei ani și convertește mai bine. Linia de separare este complexitatea produsului și a prețului, nu traficul sau cifra de afaceri.

Ce este de fapt Drupal Commerce

Drupal Commerce nu este un produs de magazin. Este un set de tipuri de entități așezat peste sistemul de entități și câmpuri al Drupal, iar tot ce urmează în acest articol decurge din propoziția aceasta.

Un produs în Drupal Commerce este o entitate cu un bundle, exact ca un nod. La fel sunt o variație de produs, o comandă, o poziție de comandă, o plată, o promoție și un magazin. Fiecare acceptă câmpuri arbitrare, așa că o variație poate purta un număr de lot, o referință de certificat, un termen de livrare în zile lucrătoare și o dimensiune folosită pentru a-i calcula prețul. Nimic din toate acestea nu este un câmp personalizat prins pe lângă o schemă fixă. Este chiar schema.

Lucrul care se cumpără este variația, nu produsul. Produsul este învelișul de prezentare, iar variația este articolul cu cod și preț, atributele generând combinațiile selectabile. Un tip de produs decide ce câmpuri are un produs, iar un tip de variație decide ce atribute poartă variațiile lui. Nimic din această așezare nu presupune îmbrăcăminte, bunuri fizice sau un număr fix de opțiuni.

Consecința este că Drupal Commerce nu are aproape nicio părere despre ce vindeți. Prețul acelei libertăți este că nu oferă nici aproape nicio decizie, iar cineva trebuie să le ia pe toate.

Unde se află Drupal Commerce acum

Versiunea recomandată este Drupal Commerce 3.3.8, publicată pe 17 iulie 2026, și funcționează cu Drupal 10.3 sau mai nou și cu Drupal 11. Versiunile stabile intră sub politica de securitate a Drupal, ceea ce contează mai mult decât pare: o vulnerabilitate raportată primește o publicare coordonată, nu un tichet pe GitHub.

Pagina proiectului Drupal Commerce raportează 35.870 de site-uri care folosesc modulul. Commerce 3.0.0 a fost prima versiune stabilă a liniei 3.x, în ianuarie 2025, și a renunțat la suportul pentru Drupal 9. În jurul ei există un ecosistem contribuit mic: Commerce Shipping este la 3.0.3 cu aproximativ 15.200 de instalări, iar modulele specializate discutate mai jos se numără în câteva mii.

Comparați asta cu WooCommerce, care raportează peste 7 milioane de instalări active și cere WordPress 6.9 și PHP 7.4 sau mai nou. Raportat la baza instalată, Drupal Commerce este de aproximativ 200 de ori mai mic.

Acel raport este cel mai important număr din acest articol și este un avertisment, nu o laudă. Înseamnă că răspunsul la întrebarea dacă există deja un modul pentru ceva anume este frecvent nu.

Argumentul cinstit pentru Shopify

Shopify rezolvă cele patru probleme care scufundă majoritatea magazinelor găzduite în regie proprie și le rezolvă înainte să fi scris o linie de cod.

Este găzduit, deci disponibilitatea, scalarea și actualizările nu mai sunt linia dumneavoastră de buget. Se ocupă de datele cardului, așa că suprafața de conformitate pe care o moșteniți este o fracțiune din ce ar fi altfel. Finalizarea comenzii este testată pe un volum de tranzacții reale pe care nicio agenție nu îl poate reproduce, iar la scara aceea diferențele mici de conversie valorează mai mult decât orice preferință de arhitectură. Iar ecosistemul de aplicații face ca majoritatea cerințelor să sosească drept abonament, nu drept proiect.

Pentru un catalog de retail cu câteva mii de coduri de produs, una sau două monede și fără prețuri negociate, niciunul dintre avantajele descrise mai jos nu se aplică. Ați plăti o agenție ca să reconstruiască, mai prost, lucruri pe care acum le primiți cu £65 pe lună.

Să o spunem clar, fiindcă restul articolului argumentează invers: majoritatea magazinelor ar trebui să se oprească la Shopify. Dacă al dumneavoastră este unul dintre ele, comparația noastră între Shopify și un magazin construit la comandă tratează decizia mai amănunțit decât pagina aceasta.

Cât costă Shopify în Regatul Unit

Shopify publică prețurile britanice în lire, deci nu este nevoie de nicio conversie. Citite de pe pagina de prețuri Shopify în septembrie 2026: Basic costă £25 pe lună la facturare lunară sau £19 la facturare anuală, Grow £65 sau £49, Advanced £344 sau £259, iar Plus pornește de la £1.800 pe lună. POS Pro adaugă £69 pe lună pentru fiecare locație.

Comisioanele de card cântăresc mai mult decât abonamentul. Ratele pentru carduri online prin Shopify Payments sunt de 2 % plus 25 p pe Basic, 1,7 % plus 25 p pe Grow și 1,5 % plus 25 p pe Advanced. Cifra pe care majoritatea o ratează este comisionul pentru procesatorul de plăți terț, perceput când folosiți alt gateway decât Shopify Payments: 2 % pe Basic, 1 % pe Grow, 0,6 % pe Advanced și 0,2 % pe Plus.

Comisionul acela se adaugă la ce percepe gateway-ul propriu-zis. Într-un magazin cu 1 milion de lire cifră de afaceri anuală care folosește un procesator extern pe Advanced, numai comisionul pentru terți înseamnă £6.000 pe an, adică £18.000 pe trei ani, pentru privilegiul de a nu folosi Shopify Payments.

Unde rămâne Shopify fără spațiu

Limitele sunt publicate și sunt precise. Documentația Shopify despre adăugarea variantelor spune că fiecare produs poate avea până la trei opțiuni și până la 2.048 de variante și că depășirea oricăreia dintre ele cere o aplicație terță sau cod de temă care să captureze proprietăți de poziție.

Trei opțiuni este plafonul care strânge primul. O fereastră, un panou imprimat, o jaluzea la comandă sau o mașină configurată au în mod obișnuit șase sau opt alegeri independente, iar în clipa în care depășiți trei, platforma nu vă mai modelează produsul, ci începe să îl aproximeze.

Finalizarea comenzii este al doilea zid. Extensiile de interfață pentru finalizare ale Shopify pentru pașii de informații, livrare și plată sunt disponibile doar pe planul Plus. Sub Plus puteți personaliza aspectul finalizării, dar nu puteți insera logică în ea, ceea ce exclude alegerea intervalului de livrare, verificarea creditului comercial și barierele de conformitate exact acolo unde trebuie să se producă.

A treia limită este acumularea. Fiecare gol este umplut de o aplicație, fiecare aplicație este o taxă lunară și o dependență la actualizare, iar un magazin cu douăzeci de aplicații are o problemă de întreținere remarcabil de asemănătoare cu cea de care a fugit.

Argumentul pentru WooCommerce și unde se forțează

WooCommerce merită o audiere mai corectă decât primește de obicei. Este gratuit, rulează pe găzduire de câteva zeci de lire pe lună, datele sunt ale dumneavoastră, iar catalogul lui de extensii este de departe cel mai mare din comerțul electronic. Pentru un magazin de retail mic sau mediu a cărui echipă știe deja WordPress, este frecvent răspunsul corect și cel mai ieftin.

Se forțează în trei locuri previzibile. Primul este modelul de date: produsele sunt un tip de postare WordPress cu atribute stocate ca metadate serializate, deci filtrarea unui catalog mare, bogat în atribute, înseamnă interogarea unui tabel cheie-valoare în loc de coloane adevărate. Este suportabil la 1.000 de produse și dureros la 50.000.

Al doilea este performanța la număr mare de variante, cel mai frecvent motiv pentru care un magazin WooCommerce pare lent. Am descris mecanica în detaliu în articolul nostru despre motivele pentru care un magazin WooCommerce este lent, iar pe scurt produsele variabile înmulțesc interogările, nu rândurile.

Al treilea este proliferarea de pluginuri. WooCommerce rezolvă probleme instalând lucruri, iar după patru ani magazinul este definit de calendarele de lansare a treizeci de furnizori, nu de al dumneavoastră.

Modelarea produselor complexe: prima linie de separare reală

Cazul cel mai limpede pentru Drupal Commerce este un produs care se configurează, nu se alege. Material vândut la metru cu taxă de croit. Geam cu preț dat de lățime înmulțită cu înălțime și un minim de facturare. O mașină cu opt grupuri de opțiuni, dintre care unele le anulează pe altele. Tipar cu o curbă de discount pe cantitate și o taxă de pregătire pe comandă.

Niciunul dintre acestea nu este o grilă de variante. Pe o platformă găzduită sunt aproximate cu o aplicație și un set de proprietăți de poziție, ceea ce înseamnă că prețul arătat clientului este calculat în afara logicii de preț a platformei și trebuie reconciliat mai târziu.

În Drupal Commerce prețul este rezolvat de cod scris de dumneavoastră. Un rezolvator de preț primește variația, cantitatea și contextul curent și returnează un preț. Nimic exotic aici, iar asta înseamnă că prețul configurat este prețul real peste tot: în coș, în comandă, în calculul taxei și în exportul către ERP.

Testul de aplicat este simplu. Dacă vă puteți scrie catalogul ca o foaie de calcul cu un rând pentru fiecare lucru vandabil, nu aveți nevoie de asta. Dacă nu puteți, tot restul articolului devine relevant.

Prețuri B2B, liste de prețuri și condiții negociate

A doua linie de separare este dacă doi clienți văd vreodată prețuri diferite pentru același cod de produs. Magazinele de retail răspund nu. Firmele de comerț răspund da, iar răspunsul acela este de obicei toată afacerea.

Shopify chiar are B2B, iar documentația despre funcțiile B2B pe planuri confirmă că este disponibil pe Basic, Grow, Advanced și Plus. Detaliul stă în limite: sub Plus primiți până la trei cataloage active pe toate piețele B2B, cataloagele directe de companie există doar pe Plus, iar avansurile, plățile parțiale și cererile de plată pe expediere tot doar pe Plus. Trei cataloage ajung pentru trei trepte de preț și nu folosesc la nimic pentru patruzeci de conturi negociate.

Pe Drupal echivalentul este modulul Commerce Price List, aflat la 8.x-2.16 cu aproximativ 1.662 de instalări raportate și acoperire din partea echipei de securitate. Stabilește prețuri pe utilizator sau pe rol, susține trepte de cantitate și intervale de date și importă din CSV.

Ultimul punct este cel practic. Un distribuitor cu patruzeci de conturi, fiecare pe lista lui convenită, împrospătată trimestrial din ERP, este o sarcină de import CSV, nu o migrare de platformă.

Multi-magazin, multi-monedă și multilingv dintr-o singură bază de cod

Un magazin este o entitate de prim rang în Drupal Commerce, iar produsele sunt atribuite magazinelor care au voie să le vândă. Este o decizie mică de proiectare cu o consecință mare: mai multe vitrine pot împărți un catalog, un flux de comenzi și o administrare, purtând în același timp monede, configurări de taxe, gateway-uri de plată și reguli de livrare diferite.

Forma obișnuită este un site britanic, un site pentru UE și un portal de comerț, toate dintr-o singură instalare. Datele de produs se introduc o singură dată. O listă de prețuri se aplică doar magazinului de comerț. Taxa se rezolvă pe magazin, fiindcă magazinul poartă propria țară de facturare și propriile înregistrări.

Nucleul Drupal aduce în plus un strat multilingv cu adevărat solid, cu aliasuri de URL pe limbă, entități traduse și legături către limbi alternative, motiv pentru care Drupal are o prezență atât de puternică în învățământul superior și în sectorul public.

Shopify Markets acoperă acum o bună parte din asta, dar finalizarea contextuală și personalizarea vitrinei prin Markets sunt limitate la planurile Advanced și Plus, deci comparația se face cel puțin cu £259 pe lună, nu cu £25.

Când catalogul este editorial

Unele cataloage sunt conținut. Un comerciant specializat ale cărui pagini de produs poartă ghiduri de cumpărare, tabele comparative, explicații tehnice și notele unui tester conduce o publicație care se întâmplă să încaseze plăți.

Pe o platformă găzduită acelea sunt două sisteme. CMS-ul ține articolul, magazinul ține codul de produs, iar ele sunt unite de o legătură și un export nocturn. Redactorii lucrează în două locuri, căutarea indexează de două ori, iar structura de URL capătă o cusătură pe mijloc.

În Drupal Commerce un produs este o entitate în același sistem cu orice articol, deci împarte fluxul editorial, istoricul reviziilor, vocabularele de taxonomie, biblioteca media, indexul de căutare și modelul de acces. O pagină de produs poate referi trei articole, iar un articol nouă produse, ambele ca referințe reale între entități, nu ca legături lipite.

Acesta este argumentul care justifică cel mai des Drupal pentru o firmă care altfel ar sta comod pe Shopify și este cel care se respinge cel mai des ca un moft, până când o echipă editorială petrece un an lucrând în două interfețe de administrare.

Produse reglementate și cu multe atribute

Produsele care poartă date de conformitate sunt al patrulea caz. Substanțe chimice cu fișe de securitate. Dispozitive medicale cu numere de certificat și date de expirare. Alimente cu matrice de alergeni. Aparate electrice cu declarații de conformitate. Orice cu trasabilitate pe lot sau cu un indicator de vânzare restricționată.

Cerința nu este doar să stocați acele valori. Este să le validați, să le versionați, să o arătați pe cea potrivită pentru lotul primit efectiv de client și să dovediți ulterior ce era publicat la o anumită dată. API-ul de câmpuri al Drupal și sistemul lui de revizii fac asta fiindcă au fost construite pentru guvernanța conținutului, nu pentru merchandising.

Partea de aplicare a regulilor contează la fel de mult. Un procesator de comandă poate refuza o finalizare care ar trimite un articol cu restricție de vârstă către o țară care îl interzice, sau care ar combina două articole ce nu au voie să călătorească împreună, și poate face asta în interiorul fluxului de comandă, nu într-un șablon de temă.

Pe o platformă găzduită fiecare dintre verificările acelea este o aplicație, iar aplicațiile nu se compun. Două aplicații care modifică amândouă coșul sunt două aplicații care într-o zi nu se vor înțelege.

Când ERP-ul este sursa de adevăr

Al cincilea caz este structural. Într-o firmă de distribuție sau de producție, ERP-ul deține stocul, prețurile, creditul clientului și starea comenzii, iar site-ul este o suprafață de afișare cu un coș atașat. Întrebarea nu este ce poate magazinul, ci cât de ieftin poate fi ținut în acord cu sistemul care conduce de fapt.

Drupal Commerce se simte bine aici fiindcă integrarea rulează în propriul dumneavoastră proces. API-ul de cozi se ocupă de munca asincronă, API-ul de migrare se ocupă de importuri repetabile și idempotente, iar nu există niciun intermediar care să taxeze pe înregistrare sau să vă limiteze fereastra de sincronizare. Un import nocturn de prețuri și stocuri de 200.000 de rânduri este o sarcină cron.

Pe o platformă găzduită, aceeași integrare este fie un abonament la o aplicație, fie unul la un middleware, iar limitele de apeluri ale platformei devin o constrângere de arhitectură în jurul căreia proiectați, nu un detaliu. Este fezabil, iar pentru multe firme este compromisul corect. Încetează să fie corect când sincronizarea este în același timp mare, frecventă și critică pentru afacere.

Dacă munca de integrare este grosul proiectului, nu magazinul în sine, atunci este un angajament de dezvoltare software cu o vitrină atașată și ar trebui delimitat așa de la bun început.

Taxele sunt locul unde platformele găzduite încetează să fie ieftine

Taxele sunt centrul de cost tăcut al comerțului electronic transfrontalier și acolo începe comparația abonamentelor lunare să inducă în eroare. Două praguri decid aproape totul.

Pragul de înregistrare în scopuri de TVA din Regatul Unit

Ghidul GOV.UK despre momentul înregistrării în scopuri de TVA fixează pragul la £90.000 din cifra de afaceri impozabilă totală. Două teste separate declanșează înregistrarea: un test glisant pe douăsprezece luni, în care trebuie să vă înregistrați în 30 de zile de la sfârșitul lunii în care cifra de afaceri a depășit £90.000, și un test prospectiv, în care trebuie să vă înregistrați imediat ce vă dați seama că cifra de afaceri va depăși £90.000 în următoarele 30 de zile.

Testul prospectiv este cel care prinde magazinele în creștere, fiindcă data înregistrării este ziua în care v-ați dat seama, nu ziua în care au intrat banii.

TVA în UE și ghișeul unic

Ghidul Comisiei Europene despre locul impozitării stabilește un prag anual combinat de EUR 10.000 care acoperă împreună vânzările intracomunitare la distanță de bunuri și serviciile de telecomunicații, radiodifuziune și electronice. Sub el, locul impozitării este acolo unde începe expedierea sau transportul. Peste el, impozitarea se mută acolo unde se încheie transportul, adică la cota clientului, în țara clientului.

Ghișeul unic vă lasă să declarați tot asta într-o singură declarație, într-un singur stat membru, depusă trimestrial cu termene la sfârșitul lunilor aprilie, iulie, octombrie și ianuarie. Ghișeul unic pentru importuri acoperă bunurile importate din afara UE în transporturi care nu depășesc EUR 150.

Ce face Drupal Commerce nativ în privința asta

Commerce include un plugin de taxare pentru TVA-ul Uniunii Europene chiar în nucleu, nu ca supliment. Poartă cotele pentru toate cele 27 de state membre plus Monaco, distinge cotele standard, reduse, intermediare, super reduse și zero și tratează teritoriile speciale de care se împiedică tabelele plate de cote, printre care Corsica, Azore, Madeira, insulele grecești și enclava austriacă Jungholz.

Aplică și regulile, nu doar cotele: impozitare la destinație pentru bunuri digitale și livrări intracomunitare între firme cu cotă zero atunci când se furnizează un cod fiscal valid. Pe o platformă găzduită, comportamentul acela este de obicei o aplicație cu un cost pe tranzacție.

Plăți, PCI DSS și felul în care încasați cardul

Modul în care colectați numărul cardului decide povara de conformitate, iar regulile s-au schimbat recent într-un fel larg înțeles greșit.

Clarificarea PCI Security Standards Council privind criteriile de eligibilitate pentru SAQ A explică un criteriu intrat în vigoare pe 1 aprilie 2025. Comercianții trebuie să confirme că site-ul lor nu este vulnerabil la atacuri prin scripturi care ar putea afecta sistemele lor de comerț electronic, ceea ce se îndeplinește fie aplicând tehnicile din cerințele PCI DSS 6.4.3 și 11.6.1, fie obținând de la procesatorul de plăți confirmarea că soluția lui integrată include acele protecții.

Delimitarea exactă este partea pe care lumea o ratează. Criteriul acela se aplică doar comercianților a căror pagină încorporează formularul de plată al furnizorului, de regulă într-un iframe. Council-ul precizează că nu se aplică comercianților care redirecționează clientul către furnizor, fie prin redirecționare HTTP, fie prin meta refresh sau JavaScript, și nici comercianților care externalizează complet funcțiile de plată.

Așadar, o redirecționare găzduită păstrează suprafața mică. Câmpurile încorporate, care convertesc mai bine și pe care aproape toată lumea le vrea de fapt, aduc integritatea fiecărui script de pe pagina de finalizare în discuția dumneavoastră despre conformitate.

Aici stă avantajul real al Shopify, fiindcă finalizarea este a lor și scripturile de pe ea sunt ale lor. Pe Drupal Commerce finalizarea este a dumneavoastră, deci răspunsul trebuie construit: o politică strictă de securitate a conținutului, subresource integrity, un inventar al fiecărui script care rulează pe pagina de plată și detectarea schimbărilor când unul dintre ele se mișcă. Munca aceea nu este nici grea, nici opțională, și trebuie să stea în buget, nu să fie descoperită în timpul unui audit.

Accesibilitatea este un risc juridic și comercial

Defectele de accesibilitate din comerțul electronic se strâng în pasul de finalizare, adică exact acolo unde fiecare defect costă bani direct.

Referința relevantă este WCAG 2.2, o recomandare W3C publicată pe 12 decembrie 2024. Criteriile care mușcă într-un magazin sunt precise. 1.3.5 Identify Input Purpose, nivel AA, acoperă completarea automată a câmpurilor de adresă și de card. 3.3.7 Redundant Entry, nivel A, este încălcat de fiecare dată când o finalizare obligă clientul să retasteze adresa de livrare la pasul de plată. 3.3.8 Accessible Authentication, nivel AA, guvernează crearea contului și autentificarea. 2.5.8 Target Size, nivel AA, prinde selectoarele de cantitate și butoanele de scoatere din coș, iar 1.4.3 Contrast, nivel AA, prinde butonul gri care în realitate este activ.

Alte două stau în jurul comenzii propriu-zise: 3.3.1 Error Identification, nivel A, și 3.3.4 Error Prevention pentru tranzacții juridice, financiare și de date, nivel AA, care se referă chiar la plasarea unei comenzi.

Poziția juridică din Regatul Unit este adesea exagerată. Un comerciant privat nu este obligat de o lege care să numească un nivel de conformitate WCAG. Se aplică obligația din articolul 20 al Equality Act 2010 de a lua măsuri rezonabile pentru a evita un dezavantaj substanțial pentru persoanele cu dizabilități, inclusiv furnizarea de mijloace auxiliare. Reglementările care chiar numesc un nivel, Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, se aplică organismelor publice, nu magazinelor.

Punctul comercial este mai ascuțit decât cel juridic. Pe o temă găzduită nu puteți repara întotdeauna ce injectează o aplicație în finalizarea comenzii. Pe o platformă pe care o controlați, puteți.

Cât costă de fapt trei ani

Comparația pe care o face lumea pune abonamentul lunar față în față cu găzduirea lunară, cea mai puțin importantă linie din tabel. Costul construcției și întreținerea domină, iar la volum domină procentele pe tranzacție.

Intervalele de mai jos sunt estimări interne Mecanik pentru un magazin britanic de nivel mediu, cu excepția cifrelor de abonament și comision Shopify, citate în lire exact așa cum le publică Shopify. Restul este ce ne-am aștepta să ofertăm, iar deschiderea din fiecare rând este mai mare decât distanța dintre platforme la capătul de jos.

Ce cumpără de fapt fiecare linie din tabel

În proză: Shopify Advanced costă între £9.324 și £12.384 în abonament pe trei ani, în funcție de angajamentul anual, și include găzduirea, dar adaugă abonamente la aplicații care ajung realist între £5.400 și £14.400 în aceeași perioadă. WooCommerce nu plătește nimic pentru platformă și între £3.600 și £14.400 pentru găzduire, cu extensii de £3.000 până la £9.000 pe cei trei ani. Drupal Commerce nu plătește nimic pentru licență, cheltuiește cel mai mult pe găzduire, între £5.400 și £21.600, fiindcă este cea mai grea aplicație dintre cele trei, și cel mai puțin pe module suplimentare, între nimic și circa £3.000, fiindcă echivalentele sunt module contribuite, nu comerciale.

Costul construcției este locul unde platformele se despart. O construcție Shopify de £8.000 până la £25.000 cumpără un magazin cu temă și integrările standard, față de £10.000 până la £35.000 pe WooCommerce. Aceeași temă de proiect pe Drupal Commerce înseamnă £35.000 până la £120.000, fiindcă finalizarea, logica de preț și integrările sunt toate scrise, nu configurate. Întreținerea urmează aceeași formă, cu £3.000 până la £9.000 pe an pentru Shopify, £4.000 până la £12.000 pentru WooCommerce și £12.000 până la £30.000 pentru Drupal Commerce, reflectând tarife zilnice de agenție britanică de circa £600 până la £900, tratate în ghidul nostru despre tarifele dezvoltatorilor Drupal.

Unde ajung totalurile pe trei ani

Totalurile pe trei ani ajung la aproximativ £32.000 până la £79.000 pentru Shopify, £29.000 până la £94.000 pentru WooCommerce și £76.000 până la £235.000 pentru Drupal Commerce. Comisioanele de card și de gateway se adaugă la toate trei și cresc cu cifra de afaceri, motiv pentru care comisionul Shopify pentru gateway terț de 0,6 % pe Advanced valorează £18.000 pe trei ani într-un magazin de 1 milion de lire.

Citiți tabelul cinstit și Drupal Commerce costă de două până la trei ori mai mult. Se justifică doar când alternativa nu este de fapt disponibilă, ceea ce este chiar rostul celor cinci secțiuni de mai sus.

Drupal Commerce headless și decuplat

Decuplarea Drupal Commerce este o cerință reală într-un set îngust de cazuri și o modă în aproape tot restul. Testul cinstit este dacă altceva decât un site web are nevoie de același catalog.

Este o cerință reală când o aplicație mobilă nativă și un site trebuie să împartă un singur model de produs și de preț, când un frontend existent construit de altă echipă nu este înlocuit, când terminale de casă sau chioșcuri consumă același coș, sau când un sistem de design aparține cuiva din afara proiectului și nu poate fi exprimat în Twig. În acele cazuri API-ul este produsul, iar CMS-ul este intenționat invizibil.

Este modă atunci când motivul invocat este performanța. Un frontend Drupal tradițional bine pus în cache servește paginile de produs anonime de la marginea rețelei, iar metoda de randare este rareori ceea ce face lent un magazin lent.

Costul se concentrează într-un singur loc. Nucleul Drupal expune conținutul prin JSON:API fără configurare, iar modulul Commerce Cart API pune coșurile în spatele unei interfețe REST, deci citirea unui catalog și construirea unui coș sunt aproape gratuite. Finalizarea nu. Tratarea adreselor, afișarea taxelor, alegerea livrării, promoțiile, integrarea elementului de plată și confirmarea comenzii trebuie rescrise toate în frontend, iar asta înseamnă de obicei 40 % sau mai mult din întreaga construcție.

Regula de decizie în cinci minute

Răspundeți la șase întrebări despre propriul catalog. Fiecare da valorează un punct.

Are vreunul dintre produse nevoie de mai mult de trei opțiuni sau de mai mult de 2.048 de combinații vandabile? Plătesc doi clienți diferiți vreodată prețuri diferite pentru același cod de produs? Vindeți în mai multe țări cu tratamente de TVA diferite sau vă așteptați să depuneți o declarație OSS? Este catalogul și conținut editorial pe care aceeași echipă îl scrie și îl întreține? Este un ERP sau un PIM autoritatea pentru preț și stoc, magazinul fiind în aval de el? Trebuie să inserați logică proprie în finalizarea comenzii, nu doar să îi schimbați aspectul?

Cu zero sau un punct alegeți Shopify. Avantajele descrise în acest articol nu vi se aplică și ați plăti ca să reconstruiți ceea ce acum închiriați.

Cu două puncte decizia este cu adevărat deschisă, iar WooCommerce este adesea calea de mijloc mai bună, mai ales dacă echipa rulează deja WordPress.

Cu trei sau mai multe puncte merită să calculați serios Drupal Commerce, fiindcă ocolișurile necesare în altă parte vor costa mai mult decât platforma pe trei ani. Cu cinci sau șase puncte platforma găzduită nu este o opțiune mai ieftină, ci un produs diferit care nu face treaba.

Unde greșesc de obicei proiectele Drupal Commerce

Cea mai frecventă eroare este alegerea lui din motivul greșit. Rulăm deja Drupal nu este o cerință de comerț. Un site de conținut și un site tranzacțional au cerințe de disponibilitate diferite, testare diferită și consecințe diferite când o punere în producție merge prost, iar tratarea magazinului ca pe încă o secțiune a site-ului existent este felul în care un proiect mic de comerț electronic capătă o echipă de platformă neplanificată.

Al doilea este subfinanțarea întreținerii. Cu 35.870 de instalări, ecosistemul este suficient de mic încât veți folosi module cu o mână de întreținători, iar cineva din partea dumneavoastră trebuie să urmărească avizele de securitate și să programeze actualizările. Un site Drupal Commerce de care nu răspunde nimeni este un incident de securitate cu întârziere, subiect tratat mai pe larg alături de cerințele de găzduire pe care Drupal chiar le are.

Al treilea este presupunerea că există un modul. Verificați înainte de a estima. Dacă nu există, munca este o dezvoltare de site web la comandă și cere o estimare reală, nu o linie într-o listă.

Al patrulea este disciplina versiunilor majore. Commerce 3 cere Drupal 10.3 sau mai nou, iar un site care rămâne în urma nucleului descoperă la un moment dat că modulele lui de comerț au mers mai departe fără el. Ghidul nostru despre dezvoltarea Drupal în 2026 și articolul despre costurile și termenele migrării tratează amândouă acest ciclu.

Cum luați decizia corectă

Alegerea se decide după complexitatea produsului și a prețului, nu după trafic, cifră de afaceri sau preferință. Modelați-vă mai întâi catalogul, pe hârtie, cu fiecare opțiune, fiecare preț negociat și fiecare integrare care trebuie să rămână în acord cu altceva. Dacă modelul acela încape într-o grilă de variante, cumpărați platforma găzduită și cheltuiți bugetul economisit pe merchandising.

Mecanik construiește și întreține ambele tipuri de magazin și vă vom spune de care parte a liniei vă aflați înainte de a oferta ceva. Dacă răspunsul este Drupal Commerce, lucrarea este un angajament de dezvoltare de site web cu o componentă serioasă de integrare; dacă munca pe ERP depășește vitrina, ea aparține mai degrabă zonei de dezvoltare software. Dacă răspunsul este Shopify, o vom spune, și preferăm să o spunem acum, nu la optsprezece luni după începerea unei refaceri.

Întrebări frecvente

Este Drupal Commerce mai bun decât Shopify? Nu pentru majoritatea magazinelor. Shopify costă mai puțin pe trei ani, se ocupă de conformitatea PCI și de găzduire și are o finalizare testată la o scară pe care nicio agenție nu o poate egala. Drupal Commerce câștigă într-un set îngust de cazuri: produse cu mai mult de trei opțiuni sau 2.048 de variante, prețuri negociate pe client, cataloage care sunt și conținut editorial și magazine în care un ERP deține prețul și stocul.

Cât costă o construcție Drupal Commerce în Regatul Unit? Așteptați-vă la £35.000 până la £120.000 pentru construcția inițială și £12.000 până la £30.000 pe an pentru întreținere, la tarife zilnice de agenție britanică de circa £600 până la £900. Pe trei ani, un magazin Drupal Commerce ajunge de obicei între £76.000 și £235.000 cu tot cu găzduire, față de aproximativ £32.000 până la £79.000 pentru Shopify Advanced. Acestea sunt estimări interne, nu oferte.

Ce versiune de Drupal Commerce ar trebui să folosesc? Drupal Commerce 3, aflat acum la 3.3.8, publicat pe 17 iulie 2026. Funcționează cu Drupal 10.3 sau mai nou și cu Drupal 11, iar versiunile lui stabile intră sub politica de securitate a Drupal. Commerce 2 a susținut Drupal 9 și 10 și este ciclul de lansare anterior, deci proiectele noi ar trebui să pornească pe linia 3.x.

Se descurcă Drupal Commerce cu TVA-ul din UE și cu OSS? Regulile fiscale sunt integrate în nucleul Commerce, nu vândute ca supliment. Pluginul de TVA al Uniunii Europene poartă cotele pentru toate cele 27 de state membre plus Monaco, distinge cotele standard, reduse, intermediare, super reduse și zero, tratează teritoriile speciale, aplică impozitarea la destinație bunurilor digitale și duce la zero livrările B2B intracomunitare cu un cod fiscal valid. Depunerea declarației OSS rămâne o sarcină de contabilitate.

Când merită Drupal Commerce headless? Când altceva decât un site web consumă același catalog, de exemplu o aplicație nativă, un terminal de casă sau un frontend deținut de altă echipă. Nu merită doar pentru viteză, fiindcă un frontend tradițional pus în cache este deja rapid. Puneți în buget rescrierea finalizării comenzii, care înseamnă de obicei 40 % sau mai mult dintr-o construcție decuplată.