Support

I am trying to access the page you linked me on July 8th, 2022 at 06:15am UTC but I am getting a WordPress error message about a critical error. As a result, I can't really tell you what exactly is going on so I'll have to speculate.

Generally speaking, I very strongly recommend against using IFRAMEs when loading content from a different domain or even subdomain (different origin, as the browsers call it). Modern browsers have been restricting what a IFRAME from a different origin can do. I understand why they're doing that with GiveWP but this is a solution which will stop working.

In your case I speculate that the IFRAME may not work correctly because you have enabled the “Protect against clickjacking” option in Admin Tools' .htaccess Maker. This will indeed tell browsers to limit what an IFRAME can do. Disable this and regenerate the .htaccess file through the .htaccess Maker.

That said, this is a problem which will only get worse over time as browsers will eventually act as if “Protect against clickjacking” is always enabled. The only workaround to that is using a fundraising / donations platform like FundraiseUp which does indeed process the donation without leaving the site. It can also do some smart stuff like proposing a different default donation amount (and reorder differently the higher amounts) depending on the type of device the site is being accessed to. You can also become a FundraiseUp partner to get a share of the (small) fee they charge — this makes sense if you are doing lots of non-profit sites.

That form is truly a mess. The checkboxes are not checkboxes, they are SPAN elements. I would assume that there is some JavaScript which is meant to simulate making them look as checkboxes. Two major fouls here. One, this form is inaccessible to people who are using assistive devices, be it for vision or motor disabilities. Two, that JavaScript seems to be using a legacy version of jQuery, it's not blocked by Admin Tools' .htaccess Maker but does not work either.

Now, I am trying to debug that page and I see that there is no click handler for that pseudo-checkbox. I also see that this is definitely not a PayPal form, this is GiveWP's form with code loading entirely off your site. So this is not a case of blocking something third party.

I also checked the HTTP headers, the only thing which can be modified by the .htaccess Maker generated .htaccess code, and see nothing which could block JavaScript. I also see that all static resources are loaded just fine, nothing is blocked.

At this point I am unsure if the .htaccess Maker has anything to do with it.

Edit your .htaccess file and remove everything between

# BEGIN AdminTools

and

# END AdminTools

This undoes everything the .htaccess Maker did to your .htaccess file.

> One last thing, do you think that there could be anything in WAF that could cause the JavaScript not to load?

Nope. The Web Application Firewall can't block the JavaScript, I did check. The only thing which could have caused a problem was the .htaccess Maker but we've ruled it out.

In fact, thinking that something in the .htaccess Maker may be blocking the JavaScript I checked the Network tab of the developer tools in the browser and saw that it loads correctly. I also checked the console at maximum verbosity (all messages) and there was nothing implying that the JavaScript does not execute. There were just the typical warnings from jQuery Migrate saying that the JavaScript was using legacy jQuery code.

I even went into JavaScript debugging, adding breakpoints at the click events of these SPANs-which-pretend-to-be-checkboxes. I didn't see any events attached to them which might change their CSS class.

I think, without being sure because I never dove that deep, that the GiveWP JavaScript code may be using jQuery to attach events but for some reason that does not work. The typical reasons — again, without being absolutely certain that this is the case here! — is either using deprecated jQuery code or targeting the wrong selectors. We had seen similar issues with our JavaScript code several years ago when we were using jQuery. We moved to vanilla JavaScript and stopped having those issues. Our JS code also got significantly less bloated and much, much faster.

I would recommend asking GiveWP for support. They know far better than either of us how their JavaScript works and why they're using a fake checkbox. They should be able to figure out why it doesn't work. All I can tell you is that there is something rotten in the kingdom of JavaScript :)

No worries :) I have no problem helping troubleshoot issues when the client approaches the issue reasonably and methodically, exactly like you do.

It sounds like there might have been something in the .htaccess not put there by Admin Tools which may have interacted with the way GiveWP redirects to PayPal.

Just something you need to keep in mind. Admin Tools in Joomla generates a new .htaccess file, completely replacing anything you had before. Admin Tools in WordPress cannot (and must not) do that. WordPress has its own .htaccess management API. We can only touch our own section of the .htaccess file. WordPress itself manages a part of this file and other plugins manage their own sections in that file. This is why things get very hairy when dealing with WordPress; we can't know how third party plugins will affect the way your .htaccess file will work! Some (okay, most) plugins are written in a very laissez-fair manner by people who don't really understand how servers work under the hood, leading to some very precarious if not outright icky code.We've seen.... things. It's possible that an automatically installed update or the very process of regenerating the .htaccess file fixed some icky code.

As for the fake checkboxes, this does look like a JavaScript issue with GiveWP. Now, if they don't care to troubleshoot and only tell you to read the documentation, well, nobody can help with that. Eventually you'll have to replace that with a different donations solutions like the one I recommended above. These third party solutions load all assets from their own CDN, minimising the chance of conflicts from misbehaving plugins. The downside is that they load from a third party CDN which makes Google Lighthouse complain a bit but not enough to ding your site's performance score significantly.

Good luck! I know next to nothing about Ruby and me and Python have agreed we don't like each other (last time I used a language with syntactic meaningful whitespace was Fortran 77 back in my university days and I didn't exactly enjoy the experience).