WooCommerce 10.5: какво да очакват разработчиците (и какво да тестваме още сега)

WooCommerce 10.5 е „на хоризонта“ и този релийз е от онези, които си заслужава да се следят отблизо, ако поддържаш магазини с реален трафик или разработваш разширения. Освен видими UI подобрения, има и фундаментална промяна в начина, по който данните за поръчки се пренасят към Analytics таблиците – точно там, където много сайтове досега успяваха да се „самозадушат“ от ActionScheduler опашки.

По-долу съм събрал какво е обявено за 10.5, какво може да счупи extension-и/теми, и какво конкретно да тествате преди финалния релийз.

График на изданието (Release Schedule) и важни дати

• WooCommerce 10.5 Beta е налична за тестване.
• Feature Freeze е стартиран на 12 януари 2026.
• WooCommerce 10.5 Beta 1 е пусната на 19 януари 2026.
• WooCommerce 10.5 Beta 2 е пусната на 26 януари 2026.
• Финален релийз (планиран): 4 февруари 2026.

За тестване на beta версиите препоръката е стандартната: ползвай WooCommerce Beta Tester plugin, за да инсталираш и обновяваш beta билдове в контролирана среда.

Какво ново идва в WooCommerce 10.5 (фокус за разработчици)

1) Основна промяна: импортът на поръчки към Analytics таблиците

Най-сериозната промяна в 10.5 е как WooCommerce вкарва данните за поръчки в Analytics таблиците. Досега моделът беше: при всяко order събитие WooCommerce стартира analytics import job през ActionScheduler. Да, job-овете са асинхронни, но на натоварени магазини това водеше до огромни backlogs – говорим за 10 000+ actions – и оттам следваха познатите симптоми: сериозен performance спад, contention в базата и осезаемо забавяне на сайта.

В 10.5 по подразбиране се преминава към Scheduled Imports: batch processing, който рефрешва analytics данните на всеки 12 часа, като обработва 100 поръчки на batch. И двете стойности са конфигурируеми през нови filter-и:

• woocommerce_analytics_import_interval – за интервала на scheduled импорта.
• woocommerce_analytics_regenerate_batch_size – за размера на batch-а (по подразбиране 100 поръчки).

Ефектът е очаквано голям: значително по-малко scheduled actions и по-ниско натоварване на базата. От developer гледна точка е важно и друго – според описанието, собственикът на магазина получава ясна видимост за статуса и може да тригърва import ръчно, когато е необходимо. Референция: #61603.

2) Checkout block: по-добър UI за shipping опции (особено при multiple packages и subscriptions)

Checkout блокът получава подобрения в UI-то на shipping опциите: когато има multiple packages (сценарий, който често се среща при subscription продукти), интерфейсът вече показва product thumbnails и контейнери с бордери за по-ясна визуална диференциация.

Паралелно с това е фиксиран и бъг, при който shipping методите не се синхронизираха коректно при превключване между Ship и Pickup delivery опции. Референция: #61625.

3) По-надежден преглед на поръчки с legacy/повредени tax данни

Ако си виждал странни case-ове с поръчки, в които tax стойностите са били записани като float/string, вместо като arrays (което се води „коректната“ структура), 10.5 добавя по-надеждно и обратно-съвместимо обработване на такива данни.

Фиксът покрива всички типове order items – продукти, shipping, fees – и включва логика, която „интелигентно“ извежда tax rate ID-та от контекста на поръчката. За разширения, които имат специфични нужди при конверсията, има и filter за custom логика: woocommerce_order_item_legacy_tax_conversion. Референция: #62271.

4) Select2 CSS вече е scope-нат, за да не „протича“ към други плъгини

WooCommerce зарежда Select2 стилове, а в по-сложни админ интерфейси това понякога води до нежелани странични ефекти в UI на други плъгини. В 10.5 тези стилове вече са scope-нати през :where(.woocommerce).

Тук детайлът е важен: :where() псевдокласът е със zero specificity, което означава, че съществуващите custom override-и би трябвало да продължат да работят, но без WooCommerce да влияе извън своя контекст. Референция: #61956.

5) Нов filter: woocommerce_shipping_tax_class за динамична tax логика при доставка

В 10.5 се въвежда нов filter woocommerce_shipping_tax_class, който позволява динамично изчисляване на shipping tax rate според съдържанието на количката, данните за клиента и локацията.

Идеята е да можеш да имплементираш custom правила – например да калкулираш данъка за доставка по „преобладаващата“ данъчна ставка в количката. Това е полезно за по-сложни tax сценарии, включително изисквания като тези в Нидерландия. Референция: #59512.

API промени и важни developer advisories

Освен функционалните промени, 10.5 идва и с няколко теми, за които има отделни developer advisories. Ако поддържаш extension-и, тези точки са задължителни за преглед, защото засягат публично поведение или премахване на вътрешни компоненти:

• WC REST API вече ще обработва коректно decode-ването на специални символи при product variation attributes. Детайли: https://developer.woocommerce.com/2026/01/14/wc-rest-api-fixes-for-product-variation-attributes-with-special-characters-in-woocommerce-10-5/
• AccessiblePrivateMethods trait ще бъде премахнат. Той е бил в Internal namespace и е трябвало да е сигнал, че не е за публична употреба. Това може да засегне разширения, които неправилно са го използвали. Детайли: https://developer.woocommerce.com/2026/01/15/removal-of-the-accessibleprivatemethods-trait-in-woocommerce-10-5/
• Product permalinks базирани на категории се променят: ще се приоритизира най-дълбоката категория за по-добро SEO и консистентност на URL-ите. Промяната засяга конкретни permalink структури. Детайли: https://developer.woocommerce.com/2026/01/13/product-permalink-changes-coming-in-woocommerce-10-5/
• При variable product страници WooCommerce гарантира, че Add to Cart бутонът е disabled, докато variation скриптът не се зареди напълно. Това предотвратява кликове преди инициализацията (особено при бавни връзки), които досега можеха да доведат до failed submissions. Детайли: https://developer.woocommerce.com/2026/01/16/add-to-cart-button-disabled-by-default-in-variable-products-in-woocommerce-10-5/

Performance: какво е новото в 10.5

Експериментален REST API cache (за всеки endpoint)

WooCommerce 10.5 ще въведе нов експериментален REST API cache, който може да се приложи към всеки endpoint в WC REST API. По обявлението се очакват повече подробности за това как да се тества функцията преди финалния релийз.

Подобрения в cached variation prices + utility клас за callbacks

Има допълнителни подобрения около cached variation prices, както и нов utility class за работа с callbacks. Детайли: https://developer.woocommerce.com/2026/01/08/variation-prices-caching-improvements-in-woocommerce-10-5/

Експериментален Product Object Caching (в рамките на request)

В 10.5 влиза и експериментален Product Object Caching механизъм: вместо да се „дърпа“ един и същ продукт многократно от базата в рамките на един request, WooCommerce кешира product instance-и, за да предотврати дублиращи се зареждания. Референция към PR: https://github.com/woocommerce/woocommerce/pull/62041 и допълнителни детайли: https://developer.woocommerce.com/2026/01/19/experimental-product-object-caching-in-woocommerce-10-5/

Фикс за Product Filters cache data + промяна в transients cleanup

Отбелязан е и performance проблем при Product Filters, свързан с cache data, който не е бил правилно set-ван и зареждан. Това може да доведе до ситуация, в която базата се „залива“ с filter data cache и магазините с големи каталози да усетят спад в производителността.

В 10.5 това е поправено, а инструментът за чистене на WooCommerce transients е обновен така, че да чисти и filter data cache, когато се изпълнява. Има и практическа бележка: ако клиент използва Product Filters block и продължава да вижда performance проблеми, това може да е причината, а решението – да се почистят WooCommerce transients. Референция: #62575.

Changelog

Пълният changelog за 10.5 (beta) е наличен тук: https://github.com/woocommerce/woocommerce/blob/10.5.0-beta.1/plugins/woocommerce/readme.txt

Практичен checklist: какво да покриеш при тестване на 10.5

• Ако имаш магазини с висок обем поръчки: провери как се държи новият Scheduled Imports модел за Analytics (натоварване на ActionScheduler, общо DB натоварване, видимост и ръчни тригъри).
• Ако extension-ът ти работи с данъци на ниво order items: тествай поръчки с legacy/нестандартни tax стойности и, ако е нужно, закачи custom логика през woocommerce_order_item_legacy_tax_conversion.
• Прегледай админ UI, където имаш Select2: увери се, че стиловете са коректни и че няма нежелани зависимости от старото „протичане“ на CSS извън WooCommerce контекста.
• Ако правиш custom shipping tax логика: огледай новия woocommerce_shipping_tax_class filter и тествай сценарии по държави/зони и различни комбинации продукти в количката.
• Ако интегрираш WC REST API за вариации: тествай атрибути със специални символи (encode/decode).
• Провери дали не използваш AccessiblePrivateMethods trait (директно или индиректно) – премахването му ще удари неправилна публична употреба.
• Ако разчиташ на category-based product permalinks: провери дали URL структурата ти попада сред засегнатите и как ще се избира „най-дълбока“ категория.
• На variable product страници: увери се, че фронтенд UX не страда от disabled Add to Cart до зареждане на variation скрипта (особено ако имаш custom JS около вариации).
• Ако имаш големи каталози и използваш Product Filters block: следи filter cache поведението и при нужда тествай ефекта от почистване на WooCommerce transients.