Subscription Management: Add to existing Subscriptions (Core Types)

[manospsyx]

The idea here is that users should be able to easily add any product to an existing Subscription.

Common use case: "Get an extra bottle of that milk with the next scheduled super-market delivery."

• [x] First step: Only support subscriptions defined at product level.
• [x] Second step: Add support for Cart Subscription schemes as well.

UI/UX

I am leaning towards a solution that will enhance the standard Add to Cart | Sign upactions with a new Add to Subscription action.

Doesn't need to "stick" as much, so I wouldn't make it a button. For products that have schemes defined at product level, the back-end code should load all subscriptions with the same billing schedule and present a form that the user can interact with. Here's a simple mockup:

<a>Add to Subscription &rarr;</a>
<form>
    <select>Choose a Subscription</select>
    <button>Add</button>
</form>

Needs to be done before looking into L2 of #222 .

Additional Notes

• [x] If a scheme is synced, match Subscriptions renewing on the same day/date.
• [x] If a scheme has a fixed length, match Subscriptions having the same amount of renewals left.
• [x] Disable add-to-sub when a scheme is prorated.

[manospsyx]

Adding this to the 2.1 Milestone. Depending on how this goes, this might be the last 2.1 feature as there's already quite a lot that's new in 2.1.

load all subscriptions with the same billing schedule

@thenbrent

Any quick tips on getting all active subscriptions of a customer that have a known billing schedule (day/week/month/year)?

Use case:

• Customer has an active subscription that includes some physical goods. The sub is renewed every Monday morning and the goods are sent to the customer on the same day.
• He/she wants to add a product (or cart) with a non-synchronized weekly sub option to that Monday subscription.

When subscribing to physical goods, I can't grok how proration could be relevant.

Of course, we should not limit SATT scope to physical goods only, but experience has shown that so far SATT is mostly popular in physical subscription applications -- trials and sign-up fees haven't received the interest we expected.

So, as you said, if proration ends up being too tough to justify the effort, it might be a good idea to support it in a future version and focus on getting the UX right in 2.1.

[thenbrent]

Any quick tips on getting all active subscriptions of a customer that have a known billing schedule

The best approach would be to use wcs_get_subscriptions() with a 'subscription_status' and 'meta_query' for '_billing_period' and '_billing_interval' (that should be future proof, albeit not the most obvious way to do it).

That will have serious perf issues though until we get to custom tables...

One way to mitigate this would be to use a pop-up dialogue box when the "Add to Subscription" button is clicked which runs an Ajax query to find the subscriptions with the match billing schedule. That way, at least the query is only being run when it's really needed, and it's not slowing down the product page load times.

I can't grok how proration could be relevant

Yeah I don't think it's relevant to physical goods in any reasonable use case, only really virtual goods where each day of access provides some value (and presumably incurs some cost).

if proration ends up being too tough to justify the effort, it might be a good idea to support it in a future version

One of the great advantages of doing this in SATT is that we don't need to support all use cases with v1.0 like we strive to do with Subscriptions core, so I'm fully in support of shipping v1.0 of this feature without proration, and adding that in if/when needed later on.

focus on getting the UX right in 2.1

The UX will likely be different depending on whether the flow includes proration or not. Although, I guess it will only differ in terms of what happens between the customer indicating the desire to add a product to a subscription (not the cart) and it being added to the subscription. That start and endpoint could remain the same, and just include the cart/checkout in the middle when needing to prorate.

[danielbair]

I don’t know if this is the same, but we have customers asking to be able to select their own cart subscription start date.

[thenbrent]

@danielbair that's quite a different bit of functionality to this.

It is something we're aware of as it has been requested before, but it's not on the roadmap for this plugin or WooCommerce Subscriptions yet.

It's something that would fit quite nicely into the Toolbox for WooCommerce Subscriptions, so you may wish to reach out to Gabor to ask if it is a feature that is going to be added to that plugin.

[danielbair]

Thank you. I will do that.

[manospsyx]

