I debugged a page live with a client, who’s also a WordPress developer.
This was my first time debugging a website issue with a client during a Zoom call. Although I couldn’t solve it on the spot, it taught me an important lesson: it’s okay to not know everything, as long as you’ve done due diligence and made an effort to understand the situation afterward.
For the context:
This project happened in 2023 and was about designing a homepage and turning it into a template for future uses on other pages. I was referred to the client, Cheryl Marlene, through a friend who went to the same Business program at the University of Washington.
Cheryl, an Akashic Mystic, sought my help in improving the outdated homepage design and reusing the design as a template for other pages. (Note: As of March 2024, she has completely changed her homepage design.)
I was excited to start the project as it would be my first paid web design project (in addition to web development). Cheryl also used GenerateBlocks as a page builder, a tool I looked forward to trying out more.
Another cool fact: Cheryl is a web developer herself, dating back to the 90s when I was still a toddler. This would be an interesting project and already made me feel relieved even before starting.
75% into the development process,
I ran into a problem. I used a reusable element in one section of the new homepage. When I viewed the page in a browser, it crashed. When I tried to edit the page, it also crashed. Uh oh.
I turned on debug mode and viewed the error log. The fatal error indicated exhausted PHP memory. Strange. The reusable button I put in the section shouldn’t cause this. But, based on my experience, the limitless editing revisions of the page might.
After explaining the situation to Cheryl, I asked her for permission to increase the PHP memory limit and potentially optimize her database tables. She was nervous about the operations and didn’t permit me right away.
We hopped on a Zoom call to discuss more and go through the process together.
Troubleshooting problems with the client.
I embraced the fact that we were about to debug things together. It’s something I usually do behind closed doors, carrying all the concerns alone. In this case, Cheryl was with me, probably with more debugging experience and deeper knowledge of the WordPress ecosystem.
Before doing anything, I made sure we had all the website backup files ready to be restored if anything went wrong.
Then we began debugging the issue.
- We increased the PHP memory limit. The error was still there.
- We limited the number of post revisions. The error was still there.
- We optimized the website by deleting trashed posts, and spam comments, and optimizing database tables. The error never went away.
I had a bad feeling that I might misdiagnose the issue in the beginning.
At that point, Cheryl had to leave the call for another obligation. Although I couldn’t solve the problem on the spot while she witnessed, her presence brought a sense of relief and that things would be okay.
I revisited the troubled homepage and compared it with other pages. I found that I could still view and edit other pages without a problem. That meant the issue was contained within this new homepage I built. That’s why none of the optimizations I did for the entire site fixed the problem.
After inspecting and testing each element on the page, the culprit was revealed. It was the button I made using Reusable Blocks (a button made reusable in other parts of the page/site). When I removed this button, the error was gone.
I looked for a way to troubleshoot or avoid this issue of Reusable Blocks, but online solutions, at that time, were quite divided. Some complained the type of the element is too fragile. So I decided to use a normal-type button rather than the reusable type and informed Cheryl of my finding.
Error was gone, here’s what lingered.
I carried out the project and it was a happy ending for both Cheryl and me.
What I found most memorable about this project was my courage to debug the issue in front of my client. If I were still a newbie developer, I wouldn’t have been bold enough to do it because I’d sure be making a fool of myself. Though I’m still far from being a WordPress wizard, I felt confident enough to lead the process. My confidence was based on my experience, research, and structured troubleshooting steps. While it didn’t guarantee a bug fix, it showed I genuinely cared to solve the problem and did my research. In the end, that’s the moment my client would remember. As a bonus, fixing the problem successfully earned me even more trust from the client.
Have you ever troubleshot a technical problem in front of, or alongside, a client? If so, how did it go?