thanks page changed
-
Hi,
we have the problem that the thank you page is only visible with a password.
as soon as you disable the plugin everything works fine.
how can we solve this problem ?
https://dev.tantra-yoga-art.de/
best regards
Daniel
-
Hi @virtual03
The thank you page being restricted by a password would not be related in any way to our plugin. There is no code in this plugin that restricts access to any frontend pages.
It’s possible you have some plugin enabled that requires you to register the payment methods with it to expose the thank you page to guest users.
I can see in your screenshot that the thank you page url is correct, which is where the Stripe plugin’s involvement ends. The Stripe plugin uses the WooCommerce provided
WC_Payment_Gateway::get_return_url
to retrieve the thank you page url and then WooCommerce redirects the user to that page.I recommend reviewing your full list of active plugins and verifying if they have any options related to restricting the thank you page.
Kind Regards
Hi,
ok thanks for your tip.
it was actually another plugin.
best regards
DanielHi Mattis,
it was following plugin, i removed it but we could contact the provider to solve the problem.
https://wordpress.org/plugins/woo-save-abandoned-carts/
best regards
DanielHi!
CartBounty does not have any limitations or functionality when it comes to showing or hiding access to WooCommerce Thank you page. This has never been seen or heard so it should be some other plugin that is causing this issue.
Hello @virtual03
Thank you, I also have CartBounty plugin installed, and issue does not appear when it is deactivated. But it also seems to be related to Elementor pro plugin. When CartBounty plugin is activated with Gutenberg editor instead of Elementor pro, issue is not there…
Are also using Elementor pro? (I have open a ticket with elementor support, they are currently looking at it)
Thanks
Hi, just wanted to add some additional note from our side.
CartBounty does not really have any direct links or hooks with WooCommerce thank you page. The closest link that we have to this page is when the order is placed and
woocommerce_new_order
hook is fired. At this point CartBounty takes care of removing its previously saved abandoned cart. There is nothing that could be even closely related with be adding some password protection to Thank you page.You could try leaving WooCommerce, CartBounty and Stripe plugins active, switch to some default Storefront theme and run a test then.
Also it would be good to check if there are maybe any errors in the log files that may provide some valuable information as to what might be causing this behavior.
Hi,
I found out that the problem is with the woocommerce plugin.
i hope it will be fixed soon.
best regards
DanielHello @virtual03
Indeed issue appears since Woocommerce 7.8 (issue is not there with version 7.7.X)
But are you using Elementor as well?
Thanks
Hi Mattis,
No, I have never installed Elementor on the site.
Best regards
DanielI rolled back this commit: https://github.com/woocommerce/woocommerce/commit/1cd947a32064bf3b716521110eae2856711ab775
in the file
/plugins/woocommerce/includes/shortcodes/class-wc-shortcode-checkout.php
in my installation, and it solved the problem.Hello @mrclayton
We went through additional testing / debugging with Cartbounty support team and it seems that the following lines impact this issue where guest customers are requested to log-in on order confirmation page (after order is paid).
In file woo-stripe-payment\includes\class-stripe.php, from lines 428 to 430
if ( ! did_action( 'before_woocommerce_init' ) ) { return false; }
When these lines are commented, the issue does not happen anymore. But what is confusing is that this issue is happening since Woocommerce did the following commit > https://github.com/woocommerce/woocommerce/commit/1cd947a32064bf3b716521110eae2856711ab775
Is this hook triggered from lines 428 to 430 is mandatory to be triggered on order confirmation page? (as it seems to handle fields on checkout page).
Thank you for your support (FYI when the other Stripe plugin is activated instead the issue does not happen as well).
We went through additional testing / debugging with Cartbounty support team and it seems that the following lines impact this issue where guest customers are requested to log-in on order confirmation page (after order is paid).
Can you provide some insight into how the Cartbounty folks came to that conclusion? I am skeptical that line of code would have any downstream affect because it’s only called once throughout the plugin and that’s to setup the frontend script manager which loads the checkout page scripts.
Is this hook triggered from lines 428 to 430 is mandatory to be triggered on order confirmation page? (as it seems to handle fields on checkout page).
No, the function
is_request
has one purpose and that’s to determine if the script manager should be instantiated.You can see in this line of WooCommerce code that they are performing an email verification before the thank you page is rendered. That’s the logic that’s controlling the rendering of that email verification html that you’re seeing. The Stripe plugin isn’t involved in that logic.
You can view WooCommerce’s logic for that function here. So for some reason, the logic is determining that the email address associated with the guest user’s order is not matching the value in the $_POST object and therefore requires verification.
You could just use the provided filter
woocommerce_order_email_verification_required
and stop that behavior all together.Example:
add_filter('woocommerce_order_email_verification_required', '__return_false');
Kind Regards
Hi @mrclayton, this is Nauris from CartBounty. Just wanted to provide additional details about the issue above.
CartBounty has a function that restores input fields on Checkout page. If you have entered them in the form, you can browse other store pages, return back to the Checkout page and your previous input fields will be restored. This function is hooked into default WooCommerce
woocommerce_checkout_fields
hook which should only be called on WooCommerce Checkout page, however the line that @ecomsight previously posted is causing this hook to fire on Thank you page which in turn creates this issue with authorization.Can you add a conditional check to your plugin’s code to prevent this behavior in the filter
woocommerce_checkout_fields
when theis_checkout()
condition returns false?There are likely other plugins that trigger the
WC_Checkout::get_checkout_fields()
function in a section other than the checkout page that would cause the described issue.Kind Regards,
- The topic ‘thanks page changed’ is closed to new replies.