One way to mitigate this would be to use a pop-up dialogue box when the "Add to Subscription" button is clicked which runs an Ajax query to find the subscriptions with the match billing schedule. That way, at least the query is only being run when it's really needed, and it's not slowing down the product page load times.

That was exactly the plan! 💯

That start and endpoint could remain the same, and just include the cart/checkout in the middle when needing to prorate.

Yup, I was thinking about this yesterday but wasn't 100% sure -- the reason is that as a dev I'm thinking backwards (wrong): Looking at code and understanding what happens from there. It takes effort to think the other way round: First, imagine what should be happening, and then confirm by looking at the code.

I think that the WCS switching class behaves in a similar way -- when switching, a transaction is only needed when there's something that needs to be paid now.

Re proration, I'm wondering if I could somehow trick WCS to treat this type of "transaction" as a "switch" and let it handle the rest, e.g. first add a line item (same as the "no proration" scenario) first and then trigger a switch. Hmmm.

The UX will likely be different depending on whether the flow includes proration or not

True, true -- I was mainly referring to the single-product page UX, as otherwise I'm not planning to introduce any new flows compared to what's already built in WCS.

[manospsyx]

select their own cart subscription start date

reach out to Gabor to ask if it is a feature that is going to be added to that plugin

Does it support cart subscriptions?

Funny enough, I just checked https://shopplugins.com/plugins/toolbox-for-woocommerce-subscriptions/ and it looks like Gabor has already implemented there something very similar to what we are discussing in this issue.

Some differences compared to what I'm thinking here vs what I see there:

• I was not planning to allow products without any Subscription Schemes to be added to an existing subscription.
• When clicking "Add to Subscription", the user should see only Subs with a billing schedule matching the billing schedule chosen for the currently viewed SATT product.
• Same as above in the cart page for the "Cart Subs" feature.

[manospsyx]

Some differences compared to what I'm thinking here vs what I see there:

Also --

• None of this should be visible IMO until the user has clicked an "Add to subscription" a element, which will pull the necessary data via AJAX. We already discussed a technical reason (speed), but for me the primary one is that showing these UI elements only if needed results in a cleaner UX.

[javorszky]

Hi @danielbair ,

Allowing people to select their cart start date is something I achieved previously as a dynamic trial plugin. I can make that part of the Toolbox plugin, it looks like a common enough request. This was asked in the WC Community Slack yesterday as well. :) Give me until next week Monday.

[javorszky]

@franticpsyx / @thenbrent if y'all like, I can add you to the repository for the plugin.

[manospsyx]

@javorszky that would be awesome, thanks!

I was really tempted to get some inspiration from your work considering your experience with WCS. Did you deal with proration there?

[javorszky]

No... assuming that's for changing schedule, I just ... change the schedule (but don't move the end date at the moment, that's a known bug) :) I'll add you to it, bear with me.

[thenbrent]

I was really tempted to get some inspiration from your work considering your experience with WCS.

An even better idea might be to build on top of the existing code within Toolbox to implement support for this through it, instead of having one form of it available in SATT for some product types, and another form available in Toolbox for other product types.

I'll let you make the call on that @franticpsyx, but personally, I prefer to avoid having similar/duplicate functionality in different plugins. It can make it confusing for store owners to know which plugin they need (i.e. we'd need to say "you need Toolbox if you want Add to Subscription feature for simple products, or SATT if you want Add to Subscription for Bundles etc.).

It also allows us to work on other features, making the total pool of functionality available to Subscriptions store owners larger.

And finally it helps make Toolbox more commercial viable by making it more popular, which hopefully allows @javorszky to continue to invest in maintaining it and adding other features (like the custom start date!), again boosting the total functionality available for Subscriptions.

I'm sure you already see all of these benefits @franticpsyx, but thought I'd elaborate on my views. 🙂

Re proration, I'm wondering if I could somehow trick WCS to treat this type of "transaction" as a "switch" and let it handle the rest

That would absolutely be the way to handle it. The problem at the moment is that Switching/proration is really not well designed, and not extensible.

We have plans to change that, see https://github.com/Prospress/woocommerce-subscriptions/issues/2452, but for now, all that proration logic is hidden within the very rigid WC_Subscriptions_Switcher::calculate_prorated_totals() method, which hardcodes things like the 'subscription_switch' cart item meta key, and even the use of Switch settings for whether items should be prorated.

That means that either needs to be refactored before it can be usable for other cases, like this.

I believe @LCmry is already looking into it, and given these cases, we might be able to prioritise that work to release in v2.4.

it looks like a common enough request

@javorszky it's definitely a popular request: http://ideas.woocommerce.com/forums/133476-woocommerce/suggestions/6663831-delay-start-of-subscription

But it's not on our roadmap. We'd gladly send people to Toolbox to get access to that feature once you build it (both via support when folks ask, but also in docs etc.) like we do with some of the other features of Toolbox.

We may eventually need to add it to Subscriptions core, because it's a needed for other mini-addons (like Gifting, but we don't have plans for that happening yet.

[javorszky]

@thenbrent thanks for the ideas link.

I have no problems with transferring that functionality to Subs core at a later date. Software evolves, and users' ease is more important than individual pieces of software. I've also added you to the repository in case you need to compare things with it.

[manospsyx]

I prefer to avoid having similar/duplicate functionality in different plugins. It can make it confusing for store owners to know which plugin they need (i.e. we'd need to say "you need Toolbox if you want Add to Subscription feature for simple products, or SATT if you want Add to Subscription for Bundles etc.).

It also allows us to work on other features, making the total pool of functionality available to Subscriptions store owners larger.

Βeen thinking about these ideas too, especially as we are short on time and SATT is not funding its own development just yet.

Looking at Gabor's work from a user's perspective and comparing that against what I have in mind for SATT my initial reaction was that the subscription management features are similar in nature:

• "delete" (already built in WCS);
• "add";
• "edit".

SATT is 3 different things:

1) A new way to create subscriptions that's decoupled from product type. 2) A compatibility layer for custom product types such as bundles / composites. 3) Cart subscriptions.

(2) and (3) are features that derive directly from (1) -- as an analogy, if you want to build a saw you better want to cut something with it, otherwise build something else.

On the other hand, Gabor's Toolbox builds upon WCS 2.0 infrastructure to do some very cool things related with manipulating/managing Subscriptions.

However, the management features we have on the SATT roadmap are tightly coupled with the idea of attaching subscription schemes to products/carts. Because the starting point is different, the final "spec" of what "adding/editing" means is going to differ as well.

In addition to this, for me the "holy grail" of SATT has always been to come up with a solution for the most common Product Bundles + WCS feature request: "Editable Subscrib-able Bundles/Composites". This has pretty much defined the way I see the project from its start:

1. Helpful for SomewhereWarm customers (self-interest, in a way).
2. Helpful for WCS customers (a good excuse to dig into the project deeply and work with Prospress).
3. Helpful for the WooCommerce platform (giving back while making seemingly advanced/tough functionality accessible to all).

This issue is simply another milestone on the way there.

For these reasons there's some strong incentive in my mind to get this thing as close to completion as possible, rather than leave it in a half-finished state and start redirecting users/customers to yet another piece of code to complete the puzzle. Strictly from a user's perspective, I believe we should do better than expect someone to talk to 4 different teams/developers (WooCommerce, Prospress, SW, Gabor) in order to get a single feature to work.

Most of the features we've worked on so far proved to be little more than a thin layer sitting on top of WCS. I'm tempted to use the word "easy" -- my point being that it would be a real pity not to finish this because the time investment needed to get this out there is too little compared to the impact.

If I had to guess I'd say that @javorszky (or any other developer other than myself) doesn't have the same incentive to build/maintain the PB/CP management features discussed in #222 . But if we are to get SATT there, we need to pass through here.

[thenbrent]

That all sounds like solid reasoning. 👍

Because the starting point is different, the final "spec" of what "adding/editing" means is going to differ as well.

Makes sense. Especially given the complexity of Bundles.

