WooCommerce 11.3 este în beta din 26 octombrie 2026, iar lansarea finală e programată în săptămâna 9 noiembrie 2026. Versiunea aduce controale de stil extinse pentru blocuri, badge-uri de reducere cu sumă sau procent, îmbunătățiri la galeria de produse pe mobil, plus schimbări în Analytics, REST API și MCP. Pentru un magazin online, miza reală nu e estetică: e cât de curat ajung datele de produs și comandă în rapoarte și în integrări.

Sursa: WooCommerce Developer Blog, anunț semnat de Brian Coords.

Ce se schimbă concret în WooCommerce 11.3

Anunțul vorbește despre 1.310 commit-uri și 117 contribuitori până în acest moment. Nu e o versiune de întreținere, e o tranșă consistentă. Cele mai vizibile modificări pentru cine administrează un magazin:

Controale de stil extinse pe blocuri. Blocurile Product, Featured Product, Featured Category, Product Categories List și altele primesc opțiuni noi de culoare, spațiere și borduri, adaptate per bloc. În plus, Featured Category poate fi folosit în Terms Query, ceea ce permite afișarea unor colecții de categorii într-un mod unitar.

Badge de reducere cu conținut flexibil. Blocul On-Sale Badge poate afișa text personalizat, suma economisită sau procentul de reducere, cu prefix și sufix. Pentru produsele variabile se afișează reducerea maximă, cu formularea „Up to”. Pe pagina de produs cu Add to Cart + Options, badge-ul se actualizează la varianta selectată și dispare dacă varianta aleasă nu e la reducere.

Galerie de produse mai fluidă pe mobil. Scroll nativ și snap, imaginile urmează degetul, cu inerție naturală la gesturi rapide.

Analytics Orders cu filtru pe metodă de plată. Mic, dar util pentru reconciliere.

Pagini de politică de retur configurabile. Comerciantul poate selecta pagina de refund și returns policy din Settings → Advanced → Page setup, iar WooCommerce adaugă date structurate cu link către acea pagină, fără markup custom.

Aici apare prima discuție serioasă de marketing: datele structurate pentru politica de retur nu sunt un detaliu tehnic. Sunt un semnal pe care motoarele de căutare îl pot folosi. Nu îți garantează poziții, dar îți dă un cadru curat pentru citare și pentru încrederea cumpărătorului. Cine lucrează pe zona de SEO și GEO știe că astfel de lucruri se pierd sau se câștigă pe detalii, nu pe sloganuri. Despre cât de stabile sunt semnalele pe care le trimitem către sistemele automate am scris separat în analiza despre cât de stabile sunt citările AI.

REST API: on_sale devine previzibil în combinație cu include și exclude

Aici e partea care contează cel mai mult pentru cine are integrări. Înainte de 11.3, combinarea parametrului on_sale cu include sau exclude producea rezultate care nu respectau logica așteptată. Concret, cererea on_sale=true&include=10,13 putea întoarce mai multe produse decât cele din include, dacă lista de produse la reducere era mai lungă. on_sale=false + include ignora complet on_sale. on_sale=true + exclude ignora exclude.

Din 11.3, comportamentul se aliniază cu ceilalți parametri de tip featured sau type. on_sale=true + include returnează doar produsele care sunt simultan în include și la reducere. Endpoint-urile afectate: Products REST API v2 și v3, Product Variations REST API v2 și v3, plus Products Store API v1.

De ce contează pentru marketing? Pentru că feed-urile de produse, listele dinamice din reclame și rapoartele custom se bazează pe aceste interogări. Dacă o integrare se baza pe comportamentul vechi, vei vedea dintr-o dată mai puține produse în răspuns. Nu e o eroare, e corecție. Dar dacă nu o observi, poți trage concluzii greșite despre performanța unui segment de produse. Recomandarea mea: înainte de update, listează toate locurile în care codul tău sau plugin-urile tale fac cereri cu on_sale combinat cu include ori exclude, și retestează-le pe un mediu non-producție.

Validare strictă la rambursări: date de comandă mai curate

A doua schimbare importantă pentru cine lucrează cu integrări: endpoint-ul POST /wp-json/wc/v3/orders/{order_id}/refunds validează explicit sumele pe linii înainte de a crea rambursarea. Până acum, o rambursare cu alocări contradictorii putea trece și lăsa în urmă înregistrări de comandă și raportări Analytics incoerente.

Din 11.3, cererile invalide returnează HTTP 400 sau 422 cu cod de eroare woocommerce_rest_*. De exemplu, un amount de 3 cu un line-item refund_total de 4 returnează 400. O alocare peste soldul rămas pe linie returnează 422. Pentru cine are integrare cu ERP, cu sistem de facturare sau cu un modul de retur, asta înseamnă un lucru simplu: verifică răspunsul înainte să consideri rambursarea creată. Nu retrimite același payload. Corectează alocarea.

Aici fac o distincție pe care o repet: o eroare de validare returnată de API nu dovedește că ai pierdut bani sau că raportarea e compromisă. Dovedește că cererea a fost respinsă. Orice concluzie despre impact financiar cere verificare în date reale, nu doar citirea unui răspuns HTTP. Exact aceeași disciplină se aplică și când interpretezi cifre din platforme, subiect pe care l-am tratat în analiza despre Shopify Analytics și App Events.

MCP, Purple și contextul blocurilor: ce afectează extensiile

WooCommerce 11.3 elimină endpoint-ul depreciat /wp-json/woocommerce/mcp și calea de conectare prin cheie REST API. Nu mai include pachetele MCP Adapter și Abilities API. Abilitățile de bază pentru produse și comenzi rămân active implicit, iar accesul prin MCP se face cu plugin-ul WordPress MCP Adapter și o parolă de aplicație WordPress.

Pentru dezvoltatorii de extensii: API-ul experimental Extensible abilities e dezactivat implicit. Când e activat, permite extensiilor să adauge câmpuri la citirea de produse și comenzi, să suporte câmpuri la scriere și să înregistreze filtre și validatori. Echipa cere testare în afara producției, pentru că API-ul încă se schimbă. Aici e o limită clară: nu e ceva ce pui live pe un magazin care generează venit.

Tema oficială de blocuri, Purple, e acum disponibilă în directorul de teme WordPress, în Woo marketplace și în directorul WordPress.com. Dezvoltarea ei s-a mutat în monorepo-ul WooCommerce.

Alte două modificări care pot rupe cod custom: blocul Single Product folosește acum contextul nativ de bloc WordPress, iar metoda extract_single_product_inner_block_names() și proprietățile aferente au fost eliminate. Și: pagina Shop se asociază direct cu template-ul Product Catalog când e activă o temă de blocuri, iar citirea _wp_page_template returnează archive-product, inclusiv dacă în baza de date e salvat alt template. Metadatele salvate rămân neschimbate, dar override-ul se aplică pe frontend, admin și REST.

Mai e și o corecție cu impact direct pe checkout: scutirea de TVA (is_vat_exempt) și calculul de livrare (calculated_shipping) rămân în sesiune la salvarea contului clientului. Înainte, orice salvare a contului, inclusiv salvarea adresei de facturare la checkout, reseta ambele valori la false. Practic, un client scutit de TVA care avea plata refuzată putea reveni cu taxă calculată la retry. Dacă ai cod care se baza pe resetarea automată a flag-ului, trebuie să îl setezi explicit în ambele sensuri.

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

Dacă ai un magazin pe WooCommerce și rulezi trafic plătit către el, 11.3 nu îți schimbă strategia. Îți schimbă igiena. Iată ce aș pune pe listă, în ordine:

1. Verifică feed-urile și integrările care ating REST API. Orice conexiune care cere produse cu on_sale plus include sau exclude trebuie retestată. Dacă folosești un plugin de feed pentru Google Shopping sau Meta, întreabă-l pe furnizor dacă a testat cu 11.3. Nu presupune.

2. Testează fluxul de rambursări pe un mediu de test. Dacă ai integrări care creează rambursări prin API, simulă un caz valid și unul invalid. Verifică ce cod primești și cum îl tratează sistemul tău. Un răspuns 422 tratat ca succes e o problemă de proces, nu de WooCommerce.

3. Profită de badge-ul de reducere cu procent. Pentru piața românească, „-25%” comunică mai rapid decât „Sale”. Testează varianta cu procent pe categoria principală și compară CTR-ul din listările de categorie, nu doar conversia. Ai nevoie de un eșantion suficient, nu de două zile de date.

4. Completează pagina de politică de retur în setări. Nu e opțional. Un magazin fără politică de retur vizibilă pierde încredere, iar datele structurate ajută la citare. Pentru un magazin românesc care vinde și în afara țării, contează dublu.

5. Nu rula Extensible abilities API în producție. E experimental, se schimbă, echipa o spune explicit. Testează pe staging.

6. Instalează WooCommerce Beta Tester 4.0.0 dacă vrei să testezi înainte. Necesită WordPress 6.8 sau mai nou și un mediu care nu e producție.

Un detaliu de nuanță pentru cine rulează campanii sezoniere: lansarea din noiembrie pică exact în fereastra de pregătire pentru Black Friday și Crăciun. Dacă magazinul tău depinde de acea perioadă, fă update-ul cu suficient timp înainte sau amână-l până după vârf. Nu face update de platformă în prima zi de campanie. Pentru cine construiește acum planuri de vânzări pe final de an, inclusiv pentru magazine fără stoc propriu, există o discuție aplicată în ghidul de dropshipping de Crăciun 2026.

FAQ

WooCommerce 11.3 e disponibilă oficial? Nu. La data anunțului, 26 octombrie 2026, exista doar versiunea beta pentru testare. Lansarea finală e programată în săptămâna 9 noiembrie 2026. Orice plan de producție se face după release-ul final, nu după beta.

Trebuie să rescriu integrările din cauza schimbării on_sale? Doar dacă faci cereri care combină on_sale cu include sau exclude. Folosirea separată a parametrilor e neschimbată. Dacă nu combini, nu ai ce modifica. Dacă combini, retestează și compară rezultatele înainte și după update.

Ce se întâmplă cu endpoint-ul MCP vechi? Este eliminat în 11.3. Accesul prin MCP se face cu plugin-ul WordPress MCP Adapter și o parolă de aplicație WordPress. Dacă ai integrare pe vechea cale, urmează pașii de migrare din documentația WooCommerce înainte de update.

Concluzia ALLSoft

AI-ul te ajută să citești mai repede un changelog de 1.310 commit-uri, să faci o listă de endpoint-uri afectate și să structurezi un plan de testare. Asta e muncă de analiză și planning, și e utilă. Dar decizia de a face update-ul, de a accepta riscul într-o săptămână de campanie și de a interpreta rezultatele după aceea rămâne la media buyer-ul și la omul care răspunde de magazin. Un AI nu îți spune dacă poți sacrifica trei zile de stabilitate în noiembrie.

Pasul concret: treci prin integrările care ating REST API, testează rambursările pe staging și pune pe listă badge-ul cu procent pentru test A/B după update. Dacă vrei să facem împreună auditul de integrări și planul de testare înainte de lansarea din noiembrie, ALLSoft Agency e locul de unde începem.