Posted on September 15, 2008 in Websites by Jeff Starr
An ongoing series of articles on the fine art of malicious exploit detection and prevention. Learn about preventing the sneaky mischievous and deceptive practices of some of the worst spammers, scrapers, crackers, and other scumbags on the Internet.
Posted on August 25, 2008 in WordPress by Erika Kendall
![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/conditional-tags.gif)
More and more these days, we are all finding WordPress being used as a content management system. It shouldn’t be too tough to see why — highly customizable, a community growing in size and knowledge, and a plethora of options in the way of plugins and simple yet highly effective PHP edits. Thanks to these, you have access to an open source script that allows you to show what you want, when you want, where you want, and how you want in virtually no time. But what happens when you only want a simple variation from one page to the next?
Posted on August 4, 2008 in WordPress by Jeff Starr
Most WordPress-powered blogs display posts in sequential order within a single column. Like this, for example:
![[ Diagram: Default WordPress Post Display Order ]](http://perishablepress.com/press/wp-content/images/2008/horiz-order/horizontal-order_default.gif)
Posted on July 29, 2008 in WordPress by Jeff Starr
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 1067You 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):
Posted on July 21, 2008 in WordPress by Jeff Starr
![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/wp-title-deco.gif)
Keeping an eye on all things WordPress, I have noticed an ongoing fascination with configuring the ultimate WordPress <title> tags. Many bloggers use various plugins to generate differently configured <title> tags depending on particular page views. A good example of this is seen in the All in One SEO Pack, which, among many other things, enables users to specify custom titles for several different types of pages. While there is nothing wrong with this approach, some of us prefer to run WordPress with as few plugins as possible. If you want to create perfect WordPress title tags without a plugin, this post will certainly help you do it. First we’ll explore some of the basics, continue with some common examples, and then conclude with a comprehensive, highly flexible script for generating distinct page titles. All of the techniques presented in this article should work well with virtually all versions of WordPress.
The <title> tag is used within the <head> section of (X)HTML pages to communicate the title of the document to both humans (your visitors) and machines (search engines). For dynamically generated sites, such as those powered by WordPress, many different types of pages exist, including:
Posted on July 8, 2008 in WordPress by Jeff Starr
Just a quick WordPress snippet for future reference. I recently explained how to disable comments, pingbacks, and trackbacks via SQL. Here’s a good way to do it via PHP:
<?php
function close_comments( $posts ) {
if ( !is_single() ) { return $posts; }
if ( time() - strtotime( $posts[0]->post_date_gmt ) > ( 30 * 24 * 60 * 60 ) ) {
$posts[0]->comment_status = 'closed';
$posts[0]->ping_status = 'closed';
}
return $posts;
}
add_filter( 'the_posts', 'close_comments' );
?>You can run this script as a plugin, through your theme’s functions.php, or through a custom user-functions.php file. Simply set the desired number of days by changing the number “30” to whatever you would like. As is, this script will close comments, pingbacks and trackbacks on all articles posted more than 30 days ago.
Posted on July 7, 2008 in WordPress by Jeff Starr
![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/themes-deco.gif)
As you may observe, the WordPress installation that powers Perishable Press is located in a subdirectory named press. This configuration was intentional, as I wanted to have the option to easily install and maintain multiple versions of WordPress in variously named subdirectories. As much as I enjoy this flexibility, many would argue the SEO-related benefits of installing WordPress in your site’s root directory, or at least making it appear that way by using WordPress’ easily customizable “Blog Address” options setting.
For example, say you have WordPress installed in a subdirectory called “gibbonz”, but you want your blog’s home page to exist at http://your-domain.tld/ and not http://your-domain.tld/gibbonz, as would be the case by default. To make this happen, you have several choices, including this method, which I summarize here, assuming the “gibbonz” scenario outlined in the preceding discussion:
Posted on June 16, 2008 in WordPress by Jeff Starr
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):
Posted on May 31, 2008 in Function by Jeff Starr
Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..
![[ Photo: Bob Barker waves at you ]](http://perishablepress.com/press/wp-content/images/2008/blacklisted/2008-05-31.jpg "Goodbye, pathetic cracker whores!")
Just under the wire! Even so, this month’s official Blacklist-Candidate article may be the last monthly installment of the series. Although additional BC articles may appear in the future, it is unlikely that they will continue as a regular monthly feature. Oh sure, I see the tears streaming down your face, but think about it: this is actually good news. After implementing the 3G Blacklist, finding decent blacklist candidates is becoming increasingly difficult. This is a good thing because it indicates that the new blacklist strategy is working. Nonetheless, every now and then, some brainless bozo will magically appear and poke around where it shouldn’t be poking. Such is the case with this month’s Blacklist Candidate Number 2008-05-31:
Come on down! You’re the next worthless turd to get banished from the site!
Posted on April 27, 2008 in Function by Jeff Starr
Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..
![[ Photo: Bob Barker Snarls at Rod Roddy ]](http://perishablepress.com/press/wp-content/images/2008/blacklisted/2008-04-27.jpg "Go to the clam store and git some contestants, dammit!!")
Since the implementation of my 2G Blacklist, I have enjoyed a significant decrease in the overall number and variety of site attacks. In fact, I had to time-travel back to March 1st just to find a candidate worthy of this month’s blacklist spotlight. I felt like Rod Roddy looking over the Price-is-Right audience to announce the next name only to discover a quiet, empty room. And then like Bob gets pissed that nobody showed up and begins to bark and snarl at Rod to go across the street to the clam store and find some damn contestants. Or, ..um, something like that. Needless to say, this month’s data isn’t as fresh as I would have liked it, but I think you’ll find the information fascinating nonetheless. So let’s get on with it then:
Blacklist Candidate number 2008-04-27, come on down! You’re the next clam-store loser to get blacklisted from the site!
Posted on April 16, 2008 in Function by Jeff Starr
Recently, while restoring my collection of Perishable Press themes, I needed a fast, effective way to randomize a series of images. After playing around with several likely candidates, I finally devised the following drop-dead easy technique:
<img src="http://domain.tld/path/random/image_<?php $random = rand(1,n); echo $random; ?>.png" alt="[ Random Image ]" height="50" width="50" />This single line of code facilitates the random display of n number of images (image_1.png, image_2.png, image_3.png, etc.) located in the target directory (http://domain.tld/path/random/). For those of you that understand how this works, great! That’s pretty much the entire purpose of this article. However, for those that would appreciate some further explanation, let’s examine this technique in a little more detail (you have been warned!)..
Prepare any number of images of the same file type (e.g., .png, .jpg, .gif, etc.) and name them numerically. You can name your images just about anything you like, so long as the only difference between each name is a single numerical digit. Further, ensure that the numerical digits begin with zero and proceed in order to the total number of images in the set. For example, assuming you have three .png images, any of the following name sequences is perfectly acceptable:
Posted on April 8, 2008 in WordPress by Jeff Starr
After several years of using WordPress, I have at least three unanswered questions:
Let’s have a look at each one of these baffling mysteries..
Posted on March 26, 2008 in Function, Standards by Jeff Starr
![[ ~:{*}:~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/negotiation-deco.gif)
In this article, I discuss the different MIME types available for XHTML and explain a method for serving your documents with the optimal MIME type, depending on the capacity of the user agent. Using either htaccess or PHP for content negotiation, we can serve complete, standards-compliant markup for our document’s header information. This is especially helpful when dealing with Internet Explorer while serving a DOCTYPE of XHTML 1.1 along with the recommended XML declaration.
According to the RFC standards 1 produced by IETF 2, web documents formatted as XHTML 3 may be served as any of the following three MIME types:
Posted on March 22, 2008 in Blogging, WordPress by Jeff Starr
Alright, time for another “How’d-you-do-that-thing-on-your-site?” post. This question comes from the one and only Mr. Graham of ImJustCreative.com. In a recent email, Graham literally begged me to share my “secret recipe” for displaying my latest Twitter Tweets (wow, did I actually just say that?) right here on Perishable Press:
…Would be really really decent of you if you could let me know how to do it? Pretty please? How do you call the last twitter feed, what commands do you need etc?
In case you have no idea what we’re talking about here, scroll down to the bottom of any page on the site (using the current theme) and observe the savviness and sophistication of my latest Twitter post, updated automagically every fifteen minutes. Or, for those of you too lazy to “go there,” here is a screenshot demonstrating the perpetual Twitter display:
Posted on March 18, 2008 in Function by Jeff Starr
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.
Posted on March 17, 2008 in WordPress by Jeff Starr
After upgrading WordPress from version 2.0.5 to 2.3.3, I did some experimenting with the “post autosave” feature. The autosave feature uses some crafty ajax to automagically save your post every 2 minutes (120 seconds by default). Below the post-editing field, you will notice a line of text that displays the time of the most recent autosave, similar to the following:
![[ Screenshot: WordPress Autosave Message (Saved at 2:34:02.) ]](http://perishablepress.com/press/wp-content/images/2008/wp-autosave/time-saved.gif "WordPress automatically saves your work every two minutes")
Surely, this relatively new feature provides an added layer of protection against lost work, but all is not perfect (yet) in the world of automatically saved content.
Several months ago, I lost several hours of work because the autosave feature completely failed to work, despite the periodically reassuring “Saved at..” message. After working for several hours with a false sense of security, WordPress choked and my post had vanished. In shock, I scoured the database for any trace of my recent efforts, but to no avail. The entire post had disappeared into the void. Utterly devastated and disillusioned, I decided to investigate the so-called “autosave” feature, learn what had happened, and take steps to avoid such travesty in the future. Here is a summary of my investigation..
Posted on March 8, 2008 in Function by Jeff Starr
Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..
![[ Photo: Bob Barker Looking Sharp ]](http://perishablepress.com/press/wp-content/images/2008/blacklisted/2008-03-09.jpg "Come on down! You're the next contestant on the 'Blacklist is Right'!")
Imagine, if you will, an overly caffeinated Bob Barker, hunched over his favorite laptop, feverishly scanning his server access files. Like some underpaid factory worker pruning defective bobble heads from a Taiwanese assembly line, Bob rapidly identifies and isolates suspicious log entries with laser focus. Upon further investigation, affirmed spammers, scrapers and crackers are swiftly blacklisted from future access. For the most heinous offenders, we suddenly hear Rod Roddy’s guzzling voice echo throughout the room:
“Candidate number 2008-03-09, COME ON DOWN!! — you’re the next contestant to get blacklisted from the site!”
Every week, I dig through my access and error logs to learn from the spammers, scrapers, and other cracker whores. Typically, attempts to exploit potential security vulnerabilities demonstrate the following characteristics:
Posted on February 19, 2008 in WordPress by Jeff Starr
![[ ~:{*}:~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/php-memory-deco.gif)
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 1 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:
Posted on February 17, 2008 in WordPress by Jeff Starr
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:
Posted on February 10, 2008 in Function by Jeff Starr
Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..
![[ Photo: Bob Barker points a finger ]](http://perishablepress.com/press/wp-content/images/2008/blacklisted/2008-02-10.jpg "Come on down! You're the next cracker whore to get blacklisted!")
Scumbag number 2008-02-10, “COME ON DOWN!!” — you’re the next baboon to get banished from the site!
Like many bloggers, I like to spend a little quality time each week examining my site’s error logs. The data contained in Apache, 404, and even PHP error logs is always enlightening. In addition to suspicious behavior, spam nonsense, and cracker mischief, this site frequently endures automated and even manual attacks targeting various XSS exploits, WordPress vulnerabilities, and other potential security holes. Although the number of successful attacks remains relatively small, the very nature of some of the attacks serves to threaten site performance, security and stability. Such is the case of blacklist candidate number 2008-02-10: IP address 128.111.48.138.
Posted on February 4, 2008 in Optimization by Jeff Starr
![[ Image: Global Map Icon ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/google-analytics_.gif)
It has occurred to me lately that I no longer use Google Analytics for Perishable Press. Instead, I find myself keeping an eye on things using Mint almost exclusively. So, the question now is: do I continue serving the GA JavaScript to keep the profile active just in case I ever need the additional stats? I mean, Mint already does a great job at recording all of information I could ever need, so I no longer see the use for Google Analytics. I do wonder, however, if Google ranks GA-enabled sites a bit higher than non-GA sites. Hmmm.. it seems to me that there are several options going forward..
The easiest thing for me to do at this point would be to just leave it alone: continue serving the extra 6.3K/21.4K GA JavaScript (i.e., urchin.js) to site visitors. Sure, I may never actually use the volumes of data I am collecting via Analytics, but hey, who cares, right? Of course, delivering the urchin.js file requires bandwidth and other server resources, and also tends to slow things down a bit, especially on those rare occasions when the Google server bogs down.
Posted on January 30, 2008 in Function by Jeff Starr
![[ ~{*}~ ]](http://perishablepress.com/press/wp-content/images/2008/misc-chunks/php-error-deco.gif)
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:
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:
Posted on January 23, 2008 in Function by Jeff Starr
Here is an example of one of the most frequently asked PHP/htaccess-related questions I receive here at Perishable Press:
How do I redirect a specific page/URL using PHP/htaccess?
So common is this inquiry that I have decided to just post a quick, “one-minute” tutorial describing the technique.
Posted on January 14, 2008 in Function by Jeff Starr
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:
# 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# enable PHP error logging
php_flag log_errors on
php_value error_log /home/path/public_html/domain/PHP_errors.log# 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 2 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.).
Posted on January 2, 2008 in Function by Jeff Starr
Come one, come all — today we officially begin a new series of posts here at Perishable Press: the public exposure, humiliation, and banishment of spammers, crackers, and other site attackers. Kicking things off for 2008: blacklist candidate number 2008-01-02!
![[ Photo: Bob Barker makes a fist ]](http://perishablepress.com/press/wp-content/images/2008/blacklisted/2008-01-02.jpg "Come on down! You're the next cracker whore to get blacklisted!")
Every Wednesday, I take a little time to investigate my 404 error logs. In addition to spam, crack attacks, and other deliberate mischief, the 404 logs for Perishable Press contain errors due to missing resources, mistyped URLs, and the occasional bizarre or even suspicious behavior of the search-engine robots. Whenever possible, I attempt to resolve a majority of the “fixable” errors, either by restoring missing resources, adding an htaccess redirect, or by any other means available.
Having exercised this rigorous maintenance practice for well over a year now, my 404 error logs are almost completely devoid of all “fixable” 404 errors, and are filled almost exclusively with spam attacks, XSS attempts, and other miscellaneous cracker nonsense. Fortunately, my site has only fallen victim to such espionage on one occasion, and on a different server.