get this thing as close to completion as possible, rather than leave it in a half-finished state and start redirecting users/customers to yet another piece of code to complete the puzzle. Strictly from a user's perspective, I believe we should do better than expect someone to talk to 4 different teams/developers (WooCommerce, Prospress, SW, Gabor) in order to get a single feature to work

👍

[manospsyx]

The best approach would be to use wcs_get_subscriptions() with a 'subscription_status' and 'meta_query' for '_billing_period' and '_billing_interval' (that should be future proof, albeit not the most obvious way to do it).

I took a step back as soon as I realized we'd be dealing with a triple join here. A single user can't possibly have too many subscriptions, but a shop can very well have thousands.

So a more scalable approach would be to get all subscriptions of the current customer, and filter them to match the billing period+interval we want in PHP.

Will have some functional single-product page code later today -- took me a while to come up with a clean flow for this and write the JS. Let's review it in the PR later. Back on the server-side for now :)

[manospsyx]

@javorszky @thenbrent Ever got any requests to introduce an editable "Friendy Name" field for Subscriptions?

This would be a nice feature to have in Toolbox, especially if you regard it within this context.

Right now customers only see a number, some billing details and the next renewal date. But this is not enough. If a subscription is manage-able and its contents change-able by customers, then we need to let users assign a friendly name to each subscription they have, e.g. "Friday's Basket", "Office Stuff", or "Booze".

Does this ring a bell? Any store owners requested this in the past?

[javorszky]

Sort of. I had a client who had 4 different variations of the product:

Once on Friday, Once on Wednesday Every Friday Every Wednesday

These were terms of a custom attribute which they used to display the name of the product as well. That said another client wants an editable product name field as well mostly because they have many different variations where only one of them is active at any given time, but they are essentially the same (a sample pack, but the contents are different based on season).

That said I've added it to the ideas board for myself. Thank you :)

[thenbrent]

I’ve seen one or two requests for it over the years.

A far more common request is to display the product line item name if/when there is only one product, see https://github.com/woocommerce/woocommerce-subscriptions/issues/437

That wouldn’t solve the issue here unless some kind of “canonical product name” option was available where the store owner could choose which product name represents the bundle/subscription name when there is more than one product line item, and then that gets displayed when referring to the subscription.

[manospsyx]

Because the starting point is different, the final "spec" of what "adding/editing" means is going to differ as well.

Jumping straight to the implementation bit here:

https://cl.ly/2n3v3X133j09

After looking at what @javorszky did in Toolbox, it appears that the flow he had in mind is more suitable as an extra layer of functionality on top of the Cart Subscriptions feature we have in SATT:

• Customer already has one or more Cart Subscriptions active.
• Customer wants to add a product to one of them, regardless of whether subscription schemes exist on that product.

The cool thing about this is that it can be made to work with any product -- of any type, as long as there's a list of active subscriptions associated with that customer.

In contrast, the spec I had in mind for the single-product page is more strict/specific in scope. By default, a customer should be able to add a product to an existing subscription (from the single-product page) when:

• The product has subscription schemes.
• The billing details of the "target" subscription match the chosen subscription scheme in the single product page.

@thenbrent you'll notice in https://cl.ly/2n3v3X133j09 that the UI is more in line with what customers see under My Account > Subscriptions. It actually re-uses that WCS template, but with some modifications.

1. First, note that the "Add to subscription" button/link needs to be clicked to get anything to load. So initially, we're starting with something that's as non-intrusive as possible. It's up for debating whether the style or location of that element is optimal.

2. For most applications, I assumed it would be preferable to give the user an overview of all subscriptions, rather than list them in a dropdown. I don't have data to back this up, but as a user I'd like to be able to see what's inside each listed subscription by clicking a View button. A solution similar to the My Account > Subscriptions list makes it possible to include more information -- possibly also a "friendly name" next to the ID?

@thenbrent - any feedback would be appreciated here.

The plan is to introduce an additional flow that's meant to be used with the Cart Subscriptions feature -- the idea is that products that don't have any subscription schemes can be added to existing Subscriptions using a similar UI in the cart page, right under the Cart Subscription options.

