diff options
Diffstat (limited to 'doc/bugs')
103 files changed, 2696 insertions, 47 deletions
diff --git a/doc/bugs/2.45_Compilation_error.mdwn b/doc/bugs/2.45_Compilation_error.mdwn index c69c2fc25..63147b656 100644 --- a/doc/bugs/2.45_Compilation_error.mdwn +++ b/doc/bugs/2.45_Compilation_error.mdwn @@ -189,3 +189,10 @@ Would you suggest I try rebuilding perl without this patch? Debian has a huge pe it's not straightforward for me to see if they do something similar to Arch. > I think Debian has a similar patch. + +--- + +[[done]] -- apparently this was a problem due to a distribution's +customisation to perl, or something. Seems to late now to track down what, +unfortunatly. And ikiwiki's Makefile no longer uses the "-libdir" switch +that seemed to trigger the bug. --[[Joey]] diff --git a/doc/bugs/404_plugin_and_lighttpd.mdwn b/doc/bugs/404_plugin_and_lighttpd.mdwn new file mode 100644 index 000000000..e478d98c3 --- /dev/null +++ b/doc/bugs/404_plugin_and_lighttpd.mdwn @@ -0,0 +1,35 @@ +Lighttpd apparently sets REDIRECT_STATUS=200 for the server.error-handler-404 page. This breaks the [[plugins/404]] plugin which checks this variable for 404 before processing the URI. It also doesn't seem to set REDIRECT_URL. + +I was able to fix my server to check the REQUEST_URI for ikiwiki.cgi and to continue processing if it was not found, passing $ENV{SEVER_NAME} . $ENV{REQUEST_URI} as the first parameter to cgi_page_from_404. However, my perl is terrible and I just made it work rather than figuring out exactly what to do to get it to work on both lighttpd and apache. + +This is with lighttpd 1.4.19 on Debian. + +> /cgi-bin/ikiwiki.cgi?do=goto also provides redirection in the same way, +> if that's any help? You might need to set the lighttpd 404 handler to +> that, then compose REDIRECT_URL from other variables if necessary. +> +> I originally wrote the plugin for Apache; [[weakish]] contributed the +> lighttpd docs and might know more about how to make it work there. +> --[[smcv]] + +>> As I said, I got it working for me, but somebody who knows perl should probably look at it with the aim of making it work for everyone. +>> I considered having lighttpd construct a proper url for the 404 redirect itself, but I don't know if it can do something like that or not. +>> For what it's worth, here's the change I made to the module: + + sub cgi ($) { + my $cgi=shift; + if ($ENV{REQUEST_URI} !~ /ikiwiki\.cgi/) { + my $page = cgi_page_from_404( + Encode::decode_utf8($ENV{SERVER_NAME} . $ENV{REQUEST_URI}), + $config{url}, $config{usedirs}); + IkiWiki::Plugin::goto::cgi_goto($cgi, $page); + } + + # if (exists $ENV{REDIRECT_STATUS} && + # $ENV{REDIRECT_STATUS} eq '404') { + # my $page = cgi_page_from_404( + # Encode::decode_utf8($ENV{REDIRECT_URL}), + # $config{url}, $config{usedirs}); + # IkiWiki::Plugin::goto::cgi_goto($cgi, $page); + # } + } diff --git a/doc/bugs/Another_UTF-8_problem.mdwn b/doc/bugs/Another_UTF-8_problem.mdwn index 031576f00..d67ed2fa0 100644 --- a/doc/bugs/Another_UTF-8_problem.mdwn +++ b/doc/bugs/Another_UTF-8_problem.mdwn @@ -11,3 +11,6 @@ with my pretty standard Ubuntu gutsy Firefox installation? --[[tschwinge]] > removed that line to fix it. --[[Joey]] [[!tag done]] + +Now we test it for Cyrillic and Western letters: +Протестируем кириллицу и ещё «_другие_» буквы: grüne Öl & hôtel — 3² × 2° --Shoorick diff --git a/doc/bugs/Building_a_sidebar_does_not_regenerate_the_subpages.mdwn b/doc/bugs/Building_a_sidebar_does_not_regenerate_the_subpages.mdwn index 596719a8b..419292930 100644 --- a/doc/bugs/Building_a_sidebar_does_not_regenerate_the_subpages.mdwn +++ b/doc/bugs/Building_a_sidebar_does_not_regenerate_the_subpages.mdwn @@ -6,4 +6,3 @@ If sandbox/page.mdwn has been generated and sandbox/sidebar.mdwn is created, the # adding a new sidebar page. So adding such a page # currently requires a wiki rebuild. add_depends($page, $sidebar_page); - 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 7daf52f2a..3e1fe823e 100644 --- a/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn +++ b/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn @@ -3,3 +3,5 @@ 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]] + +[[done]] diff --git a/doc/bugs/Comments_dissapeared.mdwn b/doc/bugs/Comments_dissapeared.mdwn new file mode 100644 index 000000000..787f18c98 --- /dev/null +++ b/doc/bugs/Comments_dissapeared.mdwn @@ -0,0 +1,69 @@ +Although I have comments enabled and I have been using them successfully for ages now, I've come to notice that they have stopped working in the last week or two. + +I am running version 3.20100312 with the following configuration: + +<http://static.natalian.org/2010-03-27/natalian.txt> + +In my (HTML5 modified page.tmpl) it doesn't seem to enter the "TMPL_IF COMMENTS" block anymore. I tried the stock page.tmpl and they didn't seem to work either, so the variable name hasn't changed has it? + +Any other ideas? With thanks, + + comments_pagespec => 'archives/* and !*/Discussion', + +> Your setup file only allows comments to pages under archives. That +> seems unlikely to be right, so I guess it is causing your problem. +> --[[Joey]] + +That's the only place where I want comments. <http://natalian.org/archives/> +Has the pagespec changed? Is it `archives/*/*` or something like that? + +It worked just fine with this configuration. I swear I have not modified it. :) -- [[Kai Hendry]] + +> No changes that I can think of. 'archives/*' will match *all* pages under +> archives. Anyway, I can see in your site's rss feed that comments are +> enabled for posts, since they have comments tags there. And +> in fact I see comments on eg +> <http://natalian.org/archives/2010/03/25/BBC_News_complaints/>. +> +> So I suspect you have simply not rebuilt your wiki after making some +> change that fixed the comments, and so only newer pages are getting them. +> --[[Joey]] + +I have tried rebuilding on my squeeze system and still comments don't appear. Any clues how to debug this? +<http://natalian.org/comments/> + +I was worried is was due to a time skew problem I was experiencing on my VPS in the last month, though the time is right now and still comments do not appear on blog posts like <http://natalian.org/archives/2010/03/25/BBC_News_complaints/> + +# Debugging templates + +`sudo apt-get install libhtml-template-compiled-perl` + + hendry@webconverger templates$ cat test-template.perl + #!/usr/bin/perl + use HTML::Template::Compiled; + local $HTML::Template::Compiled::DEBUG = 1; + my $htc = HTML::Template::Compiled->new( + filename => "$ARGV[0]", + ); + eval { + print $htc->output; + }; + if ($@) { + # reports as text + my $msg = $htc->debug_code; + # reports as a html table + my $msg_html = $htc->debug_code('html'); + } + hendry@webconverger templates$ ./test-template.perl page.tmpl + Missing closing tag for 'IF' atend of page.tmpl line 159 + + +I think the problem was before that it was `<TMPL_IF COMMENTS>` and now it is `<TMPL_IF NAME="COMMENTS">` ? + + + +# Solved + +A merge with the templates in master with my [html5](http://git.webconverger.org/?p=ikiwiki;a=shortlog;h=refs/heads/html5) branch looks like it has solved the problem. Also see [[bugs/html5_support]]. + +[[bugs/done]] diff --git a/doc/bugs/Error:_Your_login_session_has_expired._.mdwn b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn index 046d6e10d..b993cd8e7 100644 --- a/doc/bugs/Error:_Your_login_session_has_expired._.mdwn +++ b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn @@ -41,4 +41,6 @@ Whilst trying to edit http://hugh.vm.bytemark.co.uk/ikiwiki.cgi via OpenID. Any 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. :-) +Great, this saved me big time! It is a google 1st hit. I had the same with accidentally using old templates. Thanks! --[[cstamas]] + [[bugs/done]] diff --git a/doc/bugs/Exception:_Unknown_function___96__this__39___.mdwn b/doc/bugs/Exception:_Unknown_function___96__this__39___.mdwn new file mode 100644 index 000000000..189ba740f --- /dev/null +++ b/doc/bugs/Exception:_Unknown_function___96__this__39___.mdwn @@ -0,0 +1,70 @@ +I'm very excited to try out ikiwiki, since it should fit my purposes extremely well, but I'm having trouble with the search plugin. I'm pretty sure that right after I installed ikiwiki and needed dependencies, the search plugin was working fine. However, now when I try to use search, I get "Exception: Unknown function `this'" error on a blank page. I'm not sure how I should go about debugging this issue - my server's (I use Lighttpd 1.4.22) error log has no mention of the exception and there's nothing in /var/log/syslog either. + +What might be causing this exception and how I might go about debugging exceptions? + +> Appears to be coming from your xapian omega cgi binary. If you +> run `strings /usr/lib/cgi-bin/omega/omega` you can see it has +> "Exception: " in it, and I have found some similar (but not identical) +> error messages from xapian in a web search. +> +> I don´t know what to suggest, other than upgrade/downgrade/reinstall +> xapian-omega, and contacting the xapian developers for debugging. +> You could try rebuilding your wiki in case it is somehow +> caused by a problem with the xapian database. Failing everything, you +> could switch to [[google_search_plugin|plugins/google]]. --[[Joey]] + +>> Thanks, Joey. With your help I was able to figure out what was wrong. It's a fun little bug (or feature): the title of my wiki had string `$this` in title and that's what was causing the omega binary to choke. My wiki's title was inserted without escaping into the query template used by omega. Omega treated `$this` in the title as a function name and threw an exception because no such function was defined. To avoid this behavior, I used an html entity in the title, so `$this` became `$this`. I don't think that the wiki title should be inserted into the template without escaping - it can produce an error that's not trivial to debug. If users want to modify the html in the title, they should be editing respective templates, not typing html in the wiki title input. What do you think? --[[dkobozev]] + +>>> Sounds like a bug in omega, and one that probably would affect other +>>> users of omega too. Ikiwiki could work around it by pre-escaping +>>> data before passing it to xapian. I have not quite managed to reproduce it though; +>>> tried setting a page title to '$this' and 'foo $this'. +>>> That's with version 1.0.18 of omega. +>>> --[[Joey]] + +>>>> I tried it with both omega 1.0.13 and omega 1.0.18 and the issue is present in both. If I view the contents of {$srcdir}/.ikiwiki/xapian/templates/query, I can see that the wiki title is inserted verbatim and there are calls to `$setmap`, `$set` and `$def` etc in the template. --[[dkobozev]] + +>>>>> I don't see how that's relevant. It would help if you showed me +>>>>> exactly something that could be inserted into a page to cause the +>>>>> problem. --[[Joey]] + +>>>>>> Correct me if I'm wrong: ikiwiki generates an Omega template from its own templates, such as searchquery.tmpl and puts it into {$srcdir}/.ikiwiki/xapian/templates/query. Omega has its own template syntax, where function names are prefixed with dollar signs (`$`). So, when I call my wiki `$foobar`, ikiwiki generates an Omega template that looks like this snippet: + + <div id="container"> + <div class="pageheader"> + <div class="header"> + <span> + <a href="http://example.com">$foobar</ a>/search + </span> + </div> + </div> <!-- .pageheader --> + + <div id="content"> + $setmap{prefix,title,S} + $setmap{prefix,link,XLINK} + $set{thousand,$.}$set{decimal,.}$setmap{BN,,Any Country,uk,England,fr,France} + ${ + $def{PREV, + $if{$ne{$topdoc,0},<INPUT TYPE=image NAME="<" ALT="<" + SRC="/images/xapian-omega/prev.png" BORDER=0 HEIGHT=30 WIDTH=30>, + <IMG ALT="" SRC="/images/xapian-omega/prevoff.png" HEIGHT=30 WIDTH=30>} + +>>>>>> So `$foobar` clashes with Omega's template tags. Does this help? + +>>>>>>> Ahh. I had somehow gotten it into my head that you were talking +>>>>>>> about the title of a single page, not of the whole wiki. But +>>>>>>> you were clear all along it was the wiki title. Sorry for +>>>>>>> misunderstanding. I've put in a complete fix for this problem. +>>>>>>> if this was in [[bugs]], I'd close it. :) --[[Joey]] + +>>>>>>>> Rather than escaping `$` as an HTML entity, it would be more natural +>>>>>>>> to escape it as `$$` (since you are escaping it for Omega, not for +>>>>>>>> the web browser. +>>>>>>>> +>>>>>>>> Also if ikiwiki can put arbitrary text inside the parameters of an +>>>>>>>> OmegaScript command, you should also escape `{`, `}` and `,` as +>>>>>>>> `$(`, `$)` and `$.`. It's only necessary to do so inside the +>>>>>>>> parameters of a command, but it will work and be easier to escape +>>>>>>>> them in any substituted text. --OllyBetts + +[[done]] diff --git a/doc/bugs/External_links_with_Creole.mdwn b/doc/bugs/External_links_with_Creole.mdwn new file mode 100644 index 000000000..3d800b04e --- /dev/null +++ b/doc/bugs/External_links_with_Creole.mdwn @@ -0,0 +1,3 @@ +When using Creole for markup, creating an external link appears to be impossible. Neither \[[Outside URL|http://example.com]] nor <<http://example.com>> nor \[Outside URL]\(http://example.com) work. The first gets rendered as a broken WikiLink, the second get eaten and the last is not parsed in anyway so you end up with that exact text in your page. + +I'd have made this as a Creole page as a practical demonstration, but that doesn't seem possible here. Here's a page with an example: <https://www.icanttype.org//demo/CreoleExternalLinks> diff --git a/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn b/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn new file mode 100644 index 000000000..164e62075 --- /dev/null +++ b/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn @@ -0,0 +1,214 @@ +After some months, I just updated my local ikiwiki sources, and rebuilt +the Hurd web pages, <http://git.savannah.gnu.org/cgit/hurd/web.git/>. + +I was confused, having switched to the new automatic (thanks!) --gettime +mechanism, why on some pages the timestamps had changed compared to my +previous use of --getctime and setting files' mtimes (using a script) +according to the last Git commit. For example: + +community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.html + +old: + + Last edited <span class="date">2008-09-11 18:11:53 UTC</span> + <!-- Created <span class="date">2008-09-11 17:47:08 UTC</span> --> + +new: + + Last edited <span class="date">2008-09-11 18:12:22 UTC</span> + <!-- Created <span class="date">2008-09-11 17:47:50 UTC</span> --> + + +I had a look at what git.pm is doing, and began to manually replay / +investigate: + + $ git log --pretty=fuller --name-only --relative -- community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + commit 8f1b97bfe45b2f173e3a7d55dee226a9e289a695 + Author: arnebab <arne_bab@web.de> + AuthorDate: Thu Sep 11 20:11:53 2008 +0200 + Commit: arnebab <arne_bab@web.de> + CommitDate: Thu Sep 11 20:11:53 2008 +0200 + + Added a link to the X.org guide in this wiki. + + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + commit 3ef8b7d80d80572c436c4c60c71879bc74409816 + Author: arnebab <arne_bab@web.de> + AuthorDate: Thu Sep 11 19:47:08 2008 +0200 + Commit: arnebab <arne_bab@web.de> + CommitDate: Thu Sep 11 19:47:08 2008 +0200 + + Minor update on the enty trying to get X working -> 'watch this place for updates' + + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + +OK, these are my old dates. + + $ git log --pretty=format:%ci --name-only --relative -- community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + 2008-09-11 20:11:53 +0200 + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + 2008-09-11 19:47:08 +0200 + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + $ git log --pretty=format:%ct --name-only --relative -- community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + 1221156713 + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + 1221155228 + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + $ date -d @1221156713 + Thu Sep 11 18:11:53 UTC 2008 + $ date -d @1221155228 + Thu Sep 11 17:47:08 UTC 2008 + +That's all consistent. + + +But: + + $ perl -le 'use Storable; my $index=Storable::retrieve("indexdb"); use Data::Dumper; print Dumper $index' + [...] + 'community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn' => { + 'ctime' => '1221155270', + 'dest' => [ + 'community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.html' + ], + 'typedlinks' => { + 'tag' => {} + }, + 'mtime' => 1221156742, + 'depends_simple' => { + 'sidebar' => 1 + }, + 'links' => [ + 'community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x/discussion', + 'Hurd/DebianXorg' + ], + 'state' => { + [...] + + $ date -d @1221156742 + Thu Sep 11 18:12:22 UTC 2008 + $ date -d @1221155270 + Thu Sep 11 17:47:50 UTC 2008 + +That's different, and it matches what the new ikiwiki writes into the +HTML file. + + +Back to Git again, this time without specifying the file: + + $ git log --pretty=format:%ct --name-only --relative + [...] + 1221255713 + 1221255655 + unsorted/PortingIssues.mdwn + + 1221156742 [Thu Sep 11 18:12:22 UTC 2008] + 1221156713 [Thu Sep 11 18:11:53 UTC 2008] + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + 1221156267 + 1221156235 + index.mdwn + + 1221156122 + 1221156091 + index.mdwn + + 1221155942 + 1221155910 + index.mdwn + + 1221155270 [Thu Sep 11 17:47:50 UTC 2008] + 1221155228 [Thu Sep 11 17:47:08 UTC 2008] + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + + 1221154986 + community/gsoc.mdwn + community/gsoc/project_ideas.mdwn + + 1221147244 + whatsnew.html + [...] + +Aha! + +... and some more detail: + + $ git log --pretty=fuller --name-only --relative + [...] + commit e4e89e1683012c879012522105a3471a00714613 + Author: Samuel Thibault <samuel.thibault@ens-lyon.org> + AuthorDate: Fri Sep 12 23:40:55 2008 +0200 + Commit: Samuel Thibault <samuel.thibault@ens-lyon.org> + CommitDate: Fri Sep 12 23:40:55 2008 +0200 + + MSG_NOSIGNAL and IPV6_PKTINFO got fixed + + unsorted/PortingIssues.mdwn + + commit c389fae98dff86527be62f895ff7272e4ab1932c + Merge: 0339e3e 8f1b97b + Author: GNU Hurd wiki engine <web-hurd@gnu.org> + AuthorDate: Thu Sep 11 18:12:22 2008 +0000 + Commit: GNU Hurd wiki engine <web-hurd@gnu.org> + CommitDate: Thu Sep 11 18:12:22 2008 +0000 + + Merge branch 'master' of wiki@192.168.10.50:wiki + + commit 8f1b97bfe45b2f173e3a7d55dee226a9e289a695 + Author: arnebab <arne_bab@web.de> + AuthorDate: Thu Sep 11 20:11:53 2008 +0200 + Commit: arnebab <arne_bab@web.de> + CommitDate: Thu Sep 11 20:11:53 2008 +0200 + + Added a link to the X.org guide in this wiki. + + community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn + [...] + +So, merges are involved there. + +What (the new) ikiwiki code does, is use the timestamp when the merge was +done instead of the timestamp when the commit was done. Is this +intentional? Otherwise I could supply a patch. + +--[[tschwinge]] + +> In order to be nice and fast, the git backend runs git log once +> and records data for all files. Rather than looking at the log for a +> given file. So amoung other things, it does not follow renames. +> +> AFAICS, git log only shows merges modifying files if it was a conflicted +> merge. As the file is then actually modified to resolve the merge +> I think it makes sense to count the merge as the last modification in +> that case. --[[Joey]] + +>> That'd be reasonable, but `git log` will also show merges that are not +>> conflicting (as in my case). + +>>> Actually when displaying a merge, `git log --stat` only lists files that +>>> were actually modified in a new way as part of the merge resolution. +>>> Ie, if the merge resolution only joins together some of the parent +>>> hunks, the file is not listed as having been modified. +>>> +>>> So, no, ikiwiki's use of git log will not show files modified in +>>> non-conflicting merges. +>>> --[[Joey]] + +>> Yet, I'm not totally disagreeing with your choice. With this `git +>> log` invocation, you're not able to tell from its output whether a +>> conflict was resolved or not. + +>> Also, it's a bit like the *should we use the **author timestamp** or +>> **commit timestamp*** discussion. Your code will always use the +>> latest timestamp. + +>> I guess I'll get my head wrapped around that, and it's fine, so this is +>> [[done]]. + +>> --[[tschwinge]] diff --git a/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn b/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn new file mode 100644 index 000000000..0cbef403d --- /dev/null +++ b/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn @@ -0,0 +1,45 @@ +I'm trying to make a pretty theme for ikiwiki and I'm making progress (or at least I think I am :-). However I've noticed an issue when it comes to theming. On the front page the wiki name is put inside the "title" span and on all the other pages, it's put in the "parentlinks" span. See here: + +From [my dev home page](http://adam.shand.net/iki-dev/): + +<code> +<div class="header"> +<span> +<span class="parentlinks"> + +</span> +<span class="title"> +adam.shand.net/iki-dev +</span> +</span><!--.header--> + +</div> +</code> + +From a sub-page of [my dev home page](http://adam.shand.net/iki-dev/recipes/navajo_fry_bread/): + +<code> +<div class="header"> +<span> +<span class="parentlinks"> + +<a href="../">adam.shand.net/iki-dev</a>/ + +</span> +<span class="title"> +recipes +</span> +</span><!--.header--> + +</div> +</code> + +I understand the logic behind doing this (on the front page it is the title as well as the name of the wiki) however if you want to do something different with the title of a page vs. the name of the wiki it makes things pretty tricky. + +I'll just modify the templates for my own site but I thought I'd report it as a bug in the hopes that it will be useful to others. + +Cheers, +Adam. + +---- +> I just noticed that it's also different on the comments, preferences and edit pages. I'll come up with a diff and see what you guys think. -- Adam. diff --git a/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn new file mode 100644 index 000000000..1b9cb2e2d --- /dev/null +++ b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn @@ -0,0 +1 @@ +The [[plugins/highlight]] plugin hard codes some paths up the top of the plugin. This means that you need to edit the ikiwiki source if you have highlight installed in a non-standard location (e.g. if you have done a user-level install of the highlight package). diff --git a/doc/bugs/Inline_doesn__39__t_wikilink_to_pages.mdwn b/doc/bugs/Inline_doesn__39__t_wikilink_to_pages.mdwn index 32f9f1245..13b80b436 100644 --- a/doc/bugs/Inline_doesn__39__t_wikilink_to_pages.mdwn +++ b/doc/bugs/Inline_doesn__39__t_wikilink_to_pages.mdwn @@ -2,10 +2,6 @@ It seems that the [[ikiwiki/directive/inline]] directive doesn't generate wikili \[[!inline pages="bugs/* and !*/discussion and backlink(bugs)" feeds=no postform=no archive=yes show="10"]] -But here it is: - -[[!inline pages="bugs/* and !*/discussion and backlink(bugs)" feeds=no postform=no archive=yes show="10"]] - and note that it only included the 'normal' wikilinks (and also note that this page is not marked done even though the done page is inlined). One might also wonder if inline would make this page link to any internal links on those inlined pages too, but I think that would be overkill. diff --git a/doc/bugs/Links_to_missing_pages_should_always_be_styled.mdwn b/doc/bugs/Links_to_missing_pages_should_always_be_styled.mdwn new file mode 100644 index 000000000..73213209a --- /dev/null +++ b/doc/bugs/Links_to_missing_pages_should_always_be_styled.mdwn @@ -0,0 +1,5 @@ +When the CGI URL is not defined, links to missing pages appear as plain, unstyled text. I think the 'createlink' span should always wrap this text, even when the actual question mark linking to the CGI for the create action is missing. This ensures consistent styling regardless of whether the CGI is available or not (and is thus useful for example when the same wiki has clones with the CGI link and clones without). + +A proposed patch is available [on my ikiwiki clone](http://git.oblomov.eu/ikiwiki/patch/290d1b498f00f63e6d41218ddb76d87e68ed5081) + +[[!tag patch cgi done]] diff --git a/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn b/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn index c9f698158..bc80125ad 100644 --- a/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn +++ b/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn @@ -9,31 +9,12 @@ The graphviz.pm plug-in currently attempts to read PNG data in UTF-8 mode, which It also generates image URLs relative to the page being rendered, which means the URLs wont work when previewing a graph from the CGI script. +(preview bug split to [[Problems_with_graphviz.pm_plug-in_previews]]) + >> Here is an updated patch againt ikiwiki-2.5: >>> [[Applied|done]], thanks. --[[Joey]] - --- IkiWiki/Plugin/graphviz.pm.orig 2007-07-27 11:35:05.000000000 +0200 - +++ IkiWiki/Plugin/graphviz.pm 2007-07-27 11:36:02.000000000 +0200 - @@ -69,7 +69,12 @@ sub render_graph (\%) { - } - } - - - return "<img src=\"".urlto($dest, $params{page})."\" />\n"; - + if ($params{preview}) { - + return "<img src=\"".urlto($dest, "")."\" />\n"; - + } - + else { - + return "<img src=\"".urlto($dest, $params{page})."\" />\n"; - + } - } - - sub graph (@) { - - ->> --[[HenrikBrixAndersen]] - - The patch below fixes these two issues. --- graphviz.pm.orig Thu Jun 7 15:45:16 2007 diff --git a/doc/bugs/Problems_with_graphviz.pm_plug-in_previews.mdwn b/doc/bugs/Problems_with_graphviz.pm_plug-in_previews.mdwn new file mode 100644 index 000000000..c77bbeeaf --- /dev/null +++ b/doc/bugs/Problems_with_graphviz.pm_plug-in_previews.mdwn @@ -0,0 +1,54 @@ +(split from [[Problems_with_graphviz.pm_plug-in]]) + +[graphviz] generates image URLs relative to the page being rendered, which means the URLs wont work when previewing a graph from the CGI script. + +>> Here is an updated patch againt ikiwiki-2.5: + +>>> Applied, thanks. --[[Joey]] + + --- IkiWiki/Plugin/graphviz.pm.orig 2007-07-27 11:35:05.000000000 +0200 + +++ IkiWiki/Plugin/graphviz.pm 2007-07-27 11:36:02.000000000 +0200 + @@ -69,7 +69,12 @@ sub render_graph (\%) { + } + } + + - return "<img src=\"".urlto($dest, $params{page})."\" />\n"; + + if ($params{preview}) { + + return "<img src=\"".urlto($dest, "")."\" />\n"; + + } + + else { + + return "<img src=\"".urlto($dest, $params{page})."\" />\n"; + + } + } + + sub graph (@) { + + +>> --[[HenrikBrixAndersen]] + +>>> Despite this patch I am still experiencing the problem. Normal page source for a graph contains: + + <div id="content"> + <p><img src="./graph-c9fd2a197322feb417bdedbca5e99f5aa65b3f06.png" /></p> + + </div> + +>>> preview contains + + <div id="preview"> + <p><img src="./demo/diagrams/graph-c9fd2a197322feb417bdedbca5e99f5aa65b3f06.png" /></p> + + </div> + +>>> I don't quite understand why, this makes sense from the CGI path (in my +>>> case from the root of the site). The browsers appear to be trying to fetch +>>> `/demo/diagrams/demo/diagrams/graph-c9fd2a197322feb417bdedbca5e99f5aa65b3f06.png` +>>> (i.e., prepending the required relpath twice). -- [[Jon]] + +>>>> Yeah, that patch may have been right once, but it's wrong now; +>>>> preview mode uses `<base>` to make urls work the same as they would +>>>> when viewing the html page. +>>>> +>>>> Perhaps this was not noticed for a while while because it only +>>>> shows up if previewing an *unchanged* graph on a page that has already +>>>> been built before. Fixed now. [[done]] --[[Joey]] diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn index 5519e45c6..270da86d3 100644 --- a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn +++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn @@ -10,7 +10,7 @@ If I have a <--#include virtual="foo" --> in some file, it gets stripped, > Anyway, it makes sense for the htmlscrubber to strip server-side > includes because otherwise your wiki could be attacked > by them being added to it. If you want to use both the htmlscrubber and -> SSI together, I'd suggest you modify the [[wikitemplates]] +> SSI together, I'd suggest you modify the [[templates]] > and put the SSI on there. > > Ie, `page.tmpl` has a diff --git a/doc/bugs/Search_summary_includes_text_from_navigational_elements.mdwn b/doc/bugs/Search_summary_includes_text_from_navigational_elements.mdwn new file mode 100644 index 000000000..b774c4531 --- /dev/null +++ b/doc/bugs/Search_summary_includes_text_from_navigational_elements.mdwn @@ -0,0 +1,22 @@ +Each listed result for a search will show some example text from the beginning of the linked page. It strips out HTML elements, but if there's any navigational text items, they will stay. + +For example, each search result on ikiwiki.info shows "(title) ikiwiki/ (title) Edit RecentChanges History Preferences Discussion" at the start of its results. + +A way to name some CSS ids that should be removed in search results within the ikiwiki setup file would work. Here's something similar that a friend proposed: + +http://leaf.dragonflybsd.org/mailarchive/users/2009-11/msg00077.html + +(bin attachment on that page is actually a .diff.) + +> So I was looking at this and I relized that while the search plugin used +> to use the format hook, and so there was no way to avoid it seeing all +> the gunk around the page body, it was changed a while ago for different +> reasons to use its own hook, postscan. So there's really no reason not +> to move postscan so it runs before said gunk is added to the page. +> (Aside from a small risk of breaking other third-party plugins that +> somehow use postscan.) +> +> I've implemented that in git, and it drops the navigation elements nicely. +> It's perhaps less general than allowing specific divs to be skipped from +> search, but it seems good enough. Please thank the dragonfly guys for their +> work on this. [[done]] --[[Joey]] diff --git a/doc/bugs/Tab_delimited_tables_don__39__t_work.mdwn b/doc/bugs/Tab_delimited_tables_don__39__t_work.mdwn new file mode 100644 index 000000000..39d57a4fe --- /dev/null +++ b/doc/bugs/Tab_delimited_tables_don__39__t_work.mdwn @@ -0,0 +1,22 @@ +Table directive should support tab-delimited data, especially important since this is the format you will get if copy/pasting from an HTML table or spreadsheet (Gnumeric, OO Calc, Excel). Test case which fails: + +[[!table format=dsv delimiter="\t" data=""" +1 2 +2 4 +"""]] + +> They do work, but C-style backslash escapes aren't recognised, +> so the syntax `delimiter="\t"` (as in your test case) looks +> for the literal string `\t`. Replacing `\t` with a literal +> tab character makes it work - here's a test (I changed the data +> to make the table layout more obvious): +> +> [[!table format=dsv delimiter=" " data=""" +left 2 +2 right +alpha beta +"""]] +> +> So, I think this can be considered [[not_a_bug|done]]? --[[smcv]] + +>> I've clarified the documentation. --[[smcv]] diff --git a/doc/bugs/__34__First_post__34___deletion_does_not_refresh_front_page.mdwn b/doc/bugs/__34__First_post__34___deletion_does_not_refresh_front_page.mdwn new file mode 100644 index 000000000..2367335a7 --- /dev/null +++ b/doc/bugs/__34__First_post__34___deletion_does_not_refresh_front_page.mdwn @@ -0,0 +1,6 @@ +When I created an ikiwiki site (on Branchable) using the blog template, it added a "First post", which was fine. +Deleting that post removed it, but the front page did not get the re-generated, so it was still there. +--[[liw]] + +> This is a bug involving the `page()` pagespec. Deleted +> pages matching this pagespec are not noticed. --[[Joey]] [[done]] diff --git a/doc/bugs/absolute_sizes_in_default_CSS.mdwn b/doc/bugs/absolute_sizes_in_default_CSS.mdwn new file mode 100644 index 000000000..bb3c0c7a0 --- /dev/null +++ b/doc/bugs/absolute_sizes_in_default_CSS.mdwn @@ -0,0 +1,39 @@ +While toying around with some font sizes on my persona ikiwiki I discovered that some font sizes in the default CSS are fixed rather than relative. Here's a git patch that replaces them with relative font sizes (assuming the default 12pt/16px base font size recommended by the W3C): + +[[done]] --[[Joey]] + +<pre> +From 01c14db255bbb727d8dd1e72c3f6f2f25f07e757 Mon Sep 17 00:00:00 2001 +From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> +Date: Tue, 17 Aug 2010 00:48:24 +0200 +Subject: [PATCH] Use relative font-sizes + +--- + doc/style.css | 4 ++-- + 1 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/doc/style.css b/doc/style.css +index 66d962b..fa4b2a3 100644 +--- a/doc/style.css ++++ b/doc/style.css +@@ -14,7 +14,7 @@ nav { + + .header { + margin: 0; +- font-size: 22px; ++ font-size: 140%; + font-weight: bold; + line-height: 1em; + display: block; +@@ -22,7 +22,7 @@ nav { + + .inlineheader .author { + margin: 0; +- font-size: 18px; ++ font-size: 112%; + font-weight: bold; + display: block; + } +-- +1.7.2.rc0.231.gc73d +</pre> diff --git a/doc/bugs/align_doesn__39__t_always_work_with_img_plugin_.mdwn b/doc/bugs/align_doesn__39__t_always_work_with_img_plugin_.mdwn new file mode 100644 index 000000000..e986bdc82 --- /dev/null +++ b/doc/bugs/align_doesn__39__t_always_work_with_img_plugin_.mdwn @@ -0,0 +1,7 @@ +Using the img plugin to inline an image, the "align" parameter doesn't work as expected if you also include a "caption". + +As best as I can tell this is because the "caption" parameter works by wrapping the image inside a table which means that the "align" parameter is aligning within the table cell rather then the page itself. + +-- AdamShand + +> I agree, this is annoying... and [[done]]! --[[Joey]] diff --git a/doc/bugs/anonok_vs._httpauth.mdwn b/doc/bugs/anonok_vs._httpauth.mdwn new file mode 100644 index 000000000..bff37e18b --- /dev/null +++ b/doc/bugs/anonok_vs._httpauth.mdwn @@ -0,0 +1,118 @@ +I've got a wiki where editing requires [[plugins/httpauth]] (with +`cgiauthurl` working nicely). I now want to let the general public +edit Discussion subpages, so I enabled [[plugins/anonok]] and set +`anonok_pagespec` to `'*/Discussion'`, but HTTP auth is still being +required for those. + +(Actually, what I'll really want to do is probably [[plugins/lockedit]] +and a whitelist of OpenIDs in `locked_pages`...) + +--[[schmonz]] + +> The only way I can see to support this combination is for httpauth with +> cgiauthurl to work more like other actual login types. Which would mean +> that on editing a page that needs authentication, ikiwiki would redirect +> them to the Signin page, which would then have a link they could follow +> to bounce through the cgiauthurl and actually sign in. This would be +> significantly different than the regular httpauth process, in which the +> user signs in in passing. --[[Joey]] + +>> My primary userbase has grown accustomed to the seamlessness of +>> httpauth with SPNEGO, so I'd rather not reintroduce a seam into +>> their web-editing experience in order to let relatively few outsiders +>> edit relatively few pages. When is the decision made about whether +>> the current page can be edited by the current user (if any)? What +>> if there were a way to require particular auth plugins for particular +>> PageSpecs? --[[schmonz]] + +>>> The decision about whether a user can edit a page is made by plugins +>>> such as signinedit and lockedit, that also use canedit hooks to redirect +>>> the user to a signin page if necessary. +>>> +>>> A tweak on my earlier suggestion would be to have httpauth notice when the +>>> Signin page is being built and immediatly redirect to the cgiauthurl +>>> before the page can be shown to the user. This would, though, not play +>>> well with other authentication methods like openid, since the user +>>> would never see the Signin form. --[[Joey]] + +>>>> Would I be able to do what I want with a local plugin that +>>>> abuses canedit (and auth) to reach in and call the appropriate +>>>> plugin's auth method -- e.g., if the page matches */Discussion, +>>>> call `openid:auth()`, else `httpauth:auth()`? --[[schmonz]] + +>>>>> That seems it would be +>>>>> annoying for httpauth users (who were not currently authed), +>>>>> as they would then see the openid signin form when going to edit a +>>>>> Discussion page. +>>>>> --[[Joey]] + +>>>>>> I finally see the problem, I think. When you initially +>>>>>> suggested "a link they could follow to bounce through the +>>>>>> cgiauthurl", presumably this could _be_ the Edit link for +>>>>>> non-Discussion pages, so that the typical case of an httpauth +>>>>>> user editing an editable-only-by-httpauth page doesn't visibly +>>>>>> change. And then the Edit link for Discussion subpages could do +>>>>>> as you suggest, adding one click for the httpauth user, who won't +>>>>>> often need to edit those subpages. --[[schmonz]] + +>> On reflection, I've stopped being bothered by the +>> redirect-to-signin-page approach. (It only needs to happen once per +>> browser session, anyway.) Can we try that? --[[schmonz]] + +Here is an attempt. With this httpauth will only redirect to the +`cgiauth_url` when a page is edited, and it will defer to other plugins +like anonok first. I have not tested this. --[[Joey]] + +<pre> +diff --git a/IkiWiki/Plugin/httpauth.pm b/IkiWiki/Plugin/httpauth.pm +index 127c321..a18f8ca 100644 +--- a/IkiWiki/Plugin/httpauth.pm ++++ b/IkiWiki/Plugin/httpauth.pm +@@ -9,6 +9,8 @@ use IkiWiki 3.00; + sub import { + hook(type => "getsetup", id => "httpauth", call => \&getsetup); + hook(type => "auth", id => "httpauth", call => \&auth); ++ hook(type => "canedit", id => "httpauth", call => \&canedit, ++ last => 1); + } + + sub getsetup () { +@@ -33,9 +35,21 @@ sub auth ($$) { + if (defined $cgi->remote_user()) { + $session->param("name", $cgi->remote_user()); + } +- elsif (defined $config{cgiauthurl}) { +- IkiWiki::redirect($cgi, $config{cgiauthurl}.'?'.$cgi->query_string()); +- exit; ++} ++ ++sub canedit ($$$) { ++ my $page=shift; ++ my $cgi=shift; ++ my $session=shift; ++ ++ if (! defined $cgi->remote_user() && defined $config{cgiauthurl}) { ++ return sub { ++ IkiWiki::redirect($cgi, $config{cgiauthurl}.'?'.$cgi->query_string()); ++ exit; ++ }; ++ } ++ else { ++ return undef; + } + } + +</pre> + +> With `anonok` enabled, this works for anonymous editing of an +> existing Discussion page. auth is still needed to create one. --[[schmonz]] + +>> Refreshed above patch to fix that. --[[Joey]] + +>> Remaining issue: This patch will work with anonok, but not openid or +>> passwordauth, both of which want to display a login page at the same +>> time that httpauth is redirecting to the cgiauthurl. As mentioned above, +>> the only way to deal with that would be to add a link to the signin page +>> that does the httpauth signin. --[[Joey]] + +>>> That's dealt with in final version. [[done]] --[[Joey]] diff --git a/doc/bugs/attachment_upload_does_not_work_for_windows_clients.mdwn b/doc/bugs/attachment_upload_does_not_work_for_windows_clients.mdwn new file mode 100644 index 000000000..4e8c7bdcf --- /dev/null +++ b/doc/bugs/attachment_upload_does_not_work_for_windows_clients.mdwn @@ -0,0 +1,34 @@ +It seems as if windows clients (IE) submit filenames with backslash as directory separator. +(no surprise :-). + +But the attachment plugin translates these backslashes to underscore, making the +whole path a filename. + +> As far as I can see, that just means that the file will be saved with +> a filename something like `c:__92__My_Documents__92__somefile`. +> I don't see any "does not work" here. Error message? +> +> Still, I don't mind adding a special case, though obviously not in +> `basename`. [[done]] --[[Joey]] + +>> Well, it's probably something else also, I get **bad attachment filename**. +>> Now, that could really be a bad filename, problem is that it wasn't. I even +>> tried applying the **wiki_file_prune_regexps** one by one to see what was +>> causing it. No problem there. The strange thing is that the error shows up +>> when using firefox on windows too. But the backslash hack fixes at least the +>> incorrect filename from IE (firefox on windows gave me the correct filename. +>> I'll do some more digging... :-) /jh + +This little hack fixed the backslash problem, although I wonder if that +really is the problem? +(Everything works perfectly from linux clients of course. :-) + + sub basename ($) { + my $file=shift; + + $file=~s!.*/+!!; + $file=~s!.*\\+!!; + return $file; + } + +Should probably be `$file=~s!.*[/\\]+!!` :-) diff --git a/doc/bugs/barfs_on_recentchange_entry_for_a_change_removing_an_invalid_pagespec.mdwn b/doc/bugs/barfs_on_recentchange_entry_for_a_change_removing_an_invalid_pagespec.mdwn index 42e6b9e27..c3cbff43e 100644 --- a/doc/bugs/barfs_on_recentchange_entry_for_a_change_removing_an_invalid_pagespec.mdwn +++ b/doc/bugs/barfs_on_recentchange_entry_for_a_change_removing_an_invalid_pagespec.mdwn @@ -39,3 +39,6 @@ a year ago in September 2007. > ikiwiki. (Doesn't quite seem to be version 2.53.x either) Try with a current > version, and see if you can send me a source tree that can reproduce the > problem? --[[Joey]] + +Did not hear back, so calling this [[done]], unless I hear differently. +--[[Joey]] diff --git a/doc/bugs/bestlink_change_update_issue.mdwn b/doc/bugs/bestlink_change_update_issue.mdwn index 5ce4a93d2..c26e40d10 100644 --- a/doc/bugs/bestlink_change_update_issue.mdwn +++ b/doc/bugs/bestlink_change_update_issue.mdwn @@ -1,13 +1,32 @@ * Has bugs updating things if the bestlink of a page changes due to adding/removing a page. For example, if Foo/Bar links to "Baz", which is Foo/Baz, and Foo/Bar/Baz gets added, it will update the links in Foo/Bar - to point to it, but will forget to update the linkbacks in Foo/Baz. + to point to it, but will forget to update the backlinks in Foo/Baz. -* And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link - back to Foo/Baz. + The buggy code is in `refresh()`, when it determines what + links, on what pages, have changed. It only looks at + changed/added/deleted pages when doing this. But when Foo/Bar/Baz + is added, Foo/Bar is not changed -- so the change it its + backlinks is not noticed. -As of 1.33, this is still true. The buggy code is the %linkchanged -calculation in refresh(), which doesn't detect that the link has changed in -this case. + To fix this, it needs to consider, when rebuilding Foo/Bar for the changed + links, what oldlinks Foo/Bar had. If one of the oldlinks linked to + Foo/Baz, and not links to Foo/Bar/Baz, it could then rebuild Foo/Baz. -Still true in 1.43 although the code is much different now.. + Problem is that in order to do that, it needs to be able to tell that + the oldlinks linked to Foo/Baz. Which would mean either calculating + all links before the scan phase, or keeping a copy of the backlinks + from the last build, and using that. The first option would be a lot + of work for this minor issue.. it might be less expensive to just rebuild + *all* pages that Foo/Bar links to. + + Keeping a copy of the backlinks has some merit. It could also be + incrementally updated. + + This old bug still exists as of 031d1bf5046ab77c796477a19967e7c0c512c417. + +* And if Foo/Bar/Baz is then removed, Foo/Bar gets a broken link, + instead of changing back to linking to Foo/Baz. + + This part was finally fixed by commit + f1ddf4bd98821a597d8fa1532092f09d3d9b5483. diff --git a/doc/bugs/bestlink_returns_deleted_pages.mdwn b/doc/bugs/bestlink_returns_deleted_pages.mdwn new file mode 100644 index 000000000..874f18ead --- /dev/null +++ b/doc/bugs/bestlink_returns_deleted_pages.mdwn @@ -0,0 +1,75 @@ +To reproduce: + +1. Add the backlinkbug plugin below to ikiwiki. +2. Create a page named test.mdwn somewhere in the wiki. +3. Refresh ikiwiki in verbose mode. Pages whose bestlink is the test.mwdn page will be printed to the terminal. +4. Delete test.mdwn. +5. Refresh ikiwiki in verbose mode again. The same pages will be printed to the terminal again. +6. Refresh ikiwiki in verbose mode another time. Now no pages will be printed. + +bestlink() checks %links (and %pagecase) to confirm the existance of the page. +However, find_del_files() does not remove the deleted page from %links (and %pagecase). + +Since find_del_files removes the deleted page from %pagesources and %destsources, +won't it make sense for bestlink() to check %pagesources first? --[[harishcm]] + +> This same problem turned out to also be the root of half of ikiwiki's +> second-oldest bug, [[bestlink_change_update_issue]]. +> +> Fixing it is really a bit involved, see commit +> f1ddf4bd98821a597d8fa1532092f09d3d9b5483. The fix I committed fixes +> bestlink to not return deleted pages, but only *after* the needsbuild and +> scan hooks are called. So I was able to fix it for every case except the +> one you gave! Sorry for that. To fix it during beedsbuild and scan, +> a much more involved approach would be needed. AFAICS, no existing plugin +> in ikiwiki uses bestlink in needsbuild or scan though. +> +> If the other half of [[bestlink_change_update_issue]] is fixed, +> maybe by keeping a copy of the old backlinks info, then that fix could be +> applied here too. --[[Joey]] + +>> Cool that was fast! Well at least half the bug is solved :) For now I'll +>> probably try using a workaround if using bestlink within the needsbuild +>> or scan hooks. Maybe by testing if pagemtime equals zero. --[[harishcm]] + +>>> Yeah, and bestlink could also do that. However, it feels nasty to have +>>> it need to look at pagemtime. --[[Joey]] + +---- + + #!/usr/bin/perl + # Plugin to reproduce bestlink returning deleted pages. + # Run with ikiwiki in verbose mode. + + package IkiWiki::Plugin::bestlinkbug; + + use warnings; + use strict; + use IkiWiki 3.00; + + sub import { + hook(type => "getsetup", id => "bestlinkbug", call => \&getsetup); + hook(type => "needsbuild", id => "bestlinkbug", call => \&needsbuild); + } + + sub getsetup () { + return + plugin => { + safe => 1, + rebuild => 0, + }, + } + + sub needsbuild (@) { + my $needsbuild=shift; + + foreach my $page (keys %pagestate) { + my $testpage=bestlink($page, "test") || next; + + debug("$page"); + } + } + + 1 + + diff --git a/doc/bugs/broken_parentlinks.mdwn b/doc/bugs/broken_parentlinks.mdwn index caf1eeb0e..556d89b65 100644 --- a/doc/bugs/broken_parentlinks.mdwn +++ b/doc/bugs/broken_parentlinks.mdwn @@ -10,7 +10,7 @@ a dead link for every subpage. This is a bug, but fixing it is very tricky. Consider what would happen if example.mdwn were created: example/page.html and the rest of example/* -would need to be updated to change the parentlink from a bare work to a +would need to be updated to change the parentlink from a bare word to a link to the new page. Now if example.mdwn were removed again, they'd need to be updated again. So example/* depends on example. But it's even more tricky, because if example.mdwn is modified, we _don't_ want to rebuild @@ -19,6 +19,10 @@ example/*! ikiwiki doesn't have a way to represent this dependency and can't get one without a lot of new complex code being added. +> Note that this code has now been added. In new terms, example/* has a +> presence dependency on example. So this bug is theoretically fixable now. +> --[[Joey]] + For now the best thing to do is to make sure that you always create example if you create example/foo. Which is probably a good idea anyway.. @@ -27,3 +31,20 @@ example if you create example/foo. Which is probably a good idea anyway.. Note that this bug does not exist if the wiki is built with the "usedirs" option, since in that case, the parent link will link to a subdirectory, that will just be missing the index.html file, but still nicely usable. +--[[Joey]] + +---- + +<http://www.gnu.org/software/hurd/hurd/translator/writing.html> does not exist. +Then, on +<http://www.gnu.org/software/hurd/hurd/translator/writing/example.html>, in the +*parentlinks* line, *writing* links to the top-level *index* file. It should +rather not link anywhere at all. --[[tschwinge]] + +> So, the bug has changed behavior a bit. Rather than a broken link, we get +> a link to the toplevel page. This, FWIW, is because the template now +> uses this for each parentlink: + + <a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ + +> Best workaround is still to enable usedirs. --[[Joey]] diff --git a/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn b/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn new file mode 100644 index 000000000..7fe92f7a9 --- /dev/null +++ b/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn @@ -0,0 +1,27 @@ +After several runs of ikiwiki --refresh, the page I use with the [[plugin/brokenlinks]] directive on it accumulates multiple repeated lists of pages on the RHS. For example: + + * ?freebies from free kilowatts, free kilowatts, free kilowatts, free kilowatts, free kilowatts + +In this case the page "free kilowatts" has one link to "freebies" (it's tagged freebies). + +I think this may just be links caused by tags, actually. + +ikiwiki version 3.14159265. + +-- [[Jon]] + +> Is it possible that you upgraded from a version older than 3.12, +> and have not rebuilt your wiki since, but just refreshed? And did not run +> `ikiwiki-transition deduplinks`? If so, suggest you rebuild the wiki, +> or run that, either would probably fix the problem. +> +> If you can get to the problem after rebuilding with the current ikiwiki, +> and then refreshing a few times, I guess I will need a copy of the wiki +> source and the `.ikiwiki` directory to reproduce this. --[[Joey]] + +>> Hi Joey, thanks for your response. I've reproduced it post rebuild and after having ran ikiwiki-transition and many refreshes (both resulting from content changes and otherwise) unfortunately, with ikiwiki 3.14159265 (different machine to above report, though). I will contact you privately to provide a git URL and a copy of my .ikiwiki. -- [[Jon]] + +>>> Found the bug that was causing duplicates to get in, and fixed it. +>>> [[done]] --[[Joey]] + +>>>> Good work Joey, thanks! -- [[Jon]] diff --git a/doc/bugs/build_fails_oddly_when_older_ikiwiki_is_installed.mdwn b/doc/bugs/build_fails_oddly_when_older_ikiwiki_is_installed.mdwn new file mode 100644 index 000000000..7b252031b --- /dev/null +++ b/doc/bugs/build_fails_oddly_when_older_ikiwiki_is_installed.mdwn @@ -0,0 +1,31 @@ +I got this failure when trying to build ikiwiki version 3.20100403: + + $ perl Makefile.PL INSTALL_BASE=/opt/ikiwiki PREFIX= + Writing Makefile for IkiWiki + $ make + +*...snip...* + + ./pm_filter /opt/ikiwiki 3.20100403 /opt/ikiwiki/lib/perl5 < ikiwiki.in > ikiwiki.out + chmod +x ikiwiki.out + ./pm_filter /opt/ikiwiki 3.20100403 /opt/ikiwiki/lib/perl5 < ikiwiki-transition.in > ikiwiki-transition.out + chmod +x ikiwiki-transition.out + ./pm_filter /opt/ikiwiki 3.20100403 /opt/ikiwiki/lib/perl5 < ikiwiki-calendar.in > ikiwiki-calendar.out + chmod +x ikiwiki-calendar.out + HOME=/home/me /usr/bin/perl -Iblib/lib ikiwiki.out -libdir . -dumpsetup ikiwiki.setup + Use of uninitialized value $IkiWiki::Setup::config{"setuptype"} in concatenation (.) or string at IkiWiki/Setup.pm line 53. + Can't locate IkiWiki/Setup/.pm in @INC (@INC contains: . /opt/ikiwiki/lib/perl5/i486-linux-gnu-thread-multi /opt/ikiwiki/lib/perl5 blib/lib /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 35) line 3. + + make: *** [ikiwiki.setup] Error 2 + +Note that I had been trying to upgrade with an installed ikiwiki 3.20091114 +already in place under /opt/ikiwiki. The build does not fail for me +if I first remove the old ikiwiki installation, nor does it fail with +3.20100403 or newer installed at /opt/ikiwiki. Hence this is not +really a critical bug, although it's somewhat perplexing to me why it +ought to make a difference. + +> So, using INSTALL_BASE causes a 'use lib' to be hardcoded into the `.out` +> files; which overrides the -libdir and the -I, and so the old version +> of IkiWiki.pm is used. +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn b/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn new file mode 100644 index 000000000..39500af20 --- /dev/null +++ b/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn @@ -0,0 +1,87 @@ +Version 2.0 of bzr seems to break the bzr plugin. + +I traced this to the bzr_log method in the plugin, and patching that seems to fix it. The plugin just needs to parse the input little bit differently. +--liw + +> Patch applied, [[done]] (but, it would be good if it could be tested with +> an older bzr, and it's a pity bzr's human-targeted log has to be parsed, +> I assume there is no machine-targeted version?) --[[Joey]] + + From fb897114124e627fd3acf5af8e784c9a77419a81 Mon Sep 17 00:00:00 2001 + From: Lars Wirzenius <liw@liw.fi> + Date: Sun, 4 Apr 2010 21:05:07 +1200 + Subject: [PATCH] Fix bzr plugin to work with bzr 2.0. + + The output of "bzr log" seems to have changed a bit, so we change the + parsing accordingly. This has not been tested with earlier versions of + bzr. + + Several problems seemed to occur, all in the bzr_log subroutine: + + 1. The @infos list would contain an empty hash, which would confuse the + rest of the program. + 2. This was because bzr_log would push an empty anonymous hash to the + list whenever it thought a new record would start. + 3. However, a new record marker (now?) also happens at th end of bzr log + output. + 4. Now we collect the record to a hash that gets pushed to the list only + if it is not empty. + 5. Also, sometimes bzr log outputs "revno: 1234 [merge]", so we catch only + the revision number. + 6. Finally, there may be non-headers at the of the output, so we ignore + those. + --- + IkiWiki/Plugin/bzr.pm | 23 ++++++++++++++++------- + 1 files changed, 16 insertions(+), 7 deletions(-) + + diff --git a/IkiWiki/Plugin/bzr.pm b/IkiWiki/Plugin/bzr.pm + index 1ffdc23..e813331 100644 + --- a/IkiWiki/Plugin/bzr.pm + +++ b/IkiWiki/Plugin/bzr.pm + @@ -73,28 +73,37 @@ sub bzr_log ($) { + my @infos = (); + my $key = undef; + + + my $hash = {}; + while (<$out>) { + my $line = $_; + my ($value); + if ($line =~ /^message:/) { + $key = "message"; + - $infos[$#infos]{$key} = ""; + + $$hash{$key} = ""; + } + elsif ($line =~ /^(modified|added|renamed|renamed and modified|removed):/) { + $key = "files"; + - unless (defined($infos[$#infos]{$key})) { $infos[$#infos]{$key} = ""; } + + unless (defined($$hash{$key})) { $$hash{$key} = ""; } + } + elsif (defined($key) and $line =~ /^ (.*)/) { + - $infos[$#infos]{$key} .= "$1\n"; + + $$hash{$key} .= "$1\n"; + } + elsif ($line eq "------------------------------------------------------------\n") { + + if (keys %$hash) { + + push (@infos, $hash); + + } + + $hash = {}; + $key = undef; + - push (@infos, {}); + } + - else { + + elsif ($line =~ /: /) { + chomp $line; + - ($key, $value) = split /: +/, $line, 2; + - $infos[$#infos]{$key} = $value; + + if ($line =~ /^revno: (\d+)/) { + + $key = "revno"; + + $value = $1; + + } else { + + ($key, $value) = split /: +/, $line, 2; + + } + + $$hash{$key} = $value; + } + } + close $out; + -- + 1.7.0 diff --git a/doc/bugs/cgi_does_not_use_templatedir_overlay.mdwn b/doc/bugs/cgi_does_not_use_templatedir_overlay.mdwn index eb300e7c4..d86a3ac3e 100644 --- a/doc/bugs/cgi_does_not_use_templatedir_overlay.mdwn +++ b/doc/bugs/cgi_does_not_use_templatedir_overlay.mdwn @@ -20,3 +20,7 @@ However, when I make a change via the CGI (which has been created by the last se > problems; it could check if the templatedir exists, and check that it's > readable. This would add some extra system calls to every ikiwiki run, > and I'm not convinced it's worth it. --[[Joey]] + +>> Closing this bug since I never heard back that it was not one +>> of the above two problems, and I consider both problems local +>> configuration errors. --[[Joey]] [[done]] diff --git a/doc/bugs/clearenv_not_present_at_FreeBSD_.mdwn b/doc/bugs/clearenv_not_present_at_FreeBSD_.mdwn new file mode 100644 index 000000000..f38c86e03 --- /dev/null +++ b/doc/bugs/clearenv_not_present_at_FreeBSD_.mdwn @@ -0,0 +1,5 @@ +When build wrapper on FreeBSD system, is error occured with clearenv reference. clearenv() das not exists at FreeBSD system, use workaround environ[0]=NULL; +P.S. new git instalation, FreeBSD 7.x + +> `#include <stupid-standards.h>` fixed with nasty ifdefs to handle tcc w/o +> breaking everything else. [[done]] --[[Joey]] diff --git a/doc/bugs/clearenv_not_present_at_FreeBSD_/discussion.mdwn b/doc/bugs/clearenv_not_present_at_FreeBSD_/discussion.mdwn new file mode 100644 index 000000000..713198b61 --- /dev/null +++ b/doc/bugs/clearenv_not_present_at_FreeBSD_/discussion.mdwn @@ -0,0 +1 @@ +Mmmm... i see. But it not setup under FreeBSD without magic manual passes. diff --git a/doc/bugs/comments_not_searchable.mdwn b/doc/bugs/comments_not_searchable.mdwn new file mode 100644 index 000000000..6fda89bd2 --- /dev/null +++ b/doc/bugs/comments_not_searchable.mdwn @@ -0,0 +1,19 @@ +The text of comments (and other internal pages) does not get indexed by the +search plugin. + +Search indexes content passed to the postscan hook. +Comments are inlined, but inline's speed hack avoids adding inlined +content to the page until the format hook. + +And hmm, that's somewhat desirable, because we don't want searches +to find content that is inlined onto another page. + +That suggests that the fix could be to call the postscan hook +for internal pages. + +However, the search postscan hook tells xapian the page url, +and uses `urlto($page)` to do it. And that won't work for +an internal page. Guess it could be modified to tell xapian the +permalink. --[[Joey]] + +> [[done]] --[[Joey]] diff --git a/doc/bugs/comments_preview_unsafe_with_allowdirectives.mdwn b/doc/bugs/comments_preview_unsafe_with_allowdirectives.mdwn new file mode 100644 index 000000000..7f9fb67e9 --- /dev/null +++ b/doc/bugs/comments_preview_unsafe_with_allowdirectives.mdwn @@ -0,0 +1,8 @@ +If `comments_allowdirectives` is set, previewing a comment can run +directives that create files. (Eg, img.) Unlike editpage, it does not +keep track of those files and expire them. So the files will linger in +destdir forever. + +Probably when the user then tries to save the comment, ikiwiki will refuse +to overwrite the unknown file, and will crash. +--[[Joey]] diff --git a/doc/bugs/conflicts.mdwn b/doc/bugs/conflicts.mdwn new file mode 100644 index 000000000..bef0f54cd --- /dev/null +++ b/doc/bugs/conflicts.mdwn @@ -0,0 +1,32 @@ +The `conflicts` testcase has 4 failing test cases. The underlaying problem +is that there are multiple possible source files that can create the same +destination files. + +1. `foo.mdwn` is in srcdir, rendered to destdir. Then + it is removed, and `foo` is added, which will be rendered + raw to destdir. Since the `foo/` directory still exists, + it fails. +1. `foo` is added to srcdir, rendered raw to destdir. + Then it is removed from srcdir, and `foo.mdwn` is added. + The `foo` file is still present in the destdir, and mkdir + of the directory `foo/` fails. +1. `foo.mdwn` renders to `foo/index.html`. Then `foo/index.html` + is added to the srcdir, using rawhtml. It renders to the same + thing. +1. `foo/index.html` in srcdir is rendered to same thing in destdir + using rawhtml. Then `foo.mdwn` is added; renders same thing. + +Note that another case, that of page `foo.mdwn` and page `foo.txt`, that +both render to `foo/index.html`, used to cause problems, but no longer +crashes ikiwiki. It now only complains in this situation, and which +file "wins" is undefined. The fix for this relied on both pages being +named `foo`; but in the above cases, the source files have different +pagenames. + +One approach: Beef up checking in `will_render` to detect when the same +destination file is rendered by multiple pages. Or when one page renders +a file that is a parent directory of the rendered file of another page. +It could warn, rather than erroring. The last page rendered would "win"; +generating the destdir file. + +[[done]] diff --git a/doc/bugs/debbug_shortcut_should_expand_differently.mdwn b/doc/bugs/debbug_shortcut_should_expand_differently.mdwn index d34c40244..b93b20a32 100644 --- a/doc/bugs/debbug_shortcut_should_expand_differently.mdwn +++ b/doc/bugs/debbug_shortcut_should_expand_differently.mdwn @@ -9,3 +9,9 @@ instead of There are problems with code. bug #123456 is a good example of... Thanks, --[[madduck]] + +> Tschwinge changed it to expand to "Debian bug #xxxx". Which happens to +> sidestep the start of sentence problem. I think it makes sense to be +> explicit about whose bug it is, in general -- but you can always edit the +> shortcuts page for your own wiki to use something shorter and more +> implicit. --[[Joey]] [[done]] diff --git a/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn b/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn new file mode 100644 index 000000000..6dac9c8b8 --- /dev/null +++ b/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn @@ -0,0 +1,54 @@ +Adding text of the format + + Apple + : Pomaceous fruit of plants of the genus Malus in + the family Rosaceae. + : An american computer company. + + Orange + : The fruit of an evergreen tree of the genus Citrus. + +Does not result in expected HTML as described in the [MultiMarkdown Syntax Guide](http://fletcherpenney.net/multimarkdown/users_guide/multimarkdown_syntax_guide/): + +Should be + + <dl xmlns="http://www.w3.org/1999/xhtml"> + <dt>Apple</dt> + <dd> + <p>Pomaceous fruit of plants of the genus Malus in + the family Rosaceae.</p> + </dd> + <dd> + <p>An american computer company.</p> + </dd> + <dt>Orange</dt> + <dd> + <p>The fruit of an evergreen tree of the genus Citrus.</p> + </dd> + </dl> + +But instead it gives: + + <p>Apple + : Pomaceous fruit of plants of the genus Malus in + the family Rosaceae. + : An american computer company.</p> + + <p>Orange + : The fruit of an evergreen tree of the genus Citrus.</p> + +> ikiwiki's markdown support does not include support for multimarkdown by +> default. If you want to enable that, you can turn on the `multimarkdown` +> option in the setup file. --[[Joey]] + +>> Sorry, I should have indicated, I have multimarkdown enabled: + + # mdwn plugin + # enable multimarkdown features? + multimarkdown => 1, + +>>Other features appear to be working, tables and footnotes for instance. See current install: <http://wiki.infosoph.org> + +>>> Ok, in that case it's a bug in the perl module. Forwarded to +>>> <http://github.com/bobtfish/text-markdown/issues#issue/6> --[[Joey]] +>>> [[!tag done]] diff --git a/doc/bugs/deletion_warnings.mdwn b/doc/bugs/deletion_warnings.mdwn new file mode 100644 index 000000000..668626b49 --- /dev/null +++ b/doc/bugs/deletion_warnings.mdwn @@ -0,0 +1,89 @@ +Seen while deleting a blog's calendar pages: + +--[[Joey]] + +[[done]] -- the new `page()` pagespec needed to check if there was a source +file for the page, and was leaking undef. + +<pre> + 427250f..ff6c054 master -> origin/master +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +Use of uninitialized value $file in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 688. +Use of uninitialized value $file in substitution (s///) at /usr/share/perl5/IkiWiki.pm line 668. +Use of uninitialized value $base in exists at /usr/share/perl5/IkiWiki.pm line 692. +</pre> + diff --git a/doc/bugs/depends_simple_mixup.mdwn b/doc/bugs/depends_simple_mixup.mdwn new file mode 100644 index 000000000..a5910d02e --- /dev/null +++ b/doc/bugs/depends_simple_mixup.mdwn @@ -0,0 +1,88 @@ +The [[bugs]] page, at least before I commit this, has a bug at the top that +has been modified to link to done, and ikiwiki's dependency calculations +failed to notice and update the bugs page. Looking at the indexdb, I saw +that the page was not included in the `depends_simple` of the bugs page. + +I was able to replicate the problem locally by starting off with the page +marked done (when it did appear in the bugs page `depends_simple` +(appropriatly as a link dependency, since a change to the page removing the +link would make it match)), then removing the done link. + +At that point, it vanished from `depends_simple`. Presumably because +the main (pagespec) depends for the bugs page now matched it, as a content +dependency. But, it seems to me it should still be listed in +`depends_simple` here. This, I think, is the cause of the bug. + +Then re-add the done link, and the dependency calc code breaks down, +not noticing that bugs dependeded on the page and needs to be updated. + +Ok.. Turns out this was not a problem with the actual influences +calculation or dependency calculation code. Whew! `match_link` +just didn't set the influence correctly when failing. fixed + +--[[Joey]] + +--- + +Update: Reopening this because the fix for it rather sucks. + +I made `match_link` return on failure an influence of +type DEPEND_LINKS. So, a tag page that inlines `tagged(foo)` +gets a `depends_simple` built up that contains link dependencies for +*every* page in the wiki. A very bloaty way to represent the dependency! + +Per [[todo/dependency_types]], `link(done)` only needs to list in +`depends_simple` the pages that currently match. If a page is modified +to add the link, the regular dependency calculation code notices that +a new page matches. If a page that had the link is modified to remove it, +the `depends_simple` lets ikiwiki remember that the now non-matching page +matched before. + +Where that fell down was `!link(done)`. A page matching that was not added +to `depends_simple`, because the `link(done)` did not match it. If the page +is modified to add the link, the regular dependency calculation code +didn't notice, since the pagespec no longer matched. + +In this case, `depends_simple` needs to contain all pages +that do *not* match `link(done)`, but before my change, it contained +all pages that *do* match. After my change, it contained all pages. + +---- + +So, seems what is needed is a way for influence info to be manipulated by +the boolean operations that are applied. One way would be to have two +sets of influences be returned, one for successful matches, and one for +failed matches. Normally, these would be the same. For successful +`match_link`, the successful influence would be the page. +For failed `match_link`, the failed influence would be the page. + +Then, when NOTting a `*Reason`, swap the two sets of influences. +When ANDing/ORing, combine the individual sets. Querying the object for +influences should return only the successful influences. + +---- + +Would it be possible to avoid the complication of maintianing two sets of +influence info? + +Well, notice that the influence of `pagespec_match($page, "link(done)")` +is $page. Iff the match succeeds. + +Also, the influence of `pagespec_match($page, "!link(done)")` is +$page. Iff the (overall) match succeeds. + +Does that hold for all cases? If so, the code that populates +`depends_simple` could just test if the pagespec was successful, and +if not, avoid adding $page influences, while still adding any other, +non-$page influences. + +---- + +Hmm, commit f2b3d1341447cbf29189ab490daae418fbe5d02d seems +thuroughly wrong. So, what about influence info for other matches +like `!author(foo)` etc? Currently, none is returned, but it should +be a content influence. (Backlink influence data seems ok.) + +---- + +[[done]] again! diff --git a/doc/bugs/disable_sub-discussion_pages.mdwn b/doc/bugs/disable_sub-discussion_pages.mdwn index 5e9c8c9f9..39d9ba528 100644 --- a/doc/bugs/disable_sub-discussion_pages.mdwn +++ b/doc/bugs/disable_sub-discussion_pages.mdwn @@ -6,6 +6,12 @@ I do want discussion subpage, but I don't want to have, for example: discussion/ > Discussion pages should clearly be a special case that don't get Discussion > links put at the top... aaand.. [[bugs/done]]! --[[Joey]] +>> This bug appears to have returned. For example, +>> [[plugins/contrib/unixauth/discussion]] has a Discussion link. -- [[schmonz]] + +>>> Lots of case issues this time. Audited for and fixed them all. [[done]] +>>> --[[Joey]] + >>> Joey, I've just seen that you closed that bug in ikiwiki 1.37, but it seems >>> you fixed it only for English "discussion" page. The bug still occurs >>> for the international "discussion" pages. I have backported ikiwiki 1.40 diff --git a/doc/bugs/discussion_of_what__63__.mdwn b/doc/bugs/discussion_of_what__63__.mdwn index 2f469fed9..763e599bf 100644 --- a/doc/bugs/discussion_of_what__63__.mdwn +++ b/doc/bugs/discussion_of_what__63__.mdwn @@ -1,3 +1,7 @@ When searching in ikiwiki, sometimes discussion pages turn up. However, they are only titled "discussion". In order to know what topic they are discussing, you have to look at the URL. Shouldn't they be titled "foo/discussion" or "discussion of foo" or something? Thanks, --[[perolofsson]] + +> This bug was filed when ikiwiki still used hyperestradier. +> Now that it uses xapian, the search results include the full +> page name, which seems sufficient to call this [[done]] --[[Joey]] diff --git a/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn index 5bab283fd..51d6ad475 100644 --- a/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn +++ b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn @@ -21,4 +21,4 @@ It works fine with h2 and deeper. The square brackets also appear in the output > [[done]] --[[Joey]] ->> It works here but it definitely does *not* work on my wiki; but on further experimentation, I believe my problem is being caused by JasonBlevins' [h1title](http://code.jblevins.org/ikiwiki/plugins.git/plain/h1title.pm) plugin. +>> It works here but it definitely does *not* work on my wiki; but on further experimentation, I believe my problem is being caused by JasonBlevins' [h1title](http://jblevins.org/git/ikiwiki/plugins.git/plain/h1title.pm) plugin. diff --git a/doc/bugs/filecheck_failing_to_find_files.mdwn b/doc/bugs/filecheck_failing_to_find_files.mdwn new file mode 100644 index 000000000..6501508e4 --- /dev/null +++ b/doc/bugs/filecheck_failing_to_find_files.mdwn @@ -0,0 +1,65 @@ +Using the attachment plugin, when filecheck was checking the mime-type of the attachment before allowing the attachment to be removed, it was returning with an error saying that the mime-type of the file was "unknown" (when the mime-type definitely was known!) + +It turns out that the filecheck plugin couldn't find the file, because it was merely using the $pagesources hash, rather than finding the absolute path of the file in question. + +> I don't understand why the file was not in `%pagesources`. Do you? +> --[[Joey]] + +>> The file *was* in `%pagesources`, but what returns from that is the filename relative to the `srcdir` directory; for example, `foo/bar.gif`. +>> When File::MimeInfo::Magic::magic is given that, it can't find the file. +>> But if it is given `/path/to/srcdir/foo/bar.gif` instead, then it *can* find the file, and returns the mime-type correctly. +>> --[[KathrynAndersen]] + +>>> Ok, so it's not removal specific, can in fact be triggered by using +>>> testpagespec (or really anything besides attachment, which passes +>>> the filename parameter). Nor is it limited to mimetype, all the tests in +>>> filecheck have the problem. --[[Joey]] + +>>>> Alas, not fixed. It seems I was mistaken in some of my assumptions. +>>>> It still happens when attempting to remove attachments. +>>>> With your fix, the `IkiWiki::srcfile` function is only called when the filename is not passed in, but it appears that in the case of removing attachments, the filename IS passed in, but it is the relative filename as mentioned above. Thus, the file is still not found, and the mime-type comes back as unknown. +>>>> The reason my patch worked is because, rather than checking whether a filename was passed in before applying IkiWiki::srcfile to the filename, it checks whether the file can be found, and if it cannot be found, then it applies IkiWiki::srcfile to the filename. +>>>> --[[KathrynAndersen]] + +>>>>> Can you test if this patch fixes that? --[[Joey]] + +>>>>>> Yes, it works! --[[KathrynAndersen]] + +applied && [[done]] + +<pre> +diff --git a/IkiWiki/Plugin/remove.pm b/IkiWiki/Plugin/remove.pm +index f59d026..0fc180f 100644 +--- a/IkiWiki/Plugin/remove.pm ++++ b/IkiWiki/Plugin/remove.pm +@@ -49,7 +49,7 @@ sub check_canremove ($$$) { + # This is sorta overkill, but better safe than sorry. + if (! defined pagetype($pagesources{$page})) { + if (IkiWiki::Plugin::attachment->can("check_canattach")) { +- IkiWiki::Plugin::attachment::check_canattach($session, $page, $file); ++ IkiWiki::Plugin::attachment::check_canattach($session, $page, "$config{srcdir}/$file"); + } + else { + error("removal of attachments is not allowed"); +diff --git a/IkiWiki/Plugin/rename.pm b/IkiWiki/Plugin/rename.pm +index 3908443..1a9da63 100644 +--- a/IkiWiki/Plugin/rename.pm ++++ b/IkiWiki/Plugin/rename.pm +@@ -50,7 +50,7 @@ sub check_canrename ($$$$$$) { + IkiWiki::check_canedit($src, $q, $session); + if ($attachment) { + if (IkiWiki::Plugin::attachment->can("check_canattach")) { +- IkiWiki::Plugin::attachment::check_canattach($session, $src, $srcfile); ++ IkiWiki::Plugin::attachment::check_canattach($session, $src, "$config{srcdir}/$srcfile"); + } + else { + error("renaming of attachments is not allowed"); +@@ -85,7 +85,7 @@ sub check_canrename ($$$$$$) { + if ($attachment) { + # Note that $srcfile is used here, not $destfile, + # because it wants the current file, to check it. +- IkiWiki::Plugin::attachment::check_canattach($session, $dest, $srcfile); ++ IkiWiki::Plugin::attachment::check_canattach($session, $dest, "$config{srcdir}/$srcfile"); + } + } +</pre> diff --git a/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn b/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn index 8cb47f864..558eb90c8 100644 --- a/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn +++ b/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn @@ -3,3 +3,12 @@ I'm using firefox-3.0.8-alt0.M41.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1 Only explicitly pressing "reload" helps. Is it a bug? I haven't been noticing such problems usually on other sites. --Ivan Z. + +This remains to be true now, with Epiphany 2.26.3 (Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.1.4pre) Gecko/20080528 Epiphany/2.22 Firefox/3.5). --Ivan Z. + +> In the most recent ikiwiki release, I added a Cache-Control hack +> explicitly to work around firefox's broken over-caching. +> +> (When I tested epiphany and chromium, neither had firefox's problem.) +> +> [[!tag done]] diff --git a/doc/bugs/git_utf8.mdwn b/doc/bugs/git_utf8.mdwn index dc8df1dab..39903d51c 100644 --- a/doc/bugs/git_utf8.mdwn +++ b/doc/bugs/git_utf8.mdwn @@ -6,3 +6,7 @@ appearing. Probably git's output needs to be force encoded to utf-8. --[[Joey]] + +> I did that in 4ac0b2953131d7a53562ab8918c8e5a49952d8ac , [[done]] +> --[[Joey]] + diff --git a/doc/bugs/gitremotes_script_picks_up_tags_from_anywhere.mdwn b/doc/bugs/gitremotes_script_picks_up_tags_from_anywhere.mdwn new file mode 100644 index 000000000..9bd8938c5 --- /dev/null +++ b/doc/bugs/gitremotes_script_picks_up_tags_from_anywhere.mdwn @@ -0,0 +1,22 @@ +[[!tag patch]] +[[!template id=gitbranch branch=smcv/ready/no-tags author="[[smcv]]"]] + +The `gitremotes` script picks up tags from any repository, including those +used for local .debs that were never actually present in Debian: + + smcv@reptile% git tag | grep -c nmu + 52 + +This can be avoided with the `tagopt = --no-tags` option in .git/config; +see <http://git.pseudorandom.co.uk/smcv/ikiwiki.git?a=shortlog;h=refs/heads/ready/no-tags> + +> *done* thanks. Also cleared propigated tags out of origin. +> +> Hmm, in testing I still see tags get pulled the first time a remote +> is added. If those are then locally deleted, it doesn't pull them again +> with the `--no-tags`. +> --[[Joey]] + +>> Oh, I see why. Try the same branch again... --[[smcv]] + +>>> [[done]] --[[Joey]] diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn index 239474275..ba67d532b 100644 --- a/doc/bugs/html5_support.mdwn +++ b/doc/bugs/html5_support.mdwn @@ -9,10 +9,59 @@ HTML5](http://www.w3.org/TR/html5-diff/). * [ikiwiki instance with HTML5 templates](http://natalian.org) * [HTML5 outliner tool](http://gsnedders.html5.org/outliner/) -- to check you have the structure of your markup correct +> Kai, thanks enormously for working on this. I switched a page to +> the html5 doctype today, and was rather pleasently suprised that it +> validated, except for the new Cache-Control meta tag. Now I see you're +> well ahead of me. --[[Joey]] +> +> So, how should ikiwiki support html5? There are basically 3 approaches: +> +> 1. Allow users to add html5 tags to their existing xhtml pages. +> What has been done so far, can be extended. Basically works +> in browsers, if you don't care about standards. A good prerequisite +> for anything else, anyway. +> 2. Have both a html5 and a xhtml mode, allow user to select. +> 3. Switch to html5 in eg, ikiwiki 4; users have to deal with +> any custom markup on their pages/templates that breaks then. +> +> The second option seems fairly tractable from what I see here and in +> your branch. You made only relatively minor changes to 10 templates. +> It would probably not be too dreadful to put them in ifdefs. I've made a +> small start at doing that. +> +> I've made ikiwiki use the time element and all the new semantic elements +> in html5 mode. +> +> Other ideas: +> +> * Use details tag instead of the javascript in the toggle plugin. +> (Need to wait on browser support probably.) +> * Use figure and figcaption for captions in img. However, I have not +> managed to style it to look as good as the current table+caption +> approach. +> +> --[[Joey]] + # htmlscrubber.pm needs to not scrub new HTML5 elements * [new elements](http://www.w3.org/TR/html5-diff/#new-elements) +> Many added now. +> +> Things I left out, too hard to understand today: +> Attributes contenteditable, +> data-\*, draggable, role, aria-\*. +> Tags command, keygen, output. +> +> Clearly unsafe: embed. +> +> Apparently cannot be used w/o javascript: menu. +> +> I have not added the new `ping` attribute, because parsing a +> space-separeated list of urls to avoid javascript injection is annoying, +> and the attribute seems generally dubious. +> --[[Joey]] + # HTML5 Validation and t/html.t [validator.nu](http://validator.nu/) is the authorative HTML5 validator, @@ -25,6 +74,9 @@ In the future, hopefully ikiwiki can test for valid HTML5 using [Relax NG schema](http://syntax.whattf.org/) using a Debian package tool [rnv](http://packages.qa.debian.org/r/rnv.html). +> Validation in the test suite is nice, but I am willing to lose those +> tests for a while. --[[Joey]] + # HTML5 migration issues # [article](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-article-element) element @@ -37,6 +89,8 @@ This element is poorly supported by browsers. As a workaround, `style.css` needs Internet Explorer will display it as a block, though you can't seem to be able to further control the style. +> done (needed for header too) --[[Joey]] + ## Time element The [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set by a template variable with what [HTML5 defines as a valid datetime string](http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string). @@ -45,3 +99,19 @@ As a workaround: au:~% grep timeformat natalian.setup timeformat => '%Y-%m-%d', + +> Also, the [[plugins/relativedate]] plugin needs to be updated to +> support relatatizing the contents of time elements. --[[Joey]] + +> Done and done; in html5 mode it uses the time tag, and even +> adds pubdate when displaying ctimes. --[[Joey]] + +## tidy plugin + +Will reformat html5 to html4. + +---- + + +Ok, I consider this [[done]], at least as a first pass. Html5 mode +is experimental, but complete enough. --[[Joey]] diff --git a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn new file mode 100644 index 000000000..def5bcc2a --- /dev/null +++ b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn @@ -0,0 +1,46 @@ +Hi, + +XML error: + + Created <time datetime="2009-03-24T18:02:14Z" pubdate class="relativedate" title="Tue, 24 Mar 2009 14:02:14 -0400">2009-03-24</time> + +The pubdate REQUIRES a date, so e.g. `pubdate="2009-03-24T18:02:14Z"` + +> No, `pubdate="pubdate"`. It's a boolean attribute. applied && [[done]] +> --[[Joey]] +>> awesome, thanks for fixing my fix ;) --[[simonraven]] + +Otherwise the XML parser chokes. + +<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#attr-time-pubdate> + +(indented exactly 4 spaces) + +<pre> + diff --git a/IkiWiki.pm b/IkiWiki.pm + index 1f2ab07..6ab5b56 100644 + --- a/IkiWiki.pm + +++ b/IkiWiki.pm + @@ -1004,7 +1004,7 @@ sub displaytime ($;$$) { + my $time=formattime($_[0], $_[1]); + if ($config{html5}) { + return '<time datetime="'.date_3339($_[0]).'"'. + - ($_[2] ? ' pubdate' : ''). + + ($_[2] ? ' pubdate="'.date_3339($_[0]).'"' : ''). + '>'.$time.'</time>'; + } + else { + diff --git a/IkiWiki/Plugin/relativedate.pm b/IkiWiki/Plugin/relativedate.pm + index fe8ef09..8c4a1b4 100644 + --- a/IkiWiki/Plugin/relativedate.pm + +++ b/IkiWiki/Plugin/relativedate.pm + @@ -59,7 +59,7 @@ sub mydisplaytime ($;$$) { + + if ($config{html5}) { + return '<time datetime="'.IkiWiki::date_3339($time).'"'. + - ($pubdate ? ' pubdate' : '').$mid.'</time>'; + + ($pubdate ? ' pubdate="'.IkiWiki::date_3339($time).'"' : '').$mid.'</time>'; + } + else { + return '<span'.$mid.'</span>'; +</pre> diff --git a/doc/bugs/htmlscrubber_breaks_multimarkdown_footnotes.mdwn b/doc/bugs/htmlscrubber_breaks_multimarkdown_footnotes.mdwn new file mode 100644 index 000000000..343037b45 --- /dev/null +++ b/doc/bugs/htmlscrubber_breaks_multimarkdown_footnotes.mdwn @@ -0,0 +1,18 @@ +I enabled multimarkdown to make use of footnotes in my file. I have the multimarkdown plugin, +as well as the command-line program. If I write a document with footnotes: + + This line has a footnote[^1] + + [^1]: this is the footnote + +and compile it from the cli, the reference becomes a link to the footnote and the footnote +gets a backreferencing link appended. When compiled in ikiwiki with the goodstuff plugin +enabled, the links are created but their hrefs are empty (so they do not actually act as links). +Disabling the htmlscrubber plugin fixes this issue + +[[!tag multimarkdown htmlscrubber]] + +> href was of the form: #fnref:1 , scrubbed by overzealous protocol +> scrubbing. + +[[done]] --[[Joey]] diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn index 3d0c99b83..dac4d2736 100644 --- a/doc/bugs/http_proxy_for_openid.mdwn +++ b/doc/bugs/http_proxy_for_openid.mdwn @@ -22,8 +22,7 @@ Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implement Also note that the proxy won't work with liblwpx-paranoidagent-perl, I had to remove liblwpx-paranoidagent-perl first. -Please get the patch from the *.mdwn source. - +<pre> louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm --- openid.pm.old 2008-10-26 12:18:58.094489360 +1100 +++ openid.pm 2008-10-26 12:40:05.763429880 +1100 @@ -42,6 +41,11 @@ louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm # Store the secret in the session. my $secret=$session->param("openid_secret"); if (! defined $secret) { - +</pre> Brian May + +> Rather than adding config file settings for every useful environment +> variable, there is a ENV config file setting that can be used to set +> any environment variables you like. So, no changed needed. [[done]] +> --[[Joey]] diff --git a/doc/bugs/ikiwiki-transition_does_not_set_perl_moduels_path_properly.mdwn b/doc/bugs/ikiwiki-transition_does_not_set_perl_moduels_path_properly.mdwn new file mode 100644 index 000000000..b3e87b529 --- /dev/null +++ b/doc/bugs/ikiwiki-transition_does_not_set_perl_moduels_path_properly.mdwn @@ -0,0 +1,17 @@ +When installing ikiwiki the perl module path is setup correctly + + use lib '/usr/local/ikiwiki-3.20100312/share/perl/5.10.0'; + +This is not true for ikiwiki-transition: + + $ PATH=/usr/local/ikiwiki-3.20100312/bin ikiwiki-transition prefix_directives ikiwiki.setup + Can't locate IkiWiki.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 + /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) + at /usr/local/ikiwiki-3.20100312/bin/ikiwiki-transition line 4. + BEGIN failed--compilation aborted at /usr/local/ikiwiki-3.20100312/bin/ikiwiki-transition line 4. + +The missing line should be added. + +Thanks! + +[[done]] --[[Joey]] diff --git a/doc/bugs/img_plugin_and_missing_heigth_value.mdwn b/doc/bugs/img_plugin_and_missing_heigth_value.mdwn new file mode 100644 index 000000000..4bc070c95 --- /dev/null +++ b/doc/bugs/img_plugin_and_missing_heigth_value.mdwn @@ -0,0 +1,7 @@ +When I set up my picture page with `\[[!img defaults size=300x]]` then the html validator complains that the value for height is missing and the IE browsers won't show the pictures up at all; no problems with ff tho. If I set up my picture page with `\[[!img defaults size=300x300]]` then all the images are funny stretched. What am I doing wrong? + +> This is a bug. --[[Joey]] + +> And .. [[fixed|done]] --[[Joey]] + +>> Not quite; For some reason it requires me to update wiki pages twice before the height value shows up. diff --git a/doc/bugs/img_vs_align.mdwn b/doc/bugs/img_vs_align.mdwn new file mode 100644 index 000000000..c78465a37 --- /dev/null +++ b/doc/bugs/img_vs_align.mdwn @@ -0,0 +1,38 @@ +The *[[ikiwiki/directive/img]]* directive allows for specifying an +*align* parameter -- which is of limited usability as the image is +embedded as `<p><img ...></p>`. That's at least what I see on +<http://www.bddebian.com:8888/~hurd-web/hurd/status/>. On the other +hand, CSS is supposed to be used instead, I guess. (But how... I forgot +almost of my CSS foo again ;-) it seems.) --[[tschwinge]] + +> [[!img logo/ikiwiki.png align=right]]The [img tag doesn't create P tags](http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=IkiWiki/Plugin/img.pm;h=32023fa97af8ba8e63192cacaff10a4677d20654;hb=HEAD), but if you have surrounded the img directive with newlines, they will result in paragraph tags. +> +> I've edited the URL you provided to demonstrate this -- hope you don't mind! I've also added an inline, right-aligned image to this page.[[!tag done]] +> -- [[Jon]] + +> Contrary to all of the above, html does not care about P tags when +> floating an image to the left or right via align. Proof: +> <http://kitenet.net/~joey/pics/toomanypicturesofjoey/>, where the image +> is in its own paragraph but still floats. Also, I re-modified a local +> copy of the hurd page to enclose the image in a P, and it still floats. +> +> Tested with Chromium and Firefox. --[[Joey]] + +>> Uh, sorry for not confirming what I supposed to be with looking into +>> the relevant standard. It just seemed too obvious to me that the +>> closure of `<p>...</p>` would confine whatever embedded stuff may be +>> doing. (Meaning, I didn't expect that the *img*'s alignment would +>> propagate to the *p*'s and would thus be visible from the outside.) +>> +>> I confirm (Firefox, Ubuntu jaunty) that your picture page is being +>> shown correctly -- thus I suppose that there's a buglet in our CSS +>> scripts again... +>> +>> --[[tschwinge]] + +>>> It seems, the 'align=right' parameter gets filtered in my installation +>>> Are there other plugins, that could throw the parameter away? +>>> --[[jwalzer]] + +>>>> Can't think of anything. htmlscrubber doesn't; tidy doesn't. +>>>> --[[Joey]] diff --git a/doc/bugs/inline_breaks_PERMALINK_variable.mdwn b/doc/bugs/inline_breaks_PERMALINK_variable.mdwn new file mode 100644 index 000000000..fc891bb25 --- /dev/null +++ b/doc/bugs/inline_breaks_PERMALINK_variable.mdwn @@ -0,0 +1,25 @@ +in 3.20091017 the following inline + +> `\[[!inline pages="internal(foo/bar/baz/*)" show=3 archive="yes" feeds="no" template="sometemplates"]]` + +with sometemplate being + +> `<p><a href="<TMPL_VAR PERMALINK>"><TMPL_VAR TITLE></a> (<TMPL_VAR CTIME>)</p>` + +produced output that links nowhere (`<a href="">`) while the other variables do fine. This problem does not occur in 3.1415926. + +> This must be caused by an optimisation that avoids reading the page +> content when using a template that does not use CONTENT. +> +> I guess that it needs to instead check all the variables the template +> uses, and read content if PERMALINK, or probably any other unknown +> variable is used. Unfortunatly, that will lose the optimisation +> for the archivepage template as well -- it also uses PERMALINK. +> +> So, revert the optimisation? Or, make meta gather the permalink +> data on scan? That seems doable, but is not a general fix for +> other stuff that might be a) used in a template and b) gathered +> at preprocess time. +> +> For now, I am going with the special case fix of fixing meta. I may need +> to go for a more general fix later. --[[Joey]] [[!tag done]] diff --git a/doc/bugs/inline_plugin_sets_editurl_even_when_editpage_is_disabled.html b/doc/bugs/inline_plugin_sets_editurl_even_when_editpage_is_disabled.html new file mode 100644 index 000000000..62c91a932 --- /dev/null +++ b/doc/bugs/inline_plugin_sets_editurl_even_when_editpage_is_disabled.html @@ -0,0 +1,16 @@ +see subject, simple patch below +<pre> +--- a/IkiWiki/Plugin/inline.pm ++++ b/IkiWiki/Plugin/inline.pm +@@ -371,7 +371,8 @@ sub preprocess_inline (@) { + } + if (length $config{cgiurl} && defined $type) { + $template->param(have_actions => 1); +- $template->param(editurl => cgiurl(do => "edit", page => $page)); ++ $template->param(editurl => cgiurl(do => "edit", page => $page)) ++ if IkiWiki->can("cgi_editpage"); + } + } +</pre> + +[[done]] --[[Joey]] diff --git a/doc/bugs/inline_raw_broken_on_unknown_pagetype.mdwn b/doc/bugs/inline_raw_broken_on_unknown_pagetype.mdwn new file mode 100644 index 000000000..19aa94e7e --- /dev/null +++ b/doc/bugs/inline_raw_broken_on_unknown_pagetype.mdwn @@ -0,0 +1,29 @@ +When trying to insert the raw content of an attached shell script +called `whatever` using: + + \[[!inline pages="whatever" raw="yes"]] + +The generated HTML contains: + + \[[!inline Erreur: Can't call method "param" on an undefined value + at /usr/local/share/perl/5.10.0/IkiWiki/Plugin/inline.pm + line 346.]] + +Looking at the inline plugin's code, it is clear that `$template` is +undef in such a situation. Defining `$template` just before line 346, +in case it's not defined, removes the error message, but nothing +gets inlined as `get_inline_content` returns the empty string in +this situation. + +If we explicitely don't want to allow raw inlining of unknown page +types, ikiwiki should output a better error message. + +> I have made it just do a direct include if the page type is not known, in +> raw mode. That seems useful if you want to include some other file right +> into a page. You could probably even wrap it in a format directive. +> +> It does allow including binary files right into a page, but nothing is +> stopping you pasting binary data right into the edit form either, so +> while annoying I don't think that will be a security problem. --[[Joey]] + +[[done]] diff --git a/doc/bugs/inline_skip_causes_empty_inline.mdwn b/doc/bugs/inline_skip_causes_empty_inline.mdwn new file mode 100644 index 000000000..e1cbc5470 --- /dev/null +++ b/doc/bugs/inline_skip_causes_empty_inline.mdwn @@ -0,0 +1,10 @@ +When using the [[directive/inline]] directive with the skip parameter i get +emtpy list inline (no output at all). The same inline used to work before +but not in 3.20091031. + +> I need more information to help. Skip is working as expected here. +> Can I download/clone your wiki? --[[Joey]] + +>> The bug occurs only together with archive="yes" as I Just found out: + +>>> Thanks, [[fixed|done]] in git. --[[Joey]] diff --git a/doc/bugs/librpc-xml-perl_0.69_breaks_XML-RPC_plugins.mdwn b/doc/bugs/librpc-xml-perl_0.69_breaks_XML-RPC_plugins.mdwn new file mode 100644 index 000000000..d8def82aa --- /dev/null +++ b/doc/bugs/librpc-xml-perl_0.69_breaks_XML-RPC_plugins.mdwn @@ -0,0 +1,13 @@ +Upgrading to `librpc-xml-perl` 0.69-1 on debian breaks external XML-RPC plugins (such as [[rst]]). +Refresing the wiki fails with an error message like this: + + RPC::XML::Parser::new: This method should have + been overridden by the RPC::XML::Parser class at + /usr/share/perl5/RPC/XML/Parser.pm line 46, <GEN1> line 30. + +It appears an incompatible change in the library creates this problem. + +`librpc-xml-perl` version 0.67-1 works. The easiest solution is to downgrade to this version, +or disable XML-RPC plugins if they are not needed. + +[[fixed|done]] --[[Joey]] diff --git a/doc/bugs/login_page_non-obvious_with_openid.mdwn b/doc/bugs/login_page_non-obvious_with_openid.mdwn index 1d087985a..9aa702037 100644 --- a/doc/bugs/login_page_non-obvious_with_openid.mdwn +++ b/doc/bugs/login_page_non-obvious_with_openid.mdwn @@ -36,7 +36,7 @@ If you want to keep it as one form, then perhaps using some javascript to disabl > that allows modifying that form, but does not allow creating a separate > form. The best way to make it obvious how to use it currently is to just > disable password auth, then it's nice and simple. :-) Javascript is an -> interesting idea. It's also possible to write a custom [[signin.tmpl wikitemplates]] that +> interesting idea. It's also possible to write a custom [[templates]] that > is displayed instead of the regular signin form, and it should be > possible to use that to manually lay it out better than FormBuilder > manages with its automatic layout. --[[Joey]] @@ -44,4 +44,4 @@ If you want to keep it as one form, then perhaps using some javascript to disabl > I've improved the form, I think it's more obvious now that the openid > stuff is separate. Good enough to call this [[done]]. I think. --[[Joey]] ->> Looks good, thanks! :-) -- [[AdamShand]]
\ No newline at end of file +>> Looks good, thanks! :-) -- [[AdamShand]] diff --git a/doc/bugs/login_page_should_note_cookie_requirement.mdwn b/doc/bugs/login_page_should_note_cookie_requirement.mdwn index 96686053c..17ac12b34 100644 --- a/doc/bugs/login_page_should_note_cookie_requirement.mdwn +++ b/doc/bugs/login_page_should_note_cookie_requirement.mdwn @@ -31,3 +31,9 @@ Best of all would be to use URL-based or hidden-field-based session tokens if co >> don't look static. Are they really? --[MJR](http://mjr.towers.org.uk) >>> As soon as you post an edit page, you are back to a static website. + +>>> It is impossible to get to an edit page w/o a cookie, unless +>>> anonymous edits are allowed, in which case it will save. No data loss. +>>> Since noone is working on this, and the nonsense above has pissed me +>>> off to the point that I will certianly never work on it, I'm going to +>>> close it. --[[Joey]] [[done]] diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn index 5e842ca7f..ad0f506f2 100644 --- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -66,8 +66,6 @@ Patch: >>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]] -[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]] - > [[merged|done]] --[[Joey]] Patch: diff --git a/doc/bugs/map_sorts_by_pagename_and_not_title_when_show__61__title_is_used.mdwn b/doc/bugs/map_sorts_by_pagename_and_not_title_when_show__61__title_is_used.mdwn new file mode 100644 index 000000000..d12414d55 --- /dev/null +++ b/doc/bugs/map_sorts_by_pagename_and_not_title_when_show__61__title_is_used.mdwn @@ -0,0 +1,20 @@ +The [[ikiwiki/directive/map]] directive sort by pagename. That looks kind of odd, when used together with show=title. I would expect it to sort by title then. + +> This would be quite hard to fix. Map sorts the pages it displays by page +> name, which has the happy effect of making "foo/bar" come after "foo"; +> which it *has* to do, so that it can be displayed as a child of the page +> it's located in. If sorting by title, that wouldn't hold. So, map +> would have to be effectively totally rewritten, to build up each group +> of child pages, and then re-sort those. --[[Joey]] + +>> Ok, you are right, that does would break the tree. This made me think that I do not +>> need to generate a tree for my particular use case just a list, so i thought i could use [[ikiwiki/directive/inline]] instead. +>> This created two new issues: +>> +>> 1. inline also does sort by pagename even when explicitly told to sort by title. +>> +>> 2. I cannot get inline to create a list when the htmltidy plugin is switched on. I have a template which is enclosed in an li tag, and i put the ul tag around the inline manually, but htmltidy breaks this. --martin + +>>>> You might want to check if the [[plugins/contrib/report]] plugin solves your problem. It can sort by title, among other things. --[[KathrynAndersen]] + +>> See also: [[todo/sort_parameter_for_map_plugin_and_directive]] --[[smcv]] diff --git a/doc/bugs/minor:_tiny_rendering_error.mdwn b/doc/bugs/minor:_tiny_rendering_error.mdwn new file mode 100644 index 000000000..b2e07eef9 --- /dev/null +++ b/doc/bugs/minor:_tiny_rendering_error.mdwn @@ -0,0 +1,5 @@ +`\[[!inline]]` is rendered with a space in front of the first closing bracket. --[[tschwinge]] + +> I don't think that complicating the directive parser +> is warrented by the minorness of this bug. The result that it outputs is +> still valid. --[[Joey]] diff --git a/doc/bugs/misctemplate_does_not_respect_the_current_page___40__if_any__41__.mdwn b/doc/bugs/misctemplate_does_not_respect_the_current_page___40__if_any__41__.mdwn new file mode 100644 index 000000000..3b0347f5f --- /dev/null +++ b/doc/bugs/misctemplate_does_not_respect_the_current_page___40__if_any__41__.mdwn @@ -0,0 +1,101 @@ +I really like the new approach to having only one main template "page.tmpl". For instance, it improves previews during edits. +But it causes some nasty bugs for plugins that use the pagetemplate hook. It is especially visible with the [[plugins/sidebar]] plugin. + +## Some examples + +### A first example + +* activate sidebars globally and cgi +* create "/sidebar.mdwn" with "[<span></span>[foo]]" inside +* create "/foo.mdwn" with "hello!" inside +* create "/bar.mdwn" +* run ikiwiki +* with the web browser, go to the page "bar" +* notice the sidebar, click on "foo" +* notice the page "foo" is now displayed (hello!) +* return the the page "bar" and click "edit" +* notice the sidebar is still here, click on the "foo" +* -> Problem: 404, the browser goes to "/bar/foo" +* -> Was expected: the browser goes to "/foo" + +> You must have a locally modified `page.tmpl` that omits the "TMPL_IF DYNAMIC" +> that adds a `<base>` tag. That is needed to make all links displayed by +> cgis work reliably. Not just in this page editing case. +> The [[version_3.20100515]] announcment mentions that you need to +> update old `page.tmpl` files to include that on upgrade. --[[Joey]] + +>> I followed the anouncment. I also disabled my custom page.tmpl to confirm the bug. I even produced a step-by-step example to reproduce the bug. +>> In fact, the base tag work for the page links (the content part) but did not works for the sidebar links (the sidebar part) since the sidebar links are generated in the context of the root page. +>> In the examble above: +>> +>> * base="http://www.example.com/bar" relative_link_in_bar=''something" -> absolute_link_in_bar = "http://www.example.com/bar/something" (that is fine) +>> * base="http://www.example.com/bar" relative_link_in_sidebar="foo" (because generated in the context of the root page) -> absolute_link_in_sidebar = "http://www.example.com/bar/foo" (that is not fine) +>> +>> The fix commited work for previewing, but not in other cases : links are still broken. Please juste follow the example step-by-step to reproduce it (I just retried it with a "fixed" version: Debian 3.20100610). If you cannot reproduce, please say it explicitely instead of guessing about my innability to read changelogs. -- [[JeanPrivat]] + +>>> Sorry if my not seeing the bug offended you. [[Fixed|done]] --[[Joey]] + +>>>> Thanks! --[[JeanPrivat]] (I'm not offended) + +### A second example + +* create "/bar/sidebar.mdwn" with "world" +* run ikiwiki +* with the web browser, go to the page "bar" +* notice the sidebar displays "world" +* click "edit" +* -> Problem: the sidebar now shows the foo link (it is the root sidebar!) +* -> Was expecte : the sidebar displays "world" + +> I think it's a misconception to think that the page editing page is the same +> as the page it's editing. If you were deleting that page, would you expect +> the "are you sure" confirmation page to display the page's sidebar? +> --[[Joey]] + +>> It is a very good point and could be argued: +>> +>> * for dynamic page, is the root context more legitimate than the current page context? +>> * when clicking the Edit link, does the user expect to remain in the "same page"? +>> +>> But, as far as something sensible is displayed and that the links work. I'm OK with any choice. -- [[JeanPrivat]] + +### A last example + +* with the web browser edit the page "bar" +* type <code>[<span></span>[!sidebar content="goodby"]]</code> +* click preview +* -> Problem: the sidebar still displays the foo link +* -> Was expected: the sidebar display "goodby" + +> In the specific case of previewing, it is indeed a bug that the +> right sidebar is not displayed. And replacing the regular sidebar +> with the one from the previewed page is probably the best we can do.. +> displaying 2 sidebars would be confusing, and the `page.tmpl` can +> put the sidebar anywhere so we can't just display the preview sidebar +> next to the rest of the page preview. --[[Joey]] + +>> The behavior is fine for me. However, some nitpicking (fell free to ingore) : +>> +>> * If the sidebar is replaced (making the previewing in-place), for consitency, should not the previewed content also shown in-place ? i.e. above the form part +>> * there is no way to come back (without saving or canceling) to the root context (e.g. displaying the root sidebar) i.e. some sort of unpreviewing. +>> +>> -- [[JeanPrivat]] + +## Some superficial hacking + +With the following workaround hacks, I manage to solve the 3 examples shown above: + +1- edit IkiWiki/Plugin/editpage.pm and call showform with additional page and destpage parameters: +<pre>showform($form, \@buttons, $session, $q, forcebaseurl => $baseurl, page => $page, destpage => $page);</pre> + +2- edit /usr/share/perl5/IkiWiki.pm and modify the misctemplate function to use the given page and destpage: +<pre>my %params=@_; +shift->(page => $params{page}, destpage => $params{destpage}, template => $template);</pre> + +I do not guarantee (I do not even expect) that it is the proper way to solve +this bug but it may help developers to find and solve the real problem. + +> Oh, it's pretty reasonable. I don't think it breaks anything. :) +> I modified it a bit, and explicitly made it *not* "fix" the second example. +> --[[Joey]] +>> I removed the done tag (I suspect it is the way to reopen bugs) -- [[JeanPrivat]] diff --git a/doc/bugs/nested_raw_included_inlines.mdwn b/doc/bugs/nested_raw_included_inlines.mdwn index 33433e235..92ea4c4ef 100644 --- a/doc/bugs/nested_raw_included_inlines.mdwn +++ b/doc/bugs/nested_raw_included_inlines.mdwn @@ -32,3 +32,20 @@ Am I missing something? Is this a bug or Ikiwiki not supposed to support this us > currently merges pagespecs, though - maybe the patches I suggested for > [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]] > would help? --[[smcv]] + +>> That, or something seems to have helped in the meantime... +>> Actually, I think it was the [[transitive_dependencies]] support +>> that did it, though smcv's pagespec stuff was also a crucial improvement. +>> +>> Anyhoo: + + joey@gnu:~/tmp>touch testcase/page2.mdwn + joey@gnu:~/tmp>ikiwiki -v testcase html + refreshing wiki.. + scanning page2.mdwn + building page2.mdwn + building page1.mdwn, which depends on page2 + building page0.mdwn, which depends on page1 + done + +>> I happily think this is [[done]] --[[Joey]] diff --git a/doc/bugs/pagecount_is_broken.mdwn b/doc/bugs/pagecount_is_broken.mdwn index 101230d94..57df6b75d 100644 --- a/doc/bugs/pagecount_is_broken.mdwn +++ b/doc/bugs/pagecount_is_broken.mdwn @@ -1,3 +1,4 @@ -The [[plugins/pagecount]] plugin seems to be broken, as it claims there are [[!pagecount ]] pages in this wiki. (if it's not 0, the bug is fixed) +The [[plugins/pagecount]] plugin seems to be broken, as it claims there are +\[[!pagecount ]] pages in this wiki. (if it's not 0, the bug is fixed) [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/pagemtime_in_refresh_mode.mdwn b/doc/bugs/pagemtime_in_refresh_mode.mdwn new file mode 100644 index 000000000..f926ec86c --- /dev/null +++ b/doc/bugs/pagemtime_in_refresh_mode.mdwn @@ -0,0 +1,28 @@ +I'd like a way to always ask the RCS (Git) to update a file's mtime in +refresh mode. This is currently only done on the first build, and later +for `--gettime --rebuild`. But always rebuilding is too heavy-weight for +this use-case. My options are to either manually set the mtime before +refreshing, or to have ikiwiki do it at command. I used to do the +former, but would now like the latter, as ikiwiki now generally does this +timestamp handling. + +From a quick look, the code in `IkiWiki/Render.pm:find_new_files` is +relevant: `if (! $pagemtime{$page}) { [...]`. + +How would you like to tackle this? + +--[[tschwinge]] + +> This could be done via a `needsbuild` hook. The hook is passed +> the list of changed files, and it should be safe to call `rcs_getmtime` +> and update the `pagemtime` for each. +> +> That lets the feature be done by a plugin, which seems good, since +> `rcs_getmtime` varies between very slow and not very fast, depending on +> VCS. +> +> AFAICS, the only use case for doing this is if you commit changes and +> then delay pushing them to a DVCS repo. Since then the file mtime will +> be when the change was pushed, not when it was committed. But I've +> generally felt that recording when a change was published to the repo +> of a wiki as its mtime is good enough. --[[Joey]] diff --git a/doc/bugs/pages_missing_top-level_directory.mdwn b/doc/bugs/pages_missing_top-level_directory.mdwn new file mode 100644 index 000000000..77c31cd27 --- /dev/null +++ b/doc/bugs/pages_missing_top-level_directory.mdwn @@ -0,0 +1,78 @@ +Hi, + +I've rebuilt two sites now, and anything that requires a working directory structure isn't working properly. I have no idea how it's doing this. I don't see anything in my templates, and I haven't messed around with the back-end code much. + +An example would show this best I think. + +<pre> +/ <- root of site +/About/ <- sub-directory + /Policy/ <- sub-sub- +</pre> + +When you're on /About/, any generated links get mapped to /Policy/ and NOT /About/Policy/ - of course this results in a 404 error. + +I used to be able to use relative links or absolute ones to get the links I want, and now I can't do either. The generated link results in a 404 due to the stripping of a directory. + +I don't know if it's related to the fact that I have one ikiwiki install under another (/blog/ under / is also ikiwiki), but both are FUBAR. + +> what do you mean by generated links: do you mean the output of +> [[ikiwiki/wikilink]]s? Or are you generating links some other way? +> When you say "on /About/, any generated links get mapped to +> /Policy/ and NOT /About/Policy" can you provide an example of what +> source generates the link? -- [[Jon]] + +>> No, a \[[map]] call, such as: +>> +>> (actual code)<br /> +>> = = = = =<br /> +>> \[[!map pages="About/*" show="title"]]<br /> +>> = = = = =<br /> +>> +>> The end result is:<br /> +>> (actual code) +>> +<pre> +<div class="map"> +<ul> +<li><a class="mapitem" href="./Policy/">Policy</a> +<ul> +<li><a class="mapitem" href="./Policy/Microblog/">Microblogging subscription policy</a> +</li> +</ul> +</li> +</ul> +</div> +</pre> + +> I'm also confused about what is generating the links. The map directive? +> You? --[[Joey]] + +>> see above :) + +>> I suspect this is due to git scanning everything under the pwd of the .git/ directory, but not totally so. + +>>> Ikiwiki never, ever, looks in directories with names starting with a +>>> dot. --[[Joey]] + +>> Other ikiwiki sites I have don't do this, and work OK, on the same server, but different docroots. + +>>> Well, I've moved my blog to under my site's docroot - in terms of git +>>> and ikiwiki - and it's still cutting out a whole directory level. I +>>> have no idea what's going on. I need to check the code. The site is at +>>> http://simonraven.kisikew.org/ - if you follow the "About" link, you'll +>>> understand exactly what's going on, if you look at the URL in your +>>> status bar (or under your cursor if you're using a text browser). + +>>>> Your page contains the following in its html: +>>>> `<base href="../" />` +>>>> +>>>> Given a link like "./Policy/", which is *correct*, and when on the +>>>> About page will normally link to the About/Policy page, this causes +>>>> the link to really link to ".././Policy/" which is of course broken. +>>>> +>>>> Ikiwiki's standard page templates do not contain this base tag, so +>>>> I guess your customised templates are broken. --[[Joey]] [[done]] + +>>>>> I totally forgot about that tag... good catch. I was thinking it was my template that was broken, since yesterday, but I couldn't see what. Thank you very much for your eyes. + diff --git a/doc/bugs/pagespec:_tagged__40____41____44___globbing.mdwn b/doc/bugs/pagespec:_tagged__40____41____44___globbing.mdwn new file mode 100644 index 000000000..f9cb37487 --- /dev/null +++ b/doc/bugs/pagespec:_tagged__40____41____44___globbing.mdwn @@ -0,0 +1,36 @@ +With the current HEAD (b10d353490197b576ef7bf2e8bf8016039efbd2d), +globbing in `tagged()` pagespecs doesn't work for me. For example, +`tagged(*)` doesn't match any pages. (It does in this wiki installation +here, though.) + +I did not yet do any testing to figure out when this broke. + +--[[tschwinge]] + +[[!map pages="*/a* and tagged(*ose)"]] + +> Are you sure that `tagged()` ever matches pages there? Take globbing +> out of the equasion. +> +> This could be as simple as you having not rebuilt the wiki +> on upgrade to the version that tracks tagged links. --[[Joey]] + +>> Yes, it is a globbing issue: + +>> \[[!map pages="tagged(open_i*ue_gdb)" show=title]] + +>> ... doesn't show anything. + +>> \[[!map pages="tagged(open_issue_gdb)" show=title]] + +>> ... does show a map of eight pages. Also, it's working fine on the +>> autotags pages. + +>> --[[tschwinge]] + +>>> Only way I can reproduce something like this is if tagbase is not set. +>>> I have fixed a bug there, see if it works for you? +>>> --[[Joey]] + +>>>> This is now indeed [[fixed|done]] (thanks!) -- even though I already +>>>> did have tagbase set. diff --git a/doc/bugs/pagespec_error_on_refresh_but_not_rebuild.mdwn b/doc/bugs/pagespec_error_on_refresh_but_not_rebuild.mdwn new file mode 100644 index 000000000..e89545955 --- /dev/null +++ b/doc/bugs/pagespec_error_on_refresh_but_not_rebuild.mdwn @@ -0,0 +1,32 @@ +I'm getting this error message when I refresh my wiki: + + $ hg commit -u me -m "Minor corrections" + refreshing wiki.. + scanning htmletc/moco-conf-rooms.mdwn + building htmletc/moco-conf-rooms.mdwn + Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.9/Text/Typography.pm line 542. + building sidebar.mdwn, which depends on htmletc/moco-conf-rooms + building contact.mdwn, which depends on sidebar + building 500.mdwn, which depends on sidebar + Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.9/Text/Typography.pm line 542. + building ceramics.mdwn, which depends on sidebar + building glossary.mdwn, which depends on sidebar + syntax error in pagespec "internal(glossary/comment_*)" + warning: post-commit hook exited with status 2 + +But there is no error if I use `ikiwiki --rebuild` to regenerate the whole thing. + +> You neglect to say what version of ikiwiki this is, +> or give any information to reproduce the bug. +> +> My guess: A version older than 3.20100403, which included +> [this bugfix](http://git.ikiwiki.info/?p=ikiwiki;a=commitdiff;h=799b93d258bad917262ac160df74136f05d4a451), +> which could lead to incorrect "syntax error in pagespec" +> that only happened some of the time. +> +> (The Text::Typography warning seems probably unrelated.) +> --[[Joey]] + +>> I'm sorry, I don't know what I was thinking there. It's ikiwiki 3.20100212, and manually applying the patch you linked to made the bug go away. (Upgrading ikiwiki is a pain on nearlyfreespeech, especially if you don't want to keep the build directory around -- please consider making ikiwiki runnable directly from a git clone.) + +[[!meta link="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 be14e5126..c6e3cd4fd 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -144,7 +144,7 @@ So, looking at your meta branch: --[[Joey]] has no title, then A will display the link as "B". Now page B is modified and a title is added. Nothing updates "A". The added overhead of rebuilding every page that links to B when B is - changed (as the `postscan` hook of the po plugin does) is IMHO a killer. + changed (as the `indexhtml` hook of the po plugin does) is IMHO a killer. That could be hundreds or thousands of pages, making interactive editing way slow. This is probably the main reason I had not attempted this whole thing myself. IMHO this calls for some kind of intellegent dependency diff --git a/doc/bugs/plugins__47__relativedate_depends_on_locale_at_setup_file.mdwn b/doc/bugs/plugins__47__relativedate_depends_on_locale_at_setup_file.mdwn new file mode 100644 index 000000000..a9a39ac47 --- /dev/null +++ b/doc/bugs/plugins__47__relativedate_depends_on_locale_at_setup_file.mdwn @@ -0,0 +1,16 @@ +[[plugins/relativedate]] does not works when russian locale defined at setup file (locale => 'ru_RU.UTF-8'). This is happen because javascript for this plugin takes either elements title or content itself. If russian locale is turned on then title generated on russian language and JS can't convert it into Date object. innerHTML is language independent (YYYY-MM-DD HH:mm) always. + +If I switch locale to en_US.UTF-8 then this plugin correctly parses text date and print relative date. But when I mouseover on date I see unusual formating of the date (it uses AM/PM format while russians use 24-h notation). + +P.S. All pages but RecentChanges show well-formated date. RecentChanges show date formated using locale. Anyway, plugin does not work without en_US locale. + +> [[Fixed|done]]. Now it uses C locale for the date put in the title, +> that is used by relativedate. The mouseover will display the date in your +> native locale. +> +> Only exception is that when javascript is disabled... then +> relativedate can't work, so instead you will see your localized date +> displayed; but on mouseover you will get shown the C locale date. +> --[[Joey]] + +>> Thanks. diff --git a/doc/bugs/po:_double_commits_of_po_files.mdwn b/doc/bugs/po:_double_commits_of_po_files.mdwn new file mode 100644 index 000000000..a871785be --- /dev/null +++ b/doc/bugs/po:_double_commits_of_po_files.mdwn @@ -0,0 +1,19 @@ +When adding a new english page, the po files are created, committed, +and then committed again. The second commit makes this change: + + -"Content-Type: text/plain; charset=utf-8\n" + -"Content-Transfer-Encoding: ENCODING" + +"Content-Type: text/plain; charset=UTF-8\n" + +"Content-Transfer-Encoding: ENCODING\n" + +Same thing happens when a change to an existing page triggers a po file +update. --[[Joey]] + +> * The s/utf-8/UTF-8 part has been fixed. +> * The ENCODING\n part is due to an inconsistency in po4a, which +> I've just send a patch for. --[[intrigeri]] + +>> I resubmitted the patch to po4a upstream, sending it this time to +>> their mailing-list: +>> [post archive](http://lists.alioth.debian.org/pipermail/po4a-devel/2010-July/001897.html). +>> --[[intrigeri]] diff --git a/doc/bugs/po:_new_pages_not_translatable.mdwn b/doc/bugs/po:_new_pages_not_translatable.mdwn new file mode 100644 index 000000000..c19f66594 --- /dev/null +++ b/doc/bugs/po:_new_pages_not_translatable.mdwn @@ -0,0 +1,12 @@ +Today I added a new English page to l10n.ikiwiki.info. When I saved, +the page did not have the translation links at the top. I waited until +the po plugin had, in the background, created the po files, and refreshed; +still did not see the translation links. Only when I touched the page +source and refreshed did it finally add the translation links. +I can reproduce this bug in a test site. --[[Joey]] + +> I could reproduce this bug at some point during the merge of a buggy +> version of my ordered slave languages patch, but I cannot anymore. +> Could you please try again? --[[intrigeri]] + +>> Cannot reproduce with 3.20100722, [[done]] I guess. --[[Joey]] diff --git a/doc/bugs/po:_po_files_instead_of_html_files.mdwn b/doc/bugs/po:_po_files_instead_of_html_files.mdwn new file mode 100644 index 000000000..933e348c4 --- /dev/null +++ b/doc/bugs/po:_po_files_instead_of_html_files.mdwn @@ -0,0 +1,6 @@ +On the home page of my wiki, when i click on the link "ikiwiki", i get the english file instead of the french file. +At the bottom of this page, there is the "Links" line: +Links: index index.fr templates templates.fr +When i click on "templates.fr", i get the po.file instead of html. + + Sorry for the noise! I set "po_master_language" to fr and all was ok. [[done]]. diff --git a/doc/bugs/po:_ugly_messages_with_empty_files.mdwn b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn new file mode 100644 index 000000000..d3992b6bc --- /dev/null +++ b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn @@ -0,0 +1,6 @@ +If there are empty .mdwn files, the po plugin displays some ugly messages. + +> This is due to a bug in po4a (not checking definedness of a +> variable). One-liner patch sent. --[[intrigeri]] + +>> This seems to be fixed in po4a 0.40 => [[done]]. --[[intrigeri]] diff --git a/doc/bugs/po_plugin_adds_new_dependency.mdwn b/doc/bugs/po_plugin_adds_new_dependency.mdwn new file mode 100644 index 000000000..3ddcc30f2 --- /dev/null +++ b/doc/bugs/po_plugin_adds_new_dependency.mdwn @@ -0,0 +1,38 @@ +Was it intended that the po plugin add a new dependency? + +> Yes; see debian/control Build-Depends. However, I have made it disable +> building that is po4a is not available. [[done]] --[[Joey]] + + PERL5LIB=.. ./po2wiki underlay.setup + Failed to load plugin IkiWiki::Plugin::po: Can't locate Locale/Po4a/Common.pm in @INC (@INC contains: .. /Library/Perl/Updates/5.8.8 /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 /sw/lib/perl5/5.8.8/darwin-thread-multi-2level /sw/lib/perl5/5.8.8 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5 /sw/lib/perl5/darwin /usr/local/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl .) at ../IkiWiki/Plugin/po.pm line 13. + BEGIN failed--compilation aborted at ../IkiWiki/Plugin/po.pm line 13. + Compilation failed in require at (eval 27) line 2. + BEGIN failed--compilation aborted at (eval 27) line 2. + + make[1]: *** [po2wiki_stamp] Error 2 + make: *** [extra_build] Error 2 + +And it looks like this dependency is not easy to work around. The issue is that the newly translated base wiki means that the po plugin is being used by the build system. It is no longer optional. I've turned it off in my workspace like this: (heavy handed, but it lets me keep going until a proper fix is available) + + diff --git a/Makefile.PL b/Makefile.PL + index 602d8fb..68728b7 100755 + --- a/Makefile.PL + +++ b/Makefile.PL + @@ -42,7 +42,7 @@ extra_build: ikiwiki.out ikiwiki.setup docwiki + ./mdwn2man ikiwiki-makerepo 1 doc/ikiwiki-makerepo.mdwn > ikiwiki-makerepo.man + ./mdwn2man ikiwiki-transition 1 doc/ikiwiki-transition.mdwn > ikiwiki-transition.man + ./mdwn2man ikiwiki-update-wikilist 1 doc/ikiwiki-update-wikilist.mdwn > ikiwiki-update-wikilist.man + - $(MAKE) -C po + + # $(MAKE) -C po + + docwiki: ikiwiki.out + $(PERL) -Iblib/lib $(extramodules) $(tflag) ikiwiki.out -libdir . -setup docwiki.setup -refresh + @@ -114,7 +114,7 @@ extra_install: underlay_install + install ikiwiki.out $(DESTDIR)$(PREFIX)/bin/ikiwiki + install ikiwiki-makerepo ikiwiki-transition ikiwiki-update-wikilist $(DESTDIR)$(PREFIX)/bin/ + + - $(MAKE) -C po install DESTDIR=$(DESTDIR) PREFIX=$(PREFIX) + + # $(MAKE) -C po install DESTDIR=$(DESTDIR) PREFIX=$(PREFIX) + + # These might fail if a regular user is installing into a home + # directory. diff --git a/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn b/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn new file mode 100644 index 000000000..8e3399611 --- /dev/null +++ b/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn @@ -0,0 +1,34 @@ +po files are not added to git (error: /path/to/po/file not in repository tree) in my setup. + +I have set absolute path for srcdir = '/path/to/repo/doc/'. The root of my git repository is '/path/to/repo/'. When I enable the po plugin, it creates all po files and produces an error when it try to add the file saying that the /path/to/repo/doc/index.fr.po is not in the repository tree. + +I have no problem when I use an relative path like srcdir = '.'. + +I have an other issue with the po plugin when I set the srcdir to './doc/' (provided that my config file is in /path/to/repo). In this case the po plugin try to add 'doc/doc/index.fr.po' which does not exists (seems like the srcdir path is prepended twice). + +> You should never use a relative srcdir path with ikiwiki. +> +> I wonder what version of git you have there, since it works ok with the +> version I have here. But, the po plugin is definitly doing the wrong +> thing; it's telling git to add the po file with the full scrdir path +> rather than relative to its root. Fixed that. [[done]] --[[Joey]] + +>> Yeah, I figured for the relative path +>> Git version 1.6.3.3 (on both my dev and server machines) +>> +>> Here is an example of what I get when I update the po file on my laptop and I push to the master repository: + + From /srv/git/sb + 5eb4619..ecac4d7 master -> origin/master + scanning doc.fr.po + building doc.fr.po + building doc.mdwn, which depends on doc.fr + building recentchanges.mdwn, which depends on recentchanges/change_ecac4d7311b15a3a3ed03102b9250487315740bc + fatal: '/srv/www/sb.l.n/new/doc/doc.fr.po' is outside repository + 'git add /srv/www/sb.l.n/new/doc/doc.fr.po' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 161. + done + To ssh://git.lohrun.net/var/cache/git/songbook.git + 5eb4619..ecac4d7 master -> master + +>> The root repository used to run ikiwiki is `/srv/www/sb.l.n/new/` +>> -- [[AlexandreDupas]] diff --git a/doc/bugs/po_vs_templates.mdwn b/doc/bugs/po_vs_templates.mdwn new file mode 100644 index 000000000..d826546e6 --- /dev/null +++ b/doc/bugs/po_vs_templates.mdwn @@ -0,0 +1,48 @@ +The po plugin's protection against processing loops (i.e. the +alreadyfiltered stuff) is playing against us: the template plugin +triggers a filter hooks run with the very same ($page, $destpage) +arguments pair that is used to identify an already filtered page. + +Processing an included template can then mark the whole translation +page as already filtered, which prevented `po_to_markup` to be called on +the PO content. + +Symptoms: the unprocessed gettext file goes unfiltered to the +generated HTML. + +This has been fixed in my po branch. + +> My commit dcd57dd5c9f3265bb7a78a5696b90976698c43aa updates the +> bugfix in a much more elegant manner. Its main disadvantage is to +> add an (optional) argument to IkiWiki::filter. Please review. + +-- [[intrigeri]] + +>> Hmm. Don't like adding a fourth positional parameter to that (or +>> any really) function. +>> +>> I think it's quite possible that some of the directives that are +>> calling filter do so unnecessarily. For example, conditional, +>> cutpaste, more, and toggle each re-filter text that comes from the +>> page and so has already been filtered. They could probably drop +>> the filtering. template likewise does not need to filter the +>> parameters passed into it. Does it need to filter the template output? +>> Well, it allows the (deprecated) embed plugin to work on template +>> content, but that's about it. +>> +>> Note also that the only other plugin to provide a filter, txt, +>> could also run into similar problems as po has, in theory (it looks at +>> the page parameter and assumes the content is for the whole page). +>> +>> [[!template id=gitbranch branch=origin/filter-full author="[[joey]]"]] +>> So, I've made a filter-full branch, where I attempt to fix this +>> by avoiding unnecessary filtering. Can you check it and merge it into +>> your po branch and remove your other workarounds so I can merge? +>> --[[Joey]] + +>>> I merged your filter-full branch into my po branch and reverted my +>>> other workarounds. According to my tests this works ok. I'm glad +>>> you found this solution, as I didn't like changing the filter +>>> prototype. I believe you can now merge this code. --[[intrigeri]] + +[[!tag patch done]] diff --git a/doc/bugs/post-commit_hangs.mdwn b/doc/bugs/post-commit_hangs.mdwn new file mode 100644 index 000000000..32820d886 --- /dev/null +++ b/doc/bugs/post-commit_hangs.mdwn @@ -0,0 +1,47 @@ +# post-commit hangs + +I installed ikiwiki v3.14159 in /usr/local from tarball (/usr contains an older version). Having done so, and used ikiwiki-transition to update setup file, the post commit hook is now blocking in flock (as seen by ps). I should also mention that I added the goodstuff, attachment and remove plugins (which was the purpose of upgrading to v3). Any clues as how to debug/fix gratefully received. The wiki is publically viewable at wiki.sgcm.org.uk if that helps. + +> It's blocking when you do what? Save a page from the web? Make a commit +> to the underlaying VCS? Which VCS? These are all different code paths.. +> --[[Joey]] + +>> It's blocking when I run "ikiwiki --setup ikiwiki.setup" (which calls hg update, which calls ikiwiki --post-commit). +>> Hmm, maybe it's the recursive call to ikiwiki which is the problem. +>> The underlying VCS is mercurial. --Ali + +>>> You're not supposed to run ikiwiki -setup manually in your post commit hook. +>>> Doing so will certianly lead to a locking problem; it also forces ikiwiki to rebuild +>>> the entire wiki anytime a single page changes, which is very inefficient! +>>> +>>> Instead, you should use the `mercurial_wrapper` setting +>>> in the setup file, which will make ikiwiki generate a small +>>> executable expressly designed to be run at post commit time. +>>> Or, you can use the `--post-commit` option, as documented +>>> in [[rcs/mecurial]] --[[Joey]] + +>>>> I don't run ikiwiki --setup in the commit hook; I run ikiwiki --post-commit (as mentioned above). +>>>> I'm trying to run ikiwiki --setup from the command line after modifying the setup file. +>>>> ikiwiki --setup is calling hg update, which is calling ikiwiki --post-commit. Am I not supposed to do that? --Ali + +>>>>> No, I don't think that hg update should call ikiwiki anything. The +>>>>> [[hgrc_example|rcs/mercurial]] doesn't seem to configure it to do that? --[[Joey]] + +>>>>>> Ok, I'm not sure I understand what's going on, but my problem is solved. +>>>>>> +>>>>>> My hgrc used to say: +>>>>>> +>>>>>> [hooks] +>>>>>> +>>>>>> incoming.update = hg up +>>>>>> +>>>>>> update.ikiwiki = ikiwiki --setup /home/ikiwiki/ikiwiki.setup --post-commit +>>>>>> +>>>>>> I've now changed it to match the example page and it works. Thanks --Ali. + +>>>>>>> [[done]] + +> Also, how have you arranged to keep it from seeing the installation in /usr? Perl could well be loading +> modules from the old installation, and if it's one with a different locking strategy that would explain your problem. --[[Joey]] + +>> Good point. Not knowing perl, I just assumed /usr/local would take precedence. I've now used "dpkg -r ikiwiki" to remove the problem. --Ali diff --git a/doc/bugs/post-update_hook_can__39__t_be_compiled_with_tcc.mdwn b/doc/bugs/post-update_hook_can__39__t_be_compiled_with_tcc.mdwn new file mode 100644 index 000000000..a8fb19888 --- /dev/null +++ b/doc/bugs/post-update_hook_can__39__t_be_compiled_with_tcc.mdwn @@ -0,0 +1,19 @@ +Thinking that any c compiler would do the job, I tried to use tcc with ikiwiki, as explicitely allowed by the Debian package dependencies. + +I installed `tcc` and `libc6-dev` (for `libcrt1`). The wrapper compilation was OK, but the wrapper fails to run correctly and dies with + + usage: ikiwiki [options] source dest + ikiwiki --setup configfile + +Everything works fine with gcc. + +versions: Debian lenny + backports + +> Seems that tcc does not respect changing where `environ` points as a way +> to change the environment seen after `exec` +> +> Given that the man page for `clearenv` suggests using `environ=NULL` +> if `clearenv` is not available, I would be lerry or using tcc to compile +> stuff, since that could easily lead to a security compromise of code that +> expects that to work. However, I have fixed ikiwiki to use `clearenv`. +> --[[Joey]] [[done]] diff --git a/doc/bugs/preview_pagestate.mdwn b/doc/bugs/preview_pagestate.mdwn new file mode 100644 index 000000000..7f7ec0976 --- /dev/null +++ b/doc/bugs/preview_pagestate.mdwn @@ -0,0 +1,13 @@ +If a change to a page is previewed, but not saved, `%pagestate` and +`%wikistate` can be changed, and saved. Actually, it's not limited to +those. Seems that spurious dependencies can be added, though existing +dependencies will at least not be removed. + +It calls saveindex to record state about files created on disk for the +preview. Those files will expire later. However, saveindex also +saves other state changes. + +Seems like it needs to isolate all state changes when previewing... ugh. +--[[Joey]] + +[[done]] diff --git a/doc/bugs/rebuild_after_changing_the_underlaydir_config_option.mdwn b/doc/bugs/rebuild_after_changing_the_underlaydir_config_option.mdwn new file mode 100644 index 000000000..8613ef03c --- /dev/null +++ b/doc/bugs/rebuild_after_changing_the_underlaydir_config_option.mdwn @@ -0,0 +1,12 @@ +It seems that rebuild a wiki (`ikiwiki --rebuild`) after changing the `underlaydir` config option doesn't remove the pages coming from the previous underlaydir. + +I've noticed this with the debian package version 3.20100102.3~bpo50+1. + +Perhaps it is possible to improve this or mention it in the manual page? + +--prosper + +> --rebuild causes ikiwiki to throw away all its info about what it built +> before, so it will never clean up pages that have been removed, by any +> means. Suggest you do a --refresh, possibly followed by a --rebuild +> if that is really necessary. --[[Joey]] diff --git a/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn index b4e2a1501..ab08c0b26 100644 --- a/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn +++ b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn @@ -18,3 +18,5 @@ Thanks > rewriting the ikiwiki code to use it, *and* packaging that alternative > and maintaining it in Debian. So your suggestion doesn't make a lot of > sense; Debian should just find a maintainer for sparkline-php. --[[Joey]] + +[[done]] diff --git a/doc/bugs/removing_pages_with_utf8_characters.mdwn b/doc/bugs/removing_pages_with_utf8_characters.mdwn new file mode 100644 index 000000000..0d96aa75f --- /dev/null +++ b/doc/bugs/removing_pages_with_utf8_characters.mdwn @@ -0,0 +1,51 @@ +I have a page with the name "umläute". When I try to remove it, ikiwiki says: + +Error: ?umläute does not exist + +> I'm curious about the '?' in the "?umläute" message. Suggests that the +> filename starts with another strange character. Can I get a copy of a +> git repository or tarball containing this file? --[[Joey]] + +I wrote the following patch, which seems to work on my machine. I'm running on FreeBSD 6.3-RELEASE with ikiwiki-3.20100102.3 and perl-5.8.9_3. + + --- remove.pm.orig 2009-12-14 23:26:20.000000000 +0100 + +++ remove.pm 2010-01-18 17:49:39.000000000 +0100 + @@ -193,6 +193,7 @@ + # and that the user is allowed to edit(/remove) it. + my @files; + foreach my $page (@pages) { + + $page = Encode::decode_utf8($page); + check_canremove($page, $q, $session); + + # This untaint is safe because of the + + +> The problem with this patch is that, in a recent fix to the same +> plugin, I made `@pages` come from `$form->field("page")`, and +> that, in turn is already run through `decode_form_utf8` just above the +> code you patched. So I need to understand why that is apparently not +> working for you. (It works fine for me, even when deleting a file named +> "umläute" --[[Joey]] + +---- + +> Update, having looked at the file in the src of the wiki that +> is causing trouble for remove, it is: `uml\303\203\302\244ute.mdwn` +> And that is not utf-8 encoded, which, represented the same +> would be: `uml\303\244ute.mdwn` +> +> I think it's doubly-utf-8 encoded, which perhaps explains why the above +> patch works around the problem (since the page name gets doubly-decoded +> with it). The patch doesn't fix related problems when using remove, etc. +> +> Apparently, on apoca's system, perl encodes filenames differently +> depending on locale settings. On mine, it does not. Ie, this perl +> program always creates a file named `uml\303\244ute`, no matter +> whether I run it with LANG="" or LANG="en_US.UTF-8": +> +> perl -e 'use IkiWiki; writefile("umläute", "./", "baz")' +> +> Remains to be seen if this is due to the older version of perl used +> there, or perhaps FreeBSD itself. --[[Joey]] +> +> Update: Perl 5.10 fixed the problem. --[[Joey]] diff --git a/doc/bugs/rst_plugin_has_python_hardcode_in_shebang_line.mdwn b/doc/bugs/rst_plugin_has_python_hardcode_in_shebang_line.mdwn new file mode 100644 index 000000000..a594adc09 --- /dev/null +++ b/doc/bugs/rst_plugin_has_python_hardcode_in_shebang_line.mdwn @@ -0,0 +1,15 @@ +Current the rst plugin uses this shebang line: + + #!/usr/bin/python + +The problem is that rst plugin uses some feature (for example, iterator comprehension) which is unavailable on old version of Python. + +So rst plugin will not work on a machine which has an old version of python in system path even though +the user have installed a new version of python in other place. For example, I am using ikiwiki with the rst plugin on Mac OS X 10.4 which ships python 2.3 but I do have python2.6 installed on /opt/local/bin/python (via macports). + +Thus I suggest to change the shebang line to: + + #!/usr/bin/env python + +> [[done]], although the irony of all the perl hashbangs in ikiwiki +> being hardcoded doesn't escape me. --[[Joey]] diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn index 9d433e24e..8667a459b 100644 --- a/doc/bugs/rst_tweak.mdwn +++ b/doc/bugs/rst_tweak.mdwn @@ -41,3 +41,12 @@ what is supposed to happen? --Peter > That's why the [[plugin_page|plugins/rst]] has its note about > issues with wikilinks and directives. You'd have to put those inside > raw directives yourself to avoid rst escaping their result. --[[Joey]] + +You can also create a raw "role" which is at least easier than raw directives. + + .. role:: ikiwiki(raw) + :format: html + + :ikiwiki:`\[[WikiLink]]` + +A role assigns meaning to interpreted text (for example :acronym:`ABC`) or :PEP:`8`. --ulrik [kaizer.se] diff --git a/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn b/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn new file mode 100644 index 000000000..587771ba4 --- /dev/null +++ b/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn @@ -0,0 +1,44 @@ +[[!template id=gitbranch branch=smcv/unescaped-meta author="[[Simon_McVittie|smcv]]"]] +[[!tag patch]] +(Warning: this branch has not been tested thoroughly.) + +While discussing the [[plugins/meta]] plugin on IRC, Joey pointed out that +it stores most meta fields unescaped, but 'title', 'guid' and 'description' +are special-cased and stored escaped (with numeric XML/HTML entities). This +is to avoid emitting markup in the `<title>` of a HTML page, or in an RSS/Atom +feed, neither of which are subject to the [[plugins/htmlscrubber]]. + +However, having the meta fields "partially escaped" like this is somewhat +error-prone. Joey suggested that perhaps everything should be stored +unescaped, and the escaping should be done on output; this branch +implements that. + +Points of extra subtlety: + +* The title given to the [[plugins/search]] plugin was previously HTML; + now it's plain text, potentially containing markup characters. I suspect + that that's what Xapian wants anyway (which is why I didn't change it), + but I could be wrong... + + > AFAICS, this if anything, fixes a bug, xapian definitely expects + > unescaped text here. --[[Joey]] + +* Page descriptions in the HTML `<head>` were previously double-escaped: + the description was stored escaped with numeric entities, then that was + output with a second layer of escaping! In this branch, I just emit + the page description escaped once, as was presumably the intention. + +* It's safe to apply this change to a wiki and neglect to rebuild it + (assuming I implemented it correctly!), but until the wiki is rebuilt, + titles, descriptions and GUIDs for unchanged pages will appear + double-escaped on any page that inlines them in `quick=yes` mode, and + is rebuilt for some other reason. The failure mode is too much escaping + rather than too little, so it shouldn't be a security problem. + +* Reverting this change, if applied, is more dangerous; until the wiki is + rebuilt, any titles, descriptions and GUIDs on unchanged pages that + contained markup could appear unescaped on any page that inlines them + in `quick=yes` mode, and is rebuilt for some other reason. The failure + mode here would be too little escaping, i.e. cross-site scripting. + +[[!tag done]] diff --git a/doc/bugs/stray___60____47__p__62___tags.mdwn b/doc/bugs/stray___60____47__p__62___tags.mdwn index 6e508ffda..99d6fe09f 100644 --- a/doc/bugs/stray___60____47__p__62___tags.mdwn +++ b/doc/bugs/stray___60____47__p__62___tags.mdwn @@ -13,3 +13,5 @@ I believe that this snippet in `IkiWiki.pm` might be the reason for the imbalanc } The fact that HTML in a `\[[!meta title]]` is added but then escaped might indicate that some other bug is involved. + +> [[done]] --[[Joey]] diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn index 139a53760..a71ed7ba9 100644 --- a/doc/bugs/support_for_openid2_logins.mdwn +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -20,3 +20,5 @@ However both Perl OpenID 2.x implementations have not been released and are inco > I've tested with yahoo, and it works with the updated module. Sweet and > [[done]] --[[Joey]] + +## A quick fix for the impatient running stable is simply `sudo apt-get install libnet-openid-consumer-perl -t unstable` diff --git a/doc/bugs/svn_commit_failures_interpreted_as_merge_conflicts.mdwn b/doc/bugs/svn_commit_failures_interpreted_as_merge_conflicts.mdwn new file mode 100644 index 000000000..0c9bce4b9 --- /dev/null +++ b/doc/bugs/svn_commit_failures_interpreted_as_merge_conflicts.mdwn @@ -0,0 +1,21 @@ +I'm attempting a merge with the SVN plugin via the web interface +with ikiwiki-3.20100403 and subversion 1.6.11. + +The web interface says + + Your changes conflict with other changes made to the page. + + Conflict markers have been inserted into the page content. Reconcile the conflict and commit again to save your changes. + +However there are no merge conflict markers in the page. My apache error log says: + + [Fri Apr 30 16:43:57 2010] [error] [client 10.64.64.42] svn: Commit failed (details follow):, referer: https://unixwiki.ncl.ac.uk/ikiwiki.cgi + [Fri Apr 30 16:43:57 2010] [error] [client 10.64.64.42] svn: Authorization failed, referer: https://unixwiki.ncl.ac.uk/ikiwiki.cgi + +-- [[Jon]] + +> Only way for this to be improved would be for the svn plugin to +> explicitly check the file for conflict markers. I guess it could +> change the error message then, but the actual behavior of putting the +> changed file back in the editor so the user can recommit is about right +> as far as error recovery goes. --[[Joey]] diff --git a/doc/bugs/tag_plugin:_autotag_vs._staged_changes.mdwn b/doc/bugs/tag_plugin:_autotag_vs._staged_changes.mdwn new file mode 100644 index 000000000..e5526bedf --- /dev/null +++ b/doc/bugs/tag_plugin:_autotag_vs._staged_changes.mdwn @@ -0,0 +1,17 @@ +The autotag functionality of the tag plugin committed (when doing its +first commit) all changes that have been staged (in Git). I suggest it +should be restricted to the specific file only. --[[tschwinge]] + +> This is not specific to the tag plugin. Same can happen +> if you rename a file, or post a comment, or remove a file +> via web interface. All of these use `rcs_commit_staged`. +> +> This is why ikiwiki is supposed to have a checkout of +> the repository that it uses for its own purposes, and nobody else +> should mess with. There are various notes about that being needed here +> and there; you're free to not give ikiwiki its own repo, but you have to +> be aware that it can fight with you if you're making changes to the same +> repo. [[done]] --[[Joey]] + +>> Ack, that is reasonable. (And it's only been a very minor problem +>> during manual testing.) --[[tschwinge]] diff --git a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn index e7e4af7c3..a211654f1 100644 --- a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn +++ b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn @@ -28,6 +28,8 @@ rationale on this, or what am I doing wrong, and how to achieve what I want? >> is valid. [[todo/matching_different_kinds_of_links]] is probably >> how it will eventually be solved. --[[Joey]] +>>> [[Done]]: `tagged` no longer matches other wikilinks. --[[smcv]] + > And this is an illustration why a clean work-around (without changing the software) is not possible: while thinking about [[todo/matching_different_kinds_of_links]], I thought one could work around the problem by simply explicitly including the kind of the relation into the link target (like the tagbase in tags), and by having a separate page without the "tagbase" to link to when one wants simply to refer to the tag without tagging. But this won't work: one has to at least once refer to the real tag page if one wants to talk about it, and this reference will count as tagging (unwanted). --Ivan Z. > But well, perhaps there is a workaround without introducing different kinds of links. One could modify the [[tag plugin|plugins/tag]] so that it adds 2 links to a page: for tagging -- `tagbase/TAG`, and for navigation -- `tagdescription/TAG` (displayed at the bottom). Then the `tagdescription/TAG` page would hold whatever list one wishes (with `tagged(TAG)` in the pagespec), and whenever one wants to merely refer to the tag, one should link to `tagdescription/TAG`--this link won't count as tagging. So, `tagbase/TAG` would become completely auxiliary (internal) link targets for ikiwiki, the users would edit or link to only `tagdescription/TAG`. --Ivan Z. diff --git a/doc/bugs/templateForRecentChangesMissingCloseSpan.mdwn b/doc/bugs/templateForRecentChangesMissingCloseSpan.mdwn new file mode 100644 index 000000000..5c322991a --- /dev/null +++ b/doc/bugs/templateForRecentChangesMissingCloseSpan.mdwn @@ -0,0 +1,26 @@ +In the template for ikiwiki's recent changes page + + /usr/share/ikiwiki/templates/change.tmpl + +there is a missing </span> tag after the + + <span class="changedate"><TMPL_VAR COMMITDATE> + +This results in the recentchanges/ page being invalid and rendering quite horrifyingly in Internet Exploder. + +[I'm running](http://wiki.shlrm.org) (linked so you can see the one I'm running if you need to) the latest version of ikiwiki, and I note that it's broken on [ikiwiki.info](http://validator.w3.org/check?uri=http%3A%2F%2Fikiwiki.info%2Frecentchanges%2F&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.767) too :) + +[This one on debian](https://www.icanttype.org/recentchanges/) is somehow [valid](http://validator.w3.org/check?uri=https%3A%2F%2Fwww.icanttype.org%2F%2Frecentchanges%2F&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.767), although it's using the same template. Perhaps there's an additional scrubbing going on his end. + +Thanks, +David + +PS: I have fixed the template by hand on my server, so it will validate, however ikiwiki.info will not. + +> [[!template id="gitbranch" branch=smcv/trivia author="[[smcv]]"]] [[!tag patch]] +> Enabling either [[plugins/htmltidy]] or [[plugins/htmlbalance]] will automatically fix unbalanced +> markup like this; using [[plugins/comments]] without having one or other of those is a bad idea +> from the point of view of avoiding comment forgery, which is probably why icanttype.org works +> correctly. Anyway, I've fixed this in a branch: Joey, care to review smcv/trivia? --[[smcv]] + +[[done]], thanks guys --[[Joey]] diff --git a/doc/bugs/the_login_page_is_unclear_when_multiple_methods_exist.mdwn b/doc/bugs/the_login_page_is_unclear_when_multiple_methods_exist.mdwn new file mode 100644 index 000000000..70266c49c --- /dev/null +++ b/doc/bugs/the_login_page_is_unclear_when_multiple_methods_exist.mdwn @@ -0,0 +1,16 @@ +When multiple login methods are enabled, the ikiwiki login page lists one form per method, e.g. + + * one for openid + * one for local user/password store + +Followed by the "login" button underneath. It's not obvious to anyone unfamiliar with the software that these are distinct forms, or that there are multiple ways of logging in, etc. -- [[Jon]] + +> As discussed in [[login_page_non-obvious_with_openid]], +> architectural reasons disallow multiple forms, with multiple +> submit buttons. But the default style sheet includes +> a styling for the openid portion of the form that makes +> it visually distinct from the rest of the form. I'm sure the styling +> could be improved, but the current form does not seem too non-obvious +> to me, or to naive users in the field. --[[Joey]] + +>> [[done]], better fixed by new fancy openid login form. --[[Joey]] diff --git a/doc/bugs/toggle_expects_body_element_without_attributes.mdwn b/doc/bugs/toggle_expects_body_element_without_attributes.mdwn new file mode 100644 index 000000000..0b39346f4 --- /dev/null +++ b/doc/bugs/toggle_expects_body_element_without_attributes.mdwn @@ -0,0 +1,3 @@ +The toggle plugins checks for a `<body>` in the page; if not found, javascript tags are inserted at the top of the document. Since my page uses `<body onload="javascript:fixLinks()">`; a plain `<body>` is not found and I get script links before the docstring declaration. Please see the source of the following toggle-using page: http://kaizer.se/wiki/kupfer/ -- ulrik [kaizer.se] + +[[fixed|done]] --[[Joey]] diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn new file mode 100644 index 000000000..c44fe7962 --- /dev/null +++ b/doc/bugs/transitive_dependencies.mdwn @@ -0,0 +1,94 @@ +If a sidebar contains a map, or inline (etc), one would expect a +add/remove of any of the mapped/inlined pages to cause a full wiki +rebuild. But this does not happen. + +If page A inlines page B, which inlines page C, a change to C will cause B +to be updated, but A will not "notice" that this means A needs to be +updated. + +One way to look at this bug is that it's a bug in where dependencies are +recorded when preprocessing the rendered or sidebar page. The current code +does: + + add_depends($params{page}, $somepage); + +Where `$params{page}` is page B. If this is changed to `$params{destpage}`, +then the dependency is added to page A, and updates to C cause it to +change. This does result in the page A's getting lots more dependency info +recorded than before (essentially a copy of all the B's dependency info). + +It's also a fragile, since all plugins that handle dependencies have to be +changed, and do this going forward. And it seems non-obvious that this should +be done. Or really, whether to use `page` or `destpage` there. Currently, +making the "wrong" choice and using `destpage` instead of `page` (which nearly +everything uses) will just result in semi-redundant dependency info being +recorded. If we make destpage mandatory to fix this, goofing up will lead to +this bug coming back. Ugh. + +---- + +## rebuild = change approach + +[[!template id=gitbranch branch=origin/transitive-dependencies author="[[joey]]"]] + +Another approach to fix it is to say that anything that causes a +rebuild of B is treated as a change of B. Then when C is changed, B is +rebuilt due to dependencies, and in turn this means A is rebuilt because B +"changed". + +This is essentially what is done with wikilinks now, and why, if a sidebar +links to page C, add/remove of C causes all pages to be rebuilt, as seen +here: + + removing old page meep + building sidebar.mdwn, which links to meep + building TourBusStop.mdwn, which depends on sidebar + building contact.mdwn, which depends on sidebar + ... + +Downsides here: + +* Means a minimum of 2x as much time spent resolving dependencies, + at least in my simple implementation, which re-runs the dependency + resolution loop until no new pages are rebuilt. + (I added an optimisation that gets it down to 1.5X as much work on + average, still 2x as much worst case. I suppose building a directed + graph and traversing it would be theoretically more efficient.) +* Causes extra work for some transitive dependencies that we don't + actually care about. This is amelorated, but not solved by + the current work on [[todo/dependency_types]]. + For example, changing index causes + plugins/brokenlinks to update in the first pass; if there's a second + pass, plugins/map is no longer updated (contentless dependencies FTW), + but plugins is, because it depends on plugins/brokenlinks. + (Of course, this is just a special case of the issue that a real + modification to plugins/brokenlinks causes an unnecessary update of + plugins, and could be solved by adding more dependency types.) + +[[done]] --[[Joey]] + +> Some questions/comments... I've thought about this a lot for [[todo/tracking_bugs_with_dependencies]]. +> +> * When you say that anything that causes a rebuild of B is treated as a change of B, are you: i) Treating +> any rebuild as a change, or ii) Treating any rebuild that gives a new result as a change? Option ii) would +> lead to fewer rebuilds. Implementation is easy: when you're about to rebuild a page, load the old rendered html in. Do the rebuild. Compare +> the new and old html. If there is a difference, then mark that page as having changed. If there is no difference +> then you don't need to mark that pages as changed, even though it has been rebuilt. (This would ignore pages in meta-data that don't +> cause changes in html, but I don't think that is a huge issue.) + +>> That is a good idea. I will have to look at it to see if the overhead of +>> reading back in the html of every page before building actually is a +>> win though. So far, I've focused on avoiding unnecessary rebuilds, and +>> there is still some room for more dependency types doing so. +>> (Particularly for metadata dependencies..) --[[Joey]] + +> * The second comment I have relates to cycles in transitive dependencies. At the moment I don't think this is +> possible, but with some additions it may well become so. This could be problematic as it could lead to a) +> updates that never complete, or b) it being theoretically unclear what the final result should be (i.e. you +> can construct logical paradoxes in the system). I think the point above about marking things as changed only when +> the output actually changes fixes any cases that are well defined. For logical paradoxes and infinite loops (e.g. +> two pages that include each other), you might want to put a limit on the number of times you'll rebuild a page in any +> given run of ikiwiki. Say, only allow a page to rebuild twice on any run, regardless of whether a page it depends on changes. +> This is not a perfect solution, but would be a good approximation. -- [[Will]] + +>> Ikiwiki only builds any given output file once per run, already. --[[Joey]] diff --git a/doc/bugs/underlaydir_file_expose.mdwn b/doc/bugs/underlaydir_file_expose.mdwn index c827c6dd8..4ee30e39d 100644 --- a/doc/bugs/underlaydir_file_expose.mdwn +++ b/doc/bugs/underlaydir_file_expose.mdwn @@ -1,4 +1,13 @@ If a file in the srcdir is removed, exposing a file in the underlaydir, -ikiwiki will notice the removal and delete the page from the destdir. The +ikiwiki will not notice the removal, and the page from the underlay will not be built. (However, it will be if the wiki gets rebuilt.) + +> This problem is caused by ikiwiki storing only filenames relative to +> the srcdir or underlay, and mtime comparison not handling this case. + +> A related problem occurs if changing a site's theme with the +> [[plugins/theme]] plugin. The style.css of the old and new theme +> often has the same mtime, so ikiwiki does not update it w/o a rebuild. +> This is worked around in theme.pm with a special-purpose needsbuild hook. +> --[[Joey]] diff --git a/doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn b/doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn index 88dbfc39b..262aa24fc 100644 --- a/doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn +++ b/doc/bugs/unicode_encoded_urls_and_recentchanges.mdwn @@ -2,7 +2,7 @@ it appears that unicode characters in the title that are unicode letters are spa > Filenames can have any alphanumerics in them without the __ escaping. > Your locale determines whether various unicode characters are considered -> alphanumeric. In other words, it just looks at the [[:alpha:]] character +> alphanumeric. In other words, it just looks at the \[[:alpha:]] character > class, whatever your locale defines it to be. --[[Joey]] this is not a problem per se, but (at least with git backend) the recent changes missinterpret the file name character set (it seems to read the filenames as latin1) and both display wrong titles and create broken links. diff --git a/doc/bugs/utf-8_bug_in_websetup.pm.mdwn b/doc/bugs/utf-8_bug_in_websetup.pm.mdwn new file mode 100644 index 000000000..debedb01c --- /dev/null +++ b/doc/bugs/utf-8_bug_in_websetup.pm.mdwn @@ -0,0 +1,22 @@ +[[!tag patch bugs]] + +I type chinese characters into the fields. After press "save setup" button the characters turn into gibberish. + +I submit a patch that solve the problem for me. --Lingo + +> Fully fixing it is slightly more complex, but now [[done]] --[[Joey]] + +---- + + --- websetup.pm 2009-12-02 05:07:46.000000000 +0800 + +++ /usr/share/perl5/IkiWiki/Plugin/websetup.pm 2010-01-08 22:05:16.000000000 +0800 + @@ -308,7 +308,8 @@ + $fields{$_}=$shown{$_} foreach keys %shown; + } + } + - + + + + IkiWiki::decode_form_utf8($form); + if ($form->submitted eq "Cancel") { + IkiWiki::redirect($cgi, $config{url}); + return; diff --git a/doc/bugs/wrapper_can__39__t_find_the_perl_modules.mdwn b/doc/bugs/wrapper_can__39__t_find_the_perl_modules.mdwn new file mode 100644 index 000000000..9804d86c5 --- /dev/null +++ b/doc/bugs/wrapper_can__39__t_find_the_perl_modules.mdwn @@ -0,0 +1,16 @@ +If i intsall perl modules in my custom directory, cgi wrapper can't find them. I found clearing enviroment variables in code of wrapper. But information about custom directories put to perl with PERL5LIB variable. + +Workaround: add newenviron variable PERL5LIB + +My additional question - what wrapper do? I'am russian hosting provider. I am interesting with ikiwiki. + +> The wrapper allows ikiwiki to run as the user who owns the wiki, which +> is generally not the same as the user that runs the web server. +> (It also handles some other things, like some locking.) +> +> As a suid program, the wrapper cannot safely let environment variables +> pass through. +> +> If you want to install ikiwiki's perl modules in a nonstandard location, +> you can set `INSTALL_BASE` when running `Makefile.PL`. ikiwiki will then +> be built to look in that location. --[[Joey]] [[!tag done]] |