Description

In the payment gateways settings screen, there's a section prompting merchant to install other gateways for more auto-renew payment options.

This messaging should only be displayed when the store has WooCommerce Subscriptions active. With WC Payments + Subscriptions Core, WCPay is the only supported gateway.

Testing instructions

1. Make sure WC Payments is active and deactivate WC Subscriptions plugin
2. From the WP admin dashboard, navigate to WooCommerce > Settings > Payments
3. Click on the All payment method tab
4. Scroll down to the bottom of the page and notice the recurring payments section which tells store managers to "Find new gateways that support automatic subscription payments in the official WooCommerce Marketplace."

This wording should be removed from subscriptions core or changed to something else.

Product impact

• WooCommerce Payments: Automattic/woocommerce-payments#3402
• WooCommerce Subscriptions - Once this is removed from Subscriptions Core, we'll need to add this text back to WC Subscriptions if we think it's still necessary.

Part of #32

Background

Before the subscriptions-core codebase was split from WC Subscriptions, we had an open PR that introduced a few basic e2e tests and set up the e2e environment, see https://github.com/woocommerce/woocommerce-subscriptions/pull/3746.

We might be able to salvage this PR and bring it over to Subscriptions Core, however, this PR was based on a PR that added e2e tests to the PayPal Checkout repo which was based on an older version of WC core setting up their e2e environment. I'm sure there have been some updates to setting up the WC e2e environment, but also I'm imagining there are some differences between how WC Core sets up their e2e env and other repos like WCPay.

Part of tackling this issue will be looking at other similar repositories/projects for inspiration and aligning on how to set up e2e env in a standard/familiar way in subscriptions core.

Requirements

• Able to setup e2e env in Github checks/workflows
• Able to setup e2e env locally

Implementation

• Playwright - Tests will be written in Playwright rather than the typical Jest + Puppeteer
  • Reason: WP and WC are moving to Playwright so we should probably start there