Of course, developers should be able to tweak the code to make it possible to add any product to any subscription from the single-product page (even products without sub schemes), but generally speaking this spec allows both SATT and the Toolbox plugins to co-exist and is perfectly in line with how I imagined this to work initially.

[javorszky]

@franticpsyx I've also made it so that it's filterable, so if someone wants to make sure that they can only add subscription products to existing subscriptions that match the interval / period / length, they can do that too.

[manospsyx]

I’ve seen one or two requests for it over the years.

Probably makes sense, because this only becomes necessary when the user needs to manage their subscriptions, e.g. quickly add a product to an existing subscription.

Let's say I've got a weekly delivery of booze on Fridays and another weekly delivery of food on Mondays. Now say I want to add an item to one of them -- now that you've seen Gabor's solution and https://cl.ly/2n3v3X133j09 -- wouldn't it help a lot if I could identify these two subscriptions by a friendly name?

It probably makes little sense to add this feature in WCS, but considering what we are doing here I think I'd prefer to see a "friendly name" over a number/ID.

[thenbrent]

Jumping straight to the implementation bit here: https://cl.ly/2n3v3X133j09

That is beautiful. Performant, simple and unobtrusive. Available when folks are looking for it, and not in the faces of folks who aren't.

First, note that the "Add to subscription" button/link needs to be clicked to get anything to load.

❤️ 👏

It's up for debating whether the style or location of that element is optimal.

It makes sense to me intuitively. Store owners will tell us if it doesn't.

possibly also a "friendly name" next to the ID?

Given the importance of that here, we could look at prioritising https://github.com/woocommerce/woocommerce-subscriptions/issues/437

Alternatively, SATT could use the 'woocommerce_my_subscriptions_after_subscription_id' hook to display the friendly name.

Of course, developers should be able to tweak the code to make it possible to add any product to any subscription from the single-product page (even products without sub schemes), but generally speaking this spec allows both SATT and the Toolbox plugins to co-exist and is perfectly in line with how I imagined this to work initially.

Wonderful. I love everything I've seen from in the gif and your description. You've nailed it.

It probably makes little sense to add this feature in WCS

It makes sense as long as we're using the product name, not if it's an editable field added elsewhere to allow the name to be anything (like on the WooCommerce > Edit Subscription screen).

The 'woocommerce_my_subscriptions_after_subscription_id' filter is already available for this purpose (I think including the ID is important, rather than replacing it) so there's no reason we can't add it to SATT now, and iterate on that then migrate that into Subscriptions core later.

considering what we are doing here I think I'd prefer to see a "friendly name" over a number/ID.

How do you feel about using a "canonical" product approach where a store owner can choose on the WooCommerce > Edit Product screen if a product should be used as the "friendly name" on subscriptions on which it is a line item.

The only gotchas I see with that:

1. if there is no "canonical product" on the subscription, we still need to select a product name, which is easy when there is only one line item, but tricky when there is 2 or more (would it just be the first line item on the subscription, that's pretty random)
2. if there is more than one canonical product on the subscription, which is the canonical? We could avoid this by using priorities, but that gets complicated...
3. do we use the product's current canonical state? That would allow it to be set/changed on existing subscriptions, but it breaks the typical state of a subscription, which should be a snapshot and used for all its data to avoid issues with other data changing, like the product being deleted.

[manospsyx]

How do you feel about using a "canonical" product approach where a store owner can choose on the WooCommerce > Edit Product screen if a product should be used as the "friendly name" on subscriptions on which it is a line item.

The "general problem": Store Owners are likely to need something more than an ID to easily identify Subscriptions.

This is a subset of the general problem in my mind: https://github.com/woocommerce/woocommerce-subscriptions/issues/437

If a Subscription only contains one line item, it does make sense that its "friendly description" should default to the product name without any intervention from the Store Owner.

But looking back at the general problem, I'd be reluctant to display a "user-friendly description" (in its own column or next to the ID) without at least giving store owners a way to add one to those Subscriptions containing more than one line item.

In other words, if we recognize that a friendly name is useful for identifying subscriptions in some use cases, we could close the specific problem (https://github.com/woocommerce/woocommerce-subscriptions/issues/437) by working on a solution to the general one.

On to this:

It makes sense as long as we're using the product name, not if it's an editable field added elsewhere to allow the name to be anything (like on the WooCommerce > Edit Subscription screen).

I think the only solution to the general problem would be to have an editable field somewhere. That would be a niche feature that could be left out of the WCS picture. SATT might be a good place to add this.

So back to this:

How do you feel about using a "canonical" product approach where a store owner can choose on the WooCommerce > Edit Product screen if a product should be used as the "friendly name" on subscriptions on which it is a line item.

Reversing the question -- if we assume that an editable field for this purpose existed in SATT, would you be happy to close https://github.com/woocommerce/woocommerce-subscriptions/issues/437 and point store owners to SATT?

Or would you still consider that issue as something that must be solved in WCS?

[manospsyx]

Note to self:

When searching for Subscriptions matching a chosen scheme that's synced, we should only return Subscriptions that ~are synced to~ renew on the same schedule. The opposite is not necessary though: If an existing active subscription is synced, then we should be able to add a product to it as long as the chosen scheme (period, interval) matches the billing details of the subscription.

[manospsyx]

With 553b97610149682c6d3e77c6703669bcc80c93f5 all work related with subscriptions management (add/switch) has been refactored in modules (add/switch).

We need to keep things neatly separated here as there's a good chance we'll need to shuffle lots of things in/out of SATT in the future.

The 2.0 class structure already mixes cart-subscriptions functionality with core SATT functionality, which I don't particularly like. It should be straightforward to break cart-subs functionality into a standalone module, but I'll leave this out of the picture for now and focus on keeping everything we add into SATT v2.1 as cleanly separated as possible -- including this.

[manospsyx]

^ Wormhole alert. Don't think there's an easy solution for this.

@javorszky I noticed you don't touch shipping at all when adding a new item to an existing subscription, which should work decently enough when shipping costs are flat / per-order.

I never liked how the WC Shipping API is totally disconnected from the domain of orders and only works correctly when there's a cart somewhere.

Would be nice if there was a unified WC Shipping Package API with its own objects and methods that carried on to orders -- one that could be used in order to recalculate shipping costs even when changing order contents. Oh well.

[javorszky]

@franticpsyx yeah... I had a client who needs to recalculate shipping on an as-needed basis, which I did, and I wrote this about my experiences: https://javorszky.co.uk/2017/03/11/the-curious-case-of-woocommerce-shipping-and-the-hackiest-code-ive-ever-written/

tldr; you need to do a LOT of things that are super hacky :( oh, and don't forget to strip the cookies when you recalculate shipping automatically

[javorszky]

Plus there's the added complexity of what happens when the weight now pushes shipping into an entirely different tier, and it becomes a lot more expensive, or there are 2 choices (fast and expensive / slow and less expensive). How do you make that choice for the customer?

What happens when no shipping methods will deal with the resulting package?

It's a lot of fun*

Narrator: it wasn't.

[thenbrent]

I think the only solution to the general problem would be to have an editable field somewhere.

How do you see that field working?

My main concern with that approach is that I don't see any good way to do it.

It can't go on the WooCommerce > Edit Subscription screen, because then you'd need store owners to manually set it on every subscription individually (unless you set a default, like the first product line item's name).

You could create a new admin screen that provides a central UI to do it store wide for all products/subscriptions, and set it based on product IDs, and/or perhaps categories of a product, or something else, but that seems unnecessarily complicated.

You could set it on the Edit Product screen, but then again, you have to choose which name to use when a subscription contains multiple products (and you can't just have the customer select from existing names on other products to share that name between products, because what happens if one product is in more than one bundle or group etc.)

if we assume that an editable field for this purpose existed in SATT, would you be happy to close woocommerce/woocommerce-subscriptions#437 and point store owners to SATT?

It will depend on the implementation. I see that feature as being essential for SATT, especially with Bundles, but helpful for all subscriptions, so that would lead me to feel it belongs in core. At least eventually.

Would be nice if there was a unified WC Shipping Package API

These APIs improved a lot in WC 3.2, but I'm not sure if they're quite to the stage where you could pass in order values yet.

[manospsyx]

tldr; you need to do a LOT of things that are super hacky :( oh, and don't forget to strip the cookies when you recalculate shipping automatically

That was an awesome read.

But really, how hard can that be?

Having done a lot of work with the Shipping API I wouldn't even bother to go further down this point:

I can turn my order items into a cart. I know all the details. To replace get_cart I had to mangle some data from $order->get_items().

To do this reliably we'd need to recreate all session/other data used by third-party code to filter cart contents. A close workaround would be to use some of the "re-ordering" logic -- which is pretty much what WCS does to populate a cart from a subscription. The good thing about doing client work is that it usually requires us to solve a sub-set of a general problem. That leaves a lot of room for (creative) hacking.

These APIs improved a lot in WC 3.2, but I'm not sure if they're quite to the stage where you could pass in order values yet.

The best we can get from an order item is a raw product instance. Shipping methods rely on package data to do their thing, which is derived from cart contents after applying the (commonly-used) woocommerce_cart_shipping_packages filter.

If you want to manipulate the physical representation of a cart for shipping purposes, you'd use that filter.

• Want to add an amount of ice to a cart of fish? Use that filter.
• Want to split up a shipment into multiple packages? Same.
• Want to assemble a set of physical items inside a common container that happens to be one of them? Use that filter and aggregate weights/totals.

The only piece of shipping data WC stores in orders is a line item for each package rate along with some (generally useless) metadata.

Most external shipping/fulfillment services, such as Shipstation, use the REST API (or a plugin) and get shipping data by following the Order Item > Product > Weight / Dimensions route, which has nothing to do with what shipping package contents might have looked like at checkout.

There is no proper equivalent of WC()->shipping->get_packages() for orders. Once an order is created, shipping package data is lost.

There's an interesting discussion at https://github.com/woocommerce/woocommerce/pull/17670

[manospsyx]

How do you see that field working?

@thenbrent here's a rough draft: https://cl.ly/1Q0i3v2V3H0Z

The "Update Name" button doesn't need to exist, we could save that field value when the field loses focus.

It can't go on the WooCommerce > Edit Subscription screen, because then you'd need store owners to manually set it on every subscription individually (unless you set a default, like the first product line item's name).

We can default it to the same thing Store Owners see now: A hash followed by a number.

When they change it to something else, they will see that under the Subscription column: https://cl.ly/3r2c1F0m3E0J

[thenbrent]

Oh you've to the customer entering the name. I didn't think of that. That overcomes a lot of the issues I mentioned, but I can see it causing all sorts of gotchas for store owners if it's being displayed to them too (or even if it isn't, like if a customer contacts them asking about a subscription referring to it with the custom name they gave it and only they can see, so the store owner has NFI what they're talking about haha).

I still feel like using one of the product line item's names is a better option. It's a shared and implicitly agreed upon term already.

[manospsyx]

if a customer contacts them asking about a subscription referring to it with the custom name they gave it and only they can see, so the store owner has NFI what they're talking about

🤔 😄

one of the product line item's names

Which of the potentially multiple ones?

Let's give this some time -- it's not a top priority anyway! Opened #253 to circle back to it once we have some feedback and continue the discussion there.

Still got loose ends to deal with before we can call this feature complete:

• [x] If a scheme is synced, match Subscriptions renewing on the same day/date.
• [x] If a scheme has a fixed length, match Subscriptions having the same amount of renewals left.
• [x] Disable add-to-sub when a scheme is prorated.

Then:

• [x] Find out how to relay product form validation to WC core when clicking "Add".
• [x] Add a line item to the chosen sub and update its totals.

Repeat for cart subscriptions.

[manospsyx]

I think we're pretty much done here.

I'll branch off this bit to a new issue to keep PR #252 manageable:

• [x] Second step: Add support for Cart Subscription schemes as well.

Found a couple price-string-related issues while working here. Opened #259 .

Details in #252 --