* calendar: Shorten day names, and improve styling of month calendar.
* style.css: Reduced sidebar width back to 20ex from 30; the month calendar
will now fit in the smaller width, and 30 was feeling too large.
The key is using width: auto; overflow: auto; -- this allows the div(s) to the
left of the floating sidebar to be resized to fit next to it, and prevents
any clear: both from pushing the div down below the end of the sidebar.
Many thanks for the Hurd wiki's developers for originally figuring this out.
The edit page recently developed the same problem with its textarea, now
that a sidebar can appear on that page too. In editpage.tmpl I needed to
add a new div around the editcontent textarea, as the above styles cannot
be applied directly to textareas. The textarea's own width is reduced to
98% because at least in chromium this avoids it getting unnecessary
horizonatl scrollbars when a sidebar is displayed next to it.
http://bzed.de/posts/2010/05/new_css_for_bzed.de/
smcv: [10:59:01] is the logical thing you want a <div> whose meaning is "the bits the sidebar is allowed to accompany"?
bzed: [10:59:14] yeah
bzed: [10:59:58] then you could just ensure that this part is as high as the sidebar
smcv: [11:02:44] wrapping a <div> around the sidebar, content and comments seems like the way forward, then
The linktype check was being done on the relativised link target,
but %typedlinks uses the same link targets as %links, so that didn't work.
I think the bug only appeared when tagbase was not set.
This bugfix also let me factor out the common typedlink checking code.
To match calendars, which use local time. Particularly important at
the end of the month.
I checked the history, and there seemed no good rationalle for the
pagespecs to use gmtime.
Problem is that by the time rendering calls render_dependent, %pagesources
has had deleted files removed from it. So match_comment's lookup of
files in there to see if they had the _comment extension failed.
I had to introduce a hash that temporarily holds filenames of deleted pages
to fix this.
Note that unlike comment(), internal() had avoided this pitfall by being
defined to match both internal and non-internal pages.
* openid: Incorporated a fancy openid-selector signin form.
(http://code.google.com/p/openid-selector/)
* openid: Use "openid_identifier" as the form field, as required
by OpenID Authentication v2.0 spec.
test isinternal first, because match_glob with internal => 1 also returns
non-internal pages that match. This order should also be faster.
Remove test to see if pagesources is set. isinternal will not succeed if it
is not.
* comments: Comments pending moderation are now stored in the srcdir
alongside accepted comments, but with a `._comment_pending` extension.
* This allows easier byhand moderation, as the "_pending" need
only be stripped off and the comment be committed to version control.
* The `comment_pending()` pagespec can be used to match such unmoderated
comments, which makes it easy to add a feed of them, or a counter
indicating how many there are.
* Belatedly added a `comment()` pagespec.
Turns out that users with a modified page.tmpl need to modify it on
upgrade, at least to add the FORCEBASEURL (so edit preview works),
so there is no point in trying to retain compatability.
* Removed misc.tmpl. Now to theme ikiwiki, you only need to customise
a single template, page.tmpl.
* misc.tmpl will, however, still be read if a locally modified version
exists. This is to avoid forcing users to update page.tmpl right now.
This is a first pass, it avoids needing to change style.css
except where it refers to tag types.
This goes a bit off the rails at the pageheader with its nested header.
Semantically, there should be an article around the whole page
header, content, and footer. Just as there will be an article around a
whole comment or inlined page header, content, and footer.
But that will mean changing the css that currently refers to pageheader to
refer to the enclosing article instead.
* Ikiwiki can be configured to generate html5 instead of the default xhtml
1.0. The html5 output mode is experimental, not yet fully standards
compliant, and will be subject to rapid change.
Needed to handle the move of the .js files into ikiwiki/, but also this is
a longstanding bug.
Old pagemtime is not remembered in rebuild mode, and changing that would
need a lot of changes. So instead, loop on pagectime, which is remembered.
Change to remembering old pagesources info in rebuild mode. This seems safe
enough.
This is a slow implementation; it runs svn log once per file
still, rather than running svn log once on the whole srcdir.
I did it this way because in my experience, svn log, run on a directory,
does not always list every change to files inside that directory.
I don't know why, and I use svn as little as possible these days.
* Automatically run --gettime the first time ikiwiki is run on
a given srcdir.
* Optimise --gettime for git, so it's appropriatly screamingly
fast. (This could be done for other backends too.)
* However, --gettime for git no longer follows renames.
* Use above to fix up timestamps on docwiki, as well as ensure that
timestamps on basewiki files shipped in the deb are sane.
* Rename --getctime to --gettime. (The old name still works for
backwards compatability.)
* --gettime now also looks up last modification time.
* Add rcs_getmtime to plugin API; currently only implemented
for git.
* pagestats: Class parameter can be used to override default class for
custom styling.
* pagestats: Use style=list to get a list of tags, scaled by use like
in a tag cloud. This is useful to put in a sidebar.
* Rework example blog front page.
The meta title data set by comments needs to be encoded the same way that
meta encodes it. (NB The security implications of the missing encoding
are small.)
Note that meta's encoding of title, description, and guid data, and not
other data, is probably a special case that should be removed. Instead,
these values should be encoded when used. I have avoided doing so here
because that would mean forcing a wiki rebuild on upgrade to have the data
consitently encoded.
For a while, I was avoiding capitalizing ikiwiki at the beginning of a
sentence. I now think that's a bad idea (unless explicitly referring to
the `ikiwiki` command). Still, I don't go all the way and always cap it,
as a proper noun. That would make the logo look bad. ;)
I also tend to avoid capping it as IkiWiki, except when referring to the
perl internals, which do use that capitalization. (Too late to change
that.) However, it's also reasonable to do so in a WikiLink, as a nod to
historical camelcase wikis.
Colons are not allowed at the start of urls, because it can be interpreted
as a protocol, and allowing arbitrary protocols can be unsafe
(CVE-2008-0809). However, this check was too restrictive, not allowing
use of eg, "video.ogv?t=0:03:00/0:04:00" to seek to a given place in a
video, or "somecgi?foo=bar:baz" to pass parameters with colons.
It's still not allowed to have a filename with a colon in it (ie
"foo:bar.png") -- to link to such a file, a fully qualified url must be
used.
Since Firefox version 3, it's done aggressive caching of visited pages, and
does not, by default, check if the cached content is still valid when
reloading or revisiting a page. By default, Firefox seems to not re-contact
the web server at all. Compare with eg, Epiphany and Chromium, which appear
to always check, and get back a 304 when the page is unchanged.
This header makes Firefox do the right thing, at least for html files. It
still over-caches if css, javascript, images, etc, are changed.
The info is stored in the session database, not the user database.
There should be no reason to need it when a user is not logged in.
Also, hide the email field in the preferences page for openid users.
Note that the email and username are not yet actually used for anything.
The email will be useful for gravatar, while the username might be used
for a more pretty display of the openid.
Joey Hess
Joey Hess
Simon McVittie