Când deschizi pagina Checkout dintr-un magazin WooCommerce, ai de fapt unul din două sisteme diferite sub același nume: checkout-ul clasic, construit pe un shortcode și pe șabloane PHP, sau checkout-ul cu blocuri, construit cu editorul de blocuri și cu un API propriu. Diferența contează în practică, pentru că tot ce ai adăugat în checkout prin hook-uri clasice nu funcționează în varianta cu blocuri, iar un magazin cu câmpuri românești (CUI, județ, localitate, tip de client) simte această diferență imediat.
Ghidul explică cum afli ce checkout folosești, cum funcționează fiecare, ce se strică cel mai des la trecerea de la unul la celălalt și cum îți aduci câmpurile personalizate în blocuri fără să pui comenzile în pericol.
Pe scurt: vezi în editorul paginii Checkout dacă ai shortcode-ul [woocommerce_checkout] (clasic) sau blocul Checkout. Magazinele noi folosesc în versiunile recente de WooCommerce checkout-ul cu blocuri, iar câmpurile suplimentare se adaugă acolo prin Additional Checkout Fields API (WooCommerce 8.9 sau mai nou), nu prin filtrele clasice. Testează întotdeauna pe staging înainte să treci un magazin real de la un sistem la celălalt.
Cum afli ce checkout folosești
Deschide în admin pagina creată pentru Checkout (de obicei la Pagini, cea setată în WooCommerce, Setări, Avansat, Configurare pagini) și uită-te la conținut. Dacă vezi un bloc Shortcode cu textul [woocommerce_checkout], ai checkout clasic. Dacă vezi un bloc numit Checkout, cu sub-blocuri pentru contact, adresă, metode de livrare și plată, ai checkout cu blocuri. Aceeași verificare se aplică și pentru coșul de cumpărături, care poate fi și el clasic sau cu blocuri.
Pe un magazin mai vechi, poate fi clasic, chiar dacă ai actualizat WooCommerce la zi: actualizarea nu înlocuiește automat conținutul paginilor existente. Pe un magazin nou, instalarea vine de regulă cu blocurile.
Cum funcționează checkout-ul clasic
Checkout-ul clasic afișează formularul printr-un shortcode și îl construiește din șabloane PHP, pe care le poți suprascrie în temă. Orice modificare se face prin hook-uri și filtre: woocommerce_checkout_fields pentru a adăuga sau scoate câmpuri, woocommerce_after_checkout_validation pentru validare, woocommerce_checkout_create_order pentru a salva date suplimentare în comandă. Ecosistemul e vast: majoritatea pluginurilor de livrare, facturare sau marketing au fost scrise pentru acest model.
Avantajul este flexibilitatea și compatibilitatea cu pluginurile existente. Dezavantajul este că interfața se simte mai veche, iar fiecare plugin care atinge checkout-ul poate intra în conflict cu altul, pentru că toate modifică același formular prin aceleași hook-uri.
Cum funcționează checkout-ul cu blocuri
Checkout-ul cu blocuri folosește editorul Gutenberg pentru structură și un API propriu (Store API) pentru date, iar interfața este desenată în JavaScript. De aici vin două consecințe. Prima: hook-urile clasice nu mai ajung în formular, pentru că formularul nu mai este generat de șabloane PHP. A doua: orice extensie trebuie să se conecteze prin mecanismele noi, adică Additional Checkout Fields API pentru câmpuri suplimentare, extensiile Store API pentru date și, la nevoie, componente JavaScript pentru interfață.
Ca să adaugi un câmp nou, îl înregistrezi în PHP cu funcția woocommerce_register_additional_checkout_field, în care alegi locația (contact, adresă sau comandă), tipul câmpului și regulile de validare. WooCommerce îl afișează, îl validează și îl salvează în metadatele comenzii. Funcția există începând cu WooCommerce 8.9, și merită să verifici documentația curentă înainte de implementare, pentru că API-ul continuă să evolueze.
Clasic față de blocuri, pe scurt
| Aspect | Checkout clasic | Checkout cu blocuri |
|---|---|---|
| Cum se construiește | Shortcode și șabloane PHP | Editor de blocuri și Store API |
| Câmpuri personalizate | Filtrul woocommerce_checkout_fields | Additional Checkout Fields API (WooCommerce 8.9 sau mai nou) |
| Validare personalizată | woocommerce_after_checkout_validation | Mecanismele de validare ale API-ului |
| Metode de plată | Orice gateway | Doar gateway-uri cu suport pentru blocuri |
| Pluginuri vechi | De obicei funcționează | Pot fi incompatibile |
| Direcția de dezvoltare | Întreținut | Direcția principală a WooCommerce |
Ce se întâmplă cu câmpurile românești
Un magazin românesc are câteva nevoi pe care checkout-ul standard nu le acoperă: tipul de client (persoană fizică sau firmă), CUI-ul și numărul de la registrul comerțului, uneori CNP-ul, și selectoare de județ și localitate care să se potrivească cu nomenclatorul curierilor. În checkout-ul clasic, le adaugi cu filtre și le validezi în woocommerce_after_checkout_validation, așa cum e descris în ghidul despre câmpurile și validarea pentru persoane fizice și firme. În blocuri, aceleași câmpuri se înregistrează prin Additional Checkout Fields API, iar logica de validare trebuie rescrisă pentru acest API.
Selectorul de localitate este cazul cel mai sensibil. Dacă magazinul trimite coletele prin curieri, județul și localitatea trebuie să se potrivească exact cu nomenclatorul curierului, altfel AWB-ul e respins; am explicat de ce în ghidul despre integrarea curierilor. Orice înlocuire de câmpuri de adresă în checkout trebuie testată cap-coadă cu generarea unui AWB. Pluginul nostru MaxDev Facturare cu ANAF funcționează în ambele variante de checkout tocmai pentru că înregistrează câmpurile pe calea potrivită fiecărei variante.
Ce se strică cel mai des la trecerea pe blocuri
De fiecare dată când un magazin trece pe blocuri, aceeași listă de probleme apare:
- Metodele de plată. Un gateway fără suport pentru blocuri pur și simplu nu apare în formular.
- Pluginurile de livrare cu hartă de lockere. Interfața lor se injecta în formularul clasic prin hook-uri, deci trebuie rescrisă pentru blocuri.
- Câmpurile adăugate cu filtre vechi. Nu mai apar, iar datele nu se mai salvează în comandă.
- CSS-ul personalizat. Selectorii se schimbă, deci stilurile făcute pe structura clasică nu mai se aplică.
- Evenimentele de tracking. Scripturile de analytics legate de formularul clasic pot să nu se mai declanșeze la achiziție, ceea ce îți falsifică datele din GA4 și din campaniile plătite.
- Cupoanele și regulile de preț. Pluginurile care modifică totalul în checkout trebuie să fie compatibile cu Store API.
Cum migrezi în siguranță
- Fă un backup complet și lucrează pe un mediu de staging, nu pe magazinul live.
- Inventariază pluginurile care ating checkout-ul: plată, livrare, facturare, marketing, tracking.
- Verifică în documentația fiecăruia dacă declară suport pentru checkout cu blocuri.
- Schimbă pe staging conținutul paginii Checkout cu blocul Checkout.
- Testează comenzi complete: persoană fizică, firmă, cu cod de reducere, cu ramburs, cu card, cu livrare în locker, cu eroare provocată intenționat.
- Repetă testele pe telefon, unde se pierd cele mai multe comenzi.
- Verifică comanda în admin, emailurile primite și datele trimise către programul de facturare, împreună cu modul de stocare a comenzilor descris în ghidul despre HPOS.
- Verifică evenimentele de achiziție din GA4 și din pixeli.
- Planifică un rollback: păstrează conținutul vechi al paginii, ca să poți reveni în câteva minute.
- Treci pe live în afara orelor de vârf.
Când rămâi pe clasic și când treci pe blocuri
Rămâi pe checkout clasic dacă magazinul depinde de pluginuri critice fără suport pentru blocuri, dacă ai câmpuri și reguli foarte personalizate care nu s-au migrat încă sau dacă nu ai timp pentru testare. Treci pe blocuri dacă vezi un magazin nou, dacă pluginurile tale declară suport și dacă vrei să te aliniezi direcției oficiale a WooCommerce. Nu trece doar pentru că „este noul standard”: dacă magazinul vinde bine, o migrare greșită costă mai mult decât orice beneficiu. Nu promitem că blocurile sunt mai rapide: dacă viteza e motivul, măsoară întii cu Core Web Vitals, așa cum explicăm la optimizarea vitezei.
Întrebări frecvente
Pot folosi ambele tipuri de checkout în același magazin?
Pe aceeași pagină, nu: o pagină Checkout folosește fie shortcode-ul clasic, fie blocul Checkout. Poți însă reveni oricând, înlocuind conținutul paginii.
Datele din comenzile vechi se pierd dacă trec pe blocuri?
Nu. Comenzile existente rămân în baza de date. Se pot pierde doar câmpurile noi, dacă nu le înregistrezi în noul sistem înainte de migrare.
De ce nu apar câmpurile mele personalizate în checkout cu blocuri?
Pentru că filtrele clasice (precum woocommerce_checkout_fields) nu mai sunt folosite de blocuri. Câmpurile trebuie înregistrate prin Additional Checkout Fields API.
Pluginul MaxDev Facturare cu ANAF funcționează în ambele variante?
Da. Folosește checkout-ul clasic și Additional Checkout Fields API pentru blocuri, cu WooCommerce 8.9 sau mai nou.
Care e riscul cel mai mare la migrare?
O metodă de plată care nu apare în formular. Testează plata cu fiecare metodă activă înainte de go-live.
Dacă ai un checkout cu multe personalizări și vrei să-l treci în siguranță, echipa noastră de dezvoltare WooCommerce face migrări cu teste complete pe staging.
