❌

Normal view

Published — 8 September 2026 ⏭ wp

WooCommerce Subscriptions 9.2.0: settings updates and dev changes

WooCommerce Subscriptions 9.2.0 comes with updated settings page UI and behavior, and includes several other changes worth knowing if you build extensions, gateways, or custom integrations for Subscriptions. Here are the ones with the widest impact; the full list of fixes and changes is in the latest version notes on the product page.

Physical products can now be prorated

Changing proration settings has historically focused on virtual products only; 9.2.0 now allows for “Prorate Recurring Payment” and “Prorate Subscription Length” to be applied to physical products as well! 

woocommerce_subscriptions_apportion_recurring_price accepts two new values, physical-upgrade and physical, and woocommerce_subscriptions_apportion_length accepts physical. These behave the same way as their virtual counterparts: the -upgrade variant prorates upgrades only and leaves downgrades alone, while plain physical prorates in both directions.

The change is additive. Default values are unchanged, and the wcs_switch_should_prorate_recurring_price and wcs_switch_should_prorate_length filters keep their existing signatures.

Rolling back to 9.1.0 or earlier: older versions don’t recognize the new values, so proration defaults “off” without any fatals or data loss.

On the 9.1.0 settings screen, the dropdown has no option matching the stored value, so nothing appears selected. If an admin saves that settings section without picking a new value, the stored physical or physical-upgrade is overwritten with no.

Closing the gap on manual-payment flags

“Turn off automatic payments” could previously force a subscription into a manual renewal state even if the parent setting, “Accept Manual Renewals,” was disabled. 

WCS_Manual_Renewal_Manager::is_manual_renewal_required() now requires both settings to be enabled. A one-time upgrade routine re-enables “Accept Manual Renewals” on any store caught in that contradictory state, so existing behavior carries over rather than changing silently.

Line item removal gets a capability check, and links get their own nonces

Removing a line item has always been the subscription owner’s privilege, but the code enforced it loosely. wcs_can_items_be_removed( $subscription, $user_id = 0 ) in wcs-functions.php now checks the edit_shop_subscription_line_items capability, which only the owner holds. The visible effect is small — the recipient of a gifted subscription no longer sees the remove-item control on My Account.

Two things to know if you call or filter it. The capability check runs after the existing wcs_can_items_be_removed filter and is combined with it, so a filter can still narrow the result but can no longer grant removal on its own; the filter now receives the user as a third argument. With no user to check, the function returns false, so calls from cron, WP-CLI, or an unauthenticated REST request now return false where they previously could return true.

The same hardening reaches the links themselves: removal and resubscribe links now mint a nonce for their own operation instead of sharing one keyed only to the subscription ID, so a link issued for one can’t be replayed for the other. Links generated before 9.2.0 no longer verify. A resubscribe link can be reopened from My Account, but the “Undo?” link offered right after a removal can’t be reissued.

Gifting moves from a global switch to a per-product setting

While Enable gifting for subscriptions is still available — Enabled/Disabled for all products default has been removed. Gifting is now set per product via the _subscription_gifting meta key, and a new bulk-edit option turns it on or off across many products at once.

If the storewide default was “enabled for all products,” a background migration writes that value onto existing products that don’t already have one. Stores that had gifting off need no migration since off is the new default for products with no value set.

The migration has no filter, so the per-product meta and the bulk edit are the only ways to adjust gifting on existing products.

Settings REST fields get a new registration path, and one field changes type

The Subscriptions settings tab now registers through woocommerce_get_settings_pages rather than woocommerce_settings_tabs_array. A new Settings_Page class registers the /wc/v3/settings/subscriptions REST fields, replacing the now-deprecated WC_REST_Subscriptions_Settings class.

woocommerce_subscriptions_max_customer_suspensions changes from a select with a fixed option list to a number field. The values it reads and writes are unchanged. The woocommerce_subscriptions_max_customer_suspension_range filter, which adjusted that list, is deprecated and its return value is now ignored.

One wiring detail: Settings_Page hooks its output() callback to woocommerce_settings_subscriptions at priority 1 rather than the usual 10, so it renders before anything else on that action at the default priority. If your code adds to this screen expecting to run after core’s output, that assumption no longer holds.

Loading the All Products plan-selector script on custom pages

The plan-selector script (wcsatt-frontend) used to load on every page, even ones that couldn’t show subscription options. It’s now registered but not enqueued.

If you render the plan-selector markup somewhere Subscriptions doesn’t already handle — a custom template, an AJAX-loaded fragment, a quick-view modal — call WCS_ATT_Display::enqueue_frontend_script() before scripts print. It’s an idempotent wrapper around wp_enqueue_script(), so calling it from several places is fine.

A couple of smaller items: 

  • WCS_ATT_Product::get_instance_id() no longer re-runs full module bootstrap used previously by All Products for WooCommerce Subscriptions (re-registering hooks, re-firing the wcsatt_modules filters) on every call – it was doing that on every product lookup. 
  • And a new woocommerce_subscriptions_paypal_standard_expected_payment_amounts filter lets you add acceptable amounts for a PayPal Standard renewal when the subscription’s price has changed since the profile was created.

