alexwcoleman

Thanks for the review! Very happy the plugin is working well for you folks, and we’ll always be here when you need assistance ??.

The “You are missing the donation id to view this donation receipt” is due to caching. I don’t have a URL to your form to check though. The following exclusions might have to be done within any caching plugin’s settings and on the server.

The fix is a bit technical, so I’ll include as much detail as possible here, 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 @najmu,

Glad you reached out! We can’t help with custom gateways on the forums – we can only support this plugin as it was released ??. I imagine your custom code will have to constrain the custom gateway iframe to some sort of width. If you have some technical/coding questions you can post at the Github discussions page here: https://github.com/impress-org/givewp/discussions

The GiveWP developers monitor the discussion pages ??.

Have a good day!

Hi!

When you mentioned “Preview” I immediately thought of V2 forms because they’re the only type of forms with a Preview button. Thanks to your screencast I can see that you’re using a Visual Form Builder form and using the “View” link – so I’m on the right track now ??.

I was able to replicate what you’re seeing. It’s because the Single Form View has been disabled, which would explain why you can’t see a form when you try to view it using the View button. Go to Donations >> Settings >> Default Options >> Post Types and enable the Form Single Views option if you want to view forms with the custom post type slug.

Let me know if enabling the Form Single Views option allows you to view your forms, and if you have any further questions. Have a good day!

?Hello! Glad you reached out. Happy to help!

What you’re experiencing might be a known issue – but I’d like you to confirm.
?
?There’s a bug when previewing a form that has yet to be Published. Here’s the report: https://feedback.givewp.com/bug-reports/p/classic-form-breaks-preview-until-it-is-published
?
?The workaround in this case is to Publish the form, and then save the form as Draft. Here’s a screencast of me demonstrating on a form that was not published until I published it in the screencast (and then reverted it to draft): https://www.loom.com/share/576294fa26cc409db6027db060746b98?sid=82be1dd7-e889-413e-b8b4-dbaa797be5bc
?
?Let me know if the above workaround works for you ??. Have a good day!

Hi!

?Popping in here to say that the fix for this has been released (GiveWP version?3.0.1)???.
?
?Before taking any steps for troubleshooting or updating, I highly recommend taking a good backup of the site you can confidently restore from. Having a backup of your site is essential to a solid workflow, and will allow you to restore to a previous version of the site if you run into any issues. You can read more about our top recommendations for taking a backup here:?https://givewp.com/backup-for-faster-troubleshooting/

?Then, update and everything should work???. Let us know how it goes.?Have a good day!
?

Hello!

Glad you reached out. I can help here.

You’ve connected to PayPal Donations (PPD), so that’s the correct first step! Have you enabled PPD at Donations >> Settings >> Payment Gateways? If so, you might need to clear the cache in any caching plugins and/or on your server.

There should be an error log in the GiveWP logs for the Stripe issue. Error logs are accessed by going to Donations >> Tools >> Logs. Look for any relevant errors. Use the “eyeball” icon on the right of the log to expand it, and then copy/paste the complete log into your next reply – a screenshot will not show me enough. Here’s a screencast on how to get error logs: https://screencast-o-matic.com/watch/c3eD0AVFgVG.

Once we see that we’ll be able to dig in deeper. Have a good day!

quick update… the file edits show up when the next/prev month navigation is used (so the URL would then be whatever.devsite/events/2018-09/). But when whatever.devsite/events/ is used, it reverts back to whatever is in the “cache”. Weird.

Hey @amsgator, I just had this issue too. I switched my permalinks to “post name” and it sorted itself out. You may have already solved, but thought I’d pop this in here.

ok – no worries about this now – stupidity on my part was the problem…

This is what I get when I install the pre-release:

Fatal error: Call to undefined function token_get_all() in /Applications/AMPPS/www/sitename/wp-content/plugins/ultimatemember-pre-v1.3.69/core/um-shortcodes.php on line 432

I’m on SiteGround. Support says it is enabled.

ok, thanks!

(My client purchased the pro plugin – yesterday I believe)
I may have asked my question incorrectly, or I’m trying to do this on too little sleep, or I’m editing the wrong spot.
I’m looking to have images that are whatever-file-name.jpg converted to 1.jpg, another-file-name.jpg converted to 2.jpg and so on…. or heck, the filename could even be renamed to the $post->ID.
I didn’t find this option in the plugin:

The counter is anyway added by the plugin if the option is checked.

(the closest thing I found was for duplicate file names)

Thanks, and apologies for the extended question!

awesome. Would this be only for the paid plugin?

So I found a hacky workaround to scroll the page 1px on load: I added the following before $img.lazy…

$(window).scrollTop($(window).scrollTop()+1);

perhaps not the best way around, but it gets the job done.