|
2005-12-18
New: DWiki can generate Google Sitemaps
I added the ability for DWiki to generate Google Sitemap format XML
files, using the view 'sitemap'. The information included is very basic
currently: just the URL for each file page, all of them set to priority
0.8 (in the hopes that Google will decide that all of the directories
are priority 0.5 and prefer returning file page results).
Google does not say what Content-Type you should return sitemaps
in, so I have opted for 'application/xml'.
In the future, something as elaborate as Atom rendering may be
done. For now, everything is hardcoded in the sitemap::minurlset
renderer.
Updated: now directories are shown too, at priority 0.6. This feature
is clearly going to be in flux for a while.
2005-09-24
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.
2005-09-15
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 a atom::autodisc renderer 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?)
2005-09-14
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.)
2005-09-12
New: feed-max-size and feed-max-size-ips
This 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-size is 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 for atomfeed-display-howmany. If unset, there is no size
limit.
feed-max-size-ips restricts feed-max-size to the whitespace
separated list of IP addresses or tcpwrappers style IP address
prefixes (eg '66.150.15.' to get all of 66.150.15.*).
Syndication fetches from other addresses will behave as if there was
no feed-max-size.
Strictly speaking, feed-max-size limits only the size of the
atom::pages or atom::comments output 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-size a 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.
2005-09-03
New: /oldest/ virtual directory restriction
DWiki 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 conditional GETs be served new pages. But since the
conditional GET logic 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.
2005-06-14
New: Page Titles
Pages now have accessible 'titles', sort of. A page's title is taken
to be the value of the header that starts the page, if said header is
on the very first line. (So this page's nominal title is 'New: Page
Titles'.) The header level doesn't matter; a <h6> is as good as a
<h1>, so long as it's the first line on the page.
This info is available only after the page has been rendered, in the
new global context variable :wikitext:title. Fortunately for us,
Atom feed entries can have their fields in any order, so we are free
to generate <title> after <content>.
Why did I do this? First, it's suitably low rent, and second I decided
I wanted some vague way to generate semi-real page titles in Atom
feeds instead of the current full path to the page (ever so helpful
and informative as it is).
The only tricky bit was making sure that only the appropriate magic
wikitext renderers set the page title, and not all the times that we
spin through wikitext looking for, eg, permissions. (Especially
important in Atom feeds, as Atom feeds look at everyone's permissions
before they do the real rendering.)
2005-06-11
A DWiki page (technically, any wikitext, so comments too) can now
start with the line '#pragma pre' to declare that the entire rest of
the page is simply preformatted text and should be barfed out as such
(minus the #pragma line, which is swallowed). '#pragma plaintext' is
accepted too.
This is a much more convenient and maintainable way to stick plaintext
files (such as program source or something) into a DWiki than
indenting the entirity of their text one space.
Note that this does not make the page come out as text/plain. The page
is still text/html and fully templated, it's just that the wikitext is
one big <pre> lump, instead of more sophisticated formatting.
It's unlikely that DWiki will acquire any other sorts of pragmas (eg
to say 'format this as nicely HTML-ized Python code'), partly because
ChrisSiebenmann is dubious about the 'nicely HTML-ized' bit of any
formatters since they invariably involve aesthetic decisions that
people (eg, him) can and do object to. Having an easy way of including
plaintext is the 80%-90% solution, and that is the DWiki way.
2005-06-10
DWiki has a new template handling scheme: the core idea is that we now
have a way of a) picking the first existing template from a list of
them and b) generating candidate templates by variable substitution
and 'all parent directories' expansion. This gives DWiki a simple and
general framework for doing things like 'template injection', which
lets us skin an entire directory hierarchy (but not the entire wiki)
with things like blog sidebars.
This also gives us a single top-level template that generates all
normal HTML-based pages, thereby giving us a single place to skin the
entire site. The per-view templates in views/* (now only a
convention) now just generate view-specific information, leaving all
of the rest up to the top-level template.
The clarity and lack of stupid template piece duplication of the
result is a clear indication of how it is a better scheme. (And no
more silly things like splitting a <div> start and end into different
files and hoping they get included in the right spots.)
TemplateSyntax and TemplatesUsed have been revised
appropriately.
|
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.
|