Comment Spam and WP-SpamFree

I’m tired of comment spam. I guess my blog has grown to a popular enough size that I’m known by just enough bots to make things annoying.

The next plugin I’ll be trying out is WP-SpamFree. If you can’t post a comment, use my contact form to let me know there is an issue.

WP-SpamFree uses a JavaScript and Cookie based approach to break the bots out there. Apparently, it’s pretty successful but I don’t have any experience with it yet. I’ll post an update to this post when I have more input. I’m hopefully optimistic that I’ll be deleting less comment spam from now on.

Update I haven’t had a single comment spam since I installed the plugin.

Formatting Source Code with WordPress

Sometimes you get used to doing things one way and you forget to take a step back now and then and see if there isn’t something you’re missing. In my case, I was formatting source code on this blog by putting html non-breaking spaces and < codes for angle brackets etc. Ouch. What was I thinking.

Here is a much better way to do it. Use the CodeHighLigher plugin. All you have to do after enabling the plugin, is place your source code in a pre tag. Add the lang attribute to the pre tag and you’ll end up with code formatted in a number of languages. The usage section of the plugin document has all the details and languages. I’ll not add that again here. Here is an example though:

int main(int argc, char* argv[]) {
 cout << "Hello Code Formatter Plugin" << endl;
< /pre>

You can include code that would otherwise be formatted by the plugin by putting a space between the end angle bracket and the forward slash for the pre tag. The plugin then outputs the ending pre tag correctly for formatting.

Here is the above code formatted by the plugin:

int main(int argc, char* argv[]) {
 cout << "Hello Code Formatter Plugin" << endl;

Again, I'm not sure why I didn't find this sooner.

How to fix the Digg Tools JavaScript for WordPress

If you have a wordpress blog and you’ve ever had a popular enough post to have it posted to, you might be tempted to paste the digg tools javascript into your post to integrate your site with the digg post. The first thing you noticed after you got the post edited is that your new widget didn’t work properly. It reflects the accurate Digg count on the post page but the home page has an incorrect or 0 count.

The following default integration JavaScript works on the post page but not on your blogs front page. Here is a quick explanation of the problem. Notice in the original JavaScript code below, the WEBSITE_URL parameter is enclosed in single quotes. WordPress interprets single quotes when your post is displayed and prints a pretty curved quote instead. This results in pretty apostrophes and broken JavaScript. The reason the Digg count works on the post page is that the digg_url parameter, if not set, is defaulted to the referring URL. If the referring URL, in this case, the post page, is the same as an existing digg article, the Digg count is correctly accessed.

<script type="text/javascript">
digg_url = 'WEBSITE_URL';
<script src="" type="text/javascript"></script>

Well, the fix for this is so simple that I almost didn’t blog about it. Only after helping fix a post for ExtraLife, Scott said that I ought to write all this down and make a post.

The fix is simply to change the single quotes to double quotes. WordPress doesn’t send interpreted double quotes and your Digg widget renders properly in both locations. Since that was such a simple tweak, I’ve also included a div with a style that displays the widget on the right side of the text with the text wrapping around the bottom when the widget ends.

Here is my modified and corrected JavaScript. Enjoy. I’m also pasting it at the top of this page so you can see a working example. I don’t usually Digg my own articles but oh well.

<div style="position: relative; float: right; width: 52px; margin: 0px 10px 0px">
<script type="text/javascript">
digg_url = "WEBSITE_URL";
</script><script src="" type="text/javascript"></script>

Can Google’s Adsense bot understand gzipped html pages?

During my experiments with WP-Super-cache, I noticed a strange thing happen to my Adsense ads. A short while after getting gzip compression to work properly, all my ad content had foreign characters and strange seemingly unrelated content.

Having changed nothing on my blog except for installing WP-super-cache, I decided to add an additional check to my .htaccess. Here is a modified snippet that disallows Google’s Adsense bot from receiving the gzipped page:

RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{HTTP_USER_AGENT} !Google*
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$ ml.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz [L]

Notice the new line that says the User Agent can’t have Google in it’s description.

Sure enough, ads are back to normal. I’m not sure how exactly Google’s crawlers handle gzip compressed pages. They are sending an “Accept-Encoding” header that includes gzip or the page wouldn’t be served to them in the first place. Judging from the change in my Ads however, I’d suspect that the bot isn’t uncompressing the received file.

Making WP-Super-Cache gzip compression work

I was pretty excited to see an update to WP-Cache. The first thing I noticed is that when I enabled the new super cache compression option, I started getting a file save as dialog instead of my pages. As of the current version of WP-Super-Cache, the readme.txt file states that if you get this, you need to disable the super cache compression option.

Not being satisfied with this answer, I’ve done a little digging and come up with the following solution. Continue reading “Making WP-Super-Cache gzip compression work”

WP Super Cache – The Ultimate WordPress Caching Plugin

I’ve upgraded my old WP-Cache plugin to this one that I found on today.

From the Post:

Tired of clicking a link off the Digg front page only to find a crashed or mortally lagged site on the other side? Finally, Donncha (one of the main WordPress developers) has solved the problem once and for all with a plugin that blows WP-Cache away.

I had a minor issue but was able to find the answer on the WordPress plugins wp-super-cache faq page. If you are upgrading from the old plugin, you need to correctly set up you cache files in the wp-content directory. I had old files based on the original WP-Cache and needed to remove those and add the new ones.

# from within the wp-content directory
>rm wp-cache-config.php
>cp plugins/wp-super-cache/wp-cache-config-sample.php wp-cache-config.php
>ln -s plugins/wp-super-cache/wp-cache-phase1.php advanced-cache.php

After that, I was able to enable and use the plugin successfully.

In addition to enabling the plugin, I thought I’d try out the super cache functionality. To do this, you have to add a few more rewrite rules to your .htaccess file. I didn’t notice this in the documentation, but you have to add these before your other rewrite rules.

# new .htaccess file after enabling super cache
RewriteEngine On
# if these rules come after, you'll not get the super cache functionality
RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz [L]

# my original rules
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Edit: I posted an update that deals with getting the super cache compression to work.

read more | digg story