Additional subscription scheme settings

[manospsyx]

In its current state, the mini-extension is missing the following sub settings from the product-level subscription scheme UI:

• trial length
• trial period
• sign up fee

It's also missing the "Limit Subscription" setting, and the "Synchronise Renewals" setting.

These are obviously important, but since we rely on Subs core for all associated functionality, adding these in should be a trivial matter once everything else gets reviewed.

[thenbrent]

An option for this could be to:

1. add a new "Subscription" meta flag, similar to the Virtual and Downloadable meta flags: https://cloudup.com/crhjci1jz1T
2. when that is checked/unchecked, show/hide the normal subscription pricing fields (replacing the WC core pricing fields): https://cloudup.com/c63z0TS9ApU
3. a variable product can then be used if a the store manager wants to add different recurring options for that product (i.e. using "Billing Period" or "Length" etc. as attributes).

This will also then provide a solution to #2.

I suspect the main downside of this approach will be conflicts with product type specific pricing fields.

[manospsyx]

@thenbrent

I thought quite a bit about this -- as usual, there are multiple "conflicts of interest"...

The process you describe would conflict with a few product types that dont have pricing fields, or show them differently. Then we'd have to support each and every one of them by adding JS hide/show if hacks, and I'd rather avoid falling into that hole.

It's also cool that we already have the ability to attach multiple sub options to products without variations. Not sure how many people will use this feature, but I wanted to avoid a dependency on variations for this.

I tend to imagine the "Subscription" property of a product as something that may or may not exist, on a level other than the one where the product "exists" (that sounded too philosophical).

So it's more like an Add-on, that can be mandatory or optional, and have one or more properties to choose from.

Having to create a variable product with atts just to offer 2 sub alternatives results in a weird UX for the shop manager and for the customer.

Meta flags are ideal when a product property modifies the product data fields, as you said ;) Right now, Subs treats the "Subscription" as a property of a product that separates it from "other" products completely. But if we want to maximize support for other types with the least effort, we'll need to avoid going down that route, even just in terms of admin UX.

Bottom line - the current mini-extension UX is "similar" to the Add-ons UX = a separate tab. One problem with this approach (that I can see at the moment) is that some people tend to think about "Subscription" as a property associated with payment/price. So you can say that it should be "closer" to the pricing fields. Here's a potential future "issue": some people might want to define a separate "price" with every subscription option, and if we add that into the existing UX, it will have to be clear that the price they define there will override the price set in the General tab.

[felipesantana]

I might have some issue with the plugin, there is no "Subscription Option" on the tab "Subscription", I clicked "add option" and nothing happens. Did I miss some configuration? Heres a screenshot and thanks for the plugin, if I can get this working it will save my life ;D

Screenshot: http://cl.ly/image/0e0M1n3F3F1L

[manospsyx]

@felipesantana The issue you are reporting is irrelevant to this thread - please open another one. Also I'm not able to replicate this issue. Please check your browser console for errors, and post your findings in a new ticket. Thanks!

[manospsyx]

Submitted ideas:

• add the possibility for the store manager to set a % discount if the user subscribes to a product
• add sync renewal options

[thenbrent]

add the possibility for the store manager to set a % discount if the user subscribes to a product

Cool, like Amazon's "Subscribe and Save" system (though I think they've trademarked that phrase so we'll need to call it something else).

add sync renewal options

Hopefully we can most of the exiting methods in WC_Subscriptions_Synchroniser to handle this. At very least for the logic to handle everything after the products are made into cart items. To actually sync the subscription options for a product might need a bit more custom code. Although ideally we also use WC_Subscriptions_Synchroniser::subscription_product_fields() to display the sync fields (it will need extra JS to link the sync period with that subscription options chosen billing period though).

[manospsyx]

Cool, like Amazon's "Subscribe and Save" system (though I think they've trademarked that phrase so we'll need to call it something else).

This should already work in the https://github.com/Prospress/woocommerce-subscribe-to-all-the-things/tree/issue-13-patches branch - there are some issues with per-item-priced bundle types and the way their totals show up in the product details page, but other than that, I think we are good.

Will run some more tests when I get back from Cape Town ;)

[manospsyx]

@thenbrent Note we've allowed both the ability to set a % discount and the ability to override the Regular/Sale prices at subscription-scheme level.

[thenbrent]

@franticpsyx 👍 interesting that requests for that come up before requests for other subscription scheme settings, like free trial, sign-up fees etc.

[manospsyx]

@thenbrent Probably related to the use-cases/focus of SATT = selling physical products on an optional subscription basis.

This is the very same reason I thought trials + sign-up fees were a secondary feature for SATT and left them out in v1.

[seb86]

@franticpsyx @thenbrent I'm getting more requests to support this mini extension and recently a couple of clients are wanting to have at least the free trial option available.

Is this something we can work on to add soon or are you both not wanting it just yet?

[manospsyx]

@seb86 Might be a good idea to redirect them here - I'd love to see existing use cases for SATT?

At the moment we are targeting to close most pending issues for v1.1 and then make any adjustments needed for the release. Then, @thenbrent and I were planning to review all issues and see what else we'd like to include in the next release.

I don't think we should rush this for v1.1, but if these features justify another v1.x release, I'm happy to consider working on them next.

Our short/medium term goal is to review the entire mini-extension architecture and make any changes necessary to ensure that long-term development + maintenance will be sustainable + manageable.

Ideally, I'd like to postpone non-essential features after this is finished, since adding more code will only make re-architecting more complex.

[seb86]

@franticpsyx The clients are still building their stores.

This is one of the scenarios they are attempting to achieve for a subscription for men tailored to their needs to shave.

A razor, razor blades and range of daily face wash. Only two products are configurable, the rest are pre-configured in the package. This is done using the "Composite Products" extension.

They want to make the composite product subscribable using this mini-extension but they also want a free trial which is not yet available. Also, the price of the subscription changes depending on the first two variable items the customer can select but that is another issue and most likely to be as another plugin for the client.

My main focus is adding the free trial option. Perhaps you or @thenbrent can provide me a list of the actions and filters needed in order to support this and I will give it ago on a separate branch.

[manospsyx]

This is done using the "Composite Products" extension.

CP support is still pending in the issue-20 branch.

a list of the actions and filters needed in order to support this

Might be a bit of a challenge. You are looking at:

• Displaying + saving the relevant settings.
• Doing some additional product modifications when converting the product to a sub in https://github.com/Prospress/woocommerce-subscribe-all-the-things/blob/master/includes/class-wcsatt-cart.php#L147
• Adding some code to ensure html price strings are generated using modified trial period product properties, depending on the displayed subscription scheme.

Not sure if there might be other challenges along the way.

I would hold off of this until after v1.1, since the issue-20 branch includes some refactoring that I'd rather use as a starting point if I decided to work on this now.

If you develop this as a separate plugin, you'll definitely need a few extra filters in SATT.

On a side-note, it is important to keep in mind that once you start relying on SATT (or even worse, SATT plugins) for live projects, there is a high chance you might end up with a very high maintenance overhead in the medium/long-term, or even worse, a dead end if we fail to provide full backwards compatibility when a non-beta version of SATT arrives (in whatever form that might be).

[seb86]

I would hold off of this until after v1.1, since the issue-20 branch includes some refactoring that I'd rather use as a starting point if I decided to work on this now.

Are you making more adjustments this week then?

I have yet to try but we may need to provide the option to not override the price on a subscription option so that the configured price based on what the customer has chosen on a "Composite Product" is what they pay.

If you develop this as a separate plugin, you'll definitely need a few extra filters in SATT.

Could you add filters on the returning data such as this one: https://github.com/Prospress/woocommerce-subscribe-all-the-things/blob/master/includes/class-wcsatt-cart.php#L171

I understand if there are significant changes made to the SATT extension that the client will come to me for maintenance should they upgrade but I will inform them not to for the time being.

[manospsyx]

Are you making more adjustments this week then?

I think so, yes. I was hoping to find some time to work on full Composite Products support this week.

I have yet to try but we may need to provide the option to not override the price on a subscription option so that the configured price based on what the customer has chosen on a "Composite Product" is what they pay.

Of course. The "composited" items prices should not be overridden when the "Override Price" option is used. This should only affect the Base Price of the container item. On the other hand, the "Discount" option will affect all cart items.

Could you add filters on the returning data such as this one:

If @thenbrent agrees, I would suggest doing this as follows:

• code your plugin, adding filters where you need them as you move along
• when you are done, open an issue / PR with the filters you added (PR to master)

This will ensure that we'll only be adding something once you are 100% certain you'll make use of it. By the time you are done, we should have finished with issue-20, as well.

[seb86]

OK @franticpsyx That sounds like a solid plan.

[thenbrent]

I would suggest doing this as follows:

Yep, sounds good.

This will ensure that we'll only be adding something once you are 100% certain you'll make use of it. By the time you are done, we should have finished with issue-20, as well.

It also means the functionality should be discrete, so we can keep it separate if/when it is merged into core rather than pilling more functionality onto existing functions/classes.

[buckneri]

The frequency setting for monthly/daily/yearly doesn't make sense.

When you set Monthly it tallies the price and sets it to a monthly payment.
Yearly should do the same and multiply by 12 instead it just charges the same amount once per year.

This may be the designed functionality, but i'm at a loss for what product you would sell for $50/month but give the customer the option to only pay $50 per year($5/month) for the same thing. (services for example, would be monthly but give a discount for annual payment, but that annual payment would not be less than monthly it would be monthly x 12 - discount)

[thenbrent]

@buckneri please open a new issue for raising new issues like that. You can open a new issue here: https://github.com/Prospress/woocommerce-subscribe-all-the-things/issues/new

I've gone ahead and opened a new one to address this: #46

[seb86]

@franticpsyx and @thenbrent I have added filters that I require for my extension. I don't think I will need any others at this point. Let me know if you have any issues.

[seb86]

@franticpsyx and @thenbrent I have added you both as collaborators for the extension I have developed for this extension. I only seem to have one issue which I have not been able to figure out.

Would you mind spending a few minutes testing out what I may have missed?

[seb86]

@franticpsyx and @thenbrent I have added two new filters for the lowest subscription scheme option.

[seb86]

It's also missing the "Limit Subscription" setting, and the "Synchronise Renewals" setting.

@franticpsyx, @thenbrent Is this next?

[manospsyx]

@seb86 Noap - we'll be reviewing the SATT architecture before working on new features. See #42 - we need to somehow merge all the scattered logic in one place and provide a more centralized way (OO) to manage the subscription "state" of a product. :)

[seb86]

Here is a working example of synchronising subscriptions with SATT currently in development. Was created for another client.

[manospsyx]

Let's break this down into smaller issues and tackle them one by one.

[manospsyx]

We'll be breaking this down in smaller chunks. See https://github.com/Prospress/woocommerce-subscribe-all-the-things/wiki/Roadmap