I’ll share with you the lessons learned from debugging an error on my client’s website. Then I’ll dive into the behind-the-scenes story of what happened and how difficult it was to solve the problem and extract these key takeaways.
Debugging lessons learned:
How to tell if there’s an error on your website?
If you don’t yet see an error but something doesn’t work right. For example, a form can’t be submitted. An error occurs behind the scenes but your website isn’t set to show it yet. By default, a WordPress website is set to not show error messages.
Core steps to debug an error on a WordPress website.
- Enabling a debug mode and error log mode in the wp-config.php file
- When observing the error log, focus on fetal errors first. Disregard notices, and warnings. Most of the time, fetal errors are the cause of the trouble.
- Once you have located the fetal error, if you’re new to the error or unsure where to start, google it. You’re likely not the first one to encounter the issue. A website like Stackoverflow can oftentimes give you a quick answer to your problem. If you want to dive deeper or understand the error more, look for the results from websites such as WPbeginner, Kinsta, Lifewire, and Hubspot’s blog. I learned so much from those sites’ long-form articles.
- Pick the source that addresses your situation most and follow the steps to fixing your error. Test your website to rule out your assumptions till you find the one that causes the error. If you don’t find anything wrong, edit your search terms and try again. Or ask for help whether it be in a WordPress forum, contact a support team of a particular plugin/theme, a WordPress slack group, your web host, your mentor, etc.
- Document how you troubleshoot the error and include the source(s) you use. This will save you so much time and headache when facing the same error in the future.
I wish I had focused on the steps above when tackling the error I’m about to tell you. It would have saved my brain power and reduced stress and heartache. While getting lost in troubleshooting this error, I wrote in my journal, “I HATE WORDPRESS SOMETIMES.” Something I had never felt before.
Problem flagged and initial investigation
My client told me she was flooded with 50-60 daily emails through the website, all containing just a name and email with no message. We suspected spam, but with reCAPTCHA (Security measure built to distinguish between human users and automated bots on websites through challenges, such as image recognition tasks, to verify user authenticity.) and SMTP (Simple Mail Transfer Protocol – a communication protocol used for sending emails over the internet.) in place. I dove into the issue.
Initially, I doubted that these emails came from the site’s contact form because the format of the name and email fields didn’t match with the form’s fields. When I compared these emails’ format with a legitimate email sent from a real human user, it even confirmed that these emails weren’t submitted from the contact form.
Hours went by as I got lost finding answers online. Before letting myself become discouraged more, I knew I needed some new perspectives, so I turned to my husband, Andrew. He’s a problem-solver master.
Key Assumptions, a new problem arose, and debug mode turned on
Andrew pointed out two key assumptions. First, spam might target other forms on the website that didn’t have reCAPTCHA set up. That’s why the emails bombarded the inbox like that. Second, he spotted that the contact form didn’t require the message’s subject and body inputs, which means people could submit only their name and email. Bummer. This was something I overlooked.
Our first step was testing the contact form. To my surprise, the contact form and email signup form both failed to submit. Could it be the SMTP plugin error? I went to the SMTP setting and sent a test message. Failed. I was angry.
Andrew advised enabling real-time error messages to make it easier for debugging. Turning on debugging mode on the site required navigating multiple accounts. And since I don’t get to troubleshoot WordPress errors often, I haven’t taken time to streamline the processes.
I aimed to install the File Manager plugin to streamline debugging but the installation failed. That infuriated me even more. It looked like the problem was beyond the spam messages at this point.
Took a break and dug into the error log
Once debugging mode was on, numerous warnings and notices appeared in the error log, mostly related to incorrect enqueued WordPress functions. I looked them up in the WordPress documentation but struggled to understand any of them. I decided to take a break before it broke me.
I was frustrated, and hopeless, and wished I had the skills and knowledge to fix the issue without struggling this much. Although I knew I could ask my husband to rescue me from this hole, I wanted to stretch myself further and see if I could hack the website out of this mess myself.
Marie Foleo said “Everything is figureoutable.” I put this quote in my office and it gave me some positivity to continue fixing the issue.
When looking at the error log, my experience nudged me to focus on the fetal messages and ignore all the notices and warnings. The mistake I made in the past was wasting time trying to understand those warnings. Meanwhile, the ones that were likely to cause the problem were those labeled “fetal”. Though I found none, a zero HTTP response message hinted at a bigger site-wide issue.
Significant finding: cURL error (77)
I retested all the forms while observing the log. They all yielded an HTTP response of zero. The SMTP plugin and the signup form showed a cURL error (77) when I hit submit. I was on to something here.
Digging deeper, I found that the cURL error (77) referred to an SSL CA cert issue. I visited my client’s web host’s SSL section to see if there was any service expiration notice or error. Then I found a non-secure webmail port warning. This might be it?
Since this error wasn’t caused on my end, I reached out to the web host who serves my client’s website and offers all SSL services. I collected the data and screenshots, made a summary of this error, and reported the web host support team.
The web host’s investigation and forms testing
The web host investigated the case and confirmed my assumption. The solution was to upgrade the SSL CA service to cover the webmail port. I collaborated with my client about the upgrade then came time to test the forms. They worked flawlessly! Every form could be submitted fine; no more zero HTTP response.
My client forwarded me the email signup submission I sent as a test and it was a bingo. The submission looked exactly like the spam emails she had been getting. There was a name field, an email field, and nothing else. The form fields matched the incoming fields. This means the spam emails were not from the contact form but from the email signup form, which lacked reCAPTCHA.
After explaining my findings to my client, I added reCAPTCHA to the signup form. My client has never reached out to me with this issue again.
This debugging experience is both difficult and eye-opening. The problem was flagged from point A, then pulled to point D, diverted to point B, and revealed in point C, before finally untangled. It’s not linear. My emotions were driven like a rollercoaster.
This experience is valuable in many ways. It helped me get better at confronting a website error, learning to solve it by myself first before asking for help, taking a break, documenting the troubleshooting processes, and communicating while simplifying complex problems with the team.
Tell me about your mega website troubleshooting experience that got your brain smashed.