Both markdown and tidy add paragraph tags around text, that needs to be
stripped when the text is a short, one line fragment that is being inserted
into a larger page. tidy also adds several newlines to the end, and this
broke removal of the paragraph tags.
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.
Lars Wirzenius [Sun, 4 Apr 2010 09:05:07 +0000 (21:05 +1200)]
Fix bzr plugin to work with bzr 2.0.
The output of "bzr log" seems to have changed a bit, so we change the
parsing accordingly. This has not been tested with earlier versions of
bzr.
Several problems seemed to occur, all in the bzr_log subroutine:
1. The @infos list would contain an empty hash, which would confuse the
rest of the program.
2. This was because bzr_log would push an empty anonymous hash to the
list whenever it thought a new record would start.
3. However, a new record marker (now?) also happens at th end of bzr log
output.
4. Now we collect the record to a hash that gets pushed to the list only
if it is not empty.
5. Also, sometimes bzr log outputs "revno: 1234 [merge]", so we catch only
the revision number.
6. Finally, there may be non-headers at the of the output, so we ignore
those.
slightly more consistent capitalisation of ikiwiki
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.
htmlscrubber: Allow colons in url fragments after '?'
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.
Joey Hess [Wed, 31 Mar 2010 21:51:46 +0000 (17:51 -0400)]
page.tmpl: Add Cache-Control must-revalidate to ensure that users (especially of Firefox) see fresh page content.
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.
Joey Hess [Mon, 29 Mar 2010 00:23:22 +0000 (20:23 -0400)]
don't check $@ after pagespec_translate
pagespec_translate may set $@ if it fails to parse a pagespec, but
due to memoization, this is not reliable. If a memoized call is repeated,
and $@ is already set for some other reason previously, it will remain
set through the call to pagespec_translate.
Instead, just check if pagespec_translate returns undef.
sipb-www / ikiwiki.git / log
