All add-ons currently require PHP 7.4 or greater.
On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.
Please read about the changes to BoldMinded add-on licensing.
Ticket: Exception caught after upgrading from 2.2.0 to 3.3.1 - production server only
Status | Resolved |
Add-on / Version | Snaptcha 3.3.1 |
Severity | |
EE Version | 7.3.6 |
Niki Wolf
Jun 11, 2024Description of the problem
This is going to be a wild one I think. The client just purchased Snaptcha so we could include it (re-include it, actually – we had it pre EE7 but stopped using it in case there were php or EE7 errors) in the Freeform forms on the site, as FF’s honeypot is not working so great, and reCaptcha v2 is terrible, visually…
So I installed it locally, tested it, works fine. Cool. Sent it to production, did the upgrade, made sure the license was squared away, and immediately the front end, the homepage specifically (in a separate browser incognito mode so no shared cookies), dies. Like, dead-dead. (CP still works fine.) It presents this scary result:
Exception Caught
There was a database connection error or a problem with a query. Log in as a super admin or enable debugging for more information.
mysqli_connection.php:114
I uninstall it, and the site resumes normal operation on the frontend. Experimented a few times to make sure it wasn’t some weird coincidence, and it repeatedly dies with the above error every time it’s re-installed. Uninstall, and it goes back to normal operations.
Ok, so I thought, that’s weird, so let’s see what the staging site does, which is a close replica of production with a few things different – db is behind by like a year with the content updates, there is at least one other addon that is upgraded on staging but not on production, some minor template differences, but otherwise the server settings are identical as they’re in sibling directories, same PHP, etc..
I merge the same git branch to staging and push it up, wait for deployment, and repeat the upgrade/license update dance. Check the front end and.. no error??
So the bad news is, I cannot replicate this, currently, on a test/dev/staging site. If I absolutely have to, I can trash the staging site and remake it 1:1 with production (duplicate current db, current codebase, etc), but that is pretty drastic so I’m hoping you may have an inkling of what could be stomping it into the ground on the production server to make it feel like it is losing touch with the database while it’s installed?? Production is not set for debugging, and there isn’t anything in the developer logs in the CP from today.
We have several forms on a single page, so each one has an id associated with it so they won’t clash.
How To Reproduce Steps to reproduce the behavior: 1. Click install on Snaptcha (initially it was already installed but on v2.2.0, and upgraded, which started this cycle; thereafter it’s install/uninstall) 2. Check front end… error message noted below. 3. Uninstall Snaptcha 4. Check front end, back to normal (e.g. site works normally).
Error Messages
Exception Caught
There was a database connection error or a problem with a query. Log in as a super admin or enable debugging for more information.
mysqli_connection.php:114
Screenshots / Videos / Template Code No screenshots, template code for the add-on is simple. In the Freeform code, I merely uncommented out the fields like below, to include them back in:
{exp:snaptcha:field id='33'}
My next step would be to go back through all of the Freeform template files and comment those tags OUT again, try installing Snaptcha and see if it still dies. But I can’t do this until late in the afternoon as the site does e-commerce and I can’t break it during their business hours.
Environment Details: - EE Version: 7.3.6 - Version: 3.3.1 - PHP Version 8.1 - MySQL Version 8.0.36 - OS: Ubuntu 20.04 - Web Server: it’s on Digital Ocean, I believe it’s running Apache as it does observe the .htaccess files.
Additional context For what it’s worth, the config file on this build is ridiculously complex. It uses SERVER_ROOT and other such variables (prod vs. staging) and conditionals, and local uses its own config.local.php file with overrides. However, since the staging server uses this same file (with one slight modification to the $SERVER[‘HTTP_HOST’] variable), I’m not certain it could be behind it. There is nothing Snaptcha specific in it that I can see.
Thanks!!
BoldMinded (Brian)
There is nothing else to that error? No stack trace?
Niki Wolf
No, I don’t think there was because debugging is set to 0 on this site. That was the error that is visible to anyone who visits it while it was down.
Later this afternoon, after their normal business hours are over, I can change it to 1 and reinstall Snaptcha to see if it gives a more in depth stack trace and provide it if it does. I’ll also get approval from the customer to spend more time with it ‘down’ so I can check other pages to see if any work, but I doubt it as there is a form in the header and the footer on all pages.
BoldMinded (Brian)
Yeah if you could grab a stack trace that would help a lot.
BoldMinded (Brian)
Might also help if you try this, it could yield more information: https://boldminded.com/white-screen
Niki Wolf
Comment has been marked private.
Niki Wolf
For folks looking into this, here’s a redacted & truncated version of my stack trace; I have edited out my IPv6 address and cut out the extras as it’s really the first few lines that are key to what is going on. Some of the full stack trace refers to Solspace Freeform, because it is grabbing my IP address.
Niki Wolf
I’ve determined why there is a difference between staging and production with regard to the IP addresses and whether or not Snaptcha was breaking the site…
When I log into the CP and check Tools -> Logs -> Control Panel, on staging it is reporting my IPv4 address. On production, it sees my IPv6 address.
This is because of CloudFlare. The production domain is sitting behind it, but the staging domain is not. So while the webserver itself (or the webhost rather) may not be receiving the IPv6 advertisements from the ISPs, CloudFlare DOES prefer IPv6 over IPv4. So production will always receive IPv6 addresses, and will always hit that problem with the length of the IP field.
BoldMinded (Brian)
I see. The ip_address column in the exp_snaptcha table just needs to be longer. If you edit the table and just set the varchar length to 45 it should fix it until I can get a release out.
BoldMinded (Brian)
Comment has been marked private.
Niki Wolf
Comment has been marked private.
Niki Wolf
Comment has been marked private.
Niki Wolf
Comment has been marked private.
BoldMinded (Brian)
I would maybe try splitting it into two forms with two different IDs. Not only for the sake of snaptcha, but you could track the form submissions separately. If it’s a call to action, I would think it would be nice to know which one performs better. E.g. if you get data that shows the bottom form is only used 5% of the time… then is it really needed?