Posted on May 5, 2009 in WordPress by Jeff Starr
The other day, my server crashed and Perishable Press was unable to connect to the MySQL database. Normally, when WordPress encounters a database error, it delivers a specific error message similar to the following:
Posted on May 3, 2009 in Websites by Jeff Starr
Given my propensity to discuss matters involving error log data (e.g., monitoring malicious behavior, setting up error logs, and creating extensive blacklists), I am often asked about the best way to go about monitoring 404 and other types of server errors. While I consider myself to be a novice in this arena (there are far brighter people with much greater experience), I do spend a lot of time digging through log entries and analyzing data. So, when asked recently about my error monitoring practices, I decided to share my response here at Perishable Press, and hopefully get some good feedback concerning best practices for error monitoring. Here is my email response to the question:
Posted on January 21, 2008 in Websites by Jeff Starr
Just a note to web designers and code-savvy bloggers: make sure your custom error pages are big enough for the ever-amazing <cough> Internet Explorer browser. If your custom error pages are too small, IE will take the liberty of serving its own proprietary web page, replete with corporate linkage and poor grammar.
Well, that’s a good question. In order for users of Internet Explorer to enjoy your carefully crafted custom error pages, they need to exceed 512 bytes in size. Using proper doctype markup, your custom pages should include more than around 10 lines (roughly) of additional markup and/or content. A good rule of thumb is to throw down at least a couple of decent-sized chunks of code. If you are going for a minimalist set of custom error pages and need a way to increase overall page size, you can always add a paragraph or two of good ‘ol Lorem Ipsum text as a comment in the markup:
Posted on December 17, 2007 in Function by Jeff Starr
In this brief tutorial, I will show Apache users how to suppress PHP errors from visitors and enable PHP error logging via htaccess.
Tracking your site’s PHP errors is an excellent way to manage and troubleshoot unexpected issues related to plugins and themes. Even better, monitoring PHP errors behind the scenes via private log is far better than trying to catch them as they appear at random visits. Thanks to the magical powers of htaccess, there is an easy way to implement this effective strategy.
In our article, , we discuss a technique whereby PHP errors are suppressed via htaccess. This is done by including the following htaccess directives to your domain’s httpd.conf or to your site’s root (or other target directory) htaccess file:
Posted on August 27, 2007 in Function by Jeff Starr
Recently, I discussed the suspicious behavior recently observed by the Yahoo! Slurp crawler. As revealed by the site’s closely watched 404-error logs, Yahoo! had been requesting a series of nonexistent resources. Although a majority of the 404 errors were exclusive to the Slurp crawler, there were several instances of requests that were also coming from Google, Live, and even Ask. Initially, these distinct errors were misdiagnosed as existing URLs appended with various JavaScript functions. Here are a few typical examples of these frequently observed log entries:
http://perishablepress.com/press/category/websites/feed/function.opendir
http://perishablepress.com/press/category/websites/feed/function.array-rand
http://perishablepress.com/press/category/websites/feed/function.mkdir
http://perishablepress.com/press/category/websites/feed/ref.outcontrolFortunately, an insightful reader named Bas pointed out that the errors were actually PHP functions. Bas explains:
The two functions (
array_randandopendir) you define as javascript functions are PHP functions. Some servers generate clickable links to the php manual (which uses function.NAMEOFFUNCTION in their URL’s) in php scripting error messages. Maybe that’s also the cause of these problems.
Posted on July 1, 2007 in Function by Jeff Starr
There is a major problem with the “Hotlink Protection” feature of cPanel. To summarize the issue, allow me to quote a recent email sent to a completely unresponsive tech support department:
…The problem is that if I try to include any rewrite rules for permalinks, hotlinking, or blocking spambots, cPanel automatically enables its “Hotlink Protection” feature. And, even worse, it automatically adds every URL from every rewrite rule (even the ones for blocking spambots) to its “auto-discovered” list of URL’s for which image access is allowed. This means that every spammer that I am trying to block now has access to my images! If I try to remove the spammers directly from the “allow-image-access” list, the associated rewrite rules are automatically removed from my htaccess file, thus giving spammers full access to my entire site (instead of just access to images). So, it is indeed the case that I can’t add any rewrite rules to my site’s root htaccess file without cPanel automatically assuming that every URL on the page is related to hotlinking and subsequently adding them all to the “allow-image-access” list…
![[ Image: Train Wreck ]](http://perishablepress.com/press/wp-content/images/2007/misc-chunks/cpanel-problem.gif)
In other words, cPanel screws up htaccess rewrite rules via its “Hotlink Protection” feature. More specifically, spammers and robots that are denied site access via root-htaccess rewrite rules are automatically listed in the “allow access to images” field of the Hotlink Protection panel. Not good. Even worse, disabling Hotlink Protection automatically removes every rewrite rule from the htaccess file. Such bizarre functionality forces the user to choose between complete hotlink protection and other essential features such as pretty permalinks or spam blocking. Pretty sucky if you ask us. Nonetheless, here is a concise summary of the problem with the cPanel Hotlink Protection (cHP) feature:
Posted on May 1, 2007 in Presentation, Standards by Jeff Starr
Default DNS Error page for Internet Explorer
First of all, congratulations if you are geeky enough to understand the title of this article. Many would be like, "CSS, MS.. IE, error ..what..?" Whatever. If you get the title, you will get the point of this utterly pointless exercise. If that is the case, prepare for a delightful romp through geekland. Otherwise, save your precious time and stop reading here (exit strategy).
Well, okay, for the seriously unenlightened, let us explain the object of our present focus:
The default "DNS Error" page for Internet Explorer unfortunately remains a familiar sight for millions of Microsoft users. Typically, the default MS DNS Error page loads whenever a browser is unable to connect to the internet or other networked resource. Once loaded, the error page announces itself with a message that reads "The page cannot be displayed." The page then presents several options: refresh browser, retype address, check connection, check configuration, etc. — Monzilla Media (i.e., me)
Still interested? Well, okay. Actually, it’s no big deal. Just a nice, standards-compliant, CSS-based redesign of that old, nappy Internet Explorer 404 Error page. You know the one. Whenever you can’t connect to the internet, it jumps up at you, sticks out it’s tongue and mocks you. Yes, we hate it, too. But alas, with the release of Internet Explorer 7 comes a ‘brand new’ 404 error page. Surely, it’s just a matter of time before that dumpy old 404 error page circa IE5/6 disappears forever. So, before that tragedy unfolds..
Posted on January 15, 2007 in Perishable, Websites by Jeff Starr
This post is hereby dedicated to the official logging of all unresolved and/or unexplained errors encountered during development or implementation of various plugins, extensions, themes, scripts, and/or anything else that results in bizarre and mysterious errors, bugs, or other anomalies. Further, we will also post any potential solutions, fixes, workarounds, or explanations for any errors logged in this post. This information is provided for reference purposes only — please share any related information you may have concerning any of the errors described in this error log. Please use the comment form below or simply contact us directly. Thanks.
Posted on January 1, 2007 in Perishable, Websites by Jeff Starr
In our never-ending battle against spammers, leeches, scrapers, and other online undesirables, we have implemented several powerful security measures to improve the operational integrity of our perpetual virtual existence. Here is a rundown of the new behind-the-scenes security features of Perishable Press:
As you can see, we have been pretty busy around here — fortunately, the new security features have been working flawlessly, reducing stolen bandwidth, potential spam, disobedient robots, and 404 errors. Hopefully, the end result of these new features will involve smoother site functionality and better browsing for everyone.
Posted on April 3, 2006 in Function by Jeff Starr
A list of HTTP Error codes and corresponding definitions:
Informational Codes
Successful Client Requests
Client Request Redirected
Client Request Errors
Server Errors
Posted on September 25, 2005 in Nothing by Jeff Starr
There has been an internal server error.
Posted on September 24, 2005 in Nothing by Jeff Starr
Sorry, we were unable to find the requested resource.
Posted on September 23, 2005 in Nothing by Jeff Starr
You do not have the proper Authorization.
Posted on September 21, 2005 in Nothing by Jeff Starr
You do not have the proper Authorization.
Posted on September 20, 2005 in Nothing by Jeff Starr
There has been a bad request.