Merge commit 'upstream/master' into prv/po

10 files changed, 101 insertions, 3 deletions

diff --git a/doc/bugs/Error:_Your_login_session_has_expired._.mdwn b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn
new file mode 100644
index 000000000..046d6e10d
--- /dev/null
+++ b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn
@@ -0,0 +1,44 @@
+I keep getting:
+
+	Error: Your login session has expired.
+
+Whilst trying to edit http://hugh.vm.bytemark.co.uk/ikiwiki.cgi via OpenID. Any ideas?
+
+
+	iki@hugh:~$ dpkg -l | grep openid
+	ii  libnet-openid-consumer-perl     0.14-4                library for consumers of OpenID iden
+	tities
+	iki@hugh:~$
+
+> This error occurs if ikiwiki sees something that looks like a CSRF
+> attack. It checks for such an attack by embedding your session id on the
+> page edit form, and comparing that id with the session id used to post
+> the form.
+> 
+> So, somehow your session id has changed between opening the edit form and
+> posting it. A few ways this could happen:
+> 
+> * Genuine CSRF attack (unlikely)
+> * If you logged out and back in, in another tab, while the edit form was
+>   open.
+> * If `.ikiwiki/sessions.db` was deleted/corrupted while you were in the
+>   midst of the edit.
+> * If some bug in CGI::Session caused your session not to be saved to the
+>   database somehow.
+> * If your browser didn't preserve the session cookie across the edit
+>   process, for whatever local reason.
+> * If you were using a modified version of `editpage.tmpl`, and 
+>   it did not include `FIELD-SID`.
+> * If you upgraded from an old version of ikiwiki, before `FIELD-SID` was
+>   added (<= 2.41), and had an edit form open from that old version, and
+>   tried to save it using the new.
+>  
+> I don't see the problem editing the sandbox there myself, FWIW.
+> (BTW, shouldn't you enable the meta plugin so RecentChanges displays
+> better?)
+> --[[joey]]
+
+
+Thanks for you excellent analysis. The bug was due to old pre-3.0 **templates** laying about. After deleting them, ikiwiki defaults to its own templates. Clever. :-)
+
+[[bugs/done]]
diff --git a/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn b/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn
new file mode 100644
index 000000000..59b67d493
--- /dev/null
+++ b/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn
@@ -0,0 +1,19 @@
+I've noticed that Ikiwiki displays URLs with parentheses badly. The problem occurs
+in the latest version 3.00 and older versions. Please look at the link to following
+Polish entry about C programming language at Wikipedia (it seems that URLs with
+parentheses are popular there):
+
+[Język programowania C](http://pl.wikipedia.org/wiki/C_(j%C4%99zyk_programowania))
+
+I need to escape a closing parenthesis of the URL to fix the problem.
+
+[Język programowania C](http://pl.wikipedia.org/wiki/C_(j%C4%99zyk_programowania\))
+
+--[[Paweł|users/ptecza]]
+
+> This is a bug in markdown version 1. It is fixed in [[!cpan Text::Markdown]],
+> which ikiwiki will use if it's installed. [[done]] --[[Joey]] 
+
+>> Thanks a lot for the hint, Joey! I've installed `libtext-markdown-perl` package
+>> (Aptitude has removed `markdown` package to satisfy dependencies) and now
+>> I don't need to escape Wikipedia URLs with parentheses :) --[[Paweł|users/ptecza]]
diff --git a/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn b/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn
index 88a187dfc..12c0ad07f 100644
--- a/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn
+++ b/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn
@@ -24,4 +24,9 @@ Here is a patch against ikiwiki-1.51 for using find(1) and install(1) instead of
 
 >> No, apparently FreeBSD `install` does not support `-D`.  See [the FreeBSD install manpage](http://www.freebsd.org/cgi/man.cgi?query=install&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html). --[[JoshTriplett]]
 
->> Patch applied; [[bugs/done]]. --[[JoshTriplett]]
+>> Patch applied; [[done]]. --[[JoshTriplett]]
+
+There are still/again "cp -a"s in the Makefile as of 3.00
+
+> It's a cp -a || install. Is that causing you a problem somehow?
+> --[[Joey]] 
diff --git a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
index 012fcec2c..02ce4e221 100644
--- a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
+++ b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
@@ -3,8 +3,8 @@ matches all other pages, including all internal pages. This can lead to
 unexpected results, since it will match a bunch of recentchanges pages,
 etc.
 
-Recall that internal-use pages are not matched by a glob. So "*" doesn't
-match them. So if the pagespec is "* and !foo and !bar", it won't match
+Recall that internal-use pages are not matched by a glob. So "\*" doesn't
+match them. So if the pagespec is "\* and !foo and !bar", it won't match
 them. This is the much more common style.
 
 There's an odd inconsistency with entirely negated pagespecs. If "!foo"
diff --git a/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn b/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn
index c465bdd4a..564982ff3 100644
--- a/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn
+++ b/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn
@@ -8,3 +8,7 @@ cases of the one which was installed directly before the current commit.
 > I don't see one, except for diffs that show all changes in the commit,
 > rather than only changes to a single file. This feels like a bug in
 > gitweb. --[[Joey]]
+
+This is fixed by using the new gitweb style urls. Which new gitweb
+requires, but is a manual change you have to make in your setup. So,
+[[done]] --[[Joey]] 
diff --git a/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn b/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn
index 255d9cee7..0b4d70596 100644
--- a/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn
+++ b/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn
@@ -8,3 +8,6 @@ Going from *RecentChanges*, when viewing the diffs of newly created pages
 > I don't see any way to make gitweb do that. You can click on the filename
 > after the "diff -cc" to see the whole file output, but gitweb won't show
 > a diff for a newly added file. --[[Joey]]
+
+>> happily this, too, is fixed by using the new style gitweb urls. [[done]]
+>> --[[Joey]] 
diff --git a/doc/bugs/links_misparsed_in_CSV_files.mdwn b/doc/bugs/links_misparsed_in_CSV_files.mdwn
index 169c070e7..27d2b7b1e 100644
--- a/doc/bugs/links_misparsed_in_CSV_files.mdwn
+++ b/doc/bugs/links_misparsed_in_CSV_files.mdwn
@@ -12,6 +12,16 @@ Oh, wait, I see the problem. IkiWiki::linkify is only called if the external fil
 
 (this is inside /usr/share/perl5/IkiWiki/Plugin/table.pm).
 
+> To reproduce this bug, I had to install the old, broken markdown 1.0,
+> instead of the now-default Text::Markdown.
+> 
+> Why is linkify not called for external files? Well, I checked the
+> history, and it's probably best to say "for historical reasons that no
+> longer apply". So, changed as you suggest. [[done]] --[[Joey]] 
+
 I am rather confused what this check does, and the fact the comments are very different for CSV and DSV when the code is the same doesn't seem to help.
 
+> The code is not the same; two operations are run in different orders for
+> CSV and DSV, as the comments note. --[[Joey]] 
+
 -- Brian May
diff --git a/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn b/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn
index 2d9677e7f..132d23463 100644
--- a/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn
+++ b/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn
@@ -10,3 +10,5 @@ The following pages have been automatically modified to update their links to us
 <li><a href="./../../tips/convert_mediawiki_to_ikiwiki/discussion/">discussion</a></li><li><a href="./../../tips/untrusted_git_push/discussion/">discussion</a></li></ul>...
 
 In this situation I think the link to pages should be expanded to show the entire path, since there is quite likely to be a lot of things like "discussion". -- [[users/Jon]]
+
+[[done]]
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 158656a13..cccd53d05 100644
--- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
+++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
@@ -14,3 +14,5 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title
 >> It was actually more complicated than expected. A working prototype is
 >> now in my `meta` branch, see my userpage for the up-to-date url.
 >> Thus tagging [[patch]]. --[[intrigeri]]
+>>
+>>> Joey, please consider merging my `meta` branch. --[[intrigeri]]
diff --git a/doc/bugs/table_external_file_links.mdwn b/doc/bugs/table_external_file_links.mdwn
new file mode 100644
index 000000000..7b35383c5
--- /dev/null
+++ b/doc/bugs/table_external_file_links.mdwn
@@ -0,0 +1,9 @@
+If wikilinks are put in an external table file, those links are not seen at
+scan time, and so ikiwiki does not know to update the page containing the
+table when the pages the links point to change (are added, removed, etc).
+
+There seem only two solutions to that bug -- either really make wikilinks
+in an external table file not work (probably by escaping them), 
+or run the preprocess code also in scan (expensive!). --[[Joey]]
+
+[[done]]