NewFeatures: Recent Entries

2013-08-27

DWiki can now generate RSS 2.0 format syndication feeds for recently changed pages. This is a terrible hack that should not exist but ChrisSiebenmann has to deal with a few things that don't accept Atom format feeds, only RSS 2.0 feeds. RSS 2.0 page feeds are just like Atom page feeds and all Atom page feed restrictions and configuration options apply to them too. They are not advertised anywhere (either in page tools or in feed automdiscovery); to get access to them you must specify the feed URL directly, using the view name 'rss2' (as in http://you.cim/dwiki/?rss2).

See dwiki/view-rss2.tmpl and syndication/rss2entry.tmpl for what RSS 2.0 elements are used and how.

There is no RSS 2.0 feed for page comments.

(Because this is a hack, asking for the RSS 2.0 feed of VirtualDirs that are restricted such that they get redirections to the base directory, per AtomFeedsAndVirtualDirs, will get you a redirection to the Atom feed for that base directory. This is considered acceptable since people aren't supposed to be using those feeds anyways.)

Written 10:32:53 by cks.

2013-02-01

DWiki can now restrict what sorts of VirtualDirs advertise AtomFeeds (both in SyndicationDiscovery and in the Atom toolbar) and/or provide them if they're requested by URL.

It turns out that when you have a fair amount of content in a DWiki your VirtualDirs and thus your AtomFeeds proliferate like over-active rabbits. Then SyndicationDiscovery kicks in so that anyone who looks at a virtual directory can discover its Atom feed and either start polling it or just crawl it. Once your DWiki gets big enough this becomes not really a good thing, as Chris has found out with his techblog.

Read more »

Written 17:46:19 by cks.

2011-12-09

Directories can now say that they don't want to be rendered in specific view types. The usage case Chris has in mind is his techblog, where the blogdir view of categories is utterly huge because it renders hundreds of entries. Because this is intended to be a graceful gentle fix, trying to view a directory in a disallowed view generates a (permanent) redirection to the default view of the directory. To avoid redirection loops, this redirection only happens if the view has been specified explicitly as a URL parameter.

(For obvious reasons, disallowed views are also disallowed in virtual directories derived from a particular real directory.)

This is done similarly to DefaultDirViews: touch a file in the directory called .flag.noview:<viewname>. Unlike default views, this is not currently inherited by child directories.

The 'See As' page tools links also exclude disallowed view types. Right now they do so a little bit too thoroughly, in that they exclude the default view if it's also disallowed. Moral: don't do that, even though the code saves you from a redirection loop in this case.

Right now there is no restrictions on what (directory) views can be disallowed, so you can disallow Atom feeds. This is probably not a feature and will probably not be staying, although Chris may change his mind about this or just be lazy.

Written 13:43:38 by cks.

2011-06-01

New: various new configuration options

Not covered before now are various new configuration options that have been quietly added to DWiki over the five or so years that I have been using it as mostly a blogging engine. As you might expect, a bunch of these have to do with dealing with obnoxious clients of various sorts.

They are by and large documented in ConfigurationFile. I am not going to try to remember them here.

Written 10:09:45 by cks.

New: DWikiText has 'processing notes' (and better quoting)

These are directives that change how DWikiText is interpreted to do things like turn off certain font characters or map a simple-to-type character sequence like '->' to a HTML entity. They are documented in DWikiText so I am not going to repeat myself here.

In the process I added a new and less annoying plain quoting mechanism: ``...''. It looks better in ASCII than it probably does in the font here.

(The code for this was written in August of 2007 or so, but I sat on it because I wasn't entirely sure I liked the feature. Well, nuts to that; time to roll things out and just go.)

Written 10:06:13 by cks.

2006-04-08

New: directories can have an index 'page'

I've decided that sometimes I really want a directory to have an index page, not just a list of the contents. So now I can, with the unimaginatively named 'index' view. It's mostly template based; the normal template uses inject::index to display an __index file. However, the view has several special properties:

  • unlike other directory views, it is not inherited by subdirectories.
  • it is only listed as an available view in the page tools area if there is a file called __index in the directory.
  • if __index is a redirection, the index view will just generate a redirect to the target.

(Thus, the index view could be used to replace the wikiroot configuration directive.)

The index view is valid on directories even without a __index page in the directory. Right now the template just displays a normal directory listing in that case.

Written 19:56:37 by cks.

2006-03-25

New: #pragma search ...

I got tired of the relative links in my blog drafts (written in an entirely different directory than their eventual home) not working. So, introducing #pragma search; this adds additional directories to search for pages when resolving relative links, both WikiWords and explicit [[...]] links. The directories listed in a search pragma must be absolute path names, and are searched only after the hard-coded possibilities have been exhausted (including the alias directory for WikiWords).

You can't have both a #pragma search ... and a #pragma pre in the same page, partly because it doesn't make any sense. (This is the simple way of getting out of handling multiple #pragma directives.)

Written 23:30:58 by cks.

2006-03-22

New: optional disk-based caching

Having run out of other ways to really improve performance, I added a disk-based caching infrastructure to DWiki and then put in two caches.

The real cache is the renderer cache, which stores the results of selected renderers (currently just the wikitext renderers). Via some glue it's also used to store the results of the filesystem walk that's the expensive bit of blog::prevnext.

The Brute Force Cache is for dealing with Slashdotting style situations; it just caches complete requests for N seconds when the system seems to be under load. I also hijacked it as a convenient place to add extra caching for Atom feeds and to force this caching on software that doesn't do conditional GET.

(For more details, see Caching.)

This required a new storage pool class. Like the comment store, it uses a customized and restricted interface to write things (and a new interface to read them). The cache storage pool stores objects, not data blobs, using the cPickle module to make the swap back and forth. (This may be a mistake, but it's fast and easy.)

Since removing files in DWiki makes me nervous, I didn't bother to implement any sort of cache cleaning; you get to do that by hand. The cache has TTLs, and the renderer cache has validation layered on top of the cache object store, but when they detect something invalid they just ignore it. (On the other hand, the cache storage layer does use temporary files and rename(), so in a sense it's already removing files.)

In theory the cache interface is generic, so later I can hook up a memcached setup or something without having to change higher-level code.

Written 02:52:40 by cks.

2006-02-27

New: Text formatting via macros

I (ChrisSiebenmann) found myself with a genuine need for text set in HTML <strike>. Rather than try to invent a formatting setup for this that did not make me cringe, I just punted to the easy solution: macros that do text formatting.

So, DWiki now has grown the new macros:

  • ST for the font styles DWiki didn't already have.
  • C for character entities, and ShowCharEnts to show the named entities we support.
  • because I was there anyways, AB for <abbr>, so I could have those cute inline abbreviation expansion things. Tragically <abbr> is not supported by IE 6 and less, so AB may quietly change to generating <acronym> someday.
  • and finally, IMG to generate <img>. Width, height, and alt text is mandatory, and there is a hacky way to also roll title text in too. (Title text is optional.)

Through special black magic, ST, C, and AB can be used in comments (the omission of IMG is deliberate). In theory this lets a commenter cause character set explosions, but in practice a bad commenter can just write UTF-8 directly (UTF-8 is the common and only sane character set choice, so).

Implementing these as macros means that they have some limitations. You can't nest C, AB, or a differently styled ST inside an ST, and currently none of them can be done inside link text ([[....]]).

These macros are a bit of a hack. It's relatively easy to implement bits of HTML this way, but I'm not sure if it's good design overall.

Written 03:48:06 by cks.

2006-02-05

New: Previous and Next links in pages in blog views

The more I have used DWiki for a blog, the more I've realized that I want individual entries to be able to have Previous (entry) and Next (entry) links. At first I resisted because this would require an expensive filesystem walk on even individual page views, but I have now given in and made the blog::prevnext renderer, which will do this if I want.

blog::prevnext generates links directly to the pages, not to /range/N-N/ virtual directories, because I think that works better. (It would be less code the other way, but better links are worth the code.)

Written 02:23:02 by cks.

This is a log of new features of note in DWiki.


This is more text, so that we will run down the side of the page and I can see if things collide madly as they probably will. I hate layout.

[There's more, starting at 2005/12/18 or Previous 10]
(Previous day)
By day for August 2013: 27; before August.

Page tools: See As Blogdir, See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.