BTI-1229 Fix: Prevent adding a Buckaroo error twice to wc_add_notice() in classic/legacy layouts - #521
Conversation
…ssic/legacy layouts
|
Hi @janveldhuis , Thank you for creating the PR and sharing the proposed solution. We’ll keep you updated once we have any further feedback or an update from our side. |
displayBuckarooErrors() is already registered on template_redirect, which always runs before woocommerce_review_order_before_payment on a checkout render. The direct call in idinCheckout(), left behind by 64ac874 when the logic moved out of that method, queued the notice a second time after wc_print_notices() had already flushed and cleared the queue. The duplicate stayed in the WC session and surfaced in the next update_order_review response, turning it into a failure and redrawing the cart with a stale error. Removing the call fixes the duplicate at the source, so the error_notice_added flag guarding against it is no longer needed.
|
@janveldhuis Thanks for digging this one out, the duplicate notice is real and your read on the ajax path matches what I traced. I pushed a commit on top instead of asking you to redo it. Rather than guarding with a flag, I removed the displayBuckarooErrors() call from idinCheckout(). That call is a leftover from 64ac874, which moved the logic onto template_redirect but left the direct call behind. template_redirect always runs before woocommerce_review_order_before_payment on a checkout render, and payment.php wraps that action in a !wp_doing_ajax() check, so the direct call could only ever queue the second copy, never the first. Same fix, one line deleted instead of eleven added. On the earlier red build: the blank line after the class opening brace tripped PSR12 in the PHPCS job. That is gone now. |
displayBuckarooErrors() can be called twice via template_redirect and idinCheckout, if the $_GET['bck_err'] is present an error wc_add_notice() is added twice, if that 2nd error is not rendered on page, it can be passed via ajax, redrawing the woocommerce cart