When editing an MnM variable subscription, the wrong/old/cached selections & quantities re-appear

[limist]

@helgatheviking To reproduce: When configuring a MnM variable subscription, e.g. say our test server's subscription bundle and then choose some quantities different from the pre-sets (e.g. 3 of the first product, none of the 2nd and 3rd). Then checkout and purchase as usual.

Then on the Thank You page, click on the bottom link to see the new subscription.

Once on the My Account > view-subscription page, confirm the quantities match your previously selected quantities. Then click the blue "Update bundle" button; the problem is seen at that point: the wrong quantities. Perhaps they're being pulled from a hardcoded selection?

[helgatheviking]

Well I guess I should have predicted this. The output of the template is being cached to help with the performance, but as you have found, when editing you would need the order-specific quantities. This is a bit of a quandry as we wouldn't want to clear the cache and undo the performance boost. (this will also be a problem if you try to serve custom URL params as they won't be updated in the cache until the product is re-saved)

[helgatheviking]

Closed by kathyisawesome/wc-mnm-variable@bead86a 🤞

[limist]

@helgatheviking Thanks for the fix; I'm testing it now, and found what looks to be a related bug:

• After buying a subscription & variable MNM product, go to the corresponding view-subscription page
• Click on the button Update Bundle
• Zero out one product that had at least quantity=1, while increasing another product's quantity to 2 (or higher), to get back to the minimum bundle size/quantity (e.g. 20 items)
• Click the Update bundle to save the new selections
• Once the view-subscription page refreshes, the zeroed-out item should no longer be listed under the "Update Bundle" button, as expected. And the higher quantity item should also display the updated correct count.
• But, if you now click Update Bundle again, you'll see the original pre-zeroed-out quantity for the item, and the Mobile Styles counter will also be too high, e.g. 21/20 items. If you again zero-out the item, click update, you'll be back to the same issue: the item seems to be removed, but still the incorrect original quantity will be shown, like a 1.

My guess is that the new JS only updates the non-zero values, and leaves the cached values in place for the zero-quantity items; if so, it also needs to set to zero any zero-quantity items the JS pulls for the user's configuration.

[limist]

@helgatheviking Further testing notes:

• After saving and then trying to update the subscription again, if 2 or more items were zeroed out previously, I see something like "22/20 items" in the Mobile Styles footer, in addition to the incorrect previous non-zero quantities (before the 1st save/update was done above).
  • Furthermore, trying to click on the -/decrement buttons doesn't work; when I try to do so, I see the red alert "Container limited to 20" tooltip.
  • If I then change the variation to a larger one, the decrement buttons work again.
  • But in the larger variation, if I decrement down to the previous variation limit, e.g. to 20 items, and then select that smaller variation, then the items quantity is correct, however the "Update Subscription" button remains greyed out in the Mobile Styles footer, and I can't save the now-correct quantities.

[helgatheviking]

@limist rc 12 made some progress on always setting the quantities via JS... including setting them back to null when there is nothing set for them in the GET or in the subscription order (which also uses GET at it's root).

In addition to your reported issue, I'd also seen the wrong values prefilled on the single product page if I cleared out the bundle templates (note: I added a snippet with a button for that in the admin toolbar on your site) and then loaded a subscription to edit.

In my tests rc 12 fixes both of these issues. Let me know if it does for you.

--

An overfilled bundle is a problem to be addressed in MNM core. I have seen that issue before and couldn't figure it out so tried to make it really hard to get into that error state... I still see your issue when downsizing the variation in the my account area so that's not fixed today.

---

[helgatheviking]

@limist is this still an issue?