It’s finished! See this post for more information, docs and download.
This is now pretty much ready for release: just a last check for suggestions and bugs. It now supports the whole spec apart from
, which seems aimed at aggregators rather than bloggers, and
, which could easily be implemented if desired using the meta plugin.
- Moved from using
relattributes in HTML anchors to identify enclosure/via/related links to include in the feed. Just use the appropriate
relvalue – there’s no need to include the “atom-” prefix any longer.
- Support for
. This uses a technique similar to that used by the foreshortened plugin. It is excluded from the default templates in favour of a full-text
element. I’ve temporarily placed the
are now available as user-configurable variables.
- Documentation is now included in the plugin – use
perldocor read directly.
- Includes support for a stylesheet, like in the original 0.3 version. Excluded by default. You can also specify the MIME tpye of the stylesheet.
As before, comments to the mailing list please.
- enlcosure: In the body of your post, link to a file you would like to appear in your atom feed as an enclosure. Make sure this link has a
classattribute of “atom-enclosure”. For extra points: if you have access to the LWP perl module, set the configurable variable
$use_full_enclosuresto “1” and atomfeed will attempt to find the content-type and length of your enclosure. (Test: This little audio file should appear in my post as an enclosure. The code for this link looks like this:
This little audio file)
- via: To include a link from your post in your atom feed as
, give it a
classattribute of “atom-via”
- related: similar to via, simply give a link a
classattribute of “atom-related” for it to appear in your atom feed as an appropriate
Note: using the
class attribute to identify these links may change in future versions.
Changes in this version (also posted to mailing list) based on suggestions from Stu MacKenzie:
- typo corrected
XML::Parseris now a
requirerather than a
use– those who don’t have this module can now use the plugin with the consequence that their entries will never be labelled as xhtml, only text or html, regardless of validity/well-formedness.
- Regular expression for guessing text vs. mark-up is now:
m!?[a-zA-Z0-9]+ ?/?>!This should hopefully catch pretty much anything that resembles mark-up.
- The check in the
start()sub for preloaded templates is now
or‘d with the call to
_load_templates. I’m not even sure if this check is necessary, as it doesn’t appear possible for any user-defined templates to have been loaded by this stage anyway, unless someone else knows better?
Major Revision: atomfeed-beta-3
Since posting this entry, I have made a number of changes to the plugin. It now contains support for the following additional elements:
Also, it checks
$blog_description and each post’s
$title for markup by looking for
left-side angle brackets anything matching the regular expression
/<[a-zA-Z0-9]+>/. If it finds a match, it assumes that the variable contains markup and parses it as such, labelling it either html or xhtml depending on well-formedness.
You can download the new version here. The link below continues to point to the original version. Documentation is still not finished, but the code is commented. I’m particularly interested in feedback on the
I’ve updated the atomfeed plugin for Blosxom to emit a basic Atom 1.0 feed. It’s in beta; you can download it here. I’m running the plugin, so if you like you can see it in action by checking my Atom feed; the feed’s been checked with feedvalidator.org‘s new Atom 1.0 support. Here are the notes I posted to the blosxom mailing list:
The feed is very basic: only the required elements along with a feed-level
pointing at the feed, a
element (updated 2005-07-21, but it was always in there), and each
as well as an
I have not yet updated documentation in the plugin. I’m making it available so that anyone interested can take a look and make suggestions before I start looking at adding more support for optional elements and doing some other bugfixes. When I’m happy with it I’ll re-write the docs, remove the BETA flag and post some instructions on my site. Until then, use these notes as guidance if you want to use or test the plugin:
$feed_yris now a configurable variable that MUST to be set to the year you want to see in your feed level
element. This should be set once and then never changed.
is derived from the timestamp in
(entry level) is derived from a
stat()->mtimeon the actual file. For these two elements to work as intended, you really should be running entries_cache or similar, otherwise they will be the same.
- entry level
‘s are derived from
%blosxom::files. Again, for maximum conformance – to guarantee the
tags never change – is currently to use entries_cache or similar.
- I decided not to worry about sniffing for plaintext entries as it seems to me that most blosxom users will have markup in their entries, so the mechanism for determining the type of
has remained bascially the same (UPDATED – see below).
- I am still assuming that
$blog_descriptioncontain only plaintext and no mark-up whatsoever.
- the feed-level
element must appear before the
s, so I’ve taken the method used in the rss10 plugin to insert it in
$blosxom::outputin the foot subroutine using a placeholder.
Update 2005-07-21 (1)
I’ve removed the code that conditionally placed some HTML content into a
CDATA section. ALL content identfied as HTML will now be escaped.
Please direct comments to the blosxom mailing list.