tech.agilitynerd.com

scratching that itch... 
Filed under

plugin

 

Blosxom Plugin lastcommented Enhancement

I had a comment entered on my [[AgilityNerd dog agility blog]] that I subsequently deleted and of course my lastcommented plugin recorded the comment as the most recent comment. Since the plugin uses Storable to store the data I couldn't manually edit the file to remove the entry.

So I modified my lastcommented plugin to allow you to specify the, base zero, index of the entry on the URL and delete the entry. For example to delete the second entry in the list (index 1):

http://agilitynerd.com/blog/?lastcommentremove=1

To keep mischief makers from deleting all your comments the plugin has a variable in its configuration section called lastcommentremove that you set to a non zero value to enable this feature. Since this is probably a relatively infrequent activity (if you have blacklisting or wbcaptcha comment spam protection enabled) I figured this was a sufficient mechanism.

You can download the latest version of this plugin here.

Filed under  //   blosxom   plugin  

Comments [0]

Minor Additional Mods to Blosxom moreenties Plugin

I had previously extended Jason Clark's moreentries plugin for Blosxom to allow adding images to links to the previous and next group of articles/entries in the head or foot of a Blosxom weblog. While attempting to have valid HTML on my blogs I found that I had left an img tag unclosed. I also found that it wasn't as easy to change the styling of the links as I had originally planned.

So I've closed the open img tags and added the configuration variable $selfstyle into which you can place any CSS style information you'd like added to the td containing each page link. For example:

# Set to the CSS style for $moreentries::links
$selfstyle = 'style="padding: 0 3px;"'; # set to '' for no style

 

You can download the modified plugin (version 0.3) here.

Filed under  //   blosxom   plugin  

Comments [0]

New hitcounter, favorites Blosxom Plugin Features

After fixing a bug in these plugins I decided to add some new features:

  • The links generated by the favorites plugin used to display the path and filename of each popular article. It now displays the article title and the filename is displayed when hovering over the link. This makes for a much nicer looking and more useful display. Thanks to Doug for the suggestion.
  • The hitcounter plugin now tests for existence of articles before adding them to its hash of counts.
  • Requesting a page which no longer exists deletes the page and its counts from the hash of counts. Since previous versions of this plugin would record non-existent pages they could appear in the favorites listing. So now you can delete them by clicking on the link in the favorites page.
  • As pages previously stored in the hitcounter hash of counts are visited their titles will be added so they will appear in the favorites' generated links.

Both plugins must be upgraded together and will upgrade the existing hitcounter database as pages are accessed. The new versions can be downloaded here:

Filed under  //   blosxom   plugin  

Comments [0]

hitcounter, favorites, lastcommented and lastread Blosxom Plugin Updates

I found a bug in my hitcounter, favorites, lastread and lastcommented plugins due to my not using the correct Perl Storable functions. For some reason I didn't use the locking versions of retrieve() and nstore(). So when my old webhost had some problem causing long page load times (and many simultaneous requests) I ended up having my favorites data file written as zero sized.

So I changed to Storable::lock_retrieve() and Storable::lock_nstore() for all four plugins. The new versions are here:

I never heard any bug reports about these plugins, but I'm sorry if anyone ran into any difficulties due to these bugs.

Filed under  //   blosxom   plugin  

Comments [0]

Blosxom - Removing the Unknown Flavour Error

After my recent Referer Spam attacks I've been checking my logs and AWStats reports daily. I noticed that occasionally I'd get people requesting pages with incorrect suffixes. i.e. foo.ht or bar.|id| (some of these are probably spammers too). A "feature" of Blosxom is that it will still serve the page with the default layout or flavour. This feature causes a not too helpful and ugly error message to be displayed on the top of the page:

Error: I'm afraid this is the first I've heard of an "ht" flavoured Blosxom. Try dropping the "/+ht" bit from the end of the URL.

Of course removing the suffix from the URL doesn't usually work; the client is served with an empty (but flavoured) page. So I though a better solution would be to have Blosxom serve my default_flavour whenever the flavour couldn't be identified. A little Googling later turned up this Blosxom mod by James Vasille. James explicitly loads a flavour file named "default" whenever the requested flavour can't be found.

