stephanieliy

Hi @adi_wordpress,
Glad you reached out. It sounds like you’ve isolated the issue as a conflict with Elementor and GiveWP. I’d like to test this as well to see if the issue is replicable, and I’ll need a little more information to get started:

First, send along your system information. You can do this by navigating to Donations > Tools > System Info (tab) and clicking the button to “Get System Report” and copy/paste that into your reply here.

Next, send along very clear steps detailing how you came upon the issue. I’ll be “following in your footsteps”, so the more detailed the steps, the better.

Keep me posted, and if you have questions in the meantime I’m happy to help.

Hi @mbio86,
Like you, I’m curious about a possible conflict or some caching that might be causing that string to display without translating correctly.

First, send along your system information. You can do this by navigating to Donations > Tools > System Info (tab) and clicking the button to “Get System Report” and copy/paste that into your reply here.

Next, let’s make sure you have caching exclusions implemented so we can rule that out as a possible culprit.

If you’re not familiar with caching, it’s a method of saving server resources by storing copies of a page or site, so that the next visitor’s visit doesn’t trigger a call to the server at all, they just get the copy that was saved. Basically instead of the site needing to recreate the page from scratch, it sends up a copy which allows it to load faster.

We put together this deep dive into what caching is and how it can cause problems: https://givewp.com/documentation/resources/caching/

Caching works really well for speeding up sites, but when a saved copy of the site has sensitive information in it (like donor info) it’s important that GiveWP not share that with the next visitor. If GiveWP is not convinced that the browser requesting the data is the correct one, it defaults to not showing the data.

Caching is handled differently on various sites and web hosts. This could mean a caching plugin, or caching could be in a security solution. Hosting providers also have settings for caching at the server level, and they can help make adjustments for you there. Most caching solutions have a setting or section for excluding specific URLs or parts of URLs (called “slugs”) from caching. At the very least, you should exclude the following slugs from caching:

/donations/
/donation-confirmation/
/donor-dashboard/
*any page with a donation form on it

Also, the following query strings (if your caching solution has a setting for them):
give-embed=donor-dashboard
giveDonationFormInIframe=1

