Update (2020-02) – Timthumb is now a deprecated technology in favour of better image resizing methods that are more robust and secure. While I’m glad this article helped many of my fellow industry people, you shouldn’t be using it anymore!
. . . .
We recently migrated some of our websites to a new VPS with Inmotion hosting. After the migration, everything went smooth (pretty much.. but as smooth as a server transfer can be), except one issue – all the timthumb.php scripts were not working well in WordPress, which meant that blog thumbnails were not generating.
. . . .
This happened on this very blog (www.jeffkee.com) as well. So then I went to check other things out, and found out that other .php scripts that run from within the wp-content/themes/ folder were not working either! So, the problem was not just timthumb.php, but rather, all .php files within the folder. I tried restarting apache, and the server. No dice.
So I finally looked into the apache error logs, and bingo:
[Thu Feb 04 01:56:02 2010] [error] [client 174.6.169.139] SoftException in Application.cpp:610: Directory “/home/sonikas/public_html/wp-content” is writeable by others
[Thu Feb 04 01:56:02 2010] [error] [client 174.6.169.139] Premature end of script headers: timthumb.php
[Thu Feb 04 01:56:07 2010] [error] [client 174.6.169.139] SoftException in Application.cpp:610: Directory “/home/sonikas/public_html/wp-content” is writeable by others
[Thu Feb 04 01:56:07 2010] [error] [client 174.6.169.139] Premature end of script headers: test.php
So yes, some servers have more advanced PHP security set up, so that PHP files cannot run from within folders that are writable by others.
Many of us have the common (and bad) habit of setting the permission to 777 for folders that should be writable by our PHP applications. However this is not the case. It must be set to 755, in which the “group” and “others” users cannot write the folder.
The “Premature end of script headers” error happens when the script stops running before it outputs the content type headers and dates etc. In any file served through a browser, the content type and other items are defined even before the first string of the file (for example, <html>) are fed out. So when this failed, it returned a 404 error, which in turn triggered WordPress to default to the 404.php error page!
So the lesson here: instead of 777, let’s use 755 for folders that need to be modified/written by your PHP scripts.
I had help from a great guy at StackOverflow.com (username jsalonen). Without his guidance of the server error log locations I would not have figured this out anytime soon. Please see the original question at StackOverflow.com.
