WooCommerce 10.5: fejlesztői előzetes – scheduled analytics import, új filterek, API- és teljesítményfrissítések

A WooCommerce 10.5 kiadása a bejelentés szerint közel van, és fejlesztői szemmel kifejezetten izgalmas, mert nem csak UI- és kompatibilitási javítások jönnek, hanem egy régóta fájó teljesítményproblémához is hozzányúlnak: ahhoz, ahogyan a rendelések adatai az Analytics táblákba bekerülnek.

Ebben az összefoglalóban végigmegyek azon, mi érkezik 10.5-ben, mire érdemes figyelni bővítmény- és egyedi fejlesztésekben (filterek, API-változások, stílus-scope), és mit érdemes már most letesztelni béta alatt.

Kiadási menetrend (amit a fejlesztői csapat kommunikált)

• WooCommerce 10.5 Beta elérhető tesztelésre.
• Végleges kiadás: 2026. február 4. (ütemezett dátum a bejelentés szerint).
• Feature Freeze kezdete: 2026. január 12.
• WooCommerce 10.5 Beta 1: 2026. január 19.
• WooCommerce 10.5 Beta 2: 2026. január 26.

Mi a legnagyobb változás 10.5-ben? Az Analytics import teljes újragondolása

A 10.5 egyik legfontosabb fejlesztése egy alapvető változás abban, ahogyan a WooCommerce a rendelésadatokat importálja az Analytics táblákba. Korábban a WooCommerce minden rendelés-eseménynél külön analytics import feladatot indított ActionSchedulerrel (aszinkron módon). Ez papíron jól hangzik, gyakorlatban viszont nagy forgalmú boltoknál brutális ActionScheduler-torlódást okozott: simán összejött 10 000+ ütemezett action, ami komoly teljesítményromlást, adatbázis-kontenciót és érezhető belassulást eredményezett.

A 10.5-ben a WooCommerce alapértelmezetten áttér a Scheduled Imports működésre. Ennek a lényege, hogy nem minden eseménynél külön action fut, hanem az Analytics adatok frissítése batch feldolgozással, ütemezetten történik.

• Alapértelmezett frissítési gyakoriság: 12 óránként.
• Batch méret: 100 rendelés / batch.
• Mindkét érték testre szabható új filterekkel: woocommerce_analytics_import_interval és woocommerce_analytics_regenerate_batch_size.
• Jelentősen csökken az ütemezett actionök száma és az adatbázis-terhelés.
• A bolttulajdonosok egyértelműbb státusz-visszajelzést kapnak, és bármikor kézzel is el tudják indítani az importot.

Fejlesztői oldalról ez tipikusan az a változás, amit érdemes staging környezetben nagyobb rendelésmennyiséggel is megizzasztani, főleg ha van olyan integrációd, ami az Analytics táblák frissülésére vagy időzítésére épít. A kapcsolódó munka a WooCommerce GitHubon a #61603 PR-ben követhető.

Checkout block: shipping opciók UI-ja több csomag esetén + szinkron hiba javítása

A Checkout blokkban (blokkalapú pénztár/checkout) finomítottak a szállítási opciók megjelenésén. Ha több csomag (multiple packages) van jelen – ami például előfizetéses (subscription) termékeknél is gyakori –, akkor a szállítási opciók UI-ja mostantól:

• termék-bélyegképeket (thumbnail) is mutat,
• és keretes (bordered) konténerekkel különíti el a csomagokat, hogy átláthatóbb legyen a választás.

Emellett javítottak egy kellemetlen hibát is: korábban előfordult, hogy a szállítási módok nem szinkronizálódtak megfelelően, amikor a vásárló a „Ship” (kiszállítás) és „Pickup” (átvétel) opciók között váltogatott. A részletek a #61625 PR-ben vannak.

Stabilabb rendelésmegjelenítés legacy vagy sérült adó (tax) adatokkal

A 10.5 egyik „csendes” frissítése, ami valójában sok boltban életmentő: megbízhatóbbá teszi a rendelések megnyitását akkor is, ha a régi vagy sérült adatok miatt az adó (tax) értékek nem a várt struktúrában vannak eltárolva.

A konkrét probléma: bizonyos rendelésekben a tax értékek tömb (array) helyett floatként vagy stringként voltak elmentve. Ez aztán admin oldali megtekintésnél vagy feldolgozásnál hibákat, figyelmeztetéseket, szélsőséges esetben teljes oldalszintű problémákat okozhatott.

A javítás lényege, hogy a WooCommerce visszafelé kompatibilis módon kezeli ezeket az eseteket minden order item típusnál, beleértve:

• termék tételek (products),
• szállítás (shipping),
• díjak/fees.

