Merge branch 'master' into darcs

14 files changed, 119 insertions, 34 deletions

diff --git a/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn b/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn
index a95378851..7daf52f2a 100644
--- a/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn
+++ b/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn
@@ -1,3 +1,5 @@
-If I create a page whose title contains an apostrophe, then inlining that page produces nothing.  It looks like the inline plugin is failing to do the translation from apostrophe to "_39_" that other parts of the system do, so although one can make wikilinks to such pages and have them detected as existing (for instance, by the conditional plugin), inline looks in the wrong place and doesn't see the page.
+If I create a page whose title contains an apostrophe, then inlining that
+page produces nothing.  It looks like the inline plugin is failing to do
+the translation from apostrophe to `_39_` that other parts of the system do, so although one can make wikilinks to such pages and have them detected as existing (for instance, by the conditional plugin), inline looks in the wrong place and doesn't see the page.
 
 > I can't reproduce that (btw, an apostrophe would be `__39__`) --[[Joey]]
diff --git a/doc/bugs/MTIME_not_set_for_inline_or_archive_entries.mdwn b/doc/bugs/MTIME_not_set_for_inline_or_archive_entries.mdwn
new file mode 100644
index 000000000..89947b544
--- /dev/null
+++ b/doc/bugs/MTIME_not_set_for_inline_or_archive_entries.mdwn
@@ -0,0 +1,22 @@
+My <code>page.tmpl</code> can contain:
+
+    Created <TMPL_VAR CTIME>.  Last edited <TMPL_VAR MTIME>.
+ 
+and that works.  However, if I have the same line in <code>inlinepage.tmpl</code> 
+or <code>archivepage.tmpl</code>, then only the <code>CTIME</code> works - the <code>MTIME</code> is blank.
+This leads to an annoying inconsistency.
+
+Update - even though I'm not a Perl programmer, this patch seems right:
+
+    --- /home/bothner/ikiwiki/ikiwiki/IkiWiki/Plugin/inline.pm	2008-10-01 14:29:11.000000000 -0700
+    +++ ./inline.pm	2008-10-12 13:26:11.000000000 -0700
+    @@ -316,6 +316,7 @@
+     				$template->param(pageurl => urlto(bestlink($params{page}, $page), $params{destpage}));
+     				$template->param(title => pagetitle(basename($page)));
+     				$template->param(ctime => displaytime($pagectime{$page}, $params{timeformat}));
+    +				$template->param(mtime => displaytime($pagemtime{$page}, $params{timeformat}));
+     				$template->param(first => 1) if $page eq $list[0];
+     				$template->param(last => 1) if $page eq $list[$#list];	
+
+
+> [[done]], thanks
diff --git a/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn b/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn
deleted file mode 100644
index 65406680a..000000000
--- a/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-Page footers contain a list of links to the page and a list of tags applied to the page.  The link list uses the full path to pages.  However, the tag list contains only the basename of the tag pages.  For instance, if I tag a page with person1/foo and person2/bar, the tag list will just list foo and bar without the necessary disambiguating prefixes.
-
-I think the tag list should always contain the full path to the tag, with the tagbase value removed.
-
---[[JoshTriplett]]
diff --git a/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn b/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn
index 94a0e5445..eb3450a7e 100644
--- a/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn
+++ b/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn
@@ -44,3 +44,4 @@ unless that has security implications.
 >>
 >> I hope that's just a minor blemish. --liw
 
+>>> Sounds like this is [[done]] --[[Joey]]
diff --git a/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn b/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn
index 61f6f733a..865637ea4 100644
--- a/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn
+++ b/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn
@@ -11,3 +11,5 @@ appropriately, so that ikiwiki reflects the actual time of the post via the
 		if defined $mtime && $mtime <= time;
 
 >> I'll have to debug this, it's not working here... and this is an ikiwiki aggregator scraping another ikiwiki site.
+
+>>> Any news about this? --[[Joey]]
diff --git a/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn b/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn
index c57c20065..eead716d5 100644
--- a/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn
+++ b/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn
@@ -28,3 +28,23 @@ If I then edit the blog post, **then** the file gets commited and I can see the
 >>>> However, the part that seems a bit wrong to me, is this: even if my locale is utf8, I have to explicitly set a utf8 locale in the wiki's setup file, or the commit fails. It looks like ikiwiki is not using this machine's default locale, which is utf8. Also, I'm not getting any errors on apache's error log.
 
 >>>> Wouldn't it make sense to use the machine's default locale if 'locale' is commented out in the setup file?
+
+>>>>> Ikiwiki wrappers only allow whitelisted environment variables
+>>>>> through, and the locale environment variables are not included
+>>>>> currently.
+>>>>>
+>>>>> But that's not the whole story, because "machine's default locale"
+>>>>> is not very well defined. For example, my laptop is a Debian system.
+>>>>> It has a locale setting in /etc/environment (`LANG="en_US.UTF-8"`).
+>>>>> But even if I start apache, making sure that LANG is set and exported
+>>>>> in the environment, CGI scripts apache runs do not see LANG in their 
+>>>>> environment. (I notice that `/etc/init.d/apache` explocitly
+>>>>> forces LANG=C. But CGI scripts don't see the C value either.)
+>>>>> Apache simply does not propigate its runtime environment to CGI
+>>>>> scripts, and this is probably to comply with the CGI specification
+>>>>> (although it doesn't seem to completly rule out CGI's being passed
+>>>>> other variables).
+>>>>>
+>>>>> If mercurial needs a utf-8 locale, I guess the mercurial plugin needs
+>>>>> to check if it's not in one, and do something sane (either fail
+>>>>> earlier, or complain, or strip utf-8 out of comments). --[[Joey]]
diff --git a/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn b/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn
index b195f48ee..a74f6fcc7 100644
--- a/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn
+++ b/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn
@@ -4,4 +4,4 @@ Presumably this is because websetup loads all plugins, so IkiWiki::plugin::ddate
 
 (This bug seems oddly appropriate. Hail Eris)
 
-[[done fnord|done]]
+[[done_fnord|done]]
diff --git a/doc/bugs/disabling_backlinks.mdwn b/doc/bugs/disabling_backlinks.mdwn
index 74b25f0f0..ba96a4e2b 100644
--- a/doc/bugs/disabling_backlinks.mdwn
+++ b/doc/bugs/disabling_backlinks.mdwn
@@ -12,3 +12,19 @@ My first reading (and second and third) of this was that backlinks would be disa
 > Yes, it only controls the number of backlinks that are shown at the
 > bottom of the page vs how many are moved to the popup. I've tried to
 > improve the documentation for this. [[done]] --[[Joey]]
+
+
+I notice that there is quite a bit of redundancy when both tags and
+backlinks are used extensively. On most pages, the set of links features in
+both categories is almost identical because a tag's index page is shown
+both as a tag link and as a backlink. Is there a way to improve that
+situation somehow? I realise that backlinks aren't generated when the tag
+index page refers to its contents by \[\[!map ...]], etc., but sometimes an
+auto-generated index is insufficient.
+
+ --Peter
+
+> Um, if you're manually linking from the tag's page to each page so
+> tagged, I think you have larger problems than tags and backlinks being
+> the same. Like keeping that list of links up to date as tags are added
+> and changed. --[[Joey]]
diff --git a/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn b/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn
new file mode 100644
index 000000000..8cfd42e78
--- /dev/null
+++ b/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn
@@ -0,0 +1,13 @@
+I can make an image link, such as:
+
+    ![image](image.jpg)
+
+That will render as ![image](image.jpg).
+
+If I then inline that page, the (relative) URL no longer points to the right place.  The fix for this promises to be hairy.
+
+> Similarly, if you insert a relative link using the markdown link syntax,
+> it will tend to break when the page is inlined.
+> 
+> However, there is a simple way to avoid both problems: Use WikiLinks
+> and/or the [[img_directive|ikiwiki/directive/img]]. --[[Joey]]
diff --git a/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn
new file mode 100644
index 000000000..61aeff244
--- /dev/null
+++ b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn
@@ -0,0 +1,20 @@
+If I put something like the below in my index.mdwn
+
+    <<!inline pages="posts/* and !*/discussion" rootpage="posts" show="10">>
+
+But posts doesn't exist, I get the following in index.html
+
+    <input type="hidden" name="do" value="blog" />
+    <input type="hidden" name="from" value="" />
+    <input type="hidden" name="subpage" value="1" />
+
+When I create posts (touch posts.mdwn), I get the following in index.html
+
+    <input type="hidden" name="do" value="blog" />
+    <input type="hidden" name="from" value="posts" />
+    <input type="hidden" name="subpage" value="1" />
+
+Bug?
+
+> Yes, thanks for reminding me I need to do something about that... [[done]]
+> --[[Joey]]
diff --git a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn
index 63c5b5e08..c835d9f98 100644
--- a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn
+++ b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn
@@ -1,3 +1,17 @@
 [[plugins/lockedit]] adds the form fields for a [[pagespec]] to preferences. This pagespec should be supplied "raw"; i.e., without quotes around it. Inexperienced users (such as [[myself|jondowland]]) may provide an invalid pagespec, such as one with quotes on it. This will be merrily accepted by the form, but will cause no locking to take place.
 
 Perhaps some validation should be performed on the pagespec and the form-submission return include "warning: this pagespec is invalid" or "warning: this pagespec does not match any existing pages" or similar.
+
+> The pagespec is no longer in the preferences and instead in the setup
+> file now. That makes warning about a problem with it harder.
+> 
+> Ikiwiki could try to detect this problem and warn at setup time to
+> stderr, I guess.
+> 
+> Main problem is I see little way to actually detect the problem you
+> described. A pagespec with quotes around it is valid. For example, the
+> pagespec `"foo or bar"` matches a page named `"foo` or a page named `bar"`.
+>
+> There are small classes of invalid pagespecs. For example, `(foo or bar`
+> is invalid due to having unbalanced parens, while `foo or and bar` 
+> has invalid syntax. It's possible to detect these, I guess ... --[[Joey]]
diff --git a/doc/bugs/relative_links.mdwn b/doc/bugs/relative_links.mdwn
deleted file mode 100644
index a1dc8f373..000000000
--- a/doc/bugs/relative_links.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-It looks like all links in websites are absolute paths, this has some limitations:
-
-* If connecting to website via https://... all links will take you back to http://
-* Makes it harder to mirror website via HTML version, as all links have to be updated.
-
-It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested.
-
--- Brian May
-
-> Er, which absolute links are you talking about? If you view the source
-> to this page, you'll find links such as "../favicon.ico", "../style.css",
-> "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
-> --[[Joey]]
-
->> The problem is within the CGI script. The links within the HTML page are all absolute, including links to the css file.
->> Having a http links within a HTML page retrieved using https upset most browsers (I think). Also if I push cancel on the edit page in https, I end up at at http page. -- Brian May
-
->>> Ikiwiki does not hardcode http links anywhere. If you don't want
->>> it to use such links, change your configuration to use https
->>> consistently. --[[Joey]]
-
-Errr... That is not a solution, that is a work around. ikiwiki does not hard code the absolute paths, but absolute paths are hard coded in the configuration file. If you want to serve your website so that the majority of users can see it as http, including in rss feeds (this allows proxy caches to cache the contents and has reduced load requirements), but editing is done via https for increased security, it is not possible. I have some ideas how this can be implemented (as ikiwiki has the absolute path to the CGI script and the absolute path to the destination, it should be possible to generate a relative path from one to the other), although some minor issues still need to be resolved. -- Brian May
-
-I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt;
-which seems to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL set? -- Brian May
-
-> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn
index 8348ed470..8c7d8134d 100644
--- a/doc/bugs/rst_tweak.mdwn
+++ b/doc/bugs/rst_tweak.mdwn
@@ -20,3 +20,10 @@ Index: IkiWiki/Plugin/rst.pm
  print html[html.find('<body>')+6:html.find('</body>')].strip();
  ";
 </pre>
+
+----
+
+Does the Perl version of this plugin still exist?  There appears to be no "rst.pm" in the current distribution; all there is is the python version. --Peter
+
+> No, only the python version exists. It does have `raw_enabled` set.
+> --[[Joey]]
diff --git a/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn b/doc/bugs/some_strings_are_not_internationalized.mdwn
index a1b38257a..a1b38257a 100644
--- a/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn
+++ b/doc/bugs/some_strings_are_not_internationalized.mdwn