openedge1
Forum Replies Created
-
Forum: Plugins
In reply to: [Simple Cloudflare Turnstile - CAPTCHA Alternative] Stopped workingFound the issue. Latest update to Formidable has added Turnstile. After deleting plugin and adding Formidables setup, it worked.
Cheers
OK…I just found this in console…
.wpl_property_listing_container .wpl_prp_cont.grid_box .wpl_gallery_container a img {max-width: none;}
Says it is coming from main.css in the plugin.
When I checked Wayback Machine for the page, I found a snapshot from July. This CSS entry was not there. This must have been added with the last update?
I set this to 100% instead of none, and it fixed the stretching…but, that is a bad fix.
But, my issue is resolved.
Hello,
I am experiencing the same issue. I followed your instructions, but the images are still stretched. How do we fix this?
Hello
This worked. So, for future note: Minimum TLS 1.3 connections in Clodflare will cause IPN failures. Set “Minimum TLS” to 1.2.
Do not mistake this for an option called just…
TLS 1.3
This will “Enable the latest version of the TLS protocol for improved security and performance.”
This can stay actually stay on. So, if a browser or API call requests this upgraded connection it will connect at 1.3. Otherwise, by setting the minimum lower, it will allow those lower IPN calls in (PayPal requires TLS 1.2 based on all data).
- This reply was modified 1 year, 9 months ago by openedge1.
OK…may have found the problem.
We use Cloudflare for connections to the site. In one setting there is the ability to upgrade all connections to TLS 1.3. Seems PayPal has issues connecting to anything over 1.2 or below 1.1.
I have made this adjustment, and I am waiting to see if this returns the IPN call properly. Could take 24 hours to know for sure.
I will keep this ticket open and will resolve if we have success.
We do use a firewall on the server (CSF in Cpanel). But, we also have other websites on the same server with this specific addon, which are working properly.
I have also verified the IPN is setup correctly. I have asked them to get me the data on the IPN History page to see if we can spot any errors.
But, so far, we cannot find any specific problems that would prevent it from working. As well, the “other guys” donation plugin that was installed on this site, works without a hitch.
As an added bonus, one site I reviewed that uses your plugin also has Wordfence, and still works. That is not installed on this new site…and no other addon is installed to block API calls.
Just this specific site is not getting an IPN return.
Excellent. I was unsure if PayPal required a special notation or not on the order to mark it as a ‘Donation’.
I will verify with our customer on their status, but this was helpful.
Thank you
Excellent. That is what I needed. I did prefer the payment form option with the selected amounts as buttons…but, this at least captures what I need to accept. I guess I could CSS it up if I need to.
As to why we quit, very simple. Too many ads, and nickel and diming for everything. Keep it simple and give us the right features at the right price, and you will win every time.
Thank you for your help. This is resolved.
OK. And yes, this is exactly what happened. The “bot” was able to continually slam the sites payment form to attempt to inject code. It basically creates a mess, with tons of empty invoices and junk code (for example: why does the form allow code as the payment amount without any system checks to verify the price is a real number?), mass emails and a ton of junk in the database .
Some method to check for a human is really needed.
As long as you are working on some form of captcha, I do not need to open a ticket…but, a captcha is really needed from what I can see.
Hello,
It was an SQL Injection attempt. We have the invoices showing the code for the inject…so, yes, it was an SQL injection attempt. They slammed the payment page over and over with code to attempt to break the site, DDoS style. This of course generated emails for each attempt.
The attempt was done in the wee hours of the morning for us. We were notified of the issue via a mass mailing alert. The website was sending tons of emails due to the attempt. All invoices show SQL code in the payment amount field.
We debated about the “sign up to checkout”, but with the type of websites, this is not feasible. The website owner needs to allow their customers to make quick payments.
Thus, yes, a Captcha, which GiveWP has, would be very helpful in this respect.
I can open a support ticket on your site if you need more info.
We were able to find the issue. Another addon was interfering with your addon. It was built by one of our devs.
At this time, we cannot replicate it on any sites that do not have this plugin.
Closing topic.
Forum: Plugins
In reply to: [Download Manager] Purchases not showing in DiviOK,
Well, this is resolved (smile).
Seems that you MUST use the Divi Builder on the pages with the shortcodes. If you do not use the built in editor tools for Divi (i,.e: Leave it as a WordPress page), it breaks the short code displays.
In short…use the page builder to setup the pages with shortcodes.
Just an update: Version 3.77.1 has broken this again. I have reported this issue to your support. But, we’re back to whatever email address is in bounce becomes the sender of the email.
Sorry, posted in wrong thread. Ignore my comment (though, it is a bug you may want to know about)
Just a quick notice. I am reporting this via your ticket system as well. You just did a new update, and sending is broken again when a different email is in bounce.
Version 3.77.1 Has broken sending again if you use an alternate domain email in the bounce (so, say you use a gmail.com email address in bounce, it tries to send that email as @gmail.com)