On the MailingList, a frequently asked question is, how to prevent that a posting moves to the top of the blog because with a modification (e.g. a fixed typo) the modification date of the file changed and blosxom uses this file as the posting date.

This article shall outline the solutions to this problem, which were suggest in the thread started with this mail on the MailingList.

• Letting blosxom remember when it first saw this posting and let it keep that date by using a plugin.
• Setting the date through meta data inside the article or the article's file name and let a plugin tell blosxom that date.
• Setting the date through meta data inside the article or the article's file name and ressetting the file modification date after changes based on that data manually or by a manually called, local (shell) script.

We will focus on the first two concepts here.

The oldest and some kind of a no-frills plugin to preserve the posting time automatically is Rael's entries_index which caches the file modification time when it first notices a posting.

The plugin entriescache is based on entries_index and offers the same functionality, but also caches all story data for a configurable number of minutes and therefore reduces the number of accessing all posts on the harddisk to one access all few minutes.

Both plugins are also available in a variant which lets you set the time by including it as a meta tag into the post file: The plugin entries_index_tagged works like and is based on the entries_index plugin but allows to include date and time information in the Unix time stamp format (seconds since Jan 1st, 1970 00:00:00 GMT). You should install the meta plugin, too, to make this plugin work as expected.

The caching variant is the plugin entries_cache_meta. It has some more features, so it accepts at least one much more human readable date format thanthe Unix times stamp format and — if the Perl module Date::Parse is installed — all formats that module can parse.