For my site it is more appropriate to serve the $default_flavour when the requested flavour can't be found. That way I didn't have copy/create head.default, foot.default, etc files. So my code change is almost the same as James':

$template = 
  sub {
    my ($path, $chunk, $flavour) = @_;

    do {
      return join '', <$fh> if $fh->open("< $datadir/$path/$chunk.$flavour");
    } while ($path =~ s/(\/*[^\/]*)$// and $1);
# Begin added code
    do {
      return join '', <$fh> if $fh->open("< $datadir/$path/$chunk.$default_flavour");
    } while ($path =~ s/(\/*[^\/]*)$// and $1);
# End added code
    return join '', ($template{$flavour}{$chunk} || $template{error}{$chunk} || '');
  };

 

So now a less ugly page will be provided when an unknown suffix/flavour is requested.

Update 19-Apr-2005 - this algorithm has a bug that has been fixed by the defaultflavour plugin.

Filed under  //   blosxom   plugin  

Comments [0]

Blosxom - Hit Counter and Favorites Plugins

I added a Favorites page to the side menu of my AgilityNerd site. Since then I've been updating it manually about once a month based on the AWStats reports from my web hosting provider (HostMagix). This task is unnecessarily complicated because AWStats keeps page counts independently for each URL, which includes the Blosxom flavour (filename extension). For my purposes I don't want to distinguish between say HitCounterFavorites.html and HitCounterFavorites.htm

So I decided to write a plugin to track the hits per page and "lump" together counts independently from the file extension. This plugin allows me to display the hit count of visitors for each page on each page. I wrote a second plugin to use the hit count data to automatically generate my Favorites page.

Hitcounter Plugin

I based the hitcounter plugin on the categories plugin written by Todd Larason. The plugin has a couple features of interest:

  • The $reset_count flag within the plugin lets you provide a starting count value for any page. For example to set a page's count to 10 append "?count=10" to the page's URL. Disable this flag once you've set your counts to avoid mischevious count setting by outsiders.
  • The $retrieve_only_flavour flag within the plugin can be set to a flavour you want to use for retrieving counts without incrementing the count. Use this flavour to view the counts for URLs of interest.
  • You can add filters to the start() subroutine to exclude certain requests from updating your counters. I exclude RSS and Atom feed requests from my counts.
  • As of version 0.5 you can filter out loading and incrementing page counts for specific user agents via the ignore_agents array.

The hitcounter plugin stores the $blosxom::path as the key in a hash whose value is the count of hits. The hash is stored in a file in the data directory. The same hash is used for the entire site. As each page is "hit" the value is incremented and stored in the $hitcounter::count variable. I put this variable in the footer of my pages.

Favorites Plugin

My favorites plugin uses the data file containing the hash of paths and counts as its input. This plugin generates an HTML unordered list of the most visited URLs with the following configuration options:

  • The $num_entries variable controls how many URLs are listed.
  • The $include_counts variable controls if directories will be included in the list of entries.
  • The $include_counts variable controls whether or not the number of counts is appended to each list entry.
  • The $anchor_format variable controls if the full path or only the filename is displayed in the list entry.
  • The $anchor_link variable controls whether or not the entry is wrapped in an anchor <a>.
  • The $excludes variable controls which pages are excluded from consideration. I exclude the main URL for my site from showing up in the list.
  • The $groups array holds regexps that will generate separate unordered lists grouping together pages matching each regexp of $num_entries list elements. See the configuration section for an example. I use this feature for my Favorites page to group pages for agility and tech categories into separate lists.
  • The $url_flavour variable lets you specify the flavour to use for anchors to non-category URLs. It defaults to to $$blosxom::default_flavour.
  • You can add filters to the start() subroutine to exclude certain requests from doing the work to generate the HTML. For example, I only run this plugin for my Favorites page.

When this plugin runs the $favorites::count variable is populated with the HTML. I then put this variable in my Favorites.txt page.

Download version 0.5 of the hitcounter plugin here.

Download version 0.1 of the favorites plugin here.

Comments/bug reports are welcome.

Filed under  //   blosxom   plugin  

Comments [0]

Refererblock Version 0.2

I came up with two improvements to the first release of my refererblock plugin:

  • If the referer string matches the site's URL it passed immediately and isn't checked against the blacklist.
  • The blacklist.txt file was being read even if the referer string was empty. Now it is only read if the referer string is not empty and it isn't for the site's URL.

These optimizations do improve the performance of the plugin. My testing on a PIII 800MHz running Fedora Core 3 Linux with Apache 2.0 showed the following average latencies:

  • 1.5 ms - Empty referer string or current domain.
  • 2.0 ms - Referer string matching the first regex of the example blacklist file.
  • 3.0 ms - Referer string matching the final regex of the example blacklist file.

I was kind of surprised at how little additional time was required to load the blacklist file and process the regular expressions. This is probably due to the file remaining in the disk cache for subsequent requests. Of course your mileage may vary.

Download version 0.2 of the plugin here.

See my original plugin description for installation, configuration, and testing information. Please let me know if you use this plugin or if you have comments or suggestions for improving it.

Filed under  //   blosxom   plugin   referrer   spam  

Comments [0]

Blosxom - Default Flavour Plugin - Fixes Unknown Flavour Error

I previously blogged a solution for the Unknown Flavour error that involved modifying the blosxom.cgi script itself. I recently found my modification caused requests for the RSS 0.91 feed and atom feeds to return the default flavour instead of the desired feed. I suspect any plugin using a flavour that inserted itself into the Blosxom template hash table without corresponding flavour file(s) probably didn't work correctly after my modification.

While investigating a fix for that bug I noticed that a better solution would be to override the Blosxom template subroutine. So I created the defaultflavour plugin. This plugin fixes the bug by first applying any registered flavour templates if the requested template files are not found. If that registered flavour templates don't exist the plugin finally applies the default flavour template files.

Download version 0.1 of the defaultflavour plugin here.

No configuration of the plugin is required. Just copy it into the plugin directory.

Filed under  //   blosxom   plugin  

Comments [0]

Blosxom Plugins: lastcommented and lastread

In preparation for an overhaul of my website I wrote two new Blosxom plugins. The lastread plugin allows me to create a list of links to the last n articles that were viewed by readers. The lastcommented plugin allows me to create a list of links to the last n articles that had comments added by readers.

I took pains with these plugins so they only write their state files to disk when a single article is read (not when the index pages are hit) or when a comment is actually posted. I've also made it optional to not rewrite the state file if an already existing entry in the list is visited/commented again. There are a lot of Blosxom plugins that do a lot of work on every page access and I didn't want to add to the server load.

The configuration of each plugin is pretty straightforward. Both plugins require the Storable plugin for storing the state files. Only the lastcommented plugin requires any coding; whatever comment plugin you use needs to set a variable in order for lastcommented to do any work.

Download the lastread plugin
Updated 2007-06-23 to version 0.3 to fix unshift() error and ignore unknown file requests and filter out user defined HTTP Agents.

Download the lastcommented plugin
Updated 2007-06-23 to version 0.2 to fix unshift() error.

Hopefully I'll have my new site design using these plugins available in a few weeks.

Filed under  //   blosxom   plugin  

Comments [0]

Directing Search Engines to Blosxom Content Pages

I've noticed that folks who come to my site by querying through a search engine often end up on my main page and the article they are searching for has already rolled off the front page. This is because the search engine robots tend to choose the index pages as more relevant than the content pages linked to by the index pages. This is especially frustrating to me since I want my blog to serve as a reference for other Agility enthusiasts - so making my articles easily retrievable from search engines is important to me. It turns out this is a pretty common problem faced by many blogs.

I found that Jason Clark had run into this problem with his Blosxom blog and resolved it by using the following meta element on his index pages: <meta name="robots" content="noindex,follow" >. His post describes how he conditionally includes these robot meta tags through his head flavour files (using the interpolate_fancy plugin and his storystate plugin) only on his index pages and not on other pages.

For my site it is even easier. I use separate head.index pages to style my index pages differently from my htm/html pages. So I just directly inserted the <meta name="robots" content="noindex,follow" > into my head.index pages.

There are a number of other robots meta tags that I might consider adding in the future. Websnob has a thorough explanation of the tags and the robots that use them.

Hopefully over the next few months these changes will cause search engines to give their users links directly to the articles in my site.

Filed under  //   blosxom   plugin  

Comments [0]