I have been wanting to write about 404 error pages for quite awhile now. They have always been very important to me, with customized error pages playing a integral part of every well-rounded web-design strategy. Rather than try to re-invent the wheel with this, I think I will just go through and discuss some thoughts about 404 error pages, share some useful code snippets, and highlight some suggested resources along the way. In a sense, this post is nothing more than a giant “brain-dump” of all things 404 for future reference. Hopefully you will find it useful in pimping your own 404.

When requested page is not found by server, error message is returned; this is the essence of the 404 — Ancient Chinese proverb

Continue Reading

Note: This information is intended primarily for WordPress versions previous to 2.3, but may be applicable in other versions as well.

For those of you running an older version of WordPress that is generating errors such as:

Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067

You can easily resolve the issue by suppressing these errors, which are automatically generated whenever the parse_url() function tries to parse an empty value for the URL. To silence the errors, open the file wp-includes/functions.php and locate the following code (around line #1067):

Continue Reading

For the past several months and up until just recently, Perishable Press had been suffering from unpredictable episodes of the dreaded white screen of death. Although blank white screens happen to virtually all WordPress users now and then, certain configurations seem to trigger crashes more frequently than others. Here, I am referring to WordPress version 2.3.

In this case, the unpredictable crashes, inconsistent errors, and general instability began several months ago after I had completed my WordPress theme restoration project. Prior to that, I had removed all of my alternate themes and placed them on a subdomain. Meanwhile, after the themes had been removed, I decided to enable the default WordPress cache (don’t ask why). For the next month or so, before restoring my themes, my site performed exquisitely: uptime at 99% (on a shared server, no less), virtually no errors, and so on. Then, after restoring alternate theme functionality, the site began locking up and crashing multiple times each day. Here is a summary of the sequence of events (estimated time frames):

Continue Reading

I need your help! I am losing my mind trying to solve another baffling mystery. For the past three or four months, I have been recording many 404 Errors generated from msnbot, Yahoo-Slurp, and other spider crawls. These errors result from invalid requests for URLs containing query strings such as the following:

• http://perishablepress.com/press/page/2/?tag=spam
• http://perishablepress.com/press/page/3/?tag=code
• http://perishablepress.com/press/page/2/?tag=email
• http://perishablepress.com/press/page/2/?tag=xhtml
• http://perishablepress.com/press/page/4/?tag=notes
• http://perishablepress.com/press/page/2/?tag=flash
• http://perishablepress.com/press/page/2/?tag=links
• http://perishablepress.com/press/page/3/?tag=theme
• http://perishablepress.com/press/page/2/?tag=press

..plus hundreds and hundreds more ¹. The URL pattern is always the same: a different page number followed by a query string containing one of the tags used here at Perishable Press, for example: “/?tag=something”. The problem is that there are no such links anywhere on the site. The site employs permalink format for all WordPress-generated links (e.g., post/page links, search queries, tag queries, etc.). In an effort to locate the source of these URLs, I have performed multiple, thorough searches through every aspect of my site (files, database, code, examples, etc.), and the results are always the same: nothing. UGH! What is the source of these misguided URLs? Hopefully, you will be able to help shed some light on this unexplained crawl behavior (please, I beg you!!).

Continue Reading

After several years of using WordPress, I have at least three unanswered questions:

• What’s up with the WordPress PHP Memory Error?
• Why do certain phrases trigger “Forbidden” errors when saving or publishing posts?
• What happened to the Plugin Pages in the WordPress Codex?

Let’s have a look at each one of these baffling mysteries..

Continue Reading

We all know how important it is to deliver sensible, helpful 404 error pages to our visitors. There are many ways of achieving this functionality, including the well-known htaccess trick used to locally redirect users to custom error pages:

# htaccess custom error pages
ErrorDocument 400 /errors/400.html
ErrorDocument 401 /errors/401.html
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html

..and so on. These directives basically tell Apache to deliver the designated documents for their associated error types. Many webmasters and developers employ this trick to ensure that visitors receive customized error pages that are generally more user-friendly or design-specific than the rather unfriendly Apache defaults. Serving custom error pages is an excellent way to enhance overall site usability and accessibility, but there are several other useful techniques to consider as well.

Continue Reading

During the recent ASO server debacle, I raced frantically to restore functionality to Perishable Press. Along the way, one of the many tricks that I tried while trying to fix the dreaded “white screen of death” syndrome involved increasing the amount of PHP memory available to WordPress. This fix worked for me, but may not prove effective on every installation of WordPress. If you are unsure as to whether or not you need to increase your PHP memory, consult with your host concerning current available memory ¹ and overall compatibility with a localized increase. Note that if your blog is running fine, there is probably no need to employ this solution. I recommend this change only if you are experiencing PHP-related and/or PHP memory issues associated with any of the following:

Continue Reading

This trick isn’t guaranteed to prevent all WordPress-generated PHP memory errors, but it certainly seems to help reduce their overall occurrence. For some reason, after my host upgraded their servers to Apache 1.3.41, I began logging an extremely high number of fatal PHP “memory exhausted” errors resulting from the WordPress cache.php script. Here is an example of the countless errors that are generated:

Continue Reading

In my previous articles on PHP error handling, I explain the process whereby PHP error handling may be achieved using htaccess. Handling (logging, reporting) PHP errors via htaccess requires the following:

• Access/editing privileges for htaccess files
• A server running PHP via Apache, not CGI (e.g., phpSuExec) ¹
• Ability to edit/change permissions for files on your server

If you are having trouble handling PHP errors using htaccess, these three items are the first things to check. If it turns out that you are unable to use htaccess to work with PHP errors, don’t despair — this article explains how to achieve the same goals using local php.ini files. To implement this strategy, the following is required:

Continue Reading

In my previous article on logging PHP errors, How to Enable PHP Error Logging via htaccess, we observed three fundamental aspects of preventing, preserving, and protecting your site’s PHP errors:

Prevent public display of PHP errors via htaccess

# supress php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0

Preserve (log) your site’s PHP errors via htaccess

# enable PHP error logging
php_flag  log_errors on
php_value error_log  /home/path/public_html/domain/PHP_errors.log

Protect your site’s PHP error log via htaccess

# prevent access to PHP error log
<Files PHP_errors.log>
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

Now, in this article, we will explore these operations ² in greater depth, provide additional functionality, and examine various implications. First we will explore PHP error handling for production environments (i.e., for websites and applications that are online, active, and public), then we will consider error handling for development environments (i.e., for projects that are under development, testing, private, etc.).

Continue Reading

Alrighty then! Looks like recent changes to site structure have really dropped a bomb on quite a few regular visitors out there. After switching over to the new default theme last night, I had setup an email notification system to alert me of all errors encountered at this domain (i.e., the main site and all test sites). Of course, I knew that at least a few errors would be inevitable, but I had no idea that I would receive nearly 300 of them!

After examining the nature of these errors, it appears that the bulk of them are the result of either Google showing confusion over the new image directory structure, or people visiting the site with a browser cache full of old theme files. Apparently, a few visitors were actually using some of the alternate themes that I had provided via the previous default theme. So, now that the alternate themes have been removed (temporarily, for a few months), visitors are experiencing errors when they visit the site. Uhh, not so good, especially for them.

Continue Reading