Because some days are better than others, I managed to upload the wrong zip file of the link cloaker plugin. That error has been corrected. This is the correct download link for the Simple Link Cloaker plugin.

It seems that if I had named the Simple Link Cloaker plugin The Fabulous Redirector instead, all would have been well – but the guys/girls that run the WordPress plugin repository didn’t like the term ‘cloaker’. I guess it implies being shady, which we all know is not the intent or use for this plugin.

At any rate, since you can’t get it from WordPress any more, you can get it here: ilwp-simple-link-cloaker. Installation is a snap, if you remember the old way of installing plugins:

1. download the plugin zip file to your computer
2. unzip the file into a directory
3. upload the entire plugin folder to your wp-content/plugins folder
4. activate through the Dashboard > Plugins interface

Thank you for all of your support!

Note: if you’re not a WordPress plugin developer, this probably won’t interest you.

I ran across this again today, hence my rant:

I installed a plugin from the WordPress Plugin Repository ( the place that hosts WordPress plugins so you can download them ), THEN looked through the code. This small specialty plugin added 17 options to the options table!

WP developer peeps, there is no excuse for this. By adding so many options, you clog up the options table. Unless you specify the option as an autoload, you’re using a database read every time you call get_option(). What a waste!

What should you do instead? Glad you asked!

Combine your options into an array. Easy smeasy. WordPress will store your options array as serialized data. Return get_option() to a variable at the start of your script, giving you easy access to all its components.

The WordPress core is getting sizable enough that responsible developers need to optimize their code as much as possible. Eliminating unnecessary database reads/writes is a good first step.

If you need an example, leave a comment and I’ll post one.

EDIT: as requested, here’s a couple of examples. First, what many developers do but shouldn’t:

$myoption1 = "ted";
$myoption2 = "fred";
$myoption3 = "jed";

update_option( 'myoption1', $myoption1);
update_option( 'myoption2', $myoption2);
update_option( 'myoption3', $myoption3);

Notice how the above uses 3 different options: myoption1, myoption2, myoption3. These take up 3 rows in the database, and require 3 different calls to get_option() when the data is needed. Now, 3 isn’t very many – but consider when your plugin uses 30 or 40 different options or presets ( some of mine do ). The potential to clutter up the database and cause a slowdown in your page load times is huge.

Here’s how you should code your options:

$myoptions = array( 'option1' => 'ted', 'option2' => 'fred', 'option3' => 'jed');
update_option( 'myoption', $myoptions );

And that’s all there is to it. The update_option function recognizes that you are passing an array and serializes the values for entry in the database. When you need to retrieve the options, simply call get_option into an array variable, and access from there. One call, 40 options. Lotsa overhead saved

$myoptions = get_option( 'myoption');

/*
now, $myoptions['option1'] = 'ted', $myoptions['option2'] = 'fred', and so on.
*/

One of WordPress’ strengths is its attention to SEO-related issues in its core files. One of those issues is the problem of having the home page of the blog indexed twice in the search engines; once under the actual address, http://domain-name.com/index.php, and the other as the plain domain name: http://domain-name.com. Note that this is a different problem than the trailing slash problem ( http://domain-name.com/ vs. http://domain-name.com ) which WordPress also takes care of.

WordPress handles the index.php problem by rewriting requests for http://domain-name.com/index.php to http://domain-name.com. All well and good, and beneficial for most sites.

But that rewriting/redirecting caused some problems on a site I was working on yesterday, and once I figured out how, it was a relatively easy fix.

Here’s what happened: a client had me upgrade an old installation of SemioLogic’s version of WordPress to genuine WordPress. While it can be time-consuming, switching over is a fairly straightforward process most of the time. The challenge here was that while most of the site is normal .html files, WordPress is installed at the root level, and is not actually serving the ‘home’ page of the site.

So you can maybe see where this is headed: the ‘home’ page of the site is index.html. That’s what comes up when you ask for http://domain-name.com. The server is set to look for index.html first, then index.php if index.html isn’t there. So to get to the blog, you had to ask for http://domain-name.com/index.php.

But when you asked for index.php, WordPress, being the dutiful SEO-friendly software that it is, stripped off “index.php” from the request, and redirected to http://domain-name.com.

The server saw the request for the site index file and promptly served up index.html. So you couldn’t get to the home page of the blog. If you had a specific post URL and typed it in, it worked fine.

Easy fix, says I. Settings -> General, change the WordPress url to http://domain-name.com/index.php from http://domain-name.com.

Oops. Now all the permalinks have ‘index.php/’ prepended: http://domain-name.com/index.php/i-want-this-post. Not good, and not intended, especially as the site has been indexed in Google without the index.php in there.

I never did figure out how SemioLogic handled this; obviously it was working before the changeover. Undoubtedly there was an easy setting that disappeared once the SL files were gone. I can only think this issue had come up before and the author of SL provided a workaround.

Thankfully, the coders of WordPress also recognized that there may be a time when rewriting URLs wasn’t good so they provided a filter to disable or alter the rewrite. Once I found that notation in includes/canonical.php, the fix was a breeze. Write a plugin that disables the redirect to / when /index.php is called for. Here is the entire plugin:

<?php
/*
Plugin Name: Index.php fix
Plugin URI: http://ilikewordpress.com/loading-wordpress-from-index-php
Description: This plugin allows a blog installed at root to be addressed by /index.php. Remedies stripping of filename by includes/canonical.php
Author: Steve Johnson
Version: 1.0
Author URI: http://ilikewordpress.com/
*/

/*
*    Applies filter to redirect_canonical to defeat
*    stripping of index.php file
*/

function fix_index( $requested_url ) {
 if ( get_bloginfo( 'url' ) == $requested_url )
 return false;
}
add_filter( 'redirect_canonical', 'fix_index' );

?>

And that’s all there is to it. Now when a browser asks for ‘index.php’, that’s what it gets instead of a redirection to /.

You could also put this in the functions.php file of a theme, but obviously it wouldn’t work if the theme were changed.

Anyone who’s ever done any affiliate marketing knows the value of ‘cloaking’ outgoing affiliate links. First, it can deter the occasional commission thief who will strip out your affiliate code and replace it with their own, robbing you of a well-earned commission. Just as importantly, it makes your links more ‘professional’ looking when the visitor hovers over the link and looks down at the status bar. They’re more likely to click if the status bar reads http://myblog.com/i-want-you-to-go-here rather than http://gohere.com/so-i-can?make=some&money. Agreed?

So, lazy affiliate marketer that I am, I looked around for an easy way to cloak affiliate URLs. Easy being the operative word here. I wanted the system to work with WordPress, I didn’t want to upload a new PHP file every time I needed a new affiliate link cloaked, didn’t want to mess with lame <meta refresh=”99bottlesofbeer”> meta tags in new files.

I looked around for an existing WordPress plugin that would do the trick, because while I could certainly write one, I didn’t want to. Like I said, I’m a lazy affiliate marketer.

I found several – but they all did WAY more than what I needed. One that I tried even attempted to verify outgoing affiliate URLs – handy, but it added almost a minute to my posting time, and I didn’t really need the verification.

Another did everything but my dirty dishes.

Enough was enough. Broke out the PHP editor and sliced my own.

This plugin is simplicity in action. If you’re at all capable of copying/pasting or writing down a simple URL, and don’t need fancy tracking and CTR stats, this plugin’s for you. You’re not limited to a certain folder name or names, you can make the outgoing URL as long or short as you want it, make it say anything you want. Doesn’t matter.

You can download it here. If you like it, and it helps you make affiliate money easier, you can show your appreciation and buy me a beer Amp. I live on Amps. Especially the Charge lemon-flavored one, and the Tradin’ Paint 3-flavor version.

I saw a tweet today about WordPress comment page duplication issues related to SEO. While the word is still out as to just how much damage it does or doesn’t do to your ability to get found by the Great G, this specific problem is relatively easily fixed — and not by disabling the paged comments feature that the Wizards of WordPress have so kindly coded for us (you ever had a post with 300 comments? you’ll understand what I mean…).

All it takes is a little bit of code in the functions.php file in your theme. If you’re uncomfortable editing your theme files or don’t know how, leave a comment and I’ll whip up a little plugin. This may be a good time to learn to edit your files, though

This little bit of code doesn’t affect anything but WordPress comment pages. If you use WordPress for something other than a plain-vanilla blog, you may need the horsepower of Yoast’s Canonical URLs plugin for WordPress.

So in your functions.php file, insert the following code (I split the echo lines up for clarity, normally they’d be all on one line):

function canonical_for_comments() {
 global $cpage, $post;
 if ( $cpage > 1 ) :
  echo "\n";
  echo "<link rel='canonical' href='";
  echo get_permalink( $post->ID );
  echo "' />\n";
 endif;
}
add_action( 'wp_head', 'canonical_for_comments' );

Make sure you paste the code before the last ?> characters at the end of the file.

For those of you who care, here’s a quick explanation of what the above code does — you’ll get a short intro into the behind-the-scenes functioning of WordPress.

When a visitor navigates beyond the first page of comments, the variable $cpage contains the page # that’s being displayed. The $post variable contains all of the information about the post. The function tests to see if we’re on a comments page greater than 1, if so, it spits out the <link rel=…./> characters. But where does it spit them?

That’s controlled by the add_action line. We’re telling WordPress that when it’s building the head section (‘wp-head’), to add our special ‘canonical_for_comments’ function.

Simple, easy schmeezy.

I needed a colored tag cloud widget, and I couldn’t find one that I liked. So I cooked up another one. You can see it in action over in the sidebar. You can configure colors, sizes – you can even use it in your theme instead of as a widget. Or you can do both.

See the official ILWP Colored Tag Cloud plugin page to download.

An update: Twitter has seen fit to deprecate (discontinue) the search function that this plugin depended on. Until I can come up with some kind of solution, you should deactivate the plugin if you’re using it; you might have some unexpected errors.

Today is release day for Twavatar – Twitter Avatars For Your WordPress Blog.

It is a simple plugin that displays a commenter’s Twitter profile image in place of the standard WordPress gravatar. If a Twitter image can’t be found, the regular gravatar is displayed.

Twavatar is nice to twitter – it only looks once, and if it finds a profile URL, it caches it in your database for future use. Future versions of the plugin will have an expiry time on the cached URL to ensure avatarial freshness.

You can download the plugin from its page.

UPDATE: 0.6.0 is now out. Latest version add support for substituting Twittter avatar for standard Gravatar. If a Twitter avatar isn’t found, defaults to standard WP options.

UPDATE: Ha! Well, this is embarrassing. TweetSweetR is now at version 0.5.1 already

A few months ago, the twitter world was all a-twitter (I know, bad pun) about a WordPress plugin called TweetSuite. I saw it, installed it on a couple of blogs and one notable blog network. It worked okay, but didn’t really have the features I/we were looking for, and it wouldn’t run on the network. Then, the plugin kind of dropped off the radar. Maybe the author didn’t have time to support it (it happens, trust me). Feature and support requests were going unanswered, and it even appears the author stopped using his own plugin! None of this is meant to detract from the plugin – it fulfilled a need of the Twitter world at the time, and served its purpose and every plugin author has a life beyond plugins.

So rather than wait for updates that might never come, I decided to take what I thought were the best concepts of the plugin, make a few feature additions here and there, modify the execution, and come up with my own.

So, here it is: TweetSweetR in all its BETA glory.

What does TweetSweetR do?

TweetSweetR provides a number of tools and features to integrate your WordPress blog with your Twitter account. As you post, it automagically grabs a shortened URL from the http://is.gd url-shortening service and displays a badge and ‘tweet this post’ link with the shortened URL already included. A visitor clicks the link or the badge and goes to their own twitter home where they can finish adding a tweet.

TweetSweetR periodically searches for mention of the post’s short url using Twitter’s search service, and posts a list of tweets that are talking about your post.

TweetSweetR also provides a number of sidebar widgets you can use or not use:

• MyTweets, a list of your current twitter tweets
• MyFavs, a list of your favorited tweets
• TwitterTrends, a list of currently trending searches on Twitter
• MostTweeted, a list of your most-tweeted blog posts as defined by the number of search results for each short url

TweetSweetR updates itself automatically using a scheduled-tasks feature of WordPress. It gathers your latest updates, searches for mentions of your blog posts, grabs new trends — all in the background so your page loads aren’t delayed. Searches and updates are throttled to keep you from running afoul of Twitter’s API restriction of 100 requests per hour. All results are stored in the same database that your blog runs from, and TweetSweetR looks there first for information.

TweetSweetR is still very much in beta-testing mode, and new features are still being added. When TweetSweetR reaches a stable release status, I’ll add it to the WordPress plugins respository. When that happens, you’ll be able to automatically update the plugin through your WordPress plugins page.

To download the plugin and see full installation and usage details, please visit TweetSweeR for WordPress’s permanent page.

Smashing Magazine recently released a WordPress “plug-in that uses Twitter to show avatars in comments in WordPress blogs”.

While I like the idea, the implementation leaves a little bit to be desired. Comments to the release post indicate that some effort is being made to address the shortcomings in the plugin code, but as yet those changes haven’t been made.

Here’s why I don’t recommend that you use this plugin just yet:

• the Twitter API allows 100 requests per hour. If you have a blog post with 20 comments that gets visited 5 times in one hour, Twitter will cut off further requests
• each call to the avatar display requires 2 HTTP requests on the server side (via cURL calls) and one at the client side to download the avatar. Using the previous example of 20 comments, that works out to sixty extra HTTP requests for every page load. Completely unacceptable.
• the plugin requires that you diddle around with your theme. While that isn’t a problem with some bloggers, for the majority it is a non-starter. The plugin needs to hook into the appropriate WordPress functions rather than rely on theme changes.
• the plugin searches for and displays Twitter avatars first, then falls back to the common gravatar we all know and love (!) then further falls back to a default image. All fine, but no choice is given to the blog owner as to preferred fallback behavior. I would prefer to be able to choose which avatar to display as a default.
• searches for Twitter avatars are made on the email address that the commentor enters. *I* don’t even remember what email address I used when I signed up for Twitter. I would much prefer to see another form field that asks for a Twitter ID. Yes, it’s an extra field to fill out and implementing it will mean much more work in coding the plugin.

So the bottom line is that at this point in time, I don’t recommend that you use this plugin. If the changes suggested to the developer are made, though, it will definitely bear looking at again.

For more information, you can visit the release post here: Twitter Avatars In Comments WordPress Plugin.