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
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
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
<a href="$url/$yr/$mo_num/$da#$fn">permanent link</a>
Since that was specifying that a
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.
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.
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">
Mon, Oct 07, 2013 7:40 pm
Today while checking the server's Apache error log file, I noticed error
messages that appeared to be related to
, 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
where someone reported similar error messages, I
found someone responding
the messages could be due to the absence of the
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
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.
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
plugin_dir, in the
section of the file, which is after the
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
<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.
Mon, Oct 07, 2013 5:16 pm
Perl Module XML::Parser
I installed the Perl module
, which is a Perl module for parsing
# 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
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
cpan> install Bundle::CPAN
cpan> reload cpan
199 subroutines redefined
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 list-modules.pl
script produces an HTML file as output. You can use
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
Another script that can be run from a shell prompt to show you the installed
Perl modules on a system is
find-modules.pl. To use it, you can change the permissions with
chmod and then simply use
Another means of checking for installed Perl modules is through
which was developed by Brian D.
Foy and which can be found at GitHub
be run at a shell prompt with
perl Lister.pm, after changing
permissions on the file, e.g.
chmod 755 Lister.pm, 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
cgi-bin directory on the server and renaming the file to
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
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
may not show modules that have been installed manually.
List Perl Modules
Date: November 28, 2005
How do I get a list of installed CPAN modules?
Date: September 22, 2008
The CPAN Search Site
Shop Amazon Local - Subscribe to Deals in Your Neighborhood