WooCommerce 11.3 lasă extensiile să declare ce articole din coș sunt copii ale altor articole, printr-un filtru nou și un câmp read-only parent_item_key în Store API. Practic, un produs introdus doar într-un bundle nu mai apare ca „1 în coș” pe cont propriu. Pentru magazinele cu bundle-uri, e o corectare de precizie la semnalul din buton.

Ce s-a schimbat concret în WooCommerce 11.3

Anunțul din 27.10.2026, publicat pe blogul pentru dezvoltatori al WooCommerce, descrie o schimbare care pare mică și tehnică, dar care atinge direct modul în care cumpărătorul percepe starea coșului. Până acum, butonul de produs din blocul Product Button (inclusiv cel din Add to Cart with Options) număra orice articol din coș care avea legătură cu produsul respectiv. Dacă un produs intra în coș doar pentru că făcea parte dintr-un bundle, butonul lui afișa „1 în coș”, deși clientul nu îl adăugase niciodată separat.

Core-ul WooCommerce nu are cum să facă diferența între un articol adăugat intenționat și unul adăugat automat ca parte dintr-un pachet. De aceea, în 11.3, responsabilitatea trece la extensie: cea care creează articolul copil trebuie să declare cui aparține. Mecanismul e un filtru nou, woocommerce_store_api_cart_item_parent_item_key, plus un câmp nou, read-only, în articolele din coșul Store API: parent_item_key, un string sau null implicit.

Câteva detalii contează pentru cineva care lucrează la un magazin. WooCommerce nu marchează niciodată singur un articol ca fiind copil, doar extensia o face. Cheia părintelui e returnată doar cât timp părintele e în coș; dacă părintele dispare, parent_item_key devine null și copilul e tratat din nou ca articol de sine stătător. Dacă filtrul returnează o cheie care nu corespunde niciunui articol din coș, sau chiar cheia articolului însuși, WooCommerce returnează null. Și un detaliu care merită subliniat: dacă un produs apare pe mai multe linii de coș, numărul afișat însumează acum toate liniile, nu doar prima, cum se întâmpla înainte.

De ce contează pentru un magazin care vinde bundle-uri

Diferența dintre „1 în coș” afișat corect și unul afișat greșit nu e cosmetică. Butonul de produs e un semnal de intenție: îi spune cumpărătorului ce are deja în coș și ce mai poate adăuga. Când semnalul e fals, apar două efecte. Primul e confuzia directă: clientul vede că produsul e „în coș” și nu înțelege de ce, pentru că el nu l-a adăugat. Al doilea e mai subtil și mai costisitor: scade încrederea în restul cifrelor din magazin. Dacă un contor e greșit, de ce ar fi corect prețul, stocul sau estimarea de livrare?

Pentru magazinele care vând pachete, seturi, produse compuse sau „frecvent cumpărate împreună”, problema e sistemică, nu accidentală. Extensiile care adaugă articole în numele altui articol sunt exact cele vizate: bundle-uri, produse compuse, mix and match, force sells, produse înlănțuite, recomandări de tipul „frecvent cumpărate împreună”. Toate acestea creează linii de coș pe care utilizatorul nu le-a cerut explicit, iar până acum core-ul nu avea cum să le distingă.

Există și o zonă gri asumată de anunț: plugin-urile de cadou gratuit sau de upsell care adaugă un produs real legat de alt articol pot decide în ambele sensuri, pentru că „1 în coș” poate fi corect pentru ele. Aici e o decizie de produs, nu doar de cod. Dacă magazinul vrea să comunice clar că un cadou e al clientului, atunci poate să îl lase ca articol independent. Dacă vrea să comunice că e o componentă a pachetului, îl declară copil. Ambele variante sunt valide, dar trebuie alese conștient.

Un lucru important de spus fără ocolișuri: nimic nu se strică dacă extensia nu adoptă filtrul. Articolele continuă să fie numărate ca până acum. Deci nu e o urgență de tip „site-ul cade”, ci o corectare de precizie pe care o faci când ai timp și când ai interes. Dar dacă ai bundle-uri și clienții tăi întreabă de ce un produs apare ca fiind în coș fără să îl fi adăugat, ai răspunsul.

Ce trebuie să facă efectiv un developer

Anunțul e clar aici: dacă extensia ta adaugă articole în coș în numele altui articol, ești afectat. Verificarea e simplă și o poate face și un om de marketing cu acces la un mediu de test: adaugă produsul părinte în coș și uită-te la butonul unuia dintre produsele adăugate automat. Dacă scrie „1 în coș”, extensia ar trebui să folosească filtrul nou.

Implementarea cere un pas pe care mulți îl ratează: să stochezi cheia articolului părinte din coș, cea returnată de WC()->cart->add_to_cart(), nu ID-ul produsului. Confuzia dintre cele două e clasică și e exact genul de greșeală care face filtrul să returneze null fără să pară o eroare. Cheia se salvează în datele articolului copil și se returnează din filtru. Pentru orice alt articol, returnezi valoarea primită neschimbată, ca să nu ștergi un părinte declarat de altă extensie.

Nu trebuie să cureți cheia stocată când părintele pleacă din coș; WooCommerce se ocupă de asta. Documentația Store API are un exemplu complet, cu adăugarea părintelui și a copilului.

Aici intervine o regulă de verificare pe care o aplicăm constant: o verificare incompletă nu dovedește absența unei funcții. Dacă butonul încă arată „1 în coș” după ce ai adăugat filtrul, nu înseamnă automat că WooCommerce e stricat. Poate însemna că extensia nu stochează corect cheia, că o altă extensie suprascrie filtrul sau că testul a fost făcut pe un articol care nu e copil. Verifică în ordine, cu probe, nu cu presupuneri.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin pe WooCommerce și vinzi pachete, seturi sau produse compuse, întrebarea relevantă nu e „ce face 11.3”, ci „cine răspunde de extensia care creează bundle-urile”. În multe echipe mici din România, bundle-urile au fost instalate de un freelancer acum câțiva ani și nimeni nu mai știe exact ce versiune rulează și dacă e întreținută. Exact acolo apar contoarele greșite.

Al doilea lucru de urmărit e legat de măsurare, nu de interfață. Dacă folosești evenimente de tip add_to_cart pentru a urmări intenția, asigură-te că înțelegi ce se trimite atunci când un articol e adăugat automat. Confuzia dintre „adăugat de client” și „adăugat de extensie” nu se rezolvă în analytics prin speranțe. Se rezolvă prin a ști exact ce emite platforma. Aici se leagă și discuția despre igiena datelor de tracking, discutată în analiza despre scriptul de analytics compromis care a ajuns skimmer pe checkout: cu cât înțelegi mai bine ce scripturi și ce evenimente rulează în checkout, cu atât mai puțin loc rămâne pentru surprize.

Al treilea lucru e legat de experiența de cumpărare. Dacă ai bundle-uri, testează fluxul ca un client: adaugă pachetul, mergi la pagina produsului inclus și uită-te la buton. Dacă vezi „1 în coș” fără să fi adăugat produsul, ai o problemă de percepție, nu de COD. Iar problema de percepție se traduce în întrebări la suport și în coșuri abandonate din motive greu de explicat.

Pentru magazinele care rulează și pe Shopify, discuția despre cine controlează datele din coș și din checkout e similară, deși mecanismele diferă. Merită citită și analiza despre mutarea payout-urilor Shopify în Dev Dashboard, pentru că arată aceeași tendință: platformele mută tot mai multă responsabilitate către extensii și către dezvoltator, iar operatorul de magazin trebuie să știe cine răspunde de ce.

Limite, ipoteze și ce nu știm încă

