Gavin Carr, one of the Blosxom developers, recently posted a simple yet somehow not obvious idea on his blog: He uses Blosxom to automatically generate feeds for software which hasn't feeds, in this case the network monitoring system Nagios, so that he get's all Nagios events delivered to his feed reader.

A similar yet local use of this idea is to let blosxom or a wrapper script be called by your feed reader directly. Liferea (GUI, GNOME) and Snownews (text-mode, ncurses) have this feature and there is already a big repository of plugins. The same way as those plugins are called, you can easily use blosxom as a plugin to those two feed readers so you don't need to care about how to generate RSS, blosxom does that for you. You just need to set the environment variable PATH_INFO to /index.rss before, e.g. by calling blosxom like this: env PATH_INFO=/index.rss blosxom.

That way I currently monitor the NVidia Unix Drivers Portal Page for changes, using this script, the libwww-perl (LWP), wdiff, a little bit of Perl glue and of course Blosxom. (In this case I use Debian's version of Blosxom which is able to have several configuration per installation by adding a -f flag for config files.)

I was trolling the MailingList and noticed a very good tip from a certain Peter G (website, Peter, so I can link to you?). He was trying to install a plugin that had certain Perl module dependencies, but maybe because he didn't have access to the server error logs he couldn't figure out which modules were missing.

So he added this line to his blosxom.cgi which then dumped the errors into the web browser, making for easy diagnosis:

use CGI::Carp qw(fatalsToBrowser);

It's an excellent and simple diagnosis tool, and we hope it helps others!

Here's a clever tip for creating a Drafts function for BXR.

I found this tutorial on how to customize the calendar plugin's CSS to get the look and feel you really want for your site. It is in Japanese, but most of it should be clear enough to suss the meaning for us non-Japanese speakers!

If you were ever interested in learning about CSS and using it in your web design, SiteProNews has compiled a list of the 10 Best Resources for CSS. A few of these are how I learned the basics, and a few of them are new to me. All of them are great sites!

Link via Slashdot.

Here's an interesting article describing how Todd Mintz learned how to make a SEO (Search Engine Optimized) blog and has some good tips if you want to go from being a general blogger (such as I am on my personal site) to being, well, a sort of idol. For the few (or many?) of you interested in becoming the Next Big Blogger^tm you should give this a read.

I thought I'd added this a while ago, but apparently not. One of the problems with the commenting system for Blosxom, whether your using writeback or another system, is that visitors cannot preview their comments in a manner that is easy to look at and review. Last year I ran across this hint on the always interesting MacOS X Hints site. The submitter, tinker, created a simple Javascript hack that creates a popup window with the contents of comment fields.

This code has been added to this site and you can give it a try by leaving a comment on any article on this site. I've modified the code slightly to reflect the look and feel of the UNBLUG. Download the code at the MacOS X Hints link or locally here (you may have to view the source on the local file to get the actual codebase).

On its own Blosxom uses the "last modified" information from your entry files (here after called entry.txt file for clarity) to figure out what date to use when rendering your blog. This works perfectly well for most people most of the time, but if you go back and fix a spelling error on a month old entry.txt file you'll notice it pops back to the top as if it were brand new. Another problem can be if you are moving from one hosting provider to another; a direct copy can change the "last modified" tag to the moment you copy the entry.txt files. This article attempts to address a few methods you can use to fix this problem drawing from a recent discussion on the MailingList and my own observations.

(click here to read more...)

If you are using a hosting provider where you cannot go in and edit your writebacks (to delete spam, for example, or double postings) then you could try this trick.

Create a second Blosxom installation with the wikieditish plugin as the only plugin. This second installation would use your main Blosxom installation's writeback directory as its own data directory.

If your primary installation's plugin state directory is:
$plugin_dir = "/absolute/path/to/primaryblog/plugins"
$plugin_state_dir = "$plugin_dir/state"

Then your secondary installation will use this info for its data directory:
$datadir = "/absolute/path/to/primaryblog/plugins/state"

You'll probably want to add the specific writeback directory in the state directory unless you want to be able to edit other files than your writebacks. It's probably best if you create a separate plugin directory for your secondary installation.

This technique works because the writeback directory is already owned by the www user, and wikieditish (through Blosxom) is run by the www user. Because the files are run and owned by the same system user you will be able to edit the files. Also, as long as you don't use a plugin such as entriescache in your second installation then anything new/recently modified will float to the top allowing you to quickly find new comments.

This method could also be accomplished using either BXR or Blosedit for the same reasons. Peter Richard, creator of Blosedit, has confirmed this technique works using Blosedit.

If you are using (or want to use) BXR and ecto to post to your Blosxom blog you might run into a problem where posting works but your html has the < character converted to < after you post. Read on for how I fixed this problem.

(click here to read more...)

Recently on the MailingList there was a question regarding the meta plugin and how it's used. Stu MacKenzie and Dirk Husemann stepped up to the plate to give their answers. They're so good, they're repeated below.

Stu's answer:

The meta plugin provides a common "namespace" where entry files can leave messages (perl variables) for plugins. The meta plugin scans the beginning of entry files for lines starting with "meta-"; the following bits represent "a_variable_name : some value". After storing your message in a variable, the meta plugin erases the "meta-" line from the entry, to keep the "meta-" thing from appearing on your page. Other plugins can then check these messages, and make decisions based on them.

For example, there are several "markup" plugins available, and they all use different notation systems. If you used kwiki notation in an entry file, you p'bly wouldn't want the Markdown plugin to also process the file. So you'd leave a message in that entry file:

meta-markup:kwiki

which Markdown can check before it starts to process that entry.

Note that nothing good comes of the meta plugin itself; other plugins have to want to make use of its messages. (You can't just add a line to an entry that sez: "meta-Do_Big_Things:magically" and expect some really cool Big Things to magically happen ;-) Plugins that make use of the 'meta' namespace will tell you so, usually in the configuration section up top; there will be instructions and examples of what meta-variables the plugin uses and what values it recognizes.

Dirk's answer:

i'll try... the meta-markup:something tag first is just a tag, it by itself does nothing to your text at all. for it to have an effect on your blog entry, you need to have the meta plugin installed - which introduces the concept of meta information: any meta-something tag gets translated into a $meta::something variable; thus, the meta-markup:kwiki line gets translated into a $meta::markup variable with a content of "kwiki" - then you need to have a plugin that will activate when it finds $meta::markup with content "kwiki".

on one of our websites we are using both the markdown and the textile2 plugins. by having a blog entry like

title line
meta-markup: markdown

bla bla bla story body here

we activate the markdown markup system on this blog entry, if we changed that to

title line
meta-markup: textile2

bla bla bla story body here

we activate the textile2 markup system instead.

If you have any further questions regarding the meta plugin send a message to the MailingList or leave a comment below!

Jason Clark posted a Perl script called scrub. It is designed to delete comment spam from "standard" writeback comment files.

scrub is designed to work with comment files created by the writeback plugin. These files contain each comment, along with the name and url of the poster as supplied on the posting form. I've modified my copy of writeback to also log the IP address. Any information in the comment file can be matched by the regex... so if you are logging IPs as I am, you can quickly find (and eliminate) all comments from a given IP. scrub overrides perl's $/ magic variable, which is the input separator. By setting $/ to "-----\n" (the comment separator in writeback files), scrub can process each comment as a single unit.

You can read the specific documentation and download the script from Jason's site here (local download here).

Apparently this has been out there a while, but I don't remember it hitting the MailingList. BlosxThis is another way to post stories to your Blosxom blog simply by sending email to a prearranged email address. It support various levels of security and a beta script even allows images to be included.

OxDecafbad has published a bookmarklet that allows you to post links to a Blosxom blog. Get the details here and read the comments which has more information.

Many thanks to Scott Mellgren for recommending the idea for this article!

Ever wish your site would attract more visitors? There are many tactics for achieving this. One of the many is to ping various web services to let them know your blog has been updated. Many people out there use these services to see who has similar interests, who's updating their blogs, to search for content on other blogs, or to see who is talking about what today. Using these services they may find your site and decide to visit.

Pinging essentially sends a very short message to the webservice saying, "Hey, I've got a new article up." What they do with that message varies. Some may list your updated article on a generic webpage while others might index the page for their search functions.

Here is a rather large list of webservices that accept pings compiled by Jeremy C. Wright. For redundancy they are listed below (click on "Click here to read more..." at the bottom for the complete list with links).

Pinging is, ideally, automated. Sometimes it has to be done manually. Blosxom has two (?) plugins that allow you to ping webservices.

ping_weblogs_com (local download here)
ping_weblogs_com_xmlrpc (local download here)

Both plugins require some configuration which is noted in the inline documentation. Eventually someone will write plugins that will work with some of the other services mentioned. Maybe that someone will be you!

There are several online services which you can use to "manually" ping various services, some of them in large groups. Ping-o-Matic is one such service. Fill in their form with the name of your blog and its URL, place check marks next to the services you want to ping and click the Submit Pings button. You'll even get a report of success and failure.

One of the benefits of pinging an online webservice is with many of them, one ping is all you ever really need to send. Once they are aware of your blog many will automatically visit your site.

Pinging various webservices is just one of many ways you may increase traffic to your site. Others include, but are not limited to, commenting on other sites, using trackbacks to get involved in online discussions, joining various blog referal programs, advertising, and simply writing awesome, topical articles of interest. Pinging is, however, one of the few automatic things you can do (if you use plugins) that requires no more effort on your part and can have great results.

(click here to read more...)

Blosxom requires you to fill out the $datadir and $plugin_dir variables with full paths. However sometimes, if you are hosting your site on your ISP or a hosting provider, the full path is not always readily available. If you have shell access to the server you could type pwd at the prompt to detirmine the path, but often this gives you a virtual path.

Stu MacKenzie has provided a simple CGI to help you figure out the full path. Put this file (changing the name to fullpath.cgi) in your CGI directory and make it executable. Then call it in your web browser:

http://yourdomain.com/cgi-bin/fullpath.cgi

You should see the full path to the CGI directory in the web page. From there you should be able to deduce the full path to your $datadir and $plugin_dir directories.

A while back on the Mailing List, Howard Jones posted a Perl script you can use to post entries via POP email, available to most everyone on the net. You can get the script here (or locally here). Instructions are in the file.

Not long afterwards Joseph Barillari posted a Python script to the list which does the same thing but allows for image files and attempts to maintain HTML entities. You can get the file locally here.

There are times when you will discover you cannot run a plugin without installing some particular Perl modules. Often you can simply ask your hosting service to install the missing modules, but sometimes you will find it necessary to do the dirty work yourself. (click here to read more...)

Jason Clark has written some entries (one, two and three) on how to get search engine robots to not index your main page but index your individual posts. Why would you want to do this? To get more precise indexing and search result in search engines like Google. "I've often noticed that Google searches of my site not only return individual posts, but also category and date archives... This tip should help alleviate the extraneous matches."

The tip requires the interpolate_fancy and Jason's storystate plugins. Here is the code he has supplied on his site:

<head>
  <!-- other head stuff like title omitted for brevity -->
  <?$storystate::blogroot>
    <meta name="robots" content="index,follow" />
  </?>
  <?$storystate::permalink>
    <meta name="robots" content="index,follow" />
  </?>
  <?$storystate::archive>
    <meta name="robots" content="noindex,follow" />
  </?>
  <?$storystate::category>
    <meta name="robots" content="noindex,follow" />
  </?>
</head>

How would you use interpolate_fancy to create "pretty" comments? (click here to read more...)