• wp-env will be used to boot up the e2e environment with active plugins:
  • Latest WooCommerce installed/activated
  • Latest WC Payments gateway and dev tools installed/activated (not

e2e tests in subscriptions-core

Even though Subscriptions Core is a library, and on its own doesn't provide functionality without other plugins initializing it (WCPay) or extending it (WCS), we can still write e2e tests to test parts of subscriptions core that are fundamental to the core subscriptions library.

Because Subscriptions Core is designed to only work WC Payments, we should have WC Payments installed/activated in the e2e environment for better coverage.

Duplicate subscriptions e2e tests in WC Subscriptions and WCPay

E2E testing subscriptions functionality in 3 places is completely fine and is to be expected. We want to test subscriptions-core on its own and in the end products that use/extend it. So having three e2e tests in different repositories for creating a subscription product is a good thing.

When a subscriptions-core tag is pulled into WC Subscriptions and WC Payments via composer, there are some developer files being downloaded and included in the vendor/woocommerce/subscriptions-core:

To fix this, we'll need to add export-ignore in .gitattributes for the following files :

• .eslintignore
• .eslintrc
• .gitignore
• .prettierignore
• .prettierrc
• .stylelintrc.json
• phpunit.xml.dist
• webpack.config.js

Describe the bug

Currently css isn't meeting all of the standards set in https://developer.wordpress.org/coding-standards/wordpress-coding-standards/css/

To Reproduce

1. Run wp-scripts lint-css assets/css
2. see errors

Expected behavior

No errors / warnings

Actual behavior

> wp-scripts lint-style assets/css


assets/css/about.css
  10:11  ✖  Expected double colon pseudo-element notation   selector-pseudo-element-colon-notation
  11:15  ✖  Expected quotes around "WooCommerce"            font-family-name-quotes
  12:11  ✖  Expected single quotes                          string-quotes
  73:25  ✖  Expected double colon pseudo-element notation   selector-pseudo-element-colon-notation
  74:25  ✖  Expected double colon pseudo-element notation   selector-pseudo-element-colon-notation
  75:11  ✖  Expected single quotes                          string-quotes
  78:25  ✖  Expected double colon pseudo-element notation   selector-pseudo-element-colon-notation

Product impact

Should have no impact on products, internal changes to meet coding standards only

• Does this issue affect WooCommerce Subscriptions? no
• Does this issue affect WooCommerce Payments? no

Additional context

see also #32

Describe the bug

Description

In WooCommerce Subscriptions 3.1.6, we reverted a commit which introduced a bug where the "limit subscription" advanced setting was no longer showing on Simple Subscription Products.

Because Subscriptions Core was built off Subscriptions 4.0, which was built off 3.1.5, we'll need to manually cherry-pick this commit to WCS Core until Subscriptions 4.0 is merged into woocommerce-subscriptions/trunk.

Here's the changes to be merged into core: 4214-gh-woocommerce/woocommerce-subscriptions

Steps to replicate

1. Have WooCommerce Subscriptions Core installed as a standalone plugin (requires WC Payments on feature/stripe-billing or WC Subscriptions extensions 4-0-bleeding branches being active)
2. While on WCS Core trunk, go into Products > Add New
3. Set the product type to Simple Subscription
4. Notice there's no "limit subscription" setting under the Advanced tab

Description

Custom order tables are coming to WooCommerce.

woocommerce-subscriptions-core needs to be updated from old methods of saving metadata eg update_post_meta() to newer CRUD capable functions as the old methods will not be supported with custom order tables.

This issue deals specifically with the wcs_create_subscription()

Testing instructions

As this is a fundamental part of the subscriptions codebase, unit tests and thorough smoke testing should be done to confirm there are no regressions.

Product impact

No issues have been created for WooCommerce Payments or WooCommerce Subscriptions as it is a library only update and won't affect end-users.

Dev notes

Previous work was done in 3860-gh-woocommerce/woocommerce-subscriptions and was closed due to it becoming stale. So might be able to be used as a starting point.

Additional context

pdjTHR-H1-p2

Describe the bug

Currently javascript isn't meeting all of the standards set in @woocommerce/eslint-plugin

To Reproduce

1. Run wp-scripts lint-js assets/src/js
2. see errors

Expected behavior

No errors / warnings

Actual behavior

  6:1   error  Missing JSDoc @param "props.components" declaration                                                                   jsdoc/require-param
  13:0   error  Missing @param "props.components"                                                                                     jsdoc/check-param-names
  20:0   error  @param "props.useSelectShippingRate" does not exist on props                                                          jsdoc/check-param-names
  22:48  error  Insert `·`                                                                                                            prettier/prettier
  30:2   error  Insert `·`                                                                                                            prettier/prettier
  37:18  error  Replace `subscriptions` with `·subscriptions·`                                                                        prettier/prettier
  38:10  error  Replace `(recurringCart)·=>·recurringCart.shipping_rates` with `·(·recurringCart·)·=>·recurringCart.shipping_rates·`  prettier/prettier
  39:13  error  Replace `Boolean` with `·Boolean·`                                                                                    prettier/prettier
  41:4   error  Replace `subscriptions` with `·subscriptions·`                                                                        prettier/prettier
  43:33  error  Insert `·`                                                                                                            prettier/prettier
  46:3   error  Insert `·`                                                                                                            prettier/prettier
  47:34  error  Insert `·`                                                                                                            prettier/prettier
  50:3   error  Insert `·`                                                                                                            prettier/prettier
  51:22  error  Replace `({·package_id:·packageId,·...packageData·}` with `·(·{·package_id:·packageId,·...packageData·}·`             prettier/prettier
  53:9   error  Replace `packageId` with `·packageId·`                                                                                prettier/prettier
  54:15  error  Replace `packageId` with `·packageId·`                                                                                prettier/prettier
  55:17  error  Replace `packageData` with `·packageData·`                                                                            prettier/prettier
  56:17  error  Replace `collapsible` with `·collapsible·`                                                                            prettier/prettier
  57:14  error  Replace `shouldCollapse` with `·shouldCollapse·`                                                                      prettier/prettier
  58:15  error  Replace `shouldShowItems` with `·shouldShowItems·`                                                                    prettier/prettier
  59:22  error  Replace `noResultsMessage` with `·noResultsMessage·`                                                                  prettier/prettier
  60:18  error  Replace `renderOption` with `·renderOption·`                                                                          prettier/prettier
  62:3   error  Insert `·`                                                                                                            prettier/prettier

✖ 23 problems (23 errors, 0 warnings)
  21 errors and 0 warnings potentially fixable with the `--fix` option.

Product impact

• Does this issue affect WooCommerce Subscriptions? no
• Does this issue affect WooCommerce Payments? no

Additional context

see also #32

Description

The goal of this issue is to move the subscriptions unit test helper classes/functions into the subscriptions-core repository. These include:

• class-wcs-helper-coupon.php
• class-wcs-helper-product.php
• class-wcs-helper-subscription.php
• class-wcs-helper-upgrade-repair.php

These helpers are used across most of our unit tests so they'll need to be moved first.

As part of moving this functionality over, there might be some things we could take/learn from WC Payments helpers (i.e. WC data store mock and WC order helpers etc)

I'm open to ideas on this but I'm thinking we also move these to tests/unit/helpers to keep it consistent with WC Payments.

Related to https://github.com/woocommerce/woocommerce-subscriptions/issues/4195

Describe the bug

When a simple product is added to cart with an existing subscription product and subscription rules avoid to have both types, Add to cart Ajax call gets a 500 response. Looking at php logs, the error is caused by trying to use non-existing function redirect_ajax_add_to_cart in WC_Subscriptions_Cart_Validator class:

[30-Mar-2022 15:49:36 UTC] PHP Fatal error:  Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, class WC_Subscriptions_Cart_Validator does not have a method "redirect_ajax_add_to_cart" in C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php:307
Stack trace:
#0 C:\xampp\htdocs\testsubscriptions\wp-includes\plugin.php(189): WP_Hook->apply_filters(Array, Array)
#1 C:\xampp\htdocs\testsubscriptions\wp-content\plugins\woocommerce\includes\class-wc-ajax.php(191): apply_filters('woocommerce_add...', Array)
#2 C:\xampp\htdocs\testsubscriptions\wp-content\plugins\woocommerce\includes\class-wc-ajax.php(425): WC_AJAX::get_refreshed_fragments()
#3 C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php(307): WC_AJAX::add_to_cart('')
#4 C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php(331): WP_Hook->apply_filters('', Array)
#5 C:\xampp\htdocs\testsubscriptions\wp-includes\plugin.php(474): WP_Hook->do_action(Array)
#6 C:\xampp\htdocs\testsubscriptions\wp-content\plugins\woocommerce\includes\class-wc-ajax.php(90): do_action('wc_ajax_add_to_...')
#7 C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php(307): WC_AJAX::do_wc_ajax('')
#8 C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php(331): WP_Hook->apply_filters(false, Array)
#9 C:\xampp\htdocs\testsubscriptions\wp-includes\plugin.php(474): WP_Hook->do_action(Array)
#10 C:\xampp\htdocs\testsubscriptions\wp-includes\template-loader.php(13): do_action('template_redire...')
#11 C:\xampp\htdocs\testsubscriptions\wp-blog-header.php(19): require_once('C:\\xampp\\htdocs...')
#12 C:\xampp\htdocs\testsubscriptions\index.php(17): require('C:\\xampp\\htdocs...')
#13 {main}
  thrown in C:\xampp\htdocs\testsubscriptions\wp-includes\class-wp-hook.php on line 307

To Reproduce

1. Configure Woocommerce Subscriptions without mixed payment (cannot buy subscription product with other products at a time):
2. Configure a subscription variable product and avoid having more than one active subscription:
3. As guest, add the product in step 2 to cart:
4. Then, try to add a simple product to cart:

Expected behavior

Simple product is added to cart while suscription product is removed and a notice reminds both products cannot be bought at the same time.

Actual behavior

• Add to cart button remains spinning forever.
• Ajax call gets a 500 error.
• Php log shows a fatal error.

Product impact

• Does this issue affect WooCommerce Subscriptions? Yes
• Does this issue affect WooCommerce Payments? Tbc

Additional context

• Wordpress version: 5.9.2
• Woocommerce version: 6.3.1
• Woocommerce Subscriptions version: 4.1.0

Possible diagnostic and solution

Following the log, I found WC_Subscriptions_Deprecation_Handler class with a list of deprecated functions and their substitutions. There, I found redirect_ajax_add_to_cart function is now called add_to_cart_ajax_redirect.

Not sure if this handler should be managing calls to deprecated functions, but I made the substitution in maybe_empty_cart function of WC_Subscriptions_Cart_Validator class to now use add_to_cart_ajax_redirect and now it's working as expected.

Note

Since there is no public place for the WooCommerce Subscriptions plugin code to report bugs, I'll submit it here. Since this package is part of the plugin.

Describe the bug

When a user suspends their subscription the number of times he/she is allowed (if set value is not unlimited), PHP throws a warning:
Notice: Undefined variable: user_can_suspend in /var/www/vhosts/domain-name.com/wp-content/plugins/woocommerce-subscriptions/includes/class-wcs-customer-suspension-manager.php on line 79

The problem is inside WCS_Customer_Suspension_Manager::can_customer_put_subscription_on_hold():
It's because $user_can_suspend is not set outside the if statement.

Possible cause

Before the if statement, the method uses the variable name $can_user_suspend, which is similar, but not the same.

Solution

Simply typo fix, I think. ;)

To Reproduce

1. Looking at the source code of this function alone is enough. It's faulty code :)

Expected behavior

No errors

Actual behavior

Errors

Product impact

• Does this issue affect WooCommerce Subscriptions? yes
• Does this issue affect WooCommerce Payments? unknown, probably

Additional context

WooCommerce Subscriptions
Plugin version 4.0.2

This issue is based on WC Subscriptions issue 4304 (4304-gh-woocommerce/woocommerce-subscriptions).

Describe the bug

