WooCommerce 10.5 kūrėjams: suplanuoti Analytics importai, mokesčių/URL pakeitimai ir nauji eksperimentiniai kešai

WooCommerce 10.5 leidimas jau „ant nosies“, o kūrėjams ši versija įdomi ne tik dėl naujų smulkių patobulinimų, bet ir dėl gana esminio pokyčio Analytics duomenų importavimo mechanikoje. Jei prižiūri didesnę parduotuvę (ar klientų kelias parduotuves), šis pakeitimas gali tiesiogiai sumažinti ActionScheduler eilę, DB konkurenciją ir bendrą „užsikimšimo“ riziką.

Žemiau – svarbiausi 10.5 akcentai iš kūrėjo perspektyvos: kas pasikeitė, kokie filtrai atsirado, ko pasisaugoti atnaujinant, ir ką verta pasitikrinti beta fazėje.

Leidimo grafikas (Release Schedule) ir testavimas

• WooCommerce 10.5 Beta versija jau prieinama testavimui.
• Final Release suplanuotas 2026 m. vasario 4 d.
• Feature Freeze startavo 2026 m. sausio 12 d.
• WooCommerce 10.5 Beta 1 išleista 2026 m. sausio 19 d.
• WooCommerce 10.5 Beta 2 išleista 2026 m. sausio 26 d.

Testavimui siūlomas oficialus įrankis – WooCommerce Beta Tester plugin. Jis leidžia patogiai įsidiegti beta leidimus atskiroje aplinkoje (staging) ir pasitikrinti suderinamumą su tema bei plėtiniais.

Kas ateina su WooCommerce 10.5: svarbiausi pokyčiai

1) Iš esmės perrašyta užsakymų importo į Analytics lenteles logika

Didžiausias 10.5 pokytis – kaip WooCommerce importuoja užsakymų duomenis į Analytics lenteles. Iki šiol modelis buvo paprastas: kiekvienas order event (įvykis užsakyme) iššaukdavo atskirą Analytics importo užduotį per ActionScheduler. Nors tai buvo asinchoninė (async) schema, judriose parduotuvėse ji sukurdavo milžiniškas ActionScheduler eiles (pranešime minimas 10 000+ actions mastas). Pasekmės – ryškus našumo kritimas, DB lock/contension situacijos ir realūs svetainės sulėtėjimai.

WooCommerce 10.5 numatytasis elgesys keičiamas į Scheduled Imports: Analytics duomenys atnaujinami paketais, pagal grafiką, o ne „po kiekvieno įvykio“.

• Importas vykdomas kas 12 valandų (numatytasis intervalas).
• Viename pakete apdorojama 100 užsakymų (numatytasis dydis).
• Abi reikšmės gali būti keičiamos per naujus filtrus: woocommerce_analytics_import_interval ir woocommerce_analytics_regenerate_batch_size.
• Ženkliai sumažėja suplanuotų ActionScheduler veiksmų skaičius ir DB apkrova.
• Parduotuvės savininkams pateikiamas aiškesnis importo statuso matomumas ir galimybė bet kada rankiniu būdu paleisti importą.

Techninis kontekstas ir PR nuoroda: #61603.

2) Checkout bloko siuntimo pasirinkimai: geresnis UI (thumbnail’ai, paketų rėmeliai) ir sinchronizavimo bugfix

Checkout blokas (Block-based Checkout) gauna UI patobulinimą siuntimo pasirinkimų dalyje: kai yra keli siuntų paketai (ypač dažna prenumeratų/subscription produktų situacijose), interfeise rodomi produktų thumbnail’ai ir vizualiai atskirti (bordered) konteineriai kiekvienam paketui.

Kartu sutvarkyta klaida, kai perjungiant pristatymo režimus tarp „Ship“ ir „Pickup“ siuntimo metodai ne visada korektiškai susisinchronizuodavo. PR: #61625.

3) Patikimesnis užsakymų peržiūrėjimas su legacy/sugadintais mokesčių (tax) duomenimis

10.5 stiprina suderinamumą su senais arba „pakrikusiais“ užsakymų mokesčių duomenimis, kai tax reikšmės buvo išsaugotos netinkamu formatu – kaip float/string, o ne kaip masyvai (arrays). Tokie duomenys realiai pasitaiko migracijose, senų plėtinių palikime ar nestandartinėse integracijose.

• Pridėtas backwards-compatible apdorojimas per visus order item tipus: produktus, siuntimą ir mokesčius (fees).
• Sistema bando „protingai“ nustatyti (infer) tax rate ID iš užsakymo konteksto.
• Įvestas filtras woocommerce_order_item_legacy_tax_conversion, leidžiantis įdėti savo konvertavimo logiką, jei turi specifinį duomenų formatą.

