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:

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

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

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.

Hide PHP errors from visitors

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:

Continue Reading

Harvesting Raw Logs For those of us using cPanel as the control panel for our websites, a wealth of information is readily available via cPanel ‘Raw Access Logs’. These logs are perpetually updated with data involving user agents, IP addresses, HTTP activity, resource access, and a whole lot more. Here is a quick tutorial on accessing and interpreting your cPanel raw access logs.

Part One: Grab ‘em

To grab a copy of your raw access logs, log into cPanel and click on the "Raw Access Logs" icon. Within the Raw Access Log interface, scroll through the list of available log files and download the raw access log(s) of your choice.

Exit cPanel and navigate to your local copy of the raw access log, which should have been downloaded as a zipped/g-zipped file (i.e., .zip or .gz file extension), with a name similar to accesslog_your-domain.com_4_20_2007.gz.

Unzip the file and extract its contents, which should be a single file named your-domain.com. Rename the file by appending a .log or .txt extension to the file name. Alternatively, if the file is not named with a .com, .net, or .whatever extension, no rename is necessary, as it also may be opened via right-click » ‘Open With…’.

That’s all there is to it. If you understand how to interpret the contents of your Raw Access Log, you’re solid gold, baby. Otherwise, continue reading for a breif tutorial to get you started with the basics..

Continue Reading

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.

Continue Reading

Note to self: Here is the .htaccess code for creating an Apache Rewrite log. This is definitely helpful for testing .htaccess rewrite rules, permalinks, etc. Update: as jc points out in the comments section, Apache versions 2.2 or better no longer allow RewriteLog directives in htaccess files. For these versions, it is necessary to coordinate logging through the server configuration file or via virtual host. For more information, check the source. For pre-2.2 versions of Apache, continue reading to learn how to Roll your own Apache Rewrite Log!

via http.conf

Twist one up via the Apache configuration file by placing this code at the foot of your http.conf (remember to edit the path):

# Roll your own Rewrite log
# Log details via scale of 1 to 9
# 1 = few details, 5 = enough details, 9 = too much detail
RewriteEngine On
RewriteLog "/absolute/path/to/your/wwwroot/public_html/rewrite.log"
RewriteLogLevel 5

via htaccess

Roll one tuf via your site’s root .htaccess by placing this code at the end of the file (remember to edit the path):

# Roll your own Rewrite log
# Log details via scale of 1 to 9
# 1 = few details, 5 = enough details, 9 = too much detail
RewriteEngine On
RewriteLog "/absolute/path/to/your/wwwroot/public_html/rewrite.log"
RewriteLogLevel 5

Example

Here is an example indicating the type of data logged by the RewriteLog directive:

64.246.32.000 - [07/July/2007:07:07:07 - 0700] [example.com/sid#80077333][rid#800b7a33/initial] (2) init rewrite engine with requested uri /press/wp-comments-post.php
64.246.32.000 - [07/July/2007:07:07:07 - 0700] [example.com/sid#80077333][rid#800b7a33/initial] (2) rewrite /press/wp-comments-post.php -> http://64.246.32.000/
64.246.32.000 - [07/July/2007:07:07:07 - 0700] [example.com/sid#80077333][rid#800b7a33/initial] (2) explicitly forcing redirect with http://64.246.32.000/
64.246.32.000 - [07/July/2007:07:07:07 - 0700] [example.com/sid#80077333][rid#800b7a33/initial] (1) escaping http://64.246.32.000/ for redirect
64.246.32.000 - [07/July/2007:07:07:07 - 0700] [example.com/sid#80077333][rid#800b7a33/initial] (1) redirect to http://64.246.32.000/ [REDIRECT/301]

Introduction

Search engine optimization (SEO) is the business of every serious webmaster. The process of optimizing a website for the search engines involves much more than properly constructed document headers and anchor tags. Websites are like trees: their roots are the growing collection of content presented through the branching universe of the World Wide Web. Or something. The point is that optimizing a website requires nurturing the site itself while also ensuring proper exposure to the requisite elements of the internet.

The process of optimizing your first website may seem daunting. There are many aspects to consider and many websites with which to deal. Search engine registration, keyword development, and an evolving link campaign are all required for any home-grown, roll-your-own website optimization. Further, for each site you intend to optimize, there is a plethora of related data — site links, usernames, passwords, email addresses, etc. — that needs to be collected, organized, and updated. Therefore, it is essential to properly record and consistently maintain a carefully crafted SEO log.

Continue Reading