If a recurring donation is canceled by the payment gateway OR it fails, GiveWP still marks it as complete.

When entering a donor email that doesn't exist, the form displays a message related to too many email access requests; this is an incorrect message to display.

Currently, the styles of the eCheck gateway do not match the other styles, the image is cut off, and the inputs look bad.

Right now, if you are logged in and tries to make a donation using the multi-step donation form, the personal information is kept. However, when using the multi-step donation form and you are logged out, then, if you switch payment gateways, then your personal information is cleared and you need to fill it again.

I have a bug I’d like to report regarding incorrectly formatted dates and times displayed throughout the plugin. The easiest way to demonstrate this is on the Donor Dashboard. On the Dashboard, users are presented with their “Last donated {TIME} ago”. Go ahead add a test donation for that user now and you’ll notice how this time difference is incorrect. The issue has to do with the fact that all dates stored in the give_donationmeta table are being saved in the site’s timezone, rather than in UTC. (This includes the meta ‘_give_payment_date’, the data in ‘_give_payment_meta’, and ‘_give_completed_date’.) As such, functions like strtotime(), which assume that they’re working with UTC, end up incorrectly formatting the date and adding the local timezone offset. Technically, the fix for this is pretty easy. The simple way to fix it is to tell functions like strtotime() that the string they’re dealing with is already in the WP Timezone. So for example, in wp-content/plugins/give/src/DonorDashboards/Profile.php replacing line 83: 'sinceLastDonation' => ! empty( $this->donor->get_last_donation_date() ) ? human_time_diff( strtotime( $this->donor->get_last_donation_date() ) ) : '', With this: 'sinceLastDonation' => ! empty( $this->donor->get_last_donation_date() ) ? human_time_diff( strtotime( $this->donor->get_last_donation_date() . ' ' . wp_timezone_string() ) ) : '', The alternate solution is to keep things consistent with how WordPress and MySQL like to store dates (and how they’re already being stored in the give_donors table in ‘date_created’ and ‘verify_throttle’) and store them in the database in UTC. It may be worth the effort as then, should a site admin need to change a site’s timezone, this wouldn’t affect donations as they’d be displayed correctly after the change. I also noticed that you’re using the date_i18n() which is a bit of a depricated function that oftentimes ends up again formatting the date/times with the wrong offset. To see this in action, let’s temporarily change the give_date_format to include times: add_filter( 'give_date_format', 'custom_give_date_format' ); function custom_give_date_format( $date_format_contexts ) { return 'F j, Y g:i a'; } Now go to the Donors admin page. You’ll notice how all dates are actually being output in UTC rather than with the correct site’s timezone offset. The fix for this is really easy: replace date_i18n() with the newer wp_date() which will correctly take into account the site’s Timezone and format the dates/times accurately.

So when selecting from the different Gutenberg blocks, Give uses an SVG to render the Give icon. However, it uses the following clip-path clipPath="url(#SVGID_2_)". Which would work like a charm if there was only one #SVGID_2_. Unfortunately, since GiveWP creates 5 different blocks, and each block defines it’s own set of #SVGID_1_ and #SVGID_2_‘s, we end up with 5 of each. This is against ID usage standards, which results in it breaking the clipping and not rendering the icon in some browsers (for example in Firefox):

In 2.11.0 we corrected address spacing when editing donors, unfortunately this affected how the address is displayed on the Donor Dashboard in the receipt (see screenshot). This needs some formatting to make it look nice again.

Trying to connect to Stripe using PHP 8 generates a fatal error.

Right now, if the Login + Registration option is enabled and there are custom fields created using the Form Field Manager add-on, if the donor clicks to login and then cancel it, then when he/she returns to the personal information section, the custom fields are gone.

Right now, if the form has a minimum amount and I try to change my donation amount for a recurring donation using the donor dashboard, the amount field is not erased completely, but it gets the minimum amount and I can't erase that. The workaround is to ignore the first digit, add my custom amount, and then erase the first digit.