Awhile ago, Silvan Mühlemann conducted a 1.5 year experiment whereby different approaches to email obfuscation were tested for effectiveness. Nine different methods were implemented, with each test account receiving anywhere from 1800 to zero spam emails. Here is an excerpt from the article:

When displaying an e-mail address on a website you obviously want to obfuscate it to avoid it getting harvested by spammers. But which obfuscation method is the best one? I drove a test to find out.

After reading through the article and its many findings, here are what seem to be the best methods for obfuscating email addresses displayed publicly on web pages..

Continue Reading

One of my favorite security measures here at Perishable Press is the site’s virtual Blackhole trap for bad bots. The concept is simple: include a hidden link to a robots.txt-forbidden directory somewhere on your pages. Bots that ignore or disobey your robots rules will crawl the link and fall into the trap, which then performs a WHOIS Lookup and records the event in the blackhole data file. Once added to the blacklist data file, bad bots immediately are denied access to your site. I call it the “one-strike” rule: bots have one chance to follow the robots.txt protocol, check the site’s robots.txt file, and obey its directives. Failure to comply results in immediate banishment. The best part is that the Blackhole only affects bad bots: normal users never see the hidden link, and good bots obey the robots rules in the first place.

In five easy steps, you can set up your own Blackhole to trap bad bots and protect your site from evil scripts, bandwidth thieves, content scrapers, spammers, and other malicious behavior.

The Blackhole is built with PHP, and uses a bit of .htaccess to protect the blackhole directory. The blackhole script combines heavily modified versions of the Kloth.net script (for the bot trap) and the Network Query Tool (for the whois lookups). Refined over the years and completely revamped for this tutorial, the Blackhole consists of a single plug-&-play directory that contains the following four files:

Continue Reading

For the upcoming Digging into WordPress update for WordPress 3.0, I have been working with WordPress’ multisite functionality. Prior to version 3.0, WordPress came in two flavors: “original” and “multisite” (MU). Most designers probably work with regular, one-blog installations of “regular” WordPress. The htaccess rules for all single-blog installations of WordPress haven’t changed. They are the same for WordPress 3.0 as they are for all previous versions.

But now that multisite has merged with regular-flavored WordPress, we can stick with single-blog installs (which is how things are setup by default), or we can activate multisite functionality and create an unlimited network of sites. The process is still new and there are bugs that need to be worked out, but eventually it will be a widely used WordPress feature. That said, the htaccess rules used for WordPress Multisite may change as the software continues to evolve.

Continue Reading

Over the course of each year, I blacklist a considerable number of individual IP addresses. Every day, Perishable Press is hit with countless numbers of spammers, scrapers, crackers and all sorts of other hapless turds. Weekly examinations of my site’s error logs enable me to filter through the chaff and cherry-pick only the most heinous, nefarious attackers for blacklisting. Minor offenses are generally dismissed, but the evil bastards that insist on wasting resources running redundant automated scripts are immediately investigated via IP lookup and denied access via simple htaccess directive:

<Limit GET POST PUT>
 Order Allow,Deny
 Allow from all
 Deny from 123.456.789
</LIMIT>

Although many of the worst attacks happen in randomized, zombie-like fashion, I have found that individual IPs that are not blacklisted will return repeatedly until finally blocked. Yet, despite the short-term success enjoyed by denying access to the most malicious IPs, the long-term futility of such blacklisting reflects the temporary nature of this solution.

In other words, I have found that blocking individual IPs is useful only for limited periods of time. Thus, every year, I gather my code and flush the blacklist of all individually blocked IP addresses. I then start fresh, adding the worst villains to the list, blocking entire IP ranges if necessary, and referring to previous versions of my htaccess files to cross-check suspiciously familiar entities. Eventually, a new blacklist emerges and I share it at Perishable Press. Here is the current version for 2010..

Continue Reading

There are many ways to optimize your web pages. In addition to reducing HTTP requests and delivering compressed files, we can also minify code content. The easiest way to minify your CSS is to run it through an online code minifier, which automatically eliminates extraneous characters to reduce file size. Minification shrinks file size significantly, by as much as 30% or more (depending on input code). This size-reduction is the net result of numerous micro-optimization techniques applied to your stylesheet. By learning these techniques and integrating them into your coding practice, you’ll create better-optimized CSS during the development process. Sharper skills, cleaner code, faster downloads – it’s a “win-win” for everyone.

In this Perishable Press article, you’ll learn how to write leaner, cleaner CSS using 10+ micro-optimization techniques..

The basic idea behind micro-optimizing your CSS involves writing clean code, eliminating extraneous characters, and reducing overall file size. And you don’t have to rely on an automated script to do everything for you. Instead of writing lazy, sloppy, bloated code and then just dumping your hideous CSS into an automated minifier, it’s better to understand and practice as many micro-optimization tips as possible, given your particular coding style and specific project requirements.

Continue Reading

