It’s here! Digging into WordPress Version 3.0 is packed with goodness, including a new chapter on WP3, updated core content, and a super-sleek new cover.

DiW3 cover by Chris Coyier

Updated Core Material

Much has changed with WordPress since our previous book update (v2), so for version 3.0 we went through the book and updated/removed outdated core content. Everything is now hot-wired and fine-tuned to the latest version of WordPress, with new popouts and fresh links throughout the book. Here’s a shot from one of the updated core pages (a flow-chart for page templates – more graphic wizardry from Chris!):

New Chapter on WordPress 3.0

WordPress 3.0 is better than ever. Released on June 17th 2010, WP3.0 features tons of new functionality and CMS capabilities. So much good stuff, that we added an entire chapter covering all the best new WP3.0 features:

• New default theme
• Custom Admin usernames
• How to customize your background
• How to setup and use WP MultiSite
• Custom taxonomies, menus, and post types

Plus other great stuff like how to use the built-in shortlink feature, author templates, comment-form template-tags, and more. It’s 20+ pages of new WP3.0 content.

Read more

This Fall, I celebrate five years of blogging. I have written tons of web development stuff at Perishable Press, lots of helpful WordPress stuff at Digging into WordPress, some philosophical stuff at mindfeed.org, creative/artistic stuff at Dead Letter Art, jQuery stuff at jQuery Mix, and some business-related web-design stuff at Monzilla Media. Plus a bunch of interviews, guest posts, and other blogging projects. So yeah, lots of blogging and writing during the past five years. And they just flew by.

Despite what the haters may say, there are some tangible benefits to blogging. As I write, I continue to learn a great deal – not just about the fine art of writing, but also about the nature of the audience, social media, and the Web in general. There’s a lot to it, more than you may realize. Looking back during my recent hiatus, I enjoyed the opportunity to reflect on the past and contemplate lessons learned, future goals, and what it all means. Here are some of my thoughts, strategies, and lessons learned after five years of blogging..

Read more

The 2010 User-Agent Blacklist blocks hundreds of bad bots while ensuring open-access for the major search engines: Google, Bing, Ask, Yahoo, et al. Blocking bad user-agents is an effective addition to any security strategy. It works like this: your site is getting hammered by rogue bots that waste valuable server resources and bandwidth. So you grab a copy of the 2010 UA Blacklist from Perishable Press, include it in your site’s root .htaccess file, and enjoy a more secure and better performing website. It’s that easy.

Proven Security

The 2010 UA Blacklist has been carefully constructed based on rigorous server-log analyses. Obsessive daily log monitoring reveals bad bots scanning for exploits, spamming resources, and wasting bandwidth. While analyzing malicious behavior, evil bots are identified and added to the UA Blacklist. Blocked user-agents are denied access to your site, increasing efficiency and providing safety for your visitors.

Read more

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..

Read more

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:

Read more

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.

Read more

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..

Read more

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.

Read more

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):

Read more

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:

Read more

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
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.000
RewriteCond %{REQUEST_URI} !/maintenance.html$ [NC]
RewriteRule .* /maintenance.html [R=302,L]

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..

Read more

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.

Read more

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.

Read more

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..

Read more

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..

Read more