Daizu CMS

These are things which have occurred to me, and which I thought were worth writing down, but which might not be worth implementing. These are in no particular order.

• Authors and Atom/RSS feeds:

  • Should the identity of at least one author be required for articles which go in a feed? It is by Atom, so by making the author optional I'm currently forced to kludge in a pretend author called ‘Anonymous’.
  • Maybe it should be optional for author email addresses to be included in feeds? You could of course just not provide an address, but you might want it in the database for other reasons, and you might want to configure this differently for different feeds.

• Daizu::Plugin::PodArticle: probably switch to Pod::Simple. I also need to go through perlpodspec to make sure my plugin is compliant (which it definitely isn't yet). And I should make sure that the fragment identifiers and links that my code generates are compatible with other POD formatters.

• Perhaps it would be better to use Test::Pod for the tests in t/95pod.t instead of my own hack.

• Having removed the special value of none for the daizu:generator property, perhaps provide an actual class like ‘Daizu::Gen::NoPublication’ to prevent publication on part of the filesystem tree.

• Should I add any Dublin Core metadata to the HTML output? There's a specification for how that should be done. I'm currently only providing the old-school description and keywords values, from the dc:description and daizu:tags properties respectively.

• Perhaps extra metadata should be included in the body of blog articles in feeds, so that the information is visible even if you're just looking at the articles in a feed reader. This would only make sense for full-content feeds. Certainly things like the related links box which appear in the right-hand column could be usefully added. It might also be worth including the tags, if feed readers don't display them anyway.

• If it actually works in the most popular browsers, change the HeaderAnchor plugin to put its id attributes on the actual heading element, rather than adding an empty a element.

• Some parts of the Daizu code could be made more general and moved into separate CPAN modules. For example:

  • Daizu::Preview could become something like ‘Web::AdjustLinks’, with callbacks or subclassing used to decide what to do with the links when you find them. It would be handy for writing web spiders or link checkers.
  • Daizu::Plugin::PodArticle">, once I've improved its actual understanding of POD, could be turned into a much simpler Daizu plugin and a POD to HTML converter which returns its output as an XML DOM. I don't think that any of the many POD to HTML converters on CPAN can do that.
  • Daizu::Feed, perhaps with the RSS support removed. There are already modules for generating feeds, but are there any which output to an XML DOM structure instead of text? My code would have to be made a lot more flexible, and in fact I should do that anyway. Given the number of extensions available, some way of plugging in extra bits of metadata would be nice, so that Daizu plugins could be written to provide them.
  • Daizu::HTML has some useful stuff. Some of it might be better replaced with existing CPAN modules. There's code in there for serializing an XHTML DOM to HTML 4 or plain text, and for resolving relative links against a base URI (which is handy if you want to include content in an RSS feed or somewhere else out of context).
  • Daizu::Util has a collection of convenience functions for querying and updating the database. If that was tweaked to work with a few databases other than PostgreSQL it could make a nice little CPAN module.

• When adjusting preview links in HTML (in the Daizu::Preview module):

  • If the input is XHTML then so should the output be, and that means serializing empty elements in the right way.
  • Recognize links in the values of param elements for objects like Flash (with a parameter name of movie) and Windows Media Player (with a parameter name of filename) and the same name/value pairs as part of the embed element for those players.
  • Take notice of the HTML base element and perhaps also xml:base.

• Perhaps it should be possible to un-update a working copy, taking it back to an earlier revision.

• Some option to control the format of yearly blog archive pages would be nice, so that people who have thousands of articles per year can avoid listing them all on one page, and instead just link to the month pages. Or maybe provide paged archives?

• I think my redirect algorithm requires the content type to stay the same, but really it shouldn't matter in some cases, like redirecting an image from a GIF to a PNG.

• Take a look at the new SVN::Client API, and see if it provides a better way of accessing Subversion.

• Perhaps Daizu::Gen should generate blog-like index pages for directories which contain article files, so that you don't have to bother to write your own index page if it should just list the available articles. Of course if you provide an _index.html file then that would be published instead. I would have to take care to recognize pages to link to which are actually subdirectories, where the page the index links to might itself be an automatically generated index.

• Should the navigation menus make use of the rel-directory microformat?

• Currently daizu:guid values are always taken from the trunk. If the live WC is on a different branch, that might break things. But would anyone actually need to change the live WC from the trunk? Perhaps if you want to temporarily switch to a branch, and expect to switch back to the normal site later.

• An article loader plugin which turns an S5 slideshow into a normal article, with the standard site CSS and no special JavaScript. That would be a much better format for publishing talk slides. It would provide a link to the original S5 HTML to view as a slideshow.

  Problem: how do we tell this plugin to process an article? It would have to check every text/html page, and we might not want it turned on for every S5 slideshow, even if it could reliably detect when an HTML file is also an S5 file.

• A plugin hook which allows plugins to generate additional entries in redirect and ‘gone’ rewrite maps, or perhaps filter them to allow changes to Daizu's automatic redirects. There are situations when Daizu's automatic redirects won't be enough, so it would be nice if you could provide code to generate more. Sometimes a user might want to provide their own rewrite maps, and it would be nice if those could be stored in the content repository.

• How can I override a template for a single article without also overriding it for other files in the same directory. At least I'd like to be able to change it for, say, a site's homepage in an _index.html file without having it changed recursively for the whole site.

• Should I add some sort of support for ‘microsummaries’ in Firefox 2? Apparently you do this by publishing a small fragment of text at some URL, which should contain a short description to be shown in the bookmark for the page. For a blog this would be something like the time it was last updated, or the title of the latest article. The blog homepage would then have something like this in:

  <link rel="microsummary" href="microsummary.txt" />