Closed csmcneill closed 1 year ago
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.
https://github.com/Automattic/woocommerce-payments/commit/72f1c7dd1ca4b2bca710a88306f9bf04bdea35e5
@nagpai and @Automattic/pulsar - could you have a look?
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.
Another report: 6568017-zd-woothemes
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.
<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>
<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>
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.
6569425-zen
Update - PR is ready and in QA. - #6845
6573310-zen
The same error affects the Salient theme. Rolling back to 6.1.1 fixes the error.
6589875-zen
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.
another report in 6603332-zen user had already downgraded to 6.1.1 before contacting us
6608784-zen was able to resolve this by setting bnpl_affirm_afterpay_enabled
to 0
—thanks @kalessil for the suggestion!
6599613-zen
Another user report here and downgraded to 6.1.1 6618899-zen
6579755-zen reported this, but they're using the Enfold theme.
Set bnpl_affirm_afterpay_enabled
to 0
.
@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.
I've got 6720292-zen on version 6.3.2 and still experiencing this
@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.
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.
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.
@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.
@kalessil sharing my findings:
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.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
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.
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:
After selecting all available variables—but before attempting to add the product to the cart—a JavaScript error is thrown in the console:
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
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