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.
|