PR: #62271.

4) Select2 stiliai: su-scoping per :where(.woocommerce) kad „neištekėtų“ į kitus pluginus

Jei esi susidūręs, kad WooCommerce administraciniai Select2 stiliai (Select2 – populiarus select komponentas) netyčia paveikia kitų plėtinių UI, 10.5 turi labai sveiką pataisą: Select2 stiliai dabar scope’inami per :where(.woocommerce).

Svarbi detalė: :where() pseudo-klasė turi nulį specifiškumo, todėl esami custom override’ai neturėtų „užlūžti“ vien dėl specifiškumo kovų, bet tuo pačiu sumažėja rizika, kad WooCommerce CSS paveiks kitų plėtinių ekranus. PR: #61956.

5) Naujas filtras woocommerce_shipping_tax_class: dinaminė siuntimo PVM (tax) klasė pagal krepšelį/klientą/lokaciją

WooCommerce 10.5 įveda naują filtrą woocommerce_shipping_tax_class, kuris leidžia dinamiškai apskaičiuoti siuntimo mokesčių (shipping tax) tarifą pagal krepšelio turinį, kliento duomenis ir vietą. Tai aktualu, kai standartinė schema „viena siuntimo tax klasė visiems“ netinka.

Pranešime pateikiamas pavyzdinis scenarijus: siuntimo mokestį skaičiuoti pagal dominuojantį (predominant) tax tarifą krepšelyje – tai gali būti reikalinga sudėtingesniuose mokesčių režimuose, pavyzdžiui, Nyderlanduose. PR nuorodoje ši funkcija siejama su #59512 (kaip nurodyta pranešime).

API pakeitimai ir įspėjimai (API Changes and Advisories)

WooCommerce 10.5 turi ir kelis pokyčius, kurie gali nepastebimai paveikti integracijas ar plėtinius. Oficialiai jie išsamiau aprašyti atskiruose developer blog įrašuose – čia sutraukiu esmę, bet realiai verta atsiversti pilnus advisories, jei tavo sprendimas remiasi šiomis vietomis.

WC REST API: korektiškas specialių simbolių dekodavimas variation atributuose

WC REST API dabar turėtų teisingai apdoroti specialių simbolių dekodavimą product variation atributuose. Jei turi integracijas, kurios kuria/atnaujina variacijas per REST, arba filtruoja pagal atributus, šis pakeitimas gali pakeisti kraštinių atvejų elgesį. Pilna informacija: https://developer.woocommerce.com/2026/01/14/wc-rest-api-fixes-for-product-variation-attributes-with-special-characters-in-woocommerce-10-5/ .

Pašalinamas AccessiblePrivateMethods trait iš Internal namespace

AccessiblePrivateMethods trait bus pašalintas. Jis buvo Internal namespace dalis – tai buvo aiškus signalas, kad viešam naudojimui jis neskirtas. Visgi dalis plėtinių galėjo neteisingai nuo jo priklausyti. Jei tavo kode yra importai/nuorodos į šį trait, 10.5 atnaujinimas gali sulaužyti suderinamumą. Detalės: https://developer.woocommerce.com/2026/01/15/removal-of-the-accessibleprivatemethods-trait-in-woocommerce-10-5/ .

Product permalink’ai pagal kategorijas: prioritetas giliausiai kategorijai

Keičiasi product permalink generavimas struktūrose, kurios remiasi kategorijomis: dabar bus prioritetizuojama giliausia (deepest) kategorija – tikslas geresnis SEO ir nuoseklesni URL. Pakeitimas galioja tik tam tikroms permalink struktūroms (ne visoms). Išsamus aprašymas: https://developer.woocommerce.com/2026/01/13/product-permalink-changes-coming-in-woocommerce-10-5/ .

Variable product puslapiuose: „Add to Cart“ išjungtas, kol pilnai užsikrauna variation skriptas

10.5 užtikrina, kad variable product puslapiuose mygtukas Add to Cart būtų disabled, kol variation skriptas pilnai užsikrauna. Anksčiau lėtesnio ryšio atveju vartotojas galėjo spustelėti per anksti, dar iki inicializuojant variacijų pasirinkimo logiką – tai baigdavosi nesėkmingais submit’ais. Plačiau: https://developer.woocommerce.com/2026/01/16/add-to-cart-button-disabled-by-default-in-variable-products-in-woocommerce-10-5/ .

Našumo patobulinimai (Performance Improvements)

