[6.2.0] Invalid value for paymentMethodMessaging.update() when attempting to configure a variable product with the Flatsome theme active

[csmcneill]

Describe the bug

When using the Flatsome theme while WooPayments 6.2.0 is active, variable products cannot be added to the cart. Doing so produces an error notice when adding the product to the cart:

Please select some product options before adding this product to your cart.

After selecting all available variables—but before attempting to add the product to the cart—a JavaScript error is thrown in the console:

Uncaught IntegrationError: Invalid value for paymentMethodMessaging.update(): amount should be a positive amount in the currency's subunit. You specified: NaN.
    at ne (?ver=3.0:1:144524)
    at re (?ver=3.0:1:144596)
    at ?ver=3.0:1:186667
    at et (?ver=3.0:1:186693)
    at Object.update (?ver=3.0:1:217483)
    at t.<anonymous> (?ver=3.0:1:277609)
    at t.update (?ver=3.0:1:64872)
    at HTMLDivElement.<anonymous> (??-eJyNkMFqAzEMRH+oWqeHJumh9FOCaqmOUtvaWNqY/fvupgQCIVDQRWjmMaM+QtTqXD2MeUpSLcziR+iqUUvhFhm62DGLeUAzdgunZc4Tt3n4k8aehyJ1ONlLf8Tdke4A3+0qo4BE4AoRm8MFm6CL1v/hYMS5LDcLtKYbm9IUHYgdJdsTP/6IFfZwkBpvC9zSPPEk1ZQZ1h9ITQZYCZCuPb4myRSSYwK+rFkWxGf5eN3u33e7zeZt+wu4d4ZI:3:1530)
    at HTMLDivElement.dispatch (jquery.min.js?ver=3.6.4:2:43184)
    at y.handle (jquery.min.js?ver=3.6.4:2:41168)

This error is thrown on selection, and the selection event is not firing as a result.

Reverting to 6.1.1 resolves this issue. Given that reverting resolves the issue and the popularity of Flatsome, I'm opening this issue :)

Note: Reverting to Woo 7.8.0 or disabling multi-currency did not resolve the issue. Changing to a different theme does resolve the issue.

To Reproduce

1. Install/activate Flatsome.
2. Install/activate WooPayments 6.2.0.
3. Create a variable product.
4. Attempt to add the product created in step 3 to the cart.
5. See errors.
6. Revert to WooPayments 6.1.1.
7. Repeat step 4.
8. The product will be successfully added to the cart.

Actual behavior

While WooPayments 6.2.0 and the Flatsome theme are active, customers cannot add variable products to the cart because the selection event is not firing.

Screenshots

Expected behavior

WooPayments 6.2.0 + Flatsome allows variable products to be added to the cart without issue.

Additional context

Discussion: p1689800687243289-slack-C3NCP7ZJ6

Initial reports:
6556641-zen
6556849-zen
6557129-zen

[htdat]

Sounds like this commit is relevant as it's touching the variable product and amount option.
It's also available since 6.2.0 too.

72f1c7d

@nagpai and @Automattic/pulsar - could you have a look?

[nagpai]

Thanks for the report, @csmcneill, and the ping @htdat . This seems related to the PR I had worked on. I will add this to my tasks.

[rw-ye]

Another report: 6568017-zd-woothemes

[nagpai]

I have found the reason it happens. Adding my notes here:

Our script checks the quantity of the product via query selector for CSS class .quantity input. Changing this to .quantity input[type=number] makes it more specific and would mitigate the error. More details:

In case of Flatsome, the first input element within quantity is not the number input but rather the - button. This makes the amount value resolve to NaN and results in the blocking error.

A comparison of the HTML code of Storefront and Flatsome makes this clearer.

Storefront

<div class="quantity">
	<label class="screen-reader-text" for="quantity_64bb564d6432d">Beanie with Logo quantity</label>
	<input type="number" id="quantity_64bb564d6432d" class="input-text qty text" name="quantity" value="1" aria-label="Product quantity" size="4" min="1" max="" step="1" placeholder="" inputmode="numeric" autocomplete="off">
</div>

Flatsome

<div class="quantity buttons_added">
	<input type="button" value="-" class="minus button is-form">
	<label class="screen-reader-text" for="quantity_64bb5784c8eaa">Beanie with Logo quantity</label>
	<input type="number" id="quantity_64bb5784c8eaa" class="input-text qty text" name="quantity" value="1" aria-label="Product quantity" size="4" min="1" max="" step="1" placeholder="" inputmode="numeric" autocomplete="off">
	<input type="button" value="+" class="plus button is-form">
</div>

[nagpai]

The issue revealed another unexpected behavior / area of improvement. The BNPL payment messaging script seems to render even when the associated PM-s are disabled ( Afterpay and Affirm, at the moment ).

I will be addressing this in my upcoming PR too.

[csmcneill]

6569425-zen

[nagpai]

Update - PR is ready and in QA. - #6845

[lynnjat7]

6573310-zen

[EdithAllison]

The same error affects the Salient theme. Rolling back to 6.1.1 fixes the error.

[lynnjat7]

6589875-zen

[csmcneill]

https://wordpress.org/support/topic/recent-update-broke-my-store/

[kalessil]

Update: While the fix is to be released yet, we can disable BNPLs feature flag for the affected merchants on our end. They'll be able to resume operations.

[mgozdis]

Another user report: 6603804
Downgraded to 6.1.1

[tvolpert]

another report in 6603332-zen
user had already downgraded to 6.1.1 before contacting us

[csmcneill]

6608784-zen was able to resolve this by setting bnpl_affirm_afterpay_enabled to 0—thanks @kalessil for the suggestion!

[sarbouw]

6599613-zen

[mgozdis]

Another user report here and downgraded to 6.1.1
6618899-zen

[csmcneill]

6579755-zen reported this, but they're using the Enfold theme.

Set bnpl_affirm_afterpay_enabled to 0.

[csmcneill]

@EdithAllison This issue was resolved in version 6.3.0 of WooPayments, which was released pretty recently.

If this doesn't resolve the issue, then Please contact us at WooCommerce.com > My Account > Support. You may need to create an account before you can access that page.

Please include a link to this issue so that we can keep track of what's already been done.

We will be able to help you further there.

[WillBrubaker]

I've got 6720292-zen on version 6.3.2 and still experiencing this

[csmcneill]

@WillBrubaker How convinced are we that this issue is affecting that ticket?

One variable product is experiencing this issue while another isn't. Initial assessments of this issue indicated that all variable products were affected. Additionally, setting bnpl_affirm_afterpay_enabled to 0 via MC doesn't resolve the issue, but it did for all other cases after @kalessil recommended it. This could be a result of caching, so I'm leaving it set to 0 for now while we investigate further.

I've added links to the particulars in 6720292-zen in case you or @nagpai want to dig into this a bit more.

[nicdwilson]

Hi @csmcneill @WillBrubaker @nagpai

6720292-zd-a8c raises the same issue in a different way. The quantity in this page has been removed altogether by the merchant using a page builder, a different but not unusual situation. It highlights how we need a fallback if we are going to be relying on the presence of HTML elements on the page.

[csmcneill]

If the issue is a result of the user hiding the quantity option, then I would suggest that this warrants a new issue, as it would require different replication criteria.

[kalessil]

@nicdwilson

The quantity on this page has been removed altogether by the merchant using a page builder, a different but not unusual situation. It highlights how we need a fallback if we are going to be relying on the presence of HTML elements on the page.

Out of curiosity, why are merchants hiding quantity fields (what's the business use case there)?
We'll look into addressing of course, but we need to better understand context here.

[mgascam]

@kalessil sharing my findings:

1. We need to harden the script, to protect it from errors related to missing or altered elements in the DOM. I'm addressing this in the pull request Fix invalid value error for paymentMethodMessaging in product details page #7153. I suggest including this fix in the next release.
2. Using the workaround of setting bnpl_affirm_afterpay_enabled to 0 will no longer be effective once the closed beta concludes, as we plan to remove this feature flag. Instead, I recommend advising affected merchants to disable Affirm and Afterpay via WP Admin > Payments > Settings until we release the fix. cc: @csmcneill @WillBrubaker @nicdwilson. Downgrading to version 6.1.1 is also a viable option.
3. I've also investigated the comment by Chris:

Additionally, setting bnpl_affirm_afterpay_enabled to 0 via MC doesn't resolve the issue

We have this logic to inject the script only when the feature is enabled, based on the value of the bnpl_affirm_afterpay_enabled. This flag comes from the server and gets cached in the plugin. I reviewed the links of affected products in 6720292-zd-a8c but can't reproduce the issue currently. I also checked that the script is not loaded in any of the affected products (notice that the Affirm and Afterpay site messaging is no longer shown). This leads me to believe that the cached value of the bnpl_affirm_afterpay_enabled was not refreshed.

Let me know if you have any further questions or need clarification

[kalessil]

Thanks for looking @mgascam and pinging the folks, IMO hardening the logic is the way to go.
If the updated logic will cause new issues, disabling Affirm/Afterpay in settings sounds like a good option.