This is a log of new features of note in DWiki.
DWiki now has a simple hierarchical way of handling access to pages for various things (both access and commentability), so you can give (or take away) permissions for things to entire directory trees at a shot. We use a simple implementation where directories can have a magic file called
__access
, which creates default permissions for everything under them.
DWiki now has an extremely low-rent generic from-the-web search functionality. It's so low-rent I'm not sure I'm going to keep it, but we'll have to see.
As part of the fallout of other work, I fixed the nit where 'View Source' would show as a page tool on pages where viewing the source would get you a permission or unavailability error.
With blog-style things now decently supported, there is the problem that some pages want to be longer than is comfortable for display in a blog setting. Now wikitext can signal that only the front should be shown in some contexts, like so:
Directories can now have default view types associated with them, by the simple yet sleazy method of touching a file in them called
.flag.prefview:<viewname>
.This lets us auto-set a directory to default to a blogdir view.
The page tools now autogenerate a list of 'See As <whatever>' links for alternate directory formats.
This required some innards magic to distinguish a normal view being explicitly specified from no view being specified and us just defaulting to a normal view.
Directories can now be displayed as a 'blogdir', which treats the files in the directory as if they were blog entries: they are sorted by modification time, most recent first, and then they are all displayed inline with a title.
A chunk of this behavior is controlled by templates and new renderers. 'blogdir' is a new view, only valid for directories, which uses
blogdir.tmpl
. Theblog::blogdir
renderer does the direct expansion, running each file through the templateblog/blogentry.tmpl
.There are also new renderers for the new blog-like time format and for showing the owner of a file. (Currently the Unix and/or RCS owner.)
This is ... how shall we say it ... not hugely scalable over the long run in terms of time structure and number of entries.