A logika a rendelés kontextusából „okosan” próbálja kikövetkeztetni a tax rate ID-ket is, és kapunk egy új filtert, amivel saját konverziós logikát adhatsz meg: woocommerce_order_item_legacy_tax_conversion. A részletek: #62271.

Select2 CSS: végre nem „folyik át” más bővítmények felületére

Ha dolgoztál már WooCommerce-admin felületekkel vagy olyan bővítménnyel, ami Select2-t használ, ismerős lehet a jelenség: a WooCommerce által betöltött Select2 stílusok néha akaratlanul más bővítmények UI-jára is hatással voltak.

10.5-ben ezt úgy oldják meg, hogy a WooCommerce Select2 stílusai scope-olva lesznek a :where(.woocommerce) segítségével. A :where() pszeudo-osztály egyik nagy előnye, hogy nulla specifikusságot (zero specificity) ad, tehát az eddigi egyedi felülírások jó eséllyel továbbra is működni fognak, miközben megszűnik a „CSS-szivárgás” más pluginok felé. Kapcsolódó PR: #61956.

Új adózási filter: woocommerce_shipping_tax_class (dinamikus szállítási áfa/adó)

Adózásos projektekben (főleg több kulcsos, összetett szabályrendszereknél) rendszeresen előjön, hogy a szállítás adókulcsát nem lehet egyszerűen egy fix tax class-hoz kötni. A 10.5-ben ezért érkezik egy új filter: woocommerce_shipping_tax_class.

Ezzel dinamikusan számolhatod a szállítási adókulcsot például:

• a kosár tartalma alapján,
• a vevő adatai alapján,
• a lokáció (ország/régió/irányítószám) alapján.

A bejelentés konkrét példát is említ: megvalósítható vele olyan logika, ahol a szállítás adóját a kosárban szereplő tételek domináns (predominant) adókulcsa határozza meg. Ez különösen hasznos lehet olyan összetettebb adózási helyzetekben, mint amilyenek Hollandiában is előfordulnak. Kapcsolódó munka: #59512 (a bejegyzésben így hivatkozva).

API-változások és fejlesztői figyelmeztetések (advisories)

A 10.5 több olyan változást is hoz, ami nem feltétlenül látványos, de bővítményeknél és egyedi integrációknál nagyon gyorsan hibákba tud futni, ha nem számolsz vele. A WooCommerce csapat ezekhez külön fejlesztői bejegyzéseket (advisory) is írt; itt a lényeg röviden, a részletekhez pedig ott vannak a hivatalos linkek.

WC REST API: speciális karakterek helyes dekódolása variation attribútumoknál

A WC REST API mostantól korrektül kezeli a speciális karakterek dekódolását a termékvariációk (product variation) attribútumainál. Ha olyan integrációd van, ami variáció-atribútumokat olvas/ír (különösen nem ASCII, ékezetes, vagy URL-encoded értékekkel), ezt érdemes külön tesztelni. Részletes leírás: https://developer.woocommerce.com/2026/01/14/wc-rest-api-fixes-for-product-variation-attributes-with-special-characters-in-woocommerce-10-5/.

Az AccessiblePrivateMethods trait kivezetése

A 10.5-ben eltávolítják az AccessiblePrivateMethods traitet. Fontos kontextus, hogy ez az Internal namespace része volt, ami egyértelmű jelzés arra, hogy nem publikus felhasználásra szánt API. Ennek ellenére előfordulhat, hogy egyes kiegészítők hibásan mégis erre támaszkodtak – náluk ez törést okozhat. Részletek: https://developer.woocommerce.com/2026/01/15/removal-of-the-accessibleprivatemethods-trait-in-woocommerce-10-5/.

Termékpermalinkek: kategória-alapú URL-eknél változik a prioritás

A termékpermalinkeknél, ha kategória-alapú struktúrát használsz, a WooCommerce módosítja a kategória kiválasztásának logikáját: a tervek szerint a legmélyebb kategóriát (deepest category) priorizálja, ami SEO és URL-konzisztencia szempontból általában kedvezőbb. A változás csak bizonyos permalink struktúrákat érint. Részletek: https://developer.woocommerce.com/2026/01/13/product-permalink-changes-coming-in-woocommerce-10-5/.

Variable product: Add to Cart alapból disabled, amíg be nem tölt a variációs script

Variable product oldalon mostantól a Kosárba (Add to Cart) gomb alapértelmezetten letiltott, amíg a variációkezelő JavaScript teljesen be nem tölt. Korábban lassú hálózaton előfordulhatott, hogy a felhasználó rákattintott az Add to Cart-ra, mielőtt a variációválasztási logika inicializált volna, és ez sikertelen beküldéshez vezetett. Részletek: https://developer.woocommerce.com/2026/01/16/add-to-cart-button-disabled-by-default-in-variable-products-in-woocommerce-10-5/.

Teljesítmény: kísérleti REST API cache, jobb variációár-cache, kísérleti Product Object Caching

