Tam Nguyen Photography

New York Beauty and Fashion Photographer

iFailed – I Hate WordPress

Posted on December 10, 2010 in Personal

iFailed – I Hate WordPress

I hate WordPress. It’s one of the most stupid things I’ve ever had to deal with. Whoever invented it must have been on crack.

Okay, I lied; I take it back. I think WordPress is one of the coolest things I’ve seen. Once you download and install it, you can customize it to the max; or, if you want, you can just let it be, because it works right out of the box…

Except for when it doesn’t. Or maybe it does, but Facebook is just not playing nice. Or, maybe I’m just not smart enough to figure this whole thing out. Or it’s simply all of the above.

Here’s how the triangular love-hate between me, Facebook and WordPress began:

You know when you share a link on Facebook, you drop it in your status box, and Facebook parses and fetches the link’s content, along with the thumbnail image right next to the post? Well, that’s not what happened here. Instead, all I got was the URL, the link’s content underneath my name, but without the thumbnail. This was driving me crazy because everything appeared perfectly fine on my site; so I had to figure out why it was doing that.

Facebook post

When in doubt, look at the source code. This is what I saw:

<img class=”img” src=”http://external.ak.fbcdn.net/safe_image.php?

Yeah, okay that’s a bunch of gibberish. But if you look at it closely, you’ll notice that the thumbnail is being called from Facebook’s safe_image.php file, which takes in the thumbnail’s source URL as an argument. Take closer look, you’ll see that the thumbnail image is being created dynamically by my theme’s file called timthumb.php.

Okay, so the problem might be because Facebook is doing some cross-site scripting checking to make sure I’m not doing anything crazy to their site, that’s understandable. However, timthumb.php might be the one who was actually doing that checking. So, naturally, I looked into timthumb.php to see what I can do to “hack” it. Nothing interesting came up, except for the author’s website, and the fact that my version is a few iterations behind. Well, let’s update the bad boy then, shall we? I backed up my version, went to the author’s site, grabbed his latest version, and then overwrote my version… Nope, that didn’t work. I still had the same problem.

I went back to my site, looked at the thumbnail’s source URL, and this is what I saw:


Okay, what the hell is this ic.b9c300ea975508c9bb47eb8bd273d073.136x136x doing in front of the function call? It looks like some sort of a random string created either by CRC or MD5 for caching purposes. I took another look at timthumb.php, it seems the author did you some caching feature, but he modified the entire file name based on its name and DOCUMENT_ROOT to ensure uniqueness; he does nothing to the function’s name itself. When I tried using absolute path as an argument to that function call, it works fine with Facebook’s share. The thing just wasn’t happy with relative path. This pretty much eliminates the problem being timthumb.php, since it has no problem generating the thumbnails from anywhere.

Ah, maybe it’s the caching feature that I’d enabled on my site. My site has a content deliver network (CDN), which hosts all the media files from a virtually different server to help the load time, which helps my Google page rank. Talk about search engine optimization (SEO) to the max! I cleared the cache on the CDN server as well as the main server. No help. Dammit, I thought I had it for sure.

It’s not the cache, not the function call, maybe it’s the theme? I tried a different theme with no luck; the random stupid string is still there. I was about to lose all of my patience at this point. You know what, let’s just start this thing from scratch and see what happens. I downloaded WordPress 3.0.3 to a test site, copied my theme over, fired it up, posted a test, everything was fine. Next, let’s restore the database on the test site. BOOM! It broke. Oops, I didn’t realize that the database has information about my blog’s URL, which points to the main site, not the test site. Crap, okay, here we go, let’s take a trip to the database and modified the blog’s URL. Fixed. Now let’s share a test link on Facebook and see what happens…. Uhm no, still had the same issue; my thumbnail isn’t displayed on Facebook’s post.

At this point, there are 2 things left that could be the root cause: either WordPress itself, since I upgraded it from 3.0.1 to 3.0.3 within the past few days, or it’s the actual database, in which case I’m toast. I tried reverting WordPress back to 3.0.1 with no luck. Well, safe to say it’s the database. No worries, I have the weekly backups emailed to me, I can just restore the one right before the upgrade and everything will be back to normal again. Well, no, failed. That random stupid string ic.b9c300ea975508c9bb47eb8bd273d073.136x136x is still there. Sigh.

One last thing, let’s just remove ALL the plugins I have installed, run the thing as if it was just installed with the default and ugly theme. No go. Nice try though, me.

A few days have passed since I started having this bug, and there’s nothing I can do to debug it. The only workaround is to use an absolute path when inserting a thumbnail to my blog entry instead of relative path. I guess this is going to have to do for now. Maybe it’ll solve itself someday. Haven’t you heard? Problems tend to solve themselves when left unattended long enough. There, that’s my solution, temporarily, I think. I might just come back at this later on and look at it from a different angle, if there’s any.

In the meantime, if you have any suggestions, fire away, I’m all ears.

Leave a Reply

Your email address will not be published. Required fields are marked *