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>
<br>
<br>
$body
<p>
[<a href="$url$path">$path</a>]
<a href="$url/$yr/$mo_num/$da#$fn">permanent link</a>
</p>
</div>
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
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
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
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/XML/Parser.pm
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
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,
list-modules.pl. To use the script change the permissions on it so
that it can be executed with
chmod 755 list-modules.pl. The
script produces an HTML file as output. You can use
perl
list-modules.pl >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
find-modules.pl. To use it, you can change the permissions with
chmod and then simply use ./find-modules.pl.
(example output).
Another means of checking for installed Perl modules is through
Lister.pm,
which was developed by Brian D.
Foy and which can be found at GitHub
at app-module-lister
(example output).
Lister.pm can
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
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
/usr/lib/perl5/vendor_perl/5.8.8/LWP/Simple.pm
Note: The perldoc method will show modules installed via
CPAN, but
may not show modules that have been installed manually.
References:
-
List Perl Modules
Date: November 28, 2005
MoonPoint Support
-
How do I get a list of installed CPAN modules?
Date: September 22, 2008
Stack Overflow
-
App-Module-Lister
The CPAN Search Site
[/languages/perl]
permanent link
