This is a log of new features of note in DWiki.
New: https:// now supported in plain text
As part of fixing Atom feeds to not break embedded https:// urls, I decided that we should support plaintext https:// URLs, like say https://bugzilla.redhat.com/.
DWiki should now support non-HTTP URLs much better in general (before, there were a number of problems and issued). You can even include mailto: links if you really want to.
New: Atom feed autodiscovery
There's a standard for autodiscovery of Atom feeds, involving
<link rel="alternate" type="application/atom+xml" href="...">element in your<head>. Now DWiki has aatom::autodiscrenderer to create them.The current code only generates 'recently changed pages' Atom feed links, and so disappears entirely when there isn't one. In theory one can have multiple autodiscoverable feeds (the first is the default, and they get
title="..."elements), but I don't quite feel like being that daring just yet.(I am also not confidant that clients have the UI issues involved sorted out. I'm not sure I have the issues sorted out; for example, should file pages have only the comment feed in the autodiscovery, or should they also have the recent changes for their directory feed in? Which better matches practical user expectations? Can I expect users to be aware of the difference between directory pages and file pages?)
New: linktocomments renderer
This is a little new renderer that creates a link to a page in the view necessary to show comments. In turn, this has caused the 'your comment has been posted' template page to be tarted up so that it uses it, thereby letting people who have posted comments see them in the page they go to.
(I have decided not to have it link to the comment section of the page, just on general principle. I may change my mind about this.)
New:
feed-max-sizeandfeed-max-size-ipsThis is all because LiveJournal has undocumented size limits on incoming syndication feeds, limits that DWiki can easily blow past. Since I actually wanted LiveJournal to be able to get syndication feeds from me, DWiki has grown two new configuration settings.
feed-max-sizeis an integer kilobytes. It is a rough limit on how large any feed can be; once DWiki generates a feed that is this many kilobytes or larger it stopps adding more entries, regardless of the setting foratomfeed-display-howmany. If unset, there is no size limit.
feed-max-size-ipsrestrictsfeed-max-sizeto the whitespace separated list of IP addresses or tcpwrappers style IP address prefixes (eg '66.150.15.' to get all of66.150.15.*). Syndication fetches from other addresses will behave as if there was nofeed-max-size.Strictly speaking,
feed-max-sizelimits only the size of theatom::pagesoratom::commentsoutput to that size. Whatever else is tacked on to make up a feed (hopefully not very big) will add some extra size.Moral: undersize
feed-max-sizea bit. For LiveJournal, the limit is apparently 150 kilobytes (currently), so setting it to '120' or so should provide a comfortable safety margin.Although I'm not entirely fond of this (to put it one way), the documentation has been updated appropriately, making this feature more or less official.
New:
/oldest/virtual directory restrictionDWiki has long been able to give people the latest N things in a virtual directory context (as
latest/<N>). Now it can give them the oldest N things, using the obvious syntax:oldest/<howmany>.Just to show off, ranges properly convert themselves into 'oldest/<N>' at the end of their run, just as they convert themselves into 'latest/<N>' at the start.
Documentation has been updated appropriately.
New: Better Last-Modified handling
Over the past while it has become increasingly obvious that it's useful for as many responses as possible to carry a
Last-Modified:header. (The last straw was wanting Google's index to show modification dates for DWiki pages.)My reason for killing
Last-Modified:was so that things like logging in and logging out, which can't be reflected in the timestamp, would still have conditionalGETs be served new pages. But since the conditionalGETlogic is in DWiki itself, I can have DWiki be smarter about it.DWiki now separates the page timestamp from the idea of whether the page timestamp is reliable or simply vaguely useful information. The page timestamp will always be served if it exists at all, but conditional
GETs only look at the page timestamp if it's reliable (which means that if authentication is on, the answer is generally 'not').This should work much better.