MoonPoint Support Logo


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals

Advanced Search
Sun Mon Tue Wed Thu Fri Sat

Mon, Oct 07, 2013 8:46 pm

Main Id element in Blosxom's story.html

I upgraded Blosxom today from version 2.0 to 2.1.2. I normally validate the HTML code in webpages and blog entries I've created with the W3C Markup Validation Service, which is a free service provided by the World Wide Web Consortium (W3C) for verifying that HTML code in a file you upload to the service, or at a URL you request be checked by the service, is correct. I've always gotten errors similar to the one below when I've checked blog entries, but have never taken the time to figure out how to fix the problem, which I thought was in the Blosxom Perl code.

Line 210, Column 10: ID "MAIN" already defined

<div id="main">

An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).

I still got those errors when checking blog entries with the new version, but decided that I should deal with the problem at last. I found that the problem was within the story.html file I was using for Blosxom. I hadn't changed that file when I upgraded Blosxom. The file had the following contents:

<div id="main">
<a name="$fn"><b>$title</b></a>
[<a href="$url$path">$path</a>]
<a href="$url/$yr/$mo_num/$da#$fn">permanent link</a>

Since that was specifying that a <div id="main"> be used for each blog entry, whenever I would check a Blosxom blog page with multiple entries, at least one of the error messages would be reported by the W3C Markup Validation Service, since "id=main" should appear only once within a webpage since it should specify a style in CSS for a single, unique element on a page. If there were 10 entries on a page, then I would see 9 such error messages reported.

So I changed "id=main" to "class=main", since unlike "id", the class selector is used to specify a style for a group of elements on a page - see The id and class Selectors for an explanation of the two elements.

In the style.css file I specified for the blog in the head.html file for Blosxom, I inserted the following line just to have something there that I could alter later if I wanted to format entries differently. There hadn't been an element for "main" there previously.

div.main {text-align:left;}

In the head section of the head.html file, I had the following line to bring in the stylesheet I use for the blog.

<link rel="stylesheet" href="/css/style.css" type="text/css">

[/network/web/blogging/blosxom] permanent link

Mon, Oct 07, 2013 7:40 pm

Blosxom upgrade

Today while checking the server's Apache error log file, I noticed error messages that appeared to be related to Blosxom, which I've been using for this blog, which runs on a Linux server, for almost 9 years now. I found the error messages had been occurring since at least the beginning of the year and they may have been occurring for a much longer period. When I checked on the error messages, I found a February 3, 2013 posting at [Blosxom] server error where someone reported similar error messages, I found someone responding here that the messages could be due to the absence of the XML::Parser Perl module. The responder mentioned that the module is reqiured by the atomfeed plugin, which I don't use. His message also referenced the categories plugin, which I don't have, either. But I thought I would check on whether the XML::Parser module was present on the system. It wasn't, so I installed it, but that didn't stop the error messages from occurring in the Apache server's log file. I then noticed that Blosxom was not up-to-date. I had version 2.0 on the system while the current version is 2.1.2.

Blosxom is available from SourceForge at blosxom :: the zen of blogging. Upgrading from the 2.0 version to the 2.1.2 version was very easy. I made a backup copy of the existing blosxom script in case anything went wrong. I then unzipped and untarred the gunzip blosxom-2.1.2.tar.gz file I downloaded.

gunzip blosxom-2.1.2.tar.gz
tar -xvf blosxom-2.1.2.tar

The only file I needed was the blosxom one, which I edited to set the configurable variables, which are at the top of the file, to those I had for the 2.0 version. I also set the plugins directory variable, plugin_dir, in the Plugins (Optional) section of the file, which is after the Configurable variables section, since I'm using a calendar plugin for Blosxom. I then copied the new blosxom file over top the old one and then verified that the blog was still working as it had been.

When I checked the latest blog entry with the W3C Markup Validation Service, which allows one to verify that a webpage is coded correctly in HTML, I saw the warning below:

Character Encoding mismatch!

The character encoding specified in the HTTP header (utf-8) is different from the value in the <meta> element (iso-8859-1). I will use the value from the HTTP header (utf-8) for this validation.

The issue was reported as a warning rather than an error and shouldn't effect the display of entries in anyone's browser, but I thought I should fix it. I found the following line in the head.html file for Blosxom.

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

I replaced it with the following line:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Since I didn't change head.html as part of the upgrade, that issue has likely always been there; I don't know why I never noticed it before when checking blog entries with the W3C Markup Validation Service.

The upgrade didn't eliminate the error messages in the Apacehe server log file, but at least I am now at the current version of Blosxom.

[/network/web/blogging/blosxom] permanent link

Mon, Oct 07, 2013 5:16 pm

Perl Module XML::Parser

I installed the Perl module XML::Parser, which is a Perl module for parsing XML documents.
# perl -MCPAN -e shell
Terminal does not support AddHistory.

cpan shell -- CPAN exploration and modules installation (v1.7602)
ReadLine support available (try 'install Bundle::CPAN')

cpan> install XML::Parser
cpan> exit

After exiting from cpan, I checked on the module installation:

# perldoc -l XML::Parser

During the installation I was advised that a later version of CPAN was available for the system, so I updated it as well, which took quite awhile. I accepted the default answers for all of the yes/no questions posed during the installation.

cpan> install Bundle::CPAN
cpan> reload cpan
199 subroutines redefined

cpan> exit

[/languages/perl] permanent link

Mon, Oct 07, 2013 4:53 pm

Which Perl modules are installed on a system

There are a number of methods you can use to determine which Perl modules are installed on a system. I use a script, To use the script change the permissions on it so that it can be executed with chmod 755 The script produces an HTML file as output. You can use perl >list-modules.html to produce the file or you can put the script in your cgi-bin directory on a webserver and access it via a browser to see the installed modules on the system (example output).

Another script that can be run from a shell prompt to show you the installed Perl modules on a system is To use it, you can change the permissions with chmod and then simply use ./ (example output).

Another means of checking for installed Perl modules is through, which was developed by Brian D. Foy and which can be found at GitHub at app-module-lister (example output). can be run at a shell prompt with perl, after changing permissions on the file, e.g. chmod 755, or you can also make the results available through a webpage, for instance, if you don't have access to a shell prompt on a webserver via SSH, by putting the file in a cgi-bin directory on the server and renaming the file to something like Lister.cgi, if scripts need the .cgi extension on the server. It can provide version information for some modules.

Another method is to use the perldoc module_name command, if perldoc is installed on the system. You should see documentation information if a module is installed, but the message "No documentation found for module_name", if the module isn't installed.

$ perldoc XML::Parser
No documentation found for "XML::Parser".

You can also use the -l argument to perldoc, which will report the location of the file for the module, if one is present or also report "No documentation found", if the module can't be found.

# perldoc -l LWP::Simple

Note: The perldoc method will show modules installed via CPAN, but may not show modules that have been installed manually.


  1. List Perl Modules
    Date: November 28, 2005
    MoonPoint Support
  2. How do I get a list of installed CPAN modules?
    Date: September 22, 2008
    Stack Overflow
  3. App-Module-Lister
    The CPAN Search Site

[/languages/perl] permanent link

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo