All My Brain Where stuff from my brain lands

January 11, 2008

How to fix the Digg Tools JavaScript for WordPress

Filed under: Programming — Tags: , , , — Dennis @ 12:58 pm

If you have a wordpress blog and you’ve ever had a popular enough post to have it posted to Digg.com, 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 Digg.com 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 Digg.com 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>
<script src="http://digg.com/tools/diggthis.js" 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="http://digg.com/tools/diggthis.js" type="text/javascript"></script>
</div>

November 6, 2007

WP Super Cache – The Ultimate WordPress Caching Plugin

Filed under: Web — Tags: , , , , , , , — Dennis @ 3:45 pm

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

From the Digg.com 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

October 1, 2007

WordPress and Caching

Filed under: Web — Tags: , , , , , , — Dennis @ 9:11 pm

I just installed the plugin wp-cache. I’m not sure why more WordPress users don’t enable this. From the Wp-Cache description:

WP-Cache is an extremely efficient WordPress page caching system to make you site much faster and responsive. It works by caching Worpress pages and storing them in a static file for serving future requests directly from the file rather than loading and compiling the whole PHP code and the building the page from the database. WP-Cache allows to serve hundred of times more pages per second, and to reduce the response time from several tenths of seconds to less than a millisecond.

I don’t know how many times I’ve gone to a link on Digg.com and found an unusable site with mysql database connect errors, or simply a crashed web server. The comments always say “Another WordPress Blog”.

The problem isn’t WordPress specifically. Any site with a database backend for storage could have the same issues. The problem is that WordPress doesn’t cache pages by default. Any site serving static content with Apache as a front end should be able to handle digg traffic for a while assuming that they enough memory, bandwidth, and the apache directive “MaxClients” set high enough. Well, WP-Cache turns your dynamic WordPress installation into static pages and only regenerates them when they change.

We were marveling at the efficiency of this all when Scott’s Site was dugg twice on the same day.

Powered by WordPress

css.php
%d bloggers like this: