As others have pointed out, this can be counter-productive. People don’t like to read articles that have just one Digg – they seem unpopular.

So here’s a solution: use the Conditional “Digg This” WordPress Plugin to only show the Digg Badge for articles that have a certain number of Diggs.

Why Shouldn’t You Show the Digg Badge on Every Article?

It’s easy enough to plaster the Digg Badge in your template or use a plug-in to add it to every post. Most of your posts aren’t going to be popular though. You’ll get at most one or two Diggs… nothing to write home about.

When a user opens your article, he or she might be impressed by “100 Diggs.” He or she definitely won’t be impressed by “1 Digg.” That’s a hint that your article wasn’t anything special – so why should the reader keep going?

Using the Plugin to Only Show the Badge on Popular Articles

The Conditional Digg This plug-in was designed to address this issue.

All you need to do is download the source code, upload it to your plugins directory, unpack the tar.gz, and click “Activate.” You don’t need to modify any settings or insert anything into your template. It’s all automated.

How Does It Work?

The basic concept behind the plugin is this:

• Load a story in your WordPress Blog
• Check the Digg API to see how many diggs the article has
• If the article has 10 or more diggs, show the badge…
• Otherwise, leave it alone.

Originally, I coded the plug-in to use a php function to access the API and check the number of Diggs each article had as it loaded. This worked perfectly – but it took a while. Sometimes, the API is slow to respond. If the API took 8 seconds to spit back a response, that meant your page would take 8 extra seconds to load up.

Even if the API was responding quickly, this was a problem for the front page and category pages. At best, the API takes about .25 to .5 seconds to respond – and with 10-15 checks on a page… you’re still waiting a good long time for the page to load.

Load First, Check the API Later

The solution I came up with was to use some nifty AJAX to perform the API checking behind the scenes.

The plug-in creates an AJAX request for each article. It sends information to a php script which accesses the Digg API behind the scenes. The page loads up instantly and AJAX will quietly do its thing. When the response is ready, it’ll change the page to include the Digg This badge if necessary.

So, the next time you want to display a “Digg This” badge on your article, think about how many diggs your article has already. Or, use the Conditional “Digg This” WordPress Plugin to automatically add a badge to your popular articles.

I only realized today – while testing something else – that the plugin had been firing off warning messages because of an oversight in the code. Warning messages annoy me, so I decided to fix it up.

Where’s the Error?

The plug-in consists of one file – per-post-css.php.

Towards the end of the function per_post_css_js, the script loops through any retrieved CSS and JS files. During these loops, the link tags are added to the head element of the page.

Here’s the line that deals with CSS stylesheets.

foreach ($array_css as $css){ 
  print("\t<style type=\"text/css\" media=\"screen\"> @import url(". $css ."); </style>\n");
}

Notice anything potentially wrong here? What happens if there are no custom CSS files attached to your page?

Foreach looks for an array ($array_css). If a value is passed to foreach that is not an array, it’ll fire off a warning – and that’s just what it did.

The fix is simple enough. Before attempting to iterate the loop, first check to see that $array_css (and later $array_js) is in fact an array.

if (is_array($array_css)) {
	foreach ($array_css as $css){ 
		print("\t<style type=\"text/css\" media=\"screen\"> @import url(". $css ."); </style>\n");
	}
}

It’s a minor problem that creates some inconsequential warnings… but it annoyed me so I fixed it. If you have display_errors turned off in PHP (which I usually do) you won’t notice the problem either.

Per Post CSS and JS Updated Source Code

In the plug-in file, the homepage is listed as http://www.flog.co.nz. Oddly enough, I didn’t see a reference to the script on the page anymore, although the author still updates the page.

When I searched for a new copy of Per Post CSS and JS, I found a listing in a WP Plugin Directory – which pointed to an old post on flog.co.nz. That post and the link to the source code are both dead now. Perhaps they were cleaned up to make room for new content.

Regardless, I’m going to re-post the source code for the Per Post CSS and JS WP Plugin here to keep it available.

Kudos and thanks to the original author, Adam Burmister.

Unfortunately, this isn’t a built in function of WordPress. Fortunately, you can add this functionality with a plugin.

Headspace

I originally accomplished this with the Headspace plugin.

Headspace is an all in one SEO plugin for WordPress. It’s major function is to allow you to add custom titles, tags, and meta descriptions to your WordPress posts. This should help with your SEO and SERP.

An added bonus is that you can add individual CSS stylesheets and JS scripts to each page. There’s an extra field in the writing page where you can add either of these two options.

This part of Headspace worked great. However, I was having trouble getting the other SEO functions to work. I was assigning descriptions and titles, but no meta tags were being generated.

Replacing Headspace

To fix that problem, I de-activated Headspace and got the All In One SEO Pack WordPress Plugin. It worked great, but that’s another post altogether.

I didn’t realize until after I had deactivated Headspace that I had also deactivated the custom CSS on a few posts/pages. I checked the pages and low-and-behold the custom CSS didn’t exist anymore.

I didn’t want to re-active Headspace just for this function, so I went off in search of a better solution.

