+ # Get the mime type.
+ #
+ # First, try File::Mimeinfo. This is fast, but doesn't recognise
+ # all files.
+ eval q{use File::MimeInfo::Magic};
+ my $mimeinfo_ok=! $@;
+ my $mimetype;
+ if ($mimeinfo_ok) {
+ my $mimetype=File::MimeInfo::Magic::magic($file);
+ }
+
+ # Fall back to using file, which has a more complete
+ # magic database.
+ if (! defined $mimetype) {
+ open(my $file_h, "-|", "file", "-bi", $file);
+ $mimetype=<$file_h>;
+ chomp $mimetype;
+ close $file_h;
+ }
+ if (! defined $mimetype || $mimetype !~s /;.*//) {
+ # Fall back to default value.
+ $mimetype=File::MimeInfo::Magic::default($file)
+ if $mimeinfo_ok;
+ if (! defined $mimetype) {
+ $mimetype="unknown";
+ }
+ }
+
+
+I found on [[plugins/filecheck/discussion/]] what [[users/DavidBremner/]] described as :
+> no way to detect text/plain using File::MimeInfo::Magic::magic()
+But I can't figure out if my issue is boarder and includes this or not..
+
+Any ideas , solve :) more that welcome.
+
+> [[done]], as isbear noted in [[discussion]], there was a bug that
+> prevented File::MimeInfo::Magic from ever being used. --[[Joey]]
diff --git a/doc/bugs/Slow_Filecheck_attachments___34__snails_it_all__34__/discussion.mdwn b/doc/bugs/Slow_Filecheck_attachments___34__snails_it_all__34__/discussion.mdwn
new file mode 100644
index 000000000..629aba71e
--- /dev/null
+++ b/doc/bugs/Slow_Filecheck_attachments___34__snails_it_all__34__/discussion.mdwn
@@ -0,0 +1,141 @@
+##Foreword :
+Disabling of filecheck is not actually possible because btw it cause the attachment.pm to malfunction and
+any of pagespec that could contain a *mimetype* condition.
+
+attachment.pm imports "statically" filecheck so actually disabling it should be *interdicted* .
+
+
+
+----
+
+## How bad is it ?
+
+So I tried on three pages to inline !mimetype(image/*) while I allowed attachment of mimetype(image/*)
+
+My profiling tests in the bug report shows that most of the time is spend in the "Fallback using file" block code,
+I tried to comment that block and see how it'll perform. Obviously this is much much faster ... but is the mimetype
+discovered using only *File::MimeInfo* ?
+
+
+Dumping some strings before return to STDERR, rebuilding . This is just a [[!toggle id="code-test" text="dumpdebug adding"]]
+
+[[!toggleable id="code-test" text="""
+
+sub match_mimetype ($$;@) {
+ my $page=shift;
+ my $wanted=shift;
+
+ my %params=@_;
+ my $file=exists $params{file} ? $params{file} : IkiWiki::srcfile($IkiWiki::pagesources{$page});
+ if (! defined $file) {
+ return IkiWiki::ErrorReason->new("file does not exist");
+ }
+
+ # Get the mime type.
+ #
+ # First, try File::Mimeinfo. This is fast, but doesn't recognise
+ # all files.
+ eval q{use File::MimeInfo::Magic};
+ my $mimeinfo_ok=! $@;
+ my $mimetype;
+ print STDERR " --- match_mimetype (".$file.")\n";
+ if ($mimeinfo_ok) {
+ my $mimetype=File::MimeInfo::Magic::magic($file);
+ }
+
+ # Fall back to using file, which has a more complete
+ # magic database.
+ #if (! defined $mimetype) {
+ # open(my $file_h, "-|", "file", "-bi", $file);
+ # $mimetype=<$file_h>;
+ # chomp $mimetype;
+ # close $file_h;
+ #}
+
+ if (! defined $mimetype || $mimetype !~s /;.*//) {
+ # Fall back to default value.
+ $mimetype=File::MimeInfo::Magic::default($file)
+ if $mimeinfo_ok;
+ if (! defined $mimetype) {
+ $mimetype="unknown";
+ }
+ }
+
+ my $regexp=IkiWiki::glob2re($wanted);
+ if ($mimetype!~$regexp) {
+ print STDERR " xxx MIME unknown ($mimetype - $wanted - $regexp ) \n";
+ return IkiWiki::FailReason->new("file MIME type is $mimetype, not $wanted");
+ }
+ else {
+ print STDERR " vvv MIME found\n";
+ return IkiWiki::SuccessReason->new("file MIME type is $mimetype");
+ }
+}
+
+"""]]
+
+The results dump to stderr (or a file called... 'say *mime*) looks like this :
+
+
+--- prepend signals the file on analysis
+xxx prepend signals a returns failure : mime is unknown, the match is a failure
+vvv prepend signals a return success.
+
+
+This is nasty-scary results ! Something missed me or this mime-filecheck is plain nuts ?
+
+*Question 1* : How many files have been analysed : **3055** (yet on a tiny tiny wiki)
+
grep "^ --- " mime | wc -l
+3055
+
+
+*Question 2* : How many time it fails : *all the time*
+
+ grep "^ xxx " mime | wc -l
+3055
+
+
+*Question 1bis* : Doh btw , how many files have been re-analysed ? ** 2835 ** OMG !!
+
grep "^ --- " mime | sort -u | wc -l
+220
+
+
+## Conclusion
+
+- Only the system command *file -bi* works. While it is **should** be easy on the cpu , it's also hard on the I/O -> VM :(
+- Something nasty with the mime implementation and/or my system configuration -> Hints ? :D
+- Need to cache during the rebuild : a same page needs not being rechecked for its mime while it's locked !
+
+
+--mathdesc
+
+> > if ($mimeinfo_ok) {
+> > my $mimetype=File::MimeInfo::Magic::magic($file);
+> > }
+>
+> That seems strange to me, `my` restricts scope of $mimetype to enclosing if block, thus, assigned value will be dropped - I think, it is the problem.
+> Try removing that stray `my`.
+>
+> --isbear
diff --git a/doc/bugs/Underscores_in_links_don__39__t_appear.mdwn b/doc/bugs/Underscores_in_links_don__39__t_appear.mdwn
new file mode 100644
index 000000000..b25dfb7fe
--- /dev/null
+++ b/doc/bugs/Underscores_in_links_don__39__t_appear.mdwn
@@ -0,0 +1,18 @@
+Observed behavior:
+
+When I create a link like \[[cmd_test]] , the link appears as 'cmd test'.
+
+Expected behavior:
+
+I would like to be able to create links with underscores. I realize this is a feature, and I searched for ways to escape the underscore so it would appear, but I didn't find any.
+
+> as a workaround, you can use \[[cmd\_\_95\_\_test|cmd_test]] (which will link to a page named "cmd test" at the url location "cmd\_test") or \[[cmd\_\_95\_\_test]] (which will link to a page named "cmd\_test" at the url location "cmd\_\_95\_\_test"). i would, from my limited understanding of ikiwiki internals, consider the bug valid, and suggest that
+>
+> * explicit link text be not subject to de-escaping (why should it; this would be the short term solution)
+> * escaped page names never be used in user visible parts of ikiwiki (in my opinion, a user should not need to know about those internals, especially as they are configuration dependant (wiki_file_regexp))
+>
+> note that in [[ikiwiki/wikilink]], that very behavior is documented; it says that "\[[foo\_bar|Sandbox]]" will show as "foo bar". (although you can't tell that apart from "foo\_bar" easily because it's a hyperlink).
+>
+> i assume that this behavior stems from times when wikilinks and [[ikiwiki/directive]]s were not distinguished by \[[ vs \[[! but by the use of whitespace in directives, so whitespace had to be avoided in wikilinks.
+>
+> --[[chrysn]]
diff --git a/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn b/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
index 3c28e379b..34eecef8c 100644
--- a/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
+++ b/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
@@ -22,3 +22,13 @@ Of course, the next time I rerun ikiwiki --setup, it will overwrite my wrapper-w
I made a logfile of all the args, env, and stdin/stdout to/from my wrapper. If you're interested, I'll email it to you. I wasn't able to attach it here.
-- [[terry|tjgolubi]]
+
+I confirm that the supplied w3mmode setup appears not to work. When I try to edit a page and save it, w3m tries to access an URL beginning http://localhost/ . The HTML source of the edit page contains a BASE URL beginning with http://localhost. It should not. Maybe this is a result of changes a while back, where use of absolute URLs was enforced in various places in Ikiwiki.
+
+-- Martin
+
+The problem is that IkiWiki::CGI::cgitemplate() and IkiWiki::CGI::redirect() use Perl's CGI::url() to determine the absolute URL of the CGI script when it is being executed. url() generates an URL beginning http://localhost. As w3m's serverless CGI mode is rather unusual, presumably there's no provision for the URL of a CGI script beginning file:///, even if there's a way to specify that.
+
+A quick workaround might be to force the use of $config{url} instead of $cgi->url as a base for URLs when w3mmode is set.
+
+-- Martin
diff --git a/doc/bugs/__91__SOLVED__93___Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8.mdwn b/doc/bugs/__91__SOLVED__93___Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8.mdwn
new file mode 100644
index 000000000..7282a71b8
--- /dev/null
+++ b/doc/bugs/__91__SOLVED__93___Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8.mdwn
@@ -0,0 +1,11 @@
+import os
+os.environment['LANG'] = 'it_IT.utf-8'
+
+Suona plausibile?
+
+[GitHub pykipandoc](https://github.com/temmen/pykipandoc) -- Temmen
+
+> The place to put contrib plugins is in [[plugins/contrib]].
+>
+> Closing this bug report as whatever it is that was fixed is apparently not an ikiwiki
+> bug.. I guess. [[done]] --[[Joey]]
diff --git a/doc/bugs/Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8/discussion.mdwn b/doc/bugs/__91__SOLVED__93___Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8/discussion.mdwn
similarity index 100%
rename from doc/bugs/Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8/discussion.mdwn
rename to doc/bugs/__91__SOLVED__93___Pandoc_plugin_and_UTF-8:_IkiWiki_and_UTF-8/discussion.mdwn
diff --git a/doc/bugs/bug_in_cgiurl_port.mdwn b/doc/bugs/bug_in_cgiurl_port.mdwn
new file mode 100644
index 000000000..373657814
--- /dev/null
+++ b/doc/bugs/bug_in_cgiurl_port.mdwn
@@ -0,0 +1,15 @@
+I think there's a bug in the code that determines if the cgiurl is relative
+to the url. If one has a different port than the other, they're not
+relative, and I hear Fil encountered an issue where the wrong port was then
+used. --[[Joey]]
+
+> I tested, setting cgiurl to a nonstandard port. After rebuilding,
+> pages used the full url. So I don't see a bug here, or am missing
+> something from my memory of the report (which was done the bad way, on
+> IRC). [[done]] --[[Joey]]
+
+> > Sorry about wittering on IRC instead of reporting proper bugs.
+> >
+> > The setup I have is nginx in front of apache, so that nginx is listening on port 80, apache is on port 81, and ikiwiki is being served by apache. After upgrading to 3.20120203 (backported to squeeze) I found that the URLs in the edit page all have the port set as :81 ... but now that I look at it more closely, that is the case for several ikiwiki-hosting controlled sites, but not for a few other sites that are also on the same machine, so it must be some difference between the settings for the sites, either in ikiwiki, or apache, or perhaps even nginx. Anyway, on the affected sites, explicitly including a port :80 in the cgiurl fixes the problem.
+
+> > So, for the moment, this bug report is a bit useless, until I find out what is causing the ikiwiki-hosting sites to be beffuddled, so it should probably stay closed -[[fil]]
diff --git a/doc/bugs/cannot_clone_documented_git_repo.mdwn b/doc/bugs/cannot_clone_documented_git_repo.mdwn
new file mode 100644
index 000000000..4f2ec66f3
--- /dev/null
+++ b/doc/bugs/cannot_clone_documented_git_repo.mdwn
@@ -0,0 +1,16 @@
+ smcv@vasks:~$ git clone git://git.ikiwiki.info/
+ Cloning into git.ikiwiki.info...
+ fatal: read error: Connection reset by peer
+
+I tried this from a UK consumer ISP, my virtual server in the
+UK, and vasks (aka alioth.debian.org) in the Netherlands,
+with the same results. I can't update my clone from `origin`
+either; for the moment I'm using the github mirror instead.
+--[[smcv]]
+
+> Strange.. The git-daemon was not running, but one child was running
+> waiting on an upload-pack, but not accepting new connections. Nothing
+> in the logs about what happened to the parent. The monitor that checks
+> services are running was satisfied with the child.. I've made it
+> restart if the parent pid is no longer running, which should avoid
+> this problem in the future. --[[Joey]] [[done]]
diff --git a/doc/bugs/conditional_preprocess_during_scan.mdwn b/doc/bugs/conditional_preprocess_during_scan.mdwn
index 23b9fd2cc..1ba142331 100644
--- a/doc/bugs/conditional_preprocess_during_scan.mdwn
+++ b/doc/bugs/conditional_preprocess_during_scan.mdwn
@@ -1,4 +1,4 @@
-[[!template id=gitbranch branch=GiuseppeBilotta/scanif author="Giuseppe Bilotta"]]
+[[!template id=gitbranch branch=GiuseppeBilotta/scanif author="[[GiuseppeBilotta]]"]]
When a directive that should be run during scan preprocessing is inside
an if directive, it doesn't get called because the if preprocessing does
diff --git a/doc/bugs/definition_lists_should_be_bold.mdwn b/doc/bugs/definition_lists_should_be_bold.mdwn
new file mode 100644
index 000000000..a72206b8c
--- /dev/null
+++ b/doc/bugs/definition_lists_should_be_bold.mdwn
@@ -0,0 +1,27 @@
+Definition lists do not look great here...
+
+Here is an example.
+
+
+
this is a term
+
and this is its definition.
+
+
+(This wiki doesn't support Markdown's extended definition lists, but still, this is valid markup.)
+
+I believe `
` should be made bold. I have added this to my `local.css`, and I would hate to add this all the time forever:
+
+ /* definition lists look better with the term in bold */
+ dt
+ {
+ font-weight: bold;
+ }
+
+:) How does that look? I can provide a patch for the base wiki if you guys really want... ;) -- [[anarcat]]
+
+> What you dislike seems to be the default rendering of definition lists by
+> browsers. I don't think it's ikiwiki's place to override browser defaults
+> for standard markup in the document body, at least not in the default
+> antitheme. --[[Joey]]
+
+> > How about in the actiontab theme then? :)
diff --git a/doc/bugs/feeds_get_removed_in_strange_conditions.mdwn b/doc/bugs/feeds_get_removed_in_strange_conditions.mdwn
new file mode 100644
index 000000000..deec208ba
--- /dev/null
+++ b/doc/bugs/feeds_get_removed_in_strange_conditions.mdwn
@@ -0,0 +1,57 @@
+For some time now, in circumstances that I've had enormous troubles
+trying to track, I've seen feeds getting removed by ikiwiki when
+apparently unrelated pages got changed, with the message:
+
+> removing somepath/somepage/somefeed, no longer built by some/unrelated/page
+
+I've finally been able to find how and why it happens. The situation is
+the following:
+
+* page A has an inline directive that (directly) generates a feed F
+* page B inlines A, thus (indirectly) generating F again
+* page B is rendered after page A
+
+The feed removal happens when changes are made to prevent B from
+inlining A; for example, because B is a tag page and A is untagged B, or
+because B includes A through a pagespec that no longer matches A. In
+this case, this happens:
+
+* page A is built, rendering F
+* page B is built, _not_ rendering F, which it used to render
+* F is removed because it is not built by B anymore
+
+Note that although this issue is triggered (for me) from the changes I
+proposed last year to allow feed generation from nested inlines
+coalescing it to be page-based instead of destpage-based
+(bb8f76a4a04686def8cc6f21bcca80cb2cc3b2c9 and
+72c8f01b36c841b0e83a2ad7ad1365b9116075c5) there is potential for it
+popping up in other cases.
+
+Specifically, the logic for the removal of dependent pages currently
+relies on the assumption that each output has a single generator. My
+changes caused this assumption to be violated, hence the error, but
+other cases may pop up for other plugins in the future.
+
+I have a [patch] fixing this issue (for feeds specifically, i.e. only
+the problem I am actually having) on top of my `mystuff` branch, but
+since that also has heaps of other unrelated stuff, you may want to just
+[pick it from my gitweb][gw].
+
+[gw]: (http://git.oblomov.eu/ikiwiki/patch/671cb26cf50643827f258270d9ac8ad0b1388a65)
+
+The patch changes the `will_render()` for feeds to be based on the page
+rather than on the destpage, matching the fact that for nested inlines
+it's the inner page that is ultimately responsible for generating the
+feed.
+
+I've noticed that it requires at least _two_ full rebuilds before the
+index is again in a sensible state. (On the first rebuild, all feeds
+from nested inlines are actually _removed_.)
+
+While the patch is needed because there are legitimate cases in which
+nested feeds are needed (for example, I have an index page that inlines
+index pages for subsection of my site, and I want _those_ feed from
+being visible), there are other cases when one may want to skip feed
+generation from nested inlines.
+
+--[[GiuseppeBilotta]]
diff --git a/doc/bugs/find_gnuism.mdwn b/doc/bugs/find_gnuism.mdwn
index 89eee7816..65ee10657 100644
--- a/doc/bugs/find_gnuism.mdwn
+++ b/doc/bugs/find_gnuism.mdwn
@@ -3,3 +3,5 @@
Whoops, somehow missed a spot on the last incarnation of this branch.
`find -not` doesn't work on NetBSD and `find !` runs equivalently
for me. Fixed in 9659272e25fac37f896991dab01a05b4f4c85ccb.
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/graphviz_demo_generates_empty_graph.mdwn b/doc/bugs/graphviz_demo_generates_empty_graph.mdwn
new file mode 100644
index 000000000..5b96f148e
--- /dev/null
+++ b/doc/bugs/graphviz_demo_generates_empty_graph.mdwn
@@ -0,0 +1,15 @@
+The following code in our sandbox generates an empty graph:
+
+ [[!graph src=""""
+ google [ href="http://google.com/" ]
+ sandbox [ href=\[[SandBox]] ]
+ help [ href=\[[ikiwiki/formatting]] ]
+ newpage [ href=\[[NewPage]] ]
+
+ google -> sandbox -> help -> newpage -> help -> google;
+ """"]]
+
+It is the exact same thing that on the [[ikiwiki/directive/graph/]] directive documentation, from the [[plugins/graphviz]] plugin. This is ikiwiki 3.20120203 on Debian wheezy and graphviz is installed (2.26.3-10). Note that the first demo actually works. See --[[anarcat]]
+
+> Looking at the example shows too many double quoted. [[fixed|done]]
+> --[[Joey]]
diff --git a/doc/bugs/ipv6_address_in_comments.mdwn b/doc/bugs/ipv6_address_in_comments.mdwn
new file mode 100644
index 000000000..90391650a
--- /dev/null
+++ b/doc/bugs/ipv6_address_in_comments.mdwn
@@ -0,0 +1,19 @@
+If I make a comment from an ipv4 address
+I see the commenter's ipv4 address logged in the comment file.
+
+If I make a comment from an ipv6 address
+I see nothing.
+
+There is a sanity check in /usr/share/perl5/IkiWiki/Plugin/comments.pm
+line 447 (according to today's version) there is an ipv4 specific regexp.
+
+I removed the regexp and used the value without this added check and it fixed
+the problem for me. Not sure if this is the best solution. --[[cstamas]]
+
+[[patch]]
+
+[[!tag ipv6]]
+
+> [[done]] --[[Joey]]
+
+> > Thank you! --[[cstamas]]
diff --git a/doc/bugs/jquery-ui.min.css_missing_some_image_files.mdwn b/doc/bugs/jquery-ui.min.css_missing_some_image_files.mdwn
new file mode 100644
index 000000000..dd026f4ec
--- /dev/null
+++ b/doc/bugs/jquery-ui.min.css_missing_some_image_files.mdwn
@@ -0,0 +1,14 @@
+This is very minor. Noticed in nginx's logs that jquery-ui.min.css (the attachment plugin uses this) keeps referencing some png files that are not available in public_html/mywiki/ikiwiki/images/ These should be included in underlays/attachment/ikiwiki/images/ in the source repo and seem to be copied from /usr/local/share/ikiwiki/attachment/ikiwiki/images/ when I compile a new wiki. The complete list of images jquery-ui.min.css is looking for can be found here. https://github.com/jquery/jquery-ui/tree/1.8.14/themes/base/images
+
+> Do you have a list of files that are *actually* used when ikiwiki is
+> running? I don't want to include a lot of files that jquery only
+> uses in other situations. The currently included files are exactly those
+> that I see it try to use. --[[Joey]]
+
+Fair enough. These 3 files are the only ones that appear consistently in nginx error logs.
+ui-bg_glass_75_dadada_1x400.png
+ui-icons_454545_256x240.png
+ui-bg_glass_95_fef1ec_1x400.png
+
+> Hmm, that's most of the missing ones. I just added them all. [[done]]
+> --[[Joey]]
diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
new file mode 100644
index 000000000..f74ca5119
--- /dev/null
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -0,0 +1,18 @@
+[[ikiwiki/directive/linkmap]]s display the file name instead of the pagetitle, showing unsightly underscore escapes and underscores instead of blanks to users.
+
+the attached [[!taglink patch]] fixes this; from its commit message:
+
+ display the pagetitle() in linkmaps
+
+ without this patch, linkmaps display underscores and underscore escape
+ sequences in the rendered output.
+
+ this introduces a pageescape function, which invoces pagetitle() to get
+ rid of underscore escapes and wraps the resulting utf8 string
+ appropriately for inclusion in a dot file (using dot's html encoding
+ because it can represent the '\"' dyad properly, and because it doesn't
+ need special-casing of newlines).
+
+the output will look much better (at least in my wikis) with the "[[bugs/pagetitle function does not respect meta titles]]" issue fixed.
+
+the patch is stored in [[the patch.pl]] as created by git-format-patch. (btw, what's the preferred way to send patches, apart from creating a git branch somewhere?)
diff --git a/doc/bugs/linkmap_displays_underscore_escapes/the_patch.pl b/doc/bugs/linkmap_displays_underscore_escapes/the_patch.pl
new file mode 100644
index 000000000..6b56c553e
--- /dev/null
+++ b/doc/bugs/linkmap_displays_underscore_escapes/the_patch.pl
@@ -0,0 +1,68 @@
+From efbb1121ffdc146f5c9a481a51f23ad151b9f240 Mon Sep 17 00:00:00 2001
+From: chrysn
+Date: Thu, 15 Mar 2012 14:38:42 +0100
+Subject: [PATCH] display the pagetitle() in linkmaps
+
+without this patch, linkmaps display underscores and underscore escape
+sequences in the rendered output.
+
+this introduces a pageescape function, which invoces pagetitle() to get
+rid of underscore escapes and wraps the resulting utf8 string
+appropriately for inclusion in a dot file (using dot's html encoding
+because it can represent the '\"' dyad properly, and because it doesn't
+need special-casing of newlines).
+---
+ IkiWiki/Plugin/linkmap.pm | 17 +++++++++++++++--
+ 1 files changed, 15 insertions(+), 2 deletions(-)
+
+diff --git a/IkiWiki/Plugin/linkmap.pm b/IkiWiki/Plugin/linkmap.pm
+index ac26e07..b5ef1a1 100644
+--- a/IkiWiki/Plugin/linkmap.pm
++++ b/IkiWiki/Plugin/linkmap.pm
+@@ -5,6 +5,7 @@ use warnings;
+ use strict;
+ use IkiWiki 3.00;
+ use IPC::Open2;
++use HTML::Entities;
+
+ sub import {
+ hook(type => "getsetup", id => "linkmap", call => \&getsetup);
+@@ -22,6 +23,18 @@ sub getsetup () {
+
+ my $mapnum=0;
+
++sub pageescape {
++ my $item = shift;
++ # encoding explicitly in case ikiwiki is configured to accept <> or &
++ # in file names
++ my $title = pagetitle($item, 1);
++ # it would not be necessary to encode *all* the html entities (<> would
++ # be sufficient, &" probably a good idea), as dot accepts utf8, but it
++ # isn't bad either
++ $title = encode_entities($title);
++ return("<$title>");
++}
++
+ sub preprocess (@) {
+ my %params=@_;
+
+@@ -63,7 +76,7 @@ sub preprocess (@) {
+ my $show=sub {
+ my $item=shift;
+ if (! $shown{$item}) {
+- print OUT "\"$item\" [shape=box,href=\"$mapitems{$item}\"];\n";
++ print OUT pageescape($item)." [shape=box,href=\"$mapitems{$item}\"];\n";
+ $shown{$item}=1;
+ }
+ };
+@@ -74,7 +87,7 @@ sub preprocess (@) {
+ foreach my $endpoint ($item, $link) {
+ $show->($endpoint);
+ }
+- print OUT "\"$item\" -> \"$link\";\n";
++ print OUT pageescape($item)." -> ".pageescape($link).";\n";
+ }
+ }
+ print OUT "}\n";
+--
+1.7.9.1
diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
new file mode 100644
index 000000000..26945ee07
--- /dev/null
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -0,0 +1,34 @@
+The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link between the page and the subpages. This is a problem because then the [[ikiwiki/directive/orphans]] directive then marks the directives as orphans... Maybe it is a but with the orphans directive however... A simple workaround is to exclude those files from the orphans call... --[[anarcat]]
+
+> There's a distinction between wikilinks (matched by `link()`,
+> `backlink()` etc.) and other constructs that produce a
+> hyperlink. Some directives count as a wikilink (like `tag`)
+> but many don't (notably `inline`, `map`, `listdirectives`,
+> and `orphans` itself). As documented in
+> [[ikiwiki/directive/orphans]], orphans will tend to list
+> pages that are only matched by inlines/maps, too.
+>
+> The rule of thumb seems to be that a link to a particular
+> page counts as a wikilink, but a directive that lists
+> pages matching some pattern does not; so I think
+> `listdirectives` is working as intended here.
+> `orphans` itself obviously shouldn't count as a wikilink,
+> because that would defeat the point of it :-)
+>
+> Anything that uses a [[ikiwiki/pagespec]] to generate links,
+> like `inline` and `map`, can't generate wikilinks, because
+> wikilinks are gathered during the scan phase, and pagespecs
+> can't be matched until after the scan phase has finished
+> (otherwise, it'd be non-deterministic whether all wikilinks
+> had been seen yet, and `link()` in pagespecs wouldn't work
+> predictably).
+>
+> I suggest just using something like:
+>
+> \[[!orphans pages="* and !blog/* and !ikiwiki/directive/*"]]
+>
+> This wiki's example of listing [[plugins/orphans]] has a
+> more elaborate pagespec, which avoids bugs, todo items etc.
+> as well.
+>
+> --[[smcv]]
diff --git a/doc/bugs/must_save_before_uploading_more_than_one_attachment.mdwn b/doc/bugs/must_save_before_uploading_more_than_one_attachment.mdwn
index 20d5dc8e6..bd5ddc6d5 100644
--- a/doc/bugs/must_save_before_uploading_more_than_one_attachment.mdwn
+++ b/doc/bugs/must_save_before_uploading_more_than_one_attachment.mdwn
@@ -26,7 +26,19 @@ Is this a problem on my site or does anyone else see this?
>>> The right fix would probably be for `do=create` to allow replacing a page
>>> in the transient underlay without complaining (like the behaviour that
->>> `do=edit` normally has). That wouldn't help you unless [[plugins/autoindex]]
+>>> `do=edit` normally has).
+
+>>>> ... which it turns out it already does. --[[smcv]]
+
+>>> That wouldn't help you unless [[plugins/autoindex]]
>>> defaulted to making transient pages (`autoindex_commit => 0`), but if we
>>> can fix [[removal_of_transient_pages]] then maybe that default can change?
>>> --[[smcv]]
+
+>>>> It turns out that with `autoindex_commit => 0`, the failure mode is
+>>>> different. The transient map is created when you attach the
+>>>> attachment. When you save the page, it's written into the srcdir,
+>>>> the map is deleted from the transientdir, and the ctime/mtime
+>>>> in the indexdb are those of the file in the srcdir, but for some
+>>>> reason the HTML output isn't re-generated (despite a refresh
+>>>> happening). --[[smcv]]
diff --git a/doc/bugs/nonexistent_pages_in_inline_pagenames_do_not_add_a_dependency.mdwn b/doc/bugs/nonexistent_pages_in_inline_pagenames_do_not_add_a_dependency.mdwn
new file mode 100644
index 000000000..486be0363
--- /dev/null
+++ b/doc/bugs/nonexistent_pages_in_inline_pagenames_do_not_add_a_dependency.mdwn
@@ -0,0 +1,44 @@
+In commit aaa72a3a8, Joey noted:
+
+> bestlink returns '' if no existing page matches a link. This propigated
+> through inline and other plugins, causing uninitialized value warnings, and
+> in some cases (when filecheck was enabled) making the whole directive fail.
+>
+> Skipping the empty results fixes that, but this is papering over another
+> problem: If the missing page is later added, there is not dependency
+> information to know that the inline needs to be updated. Perhaps smcv will
+> fix that later.
+
+Potential ways this could be addressed:
+
+* Add a presence dependency on everything the reference could match:
+ so if the `inline` is on `a/b/c` and the missing page is `m`,
+ add a `$depends_simple` `$DEPEND_PRESENCE` dependency on `a/b/c/m`,
+ `a/b/m`, `a/m`, `m` and (if configured) `$config{userdir}/m`
+
+* Make the page names in `\[[!inline pagenames=...]]` count as wikilinks,
+ changing the behaviour of `link()` and backlinks, but causing appropriate
+ rebuilds via the special cases in `IkiWiki::Render`
+
+* Extend the special cases in `IkiWiki::Render` to consider a superset of
+ wikilinks, to which `pagenames` would add its named pages, without
+ affecting `link()` and backlinks
+
+(Note that `\[[!inline pages=...]]` cannot count as wikilinks, because
+pagespecs can contain `link()`, so can't be evaluated until we know what
+wikilinks exist, at which point it's too late to add more wikilinks.)
+
+I think the presence dependency is probably the cleanest approach?
+--[[smcv]]
+
+> I think it was possibly a mistake to use wikilink style lookup for
+> `pagenames`. --[[Joey]]
+
+[[!tag patch]] [[!template id=gitbranch branch=smcv/literal-pagenames author="[[smcv]]"]]
+>> I used the linking rules to make references to
+>> "nearby" pages convenient, but if you'd prefer "absolute"
+>> semantics, my `ready/literal-pagenames` branch does that. For
+>> my main use-case for `pagenames` ([[plugins/contrib/album]])
+>> it's fine either way. --[[smcv]]
+
+>>> Ok, [[merged|done]]. I think it's more consistent this way. --[[Joey]]
diff --git a/doc/bugs/opendiscussion_should_respect_the_discussion_option.mdwn b/doc/bugs/opendiscussion_should_respect_the_discussion_option.mdwn
index e4bc736e3..cacd2b73b 100644
--- a/doc/bugs/opendiscussion_should_respect_the_discussion_option.mdwn
+++ b/doc/bugs/opendiscussion_should_respect_the_discussion_option.mdwn
@@ -1,6 +1,11 @@
+[[!template id=gitbranch branch=smcv/ready/less-open author="[[smcv]]"]]
+[[!tag patch]]
+
The [[plugins/opendiscussion]] plugin allows pages named according to
the `discussionpage` setting to be edited anonymously, even if
`discussion => 0` is set.
(If it respected the `discussion` option, the combination of
`opendiscussion` and `moderatedcomments` might be good for blogs.)
+
+[[done]] --[[smcv]]
diff --git a/doc/bugs/opendiscussion_should_respect_the_discussion_option/discussion.mdwn b/doc/bugs/opendiscussion_should_respect_the_discussion_option/discussion.mdwn
new file mode 100644
index 000000000..a5c951671
--- /dev/null
+++ b/doc/bugs/opendiscussion_should_respect_the_discussion_option/discussion.mdwn
@@ -0,0 +1,26 @@
+This would be great to see fixed. It's perplexing to have discussion => 0 in my configuration, not have any discussion links on my site, but still be able to add a discussion page by URL hacking something like this: /cgi-bin/ikiwiki/ikiwiki.cgi?page=posts%2Fdiscussion&do=edit.
+
+spammers have figured that little trick out so I am consitently getting spammed checked into my git repository.
+
+I'm not really sure if this patch introduced other problems, but it seems to have fixed my site:
+
+ 0 mcclelland@chavez:~/.ikiwiki/IkiWiki/Plugin$ diff -u /usr/share/perl5/IkiWiki/Plugin/opendiscussion.pm opendiscussion.pm
+ --- /usr/share/perl5/IkiWiki/Plugin/opendiscussion.pm 2012-05-07 11:31:24.000000000 -0400
+ +++ opendiscussion.pm 2012-07-29 17:49:28.000000000 -0400
+ @@ -25,7 +25,7 @@
+ my $cgi=shift;
+ my $session=shift;
+
+ - return "" if $page=~/(\/|^)\Q$config{discussionpage}\E$/i;
+ + return "" if $page=~/(\/|^)\Q$config{discussionpage}\E$/i && $config{discussion};
+ return "" if pagespec_match($page, "postcomment(*)");
+ return undef;
+ }
+ 1 mcclelland@chavez:~/.ikiwiki/IkiWiki/Plugin$
+
+If libdir is configured to be ~/.ikiwiki in your ikiwiki.settings file, and you are running Debian, you can do the following:
+
+ mkdir -p ~/.ikiwiki/IkiWiki/Plugin
+ cp /usr/share/perl5/IkiWiki/Plugin/opendiscussion.pm ~/.ikiwiki/IkiWiki/Plugin/
+
+And then apply the patch above to ~/.ikiwiki/Ikiwiki/Plugin/opendiscussion.pm.
diff --git a/doc/bugs/osm_KML_maps_do_not_display_properly_on_google_maps.mdwn b/doc/bugs/osm_KML_maps_do_not_display_properly_on_google_maps.mdwn
new file mode 100644
index 000000000..2b20240c4
--- /dev/null
+++ b/doc/bugs/osm_KML_maps_do_not_display_properly_on_google_maps.mdwn
@@ -0,0 +1,14 @@
+[[!template id=gitbranch branch=anarcat/master author="[[anarcat]]"]]
+
+I know this sounds backwards, but it seems to me that the KML-generated map should be displayable on google maps. KML is the standard Google uses for google maps, and since we use it, we should interoperate with them. God knows why this is failing, but it is and should probably be fixed for the sake of interoperability: -- [[users/anarcat]]
+
+> The KML only needs a Document tag because it uses "shared styles" -- don't ask me what this is. Here is a [[patch]]: [[https://reseaulibre.deuxpi.ca/0001-Add-Document-tag-to-OSM-plugin-KML-output.patch]] --[[deuxpi]]
+
+> > I applied the patch to my master branch and tested it on the above URL: it works... mostly. The icons for the elements on the actual map seem incorrect (some are the proper icons, some others are the ugly default blue pin of google maps, weird) but I think this is a step in the right direction. Thus, this should be merged. -- [[anarcat]]
+
+>>> I've cherry-picked this patch, but from the description it does not
+>>> sound "fixed" enough to close this bug. (OTOH, perhaps only google can
+>>> fix it, so it people are happy with the state of affairs I won't insist
+>>> this bug be left open.) --[[Joey]]
+
+> > > > I am happy with this right now, so let's mark this as [[done]]. I do agree this seems like a google bug, so let's move on. --[[anarcat]]
diff --git a/doc/bugs/osm_KML_maps_icon_path_have_a_trailing_slash.mdwn b/doc/bugs/osm_KML_maps_icon_path_have_a_trailing_slash.mdwn
new file mode 100644
index 000000000..0677d0e74
--- /dev/null
+++ b/doc/bugs/osm_KML_maps_icon_path_have_a_trailing_slash.mdwn
@@ -0,0 +1,32 @@
+This is not a problem on Apache webservers because they, oddly enough, ignore trailing slashes on paths (maybe some `PATH_INFO` magic, no idea). But basically, in our wiki, the paths to the icon tags are generated with a trailing slash. An excerpt of our [KML file](http://wiki.reseaulibre.ca/map/pois.kml):
+
+
+
+Notice the trailing `/` after the `icon.png`. This breaks display on nginx - the file that gets served isn't the icon, but the frontpage for some reason. I followed the [[setup instructions|tips/dot cgi]] for Nginx that I just had to write because there weren't any, so maybe I screwed up some part, but it does seem to me that the trailing slash is wrong regardless.
+
+(Also notice how the style tag is being turned over backwards by the HTML sanitizer here, cute. :P)
+
+I wrote a crude hack for this, but this strikes me as a similar problem to the one we found in [[bugs/osm linkto() usage breaks map rendering]]. However, I am at a loss how to fix this cleanly because we cannot `will_render()` the tag icons, as they are already generated out there! Weird. Anyways, here's the stupid [[patch]]:
+
+[[!format diff """
+diff --git a/IkiWiki/Plugin/osm.pm b/IkiWiki/Plugin/osm.pm
+index a7baa5f..c9650d0 100644
+--- a/IkiWiki/Plugin/osm.pm
++++ b/IkiWiki/Plugin/osm.pm
+@@ -192,6 +192,7 @@ sub process_waypoint {
+ }
+ }
+ $icon = urlto($icon, $dest, 1);
++ $icon =~ s!/*$!!; # hack - urlto shouldn't be appending a slash in the first place
+ $tag = '' unless $tag;
+ register_rendered_files($map, $page, $dest);
+ $pagestate{$page}{'osm'}{$map}{'waypoints'}{$name} = {
+"""]]
+
+I'm not writing this to a branch out of sheer shame of my misunderstanding. ;) There also may be a workaround that could be done in Nginx too. --[[anarcat]]
diff --git a/doc/bugs/osm_linkto__40____41___usage_breaks_map_rendering.mdwn b/doc/bugs/osm_linkto__40____41___usage_breaks_map_rendering.mdwn
new file mode 100644
index 000000000..89c08b73c
--- /dev/null
+++ b/doc/bugs/osm_linkto__40____41___usage_breaks_map_rendering.mdwn
@@ -0,0 +1,23 @@
+[[!template id=gitbranch branch=anarcat/master author="[[anarcat]]"]]
+
+Under some circumstances that remain unclear to me, the usage of `urlto()` in the revised version of the [[plugins/osm]] plugin break the map totally. The javascript console in Chromium tells me the following:
+
+ GET http://mesh.openisp.ca/map/pois.kml/ 404 (Not Found)
+
+Indeed, that URL yields a 404. The proper URL is . --[[anarcat]]
+
+## Proposed solution
+
+The problem seems to be caused by `urlto()` being called for the `osm`
+directive before the generated files are registered with `will_render()`
+from the `waypoint` directive. Proposed patch adds a function that is
+called from the `preprocess` hook for both directives that registers the
+files.
+
+Here is a [[patch]] to IkiWiki/Plugin/osm.pm:
+
+--[[deuxpi]]
+
+I confirm the patch works, and I added it to my master branch. --[[anarcat]]
+
+> [[applied|done]]. Thanks guys. --[[Joey]]
diff --git a/doc/bugs/osm_sometimes_looses_some_nodes.mdwn b/doc/bugs/osm_sometimes_looses_some_nodes.mdwn
new file mode 100644
index 000000000..9de1b4e23
--- /dev/null
+++ b/doc/bugs/osm_sometimes_looses_some_nodes.mdwn
@@ -0,0 +1,5 @@
+I have heard repeated reports on that editing a page that has a waypoint in it will sometimes make that waypoint disappear from the main map. I have yet to understand why that happens or how, but multiple users have reported that.
+
+A workaround is to rebuild the whole wiki, although sometimes re-editing the same page will bring the waypoint back on the map.
+
+I have been able to reproduce this by simply creating a new node. It will not show up on the map until the wiki is rebuilt or the node is resaved. -- [[anarcat]]
diff --git a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
index c6e3cd4fd..15d28f989 100644
--- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
+++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
@@ -279,3 +279,11 @@ So, looking at your meta branch: --[[Joey]]
>>>> for the po plugin, because I want to merge the po plugin soon.
>>>> If #2 gets tackled later, we will certianly have all kinds of fun.
>>>> no matter what is done for the po plugin. --[[Joey]]
+
+>>>>> For the record: I've gotten used to the lack of this feature,
+>>>>> and it now seems much less important to me than it was when
+>>>>> initially developing the po plugin. So, I'm hereby officially
+>>>>> removing this from my plate. If anyone else wants to start from
+>>>>> scratch, or from my initial work, I'm happy to review the
+>>>>> po-related part of things -- just drop me an email in this
+>>>>> case. --[[intrigeri]]
diff --git a/doc/bugs/removal_of_transient_pages.mdwn b/doc/bugs/removal_of_transient_pages.mdwn
index 2667a2b83..4843b5900 100644
--- a/doc/bugs/removal_of_transient_pages.mdwn
+++ b/doc/bugs/removal_of_transient_pages.mdwn
@@ -25,3 +25,49 @@ pages, until this is fixed. --[[Joey]]
>>>> to affect by web edits. The `-f` check seems rather redundant,
>>>> surely if it's in `%pagesources` ikiwiki has already verified it's
>>>> safe. --[[Joey]]
+
+----
+
+[[!template id=gitbranch branch=smcv/ready/transient-rm author="[[Simon McVittie|smcv]]"]]
+
+Here's a branch. It special-cases the `$transientdir`, but in such a way
+that the special case could easily be extended to other locations where
+deletion should be allowed.
+
+It also changes `IkiWiki::prune()` to optionally stop pruning empty
+parent directories at the point where you'd expect it to (for instance,
+previously it would remove the `$transientdir` itself, if it turns out
+to be empty), and updates callers.
+
+The new `prune` API looks like this:
+
+ IkiWiki::prune("$config{srcdir}/$file", $config{srcdir});
+
+with the second argument optional. I wonder whether it ought to look
+more like `writefile`:
+
+ IkiWiki::prune($config{srcdir}, $file);
+
+although that would be either an incompatible change to internal API
+(forcing all callers to update to 2-argument), or being a bit
+inconsistent between the one-and two-argument forms. Thoughts?
+
+--[[smcv]]
+
+> I've applied the branch as-is, so this bug is [[done]].
+> `prune` is not an exported API so changing it would be ok..
+> I think required 2-argument would be better, but have not checked
+> all the call sites to see if the `$file` is available split out
+> as that would need. --[[Joey]]
+
+[[!template id=gitbranch branch=smcv/ready/prune author="[[Simon McVittie|smcv]]"]]
+
+>> Try this, then? I had to make some changes to `attachment`
+>> to make the split versions available. I suggest reviewing
+>> patch-by-patch.
+>>
+>> I also tried to fix a related bug which I found while testing it:
+>> the special case for renaming held attachments didn't seem to work.
+>> (`smcv/wip/rename-held`.) Unfortunately, it seems that with that
+>> change, the held attachment is committed to the `srcdir` when you
+>> rename it, which doesn't seem to be the intention either? --[[smcv]]
diff --git a/doc/bugs/renaming_a_page_destroyed_some_links.mdwn b/doc/bugs/renaming_a_page_destroyed_some_links.mdwn
new file mode 100644
index 000000000..fd7a80bd4
--- /dev/null
+++ b/doc/bugs/renaming_a_page_destroyed_some_links.mdwn
@@ -0,0 +1,12 @@
+When renaming a page here, ikiwiki destroyed unrelated links from unrelated pages. You can see the effect [here](http://mesh.openisp.ca/recentchanges/#diff-dc8dfa96efd3a4d649f571c3aa776f20b3ce0131), or by checking out the git tree (`git://mesh.openisp.ca/
+`) and looking at commit `dc8dfa96efd3a4d649f571c3aa776f20b3ce0131`.
+
+The renamed page was `configuration/bat-hosts` to `configuration/batman/bat-hosts` and the deleted links were ``\[[AUR | https://aur.archlinux.org/]]` and `\[[CHANGELOG|http://svn.dd-wrt.com:8000/browser/src/router/batman-adv/CHANGELOG]]`. --[[anarcat]]
+
+> Nevermind that, that commit was unrelated to the rename and probably an operator error. - No, actually, I just reproduced this again - see [another example](http://mesh.openisp.ca/recentchanges/#diff-d67dc2f0fdc149b13122fd6cba887a01c693e949).
+
+>> Looks like these all involve the wacky wikilink form that includes an
+>> external url in the link. Fixed rename code to know about those.
+>> [[done]] --[[Joey]]
+
+>>> Phew!!! Thanks a *lot* for that one, it was really annoying! :) --[[anarcat]]
diff --git a/doc/bugs/toc_displays_headings_from_sidebar.mdwn b/doc/bugs/toc_displays_headings_from_sidebar.mdwn
new file mode 100644
index 000000000..469ca8a33
--- /dev/null
+++ b/doc/bugs/toc_displays_headings_from_sidebar.mdwn
@@ -0,0 +1,3 @@
+The [[/ikiwiki/directive/toc]] directive scrapes all headings from the page, including those in the sidebar. So, if the sidebar includes navigational headers, every page with a table of contents will display those navigational headers before the headers in that page's content.
+
+I'd like some way to exclude the sidebar from the table of contents. As discussed via Jabber, perhaps toc could have a config option to ignore headers inside a nav tag or a tag with id="sidebar".
diff --git a/doc/bugs/trail_excess_dependencies.mdwn b/doc/bugs/trail_excess_dependencies.mdwn
new file mode 100644
index 000000000..f806a62eb
--- /dev/null
+++ b/doc/bugs/trail_excess_dependencies.mdwn
@@ -0,0 +1,95 @@
+I've just modified the trail plugin to use only presence, and not
+content dependencies. Using content dependencies, particularly to the page
+that defines the trail, meant that every time that page changed, *every*
+page in the trail gets rebuilt. This leads to users setting up sites that
+have horrible performance, if the trail is defined in, for example, the top
+page of a blog.
+
+Unfortunatly, this change to presence dependencies has
+introduced a bug. Now when an existing trail is removed, the pages in the
+trail don't get rebuilt to remove the trail (both html display and state).
+
+> Actually, this particular case is usually OK. Suppose a trail `untrail`
+> contains `untrail/a` (as is the case in the regression
+> test I'm writing), and you build the wiki, then edit `untrail` to no
+> longer be a trail, and refresh. `untrail` has changed, so it is
+> rendered. Assuming that the template of either `untrail` or another
+> changed page happens to contain the `TRAILS` variable (which is not
+> guaranteed, but is highly likely), `I::P::t::prerender`
+> is invoked. It notices that `untrail/a` was previously a trail
+> member and is no longer, and rebuilds it with the diagnostic
+> "building untrail/a, its previous or next page has changed".
+>
+> Strictly speaking, I should change `I::P::t::build_affected`
+> so it calls `prerender`, so we're guaranteed to have done the
+> recalculation. Fixed in my branch. --[[smcv]]
+
+I think that to fix this bug, the plugin should use a hook to
+force rebuilding of all the pages that were in the trail, when
+the trail is removed (or changed).
+
+> The case of "the trail is changed" is still broken:
+> if the order of items changes, or the trail is removed,
+> then the logic above means it's OK, but if you
+> change the `\[[!meta title]]` of the trail, or anything else
+> used in the prev/up/next bar, the items won't show that
+> change. Fixed in my branch. --[[smcv]]
+
+There's a difficulty in doing that: The needsbuild hook runs before the scan
+hook, so before it has a chance to see if the trail directive is still there.
+It'd need some changes to ikiwiki's hooks.
+
+> That's what `build_affected` is for, and trail already used it. --s
+
+(An improvement in this area would probably simplify other plugins, which
+currently abuse the needsbuild hook to unset state, to handle the case
+where the directive that resulted in that state is removed.)
+
+I apologise for introducing a known bug, but the dependency mess was too
+bad to leave as-is. And I have very little time (and regrettably, even less
+power) to deal with it right now. :( --[[Joey]]
+
+[[!template id=gitbranch branch=smcv/ready/trail author="[[Simon_McVittie|smcv]]"]]
+[[!tag patch]]
+
+> I believe my `ready/trail` branch fixes this. There are regression tests.
+>
+> Here is an analysis of how the trail pages interdepend.
+>
+> * If *trail* contains a page *member* which does exist, *member* depends
+> on *trail*. This is so that if the trail directive is deleted from
+> *trail*, or if *trail*'s "friendly" title or trail settings are changed,
+> the trail navigation bar in *member* will pick up that change. This is
+> now only a presence dependency, which isn't enough to make those happen
+> correctly. [Edited to add: actually, the title is the only thing that
+> can affect *member* without affecting the order of members.]
+>
+> * If *trail* contains consecutive pages *m1* and *m2* in that order,
+> *m1* and *m2* depend on each other. This is so that if one's
+> "friendly" title changes, the other is rebuilt. This is now only
+> a presence dependency, which isn't enough to make those happen
+> correctly. In my branch, I explicitly track the "friendly" title
+> for every page that's edited and is involved in a trail somehow.
+>
+> * If *trail* has *member* in its `pagenames` but there is no page called
+> *member*, then *trail* must be rebuilt if *member* is created. This
+> was always a presence dependency, and is fine.
+>
+> In addition, the `trail` plugin remembers the maps
+> { trail => next item in that trail } and { trail => previous item in
+> that trail } for each page. If either changes, the page gets rebuilt
+> by `build_affected`, with almost the same logic as is used to update
+> pages that link to a changed page. My branch extends this to track the
+> "friendly title" of each page involved in a trail, either by being
+> the trail itself or a member (or both).
+>
+> I think it's true to say that the trail always depends on every member,
+> even if it doesn't display them. This might mean that we can use
+> "render the trail page" as an opportunity to work out whether any of
+> its members are also going to need re-rendering?
+> [Edited to add: actually, I didn't need this to be true, but I made the
+> regression test check it anyway.]
+>
+> --[[smcv]]
+
+>>> Thanks **very** much! [[done]] --[[Joey]]
diff --git a/doc/bugs/trail_shows_on_cgi_pages.mdwn b/doc/bugs/trail_shows_on_cgi_pages.mdwn
new file mode 100644
index 000000000..74f329fbc
--- /dev/null
+++ b/doc/bugs/trail_shows_on_cgi_pages.mdwn
@@ -0,0 +1,3 @@
+When commenting on, or I think editing, a page that uses the trail
+plugin, the trail is displayed across the top of the page. This should not
+happen, probably. --[[Joey]]
diff --git a/doc/bugs/trail_test_suite_failures.mdwn b/doc/bugs/trail_test_suite_failures.mdwn
new file mode 100644
index 000000000..a3b7159ec
--- /dev/null
+++ b/doc/bugs/trail_test_suite_failures.mdwn
@@ -0,0 +1,97 @@
+[[!template id=gitbranch branch=smcv/trail author=smcv]] [[!tag patch]]
+
+`t/trail.t` has some test suite failures. This is after applying
+[[smcv]]'s patch that fixed some races that caused it to fail
+sometimes. These remaining failures may also be intermittant,
+although I can get them reliably on my laptop. I've added some debugging
+output, which seems to point to an actual bug in the plugin AFAICS. --[[Joey]]
+
+> I can reproduce this reliably at 0a23666ddd but not 3.20120203. Bisecting
+> indicates that it regressed in aaa72a3a80f, "inline: When the pagenames list
+> includes pages that do not exist, skip them".
+>
+> I don't think this is the bug noted in the commit message - the inline
+> containing `sorting/new` uses `pages`, not `pagenames`. --[[smcv]]
+
+>> It seems you removed `trail` support from `inline` in that commit.
+>> Assuming that wasn't intentional, this is fixed in `smcv/trail`.
+>> --[[smcv]]
+
+>>> Looks like a bad merge of some kind. pulled, [[done]] --[[Joey]]
+
+
+ok 71 - expected n=sorting/end p=sorting/beginning in sorting/middle.html
+not ok 72 - expected n=sorting/new p=sorting/middle in sorting/end.html
+# Failed test 'expected n=sorting/new p=sorting/middle in sorting/end.html'
+# at t/trail.t line 13.
+# got: 'n=sorting/linked2 p=sorting/middle'
+# expected: 'n=sorting/new p=sorting/middle'
+not ok 73 - expected n=sorting/old p=sorting/end in sorting/new.html
+# Failed test 'expected n=sorting/old p=sorting/end in sorting/new.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/old p=sorting/end'
+not ok 74 - expected n=sorting/ancient p=sorting/new in sorting/old.html
+# Failed test 'expected n=sorting/ancient p=sorting/new in sorting/old.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/ancient p=sorting/new'
+not ok 75 - expected n=sorting/linked2 p=sorting/old in sorting/ancient.html
+# Failed test 'expected n=sorting/linked2 p=sorting/old in sorting/ancient.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/linked2 p=sorting/old'
+not ok 76 - expected n= p=sorting/ancient in sorting/linked2.html
+# Failed test 'expected n= p=sorting/ancient in sorting/linked2.html'
+# at t/trail.t line 13.
+# got: 'n= p=sorting/end'
+# expected: 'n= p=sorting/ancient'
+ok 77
+
+
+Here, the "new" page does not seem to be included into the trail as expected.
+Looking at the rendered page, there is no trail directive output on it either.
+--[[Joey]]
+
+
+ok 90
+not ok 91 - expected n=sorting/new p= in sorting/old.html
+# Failed test 'expected n=sorting/new p= in sorting/old.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/new p='
+not ok 92 - expected n=sorting/middle p=sorting/old in sorting/new.html
+# Failed test 'expected n=sorting/middle p=sorting/old in sorting/new.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/middle p=sorting/old'
+not ok 93 - expected n=sorting/linked2 p=sorting/new in sorting/middle.html
+# Failed test 'expected n=sorting/linked2 p=sorting/new in sorting/middle.html'
+# at t/trail.t line 13.
+# got: 'n=sorting/linked2 p='
+# expected: 'n=sorting/linked2 p=sorting/new'
+ok 94 - expected n=sorting/linked p=sorting/middle in sorting/linked2.html
+ok 95 - expected n=sorting/end p=sorting/linked2 in sorting/linked.html
+ok 96 - expected n=sorting/a/c p=sorting/linked in sorting/end.html
+ok 97 - expected n=sorting/beginning p=sorting/end in sorting/a/c.html
+ok 98 - expected n=sorting/a/b p=sorting/a/c in sorting/beginning.html
+not ok 99 - expected n=sorting/ancient p=sorting/beginning in sorting/a/b.html
+# Failed test 'expected n=sorting/ancient p=sorting/beginning in sorting/a/b.html'
+# at t/trail.t line 13.
+# got: 'n=sorting/z/a p=sorting/beginning'
+# expected: 'n=sorting/ancient p=sorting/beginning'
+not ok 100 - expected n=sorting/z/a p=sorting/a/b in sorting/ancient.html
+# Failed test 'expected n=sorting/z/a p=sorting/a/b in sorting/ancient.html'
+# at t/trail.t line 13.
+# got: undef
+# expected: 'n=sorting/z/a p=sorting/a/b'
+not ok 101 - expected n= p=sorting/ancient in sorting/z/a.html
+# Failed test 'expected n= p=sorting/ancient in sorting/z/a.html'
+# at t/trail.t line 13.
+# got: 'n= p=sorting/a/b'
+# expected: 'n= p=sorting/ancient'
+ok 102
+
+
+Haven't investigated, but looks like the same sort of problem, a
+page expected to be in the trail isn't. --[[Joey]]
diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index 3eb1542d3..702608831 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -1,7 +1,31 @@
mkdir -p ikiwiki-tag-test/raw/a_dir/ ikiwiki-tag-test/rendered/
- echo '[[!taglink a_tag]]' > ikiwiki-tag-test/raw/a_dir/a_page.mdwn
+ echo '\[[!taglink a_tag]]' > ikiwiki-tag-test/raw/a_dir/a_page.mdwn
ikiwiki --verbose --plugin tag --plugin autoindex --plugin mdwn --set autoindex_commit=0 --set tagbase=tag --set tag_autocreate=1 --set tag_autocreate_commit=0 ikiwiki-tag-test/raw/ ikiwiki-tag-test/rendered/
ls -al ikiwiki-tag-test/raw/.ikiwiki/transient/
ls -al ikiwiki-tag-test/rendered/tag/
Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-test/rendered/tag/index.html` exist?
+
+[[!tag patch]]
+[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv]]
+[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv]]
+
+> To have a starting point to (maybe) change this, my `ready/autoindex`
+> branch adds a regression test for the current behaviour, both with
+> and without `autoindex_commit` enabled. It also fixes an unnecessary
+> and potentially harmful special case for the transient directory.
+>
+> The fact that files in underlays (including transient files) don't
+> trigger autoindexing is deliberate. However, this is the second
+> request to change this behaviour: the first was
+> [[!debbug 611068]], which has a patch from Tuomas Jormola.
+> On that bug report, Joey explains why it's undesirable
+> for the original behaviour of autoindex (when the
+> index isn't transient).
+>
+> I'm not sure whether the same reasoning still applies when the
+> index is transient, though (`autoindex_commit => 0`),
+> because the index pages won't be cluttering up people's
+> git repositories any more? My `autoindex-more` branch changes
+> the logic so it will do what you want in the `autoindex_commit => 0`
+> case, and amends the appropriate regression test. --[[smcv]]
diff --git a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
index b2a8b0632..9f0a1d102 100644
--- a/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
+++ b/doc/bugs/wiki_links_still_processed_inside_code_blocks.mdwn
@@ -46,4 +46,22 @@ and have it render like:
> there should give some strong hints how to fix this bug, though I haven't
> tried to apply the method yet. --[[Joey]]
+>> As far, as I can see, smileys bug is solved by checking for code/pre. In
+>> this case, however, this is not applicable. WikiLinks/directives *should* be
+>> expanded before passing text to formatter, as their expansion may contain
+>> markup. Directives should be processed before, as they may provide *partial*
+>> markup (eg `template` ones), that have no sense except when in the page
+>> cotext. Links should be processed before, because, at least multimarkdown may
+>> try to expand them as anchor-links.
+>>
+>> For now, my partial solution is to restrict links to not have space at the
+>> start, this way in many cases escaping in code may be done in natural way
+>> and not break copypastability. For example, shell 'if \[[ condition ]];'
+>> will work fine with this.
+>>
+>> Maybe directives can also be restricted to only be allowed on the line by
+>> themselves (not separated by blank lines, however) or something similar.
+>>
+>> --[[isbear]]
+
[[!debbug 487397]]
diff --git a/doc/bugs/wrong_link_in_recentchanges_when_reverting_an_ikiwiki_outside_git_root.mdwn b/doc/bugs/wrong_link_in_recentchanges_when_reverting_an_ikiwiki_outside_git_root.mdwn
index bf311c198..5f7450b79 100644
--- a/doc/bugs/wrong_link_in_recentchanges_when_reverting_an_ikiwiki_outside_git_root.mdwn
+++ b/doc/bugs/wrong_link_in_recentchanges_when_reverting_an_ikiwiki_outside_git_root.mdwn
@@ -1,3 +1,8 @@
in ikiwiki instances that don't reside in the git root directory (the only ones i know of are ikiwiki itself), reverts show the wrong link in the recentchanges (for example, in the ikiwiki main repository's 4530430 and its revert, the main index page was edited, but the revert shows doc/index as a link).
the expected behavior is to compensate for the modified root directory (i.e., show index instead of doc/index).
+
+> This seems to work OK now - commit 84c4ca33 and its reversion both
+> appear correctly in [[recentchanges]]. Looking at git history,
+> Joey [[fixed this|done]] in commit 1b6c1895 before 3.20120203.
+> --[[smcv]]
diff --git a/doc/bugs/yaml:xs_codependency_not_listed.mdwn b/doc/bugs/yaml:xs_codependency_not_listed.mdwn
new file mode 100644
index 000000000..f136d8b12
--- /dev/null
+++ b/doc/bugs/yaml:xs_codependency_not_listed.mdwn
@@ -0,0 +1,13 @@
+YAML:XS is not listed as a dep in the spec file which results in
+
+```
+HOME=/home/me /usr/bin/perl -Iblib/lib ikiwiki.in -dumpsetup ikiwiki.setup
+Can't locate YAML/XS.pm in @INC (@INC contains: . blib/lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at (eval 39) line 2.
+BEGIN failed--compilation aborted at (eval 39) line 2.
+make: *** [ikiwiki.setup] Error 2
+error: Bad exit status from /var/tmp/rpm-tmp.Sgq2QK (%build)
+```
+
+when trying to build
+
+> Ok, added. [[done]] --[[Joey]]
diff --git a/doc/contact.mdwn b/doc/contact.mdwn
index 486a4d186..7d31ddf10 100644
--- a/doc/contact.mdwn
+++ b/doc/contact.mdwn
@@ -4,7 +4,7 @@ ikiwiki's own wiki. ikiwiki provides a [[bug_tracker|bugs]], a
[[TODO_list|TODO]], and "discussion" sub-pages for every page, as well as a
[[forum]] for general questions and discussion. ikiwiki
developers monitor [[RecentChanges]] closely, via the webpage, email,
-[CIA](http://cia.navi.cx), and IRC, and respond in a timely fashion.
+and IRC, and respond in a timely fashion.
You could also drop by the IRC channel `#ikiwiki` on
[OFTC](http://www.oftc.net/) (`irc.oftc.net`), or use the
diff --git a/doc/convert.mdwn b/doc/convert.mdwn
index 871cd31fe..fd4fbeac3 100644
--- a/doc/convert.mdwn
+++ b/doc/convert.mdwn
@@ -3,5 +3,7 @@ to convert it to ikiwiki? Various tools and techniques have been developed
to handle such conversions.
* [[tips/convert_mediawiki_to_ikiwiki]]
-* [[tips/convert_MoinMoin_and_TWiki_to_ikiwiki]]
+* [[tips/convert_moinmoin_to_ikiwiki]]
* [[tips/convert_blogger_blogs_to_ikiwiki]]
+
+In addition, [[JoshTriplett]] has written scripts to convert Twiki sites, see [his page](/users/JoshTriplett) for more information.
diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn
index 3f5627028..c9c6694e7 100644
--- a/doc/css_market.mdwn
+++ b/doc/css_market.mdwn
@@ -10,6 +10,10 @@ included in ikiwiki for easy use.
Feel free to add your own stylesheets here. (Upload as wiki pages; wiki
gnomes will convert them to css files..)
+* **[lessish.css](https://raw.github.com/spiffin/ikiwiki_lessish/master/lessish.css)**, contributed by [[Spiffin]],
+ A responsive stylesheet based on the [Less CSS Framework](http://lessframework.com).
+ Links: [PNG preview](https://github.com/spiffin/ikiwiki_lessish/blob/master/lessish_preview.png) and [GitHub repo](https://github.com/spiffin/ikiwiki_lessish).
+
* **[[css_market/zack.css]]**, contributed by [[StefanoZacchiroli]],
customized mostly for *blogging purposes*, can be seen in action on
[zack's blog](http://upsilon.cc/~zack/blog/)
diff --git a/doc/examples/blog/posts.mdwn b/doc/examples/blog/posts.mdwn
index 08e014838..2bd0f1d6f 100644
--- a/doc/examples/blog/posts.mdwn
+++ b/doc/examples/blog/posts.mdwn
@@ -1,3 +1,3 @@
Here is a full list of posts to the [[blog|index]].
-[[!inline pages="page(./posts/*) and !*/Discussion" archive=yes feedshow=10 quick=yes]]
+[[!inline pages="page(./posts/*) and !*/Discussion" archive=yes feedshow=10 quick=yes trail=yes]]
diff --git a/doc/examples/softwaresite/bugs/hghg.mdwn b/doc/examples/softwaresite/bugs/hghg.mdwn
new file mode 100644
index 000000000..cece64126
--- /dev/null
+++ b/doc/examples/softwaresite/bugs/hghg.mdwn
@@ -0,0 +1 @@
+hghg
diff --git a/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__.mdwn b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__.mdwn
new file mode 100644
index 000000000..c0b896515
--- /dev/null
+++ b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__.mdwn
@@ -0,0 +1,3 @@
+Is anyone successfull mirroring feeds from ikiwiki to identi.ca (or another status.net instance)? How did you set up your feed?
+
+When I try to, identi.ca presents me with an error about no "author ID URI" being found in the feed. Indeed the ikiwiki-generated atom feed only has got a global "author" - I presume identi.ca requires author information in each entry. Is it possible to set up ikiwiki's feed that way?
diff --git a/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_1_8a5acbb6234104b607c8c4cf16124ae4._comment b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_1_8a5acbb6234104b607c8c4cf16124ae4._comment
new file mode 100644
index 000000000..1d710d153
--- /dev/null
+++ b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_1_8a5acbb6234104b607c8c4cf16124ae4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Franek"
+ ip="188.99.178.40"
+ subject="[[!meta author="..."
+ date="2012-05-19T14:51:42Z"
+ content="""
+Adding [[!meta author=\"me\"]] to the entries and/or the feedpage does not help.
+"""]]
diff --git a/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_2_155e5823860a91989647ede8b5c9224a._comment b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_2_155e5823860a91989647ede8b5c9224a._comment
new file mode 100644
index 000000000..6c709b3f0
--- /dev/null
+++ b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_2_155e5823860a91989647ede8b5c9224a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Franek"
+ ip="188.99.178.40"
+ subject="Further enquiries"
+ date="2012-05-20T10:46:07Z"
+ content="""
+I did some more experiments setting not only \"[[!meta author=...\", but also \"authorurl\" globally and per-entry in various combinations, with no success. As far as I could see, \"authorurl\" had no effect on the atom feed whatsoever.
+
+It seems that identi.ca wants a feed to have an field with a subfield, as described here: [[http://www.atomenabled.org/developers/syndication/#person]] . Is there a way to achieve this with ikiwiki inline-feeds?
+
+I also found two old and unresolved status.net bugreports on the matter:
+
+[[http://status.net/open-source/issues/2840]]
+
+[[http://status.net/open-source/issues/2839]]
+"""]]
diff --git a/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_3_317f1202a3da1bfc845d4becbac4bba8._comment b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_3_317f1202a3da1bfc845d4becbac4bba8._comment
new file mode 100644
index 000000000..6bda93433
--- /dev/null
+++ b/doc/forum/Anyone_mirroring_ikiwiki_inline_feed_to_identi.ca__63__/comment_3_317f1202a3da1bfc845d4becbac4bba8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Franek"
+ ip="92.74.26.119"
+ subject="kind of solved, but another problem comes up"
+ date="2012-05-26T19:31:19Z"
+ content="""
+The templates atompage.tmpl and/or atomitem.tmpl appear to be what would have to be altered to satisfy identi.ca. I did that on my system, just hard-coding a element into for testing. In one respect, it worked: identi.ca does not complain about the missing author uri any more. In another, it did not, another error comes up now: \"Internal server error\" and something like \"could not add feed\".
+
+I do not know where to go from this very unspecific error message. I guess I am going to try something like twitterfeed.com, for now.
+"""]]
diff --git a/doc/forum/Attachment_and_sub-directory.mdwn b/doc/forum/Attachment_and_sub-directory.mdwn
new file mode 100644
index 000000000..91d7aee27
--- /dev/null
+++ b/doc/forum/Attachment_and_sub-directory.mdwn
@@ -0,0 +1,5 @@
+Hi.
+
+If I create a page and attach a file to the page, ikiwiki creates a sub-directory with the page name and places the attachment in the sub-directory regardless of usedirs setup. Is there any setup not to create the sub-directory and to place the attachment in the same directory where the page is, so that I can edit and properly *preview* at a local machine using third-party markdown editors?
+
+Thanks in advance.
diff --git a/doc/forum/Background_picture_and_css.mdwn b/doc/forum/Background_picture_and_css.mdwn
new file mode 100644
index 000000000..827100984
--- /dev/null
+++ b/doc/forum/Background_picture_and_css.mdwn
@@ -0,0 +1,8 @@
+Is it possible to put two different background pictures into the right and left sides of the following ikiwiki css?
+
+[lessish css theme](https://raw.github.com/spiffin/ikiwiki_lessish/master/lessish.css)
+
+Is it also possible to have a background like this: [http://ysharifi.wordpress.com/](http://ysharifi.wordpress.com/)
+or this [tex.stackexchange.com](tex.stackexchange.com)
+
+I am not a css expert so, it would be nice if you could provide some details.
diff --git a/doc/forum/CGI_script_and_HTTPS.mdwn b/doc/forum/CGI_script_and_HTTPS.mdwn
new file mode 100644
index 000000000..2f255002d
--- /dev/null
+++ b/doc/forum/CGI_script_and_HTTPS.mdwn
@@ -0,0 +1,29 @@
+Dear ikiwiki folks,
+
+using Debian Wheezy and ikiwiki 3.20120629 for some reason when accessing the site using HTTP (and not HTTPS), going to Edit, so executing the CGI script, all URLs are prepended with HTTPS, which I do not want.
+
+
+
+Trying to look at the source, I guess it is originating from `IkiWiki/CGI.pm`.
+
+ sub printheader ($) {
+ my $session=shift;
+
+ if (($ENV{HTTPS} && lc $ENV{HTTPS} ne "off") || $config{sslcookie}) {
+ print $session->header(-charset => 'utf-8',
+ -cookie => $session->cookie(-httponly => 1, -secure => 1));
+ }
+ else {
+ print $session->header(-charset => 'utf-8',
+ -cookie => $session->cookie(-httponly => 1));
+ }
+ }
+
+Does it check if HTTPS is enabled in the environment? During `ikiwiki --setup example.setup` or when the CGI script is run when the site is accessed (for example in an Apache environment)?
+
+Can this somehow be disabled in ikiwiki. Reading the code I guess I could somehow set `HTTPS = off` somewhere in the `VirtualHost` section of the Apache configuration.
+
+
+Thanks,
+
+--[[PaulePanter]]
diff --git a/doc/forum/CGI_script_and_HTTPS/comment_1_3f8ef438ca7de11635d4e40080e7baa9._comment b/doc/forum/CGI_script_and_HTTPS/comment_1_3f8ef438ca7de11635d4e40080e7baa9._comment
new file mode 100644
index 000000000..03f1032e9
--- /dev/null
+++ b/doc/forum/CGI_script_and_HTTPS/comment_1_3f8ef438ca7de11635d4e40080e7baa9._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="comment 1"
+ date="2012-11-05T11:27:02Z"
+ content="""
+IkiWiki generates self-referential URLs using the `url` and `cgiurl`
+configuration parameters, and the `urlto()` and `cgiurl()` functions;
+the code you quoted isn't involved (it's choosing whether to set
+HTTPS-only cookies or not, rather than choosing how to generate
+self-referential URLs).
+
+If you want your wiki to be accessible via both HTTP and HTTPS, and use
+whichever the user first requested, you should set both `url` and
+`cgiurl` to the same URI scheme and hostname with no port specified,
+either both `http` or both `https`, for instance:
+
+ url: http://www.example.com/
+ cgiurl: http://www.example.com/ikiwiki.cgi
+
+or
+
+ url: https://example.org/wiki/
+ cgiurl: https://example.org/cgi-bin/ikiwiki
+
+(or the Perl-syntax equivalents if you're not using a YAML
+setup file).
+
+If you use one of those, IkiWiki will attempt to generate
+path-only links, like \"/wiki/\" and \"/cgi-bin/ikiwiki?...\",
+whenever it's valid to do so. A visitor using HTTP will stay
+on HTTP and a visitor using HTTPS will stay on HTTPS.
+
+The choice of `http` or `https` for the `url` and `cgiurl`
+still matters when a URL *must* be absolute, such as in an
+RSS feed.
+
+I improved this code in late 2010 for this todo item:
+[[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]].
+It's possible that it has regressed (that's happened
+a couple of times). If it has, please quote your exact
+`url` and `cgiurl` configuration.
+"""]]
diff --git a/doc/forum/Calendar:_listing_multiple_entries_per_day.mdwn b/doc/forum/Calendar:_listing_multiple_entries_per_day.mdwn
index 51c320067..251cd6d9f 100644
--- a/doc/forum/Calendar:_listing_multiple_entries_per_day.mdwn
+++ b/doc/forum/Calendar:_listing_multiple_entries_per_day.mdwn
@@ -4,7 +4,7 @@ I'd very much like to be able to list my blog posts on a daily basis (used for l
There was some effort to do this as detailed here.
-[[http://ikiwiki.info/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin/]]
+[[todo/Set_arbitrary_date_to_be_used_by_calendar_plugin]]
I had a quick go at doing something similar on Debian Stable (Ikiwiki 3.0) but alas my Ikiwiki fu is not strong enough.
@@ -15,3 +15,5 @@ I'm not sure how I go about swapping the link on the day number to a link to, I
and a suitable whilst loop looks to be all that's needed...
Any pointers appreciated.
+
+A [[!taglink patch]] has been proposed in [comment](#comment-d6f94e2b779d1c038b6359aad79ed14b)
diff --git a/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_4_4be39c2043821848d4b25d0bf946a718._comment b/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_4_4be39c2043821848d4b25d0bf946a718._comment
new file mode 100644
index 000000000..a71276d6b
--- /dev/null
+++ b/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_4_4be39c2043821848d4b25d0bf946a718._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2012-02-21T17:23:00Z"
+ content="""
+To be clear, this patch creates a `yyyy/mm/dd` file for each day, listing the posts for that day, so the calendar can link to it rather than a random single post.
+
+While a valid solution certainly, that's a lot of added pages! Especially a high overhead for such a minor UI point as this.
+
+Surely something interesting could be done with javascript or some other form of UI to make clicking on a day in a calendar that has multiple posts present a list of them? That would have essentially no overhead, since the calendar plugin already has a list of the posts made on a given day.
+
+Ikiwiki already does something similar to deal with the case where a page has a great many backlinks.. It makes a UI element that, if hovered over, pops up a display of all the rest. This is done quite simply in the `page.tmpl`
+using the popup and balloon CSS classes. Calendar could also use this.
+"""]]
diff --git a/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_5_de545ebb6376066674ef2aaae4757b9c._comment b/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_5_de545ebb6376066674ef2aaae4757b9c._comment
new file mode 100644
index 000000000..fef852066
--- /dev/null
+++ b/doc/forum/Calendar:_listing_multiple_entries_per_day/comment_5_de545ebb6376066674ef2aaae4757b9c._comment
@@ -0,0 +1,97 @@
+[[!comment format=mdwn
+ username="spalax"
+ subject="Popup listing multiple entries per day"
+ date="2012-06-08T00:56:06Z"
+ content="""
+[[!tag patch]]
+
+Hello,
+here is a patch that:
+
+- if there is a single entry in one day, does not change anything (compared to the previous version of the calendar plugin);
+- if there are several entries, when mouse passes over the day, displays a popup listing all the entries of that day.
+
+That's all. No new pages for each day, takes as little space as it took before, and only a few lines more in the source.
+
+The only thing I am not totally happy with is the CSS. We have to say that the text is aligned on the left (otherwise, it is aligned on the right, as is each day of the calendar), but I do not know which place is the more sensible to put that line of CSS in.
+
+Regards,
+-- Louis
+
+
+ diff --git a/IkiWiki/Plugin/calendar.pm b/IkiWiki/Plugin/calendar.pm
+ index d443198..2c9ed79 100644
+ --- a/IkiWiki/Plugin/calendar.pm
+ +++ b/IkiWiki/Plugin/calendar.pm
+ @@ -86,8 +86,11 @@ sub format_month (@) {
+ my $year = $date[5] + 1900;
+ my $mtag = sprintf(\"%02d\", $month);
+
+ - # Only one posting per day is being linked to.
+ - $linkcache{\"$year/$mtag/$mday\"} = $p;
+ + # Several postings per day
+ + if (! $linkcache{\"$year/$mtag/$mday\"}) {
+ + $linkcache{\"$year/$mtag/$mday\"} = [];
+ + }
+ + push(@{$linkcache{\"$year/$mtag/$mday\"}}, $p);
+ }
+
+ my $pmonth = $params{month} - 1;
+ @@ -221,11 +224,36 @@ EOF
+ $tag='month-calendar-day-link';
+ }
+ $calendar.=qq{\t\t
};
+ - $calendar.=htmllink($params{page}, $params{destpage},
+ - $linkcache{$key},
+ - noimageinline => 1,
+ - linktext => $day,
+ - title => pagetitle(IkiWiki::basename($linkcache{$key})));
+ + if ( scalar(@{$linkcache{$key}}) == 1) {
+ + # Only one posting on this page
+ + my $page = $linkcache{$key}[0];
+ + $calendar.=htmllink($params{page}, $params{destpage},
+ + $page,
+ + noimageinline => 1,
+ + linktext => $day,
+ + title => pagetitle(IkiWiki::basename($page)));
+ + } else {
+ + $calendar.=qq{
$day
};
+ + # Several postings on this page
+ + $calendar.=qq{
\n};
+ }
+ else {
+ diff --git a/doc/style.css b/doc/style.css
+ old mode 100644
+ new mode 100755
+ index 6e2afce..4149229
+ --- a/doc/style.css
+ +++ b/doc/style.css
+ @@ -316,6 +316,7 @@ div.progress-done {
+ .popup .paren,
+ .popup .expand {
+ display: none;
+ + text-align: left;
+ }
+ .popup:hover .balloon,
+ .popup:focus .balloon {
+
+"""]]
diff --git a/doc/forum/Can_I_have_different_favicons_for_each_folder__63__/comment_2_b8ccd3c29249eca73766f567bce12569._comment b/doc/forum/Can_I_have_different_favicons_for_each_folder__63__/comment_2_b8ccd3c29249eca73766f567bce12569._comment
new file mode 100644
index 000000000..0c8ca3bce
--- /dev/null
+++ b/doc/forum/Can_I_have_different_favicons_for_each_folder__63__/comment_2_b8ccd3c29249eca73766f567bce12569._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Franek"
+ ip="178.7.43.64"
+ subject="comment 2"
+ date="2012-06-25T09:58:03Z"
+ content="""
+I did as you suggested (finally) and created a simple modification of the [[plugins/favicon]] plugin: [[plugins/contrib/localfavicon]]. It checks for the \"localfavicon\" option, and if it is set, it uses bestlink() to determine which favicon to use for each page; if not, it behaves just like the original favicon plugin.
+"""]]
diff --git a/doc/forum/Can_not_advance_past_first_page_of_results_using_search_plugin.mdwn b/doc/forum/Can_not_advance_past_first_page_of_results_using_search_plugin.mdwn
new file mode 100644
index 000000000..1a9391e48
--- /dev/null
+++ b/doc/forum/Can_not_advance_past_first_page_of_results_using_search_plugin.mdwn
@@ -0,0 +1,26 @@
+I'm using the [[/plugins/search/]] plugin and it correctly displays the first page of results, but the "Next" button doesn't work.
+
+If I search for "linux", for example, I see "1-10 of exactly 65 matches" and this in my browser's address bar: https://example.com/ikiwiki.cgi?P=linux
+
+Then, I scroll down and click "Next" and I see. . .
+
+> Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.
+>
+> Are you sure you want to continue sending this information?
+
+. . . then I click "Continue" but I'm stuck on the first page of search results (it still says "1-10 of exactly 65 matches") and I have the following in my browser's address bar:
+
+https://example.com/ikiwiki.cgi?P=linux&DEFAULTOP=or&%253E=Next&DB=default&FMT=query&xP=Zlinux&xDB=default&xFILTERS=--O
+
+I noticed that if I change what's in the address bar to the following, I **can** advance to page 2 (it shows "11-20 of exactly 65 matches"). That is to say, I'm removing "25" from "%253E" as a work around:
+
+https://example.com/ikiwiki.cgi?P=linux&DEFAULTOP=or&%3E=Next&DB=default&FMT=query&xP=Zlinux&xDB=default&xFILTERS=--O
+
+Based on this output, I might need to make a change to "searchquery.tmpl", which is under [[/templates]]. . .
+
+ [wikiuser@ikiwiki1 ~]$ grep -r DEFAULTOP /usr/share/ikiwiki
+ /usr/share/ikiwiki/templates/searchquery.tmpl: