Special 10-Day Discount

For the next ten days, use coupon code DIWPERISHABLE to save $5 instantly. The book sells for $27, so with the coupon code you can grab it for a cool 22 bucks. This is a limited-time deal so take advantage and hook it up now. Go here to get the scoop and download the book.

Living, Breathing PDF Format..

The PDF version of the book is awesome because we will be able to update and expand it indefinitely. As WordPress changes, the book will evolve with new information, techniques, and code. This is why we call the DiW PDF a “living, breathing document” — it will grow with WordPress, and will be updated and improved periodically well into the future.

..and a Printed Version Coming Soon

In addition to the PDF, a printed version of Digging into WordPress will also be available sometime in the near future. Everyone who purchases the PDF version of the book will receive a fair discount on the printed book when it’s released. The printed book will be awesome, but the PDF is ideal because it’s easy to search, easy to zoom, easy to transport, and easy to copy & paste code. It even features actual hyperlinks that make it easy to jump to linked resources (and there’s a zillion of ‘em!).

Lifetime Subscription

All DiW customers automatically get a lifetime subscription to all future updates and new versions of the book. Chris and I are crazy about WordPress and plan on sharing our experience as time goes on. There are a few other WordPress books out there, but this one won’t get old and outdated as WordPress evolves. Whenever we update the book and release a new version, we’ll send you a link for a free download — fresh WordPress with the click of a button.

Affiliate Program

To help promote the book, we are also providing an affiliate program. If you like the book and want to help sell it, you can earn money doing so. For the PDF version of the book, we avoid the substantial costs typically involved with the printing, handling and shipping of a physical product. So, we are offering an affiliate commission of 50% for all affiliate sales. You are doing the legwork, and we appreciate it. Learn more here.

Thank You

Thanks in advance to anybody who picks up a copy. It goes a long way toward helping both Chris and I create all the other free content we love to share.

Digging into WordPress — packed with yummy WordPress goodness!

Sneak peak..

You can download a demo of the book here. The demo features the Table of Contents and part of Chapter 3. Here’s a little collage showing the general look and feel of what’s inside the book..

Digging into WordPress — 9 Chapters, 400 Pages, and tons of great tips, tricks, and code

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Digging Into WordPress
• Book Review: WordPress for Business Bloggers
• Looking for a Publisher
• Perishable Press Upgrade to WordPress 2.0.5
• WordPress 2.1 Released
• Rocking the Boat
• Site Overhaul, Phase Two: Switching Default Theme

First thangs first

Before getting into it, let’s take a moment to ensure we’re all on the same page. The (X)HTML <pre> element is used to display preformatted text, code, or just about anything else. pre tags are ideal for multiple lines of code or text that need to retain character spacing, display unformatted characters, keep inherent line breaks, and so on.

Let’s say we have the following code that we want to include in a web page:

<?php function shortLink($atts, $content = null) {
	extract(shortcode_atts(array(
		"href" => 'http://' // default URL
	), $atts));
	return '<a href="'.$href.'">'.$content.'</a>';
}
add_shortcode('link', 'shortLink'); ?>

After converting the “<” characters to their encoded equivalents, “<”, we would wrap the code in <pre> tags and get this in the browser:

<?php function shortLink($atts, $content = null) {
	extract(shortcode_atts(array(
		"href" => 'http://' // default URL
	), $atts));
	return '<a href="'.$href.'">'.$content.'</a>';
}
add_shortcode('link', 'shortLink'); ?>

Looks pretty similar, eh? Notice that the line breaks, spacing, and unencoded characters (besides opening brackets) That’s the whole point: the <pre> tag enables you to easily display raw chunks of source code, text (think poetry), and any other content that we don’t want the browser to process. Now let’s look at that same code when displayed without <pre> tags:

extract(shortcode_atts(array(
"href" => ‘http://’ // default URL
), $atts));
return ‘‘.$content.’‘;
}
add_shortcode(’link’, ’shortLink’); ?>

As you can see, when not wrapped in <pre> tags, code examples such as this are inaccurate and essentially useless. <pre> elements ensure that the content retains its “natural” format, which is crucial for displaying code, poetry, equations, and other types of specialized content.

Also, note that the <code> element is frequently used in conjunction with the <pre> tag when using syntax highlighters and formatting plugins such as the excellent Code Auto Escape. For example, here at Perishable Press, all multi-line code examples are wrapped with <pre><code> and then auto-escaped using the Auto Escape plugin, which automatically escapes all characters within <pre> elements, eliminating the need to manually convert, say, opening brackets to their encoded equivalents. Many other syntax highlighters and code-formatting plugins also provide this functionality, greatly facilitating the post-writing process. Such tools help you streamline production and improve display of your preformatted content.

One last thing about the <pre> tag before we dive into the good stuff. You should keep in mind that <pre> tags are used for displaying blocks of preformatted characters. That is, regardless of how many lines of text or code you use, the <pre> tag is a block-level element and will display its content as such. Conversely, the <code> tag is an inline element that is perfect for displaying individual words, characters, and lines of preformatted text within a block-level element. For example, I use the <code> tag all the time — just check out the source code of the previous couple of sentences to see what I mean.

Displaying preformatted content & dealing with overflow

Default behavior: horizontal scrollbars

One of the biggest challenges to displaying preformatted content using the <pre> tag is dealing with continuous strings of characters such as URLs and long chunks of code. By default, the <pre> element handles this by stretching to fit its content. Assuming that no widths have been specified in the CSS, the <pre> element will expand in length to accomodate its longest line of content. Interesting, but not very practical in most design scenarios. As soon as a constraining width is applied, the <pre> element uses a horizontal scrollbar to accomodate any content that doesn’t “fit” within the display area. This default behavior is deployed in the stylesheet like this:

pre {
	overflow: auto;
	width: 500px;
	}

This is a commonly seen way of dealing with oversized <pre> content. It’s fast, easy, and effective. Even so, not everyone likes to scroll..

Word-wrapping

Instead of using a scrollbar to display long lines of preformatted text, some prefer to wrap the content within the display area of the <pre> element. When we wrap preformatted content, any lines that extend beyond the specified width will wrap to the next line. As simple as this sounds, some browsers have real problems when it comes to continuous strings of text such as long URLs. Many browsers are unable to break up continuous lines of text unless specifically instructed to do so. Fortunately this is possible using a crefully crafted set of CSS directives.

To enable word-wrapping for your <pre> content, use the following slice of CSS and edit the first directive to set the desired width:

pre {
	width: 500px;                          /* specify width  */
	white-space: pre-wrap;                 /* CSS3 browsers  */
	white-space: -moz-pre-wrap !important; /* 1999+ Mozilla  */
	white-space: -pre-wrap;                /* Opera 4 thru 6 */
	white-space: -o-pre-wrap;              /* Opera 7 and up */
	word-wrap: break-word;                 /* IE 5.5+ and up */
	/* overflow-x: auto; */                /* Firefox 2 only */
	/* width: 99%; */		       /* only if needed */
	}

Once in place, this code will force your <pre> areas to stay at 500 pixels wide. If any continuous lines extend beyond this width, they will be broken and wrapped accordingly.

Auto-expanding code box with CSS

If word-wrapping isn’t for you, you may want to implement some auto-expansion functionality. Using a small snippet of CSS, it is possible to style your <pre> tags such that they magically expand whenever the user hovers their mouse. So, for example, your <pre> areas would display normally at 500pixels in width, but as soon as the user hovers their cursor over the area, it would instantly expand to a larger width, say, 700 pixels.

Setting this up is easy. Just include the following CSS in your stylesheet and enjoy the results:

pre {
	overflow: auto;
	width: 500px;
	}
pre:hover {
	position: relative;
	width: 700px;
	z-index: 99;
	}

Of course, you will want edit the width values according to your needs and customize your <pre> and hover styles to look all sweet. You know.

There are some pros and cons to this method. Here are some of the pros:

• It works great without requiring any JavaScript.
• Scrollbars appear only when the box is not expanded.
• The boxes expand instantly — no waiting required.
• Works fine even without an inner <code> wrapper.

..and of course some of the cons:

• All <pre> tags expand even if it’s not necessary (i.e., the code fits)
• The sudden display change may disorient/confuse newer web users.
• Expanding box may interfere with other page elements.
• Even after expansion, the <pre> are may still require horizontal scrollbars to see all of the content.

Auto-expanding code box with jQuery et al

The CSS expanding-box method works nice, but it’s a bit choppy — upon hover, it’s like, BAM — suddenly you’re staring at a full-size code box. Using a little bit of jQuery, we can create a much smoother expanding code box, as originally shared by Chris Coyier at Digging into WordPress.

The jQuery method is an improvement over the CSS method, behaving more elegantly:

• Expands only when hovered over
• Expands only as wide as necessary
• Expands with some nice animation

To implement, begin by styling the <pre> element with a little CSS:

pre {
	overflow: auto;
	width: 500px; 
	}

This will prepare the <pre> element for the following JavaScript:

$(function(){
	$("pre").hover(function() {
		var codeInnerWidth = $("code", this).width() + 10;
		if (codeInnerWidth > 500) {
			$(this).stop(true, false).css({zIndex:"99",position:"relative",overflow:"hidden"}).animate({width:codeInnerWidth+"px"});
		}
	}, function() {
		$(this).stop(true, false).animate({width:500});
	});
});

And that’s pretty much it. You’ll want to customize the CSS and jQuery to fit your needs, but the main thing is getting all of the widths to match up (both in the CSS and JavaScript). When JavaScript is unavailable on the user’s browser, this method degrades gracefully to default <pre> elements with auto-scrollbars.

As discussed at Digging into WordPress, this method requires that your preformatted content is wrapped in both <pre> and <code> tags. For complete information, check out the the original article.

Whipping scrollbars into shape

Vertical scrollbars, height, and Internet Explorer

If you do decide to use scrollbars to display overflow content, you will discover many inconsistencies across browsers, especially (surprise surprise) Internet Exploder. The first thing to understand is that, on standards-compliant browsers (i.e., anything other than IE) vertical scrollbars will only appear if an explicit height is specified for the <pre> element. If it is, vertical scrollbars will appear whenever the preformatted content contains more lines than is viewable within the specified height.

Why is this important? Because it makes eliminating vertical scrollbars rather easy. As a general rule of thumb, I never specify heights for preformatted content, but there are situations where you might want to do so.

As for our ‘ol friend IE, you are pretty much going to get vertical scrollbars regardless of whether or not you declare a height. They just appear on their own. Like friends of that squatter you mistakenly let stay with you for awhile.

Fortunately, there are effective ways to exterminate those stinky vertical scrollbars in IE. Here is the method I use on many of my sites:

/* no vertical scrollbars for standards-compliant browsers */
pre {
	overflow: auto; 
	width: 500px;
	}
/* no vertical scrollbars for IE 7 */
*:first-child+html pre {
	padding-bottom: 20px;
	overflow-y: hidden;
	overflow: visible;
	overflow-x: auto; 
	}
/* no vertical scrollbars for IE 6 */
* html pre { 
	padding-bottom: 20px;
	overflow: visible;
	overflow-x: auto;
	}

That code is pretty much plug-n-play with only the essentials, but you will want to customize the width in the first declaration block and add other styles as desired. What’s happening with this code? Glad you axed. Lemme break it down:

1. first block — sets default scrolling for standards-compliant browsers; no vertical scrollbars unless explicit height is set.
2. second block — hack for IE 7 that removes the vertical scrollbar and adds a bit of padding to make room for any horizontal scrollbar that might be present.
3. third block — hack for IE 6 that removes the vertical scrollbar and also adds some padding.

Of course, rather than using unsightly CSS hacks for IE, it’s best practice to summon them via conditional comments. Once in place, this code will neutralize and eliminate those nasty vertical scrollbars in IE and provide some extra bottom-padding to make room for horizontal scrollbars when they appear. This code is effective, but the additional padding is not needed when the content fits within the <pre> area and the horizontal scrollbar does not appear, resulting in an awkward blank line. Fortunately we can turn to JavaScript to account for this dynamic display property.

Fixing IE’s funky inside scrollbars with JavaScript

“IE is so bad..” — how bad is it? It renders horizontal <pre> scrollbars on the inside of the element. This sucks because it interferes with content, pushes everything up about 20 pixels, and invokes display of the unnecessary vertical scrollbar.

We saw how to remedy this display deficiency using CSS in the previous section, but it wasn’t quite ideal because of the extra bottom padding that is used to ensure content display when horizontal scrollbars appear. A better way to handle it is to use a little JavaScript to do the following:

1. Check if the browser is Internet Explorer
2. Find all <pre> elements with overflowing horizontal content
3. Add 20 pixels of bottom padding to account for the horizontal scrollbar
4. Remove the vertical scrollbar

Thankfully, Remy Sharp delivers this functionality with the following slice of JavaScript:

window.onload = function () {  
	// only apply to IE  
	if (!/*@cc_on!@*/0) return;  
	// find every element to test  
	var all = document.getElementsByTagName('*'), i = all.length;  
	// fast reverse loop  
	while (i--) {    
		// if the scrollWidth (the real width) is greater than 
		// the visible width, then apply style changes    
		if (all[i].scrollWidth > all[i].offsetWidth) {
			all[i].style['paddingBottom'] = '20px';
			all[i].style['overflowY'] = 'hidden';
		}
	}
};

..and as if that weren’t cool enough, here’s the same functionality via jQuery:

(function ($) {
	$.fn.fixOverflow = function () {
		if ($.browser.msie) {
			return this.each(function () {
				if (this.scrollWidth > this.offsetWidth) {
					$(this).css({ 'padding-bottom' : '20px', 'overflow-y' : 'hidden' });
				}
			});
		} else {
			return this;
		}
	};
})(jQuery);
// usage
$('pre').fixOverflow().doOtherPlugin();

Either of these methods will do the job nicely, making IE appear to display any horizontal scrollbars on the outside of the <pre> element.

Interestingly enough, we can also execute this dynamic functionality from within the stylesheet and eliminate the need for any JavaScript. By using one of IE’s proprietary expression properties, we can include the following directly in our IE-only stylesheet:

pre {
	width: 500px;
	overflow-x: auto;
	overflow-y: hidden;
	padding-bottom: expression(this.scrollWidth > this.offsetWidth ? 20 : 0);
	}

Just specify the width and you’re off to the races. For either of these dynamic methods (i.e., JavaScript, jQuery, or CSS expression), keep in mind that we are treating horizontal overflow issues when an explicit vertical height has not been specified.

Bonus tip: displaying a name for each class of <pre> text

If you have different types of preformatted content, you can output the name of each one within the content itself. To illustrate, let’s say you provide different types of code snippets at your site, such as CSS, HTML, and PHP. By adding a class to an inner <code> element, you can combine CSS-2.1’s attribute selector and :after pseudo-element selector to display the class name within the preformatted content area.

pre code[class]:after {
  content: 'highlight: ' attr(class);
  display: block; text-align: right;
  font-size: smaller;
  padding-top: 5px;
}

Then, you set up your preformatted code like so:

<pre><code class="CSS">

The class name you specify for each type of code block will then be displayed to the bottom-right of the preformatted content area. Shouts out to Chris Coyier for this awesome trick.

Styling preformatted content

Now that we know how to improve the physical properties of the <pre> element, let’s wrap things up with a few ideas for styling the actual preformatted content.

Fonts

When styling your preformatted content, employ fonts suitable to its purpose. For example, if your site is mostly sporting code snippets, throw down with some tough monospace typography:

• monospace
• "Courier new", Courier, "Andale Mono", monospace
• Consolas, "Lucida Console", Monaco, monospace
• Consolas, "Andale Mono WT", "Andale Mono", "Lucida Console", "Lucida Sans Typewriter", "DejaVu Sans Mono", "Bitstream Vera Sans Mono", "Liberation Mono", "Nimbus Mono L", Monaco, "Courier New", Courier, monospace

To create the perfect monospace font stack, you really should be testing on as many different browsers as possible. Check different operating systems, browsers, zoom settings, and types of preformatted content. A couple of notes: Courier is an incredibly tight-looking font that, unfortunately, does not scale well on all browsers/systems. Particularly, there seems to be a lower-limit to the display size of the Courier font. Also, to get things looking right on both PC and Mac without all the fuss, simply declare “monospace” for your <pre> font and you’ll get a great-looking font on both systems.

Borders

While maybe not beneficial to every block of preformatted text, a nice set of borders can really help accent and emphasize your content. Especially for code snippets, adding a border around the area can help users discern easily between it and the post content.

The are many cool things that can be done with <pre> borders:

• Place a border on only one or two sides of the <pre> text
• Use varying widths and/or styles (e.g., dotted or custom image)
• Get all “Web-2.0” and round your corners

Colors

Colors are another inspiring thing to play with when it comes to styling the presentation of your <pre> elements. You can color the text itself, the background, and the borders. Anything is possible here, I just wanted to point out that a good combination of colors for these different properties can really help your <pre> areas “pop.” Also fun to play with when choosing the perfect color combination is transparency, which might be used to let the background show through just a bit. Background images also present unlimited possibilities, such as adding a personal logo/icon or even a nice drop shadow for the upper/left border.

How I roll..

Last but not least, here is the template snippet that I use as a base for styling <pre> tags. After splicing this little snippet into my stylesheet, I proceed to tweak and fuss ‘til everything’s just right..

code, samp, kbd {
	font-family: "Courier New", Courier, monospace, sans-serif;
	text-align: left;
	color: #555;
	}
pre code {
	line-height: 1.6em;
	font-size: 11px;
	}
pre {
	padding: 0.1em 0.5em 0.3em 0.7em;
	border-left: 11px solid #ccc;
	margin: 1.7em 0 1.7em 0.3em;
	overflow: auto;
	width: 93%;
	}
/* target IE7 and IE6 */
*:first-child+html pre {
	padding-bottom: 2em;
	overflow-y: hidden;
	overflow: visible;
	overflow-x: auto; 
	}
* html pre { 
	padding-bottom: 2em;
	overflow: visible;
	overflow-x: auto;
	}

Rather than another long-winded diatribe exploring the manifold intricacies and subtleties of this particular stylistic strategy, I defer to your currently established comprehension of CSS and invite subsequent analysis of its constituent declarations. Or, in the parlance of the day: “it’s plug-n-play, dude - I’m outta here!!!”

Hungry for more

As mentioned, I post a lot of code here at Perishable Press. So much so, that I have become rather obsessed with the fine art of formatting and styling preformatted content. As tweeted the other day, I could spend all day just fussing over <pre> code. To me, it really is that important. In this article, I have shared many different techniques for creating perfect <pre> tags, but these methods are far from exhaustive. I am always on the lookout for new and useful ways to improve the appearance and functionality of my preformatted code examples, so if you happen to know any sweet tricks that I missed, share them and I will update the article with the method and link to your site.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• A Complete CSS Template File
• Embed Flash and Video via the object Tag
• Prevent JavaScript Elements from Breaking Page Layout when Following Yahoo Performance Tip #6: Place Scripts at the Bottom
• Optimize Convoluted Code via JavaScript
• XHTML Document Header Resource
• One Link to Open Them All
• Auto-Focus Form Elements with JavaScript

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

What is a 404 and why should I care?

Technically, you don’t need to even think about 404 errors. They are handled automatically by server. But the problem is that, by default, your server is going to deliver one sick-looking message:

Default Apache 404 error page

While that sort of message is fine for uber-geeky tech sites, chances are that “normal” visitors are going to crap themselves if they see such a thing, thinking:

What does that mean? Did I break something? I don’t have time for this. I’m outta here!

You don’t want that, and neither do your visitors. Granted, most visitors are experienced enough to “deal with it,” but there are many that just don’t understand. This is why many designers take the time to customize their 404 error pages to make them a little more “user-friendly” and not so bloody frightening. It’s not like we’re a bunch of robots, after all.

A nice, “user-friendly” 404 error page

Bottom line, here are three reasons why you should give a flying flip about 404 error pages:

• Default 404 errors are ugly and scary to regular people
• Default 404 errors may result in a higher bounce rate, because people are scared
• Custom 404 pages tell the reader that you care so much about them, and that it’s “all good”
• User-friendly 404 pages draw the reader into your site, instead of scaring them away
• Default 404 errors are useless, but your custom 404 pages can actually help the user find what they are looking for
• You get the idea..

In short, a well-designed 404 page keeps the user engaged and helps build trust. It just makes for an all-around better site.

Another “user-friendly” 404 error page

I’m sold, how do I do it?

Here are some tried and true best practices for creating that perfect 404 error page:

Keep it familiar

Your custom error page should look like a well-integrated, natural part of your website. One of the reasons why default 404 error pages are so hideous is that they look so alien to your visitors. Unless your site is nothing but black serif fonts on plain white background, the default just isn’t going to “blend in.” So keep it real, and make sure that your 404s (and other error pages) share the same design as the rest of your site.

Explain the situation

Everyone in their right mind understands that errors happen. There is no need to apologize for anything, but you do want to explain the situation. This doesn’t have to be anything too serious, just a brief sentence or two telling the user that “something happened” and that the “requested page was not found.” Try to match the tone and flow of your site. If your site is formal, best to stay that way. If your site is hilarious, don’t blow it on the 404.

Provide some guidance

A user sitting there staring at a 404 error page is obviously lost. Try to provide some guidance with a search bar, a site map, or perhaps a recipe for some strong, mixed drinks. There is a good chance that the visitor is looking for some of your popular content, so you may want to suggest a few popular site destinations. It is also helpful to include a search form (or a link to one), so that the user may report the error or ask a question about that darling resource they couldn’t find.

Display the requested URL

As the user sits there scratching their head, it may be helpful to show them the URL that was received by the server. For example, the user may think that they entered “http://yoursite.com/blondie/”, but in reality they might have entered something like “http://yoursite.com/blodie/” instead. Echoing back the originally requested URL makes it easier for the user to spot any mistakes. Later in the article, we’ll see a nice way to do this.

Be mindful of file size

As design guru Chris Coyier points out, keeping an eye on the overall size of your 404 page is a good idea. Your 404 will be delivered for every missing request, not just the ones triggered by your visitors. This includes everything from bizarre favicon requests and non-existent robots.txt files to missing scripts, stylesheets, images, and everything in-between. Needless to say, all of these 404s can add up quickly, so if bandwidth is an issue, be sure to keep an eye on total 404 size.

Take advantage

Just because life is sucking for the people who can’t find your content doesn’t mean that you can’t benefit. When visitors trigger 404 errors, collect some data about the event so you can fix the issue and prevent further occurrences. For each 404 error, there is a great deal of information that is available to you, such as the requested URL, referrer info, IP address, and much more. Once you have this data recorded somewhere, cleaning things up is much easier. Later in the article, we’ll look at some cool code snippets to help you implement some keen functionality for your 404s.

Have some fun

A confused visitor is a scared visitor. The 404 page is a great opportunity to lighten things up with a little humor. Nothing too condescending, but just enough to let ‘em know that you’re on their side, and that you hate being lost just as much as they do. A quick laugh can gloss over just about anything, and you never know — if your page is clever enough, it might be featured in one of those ridiculously popular 404 error-page galleries ;)

Later in the article, we’ll check out some classic examples of effective and useful 404 pages. For now, let’s see how to set ‘em up..

How do I implement a custom 404 page?

That depends on how your site is setup. If you are running WordPress, simply create a theme file named “404.php” and add whatever code and content you wish. Also in WordPress is the intra-page error, which is triggered when no content is found for a specific type of page view. Those familiar with the WordPress loop will recognize this as the portion of code located after the final else condition. This is not technically a 404 error — more like an intra-WordPress 404 — but it may also be customized and optimized for your visitors.

This portion of loop code is responsible for the “intra-WordPress” 404 error message

For non-WordPress sites, the easiest way to override the default 404 page and deliver your own customized page is to tweak your .htaccess with the following directive:

ErrorDocument 404 /error/404.php

This directive will replace the default 404 error page with the one specified (“/error/404.php” in our example). Edit the path according to the location of your custom file. Apache handles the rest. Thanks Apache.

Check out my previous article for more information on customizing error messages with HTAccess. You can do much more than custom 404s!

Simply brilliant, let’s see some code snippets

As mentioned, the underlying functionality of your 404 pages is just as important as the user-friendly interface. You could have the swellest 404 on teh Web, but unless you are actively working to resolve the errors, their frequency will inevitably increase. There are many awesome ways to track errors and enhance the underlying functionality of your 404 page. Here are some of my favorites.

Smart 404 for WordPress
Michael Tyson shares this excellent method to make WordPress’ 404 handler a little bit smarter:

I changed my template’s 404 page to do a search for what the viewer was really after, and redirect them there. If it can’t find an exact match, it’ll perform a search with keywords extracted from the URL. If it finds a single result, it’ll redirect, otherwise it’ll put up a few results as suggestions on the 404 page.

Sounds nice, doesn’t it. And extremely helpful as well. Here is the code to place into the top of your active theme’s 404.php file, immediately preceding the get_header() tag:

<?php global $wp_the_query;
$search = preg_replace(array("@[_-]@", "@\.html$@"),array(" ",""),urldecode(basename($_SERVER["REQUEST_URI"])));
$posts = $wp_the_query->query(array("name" => $search));

if (count($posts) == 1) {
	wp_redirect(get_permalink($posts[0]->ID), 301);
	exit();
}
$posts = $wp_the_query->query(array("s" => $search));

if ( count($posts) == 1 ) {
	wp_redirect(get_permalink($posts[0]->ID), 301);
	exit();
} ?>

That’s the juice, right there. No editing required. Then, once that is in place, you can provide the user with some helpful suggestions. Just place this code somewhere within the <body> of your 404.php page:

<?php if (count($posts) > 0) : ?>
<ul>
<?php foreach ($posts as $post) : ?>

<li><a href="<?php echo get_permalink($post->ID); ?>"><?php echo $post->post_title; ?></a></li>

<?php endforeach; ?>
</ul>
<?php endif; ?>

With that code in place, the user will see a list of potentially relevant list of posts that may include something useful or of interest. There is quite a bit that can be done with this technique, so have some fun with it.

Automatic notification emails with all the trimmings

Delivering user-friendly 404 pages to your visitors is great, but don’t let that stop you from eliminating as many lost pages as possible. Cleaning up loose ends makes your site tighter, cleaner, and more usable. One way to keep an eye on your 404 errors is to simply crack open a log and dig in. In other situations, you may prefer to have the error information emailed to you in real-time. Here is a sweet little script that will do just that — send you an informative email every time a user triggers a 404 error. The email will contain a ton of related information, including everything from IP address and server name to requested URI and user agent. This strategy isn’t recommended for high-volume sites, but for smaller blogs and niche sites, it may be just what the 404 doctor ordered.

Here is the script that makes it happen:

<?php 
// 404 auto-mailer script from Perishable Press
function errorEmailAlerts() {

	header("HTTP/1.1 404 Not Found");
	header("Status: 404 Not Found");

	// configure next two lines with your info

	$site  = "Your Site Name";
	$email = "your-email@address.com";

	// gather some data

	$http_host    = $_SERVER['HTTP_HOST'];
	$server_name  = $_SERVER['SERVER_NAME'];
	$remote_ip    = $_SERVER['REMOTE_ADDR'];
	$remote_host  = $_SERVER["REMOTE_HOST"];
	$request_uri  = $_SERVER['REQUEST_URI'];
	$cookie       = $_SERVER["HTTP_COOKIE"];
	$http_ref     = $_SERVER['HTTP_REFERER'];
	$query_string = $_SERVER['QUERY_STRING'];
	$user_agent   = $_SERVER['HTTP_USER_AGENT'];
	$error_date   = date("D M j Y g:i:s a T");

	// prepare teh email

	$subject = "404 Alert";

	$headers  = "Content-Type: text/plain"."\n";
	$headers .= "From: ".$site." <".$email.">"."\n";

	$message  = "404 Error Report for ".$site."\n";
	$message .= "Date: ".$error_date."\n";
	$message .= "Requested URL: http://".$http_host.$request_uri."\n";
	$message .= "Query String: ".$query_string."\n";
	$message .= "Cookie: ".$cookie."\n";
	$message .= "Referrer: ".$http_ref."\n";
	$message .= "User Agent: ".$user_agent."\n";
	$message .= "IP Address: ".$remote_ip." - ".$remote_host."\n";
	$message .= "Whois: http://ws.arin.net/cgi-bin/whois.pl?queryinput=".$remote_ip;

	// send teh email

	mail($email, $subject, $message, $headers);

} ?>

Include this script in your active theme’s functions.php file and edit the first two variables with your specific information. Then, place the following function call at the very top of your theme’s 404.php file:

<?php errorEmailAlerts(); ?>

Once in place and properly configured, this function will ensure that the proper 404 header is sent to the client, collect as much useful information as possible, and then send you an email with all the trimmings. Larger, high-volume sites may want to consider using a more robust method of logging and analyzing error data, but smaller, low-traffic sites and blogs will certainly benefit from tracking their 404 errors in real time.

Whitelist specific user-agents and URL-request patterns

As you begin to monitor your errors, you will inevitably discover three different types of 404:

• 404 errors caused by malicious behavior (exploit scanning, etc.)
• 404 errors caused by benign requests for non-existent resources
• legitimate 404 errors caused from missing resources or mistyped URLs

Of these three types of 404 errors, the first is by far the most common. The Web is full of unscrupulous bastards who insist on spamming, cracking and exploiting even the humblest of sites. Here at Perishable Press, I devote many resources to the fighting of this type of malicious behavior, including blacklists, scripts, and education.

For the second type of 404 error, we are referring mainly to persistent requests made by otherwise benign scripts that check for the presence of legitimate, proprietary extensions, files, and other things. A good example of this is seen in location mapping systems, which typically request the following strings when crawling your site:

• http://domain.tld/path/resource/_vpi.xml
• http://domain.tld/path/resource/_vti_bin/

These resources exist on servers that have been configured to accommodate visitors running programs such as Weblin. When they are discovered on a domain, they facilitate the discovery of site resources; when they are not found on a domain, the requests result in 404 errors. The number of these errors can be quite numerous and may appear as malicious.

In addition to specific file requests, there are also certain user agents that may exhibit unusual behavior when crawling your site. Good examples of this include bots that don’t understand fragment identifiers and search engines that try guessing for the presence of expected resources.

To prevent these sorts of benign requests from polluting your 404 monitoring process, you can either blacklist them or add them to a whitelist. To whitelist select agents, we can insert the following snippet into our previous errorEmailAlerts() function:

function errorEmailAlerts() {

	if (
		($_SERVER['HTTP_USER_AGENT'] != 'ia_archiver') && 
		($_SERVER['HTTP_USER_AGENT'] != 'Yahoo! Slurp') && 
		(strpos($request_uri, '/_vpi.xml') === false) && 
		(strpos($request_uri, '/_vti_bin') === false)
		) {

		// function contents go here

	}

}

Once in place, this conditional statement will check for any “whitelisted” user agents and/or request strings in the URL. You can easily whitelist additional items by emulating the existing code. I am thinking this is self-explanatory, but don’t hesitate to ask any specific questions in the comments section.

Fabulous, let’s see some more examples of great 404 pages

Finally, let’s wrap things up with a look at some great examples of 404 pages. Here are some of my favorite 404 error pages from around the Web.

http://patterntap.com/404

http://www.expansionbroadcast.com/404

http://slonky.com/404

http://monzilla.biz/web/404

http://www.productplanner.com/404

http://thehpage.com/404

http://wakinglimb.com/404/

http://24-7media.de/404

http://southcreative.com.au/404.shtml

http://trentwalton.com/404

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Crazy CSS Underline Effects
• Embed External Content via iframe and div
• Keep it Dark: Hiding and Filtering CSS
• Industrial-Strength Spamless Email Links
• Computer Flashback: Windows 98 Run Commands
• CSS Throwdown: Preload Images without JavaScript
• Preventing the Unpredictable White Screen of Death for WordPress Sites with Multiple Themes

During the site’s first year, I remember being too excited for my own good. WordPress was relatively new and I was completely inspired by the amazing things I could do with it. I spent most of my time building all sorts of different themes, studying web design, and posting useful code snippets. During this first year, Perishable Press was virtually unknown. Late night hours were spent drenched in CSS, (X)HTML, and PHP.

During the site’s second year, I delved deeper into web development, reading every blog, book, and comment I could get my hands on. I gobbled up knowledge like a hungry hungry hippo, and continued to post my discoveries and tricks. Some of the stuff I was posting began to assume more of a “tutorial” format, and this was back before tutorials were the highly refined gloss kits they are today. The site began getting a few links, and watched in amazement as my pages began to rank in the search engines. SEO was my new best friend, along with site optimization, usability, accessibility, and performance.

During the site’s third year, I continued sharpening my writing style, combining elaborate code descriptions with in-depth tutorials and comprehensive guides to a wide variety of development-related content. Traffic continued to increase, as did just about every other metric that I cared to look at. It was inspiring to know that people were reading, and that I was helping to give back to the incredible open-source design community from which I had learned so much. Site security became one of my primary concerns, and I continued to dive deep into the intoxicating pool of HTAccess and next generation blacklists.

During the site’s fourth year, I redesigned the site with an elaborate, psychedelic theme, and refined my content to include only the best material possible. Many of the shorter, quirkier posts were dropped in favor of more fully produced, well-researched articles on topics of broader interest than previously covered. Some awesome events happened during this most recent year, such as seeing my stupid htaccess tricks published in a book on Joomla Security, and working with Chris Coyier of CSS-Tricks on a new WordPress book, Digging into WordPress.

During the site’s upcoming fifth year, I will be rethinking everything. Design. Content. Delivery. Everything. I definitely want to take things to the next level. My plans are vast and ambitious, and I feel as if I am just getting started with this site. There is much in store for the future — don’t miss it.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Three Years and Counting
• Gravatars at Perishable Press
• Press Time
• One Year Anniversary
• Perishable Press Upgrade to WordPress 2.0.5
• Much ado about Taglines
• Miscellaneous Happenings

“Tweet This!” short links for posts

I like to include an easy way for readers to “tweet” my posts, but the URLs are generally way over Twitter’s 140-character limit. Fortunately, we can use PHP’s handy file_get_contents function to grab short versions of our URLs from a free minifying service like TinyURL.

All we need to do is add the following script to your web pages or your functions.php file:

function shortenURL($longURL) {
	$shortURL = file_get_contents("http://tinyurl.com/api-create.php?url=".$longURL);
	echo $shortURL;
}

Then, in the location where you would like to display your shortened “Tweet This!” links (e.g., after your post loop), call the function and create the link with the following code:

<a href="http://twitter.com/home?status=Reading:%20<?php the_title(); ?>:%20<?php shortenURL(get_permalink()); ?>" rel="nofollow">Tweet This!</a>

This is basically a link using the Twitter API to specify the contents of our tweet. For each post, the value of the_title() and get_permalink() will change to reflect its title and URL, respectively. If you are using a platform other than WordPress, you will need to use the equivalent of these dynamic tags.

Once you have this code in place, it will generate “Tweet This!” links that send the following information to Twitter (using this post as an example):

As you can see, the original long URL for this post was automatically shortened via the TinyURL service. Nice, clean and effective.

For more social media links, check out my comprehensive article, Fully Valid, SEO-Friendly Social Media Links for WordPress.

Custom short links using your own domain name

If you would rather not rely on a shortening service (such as TinyURL) for your shortened links, fret not — it is easy to create your own, customized URLs. There are several good reasons why you might prefer to use your own domain for your shortened URLs, including:

• preservation of valuable link juice
• prevention of link loss if the shortening service dies
• control over the appearance and branding of your links

The key to setting up customized shortened “Tweet This!” links is the inherent post ID that is associated with each of your posts. Regardless of whether or not you have permalinks setup, every one of your posts has its own unique post ID, such as seen in these examples:

• http://perishablepress.com/press/?p=711
• http://perishablepress.com/press/?p=712
• http://perishablepress.com/press/?p=713

We can use these post IDs to fashion our own shortened URLs, and then use those shortened URLs to create our own customized “Tweet This!” links. All we need is touch of HTAccess placed in the same .htaccess file as our WordPress permalinks:

RewriteRule ^x/([0-9]+)$ ?p=$1 [R=301,L]

This directive will redirect our custom shortened URLs to our default WordPress URLs, which WordPress will then redirect according to any existing permalink rules. Once this technique has been implemented, the following redirects will take place for each of your custom URLs:

Once we have the HTAccess code in place, we use the same basic markup as in our previous example to create the link. Add the following code to the desired location in your theme file (e.g., after the post loop):

<a href="http://twitter.com/home?status=Reading:%20<?php the_title(); ?>:%20<?php echo get_option('home'); ?>/x/<?php the_ID(); ?>" rel="nofollow">Tweet This!</a>

This code will create “Tweet This!” links that send the following information to Twitter (using this post as an example):

As you can see, the original long URL for this post is now a customized short URL using the same domain. Feel free to change the “x” to whatever you want — just remember to edit both the markup link and the .htaccess directive if you decide to do so.

I should also note that, for any of these “shortened” URL examples, we are only using Twitter as an example application. Many sites these days simply include a shortened version of the post URL for people to copy & paste anywhere they wish. To do something similar with the current technique, we would simply include the following snippet:

<?php echo get_option('home'); ?>/x/<?php the_ID(); ?>

Drop-dead simple short URLs using the post ID

For the sake of completeness, keep in mind that we can use the post ID to (re)create our original WordPress URL structure:

http://domain.tld/?p=719

That’s pretty short, and may work perfectly for your short links if the format is suitable for you. All we would need to do is include the following code into your WordPress theme:

<?php echo get_bloginfo('url')."/?p=".$post->ID; ?>

WordPress will automatically redirect such URLs to the corresponding permalink (if you have permalinks enabled).

Display the number of your Twitter followers in plain text via JavaScript

Another fun thing to do with Twitter is show off your subscriber number on your website. Many sites these days prominently display two numbers: one for their Feedburner subscriber count and another for their Twitter follower count. Displaying either count with a button or badge is a no-brainer, but displaying the numbers in plain text allows for greater stylistic control. Plain text is desirable because you can do just about anything with it, whereas a badge just kind of sits there, looking ugly.

To get our Twitter follower count in plain text, we need to include some free JavaScript made available to us at TwitterCounter. Just place this code wherever you would like to display your follower count:

<script type="text/javascript" language="javascript" src="http://twittercounter.com/widget/index.php?username=username"></script>

Simply edit the “username” to match your own and you are off to the races.

Display the number of your Twitter followers in plain text via PHP

If you would rather not rely on JavaScript and a third-party service to deliver your follower count data, we can use PHP’s excellent curl() functionality (edit the “www.domain.tld” to match your own):

function curl($url) {
	$ch = curl_init($url);
	curl_setopt($ch,CURLOPT_RETURNTRANSFER, true);
	curl_setopt($ch,CURLOPT_HEADER, 0); 
	curl_setopt($ch,CURLOPT_USERAGENT,"www.domain.tld");
	curl_setopt($ch,CURLOPT_TIMEOUT,10); 
	$data = curl_exec($ch);
	curl_close($ch);
	return $data;
}

That curl snippet will grab the content of the input URL and prepare it for parsing via the following code:

function followerCount($username) {
	$followers = curl("http://twitter.com/statuses/user_timeline/".$username.".xml?count=1");
	$xml = new SimpleXmlElement($followers, LIBXML_NOCDATA);
	return = $xml->status->user->followers_count;
}
echo followerCount("username");

This second snippet uses SimpleXML to parse the curl output via the Twitter API. SimpleXML is pretty common on most servers running at least PHP 5. The only thing you need to edit is the “username” in the last line. Everything else is roses. Drop this code into a web page and enjoy your follower count displayed anywhere you like, and in plain-text, no less.

Display the number of tweets for each page or post

If you are running SimpleXML (you probably are, ask your host), displaying the total number of tweets for any given post or page is easily accomplished with the following slice of PHP:

function tweetCount($url) {
	$content = file_get_contents("http://api.tweetmeme.com/url_info?url=".$url);
	$element = new SimpleXmlElement($content);
	$tweets = $element->story->url_count;
 	echo $tweets . " tweets!";
}

If you are using WordPress, you may place that code into your active theme’s functions.php file. Then, to display the total number of tweets for your posts, you would add the following function call to your post loop:

<?php tweetCount($post->permalink); ?>

You can also show the number of tweets for a particular page, even if it is not on your site. For example:

<?php tweetCount("http://perishable.biz"); ?>

Backup your tweets

Once you have been tweeting for awhile, you may begin to wonder what would happen if Twitter ever lost all of your tweets. It could happen, and if it does, do your tweets contain anything of value? If they do, I would highly recommend making regular backups (like monthly or something) of all your tweets. Doing so is easy. All you need to do is login to your Twitter account and enter the following URL into your browser:

http://twitter.com/statuses/user_timeline/username.xml?count=n

Before this will work, you need to replace the “username” with your actual username, and also change the “n” with the number of tweets you would like to download. To download all of your tweets, check your number of updates on your Twitter profile page. After entering this URL into your browser, you will be taken to an XML page containing your tweets. To make a backup, just save that page to a safe location on your computer.

Now you can rest so easy just knowing deep down that all your precious tweets are safe and sound ;)

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Fully Valid, SEO-Friendly Social Media Links for WordPress
• Conditionally Load WordPress Pages
• Display the Total Number of WordPress Posts, Comments, and Categories
• Extreme Makeover for Gravatars in WordPress
• Add RSS Feed Link Icons to WordPress Category Listings
• Super Loop: Exclude Specific Categories and Display any Number of Posts
• htaccess Combo Pack: WordPress Permalinks and non-www Redirect

To do this, all you need is an HTAccess file and a list of IPs for which you would like to allow access.

Edit the following code according to the proceeding instructions and place into the root HTAccess file of your domain:

# ALLOW ONLY MULTIPLE IPs
<Limit GET POST PUT>
 Order Deny,Allow
 Deny from all
 Allow from 123.456.789
 Allow from 456.789.123
 Allow from 789.123.456
</Limit>
ErrorDocument 403 path/custom-message.html
<Files path/custom-message.html>
 Order Allow,Deny
 Allow from all
</Files>

To prepare this code for use on your site, do these three things:

1. Edit the three IP addresses to suit your needs. Feel free to add more IPs or remove any that aren’t needed.
2. Edit both instances of “path/custom-message.html” to match the path and file name of the file that will contain your custom message. This may be anything, anywhere, with any functionality you desire.
3. That’s it. Copy/paste into your site’s root htaccess file, upload, test, and get out!

The Obligatory Break-Down

How does the magic happen? HTAccess is esoteric voodoo for sure, but that’s not going to stop us from understanding how it works. Here is the basic logic behind the operation:

• First deny access to everyone, then allow access only to the specified addresses.
• Serve everyone who doesn’t have access a customized 403 (Forbidden) message.
• Ensure that everyone has access to the customized 403 (Forbidden) message.

And here is a more in-depth, non-technical explanation of the various directives:

<Limit GET POST PUT>

In the first line of our temporary redirect code, we open a <Limit> container targeting all requests to get, post, or put files to and from the server.

Order Deny,Allow

The second line then specifies the order in which the server should execute the proceeding directives. It basically says, “first obey the deny rule and then obey the allow rule.”

Deny from all

The next line is the deny rule. It simply says, “deny everybody” (i get like this sometimes). At this point in the game, everyone is denied access.

allow from 123.456.789...

The next three lines tell Apache to allow access to the specified addresses. As many or as few of these “allow” directives may be used to achieve your specific goals. Note that the directives used to this point serve as the first step of our logical sequence.

</Limit>

The fifth line simply closes the <Limit> container block.

ErrorDocument 403 path/custom.html

In the sixth line, we are specifying our own customized error page. By default, a user that is denied access will see a simple error page that says something to the effect of “403 Forbidden — You do not have authorization to access the requested resource.” Not exactly encouraging. To improve this response, we specify our own customized error page and serve a much friendlier message, perhaps something like, “This is a private site, but you can contact me for more information..” Or something to that effect.

<Files path/custom-message.html>

After all that drama, the next line opens a <Files> container and exclusively targets our custom page. Note that you could omit the file path and just specify the file name, but doing so will apply the subsequent directives to any file named “custom-message.html” that exists within the directory structure. Either way, it is good practice to name your custom page something unique.

Order Allow,Deny

Again, we are specifying the order in which Apache should process the allow/deny directives.

Allow from all

This line then allows everyone access to the previously specified file. You know, the one with the inspiring, user-friendly message.

</Files>

Finally, we conclude our HTAccess redirect by closing the <Files> container. Taken together, the last four lines are basically telling the server to ignore the previous “deny everybody” directive only for the customized error page. All other pages remain strictly off-limits to anyone not on the guest list.

The Wrap-Up

There you have it. To use this code, prepare your customized 403 document and upload to the desired location on your server. Edit the variables mentioned in the first part of this article, copy and paste to your root htaccess file, and upload to the root directory of your domain. Remember to check that everything has been done properly by using a proxy to test the redirect. Once everything is up and running, your site will be accessible only by select visitors, while everyone else will enjoy whatever custom message you may have prepared for them.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Building the 3G Blacklist, Part 5: Improving Site Security by Selectively Blocking Individual IPs
• Series Summary: Building the 3G Blacklist
• Building the Perishable Press 4G Blacklist
• 4G Series: The Ultimate User-Agent Blacklist, Featuring Over 1200 Bad Bots
• 4G Series: The Ultimate Referrer Blacklist, Featuring Over 8000 Banned Referrers
• Ultimate htaccess Blacklist
• Permanently Redirect a Specific IP Request for a Single Page via htaccess

• No RSS feed available
• Many quality posts that contain no links
• Many quality posts but very low subscriber count
• Great content but with zero comments on any posts
• Lots of good content but with lots of Adsense or other ads
• No “About” page or business information
• And the number one brain-dead giveaway: no contact form or email address

If you pay attention as you surf around, you may want to keep an eye out for some of these dead giveaways. If it looks like the site is profiting from stolen content, it is advisable to leave immediately and locate an original source of information (you could even be cool and report the scraper site to the original author). I.e., help strengthen the legit blogging community and don’t support scrapers in any way. But avoiding scraper sites is merely an afterthought. The real challenge is to have a solid strategy in place that will help you identify, eliminate and prevent stolen content. Unfortunately, there is no “magic cure” that will stop the scrapers from stealing your hard work — apart from running a private site or not providing a feed — but there are many great tools that have proven quite effective in fighting the war against stolen content. While not completely exhaustive, here are some powerful tips and tricks that have served me well over the years:

Use partial feeds

This is arguably the most effect way to immunize against scrapers, who prefer to steal entire articles as opposed to excerpts.

Use a monitoring service

Services such as Fairshare or Copyscape will help you find out who is stealing your content

Use a feed footer plugin

WordPress users have many to choose from including the excellent Copyfeed and Ozh’ Better Feed.

Setup Google Alerts

Keep an eye on what Google discovers around the Web. If you have a specific phrase or URL (perhaps your own) that appears in all (or most) of your posts, setup a comprehensive daily Google Alert to be notified any time that Google finds a match. This is particularly useful if you have pingbacks disabled at your site.

Analyze your access logs

Keep an eye out for image requests coming from external IP addresses. These are usually associated with stolen content.

Tell them to stop

Stay vigilant and confront scrapers with formal “Cease and Desist“ emails. Gather information about the scraper and then contact them as directly and clearly as possible. Tell them to cease and desist, include all relevant URLs, and explain the consequences of non-compliance. Then follow through.

File a DMCA notice

Take action by filing a formal DMCA notice with each of the major search engines. If you are serious about stopping a scraper, filing a DMCA report is an essential step in documenting and potentially resolving the situation. The process is slow and tedious, but worth the effort.

Register your work

To verify your work in the case of a dispute, register your content with services like Numly or Registered Commons. For situations when registering is not possible, Archive.org may provide some indirect evidence of original authorship (just make sure you aren’t blocking them with your robots.txt file.

Deliver your own feeds

Rather than blacklist potential scrapers, target them directly by banning their IP or user agent from accessing your feed. You can’t do this with Feedburner, but it is a great way to prevent stolen content.

Blacklist by IP address

Once you have determined the IP of someone who is scraping your content, block them from accessing your feed by blacklisting their address. Something as simple as the following placed in your HTAccess should do the trick:
RewriteCond %{REMOTE_ADDR} ^123.123.123
RewriteRule ^(.*)$ http://domain.tld/feed
Replace the IP address with that of the scraper and replace the feed URL with anything you wish. I prefer to use the feed of the scraper’s site — works awesome ;)

Blacklist the User Agent

If the scraper is using a unique or obscure User Agent when accessing your content, you can blacklist that particular User Agent.

And there are probably many other effective techniques to be found around the Web. The take-home point is that yes, scrapers suck, but there are many ways to prevent your content from being misused. Developing your own anti-scraping strategy while staying vigilant, informed, and proactive will definitely help minimize the degree to which scrapers misuse your content.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Get Real
• Industrial-Strength Spamless Email Links
• WordPress Spam Battle: 3 Seconds that will Save You Hours of Time
• Bloggers Toolbox: Strategic Elements for a Perfect About Page
• Stupid htaccess Trick: Enable File or Directory Access to Your Password-Protected Site
• The Pros and Cons of Blogging
• Building the 3G Blacklist, Part 1: Improving Site Security by Recognizing and Exploiting Server Attack Patterns

<body>
...
<a name="top"></a>
...
<a href="#top">- Back to Top -</a>
...
</body>

There’s an easier, better and prettier way. CSS Signatures are all the rage these days. If you’re not familiar with a CSS Signature, it’s basically nothing more than an ID on your body tag, like this:

<body id="www-domain-tld">

The fundamental purpose of the CSS Signature is to allow a user to specify style adjustments to your site in their own user style sheets. Whether or not users are actually capitalizing on this is a discussion for another day, but doing this has other benefits like having an extra id to use when dealing with CSS specificity.

Additionally, we can use this to capitalize on a little known fact about HTML and anchors: you can use anchors to jump to any element on your page with an ID attribute.

Let me repeat that: You can jump to any element with an ID attribute on any page.

Here’s an example, if you don’t believe me: Nowhere on CNN.com’s homepage will you find a link to their footer, and you’ll find no mention of <a name="cnnFooter"></a> in the code but if you follow this link to CNN you will in fact find yourself staring at the footer on the CNN homepage. This is because their footer div has “cnnFooter” as the ID which allows me to jump directly to that element.

Oh sure, I know what you’re thinking: “Great, so how do I get this to work in IE?” Surprise: it works just fine in IE, at least as far back as IE 5.5 and maybe further. So, here we have a nice, tidy little tidbit with no cross-browser issues.

So, we can do away with the empty anchor element at the top of our pages and instead do this:

<body id="www-domain-tld">
...
<p><a href="#www-domain-tld">- Back to Top -</a></p>
...
</body>

Trying to be all kinds of accessible with the “Jump to Content” link? Try this:

<p>
	<a href="#content">- Jump to Content -</a>
</p>
...
<div id="content">
	<p>Neat, huh?</p>
</div>

Also works well on comments:

<p>
  <strong>Update:</strong>
  Based on <a href="#comment-12345">so and so's comment</a>...
</p>
...
<blockquote id="comment-12345">
  <h3>On Day X, so and so said:</h3>
  <p>Blah blah blah...</p>
</blockquote>

…and comment forms:

<p>
  <strong>2 Responses</strong>
  <a href="#comment-form">- Jump to Comment Form -</a>
</p>
...
<form id="comment-form" method="post" action="">
...
</form>

Using this approach will streamline a lot of your code, allowing you to get rid of a ton of those empty anchor elements. It also allows for greater flexibility when linking to content on other’s sites. Not to mention that using it means you can sit at the cool kid’s table.

About the Author

Over the course of 33 years, Bill Brown has lived and worked in West Africa as a Field Station Coordinator on Bioko Island in Equatorial Guinea, represented the Memorex line of consumer electronics on QVC, owned a squirrel, taught improvisation and stage combat and launched two successful improv comedy troupes. Oh, and along the way, he’s developed some websites and applications.

Self-taught with a penchant for entertaining others, Bill’s clients have included internationally renowned photographer Steve McCurry, The National Maritime Law Enforcement Academy (whose site was developed entirely in the rain forests of Bioko Island), Virtual Giving, Workforce Strategy Center and the WSC web application Pathways to Competitiveness. Bill was also a presenter at the 2008 National Association of Government Webmasters conference in Chicago, IL.

Bill is the creator of WebDevelopedia.com and is an active member of several discussion lists, including the CSS Discussion List. When not online, Bill can be found enjoying the company of his girlfriend, Jessica and their dog, Leica (she doesn’t have a web site).

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Embed External Content via iframe and div
• Absolute Horizontal and Vertical Centering via CSS
• Multiple Loops and Multiple Columns with WordPress, (X)HTML and CSS
• Sexy HTML List Tricks
• Fun with Downlevel Conditional Comments
• One Link to Open Them All
• Auto-Focus Form Elements with JavaScript

Although these methods are useful for legitimate purposes, they may compromise the security of your server by enabling cross-site scripting attacks (XST). By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE and TRACK methods to intercept your visitors’ sensitive data. The solution, of course, is disable these methods on your webserver.

How to disable the TRACE and TRACK methods

To disable TRACE and TRACK HTTP methods on your Apache-powered webserver, add the following directives to either your main configuration file or root HTAccess file:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

These directives disable the TRACE and TRACK methods via the following process:

• RewriteEngine on — enables Apache’s rewrite module (this directive is not required if already present in your htaccess file)
• RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) — targets all TRACE and TRACK request methods for the following rule
• RewriteRule .* - [F] — return a 403 Forbidden error response for all matched conditions (i.e., all TRACE and TRACK methods)

With these rules in place, your site is protected against one more potential security vulnerability :)

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Stupid htaccess Trick: Enable File or Directory Access to Your Password-Protected Site
• 4G Series: The Ultimate User-Agent Blacklist, Featuring Over 1200 Bad Bots
• 4G Series: The Ultimate Referrer Blacklist, Featuring Over 8000 Banned Referrers
• Secure Visitor Posting for WordPress
• Industrial-Strength Spamless Email Links
• Permanently Redirect a Specific IP Request for a Single Page via htaccess
• Temporary Site Redirect for Visitors during Site Updates

• Robots.txt directives
• Nofollow attributes on links
• Meta noindex/nofollow directives
• X-Robots noindex/nofollow directives

..and so on. These directives all function in different ways, but they all serve the same basic purpose: control how Google crawls the various pages on your site. For example, you can use meta noindex to instruct Google not to index your sitemap, RSS feed, or any other page you wish. This level of control over which pages are crawled and indexed is helpful, but what if you need to control how Google crawls the contents of a specific page? Easy. Google enables us to do this with a set of googleon/googleoff tags.

About googleon and googleoff tags

Put simply, the googleon/googleoff tags tell GoogleBot Google Search Appliance when to start and stop indexing various parts of the web document. Consider the following example:

<p>This is normal (X)HTML content that will be indexed by Google.</p>

<!--googleoff: index-->

<p>This (X)HTML content will NOT be indexed by Google.</p>

<!--googleon: index>

In this example, we see how the googleon/googleoff tags will prevent the second paragraph from being indexed by Google. Notice the “index” parameter, which may be set to any of the following:

• index — content surrounded by “googleoff: index” will not be indexed by Google
• anchor — anchor text for any links within a “googleoff: anchor” area will not be associated with the target page
• snippet — content surrounded by “googleoff: snippet” will not be used to create snippets for search results
• all — content surrounded by “googleoff: all” are treated with all attributes: index, anchor, and snippet

Cool, eh? Let’s have a look at a specific usage example..

Using googleon and googleoff tags

Example 1: Blog Comments
Let’s say your comment threads tend to stray into off-topic conversation. Keeping your pages as tightly focused on the subject at hand is a great way to improve the on-page relevancy of your targeted keywords while improving the accuracy of matching search queries. Thus, to keep the superfluous banter out of the Google index, you could add googleon/googleoff tags as follows:

<!--googleoff: all-->

<div id="comments">

   <p><strong>Nick Mason</strong> - August 2nd, 2009</p>
   <p>From Her Majesty the queen. His boots were very clean.</p>

   <p><strong>Rick Wright</strong> - August 3rd, 2009</p>
   <p>Every year is getting shorter, never seem to find the time.</p>

   <p><strong>David Gilmour</strong> - August 4th, 2009</p>
   <p>By the river holding hands roll me up and lay me down.</p>

   <p><strong>Roger Waters</strong> - August 5th, 2009</p>
   <p>And after a while, you can work on points for style.</p>

</div>

<!--googleon: all>

We definitely don’t want to see such a mindless thread in Google, and it will be interesting to see if the <pre> example gets dropped from the index..

May the Force be with You

While using this method to control how Google indexes your on-page content, there are a couple of things you should keep in mind. First, there is a difference between indexing and crawling. Google may crawl portions of your page that are demarcated with googleon/googleoff tags. So in case you were thinking that this technique may be a way to deal with Google’s new nofollow policy, forget about it — PageRank will continue to flow through any links contained within a googleoff zone.

Besides this, also keep in mind that this is a proprietary technique supported exclusively by Google Search Appliance. If you have content that you want to keep out of the index of all search engines, then you will need to find another way to do it. Eventually, Yahoo! and MSN/Live/Bing/Whatever may create proprietary “on/off tags” of their own, but chances are slim to none that they will obey the proprietary technology of the mighty Google.

For more information about googleon/googleoff tags, check out Google’s official documentation.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Stop WordPress from Leaking PageRank to Admin Pages
• Choosing the Best Title Separators
• Custom OpenSearch Functionality for Your Website
• Valid, SEO-Friendly Post Translation Links
• SEO Experiment: Let Google Sort it Out
• Dynamic Link Insertion via Unobtrusive External JavaScript
• Robots Notes Plus

But these list elements aren’t just sexy, they are also extremely flexible, enabling us humble designers to create robust list configurations that are semantically versatile and highly customizable. We all know how to throw down a basic list:

<ul>
	<li>Pancakes</li>
	<li>Bananas</li>
	<li>Monkeys</li>
</ul>

Or even throw down some hardcore nested-list action:

<ul>
	<li>Pancakes
		<ol>
			<li>Swedish</li>
			<li>Blueberry</li>
			<li>Chocolate</li>
		</ol>
	</li>
	<li>Bananas
		<ol>
			<li>Manzano</li>
			<li>Plantain</li>
			<li>Cavendish</li>
		</ol>
	</li>
	<li>Monkeys
		<ol>
			<li>Spider</li>
			<li>Howler</li>
			<li>Squirrel</li>
		</ol>
	</li>
</ul>

This nested list markup will result in a unordered bulleted parent list with numerically ordered nested lists, resulting in something like this in a browser:

• Pancakes
  1. Swedish
  2. Blueberry
  3. Chocolate
• Bananas
  1. Manzano
  2. Plantain
  3. Cavendish
• Monkeys
  1. Spider
  2. Howler
  3. Squirrel

Of course, we can style the display of this list configuration with some super-sexy CSS. For example, we can change the appearance of both ordered ( <ol> ) and unordered ( <ul> ) list markers by specifying one of the following types:

ul, ol {
	list-style-type: none;                 /* no list marker */
	list-style-type: disc;                 /* filled circles */
	list-style-type: square;               /* square markers */
	list-style-type: circle;               /* circle markers */
	list-style-type: inherit;              /* inherits style */
	list-style-type: decimal;              /* number markers */
	list-style-type: decimal-leading-zero; /* 01, 02, 03, .. */
	list-style-type: lower-alpha;          /* a, b, c, d, .. */
	list-style-type: lower-latin;          /* a, b, c, d, .. */
	list-style-type: lower-greek;          /* alpha, beta .. */
	list-style-type: lower-roman;          /* i, ii, iii, .. */
	list-style-type: upper-alpha;          /* A, B, C, D, .. */
	list-style-type: upper-latin;          /* A, B, C, D, .. */
	list-style-type: upper-roman;          /* I, II, III, .. */
	}

And, as if those options weren’t enough, CSS also enables us to use any list marker imaginable via the incredibly sexy list-style-image property. For example, we could create a small GIF image of a banana and use it as a list marker with the following CSS:

ul, ol {
	list-style-image: url(banana.gif);
	}

This technique is also possible by setting a background-image for the individual list ( <li> ) items, thereby providing a greater degree of presentational control:

ul li, ol li {
	background-image: url(banana.gif);
	}

We can even combine these methods to establish a built-in fallback mechanism that will enable the custom list-marker images to degrade gracefully to any list-style type. While we’re at it, let’s change the position of the list markers to appear within the list element itself:

ul {
	list-style-image: url(banana.gif);
	list-style-position: inside;
	list-style-type: circle;
	}

This will give us an unordered list that displays our custom banana.gif marker if supported, else the list markers will be displayed as circles. Further, the list markers in this example will be displayed on the inside of the list items. To conserve resources, we may combine these three rules into the following “shortcut” declaration:

ul {
	list-style: circle url(banana.gif) inside;
	}

If we wanted to display the list without markers, there are two ways to prevent long strings of list text from extending past the first line, for example:

  Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, 
Lorem ipsum blah blah blah, Lorem ipsum blah blah blah,

  Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, 
Lorem ipsum blah blah blah, Lorem ipsum blah blah blah,

  Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, 
Lorem ipsum blah blah blah, Lorem ipsum blah blah blah.

This case happens when the list-style-position is set to inside and the list text wraps onto subsequent lines. So, to alleviate this awkward list display, simply remove the list-style-position:inside declaration or explicitly specify it as list-style-position:outside;. Alternately, if you simply must use an inline display-type, you can prevent subsequent lines from “underlapping” the first line by using the oft-overlooked text-indent property:

ul {
	list-style-position: inside;
	text-indent: -0.7em;
	list-style: none;
	}

The text-indent technique is also useful when using generated content for your list markers. For example, by generating list markers with the following CSS:

ul {
	list-style: none;
	}
ul li:before {
	content: "\00BB \0020";
	}

You will see this for short list items:

• Pancakes
• Bananas
• Monkeys

And this for long list items:

• Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah. Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah.
• Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah. Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah.
• Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah. Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah, Lorem ipsum blah blah blah.

Ugh! There’s that nasty underlapping text wrap again. This happens because the generated content is inserted within the list elements. Unfortunately, setting the display-type to outside does not help in this scenario. Fortunately, we can easily resolve this issue by including a text-indent declaration to our previous list styles:

ul {
	text-indent: -1em;
	list-style: none;
	}
ul li:before {
	content: "\00BB \0020";
	}

Problem solved. At this point, you may be thinking, “what’s with all of that funky ‘generated content’ stuff?” If so, allow me to explain.

CSS 2.1 provides us with tools that enable us to insert various types of content into our markup. By combining the :before or :after pseudo-selectors and the content property, we can add alphanumeric and special characters into our document via the stylesheet. The characters that may be inserted may be alphanumeric text strings or escaped hexadecimal character equivalents such as the following:

• \0020 — blank space, unicode =  
• \21D3 — down arrow, unicode = ⇓ ( ⇓ )
• \00BB — right double angle quote, unicode = » ( » )

But wait, there’s more! Using CSS may be the modern, “Web-Standards” way of configuring the presentation of list elements, but there are also some interesting and useful inline tricks that, although deprecated, prove a delightful romp nonetheless. Let’s peek into the past, shall we?

