WordPress Problems #3 (Solved a classic forgehe problem)

EDIT: I didn’t actually post my WordPress Problems #2, which just gave a short explaination on server caching, and how browsers know how long to keep the data. The issue is solved now, so the previous post is now pretty useless. I’m keeping the naming scheme the same, because I do like my #2 post, but I don’t want to finish that post right now.

I really need to start debugging my problems a lot slower. Or maybe actually take some sort of class on debugging instead of mindlessly copying and pasting code around.

Well, the caching problem had been fixed. My Dashboard works without mad refreshing, pages properly update, I don’t have to “Hard Reset and Clear Cache” every time a redirect goes wrong (like installing a plugin). The culprit? A single line of code.

This was all because of a single line of code that I repeatedly missed while going over my nginx configuration.

This happens so often to me I’m going to call it a “forgehe problem” from now on. In the block of code that directs php pages to the fast-cgi php hamdler whatever-the-heck, I had a single line right underneath that: “expiry 30d;”.
I missed that. For hours upon hours of debugging, I missed that.

I don’t remember typing that. I don’t remember copying pasting that. I have no idea how that line of code came into existence. But I must have introduced it somehow. Most likely through a careless copy paste, or possibly some prior testing of caching that was never reverted.
Anyways, the problem is fixed now.

How could I have fixed the issue faster?

I had a couple of ideas after the fact.
One detail that I overlooked before was the expiry time, 30 days. Now, to my knowledge, the only thing I had set to a 30 day expiry was for images, and other media files, but that shouldnt have stopped me from ctrl-f’ing for check for other instances, and immediatly finding the problem.

The most basic issue here was skipping blocks of code I thought I knew what they did. I would only glance at the php handling code because it only had one task to do, sent php scripts to the php handler. But just because I told it to do only one task didn’t mean that it could only do one task. I also skipped the php code because it was code that I wasn’t really familiar with, so I wanted to mess with it as less as possible. Familiarizing myself with the code might’ve helped me.

Looking at logs. I didn’t check any logs of any sort, be it nginx or php logs, due to my laziness to scroll through pages of irrelevant logs to find the relevant parts, and boy did that cost me.

PS: A quick sneek peak on what’s coming soon onto the blog: I recently attended CES 2019, and had a couple of friends ask about my experiences there. So I’ll be posting my experiences at CES 2019 on this blog soon.

Leave a comment