pixelyzed

Hello, as requested, I also opened a ticket on your site.

Thank you!

Hi there! Thanks for the reply!

That setting has been checked all along so that’s not it. I made two purchase tests myself using an email that was not linked to an account in the site and I definitely went through the regular checkout page (we do not have any of the PayPal buttons that would appear elsewhere activated). I completed the order and no user account created in WordPress/WooCommerce.

The checkout page is using the new checkout experience with blocks and not the old shortcode. Could that have to do with it although it’s not affecting Stripe and was not affecting the old PayPal plugin we were using before.

Any other ideas?

Thanks!

• This reply was modified 2 months, 2 weeks ago by pixelyzed.

Hello!

Thank you for your quick response. The link to the system report is here:

https://privatebin.syde.com/?f3de592511dd505f#86LymiDb5UaMfy9Lq5RB79prw9zJTBmsZvwgonGAc1Wi

Another things I am wondering is that, even on the Checkout page, the PayPal option is not shown for a subscription if “Subscription Mode” is set to “PayPal Subscriptions” in the plugin’s settings. It only shows if “Subscription Mode” is set to “PayPal Vaulting. Any idea why this is?

Something I also forgot to mention yesterday is that, we’re connecting your plugin to a new PayPal account that is different from the one that was used with our previous PayPal plugin. Would some setting in the PayPal account itself explain what I’m describing?

Thank you so much!

Happened again sometime in the last few days. All alert settings reset and now a new just as inappropriate user on the network was set to receive the email alerts for no reason. This is really getting seriously annoying.

You need to keep investigate this. Any progress?

It happened again today, same user that should never get her email set in alerts. Had to redo all other alert settings as well.

Thank you! It has not happened again recently so I’m not surprised you are having difficulty reproducing it. I had to fix it at least 4 or 5 times including right before creating this thread but not in at least 2 weeks now.

I was not specific before but the site is on a Vultr HF server managed through RunCloud and running Litespeed. Everything up to date.

Thank you!

It happened again. Alert settings got reset to default and the alerts recipient set to the same user which has no reason whatsoever to receive those emails (she’s a user with no admin access to any site on the network, she’s not first (user ID = 1) and neither her name nor email starts with a letter that would explain that email to be automatically selected alphabetically. This seems so random.

• This reply was modified 6 months, 3 weeks ago by pixelyzed.

I will do that! Maybe think of adding it to an update with a network level dashboard? Maybe even a pro paid version with that as a distinctive feature. I’ll test it in the next few days. I have a sandbox install for that.

Thank you very much for the quick response!

I would have the same question. The CLS with your slider is really really bad.

Hello? Any idea what might be going on?

Thank you @ingenyus ! That did fix the fatal error.

Do you know if this fix will be added to the plugin soon?

Thanks again!

Also, FWIW, the URL for the page which should be /boutique/commande/ when I click the Checkout button on the cart page is changed to/attendee-registration/?tickets_provider=tribe_wooticket.

If I visit the checkout page manually (I’ve added it to the menu), I do not get the error and, on subsequent visits to the cart page, the button has the normal checkout page URL.

Does this help?

I’m also getting this error on a client site when I try to go to the WooCommerce Checkout page (whether I have a ticket product in the cart or not). As soon as I go to the Checkout page I get this:

Fatal error: Uncaught Error: Call to a member function is_built_with_elementor() on bool in /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-content/plugins/event-tickets/src/Tribe/Editor/Compatibility/Tickets.php:39 Stack trace: #0 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/class-wp-hook.php(307): Tribe__Tickets__Editor__Compatibility__Tickets->include_frontend_form() #1 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/plugin.php(191): WP_Hook->apply_filters() #2 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/formatting.php(3877): apply_filters() #3 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/class-wp-hook.php(307): wp_trim_excerpt() #4 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/plugin.php(191): WP_Hook->apply_filters() #5 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-includes/post-template.php(429): apply_filters() #6 /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-content/plugins/wp-seopre in /home/596560.cloudwaysapps.com/asaaattbwg/public_html/wp-content/plugins/event-tickets/src/Tribe/Editor/Compatibility/Tickets.php on line 39

Hi there,

I know this thread was marked as resolved but I’m adding this just to say that this is a feature that would be very useful to us as well. On a current project we’re using WooCommerce variable products to create a very simple events signup feature. Dates are variations and it’s easy enough to remove them manually for now with one product but this will grow into more and being able to expire them automatically would be awesome!

Thank you!

Hello Scott,

Thank you so much! FWIW, I am truly impressed by the level of support you and Tobias give. That makes your tools so much better and powerful!

Thanks again!