For the complete list of fixes and changes in 9.2.0, see the latest version notes.

The post WooCommerce Subscriptions 9.2.0: settings updates and dev changes appeared first on The WooCommerce Developer Blog.

Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond

The WooCommerce engineering team has been evaluating WooCommerce’s minimum PHP requirement, talking with the community, and tracking general store hosting trends. Our goal is to bump the minimum requirement to PHP 8.1 or newer, starting with the WooCommerce 11.5 release currently targeted for January 2027. This change would end support for PHP 7.4 and 8.0 in future versions of WooCommerce.

We want to hear from store owners, agencies, hosting providers, extension developers, and other WooCommerce contributors as we determine the target release.

Benefits of requiring PHP 8+

PHP 7.4 and PHP 8.0 are no longer supported by the PHP project. PHP 7.4 reached end of life in November 2022, and PHP 8.0 reached end of life in November 2023. Running unsupported PHP versions can leave sites exposed to security issues that no longer receive fixes.

Our internal WooCommerce usage data shows that PHP 7.4 currently accounts for approximately 7% of tracked stores, while PHP 8.0 accounts for approximately 2%. Among stores running a relatively recent WooCommerce version (within the last year), the combined usage is closer to 6% and trending consistently downward. WooCommerce usage tracking is opt-in, so these figures do not represent every store, but a representative sample.

Moving to a newer minimum PHP version would allow WooCommerce and third-party developers to:

  1. Use modern PHP language features (union types, attributes, null-safe, match, named parameters, …).
  2. Adopt newer, more secure dependency packages that no longer support older PHP versions.
  3. Reduce the number of PHP versions that must be tested in continuous integration, speeding up e2e testing, PR reviews, and releases.
  4. Remove compatibility branches and legacy code paths that are increasingly difficult to maintain.

Simply upgrading to PHP 8.0+ means performance improvements for WooCommerce stores by default. Those benefits come from upgrading the PHP runtime itself, and our goal is to see every WooCommerce store continually running the most optimized stack available.

Impact on stores running PHP 7.4 or 8.0

A store running PHP 7.4 or 8.0 would not be automatically upgraded to a WooCommerce version that requires PHP 8.1.

If the proposal is adopted:

  • WooCommerce 11.5 would declare Requires PHP: 8.1.
  • By default, WordPress would prevent the update from being offered to stores that do not meet that requirement.
  • The store would continue running its existing WooCommerce version and receive any dot releases to that particular branch.
  • The store would need to upgrade PHP before updating to WooCommerce 11.5 or a later compatible release.

This follows the same general approach used for previous WooCommerce PHP requirement changes. For example, WooCommerce 8.2 raised the minimum requirement to PHP 7.4 with advance communication and migration guidance. See New Requirement for WooCommerce 8.2: PHP 7.4+.

The change would not update PHP on a store’s behalf or automatically deactivate an existing WooCommerce installation. Stores that remain on an older PHP version would remain on the latest WooCommerce release compatible with that environment, subject to WooCommerce’s existing support policy.

WordPress and WooCommerce PHP requirements

WordPress currently runs on PHP 7.4 or newer and recommends PHP 8.3 or newer for a modern hosting environment. See the WordPress requirements.

WooCommerce has previously maintained a higher PHP requirement than WordPress. WooCommerce is a complex ecommerce application with its own dependencies, performance requirements, and compatibility considerations, so its minimum PHP version does not need to match WordPress’s minimum version.

Guidance for extension developers and agencies

Developers extending Woo should already be testing their code against newer PHP versions, but additional testing may be helpful.

Extensions that target WooCommerce 11.5 or later could use PHP features and dependencies available in the new supported range. Extensions that continue supporting older WooCommerce versions may need to maintain compatibility layers or separate code paths.

Raising WooCommerce’s minimum PHP version does not guarantee that every extension, theme, or custom snippet will work after a store upgrades PHP. Testing on a staging site remains important.

Feedback on the proposed PHP requirement

Please let us know:

  • What would prevent your store or client sites from moving beyond PHP 7.4 or 8.0?
  • Are there extensions, themes, or custom integrations that still require these PHP versions?
  • Would targeting WooCommerce 11.5 (January 2027) provide enough time to prepare?
  • Do hosting providers have additional data about PHP version usage across WooCommerce stores?
  • Are there compatibility or deployment concerns we have not covered?
  • What migration guidance would make this change easier for your team or customers?

When reporting a compatibility concern, please include the PHP version, WooCommerce version, affected extension or integration, and any relevant error messages or reproduction steps.

Decision and release timeline

We will review the feedback and usage data before confirming the target release and minimum PHP version.

As the change proceeds, we plan to provide advance notice, communicate the final release target, and give developers time to test against the new requirement before WooCommerce 11.5 is released.

Please share your feedback in the comments below.

The post Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond appeared first on The WooCommerce Developer Blog.

Published — 7 September 2026 ⏭ wp
Published — 5 September 2026 ⏭ wp
Published — 4 September 2026 ⏭ wp
Published — 3 September 2026 ⏭ wp
❌