WooCommerce 10.5: schimbările care contează pentru dezvoltatori (import Analytics, taxe, UI Checkout, API și performanță)

WooCommerce 10.5 intră în linie dreaptă, iar pentru noi, cei care dezvoltăm extensii sau operăm magazine cu volum mare de comenzi, versiunea asta nu e una „de rutină”. Sunt câteva modificări care ating direct performanța (în special pe partea de Analytics), compatibilitatea (date de taxe legacy/corupte), dar și comportamentul UI (Checkout block, pagini de produs variabil) și zona de API.

Mai jos ai o trecere în revistă, cu accent pe ce impact poate avea în proiecte și ce merită testat în beta înainte de release.

Calendar de release (și cum testezi beta-urile)

• Feature Freeze: 12 ianuarie 2026
• WooCommerce 10.5 Beta 1: 19 ianuarie 2026
• WooCommerce 10.5 Beta 2: 26 ianuarie 2026
• Release final WooCommerce 10.5: programat pentru 4 februarie 2026

Pentru testare, echipa WooCommerce recomandă pluginul oficial WooCommerce Beta Tester, care îți permite să instalezi și să rulezi ușor versiunile beta într-un mediu de staging.

Ce aduce WooCommerce 10.5 (pe scurt, dar tehnic)

1) Schimbare fundamentală: importul datelor de comenzi în tabelele de Analytics

Cea mai importantă schimbare din 10.5 este felul în care WooCommerce importă (sau regenerează) datele de comenzi în tabelele folosite de Analytics. Până acum, la fiecare eveniment relevant de comandă, WooCommerce pornea un job de import prin ActionScheduler. Deși era asincron, pe magazine ocupate genera backlog-uri uriașe (10.000+ acțiuni), cu efecte concrete: degradare severă de performanță, contendență pe baza de date și încetiniri vizibile ale site-ului.

În 10.5, comportamentul implicit se schimbă: WooCommerce trece la Scheduled Imports (import programat), adică o regenerare în batch-uri, la intervale regulate.

• Frecvență implicită: la fiecare 12 ore
• Dimensiune batch implicită: 100 comenzi per batch
• Configurabil prin filtre noi: woocommerce_analytics_import_interval și woocommerce_analytics_regenerate_batch_size
• Beneficii: mult mai puține acțiuni programate, încărcare mai mică pe DB, plus vizibilitate mai clară a statusului importului și posibilitatea de a declanșa manual importuri oricând

Detalii tehnice în PR: #61603.

2) Checkout block: opțiuni de livrare mai clare în scenarii cu multiple pachete (mai ales subscriptions)

În Checkout block, UI-ul pentru opțiunile de livrare este îmbunătățit: când există multiple pachete (un scenariu întâlnit mai des la produse de tip subscription), opțiunile vor afișa thumbnail-uri de produs și containere cu bordură, ca să fie mai ușor de înțeles ce se livrează și cum.

În același pachet de schimbări se rezolvă și un bug: metodele de livrare nu se sincronizau corect când utilizatorul comuta între opțiunile de tip Ship și Pickup.

Referință: #61625.

3) Comenzi cu taxe legacy/corupte: handling mai robust (float/string vs array)

O altă zonă care a creat probleme în practică: comenzi vechi (sau alterate) unde valorile de taxă au fost salvate greșit, de exemplu ca float-uri sau string-uri, în loc de structuri de tip array. În 10.5 apare un fix care adaugă handling backwards-compatible pentru toate tipurile de order item (produse, shipping, fees).

În plus, logica încearcă să infereze inteligent tax rate IDs din contextul comenzii, iar pentru cazurile speciale există și un filtru dedicat pentru conversie custom.

• Acoperire: order item types pentru products, shipping și fees
• Inferență tax rate IDs pe baza contextului comenzii
• Filtru nou: woocommerce_order_item_legacy_tax_conversion (pentru logică de conversie personalizată)

Referință: #62271.

4) Select2 CSS: stilurile WooCommerce sunt „scoped” ca să nu afecteze interfețele altor pluginuri

WooCommerce încarcă stiluri pentru Select2 (biblioteca de UI pentru select-uri avansate), iar uneori CSS-ul „curgea” și în alte zone din admin, afectând interfețe din alte pluginuri. În 10.5, stilurile sunt acum scăpate în mod controlat folosind :where(.woocommerce).

Un detaliu important: pseudo-clasa :where() are specificitate zero, ceea ce înseamnă că override-urile custom existente ar trebui să continue să funcționeze, dar fără efectele secundare în afara contextului WooCommerce.

Referință: #61956.

5) Filtru nou pentru taxe la shipping: woocommerce_shipping_tax_class

WooCommerce introduce un filtru nou, woocommerce_shipping_tax_class, care permite calculul dinamic al taxelor pentru shipping în funcție de conținutul coșului, datele clientului și locație. Practic, îți dă un punct clar de extensie pentru scenarii fiscale mai complicate.

Un exemplu de logică posibilă menționată explicit: calcularea taxei de shipping folosind rata predominantă de taxă din coș, ceea ce poate fi necesar în anumite jurisdicții (de exemplu, în Olanda) unde regulile pot cere astfel de abordări.

Referință: #59512.

API Changes & advisories (lucruri de verificat în extensii)

Pe lângă funcționalități, 10.5 vine și cu schimbări de API/comportament documentate separat în developer advisories. Dacă ai integrări pe REST API sau folosești intern clase/trait-uri „interne”, merită să le parcurgi.

