• Resolved dking64

    (@dking64)


    When embedded form is submitted; the donation is made but the form does not redirect to the designated confirmation page. The iframe loader spins indefinitely.

    During a full day of troubleshooting with dozens of tests, the submitted form redirects correctly in only case: at the URL of the form itself and with the query string ?giveDonationFormInIframe=1. It does not redirect when embedded in any page.

    Which points to the theme or plugins. But the problem persists when the theme is set to WP’s twentytwentyfive theme and ALL plugins are disabled.

    Which then points to server caching. I found other support threads about this so I followed the documented advice and contacted WP Engine to add the specified caching exceptions including the wildcard. They complied but that didn’t fix the issue.

    So if the caching exceptions were done correctly it’s not server caching, it’s not the theme, and it’s not a plugin conflict or my security and caching plugins. I’ve spent the entire day on this and have tried everything. Ideas?

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter dking64

    (@dking64)

    One specific question I have is whether the fact the the non-embedded form at https://laesf.org/give/donate-2022?giveDonationFormInIframe=1 DOES redirect correctly after donation indicate the problem is not server caching?

    If so, that leaves the question as to why an embedded form — even with twentytwentyfive theme and no non-Give plugins activated — will not forward after submission.

    Thread Starter dking64

    (@dking64)

    In case it’s helpful, the web console shows this error:

    Uncaught TypeError: Cannot read properties of null (reading ‘getAttribute’)
    const e = window.frameElement.closest(“.wp-block”).getAttribute(“data-block”);
    /give/build/assets/dist/js/give-sequoia-template.js

    Plugin Support Robin Joshua Del Mundo

    (@robindelmundo)

    Hi @dking64 ,

    Glad you reached out! Happy to help. Please excuse the slow turnaround here as well.

    You’re on the right track. When we encounter that issue, it’s usually related to caching. If you’ve already applied the caching exclusions, this can also happen if you haven’t set up the donation confirmation correctly. Double-check if the donation confirmation page has been set up properly by going to GiveWP → Settings → General — https://share.zight.com/yAuR24Dd.

    You might also try refreshing your permalinks by simply visiting your permalinks settings. This is located in your main WordPress — Settings menu. You do not have to make any changes, rather, simply visiting the Permalinks page will “flush” and refresh all the links on your website.

    I would also suggest temporarily deactivating caching on your site (if you have any kind of caching plugins), then visit your Permalinks page again.

    If the issue persists, I’m sending the caching exclusions here so that you can double check if you missed anything.

    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. This is being done 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.

    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

    Moreover, the following query strings (if your caching solution has a setting for them):
    — give-embed=donor-dashboard
    — giveDonationFormInIframe=1
    — givewp-route
    — give-listener=paypal-commerce
    — give-listener=ipn
    — give-listener=stripe

    We also use two cookies: give_nl and wp-give_session_{random generated hashed code unique for each visitor} that should be excluded.

    The give_nl cookie provides email access to donors to view their donation history on your site.
    The wp-give_session_ cookie is to maintain the donor session during the donation process.

    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.

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

    Please let me know once you’ve implemented the above, and then try a test donation while logged out to see if the issue persists.

    Meanwhile, I’m here for further questions or other concerns.

    I’m always happy to help!

    Thread Starter dking64

    (@dking64)

    Thank you very much for the detailed information.

    The good news is your reply got me looking again at the caching exclusions and, in the process, I discovered that the slug for the active donation confirmation page was /donation-confirmation-2, not /donation-confirmation. The former developer must have created a second confirmation page and deleted the original. So the confirmation was not being excluded from server caching. Once the “-2” was removed from the confirmation page slug the confirmation worked.

    A lot of time and trouble caused by the simple slug issue. Your reply led me to look at it so thank you!

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Embedded form does not redirect to confirmation (spins)’ is closed to new replies.