Active resubscribed subscriptions are being anonymized by our privacy data clean up tools. This is impacting stores which have set a period of time next to the "Retain ended subscriptions" setting found in WooCommerce > Settings > Accounts and Privacy

To Reproduce

1. Install the Crontrol Plugin so you can run cron event manually.
2. Purchase any subscription product.
3. Go into WooCommerce > Settings > Accounts & Privacy and set "Retain ended subscriptions" to be one month (screenshot).
4. Fully cancel the subscription - not pending cancellation. You will need to do this from the admin UI.
5. Resubscribe to the subscription you cancelled.
   1. At this point you should have a fully cancelled subscription and a newly resubscribed subscription.
6. Run the code snippet below replacing the subscription ID with the first subscription you purchased - the cancelled one.
7. Go into Tools > Cron Events and find the cron job with name woocommerce_cleanup_personal_data
8. Click on "run now" to run this task
9. Go into Tools > Scheduled Actions > Pending
10. Search for a scheduled action with name woocommerce_subscriptions_privacy_anonymize_ended_subscriptions
11. Click on "Run" under this scheduled action
12. After the above action is ran, search for pendings actions starting with "woocommerce_subscriptions_privacy"
13. You should see a scheduled action to clean up the old/initial subscription that we cancelled (check subscription IDs in the scheduled action args)
14. Manually run the scheduled action to clean up the old/initial subscription.
15. After the initial subscription is cleaned up, refresh the Scheduled Actions table and search for "woocommerce_subscriptions_privacy" again, you will notice there's now a scheduled action to clean up the resubscribed subscription even though it's still active 🚨

Once those actions run you'll see something like this:

The old and new subscription have been anonymized.

add_action( 'shutdown', function() {
	$subscription = wcs_get_subscription( 0 );
	$meta_key     = '_wcs-4304-end-date-updated';

	if ( $subscription && ! $subscription->meta_exists( $meta_key ) ) {

		// Simulate the subscription being ended for 1 month + 1 day.
		$subscription->update_dates(
			array(
				'last_order_date_created' => gmdate( 'Y-m-d H:i:s', gmdate( 'U' ) - MONTH_IN_SECONDS - DAY_IN_SECONDS ),
				'cancelled'               => gmdate( 'Y-m-d H:i:s', gmdate( 'U' ) - MONTH_IN_SECONDS - DAY_IN_SECONDS ),
				'end'                     => gmdate( 'Y-m-d H:i:s', gmdate( 'U' ) - MONTH_IN_SECONDS - DAY_IN_SECONDS )
			)
		);

		$subscription->update_meta_data( $meta_key, 'yes' );
		$subscription->save();
	}
} );

Expected behavior

The newly resubscribed subscription should be excluded from anonymisation.

Product impact

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
  • 4304-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref
  • Automattic/woocommerce-payments#3889

Additional context

Description

Currently we have a manual process for "releasing" subscriptions core. It goes something like this:

Prepare release PR

• Make a release branch e.g. release/5.3.0
• Update version numbers in various files
• Build assets with npm
• Push version and built assets to release branch
• Open a PR for release branch - the "release PR"

Build and push to GitHub releases

• Merge to trunk (after a final eyeball check of the changes)
• Create a GitHub release pointing at current trunk, named with raw release version 5.3.0
• Paste changelog into release description field and publish

From there, that release can be pulled into client projects using composer.

We'd like to streamline this as much as possible. There's a lot of redundant/mechanical monkey work here that is time-consuming and prone to human error.

The goal of this issue is to automate the "Build and push to GitHub releases" portion of this process, i.e. preparing the GitHub release.

The first part of this process will be tackled in #135.

Remove this message from core and port it to Subscriptions pro

This is displayed when WCPay is active and WCPay Subscriptions is enabled (via wp option _wcpay_feature_subscriptions).

Should be worker alongside with Automattic/woocommerce-payments#3024 and https://github.com/woocommerce/woocommerce-subscriptions/issues/4226

To Reproduce

1. Install WC Pay, get subscriptions active.
2. Activate WC Pay subscriptions using WC Pay DEV
3. See admin notice in plugins screen and possibly elsewhere in admin.

Expected behavior

Each plugin extending Subscriptions core should implement it's own way of showing a welcome message. The core should not have a default message.

The existing message should be ported to Subscriptions pro through #4226

Describe the bug

Updating the default payment method and choosing Yes to update active subscriptions to the new payment method does not update the subscription payment method as expected.

To Reproduce

1. Create a new subscription order.
2. As a customer, add a new payment method.
3. Make the new payment method the default.
4. When prompted, select Yes to update subscriptions to the new payment method.
5. See payment method for the subscription is not updated.

Product impact

• Does this issue affect WooCommerce Payments? Yes Automattic/woocommerce-payments#3729
• Does this issue affect WooCommerce Subscriptions? No

Screenshots

Clicking Make Default on the Amex card ending in 0005. Presents the prompt.

Clicking Yes does not update the payment method for the subscription

Describe the bug

When creating a new subscription manually via the admin screen, selecting WooCommerce Payments as the payment method and selecting a card/token won't actually save as WCPay because the subscription will be treated as manual because it doesn't have a WCPay Subscription ID.

We should improve the UX so there isn't any confusion left by this behaviour.

To Reproduce

With WooCommerce Subscriptions disabled:

1. Go to WooCommerce > Subscriptions > Add new
2. Select a customer, add a line item, etc.
3. Click the pencil icon in the billing section.
4. Select WooCommerce Payments.
5. Select a card/token in the dropdown.
6. Save.
7. The subscription saves and is treated as manual renewal.

Actual behavior

The subscription gets saved with WooCommerce Payments as the payment method (in the db), but because there's no WCPay subscription ID, it gets treated as manual. This is because of the behaviour in subscriptions-core introduced in this PR.

Screenshots

^ After saving

Expected behavior

We should remove all payment method options from this dropdown so admin users aren't given an option that isn't valid. ie Manual renewal should be the only option.

Additional context

WCPay issue: Automattic/woocommerce-payments#3384
subscription-core issue: #47
WC Subscriptions issue: 4266-gh-woocommerce/woocommerce-subscriptions

There are various PRs and fixes in progress in subscriptions core that should be included with the initial release of WCPay Subscriptions in WCPay 3.2.

The goal of this issue is to do whatever is needed to package up these fixes and include in WCPay RC build. This may require tagging a GitHub release and updating composer in WCPay.

Once the subs core release is ready it will need to be included in WCPay: see also Automattic/woocommerce-payments#3138

(Details tbd - @mattallan feel free to edit / add info)

Describe the bug

On WC Subscriptions 4.0.2 + WC 6.2, a DivideByZero fatal error is thrown when the user's session cart has been set to zero.

To Reproduce

I don't know exactly how to reproduce the problem, my client reported the WordPress critical error of death screen, I investigated, and found this error in the logs. It gets thrown after she attempts to log in.