A 10.5-ben több teljesítményfókuszú fejlesztés is érkezik, és ezek közül több kísérleti (experimental) jellegű. Ez fejlesztőként azt jelenti, hogy érdemes tudatosan tesztelni, de óvatosan élesíteni – főleg, ha egyedi cache-rétegeid, REST API fogyasztóid, vagy nagy katalógusos boltod van.

Kísérleti REST API cache bármely WC REST API endpointhoz

A WooCommerce 10.5 egy új, kísérleti REST API cache-t vezet be, amit elvileg a WC REST API bármely endpointjára rá lehet húzni. A bejelentés szerint a kiadás előtt még jön részletesebb információ arról, hogyan lehet tesztelni. Addig is érdemes fejben tartani: ha REST API-n keresztül nagy a forgalmad (headless, külső ERP, mobil app, feedek), ez hosszabb távon jelentős terheléscsökkentést adhat.

Variációárak cache-e: finomítások + új utility class callbackekhez

A variációárak (cached variation prices) gyorsítótárazása is kapott fejlesztéseket, és érkezik egy új segédosztály (utility class) a callbackekkel való munkához. Részletek: https://developer.woocommerce.com/2026/01/08/variation-prices-caching-improvements-in-woocommerce-10-5/.

Kísérleti Product Object Caching: termék példányok cache-elése requesten belül

Szintén 10.5-ös újdonság az experimental Product Object Caching. A célja, hogy egyetlen kérés (request) alatt a WooCommerce cache-elje a termékobjektum példányokat, és ezzel elkerülje a duplikált termékbetöltéseket adatbázisból. Ez tipikusan olyan optimalizáció, ami sokszor „ingyen” hoz gyorsulást nagyobb oldalakon, ahol ugyanaz a termék több helyen is előkerül egy render során. A kapcsolódó PR: https://github.com/woocommerce/woocommerce/pull/62041, a részletes fejlesztői leírás pedig: https://developer.woocommerce.com/2026/01/19/experimental-product-object-caching-in-woocommerce-10-5/.

Product Filters: cache adatkezelés javítása + transients cleanup frissítés

Javítanak egy teljesítményproblémát a Product Filters (termékszűrők) cache adatainál is: korábban bizonyos esetekben nem megfelelően álltak be és töltődtek be ezek az adatok, ami azt eredményezhette, hogy az adatbázist elárasztotta a filter cache. Nagy katalógusoknál ez kifejezetten fájdalmas tud lenni.

A 10.5-ben ezeket rendbe teszik, és frissítik a WooCommerce transients cleanup eszközt is, hogy futáskor a filter adat cache-t is törölje. A bejelentés külön kiemeli: ha a vásárlók a Product Filters blokkot használják, és továbbra is teljesítménygondokat tapasztalsz, akkor ez lehet az ok, és a megoldás a WooCommerce transients kitakarítása lehet. Kapcsolódó PR: #62575.

Changelog és követés

A teljes változáslista (changelog) elérhető itt: https://github.com/woocommerce/woocommerce/blob/10.5.0-beta.1/plugins/woocommerce/readme.txt.

Gyakorlati teszt-checklist fejlesztőknek (mire nézz rá béta alatt)

• Nagy forgalmú / sok rendeléses stagingen nézd meg, hogyan viselkedik az új Scheduled Imports: ActionScheduler queue mérete, DB-terhelés, Analytics adatok frissülési ideje.
• Ha egyedi kódod az Analytics import ütemezéséhez kapcsolódik, teszteld a két új filtert: woocommerce_analytics_import_interval és woocommerce_analytics_regenerate_batch_size.
• Blokkos pénztárnál teszteld a több csomagos szállítási opciók UI-ját (különösen subscription termékekkel), illetve a Ship/Pickup váltás szinkront.
• Rendelés-admin oldalon próbálj megnyitni olyan régi rendeléseket is, ahol gyanús/legacy tax adatok lehetnek; ha van saját adó-konverziód, nézd meg a woocommerce_order_item_legacy_tax_conversion filtert.
• Nézd át, hogy bármely kiegészítőd nem használja-e az Internal namespace elemeit, különösen az AccessiblePrivateMethods traitet.
• Ha kategória-alapú termék URL-struktúrát használsz, ellenőrizd a termékpermalinkek változását és az esetleges SEO/redirect igényeket a dokumentált érintett struktúrákban.
• Ha REST API-val kezelsz variáció attribútumokat, ellenőrizd a speciális karakterek kezelését.
• Variable product oldalakon validáld, hogy a saját JS/UI kódod együtt él a „gomb disabled, amíg nem töltött be a variációs script” változással.
• Nagy katalógusnál Product Filters blokk használata esetén figyeld a transients és filter cache hatását; szükség esetén futtasd a transients tisztítást.