Your host or the caching plugin/solution you are using can help with that. Some of them may require what’s called a “wildcard” like /donations/* to capture all subdirectories under the /donations/ folder.

One helpful tip: Check in with your hosting provider. Most hosts have caching at the server level, and they will be able to adjust this for you. You can also temporarily disable caching on the site to confirm that the uncached site isn’t showing the problem.

While fine-tuning cache falls outside the scope of the support we’re able to provide, your success with online donations is our number one priority, and we’re happy to provide any tips.

Keep me posted on how things go, I’m happy to keep working this with you!

Hi @equin0xx,
It’s been a bit since I’ve heard back, and I know troubleshooting can take a little extra time. I’m marking this as resolved for now, but if you still have questions you can send them along here and I’ll be happy to hop in for a look. Have a great day!

Hi @michellekoen,
I know you are giving things a look here, and that you might need a little extra time. I’m marking this as resolved for now, but if you come across any new information or have any questions you can send that along right here and I’ll be happy to hop in!

Hi @hirenmakasana,
I know you are doing some work here, so I’m going to mark this as resolved, but if you have any questions don’t hesitate to send them along here. I’m happy to help as you navigate things!

Hi @eduardolorden,
Thanks for that clarification, it helps!

I suspect you might be experiencing a conflict, but I’d need to do a bit of digging to be sure.

First, send along your system information. You can do this by navigating to Donations > Tools > System Info (tab) and clicking the button to “Get System Report” and copy/paste that into your reply here.

If you have a URL for that page, I’d love to take a look from the front end as well.

I’ll set up a sandbox and use your information to try to replicate what you are seeing.

A screencast or video of what you are seeing would be fantastic. You can send that along right here and I’ll give it a look.

If you have any questions in the meantime, I’m here to help.

Hi @eduardolorden,
Glad you reached out. It sounds like you might be seeing a fatal error or critical error when you install and activate GiveWP. Do I have that right?

Typically, this error means some broken code is causing your site to crash. PHP errors like critical or fatal errors are recorded in your server logs. If you don’t know where to find the PHP error logs you can contact your hosting provider and they will be able to point you in the right direction to find them, or they can send them right along to you.

The details in these error codes give us helpful context to understand the issue you are running into, so they will be the first step in getting to the bottom of things.

Let me know if you have any questions about this in the meantime, I’m happy to help.

Hi @equin0xx,
Glad you reached out. I’ll need a little more context to understand what’s happening here.

First, send along your system information. You can do this by navigating to Donations > Tools > System Info (tab) and clicking the button to “Get System Report” and copy/paste that into your reply here.

Next, can you give me a detailed description of what you are trying to do, and the parts that aren’t working? For example, what kinds of changes have you made that you aren’t seeing reflected? I’ll need to know exactly what to look for.

Let me know if you have other questions in the meantime, I’m happy to help.

Hi @michellekoen,

Thanks for sending along that information.

I’m still leaning towards a redirect being your issue here. If you navigate over to your Stripe dashboard, you should be able to click one of those donations and see a record of webhook activity and/or error codes. You’ll see a 200 response for the donation being received, but if you scroll down a bit you should see the 301 error with some additional details. Those details will pinpoint right where the trouble is coming from.

Usually this comes down to a very subtle difference between your site, and your webhook URL. Sometimes it’s a little more obvious, like the site using HTTP and then being redirected to HTTPS. But in some cases it comes down to something very small, like an extra /. We need to know exactly where the difference is to be able to correct it to stop that redirection.

Because you are receiving completed donations, we know your webhook is communicating, we just need to close that communication loop. A 301 will stop recurring donations from completing successfully, so we’ll want to get it squared away.

Give the code a look in your Stripe dashboard, and let me know what you find. Once we have a little more context, we should be able to set things right.

Keep me posted, I’m happy to help with questions along the way!

Hi @ladydev,
Do you happen to be working with a Classic or Multi-Step forms?

Those forms won’t display settings on the front of the block. They are intended to be configured from the backend of your site at Donations > All Forms > Edit.

The Legacy form template does display those settings on the front of the block, but it is the only template to display them.

I’ve created a feature request for our teams to review for including those settings across all form templates here: https://feedback.givewp.com/feature-requests/p/enable-settings-options-on-the-donation-form-block-for-classic-and-multi-step-te

Let me know which template you are using. If you are working with the Legacy template and still not seeing those settings, I’ll be happy to give things a look.

Hi @hirenmakasana,

That error is typically caused by two issues, so I’ll send along information for both here.

First, we see this error when someone donates and uses an email address that belongs to a user who has donated before at some point. If you don’t want donors to have to register and/or log in to the site to make a donation, you’ll want to disable Registration and enable Guest Donations on the form settings:

Then, also enable Email Access in Donations -> Settings -> General -> Access Control.

That will allow your donors to give as “guests” and will eliminate that error message for you.

If that doesn’t get you going, you may have an issue with caching that is the culprit. GiveWP has some best tips for managing caching:

The fix here is a bit technical, so I’ll include as much detail as possible, but you may need to reach out to your web developer or web support person to implement the recommendations I’ll be talking about below.

Your issue here is caused by some caching happening somewhere in the process. If you’re not familiar with caching, it’s a method of saving server resources by storing copies of a page or site, so that the next visitor’s visit doesn’t trigger a call to the server at all, they just get the copy that was saved. Basically, instead of the site needing to recreate the page from scratch, it sends up a copy which allows it to load faster.

We put together this deep dive into what caching is and how it can cause problems: https://givewp.com/documentation/resources/caching/

Caching works really well for speeding up sites, but when a saved copy of the site has sensitive information in it (like donor info) it’s important that GiveWP not share that with the next visitor. If GiveWP is not convinced that the browser requesting the data is the correct one, it defaults to not showing the data.

Caching is handled differently on various sites and web hosts. This could mean a caching plugin, or caching could be in a security solution. Hosting providers also have settings for caching at the server level, and they can help make adjustments for you there. Most caching solutions have a setting or section for excluding specific URLs or parts of URLs (called “slugs”) from caching. At the very least, you should exclude the following slugs from caching:

/donations/
/donation-confirmation/
/donor-dashboard/
*any page with a donation form on it

Also, the following query strings (if your caching solution has a setting for them):
give-embed=donor-dashboard
giveDonationFormInIframe=1

Your host or the caching plugin/solution you are using can help with that. Some of them may require what’s called a “wildcard” like /donations/* to capture all subdirectories under the /donations/ folder.

Some folks prefer to customize the URLs to their site pages, so you may find that your URLs don’t have the slugs mentioned above, even though they contain the same content. In cases like those, we recommend whitelisting the page, not just the slug, that way the pages with those essential pieces of information are still excluded from caching. This is especially important for URLs of pages with donation forms on them.

One helpful tip: Check in with your hosting provider. Most hosts have caching at the server level, and they will be able to adjust this for you. You can also temporarily disable caching on the site to confirm that the uncached site isn’t showing the problem.

While fine-tuning cache falls outside the scope of the support we’re able to provide, your success with online donations is our number one priority, and we’re happy to provide any tips.

I know this was quite a bit of information to share. If you have any questions about this let me know, I’m happy to help.

Hi @mbio86,
Thanks for sharing all that information, it’s helpful. It’s a little strange that your admin email address is receiving email receipts, but other emails are not. GiveWP only needs to see a donation marked as “complete” to send an email receipt.

Your admin email address is receiving a donation receipt when you donate, and that means GiveWP is sending receipts. It’s possible that the email clients for the other email addresses you are using have spam or junk filters that might be catching your emails, or there may be rules in place that are blocking the receipts altogether.

I’ve also run tests using my own test site and sandbox, and I’m able to confirm that donation receipts are sending properly, which means the email issue isn’t replicable.

Diagnosing email issues can be tricky, because the only side of the process in your control is whether or not the emails are being generated by your site. In this case, they are, because we see them when the admin email donates. Outside of this, you’d need to look at other factors like those in the troubleshooting article I sent along, or you may want to consider removing WordPress from the equation entirely and use the SendWP integration.

I’m happy to help as much as I possibly can, but without a replicable issue I’m relatively stuck. That troubleshooting article has the best tips to help move you forward. I’ll mark this as resolved for now, but you are welcome to send along any other questions you have about this, I’ll hop back in for a look!

Hi @mbio86,

Emails are a bit tricky in WordPress, and most often the issue is not with GiveWP (honestly!). GiveWP only needs to see that the donation is marked as “Complete” to generate the donation receipt, even when running test donations. That being said, there are other factors in play on the WordPress side of things that may need adjusting to get those email receipts back up and running. We put together this troubleshooting guide to help:

https://givewp.com/documentation/core/settings/emails/troubleshooting-common-email-problems/

Essentially, you’ll need to confirm WordPress is sending the email receipts, and then figure out why they aren’t being delivered. Most of our users who walk through those steps are able to resolve those email issues!

If the email is not coming through there might be an issue with email deliverability in general — that is controlled by your host. Usually, email deliverability issues can be solved via using SMTP instead of the default PHP mail function that is provided by WordPress out of the box. For more information about this, you can jump right to this section of the email troubleshoot document titled Sending Email from your WordPress Site via SMTP.

You may also want to give the SendWP integration a look. It is an email delivery system baked right into GiveWP, you can read more about that here: SendWP.

Let me know if you have any questions about this, I’m happy to help.

Hi @mbio86,
I can definitely help here! I’m not able to access sites, but your screenshots worked perfectly, and I can always take a look at a URL from the front end. Most of the strings you highlighted are available for translation, just a couple aren’t.

When you are searching for a string to translate, you can just start typing in the text, and Loco Translate will give you a list of possible matches. For example, here’s the string for Lifetime Donations in the Donor Dashboard:
Lifetime Donations – https://imgur.com/Tb3BcR7

I did find a couple strings that don’t have translations, and we are tracking them for a fix here: https://feedback.givewp.com/bug-reports/p/donor-dashboard-notifications-should-be-translatable-or-editable.
Your giving stats
Donor for %s

Give searching by string a look and let me know how things go. I’m happy to help with any questions you have.

Hi @michellekoen,
Glad you reached out.

You mentioned you are only seeing 301 errors on test payments, is that right?

A 301 error means there is a redirect, and that can happen for a couple of reasons.

1. A possible issue with your webhook (which you’ve ruled out, so no worries there)
2. A plugin or security solution. Firewalls and Coming Soon plugins are common culprits for this.
3. The hosting provider.

In this case, I’m leaning very heavily toward the hosting provider. I’d recommend reaching out to them for clarification about redirects. If that doesn’t help get you going, I’ll need a look at your system information to see if we can get some traction for what may be causing the redirection. You can send this by navigating to Donations > Tools > System Info (tab) and clicking the button to “Get System Report” and copy/paste that into your reply here.

Let me know if you have any questions about this in the meantime, I’m happy to help.