Per Post CSS and Javascript

I eventually stumbled on this very simple plugin – Per Post CSS and JS.

It’s only a few short lines. It uses the custom fields function of WordPress to add the custom link tags. You define a CSS or JS field for a post, enter the URL, and the plug-in adds a link tag to the head section of your page.

It’s quite simple, and if I didn’t find a suitable script I was going to make one myself. However, this works perfectly well and I don’t think I could really expand on it (except maybe creating the CSS and JS fields on the writing screen, instead of using the custom fields) – so I doubt I’ll be writing my own plug-in anytime soon.

When it’s possible, re-use. Then focus your energy on things you need to do yourself.

I opened up phpmyadmin, expecting to see a “categories” table. No dice. After a few minutes I figured it out – and I decided it might be a good idea to explain how the WordPress database is structured.

When I first opened the database, I was impressed with its size. It’s made up of only ten tables. The other CMS I’ve used (CMS Made Simple) uses dozens of tables – so this seemed pretty compact.

Part of how this is done is that things are compressed into the pre-existing tables, rather than given their own tables. As a result you’ve got a more compact, more efficient database structure – but not necessarily the most intuitive structure.

To the right, you’ll see an map of the basic database structure. In the middle is the most important table – wp_posts.

Post Information – wp_posts

This is the heart and sole of your WordPress blog. It contains the basic information about each post and this is how other information is linked to your posts.

There is a lot of information here, but the major fields are ID, post_content, and post_title. The ID is used to link your post to other fields (like comments), and the content and title fields make up the actual post.

That’s what is read and displayed for the user to read.

Comments – wp_comments

This table is connected to the wp_posts table, and it contains all of the comment and trackback information for your blog.

Each comment has a “comment_post_ID” field – which matches up with the individual ID of the post it is attached to. There are a number of other fields that contain the comment data – like comment_author, comment_author_url, and comment_content.

Category and Tag Information – wp_terms

The original question was, “Where is the category information stored?”

This used to be in a “category” field in the wp_posts table. However, a more efficient way to do this was to create a new table with all the category information and a third table to link a post with a category – since each post can have multiple categories.

Each category and tag is defined in the wp_terms field. This includes the name, an id, and a description. In the wp_terms_taxonomy field, each “term” is defined as either a tag or a category.

Then, the wp_terms_relationships includes two numbers – a term id and a post id. By grabbing every term that uses a post’s id, WordPress can immediately identify all of the appropriate categories and tags to use.

For performance sake (but not necessarily readability), the tags and categories have been made synonymous in the database. They’re all “terms” – which cuts down on the number of queries WordPress needs to make to build a page.

Non-sequitors – wp_links, wp_users, and wp_options

The last few tables are non-sequitors. They aren’t attached to the wp_posts table, and they define random things about your blog.

For example, wp_links contains the information about links that are displayed in your “Links” section… if you use it.

The wp_users table identifies the user accounts that are registered for your blog. Chances are that that includes you – and no one else. The wp_usermeta table is attached to this, and it includes some options for each user (like whether or not they use the WYSIWYG editor for writing posts).

The only really important table here is wp_options.

This defines all of the major options of your blog – like the url, the title, the description, etc. Anything you set in the Dashboard is stored in a row in this table.

This also stores all of the plugin and widget information. WordPress uses a nifty trick to store widgets – it simply serializes them and stores them in a textfield in the database. Then, it can put the widget back together with by deserializing it.

This way a widget can be stored and reconstructed from one database row in one table, rather than creating a whole new table for each widget. It makes the information in the database pretty unintelligible – but it cuts down massively on the number of queries needed to create and use the widgets.

Start Messing Around

The purpose of this, of course, is to understand the database structure so that you can mess around with it yourself. That is, after all, the point of open source programs.

So lurk around in the database a bit. This is very useful information for writing plug-ins that need to interact with the WordPress database.

I started a (now defunct) website last year, powered by WordPress. It never got too popular, and in the beginning I was excited every time I got a “New Comment” or “New Trackback” e-mail. Then I realized they were mostly all spam.

A few minutes ago, I checked my e-mail and had a spam comment in my inbox. I thought, “Ahh, here comes the spam.”

When I logged into the dashboard, I spammed the comment and was about to move away. Then I happened to look at the dashboard again – and I remembered that I had set up Akismet this time around.

I just added the widget to the left sidebar because I was so impressed. Akismet apparently blocked 84 spam comments – and this was the first one that got through. I’d say that’s pretty impressive.

If you’re running a WordPress blog, or something else that uses comments and can utilize an Akismet plug-in, do so. There’s nothing more frustrating than wading through spam comments and trackbacks all day long.

Akismet is apparently pretty effective at cutting them down. A few of them might sift through, but you can never get rid of all the spam. So be happy if you can eliminate 84/85.

You can download the Akismet plugin for WordPress, but all new builds come with Akismet pre-installed. All you have to do is fill in the Akismet API number – which you can get for free with a WordPress account.

Happy spam-free comment logs.