Anunțul spune explicit că, deocamdată, contorul din Product Button e singurul loc care folosește parent_item_key. Ideea declarată e că blocurile vor putea conta pe acest câmp oricând au nevoie să știe că un articol aparține altuia. Se dă ca exemplu viitor posibilitatea ca blocurile Cart și Mini-Cart să afișeze articolele copil indentate sub părinte. Asta e o intenție declarată, nu o funcție livrată. Tratează-o ca atare.

Aici e locul unde mulți fac saltul greșit: citesc „în viitor Cart și Mini-Cart ar putea” și raportează „WooCommerce afișează acum copiii indentați”. Nu. E o direcție, nu o livrare. Orice decizie de design care depinde de ea ar trebui să aibă un plan B.

O a doua zonă de ipoteză: impactul asupra conversiei. Anunțul nu oferă cifre, nu oferă studii, nu spune că vânzările cresc dacă adopți filtrul. E o corectare de acuratețe. Orice promisiune de tipul „adoptă filtrul și scazi abandonul” ar fi inventată. Nu avem date pentru asta și nu o vom afirma.

O a treia zonă: ecosistemul de extensii. Nu știm, din materialul sursă, care extensii au adoptat deja filtrul și care nu. Nu știm nici dacă există un calendar public de adopție. Deci recomandarea practică e să întrebi furnizorul extensiei, nu să presupui. Dacă furnizorul nu răspunde, un test în staging îți dă mai mult decât orice promisiune.

Pași propuși pentru următoarele săptămâni

Primul pas e inventarul. Fă o listă cu extensiile care pot adăuga articole în coș în numele altui articol: bundle-uri, produse compuse, cadouri, upsell-uri, recomandări. Pentru fiecare, notează versiunea și furnizorul.

Al doilea pas e testul de comportament. Pe un mediu de test, adaugă părintele în coș și verifică butonul fiecărui copil. Notează ce vezi, cu screenshot. Nu te baza pe memorie.

Al treilea pas e întrebarea către furnizor: „Ați adoptat filtrul woocommerce_store_api_cart_item_parent_item_key în versiunea X?” Dacă răspunsul e nu, decide dacă aștepți sau dacă faci tu modificarea, dacă extensia e proprie sau dacă ai un developer disponibil.

Al patrulea pas e verificarea după orice actualizare. Filtrul poate fi suprascris de altă extensie, iar un update poate schimba comportamentul. O verificare periodică e mai ieftină decât o reclamație de la client.

FAQ

Trebuie să fac ceva dacă magazinul meu nu folosește bundle-uri? Nu. Dacă toate articolele din coș sunt adăugate direct de client, nu ai articole copil de declarat, iar comportamentul rămâne cel de până acum.

Filtrul repară automat contorul greșit? Nu. Filtrul e mecanismul prin care extensia poate declara relația. Dacă extensia nu îl folosește, contorul rămâne cum e azi. Anunțul spune clar că nimic nu se strică, dar nici nu se repară singur.

Ce se întâmplă dacă părintele e scos din coș? Cheia părintelui devine null, iar copilul e tratat ca articol de sine stătător. Nu trebuie să cureți tu cheia stocată; WooCommerce gestionează asta.

Arc final: AI-ul ajută, omul decide, agenția execută

Unelte AI pot accelera partea plictisitoare: să faci inventarul extensiilor, să compari versiuni, să generezi un checklist de test, să structurezi un tabel cu rezultate. Pot ajuta și la planning, la redactarea întrebărilor către furnizori, la documentarea pașilor. Dar AI-ul nu vede butonul din pagina de produs și nu decide dacă „1 în coș” e corect sau nu în magazinul tău. Decizia și execuția rămân la media buyer și la omul care răspunde de magazin, pentru că acolo e contextul real: ce vinzi, cum vinzi, ce promiți.

Pasul concret îl face ALLSoft Agency: audit pe fluxul de coș și pe extensiile care creează bundle-uri, verificare în staging, propunere de modificare acolo unde are sens. Fără promisiuni de cifre pe care nu le avem. Doar verificare, probe și decizie.