WooCommerce Subscriptions 9.2: что изменилось для магазинов и разработчиков

WooCommerce Subscriptions 9.2.0 вышел с изменениями, которые затрагивают не только интерфейс настроек, но и поведение подписок, кастомные интеграции и код расширений. Особенно внимательно обновление стоит проверить магазинам с физическими товарами по подписке, ручными продлениями, gifting и собственными страницами выбора плана.

Официальный WooCommerce Developer Blog опубликовал advisory 8 сентября 2026 года. Ниже — не перевод заметки, а практический разбор того, что изменилось и где после обновления могут проявиться несовместимости.

Главное изменение: prorating теперь доступен для физических товаров

Раньше настройки перерасчёта при смене подписки были ориентированы прежде всего на виртуальные продукты. В WooCommerce Subscriptions 9.2.0 правила Prorate Recurring Payment и Prorate Subscription Length можно применять и к физическим товарам.

Для разработчиков это сопровождается новыми значениями настроек. Фильтр woocommerce_subscriptions_apportion_recurring_price теперь принимает physical-upgrade и physical, а woocommerce_subscriptions_apportion_length — значение physical.

Логика соответствует уже существующим вариантам для виртуальных товаров: вариант с -upgrade применяется только при переходе вверх, а обычный physical — при изменениях в обе стороны. При этом значения по умолчанию не меняются, а сигнатуры фильтров wcs_switch_should_prorate_recurring_price и wcs_switch_should_prorate_length сохранены.

Что важно учесть при откате на 9.1.0

WooCommerce отдельно предупреждает о сценарии rollback. Старые версии Subscriptions не знают новых значений physical и physical-upgrade. Фатальной ошибки или потери данных из-за этого не происходит, но prorating фактически возвращается в состояние off.

Есть и менее очевидный нюанс. На экране настроек 9.1.0 для сохранённого нового значения не будет подходящего пункта в выпадающем списке. Если администратор сохранит этот раздел настроек, не выбрав другое значение, новое значение может быть перезаписано на no.

Поэтому после отката недостаточно проверить, что сайт просто открывается. Нужно заново пройти настройки switching/prorating и убедиться, что бизнес-логика подписок осталась ожидаемой.

Ручные продления теперь строже зависят от родительской настройки

В предыдущем поведении опция отключения автоматических платежей могла перевести подписку в режим manual renewal даже тогда, когда основная настройка Accept Manual Renewals была выключена.

В 9.2.0 метод WCS_Manual_Renewal_Manager::is_manual_renewal_required() требует, чтобы обе настройки были включены. Для магазина это делает поведение более последовательным, но кастомный код, который рассчитывал на прежнюю комбинацию флагов, стоит протестировать.

Также WooCommerce разделил nonce для операций удаления и resubscribe. Раньше ссылки могли использовать общий nonce, завязанный на ID подписки; теперь каждая операция получает собственный. Старые ссылки, созданные до обновления, после перехода на 9.2.0 не проходят проверку.

Gifting переходит от глобального переключателя к настройке товара

Ещё одно заметное изменение касается подарочных подписок. Глобальная настройка Enable gifting for subscriptions остаётся, но вариант глобального поведения «включено для всех товаров по умолчанию» убран.

Теперь gifting хранится на уровне конкретного товара через meta key _subscription_gifting. Для массового изменения WooCommerce добавляет bulk-edit настройку.

Если до обновления магазин использовал глобальное «enabled for all products», фоновая миграция запишет это значение существующим товарам, у которых ещё нет собственной настройки. Если gifting был выключен, отдельная миграция не нужна: отсутствие значения теперь соответствует выключенному состоянию.

Для магазинов с большим каталогом после обновления стоит выборочно проверить товары и массовое редактирование, особенно если gifting влияет на frontend или собственные интеграции.

Меняется регистрация страницы настроек и REST-полей

В WooCommerce Subscriptions 9.2.0 вкладка настроек регистрируется через woocommerce_get_settings_pages вместо woocommerce_settings_tabs_array. Новый класс Settings_Page отвечает за REST-поля маршрута /wc/v3/settings/subscriptions, а прежний WC_REST_Subscriptions_Settings помечен как deprecated.

Если расширение или собственный плагин напрямую использует старый класс, это сигнал обновить интеграцию до того, как deprecated-код будет удалён в одной из будущих версий.

Поле woocommerce_subscriptions_max_customer_suspensions тоже изменилось: вместо select с фиксированным набором опций теперь используется числовое поле. Сами читаемые и записываемые значения сохраняются, но фильтр woocommerce_subscriptions_max_customer_suspension_range deprecated, а его результат больше не влияет на список.

Приоритет вывода настроек тоже может затронуть кастомный код

Новый Settings_Page подключает output() к действию woocommerce_settings_subscriptions с приоритетом 1, а не типичным 10. Это важно для кода, который добавляет собственные элементы на экран Subscriptions и рассчитывает на конкретный порядок выполнения.

После обновления стоит открыть страницу настроек и проверить не только наличие полей, но и их порядок, сохранение значений и совместимость собственных callbacks.

Plan-selector больше не загружается на каждой странице автоматически

Скрипт wcsatt-frontend, связанный с All Products for WooCommerce Subscriptions, раньше загружался глобально. В 9.2.0 он регистрируется, но не enqueue-ится на страницах, где WooCommerce не ожидает интерфейс выбора subscription plan.

Это улучшает загрузку страниц, которым скрипт не нужен. Но если план-селектор выводится на кастомном шаблоне, в quick-view, AJAX-фрагменте или другом нестандартном месте, разработчик должен вызвать WCS_ATT_Display::enqueue_frontend_script() до вывода scripts.

Метод является idempotent-обёрткой вокруг wp_enqueue_script(), поэтому повторный вызов в нескольких местах не должен создавать несколько подключений одного и того же скрипта.

Есть и небольшие изменения для производительности и PayPal Standard

WooCommerce отмечает, что WCS_ATT_Product::get_instance_id() больше не запускает полный bootstrap модуля All Products при каждом обращении к товару. Ранее это могло повторно регистрировать hooks и запускать фильтры wcsatt_modules при lookup товара.

Также появился фильтр woocommerce_subscriptions_paypal_standard_expected_payment_amounts. Он позволяет добавить допустимые суммы для renewal через PayPal Standard, когда цена подписки изменилась после создания профиля.

Обновлять сразу на production или сначала staging?

Для магазина без кастомизаций риск ниже, но Subscriptions обычно связан с оплатой и автоматическими продлениями. Поэтому разумнее сначала обновить копию сайта, проверить настройки и несколько ключевых сценариев, а уже затем переносить обновление на production.

Особенно это относится к проектам, где есть собственный PHP-код, нестандартные страницы тарифов, интеграции с CRM или платёжными шлюзами. Первый checkout может работать корректно, а проблема проявится позже на renewal или switch.

О базовой архитектуре рекуррентных платежей я отдельно писал в материале про подписки и продления WooCommerce. Если проект использует собственные REST-интеграции, полезно также проверить подход к авторизации WordPress REST API.

Когда имеет смысл провести аудит перед обновлением

Если WooCommerce Subscriptions работает вместе с кастомным checkout, собственными hooks, CRM, ERP или нестандартным gateway, перед обновлением лучше составить небольшой набор regression-тестов. Это быстрее, чем разбирать проблему уже после того, как подписки клиентов начали продлеваться по неправильному сценарию.

A.S Groups занимается разработкой и доработкой WooCommerce, включая кастомный PHP/JavaScript, API и интеграции. Если нужно проверить совместимость магазина с Subscriptions 9.2.0 или разобраться с конкретным renewal-сценарием, можно описать задачу и приложить список используемых расширений.

Итог

WooCommerce Subscriptions 9.2.0 не выглядит как обновление с одним крупным breaking change, но оно меняет несколько точек, где кастомный код мог зависеть от прежнего поведения. Наиболее заметны prorating физических товаров, новая модель gifting, более строгая логика manual renewals, обновлённая регистрация settings/REST и отказ от глобальной загрузки plan-selector script.

Для обычного магазина это повод проверить настройки после обновления. Для проекта с разработкой поверх Subscriptions — повод пройти staging-тесты и убедиться, что hooks, REST, платежи и frontend-сценарии работают так же, как задумано.