Merge remote branch 'smcv/ready/link-types'

fixed

Remove typedlink from [[ikiwiki/pagespec]]

It's not supported in this branch any more.

Auto-rebuild wikis on upgrade due to the taglink change

debian/NEWS and debian/postinst should be edited before release to have
an appropriate version number.

Revert spam

This reverts commit e496920e51ae9f0ecfbad5799634a5064193dcdb.

"Twice is enemy action"; enjoy your ban!

Revert spam

This reverts commit b29c50c731d17c83fef21ef606654ce3bde84310.

Nice try, no cigar.

nearly there!

comment

comment

comment

idea

first question

oops, branch returned now

more flexible underlays, please?

response

if applied, reverting this would be problematic

tag as patch

pages talking about escaping should really be escaped correctly

as seen on IRC

switch branch for review to use ready/foo convention

ready for review, I think

fix bug that left stray </p> tags

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.

txt: Add a special case for robots.txt.

comments: Fix missing entity encoding in title.

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.

response

potential performance improvements

speed

fix test suite

close bug, comment

more idiomatic perl

rename hash and avoid unnecessary hash ref

Variable renamed to be a bit more self-explanatory.
Probably more idiomatic perl to not use a hash ref when a hash can be used.

changelog

fix indentation & whitespace

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.

advertise some bugfixes

bug report + patch: unnecessary YAML::Any dependency

Typo.

Add the Banu website

Remove my homepage

updated branch

update fieldsort plugin to be compatible with the latest version of my branch

Add a unit test for changed-link calculation

Remove the typedlink(tag foo) pagespec feature, which is less friendly than tagged()

Plugins that introduce a link type should also introduce pagespec syntax
for it.

Remove tagged_is_strict option, and just behave as though it was enabled

Jon was worried about the backwards-compatibility break involved in making
tagged() not match non-tag links, but Joey seems less concerned about it.

Fix some typos that would break Render during changed-link calculation

implement typed links; add tagged_is_strict config option

answer about autofiles for tags

link to commits

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.

add news item for ikiwiki 3.20100403

releasing version 3.20100403

fix buggy program installation code

updated branch

response

response

cross-reference

vague musings about wikilinks

perhaps the typedlink(tag foo) pagespec isn't so useful

reduced difference

sort-order could usefully be overridden for meta author, too

actually I can see a second use for "nonlinear" syntax - but I don't think it's worth it

make questions to Joey more explicit

respond at some length

respond (also unindent Joey's review to avoid very deep indentation)

idea

comments

minor comment

fix branch name

qualify template_file

template: Search for templates in the templatedir, if they are not found as pages in the wiki.

review from the woods

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.

Despam, again. Someone ban adrianna please?

Despam

implemented!

Explain tab-delimited tables a bit better

considering tags and fields

response; thoughts about inline and tags

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.

response

they do work, with the right syntax (C backslash escapes aren't interpreted)