diff options
Diffstat (limited to 'doc/bugs')
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]] |