I’ve been getting swamped by referer spam lately. Most of it is for domains that appear to have had hosting suspended. I had already seen a correlation between this referer spam and comment spam; what I didn’t know (but should have guessed) is that lots of folks are seing this. Tim Bray wrote about the problem today, pointing to more info from John Sinteur and Ann Elisabeth. Apparently all of these referer URIs resolve to a single webhost, with an IP of 161.58.59.8.
Ann’s post is one of many on her blog about the subject, she is actively pursuing this and trying to get Verio to pull the miscreant’s hosting. I suggest reading everything on her homepage for lots of good info.
John’s post on the WordPress support blog includes PHP code that sends a 301 Moved Permanently redirection header to any request with a referer URI that resolves to the IP above. Where does he redirect them? Back to the referer URI, of course.
Now, that’s an idea I like. I liked it so much I wrote a perl version as a Blosxom plugin. It’s called deferer, and is available here. Right now, it’s a one-trick pony, but (when time permits) I intend to expand it to a more comprehensive referer spam solution. I don’t know how effective redirecting these requests is- the spider scripts sending the requests may not follow redirects. Even so, deferer reduces server load (it ends the blosxom invocation early) and saves bandwidth.
Update: Deferer has been updated to version 0+2i, to fix a bug that caused a 500 Server Error if the referer hostname could not be resolved.
Steve Schwartz has created an updated version of my moreentries plugin that adds a series of links for each additional page of posts, like at the bottom of the page on Google. It supports both text and image links. I think this is just fantastic… this is a feature I’ve had requested, and just never got around to implementing. Go check it out!
Version 0+2i of my Storystate plugin is available here. For full details on the uses for this plugin, see the original writeup. This version adds a single new variable, $storystate::rqst_category. This is similar in use to the standard $path variable, except that it’s built from the request URL and not the path of a given post, so it’s available in the header flavour file. This allows you to display the current category in directory style (i.e., WebDev/Blosxom/Plugins) in the header. Since it’s really only useful on category index pages, you can mix it with Rael’s interpolate_fancy plugin to do something like:
<?$storystate::category>
<h2>Viewing Post Category: WebDev/Blosxom/plugins/storystate</h2>
</?>
For display purposes, the breadcrumbs plugin is probably a better choice. I added this primarily for use with per-category RSS feed autodiscovery (link to come).
I’ve created a new plugin for Blosxom, called moreentries. It creates ‘Next’ and ‘Previous’ links when there are more entries than allowed on a page (as determined by the Blosxom config variable $num_entries). This doesn’t affect date-style urls, since Blosxom ignores $num_entries for date urls.
Please note this is the first version. It’s been tested (with thanks to Fletcher T. Penney), but it may have bugs. Please Note: it probably won’t work right with static rendering, since it will require additional pages to be created. I’ll look into this if there is interest.
You can see it in action here on this site.
Download link: moreentries
Update: Fixed download link.
Update #2: Fixed the other download link (in the first paragraph). D’oh!
Update #3: As I stated in the perldocs, this could be done much more efficiently if blosxom.cgi were updated. Lars has suggested an elegant way of doing just that. If you’d like to patch your blosxom.cgi, check it out. If Rael releases an offical update to blosxom.cgi to include such a change, I’ll release a new version of the plugin to take advantage of it. This version will remain as well, for those using the current Blosxom version.
I author (and edit) my blog entries using the wikieditish plugin for Blosxom. I write nearly all of my content using the textile plugin. While this arrangement works, it isn’t perfect. For example, to show an example xml , I have to escape the < character as & lt; xml /> in the editor. If I need to edit the entry after it is posted, however, encoded characters are unencoded in the textarea of the edit form. This means I have to remember to re-encode such things.
This, and other desired features, is leading me to consider building a new editing plugin for Blosxom. Features I want:
- Play nice with other plugins, such as textile, wikiwordish, smartypants, others
- render exactly what’s in the disk file to the edit box, handling escaping on the way.
- option (checkbox, metatag?) to mark article as being interpolate-fancy exempt; causes auto-escaping of <'s, making it easier to post sample xml text, etc.
- Preview feature. Saves post with alternate extension, then runs the article through Blosxom in some way that recongnizes the extention, letting you see the post in context of your flavour template(s), without posting to the world; while viewing you can return to re-edit or elect to post. This means seeing content via your standard template, PLUS seeing some kind of editing interface. Perhaps a popup, or frame, or maybe edit plugin fiddles your flavour template directly?
- Checkboxes (maybe even backed by server- or client-cookie- based preferences) for auto-inserting commonly used meta-tags like meta-markup:textile.
- This may just be a matter of flavor templating the editing form (a la wikieditish), but I want to see hints for the plugins I use, like textile, etc.
- more secure passwording than wikieditish
- would-be-nice-needs-more-thought: ability to accept posts
via the nAtom API
I’m just pushing the thoughts around inside my head at the moment. If you have additional features you’d like to see in an editing plugin, click the comment link below.
My very first published plugin for Blosxom. You can download it here.
Storystate provides a number of convenience variables for use with the interpolate_fancy plugin by Blosxom author Rael Dornfest. It was designed to be especially useful with writeback. Storystate also allows presence of a meta-writeback tag to control if writebacks are open or closed. It’s basically useless without interpolate_fancy.
NOTE: best if used with interpolate_fancy version 2003-09-07 or later.
Excerpt from the POD docs:
Just drop it in your $plugin_dir. Optionally, you can adjust the values of the configuration variables at the top of the file. There are covered later.
Most of the variables are simple boolean indicators, using undef for false. This allows them to be used with interpolate_fancy’s and constructs. Some variables are story specific, (updated for each story), while others are based on the request url and are valid in the head and foot as well.
The request flag variables are:
- $permalink true if request url is a subdir permalink, e.g. /this/that/story.html
- $datepermalink true if request url is a date permalink, e.g. /2003/09/07/story.html
- $anypermalink true if request url is either of above
- $blogroot true if request is for blog’s root e.g. / or /index.html
- $archive true if request if date style, e.g. /2003/09
- $category true if request is subdir style, e.g. /this/that
The story-specific flag variables are:
- $writeback_closed true if writebacks are closed for story (see below)
- $permalink_wbopen true if !$writeback_closed and $permalink
- $permalink_wbclosed true if $writeback_closed and $permalink
The idea of closing writebacks is that you are no longer accepting comments for a given story. Just add meta-writeback: on or meta-writeback: off to the header of the story. If no meta-writeback header is found, the value of the config variable $writeback_default is used instead. Values are on (writebacks open) and off (writebacks closed). This is of course dependant upon you implementing checks against these variables in our story template, see the example below.
There is also a story-specific text variable:
- $writeback_message description of writeback state for story
This is useful for links to your writeback page. It returns (by default):
- ‘Add the first comment’ If writebacks are open for story and no comments exist
- ‘No Comments’ if writebacks are close and no comments exist
- ‘1 comment’ if only one comment
- ‘n comments’ if >1 comment, n=$writeback::count
These messages are configurable, see the config variables at the top of the file, they are documented inline.
See the POD docs for an example of usage, I just can’t get sample HTML to play nice with Textile2.