PHP Fatal error:  Uncaught DivisionByZeroError: Division by zero in /.../wp-content/plugins/woocommerce-subscriptions/includes/class-wcs-cart-renewal.php:447
Stack trace:
#0 /.../wp-includes/class-wp-hook.php(307): WCS_Cart_Renewal->get_cart_item_from_session()
#1 /.../wp-includes/plugin.php(189): WP_Hook->apply_filters()
#2 /.../wp-content/plugins/woocommerce/includes/class-wc-cart-session.php(161): apply_filters()
#3 /.../wp-includes/class-wp-hook.php(307): WC_Cart_Session->get_cart_from_session()
#4 /.../wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#5 /.../wp-includes/plugin.php(474): WP_Hook->do_action()
#6 /.../wp-settings.php(609): do_action()
#7 /.../wp-config.php(95): require_once('/home/643317.cl...')
#8 /.../wp-load.php(55): require_once('/home/643317.cl...')
#9 /.../wp-blog-header.php(13): require_once('/home/643317.cl...')
#10 /.../index.php(17): require('/home/643317.cl...')
#11 {main}
  thrown in /.../wp-content/plugins/woocommerce-subscriptions/includes/class-wcs-cart-renewal.php on line 447

Somehow my client, who is a superadmin on this multisite network, ended up with a cart line item of zero. I suspect it may be related to switching back and forth between sites.

Expected behavior

It shouldn't throw that error

Actual behavior

It throws that error

Product impact

• Does this issue affect WooCommerce Subscriptions? yes
• Does this issue affect WooCommerce Payments? unknown

Additional context

To fix this temporarily, I added a sanity check to the get_cart_item_from_session function:

From WC 4.0.2, the line number was 428, where I added -

if ( empty( $item_to_renew['qty'] ) || $item_to_renew['qty'] < 1 ) {
	return null;
}

I realize that the second IF condition is overkill, but I've had weird behavior with empty before, so I usually make redundant checks like this.

Describe the bug

The subscriptions core library is loaded in WC Payments on the plugins_loaded with priority 0, however, the woocommerce_loaded do_action is triggered on plugins_loaded with -1 priority.

This means any code in subscriptions core that is hooked onto the woocommerce_loaded hook is not running in WC Payments.

I did a search through our codebase and here's all the classes which have woocommerce_loaded and the list of functions that are not running in WC Payments:

• WC_Subscriptions_Change_Payment_Gateway
  • maybe_zero_total() - Forces $subscription->get_total() to return $0 when changing the payment method.
• WC_Subscriptions_Checkout
  • filter_woocommerce_script_parameters() - Makes sure the guest checkout option value passed to the woocommerce.js forces registration
• WCS_Cached_Data_Manager
  • load_logger() - Creates the logger instance for the class.
• WCS_Cart_Renewal
  • add_line_item_meta() - For order items created as part of a renewal, keep a record of the cart item key so that we can match it later once the order item has been saved and has an ID
  • set_order_item_id() - After order meta is saved, get the order line item ID for the renewal so we can update it later
  • hidden_order_itemmeta() - Don't display cart item key meta stored above on the Edit Order screen
  • maybe_update_subscription_address_data() - Update customer's address on the subscription if it is changed during renewal
  • add_order_line_item_meta() - Adds custom line item meta from the old line item into the new line item meta

Working on this issue will rely on the unit test helpers being migrated: #60
Related to woocommerce/woocommerce-subscriptions#4195

Description

The goal of this issue is to migrate coupon, gateway, and admin related unit tests from the WC Subscriptions repository to the list of Subscriptions Core unit tests.

The unit test files that need to be migrated from woocommerce-subscriptions include:

• tests/unit/admin/admin-post-types.php
• tests/coupons/coupons.php
  • not including any WCS_Limited_Recurring_Coupon_Manager tests as thats a feature of WC Subscriptions)
• tests/unit/admin/wcs-permalink-manager.php should be moved out of tests/unit/admin and put in tests/unit/
• tests/unit/gateways/wcs-test-subscriptions-payment-gateways.php
  • this class was split into a core and pro version so some of these tests won't need to be migrated over

As part of migrating these tests over, we should also:

• use consistent naming of test files i.e. test-{file-name}.php
• each test class should extend WP_UnitTestCase instead of WCS_Unit_Test_Class
• keep the subscriptions-core/tests/unit/ file structure the same as subscriptions-core/includes (i.e. the coupons test file doesn't need to be in its own directory)

Description

From https://developer.woocommerce.com/2022/01/11/woocommerce-6-1-released/:

The is_ajax function has been deprecated. The WordPress function wp_doing_ajax should be used instead.

Testing instructions

1. Install WooCommerce 6.1.
2. Install woocommerce-subscriptions-core as a plugin.
3. Enable debugging by setting this constant in wp-config.php.

define( 'WP_DEBUG', true );

4. Purchase something so there is an order created in your store. If there is already an order, skip this step.
5. Edit an order and click the update button (no need to change anything).
6. Observe the deprecation warning:

Deprecated: is_ajax is deprecated since version 6.1.0! Use wp_doing_ajax instead. in {wordpress_path}/wp-includes/functions.php on line 5211

Product impact

• Does this feature affect WooCommerce Subscriptions? 4296-gh-woocommerce/woocommerce-subscriptions
• Does this feature affect WooCommerce Payments? Automattic/woocommerce-payments#3695

Describe the bug

❗ This issue relates to the WC Subscriptions issue: 4286-gh-woocommerce/woocommerce-subscriptions

When wcs_get_subscription returns false for some reason, the subsequent code to render the admin subscription table doesn't handle this well, e.g. render_shop_subscription_columns function calls $the_subscription->get_status() without checking the function is actually getting a subscription or output_rows is calling $subscription->get_parent_id(), again without checking if it's actually not getting false instead of the subscription object.

This causes a fatal.

To Reproduce

1. With a subscription with corrupt data (for example an invalid next payment data meta - like a string), view the admin subscriptions table.

Expected behavior

No errors.

Actual behavior

Fatal errors

Product impact

• Does this issue affect WooCommerce Subscriptions?
  • 4286-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments?
  • Automattic/woocommerce-payments#3596

Additional context

Description

Currently we have a manual process for "releasing" subscriptions core. It goes something like this:

Prepare release PR

• Make a release branch e.g. release/5.3.0
• Update version numbers in various files
• Build assets with npm
• Push version and built assets to release branch
• Open a PR for release branch - the "release PR"

Build and push to GitHub releases

• Merge to trunk (after a final eyeball check of the changes)
• Create a GitHub release pointing at current trunk, named with raw release version 5.3.0
• Paste changelog into release description field and publish

From there, that release can be pulled into client projects using composer.

We'd like to streamline this as much as possible. There's a lot of redundant/mechanical monkey work here that is time-consuming and prone to human error.

The goal of this issue is to automate the "Prepare release PR" portion of this process, i.e. preparing the release PR.

The second part of this process will be tackled in #131.

Describe the bug

PayPal Checkout smart payment buttons and Stripe Payment Request buttons (Apple & Google Pay) are being shown on subscription product pages when the WC Subscriptions extension is not active.

This is a bug because WooCommerce Payments should be the only available payment method when using the free subscriptions feature.

In subscriptions-core, we filter the list of available payment methods to only return WooCommerce Payments and in Stripe and PayPal Express Checkout I can see that they're checking if their gateway is available before rendering these buttons.

The reason they're still loading on subscription product pages is because our logic in WC_Subscriptions_Core_Payment_Gateways::get_available_payment_gateways() doesn't filter the list of gateways when viewing the subscription product page.

To Reproduce

1. Make sure the WC Subscriptions extension is deactivated
2. Activate WC Payments + Subscriptions feature, Stripe, PayPal Checkout
3. Setup and enable all three payment gateways (enable express payment methods on WCPay/Stripe and Smart Buttons on PayPal Checkout)
4. Create a subscription product if you don't have one
5. View the Subscription Product page
6. Notice the PayPal Smart Payment Buttons and Stripe express buttons incorrectly being shown 🔴
7. Add a subscription product to your cart and view the page again.
8. Notice only WC Payments express buttons are shown 🟢

Expected behavior

PayPal Smart Payment Buttons and Stripe express payment buttons shouldn't be shown on subscription product pages when WooCommerce Payments is the only available payment method.

I think the solution here is to add some logic here which checks is_product() and not a subscription product.

If it's a subscription product, we want to make sure to only return WooCommerce Payments.

Product impact

• Does this issue affect WooCommerce Subscriptions?
  • WC Subscriptions is not affected because we don't filter the list of available payment methods.
• Does this issue affect WooCommerce Payments? Yes
  • Automattic/woocommerce-payments#3401

Describe the bug

The pointer that appears on the “Add new product” page incorrectly references the WooCommerce Subscription extension even when WooCommerce Subscription is not installed or active.

To Reproduce

1. Have a WordPress website with WooCommerce Payments installed. WooCommerce Subscriptions should not be installed or activated.
2. Navigate to /wp-admin/post-new.php?post_type=product&select_subscription=true&subscription_pointers=true
3. Issue: Observe, the content in the pointer is "The WooCommerce Subscriptions extension adds two new subscription product types - Simple subscription and Variable subscription."

This is misleading as the WooCommerce Subscriptions extension is not installed and should not be referenced in this pointer.

Expected behavior

The pointer should only reference WooCommerce Subscriptions when the WooCommerce Subscriptions extension is installed and active.

Otherwise, it should reference WooCommerce Payments.

Actual behavior

The pointer references the WooCommerce Subscriptions extension whether or not it's installed or active.

Product impact

• Does this issue affect WooCommerce Subscriptions? no
• Does this issue affect WooCommerce Payments? yes Automattic/woocommerce-payments#4098

Describe the bug

Taken from: 4232-gh-woocommerce/woocommerce-subscriptions

When using the checkout block as the default checkout and attempting to switch a limited subscription, the following message is encountered when trying to complete checkout:

[subscription product] has been removed from your cart because it can no longer be purchased. Please contact us if you need assistance.

To reproduce

1. Use the checkout block
2. subscription switching is enabled
3. a variable subscription is limited to one of any status
4. try to switch that subscription. after pressing the 'place order' button see a message similar to:

Expected behavior

Switching a limited product should be allowed.

Actual behavior

The checkout is prevented due to limited products purchasability logic running.

Product impact

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref
  • No. Not in the same way at least, since switching isn't a feature offered in WC Pay.

Describe the bug

Currently we're using an experimental flag to "unhide" various cart item data relating to subscriptions when displaying in cart or checkout (blocks).

The item data is hidden in the shortcode checkout, and unhidden specifically for blocks.

The item data includes information such as:

• Free trial period
• Sign up fee
• Synched renewal date

This was introduced as part of initial blocks support - hat tip @senadir @james-allan @jorgeatorres.

Rubik and checkout team are reviewing this experimental flag and reached out to ask for feedback from us (as maintainers of Subscriptions).

Specifically:

• It's not used anywhere else – WC Subscriptions (now also WCPay Subscriptions) is the only client of this API.
• It may not strictly be needed – we may be able to solve this in different ways which are better or more maintainable overall.

See this comment from @mikejolley for more details of the options: woocommerce/woocommerce-blocks#4999 (comment)

The goal of this issue is to confirm if we need (require) __experimental_woocommerce_blocks_hidden. Once that's decided we can log follow up issues as needed:

• If we stick with __experimental_woocommerce_blocks_hidden, switch to stable variation when appropriate/shipped.
• If we abandon it, implement improved approach.

Product impact

• Does this issue affect WooCommerce Subscriptions? yes 4310-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments? yes Automattic/woocommerce-payments#3778

Additional context

Related to Automattic/woocommerce-payments#2962

Description

When admin create or edit a subscription via admin, only allow them to choose WooCommerce Payments or Manual Renew

Acceptance criteria

• Manual renewal is the only option if the customer doesn't have any saved cards.
• WooCommerce Payments is the only option shown if WC Subscriptions (plugin) isn't active.

Testing instructions

Creating subscription:
Test should be done with and without upe active

Case 1

• With WC Payments plugin active and WC Subscription inactive
• Go to WooCommerce > Subscriptions > Add new
• Choose a customer with a saved credit card on WCPayments
• Click the pencil icon in the billing fields section.
• It should show only WC Payments

Case 2

• With WC Payments plugin active and WC Subscription inactive
• Go to WooCommerce > Subscriptions > Add new
• Choose a customer without a saved credit card on WCPayments
• Click the pencil icon in the billing fields section.
• It should show only Manual Renewal

Case 3

• With WC Payments plugin active and WC Subscription active
• Go to WooCommerce > Subscriptions > Add new
• Choose a customer with a saved credit card on WCPayments
• Click the pencil icon in the billing fields section.
• It should show Manual Renewal and WC Payments

I am exporting data from "WooCommerce" to "ChartMogul", and it accepts two types of line items:
a) One Time
b) Subscription

None subscription orders are straight forward "One Time"
Subscription orders, specially parent orders need to be tested for two conditions:
a) Trial order / payment
b) Regular payment (none trial).

Because of varying trial fees, free trials, currency conversions, I can't compare it like this:

$has_trial_signup = WC_Subscriptions_Order::get_sign_up_fee( $order, $product->get_id() ) >= 0

It fails, when customer has just paid full, because it returns 0, hence $has_trial_signup is true, which is actually not the case.

In my case, signup fee can be $0, and still be a trial.
And signup fee can be $0, but not a trial.

So is this possible to just detect if order was trial order or full payment for Subscription orders, specifically "Parent Order".

Describe the bug

When there is only 1 Shipping Method available in the initial package, WooCommerce core doesn't display any radio buttons. Instead, it adds a hidden input element: https://github.com/woocommerce/woocommerce/blob/6ab6788c7547bf76f8e5a6e6948dd4fd93e5d2f3/plugins/woocommerce/templates/cart/cart-shipping.php#L38 and then runs the woocommerce_after_shipping_rate action. The hidden input element is necessary for the chosen_shipping_methods session key to be set correctly.