A good designer knows that tables should not be used for layout, but rather for displaying columns and rows of data. HTML enables the creation of well-structured, well-formatted tables, but they’re used infrequently enough to make remembering all of the different elements and attributes rather time-consuming and tedious. So to make things easier, here is a clean HTML5 template to speed-up development for your next project:

• Update, June 9th: Here is an absolute basic vanilla template for any markup language.
• Update, June 9th: Here is a better template for HTML5. For HTML 4.01 or anything XHTML-flavor, use the following template:

<table dir="ltr" width="500" border="1" 
			summary="purpose/structure for speech output">
	<caption>Here we assign header information to cells 
			by setting the scope attribute.
	</caption>
	<colgroup width="50%" />
	<colgroup id="colgroup" class="colgroup" align="center" 
			valign="middle" title="title" width="1*" 
			span="2" style="background:#ddd;" />
	<thead>
		<tr>
			<th scope="col">Name</th>
			<th scope="col">Side</th>
			<th scope="col">Role</th>
		</tr>
	</thead>
	<tfoot>
		<tr>
			<td>Darth Vader</td>
			<td>Dark</td>
			<td>Sith</td>
		</tr>
	</tfoot>
	<tbody>
		<tr>
			<td>Obi Wan Kenobi</td>
			<td>Light</td>
			<td>Jedi</td>
		</tr>
		<tr>
			<td>Greedo</td>
			<td>South</td>
			<td>Scumbag</td>
		</tr>
	</tbody>
</table>

Ahh, gives me goose bumps just looking at it. You can use this code with any markup language, whether HTML5, HTML 4.1, or any flavor of XHTML. Here is how this basic template looks in the current web page ¹ (using different data and with styles removed):

Continue Reading

To wrap long URLs, strings of text, and other content, just apply this carefully crafted chunk of CSS code to any block-level element (e.g., perfect for <pre> tags):

pre {
	white-space: pre;           /* CSS 2.0 */
	white-space: pre-wrap;      /* CSS 2.1 */
	white-space: pre-line;      /* CSS 3.0 */
	white-space: -pre-wrap;     /* Opera 4-6 */
	white-space: -o-pre-wrap;   /* Opera 7 */
	white-space: -moz-pre-wrap; /* Mozilla */
	white-space: -hp-pre-wrap;  /* HP Printers */
	word-wrap: break-word;      /* IE 5+ */
	}

See demonstration

Explanation

By default, the white-space property is set to normal. So you might see something like this when trying to force long URLs and other continuous strings of text to wrap:

Continue Reading

Redirecting visitors to a maintenance page or other temporary page is an essential tool to have in your tool belt. Using HTAccess, redirecting visitors to a temporary maintenance page is simple and effective. All you need to redirect your visitors is the following code placed in your site’s root HTAccess:

# MAINTENANCE-PAGE REDIRECT
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.000
 RewriteCond %{REQUEST_URI} !/maintenance.html$ [NC]
 RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif) [NC]
 RewriteRule .* /maintenance.html [R=302,L]
</IfModule>

That is the official copy-&-paste goodness right there. Just grab, gulp and go. Of course, there are a few more details for those who may be unfamiliar with the process. Let’s look at all the gory details..

Continue Reading

An excellent way to simplify and streamline your Cascading Style Sheets (CSS) is to take advantage of the many different shorthand properties available to you. Working with a lot of CSS, you eventually memorize these different shortcuts, but every now and then, I find myself needing a quick, straightforward reference for some of the more elaborate property combinations. In this post, I’ll show you the shorthand rules for the following properties:

1. Font Properties
2. List Properties
3. Background Properties
4. Border and Outline Properties
5. Transition Properties (CSS3)

These are the top 5 on my list of most complicated and frequently used shorthand properties. There are others as well, even in CSS3, but I’ll save those for another post. Alright enough of my narcissistic ramblings – let’s do this thing!

Font Properties ↩

Styling fonts involves a number of individual properties. You can save quite a bit of space using shorthand notation, but be careful to include at least font-size and font-family (in that order). Here are all 6 of the font properties along with their default values:

/* font properties with default values */
font-variant: normal
line-height: normal
font-family: varies
font-weight: normal
font-style: normal
font-size: medium

These 6 declaration blocks can be combined into a single shorthand rule, ordered according to W3C specifications:

/* shorthand notation for font properties */
font: [font-style] [font-variant] [font-weight] [font-size]/[line-height] [font-family];

/* EXAMPLES */
font: 14px Georgia, serif;
font: 14px/1.4 Georgia, serif;
font: italic lighter 14px/1.4 Georgia, serif;
font: italic small-caps lighter 14px/1.4 Georgia, serif;

As you can see, a single line of code is used to replace an entire block. Far more elegant, if not slightly awkward looking. The more I use this syntax, the more I like it.

Continue Reading

If you’ve been keeping an eye on your 404 errors recently, you will have noticed an increase in requests for nonexistent mobile files and directories, especially over the past year or so. The scripts and bots requesting these files from your server seem to be looking for a mobile version of your site. Unfortunately, they are wasting bandwidth and resources in the process. It has become common to see the following 404 errors constantly repeated in your log files:

• http://domain.tld/apple-touch-icon.png
• http://domain.tld/iphone
• http://domain.tld/mobile
• http://domain.tld/mobi
• http://domain.tld/m

So some bot comes along, assumes that your site includes a mobile version, and then tries its hand at guessing the location. In the common request-set listed above, we see the bot looking first for an “apple-touch icon,” and then for mobile content in various directories. If this only happens once in awhile, it’s no big deal. But these days I’ve been seeing many different bots requesting these nonexistent resources.

Even worse, these mobile-hungry bots can’t seem to remember where they’ve been – they typically request the same resources repeatedly, and in multiple locations within the directory structure. I frequently see hundreds of these types of requests in my weekly error-log analyses. Needless to say, this is an incredible waste of time, bandwidth, and server resources.

Continue Reading

In my previous post on Quick and Easy CSS @font-face Code, I provide a choice set of CSS rules for embedding custom fonts into your web pages. It’s a solid, cross-browser technique that works great, but as Marty Thornley pointed out, it would be useful to have a more thorough explanation of how the code actually works. So, rather than going back and adding a bunch of additional information to the original post, I’m following up with a visual walkthrough of the @font-face code.

In step-by-step visual format, this article will show you what the code is doing and how to use it with your own custom fonts.

Step 1: Declaring the @font-face rules

The first thing we want to do is copy & paste the quick and easy @font-face code into our stylesheet:

@font-face { /* declare fonts */
	font-family: "MuseoLight";
	src: url("fonts/Museo300-Regular.eot");
	src: local("Museo 300"), local("Museo-300"),
		url("fonts/Museo300-Regular.woff") format("woff"),
		url("fonts/Museo300-Regular.otf") format("opentype"),
		url("fonts/Museo300-Regular.svg#Museo-300") format("svg");
		}

Yes, it’s a hideous-looking chunk of CSS, but that’s not going to stop us from using it to embed our own custom fonts. Let’s break it down and see how the different parts fit together..

Continue Reading

I’ve been using custom fonts in my designs for quite a few sites now, and have refined what seems to be an ideal chunk of CSS code for implementing the @font-face rules. Some of the sites that include these rules include Perishable Press and Digging into WordPress, which look more stylish and refined with the custom fonts in effect. I’ve tested this code on quite a few browsers, including the following:

• Safari 3.1+
• Opera 10+
• Firefox 3.5+
• Chrome 4.0+
• Internet Explorer 6+

This technique delivers your custom fonts quite consistently to all of these browsers, and degrades gracefully for those that don’t support it. Of course, there are always weird exceptions contingent in particular scenarios, but overall it’s a solid chunk of code put together from much research, experimentation, and testing. I share it here hoping it will help others implement custom @font-face fonts quickly and easily. Let’s step to it..

Continue Reading

Jeff Morris recently demonstrated a potential issue with the way WordPress handles multipaged posts and comments. The issue involves WordPress’ inability to discern between multipaged posts and comments that actually exist and those that do not. By redirecting requests for nonexistent numbered pages to the original post, WordPress creates an infinite amount of duplicate content for your site. In this article, we explain the issue, discuss the implications, and provide an easy, working solution.

Understanding the “infinite duplicate content” issue

Using the <!--nextpage--> tag, WordPress makes it easy to split your post content into multiple pages, and also makes it easy to paginate the display of your comment threads. For both paged posts and paged comments, WordPress appends the page number to the permalink. So for example, if we have a post split into 3 pages, WordPress will generate the following set of completely valid permalinks (based on name-only permalink structure):

Continue Reading

Whenever I find myself working with PHP or messing around with server settings, I nearly always create a phpinfo.php file and place it in the root directory of whatever domain I happen to be working on. These types of informational files employ PHP’s handy phpinfo() function to display a concise summary of all of your server’s variables, which may then be referenced for debugging purposes, bragging rights, and so on.

While this sort of thing is normally okay, I frequently forget to remove the file and just leave it sitting there for the entire world to look at. This of course is a big “no-no” for site security, because the phpinfo.php file contains a hefty amount of information about my server, including stuff like:

• The web server version
• The IP address of the host
• The version of the operating system
• The root directory of the web server
• Configuration information about the remote PHP installation
• The username of the user who installed php and if they are a SUDO user

Continue Reading

The updated book is looking better than ever! A little over 3.5 months after Digging into WordPress v1, Chris and I have updated the book, the site, and everything else for DiW Version 2. Both PDF and printed-version of the book now include two new chapters and two free themes. We have a new “Bonus Tricks” chapter with some awesome theme techniques, and another chapter on “WordPress Updates” that explains how to use all the latest WordPress features. Along the way, we also discuss the two free themes that are bundled exclusively with DiW Version 2. We even updated the printed version of the book, which is now available.

Free Lifetime Updates: If you have already bought the book, you should already have gotten an email with a download link for the new version, which also contains the new bundled themes.

Continue Reading