First, the list-style type property may be specified inline for <ul> (and even <li>) elements:

<ul type=circle>
	<li>Telegraph</li>
	<li>Telephone</li>
	<li>Mobile phone</li>
</ul>

For unordered lists, the accepted values are circle, square, and disc. For ordered lists, the accepted property values are A, a, I, i, and 1. Here is an example:

<ol type=A>
	<li>Atari</li>
	<li>Nintendo</li>
	<li>Playstation</li>
</ul>

Here is a breakdown of the accepted values for the type property:

• circle — circle markers
• square — square markers
• disc — disc markers
• A — uppercase letters
• a — lowercase letters
• I — uppercase roman
• i — lowercase roman
• 1 — default markers

That’s all fine and well, but something that is far more useful is the ability to set specific values for various list items. By using the deprecated value attribute applied to the <li> element, we may set marker values as in the following example:

<ol>
	<li value=3>The marker for this item is the number 3</li>
	<li>The marker for this item is the number 4</li>
	<li>The marker for this item is the number 5</li>
	<li value=11>The marker for this item is the number 11</li>
	<li>The marker for this item is the number 12</li>
	<li>The marker for this item is the number 13</li>
</ol>

..which looks like this:

3. The marker for this item is the number 3
4. The marker for this item is the number 4
5. The marker for this item is the number 5
11. The marker for this item is the number 11
12. The marker for this item is the number 12
13. The marker for this item is the number 13

We can do something similar by using the start attribute, which enables us to specify the initial value of an ordered list. Here is an example:

<ol start=77>
	<li>The marker for this item is the number 77</li>
	<li>The marker for this item is the number 78</li>
	<li>The marker for this item is the number 79</li>
</ol>

..which produces this:

77. The marker for this item is the number 77
78. The marker for this item is the number 78
79. The marker for this item is the number 79

This seems incredibly useful, such that I wonder if there is an equivalent way to accomplish this using modern methods, CSS and/or HTML.

One final trick before I close — older versions of HTML enable you to create “compact” lists using the compact attribute:

<ol compact>
	<li>Business</li>
	<li>Pleasure</li>
	<li>Nonsense</li>
</ol>

The idea here is that any list featuring the compact attribute will be displayed in a more compact fashion in the browser. Instead of applying the usual margin and padding to the list and its various items, the browser will reduce the amount of these properties to render a tighter, more “compact”-looking list.

That does it for this fun-filled episode of Sexy HTML List Tricks — stay tuned for more exciting content from Perishable Press.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Absolute Horizontal and Vertical Centering via CSS
• Multiple Loops and Multiple Columns with WordPress, (X)HTML and CSS
• Embed External Content via iframe and div
• Maximum and Minimum Height and Width in Internet Explorer
• Prevent JavaScript Elements from Breaking Page Layout when Following Yahoo Performance Tip #6: Place Scripts at the Bottom
• CSS/(X)HTML Tutorial: Hovering Accessibility Jump Menu
• Series Summary: Obsessive CSS Code Formatting

You think I’m joking

Before we begin, I feel it necessary to emphasize the serious need for millions of mobile makeovers. There are waay tooo many sites that are completely inaccessible on the Mobile Web simply because their owners are either too lazy or ignorant to do anything about it. Think I’m joking? For those of you who haven’t surfed via mobile recently, allow me to share a few surprisingly borked websites:

Mobile screenshots of WordPress.com, and About.com, Go.com

Mobile screenshots of Alexa.com, DailyMotion.com, MediaFire.com, and Hi5.com

Mobile screenshots of Go.com, Wikipedia.com, imdb.com, and Conduit.com

As you can see, it’s a bloody war zone out there. And we’re not just talking about smaller, personal sites either — all of the screenshots shown above were taken from the top 50 sites on the Web [1]. Sure, some sites are still readable, but if there is a better alternative elsewhere on the Web, I’m there. Other sites are just too terrible to even consider, and get bounced out of the browser before you can say, “WTF?” If this sounds like your site, or if you’re just not sure because you’ve never actually seen your site from a mobile device, it’s time for a mobile makeover.

Mobile stylesheets to the rescue

Even if you do nothing else to fix your broken site, add an alternate stylesheet for mobile devices. Really. You don’t even have to include any styles — the very presence of a mobile-specific stylesheet will override all styles from your screen stylesheet, thereby simplifying the presentation of your site. Including a mobile-specific stylesheet is as easy as uploading a blank .css file and adding the following code to the <head> of your web pages:

<link rel="stylesheet" href="http://domain.tld/mobile.css" type="text/css" media="handheld" />

The key here is the media="handheld" attribute, which tells browsers to apply the linked stylesheet to all mobile devices. This method isn’t perfect, especially considering the difficulty of testing on the millions of different mobile devices currently available. For example, the Windows Mobile browser will not apply media="handheld" stylesheets if a media="screen" stylesheet is also included. This is unfortunate because virtually all websites use a screen-media stylesheet to style their sites. Fortunately, there is a simple yet effective fix that will force Windows Mobile browsers to apply handheld-media stylesheets whenever available.

The trick to getting Windows Mobile to recognize handheld stylesheets is to capitalize the media attribute value for the screen stylesheet:

<link rel="stylesheet" href="http://domain.tld/screen.css" type="text/css" media="Screen" />
<link rel="stylesheet" href="http://domain.tld/mobile.css" type="text/css" media="handheld" />

Notice the capital “S” in “Screen”? That’s all it takes to get handheld stylesheets working in Windows Mobile browsers.

Take-home message for basic mobile-friendliness: clear your default browser styles by including a blank handheld stylesheet via the “Capital-S Method” described above. Then, once your site’s presentation is reset to (mobile) browser defaults, move on to the next section for additional mobile-makeover tips.

Dinosaur protection

At this point you should be delivering at least two separate stylesheets, one for screen media and another for handheld media. So far so good, but we need to account for older browsers that may ignore the handheld attribute and apply the mobile styles to the page. This could have a devastating impact on the look of your site in older browsers. To help prevent this from happening, we want to enclose any mobile-specific styles within an @media selector as follows:

@media handheld {

	.selector-01 {
		padding: 0;
		margin: 0;
		}
	.selector-02 {
		padding: 0;
		margin: 0;
		}
	.selector-03 {
		padding: 0;
		margin: 0;
		}

}

This is merely a precautionary measure aimed at preventing old browsers from applying your mobile styles to your normal screen styles. All CSS styles that are placed in your handheld stylesheet should be enclosed and qualified by the @media handheld selector.

Apply some mobile styles

Now that you’ve got everything setup and ready to go, it’s time to apply some sweet mobile styles to get your pages looking oh so tuff. Of course the amount of styling is entirely up to you — you design your mobile pages as elaborately or as minimally as desired. As mentioned, by merely including the mobile stylesheet, you will have effectively neutralized any full-size screen styles that you may have had in place. Thus, as you start out, you will see something similar to this:

Default mobile browser styles on the HTC 8525 mobile device

As you can see, compared with the atrocious examples shown above, the simple act of including even a blank stylesheet can take your site from “WTF!!!” to “FTW!!!” in the blink of an eye.

But why stop there? Sure your site displays all nice, crisp and clean on mobile devices, but there are a few basic improvements that can greatly enhance the look and feel of your mobile site. For example, mobile browsers are usually pretty tiny, so you will want to maximize every pixel of available screen space. One way of doing this involves eliminating extraneous margins and padding from around the <html> and <body> elements. Nothing too extreme, perhaps a nice 3-pixel bit of padding to give the content just enough breathing room. While we’re at it, let’s ensure we’ve got a clean white background and some nicely contrasting text color:

html, body {
	background: #fff;
	padding: 3px;
	color: #000;
	margin: 0;
	}

Of course, the goal here is to get you thinking about how to customize the presentation of your site. Background colors, text colors, and even font families are all fun things to play around with. To keep things basic, we can add a simple, sans-serif font with a decent font-size and line height:

html, body {
	font: 12px/15px sans-serif;
	background: #fff;
	padding: 3px;
	color: #000;
	margin: 0;
	}

Mind your floats please

An important thing to keep in mind as you implement a new handheld stylesheet is that all of the content will appear in linear order in a single column down the length of the page. Floated items such as sidebars, callouts, and other items will appear either above or below your main content, depending on the order of appearance in the source code. This is a good thing, especially considering the extremely narrow screen-widths of most mobile devices. To include a floated sidebar would require users to scroll horizontally as well as vertically. As you may know, horizontal scrolling sucks, especially when working on the go. So keep this in mind before re-floating anything in your handheld stylesheet. To be extra cautious, the truly paranoid can add this to their mobile styles:

* {
	float: none;
	}

There is no width

Similar thinking applies for content width. Any explicit widths (those set in pixels or ems) that you set in your mobile stylesheet will probably do more harm than good, especially considering the extreme variation in screen widths across devices. Specifying a width for your content may result in proper display in a few devices, but there inevitably will be many more that will require horizontal scrolling to display the content. A good solution is to either specify your widths in percentages or avoid specifying widths except where required for layout purposes (e.g., for small graphics, etc.).

Eliminate clutter

Keeping things simple is one of the primary goals when designing for small screens. On a full-size web page, you’ve got plenty of room for lots of buttons, badges, advertisements, photos, and anything else that tickles your fancy. The question you need to ask yourself is, “how much of this content is necessary for my mobile visitors?” Only you can make that decision, but there are a few questions that may help you think through the process:

• What are mobile visitors looking for? What information do they want/need?
• Do mobile visitors have time/interest in all of my tedious sidebar content?
• With a barebones stylesheet, which elements are clearly superfluous?
• Which navigational elements are absolutely necessary? Which are redundant?
• Are there entire regions of my page that would be better off not displayed?

And so on and so forth. Hopefully you get the idea: only display what is absolutely necessary or essential. Perhaps an example will serve to illustrate the point. Here at Perishable Press, I recently implemented a mobile-friendly stylesheet for some of my themes. The thinking/design process went something like this:

• First, reset everything to default mobile styles.
• Most mobile visitors are here for one thing: content.
• Thus, there is no need for a sidebar or a super-footer.
• I decided to display a small logo, some header nav, and a small footer.
• Basic styles were applied to post content and comments.
• The result is a clean, easy-to-use mobile version of my site.

And of course, to hide the unwanted elements, I added the following CSS:

#sidebar, #footer {
	display: none;
	}

Hopefully that is clear, the idea is to apply display:none; to the outermost element of the area that you would like to hide. As a noob way back in the day, I didn’t realize this, and instead applied display:none; to every element within the hidden area. So silly ;)

More mobile-makeover tips

Slim down heading elements
On many mobile devices (at least on the ones that I’ve seen), heading text frequently appears to be heavily overweighted (new word), especially text within <h1> and <h2> elements. To alleviate this issue, we can add the following CSS to our handheld stylesheet:

h1, h2, h3, h4, h5, h6 {
	font-weight: normal;
	}

Control your images
Images are another element that you may want to consider. Chances are that many of your images exceed the width of most mobile browsers, which may or may not automatically resize them. Fortunately, we can apply a maximum-width to our images that will help insure their proper scaling in supportive browsers. The trick is choosing a max-width that accommodates the widest variety of mobile devices. As an example, here is how to apply a max-width of 250px for all images in our main content <div>:

#content img { 
	max-width: 250px;
	}

Front and center
Centering headings, footer credits, and other information is a uesful way to bring a sense of organization and balance to your mobile presentation. Here is an easy way to do so:

.center {
	width: 100%; !important;
	text-align: center;
	}

Link me deadly
Last but not least, links are perhaps the most important element on the mobile page. When easily identifiable, links help visitors navigate easily and efficiently. When poorly styled or otherwise obscure, links are essentially useless, leaving your visitors groping in the dark for their next move. Thus, when styling your mobile links, it is good practice to emulate conventional link appearance with an underline, distinguished color, and perhaps a slightly contrasting background color to boot. Here is an example that keeps links looking crisp and clean:

a:link, a:visited {
	text-decoration: underline;
	color: #0000CC;
	}
a:hover, a:active {
	text-decoration: underline;
	color: #660066;
	}

Apply styles to the iPhone

As you go about applying styles for the mobile presentation of your site, you will inevitably want to target the ubiquitous iPhone and apply a few iPhone-specific CSS styles. Fortunately, the iPhone has a rather unique screen width, enabling us to target specific selectors with the following @media selector:

@media only screen and (max-device-width: 480px) { 

	.selector {
		padding: 0;
		margin: 0;
		}

}

With this technique, you can target any elements you wish. Simply enclose your iPhone-specific CSS with that crazy-looking @media selector and enjoy the results. Note that there are other (non-iPhone) mobile browsers that also have the same screen width as the iPhone, so any styles targeting the iPhone may also be applied to a few other devices as well.

Another useful technique for the iPhone involves controlling the automatic resizing of text. The iPhone has an annoying habit of adjusting font size according to the width of the web page. While occasionally useful, this “feature” has a tendency to make your web pages look like crap. Fortunately, we can override this feature with the following slice of CSS:

html {
	-webkit-text-size-adjust: none;
	}

This is a proprietary property aimed exclusively at Safari. Accepted values are as follows:

• none — this is the default value. no text-size adjustments will be made
• auto — leave it up to the Safari browser to handle any text-size adjustments
• %value — specify an explicit percentage value by which to adjust text-size

Have more sweet iPhone design tips? Share it with a comment! :)

Putting it all together

Let’s put everything together to create a basic handheld stylesheet template. Applied to your site via separate external handheld stylesheet, the following code will give your site a quick 5-minute mobile makeover:

/* mobile styles */
@media handheld {

	html, body {
		font: 12px/15px sans-serif;
		background: #fff;
		padding: 3px;
		color: #000;
		margin: 0;
		}
	#sidebar, #footer {
		display: none;
		}
	h1, h2, h3, h4, h5, h6 {
		font-weight: normal;
		}
	#content img { 
		max-width: 250px;
		}
	.center {
		width: 100%; !important;
		text-align: center;
		}
	a:link, a:visited {
		text-decoration: underline;
		color: #0000CC;
		}
	a:hover, a:active {
		text-decoration: underline;
		color: #660066;
		}

}
/* iPhone-specific styles */
@media only screen and (max-device-width: 480px) { 

	html {
		-webkit-text-size-adjust: none;
		}

}

These are some of the CSS rules that I use for various themes here at Perishable Press. After customizing a basic set of styles with some fresh link colors and a few other bits of presentational seasoning, I have transformed my complex screen designs into something crisp, clean, and easy to read for my mobile visitors:

Mobile Screenshot of Perishable Press

No more excuses

With these simple steps, you can ensure that your visitors are able to access your content in a user-friendly way. You don’t need to create a complete mobile version of your site, but adding a few basic rules will ensure that your site is available, accessible, and useful for your mobile visitors. So no more excuses! We have the technology and skills to make the mobile Web a better place. Get on board and pimp your sites for the Mobile Web today.

[1] According to Alexa, which may or may not be the most accurate source of information.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• New Mobile CSS Styles for Perishable Press
• CSS/(X)HTML Tutorial: Hovering Accessibility Jump Menu
• A Complete CSS Template File
• Accessibility Notes Plus
• IE Scrollbar Colors
• Absolutely Centered Layout
• Automatic Language Translation Methods

Web designers can do some pretty cool stuff with HTML 4 and CSS 2.1. We can structure our documents logically and create information-rich sites without relying on archaic, table-based layouts. We can style our web pages with beauty and detail without resorting to inline <font> and <br> tags. Indeed, our current design methods have taken us far beyond the hellish era of browser wars, proprietary protocols, and those hideous flashing, scrolling, and blinking web pages.

As far as we’ve come using HTML 4 and CSS 2.1, however, we can do better. We can refine the structure of our documents and increase their semantic precision. We can sharpen the presentation of our stylesheets and advance their stylistic flexibility. As we continue to push the boundaries of existing languages, HTML 5 and CSS 3 are quickly gaining popularity, revealing their collective power with some exciting new design possibilities.

Goodbye <div> soup, hello semantic markup

In the past, designers wrestled with semantically incorrect table-based layouts. Eventually, thanks to revolutionary thinking from the likes of Jeffrey Zeldman and Eric Meyer, savvy designers embraced more semantically correct layout methods, structuring their pages with <div> elements instead of tables, and using external stylesheets for presentation. Unfortunately, complex designs require significant differentiation of underlying structural elements, which commonly results in the “<div>-soup” syndrome. Perhaps this looks familiar:

<div id="news">
   <div class="section">
      <div class="article">
         <div class="header">
            <h1>Div Soup Demonstration</h1>
            <p>Posted on July 11th, 2009</p>
         </div>
         <div class="content">
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
         </div>
         <div class="footer">
            <p>Tags: HMTL, code, demo</p>
         </div>
      </div>
      <div class="aside">
         <div class="header">
            <h1>Tangential Information</h1>
         </div>
         <div class="content">
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
         </div>
         <div class="footer">
            <p>Tags: HMTL, code, demo</p>
         </div>
      </div>
   </div>
</div>

While slightly contrived, this example serves to illustrate the structural redundancy of designing complex layouts with HTML 4 (as well as XHTML 1.1 et al). Fortunately, HTML 5 alleviates <div>-soup syndrome by giving us a new set of structural elements. These new HTML 5 elements replace meaningless <div>s with more semantically accurate definitions, and in doing so provide more “natural” CSS hooks with which to style the document. With HTML 5, our example evolves:

<section>
   <section>
      <article>
         <header>
            <h1>Div Soup Demonstration</h1>
            <p>Posted on July 11th, 2009</p>
         </header>
         <section>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
         </section>
         <footer>
            <p>Tags: HMTL, code, demo</p>
         </footer>
      </article>
      <aside>
         <header>
            <h1>Tangential Information</h1>
         </header>
         <section>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
            <p>Lorem ipsum text blah blah blah.</p>
         </section>
         <footer>
            <p>Tags: HMTL, code, demo</p>
         </footer>
      </aside>
   </section>
</section>

As you can see, HTML 5 enables us to replace our multitude of <div>s with semantically meaningful structural elements. This semantic specificity not only improves the underlying quality and meaningfulness of our web pages, but also enables us to remove many of the class and id attributes that were previously required for targeting our CSS. In fact, CSS 3 makes it possible to eliminate virtually all class and id attributes.

Goodbye class attributes, hello clean markup

When combined with the new semantic elements of HTML 5, CSS 3 provides web designers with god-like powers over their web pages. With the power of HTML 5, we obtain significantly more control over the structure of our documents, and with the power of CSS 3, our control over the presentation of our documents tends toward infinity.

Even without some of the advanced CSS selectors available to us, the new variety of specific HTML 5 elements enable us to apply styles across similar sections without the need for defining class and id attributes. To style our previous <div>-soup example, we would target the multitude of attributes via the following CSS:

div#news    {}
div.section {}
div.article {}
div.header  {}
div.content {}
div.footer  {}
div.aside   {}

On the other hand, to style our HTML 5 example, we may target the various documents regions directly with this CSS:

section {}
article {}
header  {}
footer  {}
aside   {}

This is an improvement, but there are several issues that need addressed. With the <div> example, we target each area specifically through use of class and id attributes. Using this logic allows us to apply styles to each region of the document, either collectively or individually. For example, in the <div> case, .section and .content divisions are easily distinguished; however, in the HTML 5 case, the section element is used for both of these areas and others as well. This is easily resolved by adding specific attribute selectors to the different section elements, but thankfully, we instead may use a few advanced CSS selectors to target the different section elements in obtrusive fashion.

Targeting HTML-5 elements without classes or ids

Rounding out the article, let’s look at some practical examples of targeting HTML-5 elements without classes or ids. There are three types of CSS selectors that will enable us to target and differentiate the elements in our example. They are as follows:

• The descendant selector [CSS 2.1]: E F
• The adjacent selector [CSS 2.1]: E + F
• The child selector [CSS 2.1]: E > F

Let’s have a look at how these selectors enable us to target each of our document sections without the need for classes or ids.

Targeting the outermost <section> element
Due to the incompleteness of our example, we will assume that the outermost <section> element is adjacent to a <nav> element which itself is a direct descendant of the <body> element. In this case, we may target the outermost <section> as follows:

body nav+section {}

Targeting the next <section> element
As the only direct descendant of the outer <section>, the next <section> element may be specifically targeted with the following selector:

section>section {}

Targeting the <article> element
There are several ways to target the <article> element specifically, but the easiest is to use a simple descendant selector:

section section article {}

Targeting the header, section, and footer elements
In our example, each of these three elements exists in two locations: once inside the <article> element and once inside the <aside> element. This distinction makes it easy to target each element individually:

article header {}
article section {}
article footer {}

..or collectively:

section section header {}
section section section {}
section section footer {}

So far, we have managed to eliminate all classes and ids using only CSS 2.1. So why do we even need anything from CSS 3? I’m glad you asked..

Advanced targeting of HTML 5 with CSS 3

While we have managed to target every element in our example using only valid CSS 2.1, there are obviously more complicated situations where the more advanced selective power of CSS 3 is required. Let’s wrap things up with a few specific examples showing how CSS 3 enables us to style any element without extraneous class or id attributes.

Targeting all posts with a unique post ID
WordPress provides us a way of including the ID of each post in the source-code output. This information is generally used for navigational and/or informational purposes, but with CSS 3 we can use these existing yet unique ID attributes as a way to select the posts for styling. Sure, you could always just add a class="post" attribute to every post, but that would defeat the point of this exercise (plus it’s no fun). By using the “substring matching attribute selector,” we can target all posts and their various elements like this:

article[id*=post-] {}           /* target all posts */
article[id*=post-] header h1 {} /* target all post h1 tags */
article[id*=post-] section p {} /* target all post p tags */

Now that’s just sick, and we can do the same thing for numerically identified comments, enabling us to apply targeted styles to associated constructs:

article[id*=comment-] {}           /* target all comments */
article[id*=comment-] header h1 {} /* target all comment h1 tags */
article[id*=comment-] section p {} /* target all comment p tags */

Target any specific section or article
Many sites display numerous of posts and comments. With HTML 5, the markup for these items consists of repetitive series of <section> or <article> elements. To target specific <section> or <article> elements, we turn to the incredible power of the “:nth-child” selector:

section:nth-child(1) {} /* select the first <section> */
article:nth-child(1) {} /* select the first <article> */

section:nth-child(2) {} /* select the second <section> */
article:nth-child(2) {} /* select the second <article> */

In a similar manner, we may also target specific elements in reverse order via the “:nth-last-child” selector:

section:nth-last-child(1) {} /* select the last <section> */
article:nth-last-child(1) {} /* select the last <article> */

section:nth-last-child(2) {} /* select the penultimate <section> */
article:nth-last-child(2) {} /* select the penultimate <article> */

More ways to select specific elements
Another way to select specific instances of HTML-5 elements such as <header>, <section>, and <footer>, is to take advantage of the “:only-of-type” selector. With these HTML-5 elements appearing in multiple locations in the web document, it may be useful to target elements that appear only once within a particular parent element. For example, to select only <section> elements that are the only <section> elements within another <section> element (insane, I know), as in the following markup:

<section>
   <section></section>
   <section>
      <section>Target this section</section>
   </section>
   <section>
      <section>Target this section</section>
   </section>
   <section>
      <section>But not this section</section>
      <section>And not this section</section>
   </section>
   <section></section>
</section>

..we could simply use the following selector:

section>section:only-of-type {}

Again, you could always add an id to the target element, but you would lose the increased scalability, maintainablity, and clarity made possible with an absolute separation of structure and presentation.

The take-home message for these examples is that CSS 3 makes it possible to target virtually any HTML-5 element without littering the document with superfluous presentational attributes.

Much more to come

With the inevitable, exponential rise in popularity of both HTML 5 and CSS 3, designers can look forward to many new and exciting possibilities for their web pages, applications, and scripts. Combined, these two emerging languages provide designers with immense power over the structure and presentation of their web documents. In my next article on this topic, we will explore some of the controversial aspects of HTML 5 and also examine some of the finer nuances of CSS 3. Stay tuned!

Note to WordPress users

You can start using HTML 5 right now. To see a live, working example of a WordPress theme built entirely with HTML 5, CSS, and of course PHP, drop by the Digging into WordPress site and visit our newly revamped Theme Playground. There you will find my recently released H5 WordPress Theme Template available for immediate download. And while you’re there, be sure to secure your copy of Digging into WordPress, coming this Fall.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Rethinking Structural Design with New Elements in HTML 5
• Absolute Horizontal and Vertical Centering via CSS
• XHMTL/CSS Remix: Creative Commons License
• CSS/(X)HTML Tutorial: Hovering Accessibility Jump Menu
• Does Google Hate Web Standards?
• A Complete CSS Template File
• Absolutely Centered Layout

In newer versions (from 2.5 I think) of WordPress, the query_posts() function enables users to display posts in random order using the orderby=rand parameter. This would have made my life easy, as I could have included the following code for each of my random post lists:

<ul class="random-posts">
	<?php query_posts('tag=whatever&showposts=5&offset=0&orderby=rand'); ?>
	<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
	<li>
		<a href="<?php the_permalink(); ?>"><?php the_title(); ?></a>
	</li>
	<?php endwhile; endif; ?>
</ul>

This would have been great, but the random-post ordering doesn’t work for my particular version of WordPress. As it turns out, for older versions of WordPress that are missing the incredibly useful orderby=rand parameter for the query_posts() function, there is an unofficial plugin available in the WordPress Help Forums that imparts the orderby=rand functionality to the query_posts() function, thereby enabling users of pre-2.5 versions of WordPress to implement their own random post loops.