In WooCommerce Subscriptions, there are two cases in which there could be only 1 Shipping Method for the recurring package:

• when there is only 1 Shipping Method available for the matched zone (this is similar to the check WooCommerce core makes in the initial package) and;
• when the recurring package rates match the initial package rates (in other words, when the initial and recurring package have the same contents).

In both cases:

• the Shipping Methods radio buttons must be hidden,
• the hidden input element should be added and;
• the woocommerce_after_shipping_rate action should run.

This happens, though, only when there is 1 Shipping Method available for the matched zone and not when the recurring package rates match the initial package rates -- even though in the latter case only 1 Shipping Method is displayed as well.

The reason why this happens is that in this validation: https://github.com/Automattic/woocommerce-subscriptions-core/blob/trunk/includes/wcs-cart-functions.php#L108 the code only checks how many Shipping Methods are available for the matched zone and not if the recurring package rates match the initial package rates.

Therefore, when the recurring package rates match the initial package rates and one Shipping Method is displayed:

• the hidden input element is not added (and so, this Shipping Method is not set as the chosen shipping method for the recurring package in the session) and;
• the woocommerce_after_shipping_rate action does not run (and therefore, any code that hooks into this action doesn't run either).

To resolve this, it is necessary to make sure that this code: https://github.com/Automattic/woocommerce-subscriptions-core/blob/trunk/includes/wcs-cart-functions.php#L109-L110 always runs when this validation: https://github.com/Automattic/woocommerce-subscriptions-core/blob/trunk/includes/wcs-cart-functions.php#L90 passes.

To Reproduce

1. Make sure that you have at least 2 Shipping Methods available in your store.
2. Add a Simple Subscription Product to the cart.
3. Ensure that the Shipping Method radio buttons are hidden in the recurring package and that the Shipping Method selected in the initial package applies to the recurring package as well.
4. Install a snippet that uses the woocommerce_after_shipping_rate actiond (a) or a snippet that prints the chosen shipping methods per package (b):

(a)

add_action( 'woocommerce_after_shipping_rate', 'print_random_message' );

function print_random_message() {
	echo "Hello World!";
}

(b)

add_action( 'woocommerce_after_checkout_form', 'print_chosen_shipping_methods' );

function print_chosen_shipping_methods() {
	$chosen_methods = WC()->session->get( 'chosen_shipping_methods' );
	error_log( print_r( $chosen_methods, 1 ) );
}

5. If you used (a), does the custom message show up for the Shipping Method in the recurring package? If you used (b), is the chosen method for the recurring package passed to the session?

Expected behavior

The expected behavior is that the woocommerce_after_shipping_rate action should run after each Shipping Method regardless of how many Shipping Methods are available in the package or whether the package is a recurring one. Moreover, the hidden input element should show up when there is only 1 Shipping Method in the recurring package in order for this method to be set as the chosen one in the session.

Actual behavior

When the recurring package rates match the initial package rates, only one Shipping Method is displayed in the recurring package and the woocommerce_after_shipping_rate action does not run. Moreover, this Shipping Method is not set as the chosen one in the session.

Product impact

This issue affects all code that uses the woocommerce_after_shipping_rate action and expects that this action runs after all Shipping Methods. For example, Conditional Shipping and Payments conditionally adds notices next to each restricted Shipping Method -- these notices cannot be shown in Shipping Methods in the recurring cart since this action is missing.

Moreover, it affects all code that works based on the chosen shipping methods (WC()->session->get( 'chosen_shipping_methods ) as the chosen shipping method for the recurring package is not set.

PR incoming.

Description

One of our unit tests sometimes passes or fails with the following in result:

1) WC_Subscriptions_Test::test_calculate_trial_end_date
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'2022-02-17 05:28:33'
+'2022-02-17 05:28:34'

The 1 second off issue is caused by the unit test storing a value for $now = time(); before creating a new subscription.
The test then compares $now + 1 month with the subscriptions start time + 1 month which can sometimes be different.

I think we should update this unit test to not store time() and instead use the start time on the subscription.

Describe the bug

The file /assets/js/admin/admin.js overrides some WC core functions to show/hide content for "show_if" CSS classes.
The function hides content that should be shown for the "variable-subscription" type and then do its own logic to show the content again.

It checks only for the 'variable' and 'subscription' types but misses any other. In my case, I faced the issue when the tab should be shown for simple, variable, subscription, and variable-subscription types, but it does hide it (as it contains the 'show_if_variable-subscription' class and does not show again for simple type (I assume, It wouldn't work for any other types, except the types that are hardcoded checked))

To Reproduce

Add a new product tab with the following classes. It wouldn't appear for the "simple" type.

Description

In the file includes/class-wc-subscriptions-manager.php on line 89 there is the following check:

$renewal_order = self::process_renewal( $subscription_id, 'active', $order_note );

Because of the hardcoded 'active' parameter im unable to add an custom status thats processed with renewal orders.

Problem

I have implemented an custom status to be able to set custom cancellation processes.
For example to cancel the subscriptions that got canceled every half a year on fixed dates and keep the subscription generate 'next payment dates' till then.
Basicly an 'active status' that got set an 'end date' based on the conditions.
Even tho this works and next payment dates are generated they wont get processed because the process_renewal function gets only called for active status subscriptions.

Solution

Is it possible to add an hook to add an custom status for the second parameter?
So instead of an hardcoded 'active' status to be able to set an additonal status that should be processed.

Or to be able to override the whole function.

Or even to implement it so the process gets triggered for every status that has 'next payment dates' set.

WC Subscriptions has an error notice to inform the merchant that they are downgrading, which can be dangerous (e.g. after data upgrades have run).

This shows for merchants activating WC Subs 3.1.6 with the current dev WC Pay (forthcoming 3.2, with subscriptions feature). The message is misleading and alarming – it might cause support requests. This combination of plugins should work well and be supported, so ideally there would be no notice in this situation.

How to reproduce the bug

1. Set up WCPay 3.2/develop branch in your dev env and make sure you are onboarded.
2. Ensure WCPay Subscriptions is enabled - set option _wcpay_feature_subscriptions to 1 or use dev tools plugin.
3. Install and activate WC Subscriptions 3.1.6.

Expected behaviour

No error!

Possibly something congratulatory, e.g. : congratulations on upgrading to WC Subscriptions, you now have access to more features, flexibility and other payment gateways.

Actual behaviour

Error notice with links to open a support ticket: Warning! It appears that you have downgraded WooCommerce Subscriptions from 4.0.0 to 3.1.6. Downgrading the plugin in this way may cause issues. Please update to 4.0.0 or higher, or [open a new support ticket] for further assistance. [Learn more »]

Possible solutions

• Change the wording etc of the message for specific version combinations.
• Make the notice dismissable.
• Release an updated WC Subscriptions. This would address the issue in the newest combination, though it would still occur if merchants use old subs zip, and we may hit the issue again as new versions are released.
• Use a different versioning system for subs core library and/or WCPay Subs feature. I'm not sure if this would fix, but could be part of a fix.

Impact?

I'm not clear on how common this scenario might be. If it's rare that merchants would actually see this message, maybe ok to de-prioritise.

However this notice is a symptom that there are some changed assumptions, so it would be good if we could get ahead of that.

Slack discussion p1634009219292300-slack-C02BW3Z8SHK

Description

Related to 4291-gh-woocommerce/woocommerce-subscriptions.

Template files were moved from woocommerce-subscriptions/templates to woocommerce-subscriptions-core/templates, so 3rd-party plugin that tries to load WCS' templates using wc_get_template() will not work.

Product impact

• Does this feature affect WooCommerce Subscriptions? 4291-gh-woocommerce/woocommerce-subscriptions
• Does this feature affect WooCommerce Payments? Automattic/woocommerce-payments#3606

Dev notes

Additional context

Describe the bug

If you filter your WooCommerce > Subscriptions table in such a way that 0 results are returned, it displays the empty state messaging rather than the no results found message.

To Reproduce

1. Go to WooCommerce > Subscriptions
2. Filter your table by searching for a string that won't exist or by filtering by a payment method you won't have subscriptions with (eg PayPal on a WCPay Subscriptions store).
3. You should see 0 results returned and the following message.

Expected behavior

The message should read: "No Subscriptions found"

Actual behavior

It's related to a caching issue. Because we store a bool in a transient it gets stored as an int. That then fails this true === check.

Product impact

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
  • 4274-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref
  • Automattic/woocommerce-payments#3412

Additional context

Describe the bug

Related to 4276-gh-woocommerce/woocommerce-subscriptions

Product impact

• Does this issue affect WooCommerce Subscriptions? yes 4276-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments? likely yes but TBD

Describe the bug

When an admin manually modifies the cost of a single subscription product on an order that contains multiple subscription products, a discount_initial coupon is added to the order. That discount is then applied to all subscription products, rather than the single subscription product whose cost was edited.

This customer uses the "Checks" gateway as a way to create an order that can be modified to be accurate later, adjusting the costs as needed on specific products- sometimes only a single one (sort of like a 'contact for quote' situation). This issue turned a $5 discount added to a single product into an $800 discount, after the discount_initial coupon code was applied to every subscription products on that order.

To reproduce

1. Create two subscription products.
2. Enable the Checks payment method.
3. Place an order for both subscription products, using the Checks payment method.
4. Modify the cost of one subscription product (not both) and update.
5. View the order as the customer and notice the discount was applied to all subscription products via a hidden coupon code.
6. Pay for the order as the customer.
7. View the order as an admin and notice the coupon code discount_initial was added and applied to all products on the order.

Screenshots

Order where a single line item/subscription product was edited (showing correctly):

Checkout page after edit (showing the amount being applied to all products incorrectly):

Order admin after customer pays for updated order (incorrect amount):

Expected behavior

When a single subscription product has the cost manually edited by an admin, that discount should only be applied to that product, not every subscription product on the order.

Additional details

Reported in 4404381-zen

See original issue in WooCommerce Subscriptions repository: 4233-gh-woocommerce/woocommerce-subscriptions

Confirmed locally with WP 5.8.1, Storefront 3.9.1, WC 5.8.0, & Subscriptions 3.1.6

Related WC Subscriptions issue: https://github.com/woocommerce/woocommerce-subscriptions/issues/4271

In WCS Core, we display a warning to store managers when they downgrade their Subscriptions version to a previous major version: i.e.
4.0.0 -> 3.1.6

As mentioned on #7 (comment), this notice is somewhat not relevant these days and was originally added to Subscriptions to notify store managers that have downgraded from 2.0 back to 1.5.

This is because in 2.0, Subscriptions changed significantly from being array stored on an order, to a custom order type, so downgrading back to 1.5 was really bad.

These days downgrading from Subscriptions 4.0 to 3.0 isn't a big deal at all so this issue is to look at updating when we show this notice:

Some options:

• downgraded 2 major version
• downgraded back to 1.5.x

Describe the bug

ticket: 4828631-zd-woothemes

When a customer pays for a failed renewal order with PayPal Standard we create a new subscription in PayPal and pass arguments to start the subscription from today.

[a1] => 15.91
[p1] => 1
[t1] => M
[a3] => 15.90
[p3] => 1
[t3] => M
[src] => 1
[sra] => 0

Looking at the PayPal Standard docs, these args essentially translate to a $15.91 sign up where there is a 1 (p1) month (t1) free trial with a $15.90 every 1 (p3) month (t3).

I'm not entirely sure why there's a 1 month free trial, however that's pretty harmless as far as I can tell.

The problem is that we aren't accounting for a synced subscription.

To Reproduce

I haven't replicated this issue myself I've only confirmed this by observing the issue on this customers site by looking through PayPal logs. I've included the following steps based on how I think it can be replicated.

1. Purchase a synced subscription with any gateway.
2. Either force the renewal to fail or mimic that behaviour.
3. Attempt to sign up to the failed renewal order using PayPal Standard.
4. You should see that the PayPal Standard subscription is essentially not synced. It will have a next payment date 1 billing cycle from today rather than when it should have been synced.

Expected behavior

The PayPal subscription should have a trial that takes the subscription up to the next sync date.

Actual behavior

Product impact

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref
  • No WC Payments doesn't support PP Standard subscriptions.

Working on this issue will rely on the unit test helpers being migrated: #60
Related to woocommerce/woocommerce-subscriptions#4195

Description

This issue is to track moving the existing unit tests found on WC Subscriptions repository that are related to related orders and customer data, over to the subscriptions-core.

Test files that will need to be migrated over include:

• tests/framework/class-wcs-customer-store-test-base.php
• tests/framework/class-wcs-customer-test-store.php
• tests/framework/class-wcs-related-order-test-store.php
• tests/framework/class-wcs-related-order-store-test-base.php
• tests/unit/related-orders/related-order-store.php
• tests/unit/related-orders/related-order-store-cpt.php
• tests/unit/related-orders/related-order-store-cached-cpt.php
• tests/unit/customer-store/customer-store.php
• tests/unit/customer-store/customer-store-cpt.php
• tests/unit/customer-store/customer-store-cached-cpt.php

As part of migrating these files, we should also:

• use consistent naming convention i.e. test-{file-name}.php
• each test class should extend WP_UnitTestCase instead of WCS_Unit_Test_Class (I don't think we'll need this custom unit test class anymore)
• keep the tests/unit/ file structure similar to that of subscriptions-core/includes. Rather than having unit/related-orders and unit/customer-store directories, these files would just go in tests/unit/data-stores/test-{file-name}.php
• framework files could go under tests/unit/helpers or somewhere else (open to ideas)

Description

Currently subscriptions-core composer package type is set to "library" which isn't a supported package type by composer/installers, this means WC Subscriptions or WC Payments can't use the Custom Install Paths feature of composer/installer to install subscriptions-core in a different path to other dependencies.

As part of addressing an issue with translating WC Subscriptions + subscriptions-core (see pdjTHR-tA-p2 for internal discussion on this topic) the solution we have decided to go with is install subscriptions-core in packages/ without moving everything from vendor to be in packages/ so we should use a known composer type.

Most similar packages (WC admin, Action scheduler, Blocks) use the "wordpress-plugin" type so we should update this line in composer.json to this type.

Description

#86 introduces is_deprecated_default_path(). Write a unit test for that function.

Product impact

• Does this feature affect WooCommerce Subscriptions? no.
• Does this feature affect WooCommerce Payments? no.

Description

Add automated checks to pull requests to make submissions and reviewing easier.

Checks to add

• PHP linting (implemented with Adding basic linting via github actions. #34)
• PHPCS running on new changes (implemented with Adding basic linting via github actions. #34)
• JS linting #59
• Have some of these checks run on pre-commit (similar to WC Payments)
• PHPUnit added and a simple assertTrue(true) unit test running #57
• #156
• Start requiring PHPUnit tests on any new functions
• Port/migrate any old unit tests from WC Subscriptions (these are old/slow tests so it might be worth looking into them and deciding if we should scrap them entirely or make them more efficient as we copy them over)
• Basic e2e test ?
• Start updating existing code to run on the latest WC codesniffer rules
• Enforce minimum test coverage.

Update WC_Subscription::is_manual() so only WC Pay Subscriptions are considered automatic. All other subscriptions will be manual unless they install the WC Subscriptions plugin.

To achieve this apply one of the following changes:

1. Add a new condition to this if that only WC Pay subscriptions pass.
2. Change WC_Subscription::get_requires_manual_renewal() so it only returns true when it's set up with WC payments.

In both those cases we can introduce a function to WC_Subscriptions_Core_Payment_Gateways (core) and override it in WC_Subscriptions_Payment_Gateways (plugin)

Working on this relies on the unit test helpers being migrated: #60
Related to https://github.com/woocommerce/woocommerce-subscriptions/issues/4195

Description

This issue will tackle migrating all of the unit tests for our wcs-x-functions.php files from woocommerce-subscriptions/tests/unit/ over to the the subscriptions core repository.

The unit tests that need to be moved include:

• wcs_test_wcs_helper_functions.php
• wcs_test_wcs_functions.php
• wcs_test_wcs_compatibility_functions.php
• wcs_test_wcs_cart_functions.php
• wcs_test_user_functions.php
• wcs_test_time_functions.php
• wcs_test_order_functions.php (move the one unit test from orders/functions.php to this file as well)
• wcs_test_deprecated_functions.php

As part of doing this move we should also:

• rename the files to test-{file-name}.php instead of wcs_test_{file_name}.php
• each test class should extend WP_UnitTestCase instead of WCS_Unit_Test_Class (I don't think we'll need this custom unit test class anymore)

Describe the bug

When creating a Simple Subscription product:

• the "One time shipping" option under Product Data > Shipping and;
• the "Limit Subscription" option under Product Data > Advanced,
  are hidden.

Here's a video depicting this behavior:

To Reproduce

1. Go to the Products tab
2. Create a new Simple Subscription product.
3. Navigate to either Product Data > Shipping or Product Data > Advanced and check if Subscription specific settings show up there.

Expected behavior

The expected behavior is that "One time shipping" and "Limit Subscription" settings would show up for Simple Subscription products.

Actual behavior

The actual behavior is that these settings only show up for Variable Subscription products but not for Simple Subscription ones.

Product impact

• Does this issue affect WooCommerce Subscriptions? Yes 4288-gh-woocommerce/woocommerce-subscriptions
• Does this issue affect WooCommerce Payments? Yes Automattic/woocommerce-payments#3537

This issue can have a major product impact as many of the Subscription-specific settings do not show up for Simple Subscription products. So, customers cannot use many of the advertised features.

In addition to that, customers who transitioned from WooCommerce Subscriptions to WooCommerce Payments will not be able to edit the values of these settings.

Additional context

This issue was introduced via: da32cf1#diff-0dec7a408ff08c7c6200cd2b92cdc10704d7b68c3066c70f9e3c89ebadd6a7eb

The aim of that commit was to fix an issue with Subscription-related fields incorrectly showing up/getting hidden when adding new variations to a product.

To fix this, this commit sets all Subscription-related fields to hidden for all product types. Then, if the current product is a Variable Subscription product, these fields get shown. However, there isn't any code for what should happen for Simple Subscription products -- therefore, these fields remain hidden for Simple Subscription products.

Description

In WC Payments we added the following helper functions to the WC_Payments_Subscriptions_Utilities trait:

• is_subscriptions_plugin_active()
• get_subscriptions_plugin_version()
• get_subscriptions_core_version()

After working on third-party compatibility with WCPay Subscriptions, we've found these functions would be useful to have available outside classes that use the subscriptions utilities trait, so this issue is to look at adding these functions.

Some options:

Function names

• wcs_is_subscriptions_plugin_active()
• wcs_get_subscriptions_plugin_version()
• wcs_get_susbcriptiosn_core_version()

We could shorten these by removing _subscriptions i.e. wcs_is_plugin_active() but that seems to vague.

Location

• Inside wcs-helper-functions.php
• Inside wcs-functions.php
• New wcs-core-functions.php

I'd probably go with inside wcs-functions.php but I'm open to other options. I also thought of the existing wcs-compatibility-functions.php but from looking at the functions, this file looks to be used for public subscriptions functions to help with compatibility with WooCommerce so I don't think these functions work here.

Product impact

• Does this feature affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• Does this feature affect WooCommerce Payments?
  • Once these functions have been added, we can remove the functions from WCPay and replace them with these new ones.

The REST API subscription endpoints currently allow users to change a subscription that is incompatible with WC Pay Subscriptions. With that in mind, we need to remove the REST API files out of core and introduce them directly to the plugin.

The REST API wasn't included on the original feature matrix here: paJDYF-27L-p2

Working on this issue will rely on the unit test helpers being migrated first: #60
Related to woocommerce/woocommerce-subscriptions#4195

Description

This issue is to track migrating the existing unit tests found on WC Subscriptions repository that are related to the main WC Subscription class, emails and other remaining unit tests like the core autoloader.

Test files that will need to be migrated over include:

• tests/unit/subscriptions/subscriptions.php
• tests/unit/subscriptions/subscriptions-payment-count.php
  • this is testing subscription->get_payment_count() and doesn't need to be a separate class so it should be moved into the above file
• tests/unit/wcs_emails.php
• tests/unit/wcs_post_meta_cache_manager.php
• tests/unit/wcs_test_autoloader.php

As part of moving these files over, we should also:

• use consistent naming convention i.e. test-{file-name}.php
• each test class should extend WP_UnitTestCase instead of WCS_Unit_Test_Class
• keep the tests/unit/ file structure similar to that of subscriptions-core/includes. Rather than having unit/subscriptions this should go in tests/unit/test-{file-name}.php