intrigeri [Tue, 30 Dec 2008 22:00:46 +0000 (23:00 +0100)]
po: remove renamed pages special handling, not needed anymore
Thanks to the new rename hook behaviour, the whole renaming work is now done
by the rename plugin, and we don't need to remember which pages were renamed.
Joey Hess [Fri, 26 Dec 2008 21:08:33 +0000 (16:08 -0500)]
inline: Run format hook first
inline has a format hook that is an optimisation hack. Until this hook
runs, the inlined content is not present on the page. This can prevent
other format hooks, that process that content, from acting on inlined
content. In bug ##509710, we discovered this happened commonly for the
embed plugin, but it could in theory happen for many other plugins (color,
cutpaste, etc) that use format to fill in special html after sanitization.
The ordering was essentially random (hash key order). That's kinda a good
thing, because hooks should be independent of other hooks and able to run
in any order. But for things like inline, that just doesn't work.
To fix the immediate problem, let's make hooks able to be registered as
running "first". There was already the ability to make them run "last".
Now, this simple first/middle/last ordering is obviously not going to work
if a lot of things need to run first, or last, since then we'll be back to
being unable to specify ordering inside those sets. But before worrying about
that too much, and considering dependency ordering, etc, observe how few
plugins use last ordering: Exactly one needs it. And, so far, exactly one
needs first ordering. So for now, KISS.
Another implementation note: I could have sorted the plugins with
first/last/middle as the primary key, and plugin name secondary, to get a
guaranteed stable order. Instead, I chose to preserve hash order. Two
opposing things pulled me toward that decision:
1. Since has order is randomish, it will ensure that no accidental
ordering assumptions are made.
2. Assume for a minute that ordering matters a lot more than expected.
Drastically changing the order a particular configuration uses could
result in a lot of subtle bugs cropping up. (I hope this assumption is
false, partly due to #1, but can't rule it out.)
Simon McVittie [Sun, 21 Dec 2008 16:32:44 +0000 (16:32 +0000)]
openid: in &openiduser, let domain-style providers have arbitrarily many subdomains
This leads to better display for OpenIDs like smcv.pseudorandom.co.uk
and thm.id.fedoraproject.org (to take a couple of examples from the
IkiWiki commit history).
Joey Hess [Sun, 21 Dec 2008 01:55:38 +0000 (20:55 -0500)]
avoid storing transient state in pagestate
None of the comment state needs to be stored through the a later run of
ikiwiki, so move it all from pagestate to a more transient storage.
This is assuming that we'll never want to add pagespecs to search against
the comment state. Pagespecs like author() are why the meta plugin does
store its meta data in pagestate -- the data can be needed later to match
against.
Joey Hess [Sat, 20 Dec 2008 23:36:16 +0000 (18:36 -0500)]
tweak author display
Put the icon after the name, mostly because it scans better on
non-graphical browsers where the alt text is displayed. And because the
name is really the more important part.
Joey Hess [Sat, 20 Dec 2008 23:30:14 +0000 (18:30 -0500)]
my try at improving comment styling
Makes it look more like a blog, but not enough to be confusing, and with
nothing as large as in a blog. Removal of the vertical line under the
subject imho makes it easier to scan through comments as each box is a new
one. Bolding the subject seems to make it stand out enough, especially as
its a link now. (Also considered increasing its font size to 110%.)
Simon McVittie [Thu, 18 Dec 2008 20:28:41 +0000 (20:28 +0000)]
comments_display: display (?) for anon users, {x} for OpenIDs and {*} for local logins
This is a mockup of Joey's idea; to do it properly, the icons should
move to the basewiki or to a comments underlay, and {x} should be
replaced with an OpenID logo (if one with clear licensing even exists).