For those of you who would like to setup some random post loops on your own site, here’s how to do it in two easy steps. (Remember, this is only necessary if the above method does not work for your particular version of WordPress.)

Numero Uno: Upload and activate the plugin

Copy & paste the following code into a file named “random-posts.php” (or whatever), upload it to your /wp-plugins/ directory, and activate it via the Plugins panel in the WordPress Admin:

<?php
/*
Plugin Name: Random Posts Query
Description: Imparts random display functionality to posts generated via 
query_posts in older versions of WordPress (especially great for version 2.3)
Author URI: http://wordpress.org/support/topic/70359?replies=3#post-444323
*/

// usage: include "random=true" as a parameter in your query_posts loop

function query_random_posts($query) {
	return query_posts($query . '&random=true');
}
class RandomPosts {
	function orderby($orderby) {
		if (get_query_var('random') == 'true')
			return "RAND()";
		else
			return $orderby;
		}
		function register_query_var($vars) {
			$vars[] = 'random';
			return $vars;
		}
}
add_filter('posts_orderby', array('RandomPosts', 'orderby'));
add_filter('query_vars', array('RandomPosts', 'register_query_var'));
?>

Numero Dos: Include and customize the template code

Once the plugin is in place, create multiple tag-specific and category-specific random-post lists by placing the following code after the main loop in your theme template file (e.g., the sidebar.php file):

<ul class="random-posts">
	<?php // use tag=whatever or category_name=whatever for cat/tag-specific posts ?>
	<?php query_posts('tag=whatever&showposts=5&offset=0&random=true'); ?>
	<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
	<li>
		<a href="<?php the_permalink(); ?>"><?php the_title(); ?></a>
	</li>
	<?php endwhile; endif; ?>
</ul>

Before uploading, make sure you customize this code according to your needs. Old heads feel free to knock the boots, while newer chaps may benefit from the following information:

• As mentioned in the code comments, replace the “tag=whatever” parameter with the name of the tag for which you would like to display random posts.
• To display random posts from a specific category instead of a specific tag, simply replace the tag=whatever parameter with category_name=whatever and change the name to your chosen category.
• Adjust the other query_posts parameters as needed to accomplish your post-display goals. For example, you may also want to display the post excerpt for each post item by including the the_excerpt() tag.
• Note that this code is essentially the same as that given for newer versions of WordPress; the only difference being that you use the orderby=rand parameter for newer versions of WordPress (where the plugin is not required), and random=true for older versions (where the plugin is required).
• Placing additional query_posts() loops after the main loop may result in unintended paging and/or plugin issues, so make sure to place it after the main loop.
• To create multiple lists of random posts, simply create multiple instance of this loop and change the category or tag parameter names to suit your needs.

Time to chill

That concludes this brief retro-tutorial. Although it may not be of much use to those treading the perpetual “upgrade” treadmill, it will hopefully provide some relief for randomizing posts in older WordPress versions.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Add RSS Feed Link Icons to WordPress Category Listings
• Super Loop: Exclude Specific Categories and Display any Number of Posts
• Easily Adaptable WordPress Loop Templates
• Transfer Autometa Plugin Data into All in One SEO Pack
• Quickly Disable or Enable All WordPress Plugins via the Database
• WordPress Tip: Remove Spam from the Comment Subscription Manager
• 3 Ways to Exclude Content from WordPress Feeds

HTAccess password protection works in cascading fashion

Before we begin, there are few things you need to know about Apache’s various password-protection directives. First, these password-protection tricks apply to the directory in which they are placed. For example, to password-protect your entire site, you would place one of these tricks in the web-accessible root HTAccess file for your site. HTAccess directives are applied down the directory structure, in cascading fashion, such that all subdirectories are also protected.

You need two files for password protection: htaccess and htpasswd

The second thing you need to know is that, in most cases, there are two parts to any password-protection implementation: the .htaccess file and the .htpasswd file. The .htaccess file will contain any of the sweet tricks provided in this article, while the .htpasswd file will contain the required username and an encrypted version of your password.

There are several ways to generate your .htpasswd file. If you are comfortable with Unix, you can simply run the “htpasswd” command. For example, entering the following command will create a working password file in the /home/path/ directory:

htpasswd -bc /home/path/.htpasswd username password

Placing the password file above the web-accessible root directory is a good security measure. If you examine the file after it has been created, the only thing it will contain is a line that looks similar to this:

username:Mx1lbGn.nkP8

Instead of running a Unix command, you may prefer to use one of the 200,000 online services providing an online password generator.

Regardless of how or where you decide to create your .htpasswd file, keep its location in mind for use in its associated HTAccess file(s). And yes, you may use one .htpasswd file for multiple HTAccess files placed in multiple directories.

Know which version of Apache you are using

In each of the examples below, the directives are enclosed within an <IfModule> container. This is to prevent your server from crashing if the required Apache modules are not available or not installed. Generally, the required modules will be present, but the <IfModule> check is a good precautionary measure.

When implementing any of the password-protection methods in this article, make sure you double-check which version of Apache you are using before you begin. The examples in this article assume you are using either Apache 1.3 or 2.0, as the <IfModule> containers are checking for the presence of the mod_auth module. Thus, if you are running Apache 2.2 (or better), you will want to replace the current <IfModule> containers with the following:

<IfModule mod_authn_file.c></IfModule>

If in doubt, ask your host, install the ShowIP Firefox extension, or dig around in your server’s control panel. And, if you just don’t know, don’t care, or can’t figure it out, just remove the opening and closing <IfModule> tags from the method you would like to use and call it good. Without them, if your server is not equipped the required module, it will simply return a 500 error message, which is easily resolved by removing the password directives.

You can customize the dialogue on the password prompt

The last thing that you should know before diving into some sweet tricks is that you may customize the message shown on the password prompt by editing the following line in each of the examples in this article:

AuthName "Username and password required"

By changing the text inside of the quotes, you may use any language you wish for the password prompt.

At this point, we’re ready to dive into some juicy HTAccess password-protection tricks!

Basic password protection

To password protect your site or any directory, place this code in the associated HTAccess file:

# basic password protection
<IfModule mod_auth.c>
 AuthUserFile /home/path/.htpasswd
 AuthName "Username and password required"
 AuthType Basic
 <Limit GET POST>
  Require valid-user
 </Limit>
</IfModule>

That’s about as basic as it gets. Remember to create your password file and specify its directory in the first line. Let’s move on to something more interesting.

Open-access for a single IP, password-protect for everyone else

This method is great during project development, where you want open access with the ability to give others access via password:

# password protect excluding specific ip
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 AuthType Basic
 Require valid-user
 Order Deny,Allow
 Deny from all
 Allow from 111.222.333.444
 Satisfy Any
</IfModule>

By placing that code into the HTAccess file of the directory that you would like to protect, only the specified IP will be allowed open access; everyone else will need to enter the proper username and password.

Open access for multiple IPs, password-protect for everyone else

The above code may be modified easily to provide multiple IPs open access while denying everyone else:

# password protect excluding specific ips
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 AuthType Basic
 Require valid-user
 Order Deny,Allow
 Deny from all
 Allow from localhost
 Allow from 111.222.333.444
 Allow from 555.666.777.888
 Satisfy Any
</IfModule>

You may add as many IPs as needed. This method is great during project development, where the following conditions will apply:

• Project development remains private for regular visitors
• Project access may be granted to clients (or anyone) by providing the password
• Members of the development team have open access on their respective machines

In addition to providing unrestricted access to your team, you may also want to keep certain web services in mind by including the following directives (insert above the Satisfy Any directive):

Allow from validator.w3.org
Allow from jigsaw.w3.org
Allow from google.com

Open access for everyone with password-protect for specific IPs

This method is useful for a variety of situations, including cases where you would like to block a list of malicious IPs.

# password protect only for specified ips
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 AuthType Basic
 Require valid-user
 Order Allow,Deny
 Allow from all
 Deny from 111.222.333.444
 Deny from 555.666.777.888
 Satisfy Any
</IfModule>

You may list as many IP addresses as necessary. You may also deny from entire IP blocks by truncating the address accordingly. For example, to block everyone coming from an IP address beginning with “999.888”, we would add the following directive:

Deny from 999.888

For more information on how this works, see this section of my Stupid htaccess Tricks article.

Open access for everyone with password-protect for specific CIDR number

Similar to the previous method, here is a technique for requiring a password only from a select CIDR number. This method is useful for blocking mega-spammers such as RIPE, Optinet, and others. If, for example, you find yourself adding line after line of Apache Deny directives for addresses beginning with the same first few numbers, choose one of them and try a whois lookup. Listed within the whois results will be the CIDR value representing every IP address associated with that particular network. Thus, blocking via CIDR is an effective way to eloquently prevent all IP instances of the offender from accessing your site. Here is a generalized example for blocking by CIDR:

# password protect only for specified CIDR
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 AuthType Basic
 Require valid-user
 Order Allow,Deny
 Allow from all
 Deny from 10.1.0.0/16
 Deny from 80.0.0/8
 Satisfy Any
</IfModule>

Password protect a single file

I have used this technique countless times. To password-protect a single file, simply add this to your HTAccess file:

# password protect single file
<IfModule mod_auth.c>
 <Files "protected.html">
  AuthName "Username and password required"
  AuthUserFile /home/path/.htpasswd
  Require valid-user
  AuthType Basic
 </Files>
</IfModule>

Here we are protecting a file named “protected.html” from access. The file will only be available after submission of the proper username and password.

Password protect multiple files

To protect multiple files, the method is very similar, only this time we are using Apache’s FilesMatch directive. This allows us to list as many files as needed:

# password protect mulitple files
<IfModule mod_auth.c>
 <FilesMatch "(protected\.html)|(passwords\.txt)">
  AuthName "Username and password required"
  AuthUserFile /home/path/.htpasswd
  Require valid-user
  AuthType Basic
 </FilesMatch>
</IfModule>

In this example, we are password protecting two files, “protected.html” and “passwords.txt”. To add more, simply include more instances of “|(filename\.ext)” in the list of files.

Password protect multiple file types

With this method, we are using Apache’s FilesMatch directive to password-protect multiple file types. Here is an example:

# password protect mulitple file types
<IfModule mod_auth.c>
 <FilesMatch "\.(inc|txt|log|dat|zip|rar)$">
  AuthName "Username and password required"
  AuthUserFile /home/path/.htpasswd
  Require valid-user
  AuthType Basic
 </FilesMatch>
</IfModule>

Once in place, this code will require a password for access to the following file types: .inc, .txt, .log, .dat, .zip, and .rar. Customize to suit your needs.

Password protection for everything except a single file

Thanks to Brett Batie for this powerful technique for allowing access to a single file while password-protecting everything else:

# password protect everything except a single file
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 Require valid-user
 AuthType Basic
 <Files "open-access.html">
  Order Deny,Allow
  Deny from all
  Allow from 123.456.789
  Satisfy any
 </Files>
</IfModule>

When placed in the root directory or any parent directory, this code will password-protect everything except the file named “open-access.html”, which itself may be located in any subsequent directory or subdirectory.

To protect everything while allowing access to multiple files, we may use Apache’s FilesMatch directive instead. Here is an example allowing access to “open-access-1.html”, “open-access-2.html”, and “open-access-3.html”:

# password protect everything except specified files
<IfModule mod_auth.c>
 AuthName "Username and password required"
 AuthUserFile /home/path/.htpasswd
 Require valid-user
 AuthType Basic
 <FilesMatch "(open-access-1.html)|(open-access-2.html)|(open-access-3.html)">
  Order Deny,Allow
  Deny from all
  Allow from 123.456.789
  Satisfy any
 </FilesMatch>
</IfModule>

Note that we may consolidate the file list as follows:

<FilesMatch "open-access-[1-3]\.html">

An alternative approach to allowing open access to any file or group of files is to locate them in their own directory with the following directives added to its HTAccess file:

Allow from all
satisfy any

Wrap it up then

As you can see, Apache’ mod_auth functionality makes it possible to configure just about password-protection setup you may need. From preventing access from specific IP addresses and domains to allowing access only for specific files and directories, Apache makes it possible to protect your files easily and securely. And we haven’t even gotten into the many possibilities available for configuring specific user and group authorizations. I think I’ll save that for another article. In the meantime, for more information on Apache’s powerful mod_auth, check out the Official Documentation.

Source: Perishable Press

[ Thank you for subscribing to Perishable Press ]

Related articles

• Ultimate htaccess Blacklist 2 (Compressed Version)
• Stupid htaccess Trick: Enable File or Directory Access to Your Password-Protected Site
• Three Ways to Allow Hotlinking in Specific Directories
• Blacklist Candidate Number 2008-01-02
• Blacklist Candidate Number 2008-02-10
• Blacklist Candidate Number 2008-03-09
• Blacklist Candidate Number 2008-04-27