Monthly Archives: June 2023

TL/DR; Your users may get a ‘There Has Been a Critical Error on This Website’ message when they submit a comment

It probably means your webhost has disabled the PHPMailer function on a shared platform for security reasons. The fix is simple: download an SMTP plugin and use your website’s SMTP server and one of its email accounts and you’re good to go.

NB, although your users get that scary message, their comment may still be posted on your website. The point of origin of that message is your website sending the notification to you not something your user is trying to do. But best fix it, eh?

Big shout out (because that’s what us kids do) to Masher for spotting this error and to me for fixing it.

TL/DR; POP3 false positives can really mess you up. Sort them out the minute you get ‘can’t log in’ messages

So I got my core domain/sub-domain up and running on the new host after battling with a) corrupt user.ini file and b) .htaccess with incorrect permissions. It took just short of 24 hours of downtime to identify and fix the issues and I really didn’t like that much downtime. Actually it took 23-1/2 hours of downtime to identify and 10 minutes to fix, then 10 minutes to test.

I went to bed a happy bunny. When I woke up this morning I ran checks which all came back green. Then I tried to log in to the core domain front end except I couldn’t even see the front end because I got a 500 error. So I tried the sub-domain and couldn’t see that either. Then I tried this website and couldn’t see that. All three properties returned 500 error messages.

So I got onto the host chat and asked the to look. They said they were all up and in the green then they went off to check something. Five minutes later they came back to say my Internet node’s IP address had been banned. They’d removed the ban and everything should be sorted. I checked. It was indeed all sorted.

I asked how my IP address could have been banned. They pasted a report that said it was due to repeated but failed POP3 login attempts. I checked my phone and yes, in my email client there nestled half a dozen failed login attempts on one of the new email accounts I’d set up against the core domain. Apparently the hosting infrastructure registered my IP as unfriendly and banned me from all domains in my hosting hosting account. Ooops.

Anyway, I’ve reset the POP3 password and everything’s great now. How embarrassing though.

TL/DR: user.ini file (which only your host should be able to get at) can screw you over

I started to move my core domain to a new host on Friday. I followed the usual procedure and blow me down what a problem I had getting /blog back up. Error messages all over the place. I deleted the database, removed the wordpress files, deleted the database user and basically I tried to reset everything. Except the problem(s) wouldn’t go away. Through various tinkering I could change the error message the site was putting out but I couldn’t get past the errors. I tried everything. Every single trick in the book. Eventually, after a long time of running into brick walls, I called tech support. Once they’d worked out what the problem was, they fixed it very sharply, but it took a while to get to the issue which was…

A corrupt user.ini file.

TL/DR: moved WordPress to a new host and website didn’t work (and how to fix it)

I’ve just moved this domain to a new host. In the last 15 years moving domains from host A to host B is a thing I’ve done for fun a couple of thousand times and a thing I’ve done professionally a few hundred thousand times (the biggest challenge was moving the entire corporate dot com website plus mobile apps from a legacy datacentre to a super-dooper hybrid cloud datacentre, fitting in upgrades whilst in-flight, and putting in a few thousand mapping and routing changes, and overlaying the new infrastructure with a new security model along the way was no picnic, I can tell you!). So moving this little domain from one host to another was a piece of cake, yes? Well, no.

On the new host I created the new database, created a user, assigned permissions to the new user then I created the new domain in cpanel. Flipped over to the old host and downloaded all the WordPress files and directories, then downloaded a copy of the database. While WordPress was still downloading I went back to the new host and imported the legacy database into the new one. When WordPress had finished downloading, I opened an ftp session to the new host and uploaded all the WordPress stuff. Then I opened the wp-config.php file and changed the username, database name, localhost, and password, then sent that on its way too. Then I created an email address for this domain on the new host.

Then I went to the domain registrar (a third party, just to keep things complicated) and updated the nameservers and then the DNS settings, pointing everything at the new host. This should have resulted in a seamless switchover while I was catching some Zs. So when I woke up and say the blandest of bland error messages that said, in a nutshell, this website isn’t working today (or ever, unless you fix it), I was a mite disappointed.

Ping and tracert both told me that the new DNS settings had propagated and all calls to this domain were being packaged to the new host correctly. On a whim I tried the MX settings, I created a new email on the new account against this domain on the new host and sent it off. The email rattled into my other inbox. I replied to it. The reply rattled into the new inbox. So MX settings mirrored what ping and tracert were telling me – that the new domain was up and running. Except the error message said it wasn’t.

The only thing left to pick apart was the config file in WordPress. I read through every single character very carefully and on line 25 I found the gremlin. When I created the new database I’d given it a password similar to abcde12e4t99!!” and that was why the migration failed. The password contained the character ‘ (yes, a simple single quotation mark) and the coding structure of WordPress expects to see the two characters ); after every single quotation mark at the end of a line of code. So this, for example:

define(‘DB_HOST’, ‘localhost:3306’);

But because I’d used a ‘ after the second exclamation mark I’d tripped up on the WordPress syntax, because it expected to see ‘); and not expecting to see another quotation mark. And that was the problem. The whole website was brought down by a ‘ in the password text. The solution was, obviously, not to use a quote mark in the password. I changed the password and Robert’s your Mother’s Brother, everything just clicked into place.