• WC REST API: handling corect pentru decodarea caracterelor speciale în atributele variațiilor de produs. Detalii: https://developer.woocommerce.com/2026/01/14/wc-rest-api-fixes-for-product-variation-attributes-with-special-characters-in-woocommerce-10-5/
• Se elimină trait-ul AccessiblePrivateMethods. Era în namespace-ul Internal (semnal clar că nu e destinat consumului public), dar poate afecta extensii care l-au folosit greșit. Detalii: https://developer.woocommerce.com/2026/01/15/removal-of-the-accessibleprivatemethods-trait-in-woocommerce-10-5/
• Schimbări la product permalinks bazate pe categorii: se prioritizează categoria cea mai „adâncă” (deepest category) pentru SEO și consistență în URL-uri; afectează doar anumite structuri de permalink. Detalii: https://developer.woocommerce.com/2026/01/13/product-permalink-changes-coming-in-woocommerce-10-5/
• Pe paginile de produse variabile, butonul Add to Cart este acum dezactivat până când scriptul de variații s-a încărcat complet. Motiv: pe conexiuni lente, utilizatorii puteau click-ui înainte de inițializarea logicii de selecție, ducând la submit eșuat. Detalii: https://developer.woocommerce.com/2026/01/16/add-to-cart-button-disabled-by-default-in-variable-products-in-woocommerce-10-5/

Îmbunătățiri de performanță în WooCommerce 10.5

REST API cache (experimental) pentru orice endpoint

10.5 introduce un REST API cache experimental care poate fi aplicat oricărui endpoint din WC REST API. În anunț, echipa precizează că vor veni detalii suplimentare despre cum se testează această funcționalitate înainte de release. Ideea e clară: reducerea timpilor de răspuns și a încărcării, mai ales când API-ul este lovit frecvent de integrări, dashboard-uri sau aplicații headless.

Îmbunătățiri pentru cached variation prices + utilitar pentru callbacks

Sistemul de caching pentru prețurile variațiilor primește optimizări suplimentare, împreună cu introducerea unei clase utilitare pentru lucrul cu callbacks (utile când ai multă logică înregistrată dinamic). Detalii: https://developer.woocommerce.com/2026/01/08/variation-prices-caching-improvements-in-woocommerce-10-5/

Product Object Caching (experimental): cache pe instanțe de produs în cadrul aceluiași request

Apare și o funcționalitate experimentală numită Product Object Caching: în loc să încarce același produs din DB de mai multe ori într-un singur request, WooCommerce poate păstra în cache instanțele de produs pe durata request-ului, evitând load-uri duplicate.

Referințe: PR https://github.com/woocommerce/woocommerce/pull/62041 și articol cu context: https://developer.woocommerce.com/2026/01/19/experimental-product-object-caching-in-woocommerce-10-5/

Fix pentru Product Filters: cache data setat/încărcat corect + cleanup transients

Dacă ai magazine cu cataloage mari și folosești Product Filters block, există o optimizare punctuală: în 10.5 se repară un caz în care cache data pentru filtre nu era setat și încărcat corect. Problema putea duce la „inundarea” bazei de date cu date de cache pentru filtre și, implicit, la degradarea performanței.

• Cache-ul pentru Product Filters este setat și încărcat corect, reducând presiunea pe DB
• Tool-ul de cleanup pentru WooCommerce transients a fost actualizat ca să șteargă și cache-ul de filter data când rulează
• Dacă există în continuare probleme de performanță cu Product Filters block, cauza poate fi cache-ul rămas, iar soluția indicată este rularea curățării de WooCommerce transients

Referință: #62575.

Changelog complet (pentru diff-uri fine)

Pentru lista completă de modificări, vezi changelog-ul din readme: https://github.com/woocommerce/woocommerce/blob/10.5.0-beta.1/plugins/woocommerce/readme.txt

Ce merită testat concret înainte de 10.5 (checklist pentru staging)

• Magazine cu volum mare de comenzi: verifică impactul noului Scheduled Imports asupra ActionScheduler (număr de acțiuni, timpi, load DB) și confirmă că Analytics se actualizează conform așteptărilor
• Checkout block cu subscriptions / multiple packages: verifică UI-ul (thumbnails + containere) și sincronizarea corectă când comuți Ship ↔ Pickup
• Comenzi istorice/importate: caută edge-case-uri cu taxe salvate ca float/string și testează dacă ai integrări care depind de structura veche; dacă e nevoie, folosește woocommerce_order_item_legacy_tax_conversion
• În admin, în ecrane unde folosești Select2 din alte pluginuri: verifică dacă scoping-ul :where(.woocommerce) elimină conflictele fără să-ți strice override-urile
• Logici fiscale custom: evaluează dacă woocommerce_shipping_tax_class îți simplifică implementarea (de exemplu, taxă de shipping calculată pe rata predominantă din coș)
• REST API consumers: verifică endpoint-urile pentru produse variabile/atribute cu caractere speciale; confirmă că decodarea e corectă
• Front-end pe produse variabile: confirmă comportamentul nou al butonului Add to Cart (dezactivat până se încarcă scriptul) și că nu ai JS custom care presupune alt flow
• Performanță: dacă folosești Product Filters block, rulează cleanup la transients și monitorizează DB; urmărește și funcțiile experimentale de caching (REST API cache, Product Object Caching) în funcție de compatibilitatea proiectului