(Reading time: 4 – 7 minutes)

It has been cold in the San Francisco Bay Area the last week or so… I know, I know, I can hear you out there “Cry me a river, Dave, it’s what you deserve for all those `Another beautiful day in Paradise’ tweets.”

Fine. We’re spoiled here in The City by the Bay. And we like it!

We’re spoiled in more ways than the weather here in San Fran. For example, I’m sitting here in the Automattic lounge on San Francisco’s Embarcadero listening to developer Michael Enslow present the work his company Mister Machine did for Social Media Week.

Automattic Lounge (courtesy Beau Lebens)

You may not know when you’re using HTML5, and that’s ok. Just expect better websites, that’s the take home.

Here’s what’s interesting about the talk:

• The Social Media Week site was built from scratch using a stripped down, in-house WordPress theme template.
• The theme leveraged HTML5Boilerplate and Modernizr to bring cutting edge capability to the website.
• The advantage of using custom post type is being able to get better display of the content on the browser page.

What’s best about all this is hanging out, in person, at the San Francisco WordPress Meetup with about 75 other rabid WordPress aficionados.

Lydia Sugarman, a good friend of mine from the San Francisco entreprenuerial startup circles is here. Ralph Carlson was on his way down from the hills, but his car got cantankerous around Davis (60 miles up the road). No worries, Ralph will be down for a future Meetup. New friends Chantal and Yoli, both talented website designers, are also in the audience.

Woops, someone asked for a show of hands… about 30% of the audience has been working with custom post types and taxonomies. An invisible groundswell.

Stir in custom taxonomies

Next up is Zach Berke of Exygy.com, with details about how custom post types and taxonomies for the Skoll Foundation website.

• Custom taxonomies are to categories as custom post types are to regular posts. This allows more dynamic feeds, as a new custom post can be associated with custom taxonomy.
• Where you would normally see a “Category” metabox on the post editor, you can have a custom taxonomy box.
• Using Brad Williams Custom Post Type UI Plugin for WordPress was a key piece of the implementation puzzle.

This is powerful stuff!

The key to custom taxonomy is defining the elements of the taxonomy. That is, you have to get your taxa in order, taxa being those taxon comprising your taxonomy.

Zach showed how getting this right allowed much more sensible navigation through the Skoll Foundation website. People associated with various issues and causes can be found and listed automatically.

Post formats make life easy for theme developers

Next up: Beau Lebens on Post Formats, a feature introduced in WordPress 3.1. From the Codex link:

Post Formats is a theme feature introduced with Version 3.1. A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post. The Post Formats feature provides a standardized list of formats that are available to all themes that support the feature.

Having standard post formats in WordPress Core really helps theme developers.

This is not to be confused with Custom Post Types, even though it is confusing. A custom post type is a reference to the content contained in a post, and nothing to do with how such content may be displayed. WordPress developer Mark Jaquith has an excellent article on Post Formats vs. Custom Post Types. Definitely worth reading if the difference is important to you.

Mixed media socialization

You’ve undoubtedly heard of mixed media art, maybe even seen it in real life. Certainly, if you’ve ever been to Burning Man, that’s about as mixed as media gets.

A while back, in a comment elsewhere, I described social media as getting the “social,” and not worrying overmuch about the medium. While I’m definitely not the most relentlessly social person, since I’ve started reaching out in person to people I know from online, I’ve noticed a nice carryover effect: the offline and online work together.

If you can find a WordPress or marketing or writing or some other group or meetup close by, attend!

The upshot: if you’re not out there getting some face time with your online colleagues, consider reducing some of your online time and increasing your offline time.

What’s your experience? Are you getting out there and pounding some pavement? Is it helping? Hurting? Comment below!

Post from: Website In A Weekend

Custom post types at San Francisco WordPress Meetup (Face time!)

(Reading time: 5 – 8 minutes)

Programming is fun and easy compared to keeping track of everything.

One of the things I have to keep track of is the Thesis custom_functions.php source file for my Thesis custom template pages. This file sits on the web server of course, but also in a source code repository, and in a local copy running on my development computer.

Normally, this isn’t a problem.

Then I edited custom_functions.php through the built-in WordPress file editor. I forgot that the plugin editor strips out newline escapes ("\n" → "n"), which litters the web page with random letters “n” and thoroughly destroys the layout.

Now, having multiple copies is a problem, because one of the copies is broken.

So I spent a unhappy afternoon being stymied by an “unfixable bug” in the WordPress plugin editor.

“Works for me”

I’m not the only person who has had this trouble.

But none of the WordPress developers have it.

As you can see from the screen capture of the WordPress Trac ticketing system, issue #10903 is closed with a “worksforme.”

That’s a very hackerish thing to say.

I can’t say I blame them. WordPress is free software after all. If this issue really were a problem for me, I’d knuckle down and fix it myself, or pay someone to fix it for me.

Instead, I make like the internet and route around the damage.

The No-solution Solution

The no-solution solution for fixing bugs is pretty simple. Here’s a few concrete suggestions:

1. Leverage the pain of others.

Typically, when you have a bug in a piece of software like WordPress, many other people are experiencing the same problem.

Most likely, someone has also reported the problem.

Once the problem has been reported, it goes on a release schedule for eventual fixing (or not). You have little control (none) over the release schedule, so…

2. Do something else.

For me it falls into the category of “If it don’t work, find sumpin else to do.”

In my example above, I just stopped using the built-in plugin editor. I routed around the problem. Simple.

But that’s not good enough for some people. For example, Holly Jahangiri prefers a more direct approach:

That is an entirely-too-practical approach to life, David. I gravitate towards the “if it don’t work, beat your head against a brick wall until your ears bleed and some geek takes pity on you and figures it out so you’ll stop” approach. :)

3. Bang your head until your ears bleed.

A while back, Jena Isle had a problem with one of her articles submitted to Digg. The article could be loaded from her blog, but it came back with Invalid URL from Digg. It ended in my lap via Holly Jahangiri:

…”Invalid URL” has to do with special characters in the title. In this case, there are no obvious special characters, but when you try to Digg (or strangely enough, even copy from the address bar) the URL from the post page – Bam! error.

I did some poking around on Google, and found that it was known but infrequent problem, and nobody has any idea how to fix it. Blood, leaking from my ears… I emailed Holly something like “Don’t Digg that article.” Problem solved!

Holly, to her credit, continued to bang her head:

Oh, well, it’s still working for me – that bleeding out the ears thing – except there were no geekier geeks racing to my rescue and I did figure it out, finally, I think. For some reason, somehow, it was taking the url as having a comma before blogspot (I have no idea why, unless there’s some place to set that in the plug-in Jen’s using, but I suspect maybe, just maybe, it’s some weird error somewhere in her settings). Anyway, digging it from the FRONT page, not the post page, worked.

Yikes!

If head banging isn’t your thing (and nothing wrong with it if it is), you need to know…

When to punt

Free software such as WordPress depends on users reporting and, when possible, fixing bugs. It’s a good model, as you can see from the wild success of WordPress.

Fixing, or even reporting bugs isn’t always feasible. Putting on my developer hat, when a user can’t precisely describe a bug so that I can reproduce it, I’m not going to have time to fix it. Likewise, when I don’t have to precisely describe a bug, I won’t report it either.

Here are a few guidelines I use for deciding whether to fix or report bugs:

• Do I have time? It’s going to be an hour’s work, at least. If fixing it won’t save me time in the long run, punt.
• Does Google bring back junk? We’re getting close to the day when just about any keyword or phrase with traffic is going to be gamed. If I get no related results from search, punt.
• Is the bug close to my competence level? There is this notion of a “technology stack” (which I’ll write more about in the future*). This means I’ll consider fixing bugs in WordPress, but not in the web server, etc.

NOTE: All of these guidelines apply to like activities, for example, web and WordPress theme design.

If something is just too hard to do, that’s a hint!

As a public service, here’s a recap of techniques for handling bugs:

1. Leverage the pain of others.
2. Do something else.
3. Bang your head until your ears are bleeding.

Can you add to this list? What’s your special technique for handling bugs?

Post from: Website In A Weekend

Saturday Morning Surfing: When a bug is unfixable; leave it alone

(Reading time: 4 – 7 minutes)

When all you have is a hammer, everything looks like a nail. Or something like that, according to Lofti Zadeh.

WordPress is a pretty big hammer, and even when you have screws instead of nails, the hammer still works.

And you, dear reader, are most likely a do-it-yourselfer. Kind of goes with the “website in a weekend” territory.

Sometimes you need more than a hammer. WordPress isn’t always enough. You need more tools in your toolkit. As any good DIYer, you make a point of mastering the selected tools in your toolkit.

Here’s a few of the tools in my WordPress DIY toolkit:

• GIMP, the Gnu Image Manipulation Program. Disclaimer: I was across the street from the Berkeley XCF when Peter and Spencer first wrote the GIMP. I’ve dabbled since version 0.56. GIMP has come a long way!
• Inkscape, SVG done right. Every good pixel program (i.e., GIMP) needs a vector program to drive it. Inkscape fits my bill. While SVG hasn’t gotten the traction it deserves (this is a political problem, not a technical problem), it’s got enough traction to make it worthwhile. And Adobe stiffed me hard on the update from Illustrator 8 to the Creative Suite programs (i.e., no upgrade incentive, so I’m not upgrading).
• Aptana Studio, best of a bad breed. Aptana has succeeded in taming Eclipse, a long running Java Integrated Development Environment which seems to introduce as many problems as it solves from release to release. I’ll probably get flamed for that one, but I’ve tried (unsuccessfully) off and on to like Eclipse since it was first announced – with much fanfare – about 10 years ago. Aptana works beautifully, and it’s free for a basic edition (all you probably need as a small business person).
• Winmerge for Windows, DeltaWalker for MacOSX. Do you know the difference between those two custom.css files? No? How do you plan to find out? I do it the easy way and use a differencing tool. On MS Windows, I use the free Winmerge application. On MacOSX I use DeltaWalker, which is around $40 US, and a very good value.
• Filezilla. FTP is a critically important in every DITer’s toolkit, and Filezilla is one of the best.
• Trac wiki, from Edgewall. Trac is the same software used by Automattic for WordPress development. I also lean heavily on the bug and issue tracking capability of Trac, which is integrated into the wiki. Super convenient!
• Subversion source code control. Think of subversion as “collaborative backups, with complete version history.” It’s more than that, but that’s good enough for now. Take home: you need to have a back up plan in place, and using it, before you go banging away on your WordPress files. Really, you do.
• Notepad/TextEdit: these come with your computer, no need to link. Both of these are invaluable for snapping out fast notes without having to think very much. For example, this blog post was mostly written in TextEdit on my Macbook, then copied into WordPress.

Some DIY Theme Work

I need to add some updates to Thesis theme custom.css that Amanda Farough sent along a couple of weeks ago. As it turns out, I’ve added a large number of modifications to her work, so I can’t just copy her file into my WordPress theme. Everything would break. It would be nasty and you would think “WTH is Dave smoking?”

You may or may not be thinking that anyway…

While we’re at it, let’s upgrade to Thesis 1.8 along the way.

Here’s the order of business:

1. Download current custom.css to Desktop.
2. Compared and merged remote version to Amanda’s version.
3. Compared merged version to version in repository. Woops. That’s no good. The repository is out of date! time to change course, time to install WordPress locally!
4. Started MAMP server.
5. Rebuilt WordPress Whitepaper 6: Develop WordPress Plugins on Windows with WAMP Environment. (I use these whitepapers. Dogfood. [link])
6. Create database for WiaW on localhost.
7. Download WordPress 3.0.1, copy into localhost (MAMP/htdocs) directory.
8. Woops, doesn’t work, install fails. What gives? Bad MySQL command is what gives:
   

   mysql> grant all privileges on *.* to 'wiaw'@'loclahost' with grant option;

   “loclahost?”

   I don’t think so. It’s “localhost.” Fixed.

9. WordPress installed! Yahoo!
10. Copy Thesis 1.8 into themes. This was done by checking out the Thesis code from the subversion repository. That way, when I’m done, I can check it back in and have a archival record of it. (No, I can’t recall why I didn’t do this after the last update to Website In A Weekend. Pretty slack if you ask me, and if you forget back up or archive your junk, I’ll certainly harsh you up about it. =)
11. Copied the “correct” custom.css file into thesis_18 on the new localhost installation.

And that’s enough for my hour. As usual, getting one thing done (theme modification) requires doing something else first (building development environment).

Remember, this DIY hour includes writing this blog post!

And back to you:

How much DIY do you do? What’s in your toolkit? What’s your favorite tool?

Update September 22, 2010: As it turns out, I’m reviewing the Scribe SEO plugin for the next release of Blog Post Engineering. This is the first article I’ve checked. Scribe SEO scored this blog post at 96%.

Post from: Website In A Weekend

DIY WordPress: What’s Your Toolchain Look Like?

(Reading time: 5 – 8 minutes)

“Code is poetry.”

You’ve probably seen that little epigram floating around the net. If you code, you “get it.” If you don’t code, it’s not hard to understand: whatever intrinsic beauty is latent in a piece of code should be found.

As with poetry, finding that latent beauty is the hard part.

In my Ongoing Quest for World Domination of WordPress recipe formatting, I have plenty of occasion to look for latent beauty.

Lately, that beauty has been lurking in PHP form handling. Specifically, hRecipe provides a spiffy Javascript popup box allowing the WordPress recipe maven a friendly way to enter their recipes for publication on blog posts and pages. This popup box is called a “thickbox” and it’s a component of the nearly ubiquitous jQuery library which ships with every installation of WordPress.

After entering a recipe, it’s easy to send the formatted information directly to a blog post. This is how it’s been done so far, and how the hReview plugin (upon which hRecipe) is based works.

But that’s not good enough. All this recipe data should be in the WordPress database.

PHP vs. Javascript form handling

In general, handling HTML forms is well-understood technology. But the specific details vary enough from platform-to-platform that it’s worth learning new techniques. What follows is a few notes on how to implement form handling using the WordPress Ajax capability.

First the motivation: because of the way thickbox is implemented as a child window of the blog post editor, code for handling the form can be written in the thickbox handler or the class that invokes the thickbox handler.

Which leaves the database out of scope.

Even if you derived a class from the database handler itself, you may still be out of scope with respect to the instance of the current hRecipe class.

Conversely, there’s no easy and elegant way to pass the database handling code into the thickbox handler. The database code is all PHP running on the server, and the thickbox code is mostly Javascript, running in your browser. An ugly problem to be sure.

Succinctly, we want the form data processed such the database is in scope, but the processing is encapsulated within it’s own file.

Enter WordPress.

WordPress Ajax form handling

It turns out that WordPress has an Ajax broker (for lack of a better word) which will pass the form data from the Javascript code to the form handler running on the server. Here’s what that looks like:

1
2
3
4
5
6
7
8
9

$(document).ready(function() {
	$("#hrecipe_form").submit(function() {
		var ajaxurl = "<?php echo admin_url('admin-ajax.php');?>";
		var data = jQuery(this).serialize();
		jQuery.post(ajaxurl, data, function(response) {
    	});
		return false;
	});
});

Simple, right?

Ok, it’s a little more complicated than specifying the action attribute in your form, but I guarantee the tradeoff for power is worth the slight added complexity. Since you’re using Javascript anyway (thickbox), it really isn’t a problem.

Taking it from the top…

• Line 1: The usual JQuery invocation.
• Line 2: The id attribute of your form. This should be self-explanatory. If you don’t know what id attributes are, you have some homework to do. In this case, we’re passing an anonymous function into .submit. The usual JQuery way.
• Line 3: It’s absolutely key to get the admin-ajax.php file included. The methods you need for hooking the WordPress Ajax interface up are in that file. If you implement this, and it doesn’t work, checking for this file should be your first step in debugging.
• Line 4: This is all of your form data. Every single element. Spiffy!
• Line 5: The Ajax call. The third argument captures whatever you return from your handler. In this case, I’m choosing not to do anything with the returned data. You could (should) put a Javascript alert box here when you first implement; it’s fun watching this code execute.

And that’s it for the Javascript part.

Now you need to ensure your form has the correct id attribute, and a field for triggering the action handler.

Form data for Ajax

Simple: <form method="post" id="hrecipe_form" action="" >.

You probably don’t need the method attribute, that’s taken care of using Javascript.

Next, add a hidden input field named “action,” like this:
<input type="hidden" name="action" value="thickbox_form" />

Simple, right?

Let’s get the handler installed.

Handling the request with PHP

The cool part is that the PHP side of WordPress won’t know the difference. As far as it’s concerned, it’s $_GET and $_POST as usual. Here’s how to do it.
add_action("wp_ajax_thickbox_form", array ($recipe, 'thickbox_form_handler'));

The key to this action is understanding the wp_ajax tag, which registers the handler given as the second argument to add_action. Nothing new here; even if wp_ajax is new to you, you have seen the pattern before.

Note also that I’m using a class-based design for hRecipe, thus I have to pass add_action the hRecipe class instance ($recipe) where the handler is located. Otherwise, thickbox_form_handler will be out of scope.

The handler code:

103
104
105

function thickbox_form_handler() {
   include ('view/recipe_form.php');
}

The form data is all nicely tucked away into recipe_form.php, which connects to the WordPress database and handles all the messy chores of extracting the values of the form fields.

We’ve solved the problem: recipe_form.php is now in scope, but all it’s ugliness is “under the hood.”

Implementing Ajax in WordPress

If you have arrived here from other pages showing you how to do the same thing, you have probably read that all of this needs to be in the same file. Or perhaps some other limitation must be respected. With all due respect to the authors of other articles, such limitations are artifacts of the main requirement:

Everything must be in scope.

If you have every call and function in scope, it’s as simple as shown here. If this code doesn’t work for you, checking scope should be your first step in debugging. Here’s a checklist:

1. Ensure your form id matches the Javascript id you’re invoking .submit for.
2. Check to see that you have an input field named “action” with an appropriate value.
3. Make sure your add_action is using the same value appended to the wp_ajax tag as you set for your input field with name="action".
4. Ensure the admin-ajax.php is in your path. This is critical, none of this works without the handlers in that file.

Questions welcome, I’ll do my best to answer.

Post from: Website In A Weekend

Thickbox Ajax Form Handling in WordPress

(Reading time: 6 – 9 minutes)

WordPress can be considered a dynamic web application. What that means depends a little bit on who you talk to, and what you are using WordPress to achieve. (Look for related reading at the end of this article.)

What “dynamic web application” means for this article is a web page resulting from an unholy fusion of HTML, CSS, PHP and MySQL. And Javascript. Can’t forget Javascript.

5 different langguages. That’s crazy. Seriously, it’s crazy. Back in the dinosaur days (1990s), it was plenty to master one programming language per application.* You could even spend most of a career just in one or a few languages.

Anyway, if you’re still with me, you probably know a little bit about HTML and CSS by now. It turns out that for WordPress, you don’t need a lot of Javascript or MySQL for tweaking themes and plugins. Helpful, they are, but not necessary.

What you need now is a little PHP, so that’s where we’re going next.

“Why should I care about PHP?”

You continue, despite your better judgement, to read Website In A Weekend on a regular basis. Which means by hook or by crook, you’re at least partly in the do-it-yourself camp. You may not want to camp in DIY, but there you are. So you should care because if you don’t, you’re gonna mess something up sooner or later.

And it won’t be pleasant.

So that’s why you should care.

WTH is PHP, anyway?

PHP is a recursive acronym, meaning PHP Hypertext Preprocessor. For more on recursive acronyms, I suggest Wikipedia.

PHP is a programming language that slides in and around HTML to do a lot of tedious dirty work so you don’t have to. PHP code intermingled with HTML often appears ugly. In programming, something appearing ugly often is ugly. One of the weaknesses of PHP is that some of this ugliness can’t be helped. It was designed in.

PHP is a module that plugs into your web server that translates (preprocesses) PHP files into HTML (hypertext). The PHP interpreter is different than the web server. You can run a web server without PHP, but you can’t serve PHP over the web without a web server.

PHP is all that and more!

PHP Hypertext Preprocessor

From the above, PHP the programming language is what’s of most concern to you, right here and right now. The language is what you’re going to see when you’re poking around in WordPress. Here’s the basic concepts.

• PHP language syntax. PHP syntax derives from the family of C like languages. If you know already know C, you will pick up PHP pretty quick (but you probably already know that). If you don’t know C, no worries, it’s not that important. The point is, there’s history and meaning behind PHP syntax. It didn’t sprout from someone’s forehead, ex nihilo.

  Current versions of PHP are “object-oriented.” But really, PHP is procedural, object-oriented capability was bolted on, not designed in.

• Understand variable scope. Understanding variable scope is critical. If you have programmed before, you may need to unlearn some assumptions, like global variables not acting how you think they should. Variable scope in PHP still trips me up. If you have little programming experience, you won’t have to unlearn anything. That’s a good thing.
• PHP paths are critical. When you write an application or even tweak a plugin for WordPress, you need to know how WordPress and PHP find things like files and images you want to deliver to your readers. WordPress does a pretty good job of standardizing paths. Spend the time to figure that out.
• Understand single and double quoting. Single and double quoting in PHP behave slightly differently, but these small differences are important. Sometimes single and double quotes can be used the same way, other times, they can’t be used the same way. Most people develop their own scheme for when and how to use each type of quoting.
• WordPress and PHP APIs are different. A collection (library) of functions is called an Application Programming Interface (API). When you’re just starting out, it’s critical to figure out the difference between functions that are part of PHP and functions that are part of WordPress.

Here’s four functions you absolutely must know for effectively programming in WordPress. I suggest either memorizing these functions (smart) or have their definitions on speed dial (not as good, but it’s how I do it).

• dirname: returns the directory path to the file given as argument. This is the directory on the server, not the URL path. PHP function.
• basename: returns just the file name for a given path. Dual to dirname. PHP function.
• add_action: adds a specified function to a WordPress action. Example: if you want to print your own meta tags into your web page head element, create a function and use add_action to tell WordPress where to print the output of your function. See Line 20 in Anchor Text Plugin.WordPress function.
• add_filter: modifies text before printing that text to a WordPress page. For example, WordPress uses a filter to automatically add paragraph breaks to your blog posts. (Which some people really hate, but what can you do?). WordPress function.

By the way, I just got a nice email from Tim Lumen, who operates Groovera.com. Curiously, I just happen to be listening to Low Mercury right at this very moment. Low Mercury is super-chill, great for those days when Trance, Techno and Breakbeats is just a little too much. If you’re in a kick back writing mode, check ‘em out. Groovera is 100% listener supported, and worth it. If you like what you hear, donate or subscribe. If you’re in budget mode, give Tim a little link love. Or both!

Related reading

Here’s some articles you might like from 2009:

• Static Versus Dynamic Websites – Operational, Informational, Interactional. The meaning of static and dynamic websites depends on the context of your discussion, and you need to know these 3 definitions so you won’t get ripped off.
• Dynamic Content Generation – How WordPress is Like a Sushi Restaurant. Understanding how WordPress works is easy: it works just like a sushi restaurant. Read it and see, I’m sure you’ll agree.

Post from: Website In A Weekend

DIY WordPress: What You Need to Know About PHP if You Don’t Yet Know a Damn Thing

(Reading time: 3 – 5 minutes)

Do I have your attention?

Good.

I’ve mentioned this before, anchor text matters.

If linking is the door to higher search results, anchor text is the key that unlocks that door.

I know this for several reasons. I rank pretty well for a couple of long tail terms. I also watch as many of those free SEO videos as I can from people like Brad Callen, Andy Jenkins and the like. You know, the Stompernet guys and big time internet marketers. They give away a lot of good stuff for free. And if they’re a-givin’ I’m a-takin’.

Using anchor text naturally, such that it doesn’t break the flow of your prose (and sound all weird) is a bit of an art.

But first you have to get the anchor text (if you are linking), or find a way to provide it people who want to link.

1. Ask for anchor text

If you aren’t sure what anchor text to use when linking to an article, ask the article’s author.

If you’re an author, provide anchor text information to people who want to link to you.

If you find yourself being linked to with unsuitable anchor text, here’s what Erica Douglass does:

I send them an email thanking them for linking to my blog, and then say “Instead of erica.biz as your link text, can you put ‘starting your own business‘?” (I’ll also often throw in an entire sentence with the <a href=""></a> etc. already in there.

Sometimes it works. Sometimes it doesn’t. I’ve gotten most of my good rankings from guest posting and putting the SEO’d text in my blurb. I show how to do this in Guest Post Secrets.

2. Using SEO keyword metadata

STOP.

I’m not going to write what you think I’m going to write about keywords. Instead, I’m going to make an offer. First:

Use your meta keywords to specify your preferred anchor text.

That way, when I want to link to you, I’ll know what you want to rank for. I just look at the source for your page, extract what I need. Easy.

Here’s the offer: if you want to link to one of my articles, and you find that it (the article) has no keyword metadata (there are plenty, too many), email me, I’ll add keywords you can use for anchor text, and send you a free copy of Blog Post Engineering when I get the trackback from your link.

3. Let’s plug it in

If the notion of specifying keyword metadata is simply too repellent, I offer a tiny plugin for your amusement.

Since it’s Tuesday, we can go technical.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/*
 * Plugin name: Fast Anchor Text
 * Plugin URI: http://website-in-a-weekend.net/seo-anchor-text
 * Description: Set desired anchor text as custom field.
 * Version: 0.1
 * Author: Dave Doolin
 * Author URI: http://website-in-a-weekend.net/
 */
 
function anchor_text_meta() {
 
   if (is_home()) return;
 
   global $post;
   $anchor = get_post_meta($post->ID, 'anchortext', true);   
   if ($anchor) {
      echo "<meta name=\"anchortext\" content=\"$anchor\" />\n";  
   }
}
add_action('wp_head', 'anchor_text_meta');
?>

If you don’t like plugins, and you prefer messing around with functions.php (or custom_functions.php in Thesis theme), you can just paste the functional parts into those files.

Here’s a screenshot of how to use it:

Key in blue box, anchor text in red box

Here’s the plugin file: anchor.zip.

Blog Maintenance Challenge

Believe it or not, I am slowly yet surely adding material to the Blog Maintenance Challenge. Dealing with keywords and anchors is definitely on the curriculum.

I’ll have some videos over there too.

Post from: Website In A Weekend

SEO Anchor Text SEO Anchor Text SEO Anchor Text SEO Anchor Text

(Reading time: 11 – 18 minutes)

We hear it all the time: speed of implementation. Execute fast. Fail fast, even. But all of this sterling advice assumes we know how to execute.

When you’re starting from scratch, with big ambitions, you have a problem: you can’t execute on any of your ideas.

There is a solution…

…when you can’t do what you want, do what you can.

For example, I want to build the Next Big Thing, but my network programming skills aren’t up to scratch. I could choose to be in a bind and do nothing, or I could choose to build the necessary skill set.

It’s building the skill set for me.

Note: in the software business, and especially within the startup ecosystem, business acumen and programming wizardry are not assumed to be mutually exclusive. In fact, a lot of the real rock stars in Silicon Valley are better than average at both.

As it turns out, I was chatting with Jenn Jinright about this very problem, this skill building problem. She’s relatively new, and has just started to realize the stupendiosity of the amount of work involved in building any business, much less a business based on the internet subject to global labor pressure.

I told her I was in the same boat, in a different area, and that I would finish up an article to demonstrate how I do it.

This is that article.

Design top down, build bottom up

The strategy is to fix a general picture of what you’re aiming for, then figure out what the pieces of that puzzle look like. You won’t see it clearly. That’s ok. This is top down design.

Once you have a general notion of what the pieces look like, build those pieces, which is easier said than done. This is building from the bottom up.

You may (will) end up building things you don’t need. That’s how it is. The things you do build may not (won’t) work the way you think. But if you keep after it, you will build yourself a toolchest, an arsenal of weaponry which you can haul out to solve tactical problems as they come up.

Because this is Technical Tuesday and because I’m building a suite of WordPress plugins for various reasons, I’m going to use WordPress plugin development as my motivating example. I’d be delighted to write another article on this topic using, say, an AWeber list segmentation to deal with a technical upgrade to an information product (Thesis theme customization). Just let me know.

Note: If you’re a DIY’er (and a lot of you are), you don’t need to understand exactly what’s going on in the code example below. But if you follow along, you will learn a great technique for teaching yourself.

6 reasons for Technical Tuesday

Most of my articles on Website In A Weekend solve several problems at once, but just to be clear, here’s my motivation for these “technical tuesdays”:

1. Building out a plugin toolset for fast execution. With a little care, plugins can be designed to snap together like Legos. I leveraged a couple of existing plugins this way to build the Statustar demo at the last Bay Area Startup Weekend.
2. Search engine bait for WordPress widget development, on a topic not well covered. This means I didn’t find any code that worked the way I wanted, out-of-the-box, so I write my own code and article.
3. My content strategy reserves one day a week for deep tech, the hard stuff, The Hero Stuff. Long time readers (bofem) know this.
4. I write to learn. I teach this stuff to myself. You can learn right along with me, and what I do here is an excellent way to teach yourself.
5. Deliberate practice forces learning. It turns out the difference between “good” and “great” is doing the work that matters. Building technical skill very fast matters to me. Once a week I do that work.
6. Last, and far from least, this is part of the base code I used to create the Blog Post Engineering Affiliate Widget plugin. No messy text boxes in my sidebar. More about that at the end, including how you can get the plugin yourself.

This still begs the question…

Why use plugins at all, if they’re so slow?

Here’s the deal: instead of fooling around with functions.php or custom_functions.php, write a little plugin instead. Theme files aren’t portable, plugins are. If you break your theme, that’s a major malfunction. Breaking an accessory plugin, no big deal, just delete it.

Before we go any further, I’m just sure someone is thinking “Too many plugins makes WordPress slow!!!”

Yes and no.

How WordPress plugins affect loading speed depends on not just the extra HTTP requests, but also on:

1. What those plugins are doing, that is, what functions they use in WordPress.
2. How many files are packaged with the plugin.
3. How many lines of code in the plugin are executed.

It turns out it’s pretty hard to predict performance in advance, which is why we have (surprise) performance testing. I’m not aware of anyone who has published performance results accounting for any of these plugin dependencies. Hopefully, somebody smart will latch on to this notion and do some quantitative testing. Or pay me to do some quantitative testing, that would be fine too.

We’re going to look at code now. If this is a problem, jump the code.

WordPress Widget Demo Plugin

Here’s the whole listing, it’s pretty short, you can cut and paste it if you want but I would recommend typing it all in by hand. You will learn it better that way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

<?php
/*
 * Plugin name: Demo Plugin Widget
 * Plugin URI: http://website-in-a-weekend.net/plugins/demo-plugins/
 * Description: Demonstrating how to add a WordPress widget with a plugin.
 * Version: 0.1
 * Author: Dave Doolin
 * Author URI: http://website-in-a-weekend.net/
 */
 
if (!class_exists("demo_plugin_widget")) {
 
	class demo_plugin_widget extends WP_Widget {
 
		function demo_plugin_widget() {
			$widget_ops = array('classname' => 'demo_plugin_widget', 'description' => 'A Widget Demo' );
			$this->WP_Widget('demo_widget', 'Plugin Demo Widget', $widget_ops);
		}
 
		/* This is the code that gets displayed on the UI side,
		 * what readers see.
		 */
		function widget($args, $instance) {
			extract($args, EXTR_SKIP);
			echo $before_widget;
			$title = empty($instance['title']) ? '&nbsp;' : apply_filters('widget_title', $instance['title']);
 
			if (!empty($title)) { 
				echo $before_title . $title . $after_title; 
			}
			?>
 
<ul>
	<li>Some text here.</li>
	<li>More text.</li>
</ul>
 
<?php
            echo $after_widget;
		}
 
		function update($new_instance, $old_instance) {
			$instance = $old_instance;
			$instance['title'] = strip_tags($new_instance['title']);
			return $instance;
		}
 
		/* Back end, the interface shown in Appearance -> Widgets
		 * administration interface.
		 */
		function form($instance) {
			$instance = wp_parse_args( (array) $instance, array( 'title' => '', 'entry_title' => '', 'comments_title' => '' ) );
			$title = strip_tags($instance['title']);
			?>
 
<p>
<label for="<?php echo $this->get_field_id('title'); ?>">Title: 
    <input
	   class="widefat" id="<?php echo $this->get_field_id('title'); ?>"
	   name="<?php echo $this->get_field_name('title'); ?>" type="text"
	   value="<?php echo attribute_escape($title); ?>" 
	/>
</label>
</p>
 
			<?php
		}			
	}
 
	function demo_widget_init() {
		register_widget('demo_plugin_widget');
	}
	add_action('widgets_init', 'demo_widget_init');
 
}
 
$wpdpd = new demo_plugin_widget();
 
?>

A few dozen lines of code gets a simple widget. This is very cool, seriously cool.

Break it down!

Now we’re going to explain how the widget code works by breaking it down piecewise. If this is a problem, jump the code explanation.

Let the learning begin: I’m using Safari browser on my Macbook, and I’ll be using Google to look up a few references I’m not sure about. We’ll figure out what is going on, and why.

11
12
13
14
15
16
17
18

if (!class_exists("demo_plugin_widget")) {
 
	class demo_plugin_widget extends WP_Widget {
 
		function demo_plugin_widget() {
			$widget_ops = array('classname' => 'demo_plugin_widget', 'description' => 'A Widget Demo' );
			$this->WP_Widget('demo_widget', 'Plugin Demo Widget', $widget_ops);
		}

The easy stuff:

• Line 11: ensure there isn’t any conflict with existing code. This may seem faintly ridiculous, and in production (shipping) code, maybe it is (maybe it isn’t… I’ve had collisions with my recipe plugin in the past). When you’re developing, these kinds of conflicts can occur as a side effect from using advanced development techniques such as “cut-n-paste.”
• Line 13 opens the class definition. We’ll close the class definition on line 75.
• Line 16: The widget needs to know about itself, and it needs to be able to tell you about itself.
• Line 17: Set the WP_Widget base class parameters 1. the ID used for targeting, css, etc., 2. descriptive text to display in the title bar in the Widgets interface, and 3. our class array.

Standard stuff, really, once you see it a few times.

Next, we need to override the three required functions of WP_Widget: widget, update and form.

23
24
25
26

		function widget($args, $instance) {
			extract($args, EXTR_SKIP);
			echo $before_widget;
			$title = empty($instance['title']) ? ' ' : apply_filters('widget_title', $instance['title']);

• Line 23: widget is a required function, you have to override it.
• Line 24: grab the variables we need, but (EXTR_SKIP) don’t overwrite any variable we already have.
• Line 25: $before_widget is a variable obtained from the sidebar. It might contain some HTML markup controlling the layout of the widget in the sidebar. For example, check out this WordPress custom sidebar example. This is really interesting code design, the layout is manually controlled within the widget. I would not have done it this way (too easy to forget), and I’m curious what the design tradeoffs are.
• Line 26: If the title variable is empty, give it a single space (&nbsp) to help the layout render when it’s displayed. Else set the title.

Moving right along…

28
29
30
31
32
33
34
35
36
37
38
39
40

			if (!empty($title)) { 
				echo $before_title . $title . $after_title; 
			}
			?>
 
<ul>
	<li>Some text here.</li>
	<li>More text.</li>
</ul>
 
<?php
            echo $after_widget;
		}

It’s getting easier, sort of…

• Line 28: Not a big fan of double negatives. I’m not the brightest bulb in the building, so I always have to pause for a moment with “not empty.” I’d prefer something like “full.” Heresy.
• Line 31: We need to jump out of PHP and write some HTML directly.
• Lines 33-36: Dummy text, instructional purposes only.
• Line 38: Get back into PHP, more work to do.

42
43
44
45
46

		function update($new_instance, $old_instance) {
			$instance = $old_instance;
			$instance['title'] = strip_tags($new_instance['title']);
			return $instance;
		}

This is easy, the update function handles everything that happens when you set the values in the widget when your in the Appearance -> Widgets administration area.

Form is also easy, it lays out the HTML you use in the administration area:

51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

		function form($instance) {
			$instance = wp_parse_args( (array) $instance, array( 'title' => '' ));
			$title = strip_tags($instance['title']);
			?>
 
<p>
<label for="<?php echo $this->get_field_id('title'); ?>">Title: 
    <input
	   class="widefat" id="<?php echo $this->get_field_id('title'); ?>"
	   name="<?php echo $this->get_field_name('title'); ?>" type="text"
	   value="<?php echo attribute_escape($title); ?>" 
	/>
</label>
</p>
 
			<?php
		}			
	}

Long snippet here. No matter, we’ll take it a line at a time.

• Line 52: $instance is where the current data lives. If we change that data, the changes are handled in update.
• Line 53: Strip tags gets rid of HTML, Javascript and other potentially nasty artifacts, increasing the security of your code.
• Lines 56-64: This is the HTML code shown in the actual widget itself. In this case, “Title:” labels an input element which sets title variable.

Not so bad.

70
71
72
73
74
75
76
77

	function demo_widget_init() {
		register_widget('demo_plugin_widget');
	}
	add_action('widgets_init', 'demo_widget_init');
 
}
 
$wpdpd = new demo_plugin_widget();

Almost done:

• Line 73 adds our custom widget to the list of widgets WordPress already knows about, using the function defined in line 70 as the relevant callback. You probably already know this, I’m just writing it out to be complete.
• Line 75 closes the class definition.
• Line 77 is important, it initializes an instant of the widget. If you used this widget in your own plugin, you might want to initialize it somewhere else, perhaps in the main plugin class.

And that’s the end of that.

Get a grip on this simple code, and you will be able to snap a widget into your own code very easily. Not quite cut and paste, but very close.

Using the widget plugin

Having developed this widget component for Startup Weekend, it was only natural to snap it into the the Blog Post Engineering Affiliate plugin.

It’s really cool. You just download the bpe.zip file to your desktop, upload it using the WordPress plugin installation panel, and configure your sidebar with your affiliate link. No more messing around with text widgets and URLs.

Having the widget code “in my back pocket” let me build the affiliate plugin really fast. It took about 45 minutes to implement the widget, and part of that was an error on my part. Using it will save you a LOT of time.

So, are plugins slow or not?

As mentioned in my estimated reading time plugin article, having more plugins goes counter to received opinion in Blogistan (i.e., more plugins is bad.)

Recall I said something about taking anyone’s opinion on this with a grain of salt. Because until you measure performance, it is simply opinion. I guarantee 99% of the people that spout this nonsense haven’t ever fired up YSlow and checked to see which plugin is the slowest. Last I checked, it was Tweetmeme here on Website In A Weekend. It’s going to be different on your WordPress installation.

Here’s how the expert opinion works: if you have very little experience, and you ask someone with a lot of experience… they’re going to tell you something you can understand and act on: “Remove your plugins to speed up WordPress.” (If they don’t tell you to Read The Effen Manual instead.)

Easy. Useless. I like my plugins. All of them.

They aren’t likely to tell you “Install Firebug and YSlow, then run a few performance tests to average plugin load time to see which plugins are slowing you down.” (Actually, they might if you paid them real money.)

Don’t take my word for it. Think for yourself. Test it for yourself.

Post from: Website In A Weekend

WordPress Widget Plugin – Super easy customization (Tuesday means technical)

(Reading time: 6 – 10 minutes)

Tim Ferriss has a lot to say about blogging. In fact, he can talk for an hour straight about it, as I found out last year at WordCamp 2009 in San Francisco.

I learned about Tim’s strategy, and he gave us a few of his tactics and techniques. One of Tim’s really interesting tactics for treating readers with respect was providing an estimate of how much time it might take them to read an article. For those unacquainted with Tim’s writing, sometimes it’s long, 3000 words or more long.

These days, I’m starting to see a lot more blogs with an estimated reading time displayed. Back last June, a whole year ago, there weren’t very many. There are surely several ways to implement an estimated reading time; being WordPress, there is a plugin.

And so, once again, a Technical Tuesday, where we break down one of Website In A Weekend’s most popular plugins: Estimated Reading Time.

But…

Before we get started, (IMPORTANT →) You Do Not Need To Read The Code To Get The Point.

You do, however, need to scan over the code. Take it in as a “block.” Notice it’s not very long.

The Estimated Reading Time plugin

The Estimated Reading Time plugin is pretty short, just a couple of dozen lines. If this hurts your eyeballs, by all means jump right over the code.

Otherwise, check it out in all it’s PHP glory:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

if (!function_exists('est_read_time')):
function est_read_time( $return = false) {
	$wordcount = round(str_word_count(get_the_content()), -2);
	$minutes_fast = ceil($wordcount / 250);
	$minutes_slow = ceil($wordcount / 150);
 
	if ($wordcount <= 150) {
		$output = __("Reading time: < 1 minute");
	} else {
		$output = sprintf(__("Reading time: %s - %s minutes"), $minutes_fast, $minutes_slow);
	}
	if ($return) {
		return '<p class="estread">' . $output . '</p>';
	} else {
		echo '<p class="estread">' . $output . '</p>';
	}
}
endif;
 
if (!function_exists('est_the_content')):
function est_the_content( $orig ) {
	// Prepend the reading time to the post content
	return est_read_time(true) . "\n\n" . $orig;
}
endif;
 
if (function_exists('add_filter')):
   // Set this to priority 9 so it's called before wptextuarize/wpautop/etc
   add_filter('the_content', 'est_the_content', 9); 
endif;

That’s not bad, 30 lines of pure D elegance.

Just for fun, let’s break it down… (no? Go for the goodies?)

The break down

1
2

if (!function_exists('est_read_time')):
function est_read_time( $return = false) {

Let’s check to see if this function for estimated reading time already exists in WordPress, perhaps in another plugin. If so, skip over it.

If not, do some computation.

3
4
5

	$wordcount = round(str_word_count(get_the_content()), -2);
	$minutes_fast = ceil($wordcount / 250);
	$minutes_slow = ceil($wordcount / 150);

These simple computations are the heart of the plugin, and if you’ve noticed the “2-2″ bug, this computation is where that occurs. Here’s how it works:

1. After counting the words with str_word_count, the PHP round function with argument -2 multiplies the result by 100.
2. Then, dividing by 250 and 150, respectively, gives a range, and the ceil function returns the next highest integer from the division.

Not hard, right?

Let’s figure out what to show the reader:

7
8
9
10
11

	if ($wordcount <= 150) {
		$output = __("Reading time: < 1 minute");
	} else {
		$output = sprintf(__("Reading time: %s - %s minutes"), $minutes_fast, $minutes_slow);
	}

Here’s the other half of the “2-2 minutes” bug. Fixing it won’t be hard, will just take a little time examining how round and ceil work, or kludging in a fix by checking to see if $minutes_fast equals $minutes_slow.

Once we know what we want to display…

12
13
14
15
16
17
18

	if ($return) {
		return '<p class="estread">' . $output . '</p>';
	} else {
		echo '<p class="estread">' . $output . '</p>';
	}
}
endif;

This means that when the function is called from some other part of WordPress, it will return a string to wherever it’s wanted. Else, it prints the estimated reading time string straight to your screen.

Note that “estread” class is added automatically. This CSS currently has to be added manually to your style sheet. (custom.css if you use Thesis) In the near future, the plugin will have it’s own style sheet.

Here’s where we set up for the hook…

12
13
14
15
16
17

if (!function_exists('est_the_content')):
function est_the_content( $orig ) {
	// Prepend the reading time to the post content
	return est_read_time(true) . "\n\n" . $orig;
}
endif;

Calling est_reading_time with true. We want the string back because…

12
13
14
15

if (function_exists('add_filter')):
   // Set this to priority 9 so it's called before wptextuarize/wpautop/etc
   add_filter('the_content', 'est_the_content', 9); 
endif;

…we’re adding the string with the reading time directly to the content.

Easy, right?

“But why,” you might ask, “should I bother myself with these tedious details?”

That’s an excellent question, and you, Website In A Weekend reader, deserve an answer.

Ripping back the (plugin) veil

Long time readers (bofem) recall that I’ve published similar code and plugin breakdowns in the past. Just last week, we tore into the SEO Slugs plugin. A month or two past, we had the world’s shortest plugin.

Stay with me here…

If you think I might demonstrating something (more than just showing off even though I am sort of showing off, at least a little bit), you might be right.

I’m setting the stage for a nice big twist of Blogistan’s collective nose. Remember this old saw “Too many plugins is bad and makes your blog slow.”?

Who says so? Why do they say it? How do they know, who granted their authority and why should I believe what J. Random Blogger says about plugins, loading speed, or any other damn thing about blogging?

More important, why should you believe it?

Rule of thumb: If it didn’t come directly from a WordPress core developer, or plugin author with years of experience, or a professional webmaster, take it with a grain of salt. Maybe a big lump of salt.

Worse yet, even if you get your information straight from the horse’s mouth (so to speak), it may be suspect. I’ll go deeper into “why” in the future.

Let’s wrap this up.

Do you need estimated reading time?

This plugin is pretty small, and it’s not going to put much of a load on your WordPress installation (almost none, really), so using it won’t cost much more than installing it. But before you “just install it,” note that my primary reason for using it is because the length of my articles varies wildly between roughly 1 minute reading time to over 20 minutes reading time.

Further, the topics that I write on vary between highly accessible to highly technical.

Because of this wide range of length and topical difficulty in my blog posts, letting the reader know what’s in store just seems polite. And it works. Readers have commented that having some notion of their commitment ahead of time is very helpful.

Seeing a short post (1 – 2 minutes) may bring a reader in who might otherwise pass. Seeing a long post, a reader might choose to go get a cup of coffee before starting to read (I say this because this is what I’ve been told by a reader in the past.)

Displaying an estimated reading may or may not be useful for you. If you write articles of uniform length, your readers always know what to expect, reading time is superfluous. Likewise, if your articles are fairly well-focused and written in a uniform voice, your articles can be any length, from 100 to 3000 words, and your readers will be there for you regardless of article length.

Also. Remember why I do this stuff: Talent is Overrated, I write to learn, and deliberate practice is the only sure path to mastery.

Post from: Website In A Weekend

Estimated Reading Time Plugin : Sharpening the stick (technical tuesday)

(Reading time: 12 – 19 minutes)

I was talking to Julie Roads the other day about post slugs, and it occurred to me I haven’t written on post slugs for quite a while. In fact, while it’s on my mind, go visit Julie and get yourself some refresh and reload.

Now that you’ve wiped your slate clean, let’s reload it with Stuff You Need To Know. Like post slugs.

Life without paper - Interactive Ancient History from Historic Connections

Although I discuss post slugs in Blog Post Engineering in some detail, much of what follows is new material. Some of this may go into the next release of Blog Post Engineering as well.

It turns out there exists a spiffy little plugin called “SEO Slugs,” which will:

• Help you create shorter, keyword-rich slugs using your article title.
• Will not automatically change your title, so you have ultimate control (as it should be).

The SEO Slugs plugin is very old and hasn’t been updated in years. I usually recommend NOT using older plugins (for good reason), but as you will see, there isn’t anything out of date in SEO Slugs. (That’s either a testament to the strength of WordPress design, or an indictment to it’s lack of innovation. I could argue both sides. I’ll spare us all.)

This plugin is cool, because you don’t really have to do anything, it just works quietly in the background:

SEO Slugs plugin works automatically to remove stopwords

Since it’s (Technical) Tuesday, it’s a perfect opportunity to get all hard core about it too. So I’m going to break this stepwise for you. You will see how I attack plugin problems, and how this particular plugin works to your benefit.

SEO Slugs plugin

First, if code makes your eyes glaze over, just skip right over to where I break this plugin down one piece at a time.

Since SEO Slugs is really short, I’m listing out all 43 lines right here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

<?php
/*
Plugin Name: SEO Slugs
Plugin URI: http://www.vretoolbar.com/news/seo-slugs-wordpress-plugin
Description: Removes common words like 'a', 'the', 'in' from post slugs to improve SEO.
Version: 1.0
Author: Andrei Mikrukov
Author URI: http://www.vretoolbar.com
*/
 
/*
Copyright Andrei Mikrukov 2007
 
Licensed under the terms of the GPL version 2, see:
http://www.gnu.org/licenses/gpl.txt
 
Provided without warranty, inluding any implied warrant of merchantability or fitness for purpose.
*/
 
add_filter('name_save_pre', 'seo_slugs', 0);
 
function seo_slugs($slug) {
 
    // We don't want to change an existing slug
    if ($slug) return $slug;
 
    global $wpdb;
    $seo_slug = strtolower(stripslashes($_POST['post_title']));
 
    $seo_slug = preg_replace('/&.+?;/', '', $seo_slug); // kill HTML entities
    // kill anything that is not a letter, digit, space or apostrophe
    $seo_slug = preg_replace ("/[^a-zA-Z0-9 \']/", "", $seo_slug);
    // Turn it to an array and strip common words by comparing against c.w. array
    $seo_slug_array = array_diff (split(" ", $seo_slug), seo_slugs_stop_words());
    // Turn the sanitized array into a string
    $seo_slug = join("-", $seo_slug_array);
 
    return $seo_slug;
}
 
function seo_slugs_stop_words () {
    return array ("a", "able", "about", "above", "abroad", "according", "accordingly", "across", "actually", "adj", "after", "afterwards", "again", "against", "ago", "ahead", "ain't", "all", "allow", "allows", "almost", "alone", "along", "alongside", "already", "also", "although", "always", "am", "amid", "amidst", "among", "amongst", "an", "and", "another", "any", "anybody", "anyhow", "anyone", "anything", "anyway", "anyways", "anywhere", "apart", "appear", "appreciate", "appropriate", "are", "aren't", "around", "as", "a's", "aside", "ask", "asking", "associated", "at", "available", "away", "awfully", "b", "back", "backward", "backwards", "be", "became", "because", "become", "becomes", "becoming", "been", "before", "beforehand", "begin", "behind", "being", "believe", "below", "beside", "besides", "best", "better", "between", "beyond", "both", "brief", "but", "by", "c", "came", "can", "cannot", "cant", "can't", "caption", "cause", "causes", "certain", "certainly", "changes", "clearly", "c'mon", "co", "co.", "com", "come", "comes", "concerning", "consequently", "consider", "considering", "contain", "containing", "contains", "corresponding", "could", "couldn't", "course", "c's", "currently", "d", "dare", "daren't", "definitely", "described", "despite", "did", "didn't", "different", "directly", "do", "does", "doesn't", "doing", "done", "don't", "down", "downwards", "during", "e", "each", "edu", "eg", "eight", "eighty", "either", "else", "elsewhere", "end", "ending", "enough", "entirely", "especially", "et", "etc", "even", "ever", "evermore", "every", "everybody", "everyone", "everything", "everywhere", "ex", "exactly", "example", "except", "f", "fairly", "far", "farther", "few", "fewer", "fifth", "first", "five", "followed", "following", "follows", "for", "forever", "former", "formerly", "forth", "forward", "found", "four", "from", "further", "furthermore", "g", "get", "gets", "getting", "given", "gives", "go", "goes", "going", "gone", "got", "gotten", "greetings", "h", "had", "hadn't", "half", "happens", "hardly", "has", "hasn't", "have", "haven't", "having", "he", "he'd", "he'll", "hello", "help", "hence", "her", "here", "hereafter", "hereby", "herein", "here's", "hereupon", "hers", "herself", "he's", "hi", "him", "himself", "his", "hither", "hopefully", "how", "howbeit", "however", "hundred", "i", "i'd", "ie", "if", "ignored", "i'll", "i'm", "immediate", "in", "inasmuch", "inc", "inc.", "indeed", "indicate", "indicated", "indicates", "inner", "inside", "insofar", "instead", "into", "inward", "is", "isn't", "it", "it'd", "it'll", "its", "it's", "itself", "i've", "j", "just", "k", "keep", "keeps", "kept", "know", "known", "knows", "l", "last", "lately", "later", "latter", "latterly", "least", "less", "lest", "let", "let's", "like", "liked", "likely", "likewise", "little", "look", "looking", "looks", "low", "lower", "ltd", "m", "made", "mainly", "make", "makes", "many", "may", "maybe", "mayn't", "me", "mean", "meantime", "meanwhile", "merely", "might", "mightn't", "mine", "minus", "miss", "more", "moreover", "most", "mostly", "mr", "mrs", "much", "must", "mustn't", "my", "myself", "n", "name", "namely", "nd", "near", "nearly", "necessary", "need", "needn't", "needs", "neither", "never", "neverf", "neverless", "nevertheless", "new", "next", "nine", "ninety", "no", "nobody", "non", "none", "nonetheless", "noone", "no-one", "nor", "normally", "not", "nothing", "notwithstanding", "novel", "now", "nowhere", "o", "obviously", "of", "off", "often", "oh", "ok", "okay", "old", "on", "once", "one", "ones", "one's", "only", "onto", "opposite", "or", "other", "others", "otherwise", "ought", "oughtn't", "our", "ours", "ourselves", "out", "outside", "over", "overall", "own", "p", "particular", "particularly", "past", "per", "perhaps", "placed", "please", "plus", "possible", "presumably", "probably", "provided", "provides", "q", "que", "quite", "qv", "r", "rather", "rd", "re", "really", "reasonably", "recent", "recently", "regarding", "regardless", "regards", "relatively", "respectively", "right", "round", "s", "said", "same", "saw", "say", "saying", "says", "second", "secondly", "see", "seeing", "seem", "seemed", "seeming", "seems", "seen", "self", "selves", "sensible", "sent", "serious", "seriously", "seven", "several", "shall", "shan't", "she", "she'd", "she'll", "she's", "should", "shouldn't", "since", "six", "so", "some", "somebody", "someday", "somehow", "someone", "something", "sometime", "sometimes", "somewhat", "somewhere", "soon", "sorry", "specified", "specify", "specifying", "still", "sub", "such", "sup", "sure", "t", "take", "taken", "taking", "tell", "tends", "th", "than", "thank", "thanks", "thanx", "that", "that'll", "thats", "that's", "that've", "the", "their", "theirs", "them", "themselves", "then", "thence", "there", "thereafter", "thereby", "there'd", "therefore", "therein", "there'll", "there're", "theres", "there's", "thereupon", "there've", "these", "they", "they'd", "they'll", "they're", "they've", "thing", "things", "think", "third", "thirty", "this", "thorough", "thoroughly", "those", "though", "three", "through", "throughout", "thru", "thus", "till", "to", "together", "too", "took", "toward", "towards", "tried", "tries", "truly", "try", "trying", "t's", "twice", "two", "u", "un", "under", "underneath", "undoing", "unfortunately", "unless", "unlike", "unlikely", "until", "unto", "up", "upon", "upwards", "us", "use", "used", "useful", "uses", "using", "usually", "v", "value", "various", "versus", "very", "via", "viz", "vs", "w", "want", "wants", "was", "wasn't", "way", "we", "we'd", "welcome", "well", "we'll", "went", "were", "we're", "weren't", "we've", "what", "whatever", "what'll", "what's", "what've", "when", "whence", "whenever", "where", "whereafter", "whereas", "whereby", "wherein", "where's", "whereupon", "wherever", "whether", "which", "whichever", "while", "whilst", "whither", "who", "who'd", "whoever", "whole", "who'll", "whom", "whomever", "who's", "whose", "why", "will", "willing", "wish", "with", "within", "without", "wonder", "won't", "would", "wouldn't", "x", "y", "yes", "yet", "you", "you'd", "you'll", "your", "you're", "yours", "yourself", "yourselves", "you've", "z", "zero");
}
?>

Spiffy, right? I love little pieces of code like this. Pure poetry.

Let’s prise it apart and ponder it piecewise.

Let’s break it down

Once again, if you’re getting queasy, just skip right over this part to get to the goodies at the end.

And once again, why all this trouble? Couple of reasons: SEO Slugs is very short, so “Because I can” is really all the justification I need. But another, more important reason is that it illustrates a very important and powerful capability of WordPress, in a context that most intermediate WordPress bloggers can understand. That is, you. (And that includes you too Mr. El Dorado)

Start at the beginning…

…which is usually the best place to start.

In this case, on line 20 we’re kicking off with add_filter, one of the top five most important functions in WordPress. Dig into the WordPress code, add_filter is everywhere you look. Even with relatively benign functions such as register_activation_hook, scratch it deep enough, there’s a daggone add_filter lurking down in the basement.

20

add_filter('name_save_pre', 'seo_slugs', 0);

Here’s what add_filter does: it takes a function, here given by seo_slugs declared on line 22, and adds that function to the list of functions which get called when the name_save_pre template is invoked. That is, when you press “Save Draft,” the seo_slugs function processes your article title and emits a tasty new post slug full of keyword-rich scrumptiousness.

But suppose you like your post slug. It’s quite tasty enough, thank you. That’s cool, SEO Slugs will keeps it mitts to itself. Here’s proof:

24
25

    // We don't want to change an existing slug
    if ($slug) return $slug;

All this means is that when you put your own slug in the little box, you get to keep it:

Use your own post slug.

What’s next…

27
28

    global $wpdb;
    $seo_slug = strtolower(stripslashes($_POST['post_title']));

wpdb is your WordPress database. It’s another one of those things that’s everywhere, you need to make it’s acquaintance sooner or later.

The next function, strtolower takes your title and turns all your capital letters into lower case letters. Actually, it takes your title after it does a little magic on it with stripslashes, but let’s leave that rabbit hole for another day.

Next, if you have some of those cool HTML symbols in your title, like hearts ♥s and stuff ‽, we have to remove those for the post slug:

30

    $seo_slug = preg_replace('/&.+?;/', '', $seo_slug); // kill HTML entities

preg_replace is easy: Perl-compatible regular expression, replace all matching instances.

You know how I always say, “Simple, but not easy”? Well, this is easy, but not simple.

Let’s get rid of more cruft people like me put in our blog post titles, like punctation marks, etc.

31
32

    // kill anything that is not a letter, digit, space or apostrophe
    $seo_slug = preg_replace ("/[^a-zA-Z0-9 \']/", "", $seo_slug);

Self-explanatory, if you grok regular expressions. ^a-zA-Z0-9 means get rid of everything not a through z, A through Z or 0 through 9. Easy peasy. (But not simple.)

Here’s where we get to the good stuff. Our post slug is all prepped, now it’s time to strip out the stop words. Words like “a” and “the” and “and” which are boring and unrankable. Seriously, trying to rank for the word “the” would be pretty hard.

31
32
33
34
35
36

    // Turn it to an array and strip common words by comparing against c.w. array
    $seo_slug_array = array_diff (split(" ", $seo_slug), seo_slugs_stop_words());
    // Turn the sanitized array into a string
    $seo_slug = join("-", $seo_slug_array);
 
    return $seo_slug;

Picking up the pace, line 32 matches your title against an array of stop words, and deletes everything in your title that is also in the array. Line 34 puts it all back together, this is what you see in your permalink after you save or publish your blog post. Line 36 is the seo_slugs function giving your brand new slug back to WordPress.

And there you have it, the entire SEO Slugs plugin.

Give it try, see what you think.

UPDATE: Don’t know why I didn’t think of this before.

“Why all this toil and trouble?”

That’s a pretty good question.

In part, I’m showing you exactly what I do when I teach myself. I just go through the code one line at a time, learn what each line does, then (the hard part) figure out why that line is necessary.

Understanding source code requires an investment of time and mental energy. While I eat this stuff two or three meals per day, it’s not quite to some people’s taste, and others are downright allergic to the very notion.

But there are rewards.

One of which is overcoming all fear of WordPress coding. Well, at least most fear. There is some scary sh*t in the WordPress core, but you never need look at that if you just stick to WordPress plugins.

Knowledge builds on itself incrementally. Learning a half dozen of the most common functions you find in plugins goes a long way to stomping that learning curve flat. This is usually irrelevant, I admit, except when it’s Zero Dark Thirty and your blog is down. And you don’t know why. Then knowing a little WordPress seems pretty smart.

In any case, between this article and Blog Post Engineering, you have a grip on post slugs. Provided you have a grip on Blog Post Engineering…

Lagniappe

July 17, 2010, and I’ve put a full week into the next release of Blog Post Engineering. Julie Angelos just pinged Top 10 Reasons WordPress is the future of the internet, with a CommentLuv link looking like this:ㄥ❀∨モ criticism ♥.

How could anyone resist that?

Now, I asserted that SEO Slugs removes fancy pants HTML entities, and it does. But you can still have such beasties in your post slug, just paste them in manually.

Here’s proof:

I have no idea what the effect on SEO is with such a spiffy little post slug. Neither do I care! Once in a while, just have some fun tweaking the rules.

Post from: Website In A Weekend

Really Fast SEO Slugs with WordPress plugin (Technical Tuesday)

(Reading time: 3 – 4 minutes)

I’m sitting here on a Mayday Saturday morning (that is, last weekend) at Paypal Town Center here at eBay central in San Jose California.

It’s another Startup Weekend; Walter and I are building a new business in one weekend.

Here’s the problem we want to solve:

Sometimes I want people to contact me directly, sometimes I don’t.

But every application I use, such as Skype, and Gmail, and Facebook has it’s own status indicator. Except that some don’t have status indicators at all (yeah I’m talking to you, Twitter).

What we want is a global way of letting people know “I’m available” or “Go ‘way.”

Such that anywhere I’m at, like Website In A Weekend, or iPhone, or Gmail chat, or Skype, or Facebook (ok, maybe not Facebook ’cause they play by their own rules), I can set my status and it will be set everywhere else.

“But, what,” you ask, “has this to do with WordPress and blogging?”

That’s an excellent question Let’s find out.

What’s in it for you

If you had a notion that maybe this “Weekend Apps” or “Startup Weekend” was somehow related to “Website In A Weekend,” you’d be pretty close to the truth.

The inspiration for Website In A Weekend came from attending these startup weekends.

It’s a great model. In one intensive weekend, you get yourself crammed full of everything you need to get a business going.

Remember my writeup on Foodspotting? Startup Weekend.

A disclaimer, of sorts

I have to be completely honest here…

A lot of people assume they get weekends off. As in, every weekend.

I cannot relate to that.

The only time I’ve had much in the way of “weekends off” was the 4 years in the USMC (except for deployments, which are work every day of course), and a couple of brief stint as a post-graduate researcher.

Pretty much half my life, weekends have been nice to have off, but not something I could necessarily count on. When I was working construction, if it rained on Tuesday, we work on Saturday. Otherwise, lose a day’s pay.

School? Part time work to pay the bills, and studying, always.

So as an entrepreneur, it doesn’t feel strange at all to work on weekends.

For me, scheduling an entire weekend to build a brand new application – or a brand new website – well, that’s just how the world is. And I’m not the only person working this hard! I’m not sure if I feel validated or terrified, but most of the people at the top of this blogging craft put in 60+ hours per week!

What are you doing this weekend?

To be sure, working on weekends isn’t everyone’s cup of tea.

But having a huge block of time which is all yours, that is, time your employer doesn’t have demands on, really let’s you focus on the task at hand. It’s like getting two weeks work done in two days!

What this means for you: when you’re ready to buckle down on a Friday evening… I’m all in! We’ll have you a brand new WordPress site, with all the bells and whistles, by late Sunday afternoon. You can even go get one of those “free” WordPress installs if you like. I’m totally cool with that, in fact, I’d love it if you did because that stuff is boring and having it handled already would be awesome.

Just let me know!

Post from: Website In A Weekend

Startup Weekend – Start a brand new business in 56 hours (Saturday Morning Surfing)