Eksperimentinis REST API kešas: galima taikyti bet kuriam endpoint’ui

WooCommerce 10.5 įneša naują eksperimentinį REST API cache, kurį galima pritaikyti bet kuriam WC REST API endpoint’ui. Kol kas pažadėta, kad prieš 10.5 finalą bus daugiau informacijos, įskaitant testavimo instrukcijas. Jei kuri headless ar turi intensyvių integracijų, šią funkciją tikrai verta sekti.

Variation prices caching: patobulinimai ir nauja utility klasė callback’ams

Keletas patobulinimų pasiekė cached variation prices mechaniką, kartu atsirado nauja utility klasė darbui su callback’ais. Detalės: https://developer.woocommerce.com/2026/01/08/variation-prices-caching-improvements-in-woocommerce-10-5/ .

Eksperimentinis Product Object Caching: produktų instancijų kešas vienos užklausos (request) metu

Dar viena eksperimentinė naujovė – Product Object Caching. Idėja paprasta: vieno request metu kešuojamos produktų instancijos, kad būtų išvengta pakartotinių tų pačių produktų užkrovimų iš DB. Tai ypač aktualu sudėtinguose šablonuose ar blokuose, kur produktas gali būti „paprašomas“ kelis kartus skirtinguose sluoksniuose. PR: https://github.com/woocommerce/woocommerce/pull/62041 ir papildomas paaiškinimas: https://developer.woocommerce.com/2026/01/19/experimental-product-object-caching-in-woocommerce-10-5/ .

Product Filters: sutvarkyti cache duomenų set/load nesklandumai ir transients valymas

10.5 sprendžia našumo problemą, susijusią su Product Filters cache duomenimis, kurie ne visada buvo teisingai nustatomi ir užkraunami. Pasekmė galėjo būti nemaloni: DB „užpilama“ filtrų cache įrašais, o didelių katalogų parduotuvėse tai atsiliepdavo greičiui.

• Sutvarkyta cache data set/load logika, kad DB nebūtų užversta filtrų cache duomenimis.
• Atnaujintas WooCommerce transients cleanup įrankis: jam vykdant valymą dabar išvalomas ir filter data cache.
• Jei klientai naudoja Product Filters bloką ir vis dar jaučia našumo bėdas, viena iš tikėtinų priežasčių – būtent šie cache duomenys; praktinis sprendimas – išvalyti WooCommerce transients.

PR: #62575.

Changelog

Pilnas 10.5 pakeitimų sąrašas (beta šakai) pateiktas čia: https://github.com/woocommerce/woocommerce/blob/10.5.0-beta.1/plugins/woocommerce/readme.txt .

Ką kūrėjui verta pasitikrinti prieš atnaujinant į 10.5

1. Jei turi didelės apimties parduotuves, staging aplinkoje stebėk ActionScheduler eilės dinamiką po perėjimo prie Scheduled Imports ir įvertink, ar nereikia koreguoti woocommerce_analytics_import_interval ar woocommerce_analytics_regenerate_batch_size.
2. Jei tavo plėtinys ar tema naudoja Checkout bloką su subscription produktais ar kelių siuntų paketais, peržiūrėk, ar UI pasikeitimai nedaro įtakos custom CSS/JS.
3. Jei esi turėjęs nestandartinius tax duomenų formatus order item’ų lygyje, įvertink woocommerce_order_item_legacy_tax_conversion filtro poreikį.
4. Admin UI srityse, kur naudotas Select2, pažiūrėk ar pasikeitęs scoping nepaveikė tavo override’ų (turėtų būti saugu dėl :where() nulinio specifiškumo, bet geriau patikrinti realiai).
5. Jei siuntimo mokesčių logika priklauso nuo krepšelio sudėties, įvertink, ar woocommerce_shipping_tax_class filtras gali supaprastinti (ar pagerinti) tavo sprendimą.
6. REST API integracijose su variacijų atributais pasitikrink specialių simbolių atvejus.
7. Kodo bazėje susirask bet kokį AccessiblePrivateMethods naudojimą – 10.5 jį pašalina.
8. Jei SEO strategijoje svarbūs product URL’ai pagal kategorijas, peržiūrėk permalinks pokyčius ir jų poveikį tikslinėms struktūroms.
9. Frontende variable product puslapiuose patikrink UX, jei turėjai custom „Add to Cart“ elgseną ar JS, kuris tikisi, kad mygtukas visada aktyvus iškart užsikrovus HTML.
10. Jei naudoji Product Filters bloką dideliuose kataloguose, po atnaujinimo stebėk DB ir, jei reikia, vykdyk transients valymą.