dholtzman

Has there been any progress on this issue? It’s a pretty. major inconvenience for donors/customers to have to enter their address information twice! Thank you very much.

I am seeing the same errors on https://www.investinmpl.org. WordPress 6.3.1, TEC 6.2.2, Events Calendar Pro 6.2.1, calendar page https://www.investinmpl.org/events/. I’ll paste a full sample error below. Thank you.

Sep 27, 09:09:29

WordPress database error Incorrect DATETIME value: '' for query
SELECT SQL_CALC_FOUND_ROWS (wp_eg65rv_tec_occurrences.occurrence_id + 10000000) as occurrence_id
FROM wp_eg65rv_posts LEFT JOIN wp_eg65rv_postmeta ON ( wp_eg65rv_posts.ID = wp_eg65rv_postmeta.post_id AND wp_eg65rv_postmeta.meta_key = '_EventHideFromUpcoming' )
JOIN wp_eg65rv_tec_occurrences ON wp_eg65rv_posts.ID = wp_eg65rv_tec_occurrences.post_id
WHERE 1=1 AND (
CAST(wp_eg65rv_tec_occurrences.start_date AS DATETIME) > ''
AND
wp_eg65rv_postmeta.post_id IS NULL
) AND wp_eg65rv_posts.post_type = 'tribe_events' AND ((wp_eg65rv_posts.post_status = 'publish')) AND (wp_eg65rv_posts.ID NOT IN (182))
GROUP BY wp_eg65rv_tec_occurrences.occurrence_id
ORDER BY wp_eg65rv_tec_occurrences.start_date ASC, wp_eg65rv_posts.post_date ASC
LIMIT 0, 1
made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/plugins/the-events-calendar/src/views/v2/default-template.php'), Tribe\Events\Views\V2\Template_Bootstrap->get_view_html, Tribe\Events\Views\V2\Template_Bootstrap->get_v1_single_event_html, tribe_get_view, include('/plugins/the-events-calendar/src/views/single-event.php'), tribe_the_next_event_link, tribe_get_next_event_link, Tribe__Events__Adjacent_Events->get_next_event_link, Tribe__Events__Adjacent_Events->get_event_link, Tribe__Events__Adjacent_Events->get_closest_event, WP_Query->get_posts, apply_filters_ref_array('posts_pre_query'), WP_Hook->apply_filters, TEC\Events\Custom_Tables\V1\WP_Query\Modifiers\Events_Only_Modifier->filter_posts_pre_query, TEC\Events\Custom_Tables\V1\WP_Query\Custom_Tables_Query->get_posts, WP_Query->get_posts, QM_DB->query

Thank you!

In order to make this code work, I had to add an opening PHP tag at the beginning, and unselect the “Load form using AJAX” behavior option. Is changing this setting likely to cause any issues?

Since the code includes the new error message text, we modified this to let users know they need to reload the form and start over before correcting errors. We still hope you will be able to fix this issue in a future update!

Our form toggles between PayPal buttons and a Submit button. We just noticed that it is possible to correct and resubmit the form when the Submit button is active–the issue only affects PayPal submissions. Is this correct?

We also noticed that when there are omitted required fields with no PayPal button, there is no error message at the top of the form. Instead the page scrolls up to the first omitted field. Is there a reason why the “Please correct the errors before submission” message is not generated in these cases?

Finally, we are using an updated mu-plugin you sent us last May to toggle between the PayPal and Submit buttons, but I see that there is also a “Switch PayPal field’s visibility with Submit button” option in the PayPal field Advanced tab. From very brief testing, this seems to do the same thing. Is there a difference between the two approaches?

I apologize for all the additional questions. We’re trying to understand this as thoroughly as possible. Thanks again.

Thank you again.

I have confirmed that this issue occurs in Sandbox as well as Live mode. Despite this, I tried the steps you suggested on our test site, as well as several other changes to simplify the form. Finally, I reproduced the issue on a test form with only three fields: a currency field, a required checkbox, and a PayPal field with the amount taken from the currency field. So calculations and visibility conditions were not the source of the problem in this case.

This led me back to a thread that I wish I had read more carefully the first time I saw it: https://www.ads-software.com/support/topic/paypal-amount-must-be-greater-than-0/. It appears that unless there is a default value in the field used for the PayPal Amount, the “PayPal amount must be greater than 0” message displays when the form is submitted with required fields omitted. If there is a default value, the correct error message displays (“Please correct the errors before submission”).

Our problem now is that we do not want to have preselected defaults in the fields that may contribute to the Total field: the three “Subscriptions” radio-button fields and Donation. The only workaround I have come up with is to create a number field with an arbitrary default value, include it in the Total calculation, set it to be hidden when there are values in the subscription or Donation fields so that it no longer affects the Total, and then hide it completely from the user with CSS.

This appears to be working on our test site, but it is a bit of a kludge. Do you have a better solution? Or have I missed something along the way? Thanks.

Thanks very much for your quick and helpful response. We do indeed have “…complex calculations and/or visibility conditions.” The exported form is here: https://pastebin.com/vVx8hEW6.

Our site requires all new registrations to be approved by an Admin. (I have confirmed that this setting is applied to all User Roles.) Does this protect us from the vulnerability?

Thanks very much for the snippet. I put it in the mu-plugins folder in place of the existing mu-plugin–was that correct?

The buttons (PayPal or Submit) are still displaying when they should based on other fields in the form, but we haven’t had a chance to test actual transactions. If anything doesn’t work right, I’ll let you know. Thanks again.

Thanks for your quick reply! This issue appears to be resolved, but I remain concerned because 1) I’m not sure why the changes I made eliminated the error, and 2) your reply suggests that our use of the mu plugin may cause other problems.

The UK Members only – Method of Payment field in the form has five options, two of which cause the PayPal/Credit buttons to appear and three of which cause the Submit button to appear. As I continued testing, I was surprised to find that choosing “BACS”, which should have exactly the same effect as “Cheque”, did not produce the error.

I compared this field with the equivalent field on the live site, and I found that the values that entered under the labels when each option is expanded in the field settings were not the same, presumably because I did not check these when I recreated the field in the new version of the form. I changed them all to match the live site, which included changing the value “Cheque” to the lower-case “cheque”. This appears to have fixed the problem, though I’m not sure it did so immediately on one of my two test sites.

I also unhid and re-hid the the “PayPal or not PayPal field” which is an intermediate calculation field which actually toggles the visibility of the PayPal buttons.

Please let me know if you can shed any light on this mysterious result, and if you recommend we make any other changes relating to our use of the mu-plugin.

Thank you very much.

I have figured this out. Please close. Thanks.